clarification about apel-ssm-openstack replacement #15
Comments
|
Hi, you can remove apel-ssm-openstack and replace the two cron jobs with a single one that invokes caso-extract, there is no "push" needed. The ssmsend in cron will still be needed, that's what sends records to the accounting portal. Cheers, |
|
now i get this ssl error, any hint? [apel@egi-cloud ~]$ /home/apel/.virtualenvs/caso/bin/caso-extract |
|
Hi, I am taking the same certificate verify failed error on my installation. Do we need to set true the insecure parameter in caso.conf? Cheers, --feyza |
|
No, you shouldn't use the insecure flag in a production environment. This is not a cASO problem, but a problem with the installation that cASO is using. The SSL error is caused by the requests module when it is use by any of the OpenStack clients. This is due to the fact that it cannot verify the server's certificate because it is not contained in the CA bundle. This will happen for all the OpenStack clients, not only for cASO.
In either case, it is needed to add tha CA that signed the host's certificates to the trusted CA bundle that requests is using. In the case of the system-wide bundles, you should refer to the documentation of those packages. In the case of using the requests' vendorized CA bundle, I guess it is enough to append the correct certificates to the end of the @marcoverl, you are in the later case (you have your own installation in @feyzaeryol I do not know the details of your installation, but I hope that the information above helps you. |
|
Hi Alvaro, This solves my problem. Now it is works without any error. Cheers, --feyza |
|
ok, fixed the issue with the cert bundle, now i get some issue related to keystone users: [apel@egi-cloud ~]$ /home/apel/.virtualenvs/caso/bin/caso-extract |
|
This was already solved in #11, please update caso to 0.1.2. |
|
ok, i've updated to 0.1.2, but now i have auth. issues, even if everything seems ok in the caso.conf, and OS commands works for the OS accounting user as expected from the command line. (caso)[apel@egi-cloud ~]$ caso-extract -d -v |
|
Almost nothing has changed from 0.1.1 to 0.1.2, so this should not be because of the update (the only relevant change was the fix for #11 ( In #15 (comment) you were already contacting nova (it failed loading the users from Keystone), now you are not able to contact it again, and that code has not changed. |
|
Hi, i got some progress if i run caso-extract as root instead as apel (i am talking about linux user here). (caso)[root@egi-cloud]# caso-extract --version |
|
ok it was due to the Nova API bug you pointed out in the documentation, when using with |
|
but unfortunately the error still arise if --extract_from option is not used, even if the file /var/spool/caso/lastrun now does exist |
|
ok, actually the behaviour above is not reproducible, i can have: (caso)[root@egi-cloud ~]# caso-extract -v and a two minutes later everyhting ok: (caso)[root@egi-cloud ~]# caso-extract -v so, i think i can close the issue. |
Hello,
i am not sure what i should replace:
i have a cron job with:
[root@egi-cloud ~]# cat /var/lib/osssm/cron
-# extract and buffer usage records
0 */2 * * * apel /usr/bin/osssm.extract
-# send buffered usage records to APEL/SSM
15 */12 * * * apel /usr/bin/osssm.push
-# send buffered usage records to GOC
30 */24 * * * apel /usr/bin/ssmsend
where: /usr/bin/osssm.extract , .push and /etc/osssmrc come from:
[root@egi-cloud ~]# rpm -qf /usr/bin/osssm.extract
apel-ssm-openstack-1.19-1.noarch
and
[root@egi-cloud ~]# rpm -qf /usr/bin/ssmsend
apel-ssm-2.1.1-0.el6.noarch
In /etc/osssmrc i have some config. values similar to the one i have now in /etc/caso/caso.conf.
So, can i simply remove apel-ssm-openstack-1.19-1.noarch and replace /usr/bin/osssm.extract in the cron job with caso-extract?
what about /usr/bin/osssm.push? is something done inside caso-extract?
The text was updated successfully, but these errors were encountered: