| opendevreview | Merged openstack/openstack-ansible-os_horizon master: Fix ALLOWED_HOSTS https://review.opendev.org/c/openstack/openstack-ansible-os_horizon/+/844815 | 02:10 |
|---|---|---|
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_horizon stable/yoga: Fix ALLOWED_HOSTS https://review.opendev.org/c/openstack/openstack-ansible-os_horizon/+/847653 | 06:55 |
| noonedeadpunk | https://review.opendev.org/c/openstack/openstack-ansible/+/847652 rly still has post failures?! | 06:55 |
| noonedeadpunk | so basically it's not even ara reports that was big. it's absolutely dead swift providers | 06:59 |
| jrosser_ | yes i agree | 07:02 |
| jrosser_ | i was wondering if we could modify the zuul swift upload task to put the target swift service into the task name | 07:02 |
| jrosser_ | well - or maybe the zuul API would tell us where the logs should have been | 07:03 |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible master: DNM - display tree of collected logs https://review.opendev.org/c/openstack/openstack-ansible/+/844817 | 07:04 |
| noonedeadpunk | I think infra folks just didn't see a problem with any... | 07:16 |
| jrosser_ | it would also help if the logs upload made some stats | 10:03 |
| jrosser_ | maybe we run into some LB rate limit somewhere in front of swift endpoint | 10:04 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Fix facts gathering for zun https://review.opendev.org/c/openstack/openstack-ansible/+/846799 | 11:32 |
| depasquale | ciao guys there is some one that can help me with a magnum-keystone integration issue? | 12:18 |
| depasquale | I was going to report a possible bug, but I wanted to ask before to someone | 12:18 |
| depasquale | ok let's try to be fast and clear. I have a complete working stable/xena environment installed with openstack-ansible... I have added magnum service and I am trying to create a kubernetes cluster for the first time. I have used during the installation self-signed SSL certificates generated by ansible | 12:21 |
| depasquale | when I launch the fedora-coreos image, everything is installed properly but the heat stack stuck waiting for the master node to complete the installation procedure and triggere an event to Heat to mark as complete the task | 12:22 |
| depasquale | looking at the journal of the master node created, it is trying to contact keystone on its public endpoint but it is not able to trust the SSL certificate and then refuses and generate an exception that prevent to complete the procedure | 12:23 |
| depasquale | any suggestion? | 12:23 |
| depasquale | workaround? | 12:23 |
| depasquale | just for your information I am installing on baremetal no Kolla neither virtualized environments | 12:24 |
| depasquale | I have installed openstack-ansible from source | 12:24 |
| noonedeadpunk | depasquale: hey. It;s interesting. I believe we should have spawn a cluster in CI tempest jobs somehow | 12:44 |
| noonedeadpunk | eventually one workaround would be to use let's encrypt certs at least for public endpoint. You can check doc on how to enable them here: https://docs.openstack.org/openstack-ansible/latest/user/security/index.html#certbot-certificates Obviously it requires VIP to be an fqdn rather then IP | 12:47 |
| noonedeadpunk | depasquale: as a workaround, I think that `[drivers]/verify_ca` is smth that is in charge of that | 12:49 |
| noonedeadpunk | so highly likely, you should be able to define these with smth like that https://paste.openstack.org/show/bcOIIa79lSgwoj5UJQtu/ | 12:51 |
| noonedeadpunk | or even define openstack_ca_file in the same section to trust internal CA | 12:51 |
| opendevreview | Merged openstack/openstack-ansible-os_manila master: Create backends when running against manila_share https://review.opendev.org/c/openstack/openstack-ansible-os_manila/+/847276 | 13:03 |
| jrosser_ | depasquale: have you looked at the `openstack_ca_file` setting in magnum.conf? | 14:31 |
| depasquale | ciao guys thanks for the answers. I will try to answer: 1) I cannot use let's encrypt certificate in my scenario because no public access is foreseen to the infrastructure | 14:48 |
| depasquale | 2) I have already tried to modify the magnum.config with the verify_ca=False (https://paste.openstack.org/show/bstbOgvzUZelxx0VLe1P/) but it seems does not help | 14:49 |
| depasquale | I did this manually on all the 3 infra-magnum containers | 14:49 |
| depasquale | I am going to test the magnum_config_overrides: in my user_variables.yml by executing again os-magnum-install.yml... hoping this will not just change the magnum.conf data that I have already modified | 14:51 |
| depasquale | I have reported details here: https://bugs.launchpad.net/openstack-ansible/+bug/1979898 | 14:51 |
| jrosser_ | yes it will remove your local changes | 14:51 |
| jrosser_ | tbh this is not an openstack-ansible bug | 14:51 |
| depasquale | ok | 14:52 |
| depasquale | so you think the bug is on magnum side so I have to report this to the project, I am right, I am not? | 14:52 |
| jrosser_ | if you've set verify_ca then the next thing to do is to ssh to the magnum cluster nodes and debug whats going on | 14:53 |
| jrosser_ | it could be just as likley that the cluster node tries to contact your internal endpoint (by mistake) for example | 14:53 |
| depasquale | I did ;) I have just reported the journal error that point out the problem with SSL | 14:53 |
| depasquale | no no they connect to the public endpoint (10.0.0.10:5000) | 14:54 |
| depasquale | but the SSL verification fails... probably it is because during the configuration of the master node (heat) does not copy the right SSL certificates to the target machine | 14:54 |
| jrosser_ | it does also depend which library/tool is failing there | 14:56 |
| jrosser_ | python for example does not use the system CA stor | 14:56 |
| jrosser_ | e | 14:56 |
| depasquale | If I will not find a solution, probably in the next trial I will go to install the overall openstack without SSL just to relax possible mistakes. in my scenario the openstack cluster is used only by internals and so I can relax security a little bit | 14:56 |
| depasquale | ok jrosser_ I will double check any possible solution/workaround | 14:57 |
| jrosser_ | it would be worth checking the magnum code with what is supposed to happen with verify_ca | 14:57 |
| jrosser_ | and see if this actually happens in the scripts that are sent to the cluster node | 14:58 |
| depasquale | If I find the place where the call is made, I would be happy also to just try to complete the process by modifing by hand the call | 14:58 |
| depasquale | ok I will continue to investigate | 14:59 |
| depasquale | ;) | 14:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!