Sunday, 2019-05-26

*** markvoelker has quit IRC00:18
*** hwoarang has quit IRC00:39
*** hwoarang has joined #openstack-ansible00:39
*** kplant has joined #openstack-ansible00:44
*** kplant has quit IRC00:49
*** hwoarang has quit IRC00:50
*** hwoarang has joined #openstack-ansible00:50
*** sreejithp has joined #openstack-ansible00:56
*** hwoarang has quit IRC01:01
*** hwoarang has joined #openstack-ansible01:01
*** CeeMac has quit IRC01:02
*** hwoarang has quit IRC01:19
*** hwoarang has joined #openstack-ansible01:25
*** sreejithp has quit IRC01:39
*** kplant has joined #openstack-ansible01:40
*** hwoarang has quit IRC02:03
*** hwoarang has joined #openstack-ansible02:03
*** sreejithp has joined #openstack-ansible02:14
*** markvoelker has joined #openstack-ansible02:15
*** sreejithp has quit IRC02:22
*** hwoarang has quit IRC02:24
*** hwoarang has joined #openstack-ansible02:24
*** dave-mccowan has joined #openstack-ansible02:32
*** dave-mccowan has quit IRC02:36
*** kplant has quit IRC02:38
*** markvoelker has quit IRC02:49
*** sreejithp has joined #openstack-ansible02:57
*** kplant has joined #openstack-ansible03:06
*** kplant has quit IRC03:11
*** BjoernT has joined #openstack-ansible03:23
*** BjoernT has quit IRC03:27
*** BjoernT has joined #openstack-ansible03:29
*** Talion has joined #openstack-ansible03:57
*** hwoarang has quit IRC03:57
*** hwoarang has joined #openstack-ansible03:58
*** BjoernT has quit IRC04:01
*** sreejithp has quit IRC04:06
*** hwoarang has quit IRC04:08
*** hwoarang has joined #openstack-ansible04:09
*** radeks has joined #openstack-ansible04:16
*** radeks has quit IRC04:17
*** radeks_ has joined #openstack-ansible04:17
*** hwoarang has quit IRC04:33
*** hwoarang has joined #openstack-ansible04:33
*** markvoelker has joined #openstack-ansible04:46
*** radeks_ has quit IRC05:02
*** markvoelker has quit IRC05:19
*** Talion has quit IRC05:44
*** Talion has joined #openstack-ansible05:44
*** Talion has quit IRC05:46
*** Talion has joined #openstack-ansible05:46
*** hwoarang has quit IRC05:48
*** hwoarang has joined #openstack-ansible05:48
*** hwoarang has quit IRC05:53
*** hwoarang has joined #openstack-ansible05:54
*** altlogbot_0 has quit IRC06:29
*** altlogbot_3 has joined #openstack-ansible06:29
openstackgerritDmitriy Rabotyagov (noonedeadpunk) proposed openstack/openstack-ansible-os_keystone master: Execute the keystone db setup earlier in the process  https://review.opendev.org/65967606:43
*** hwoarang has quit IRC07:09
*** hwoarang has joined #openstack-ansible07:09
openstackgerritOpenStack Proposal Bot proposed openstack/openstack-ansible master: Imported Translations from Zanata  https://review.opendev.org/65873107:10
*** kplant has joined #openstack-ansible07:12
*** markvoelker has joined #openstack-ansible07:16
*** kplant has quit IRC07:16
*** hwoarang has quit IRC07:19
*** hwoarang has joined #openstack-ansible07:19
*** hwoarang has quit IRC07:25
*** hwoarang has joined #openstack-ansible07:25
*** markvoelker has quit IRC07:49
*** radeks_ has joined #openstack-ansible07:51
*** sreejithp has joined #openstack-ansible08:02
*** sreejithp has quit IRC08:06
*** markvoelker has joined #openstack-ansible08:46
*** markvoelker has quit IRC09:19
*** hamzaachi has joined #openstack-ansible09:20
*** hwoarang has quit IRC09:32
*** hwoarang has joined #openstack-ansible09:32
*** Talion has quit IRC09:47
*** hwoarang has quit IRC10:32
*** hwoarang has joined #openstack-ansible10:33
*** markvoelker has joined #openstack-ansible11:15
*** hwoarang has quit IRC11:16
*** hwoarang has joined #openstack-ansible11:16
*** hwoarang has quit IRC11:25
*** hwoarang has joined #openstack-ansible11:25
*** markvoelker has quit IRC11:50
*** dave-mccowan has joined #openstack-ansible11:52
*** hwoarang has quit IRC11:55
*** hwoarang has joined #openstack-ansible11:56
*** dave-mccowan has quit IRC12:13
*** kplant has joined #openstack-ansible12:20
*** tosky has joined #openstack-ansible13:05
*** markvoelker has joined #openstack-ansible13:46
*** markvoelker has quit IRC14:20
*** adrianreza has quit IRC14:33
*** hwoarang has quit IRC14:42
*** hwoarang has joined #openstack-ansible14:43
*** hwoarang has quit IRC14:52
*** hwoarang has joined #openstack-ansible14:52
*** Talion has joined #openstack-ansible15:12
*** markvoelker has joined #openstack-ansible15:16
*** hwoarang has quit IRC15:22
*** hwoarang has joined #openstack-ansible15:23
*** hwoarang has quit IRC15:42
*** hwoarang has joined #openstack-ansible15:42
*** markvoelker has quit IRC15:50
*** sreejithp has joined #openstack-ansible16:03
*** sreejithp has quit IRC16:07
*** hwoarang has quit IRC16:33
*** hwoarang has joined #openstack-ansible16:33
*** hamzaachi has quit IRC16:42
*** markvoelker has joined #openstack-ansible16:47
*** hwoarang has quit IRC16:52
*** hwoarang has joined #openstack-ansible16:52
*** markvoelker has quit IRC17:20
openstackgerritJonathan Rosser proposed openstack/openstack-ansible master: Update to ceph-ansible 4.0.0  https://review.opendev.org/65650317:47
*** tosky has quit IRC17:48
*** tosky has joined #openstack-ansible17:49
*** noonedeadpunk has joined #openstack-ansible18:02
noonedeadpunkfolks, can you knidly vote on translations patch https://review.opendev.org/#/c/658731/ to get it merged, until futher potential bugs hasn't landed:)18:03
openstackgerritDmitriy Rabotyagov (noonedeadpunk) proposed openstack/openstack-ansible master: Fix OS requirments  https://review.opendev.org/66149618:22
openstackgerritDmitriy Rabotyagov (noonedeadpunk) proposed openstack/openstack-ansible master: Fix OS requirments  https://review.opendev.org/66149618:24
openstackgerritMerged openstack/openstack-ansible master: Imported Translations from Zanata  https://review.opendev.org/65873118:32
openstackgerritDmitriy Rabotyagov (noonedeadpunk) proposed openstack/openstack-ansible master: Fix OS requirments  https://review.opendev.org/66149618:54
*** markvoelker has joined #openstack-ansible19:16
*** pnull has joined #openstack-ansible19:25
*** markvoelker has quit IRC19:50
*** tosky has quit IRC20:18
*** tosky has joined #openstack-ansible20:26
guilhermespnoonedeadpunk: nice, looking20:27
guilhermespbtw, are you around noonedeadpunk ?20:28
noonedeadpunkkinda)20:28
noonedeadpunkalthough it's 11.30 pm)20:29
guilhermesphahaha well it is just something about your comments here https://review.opendev.org/#/c/657036/20:30
guilhermespbefore I move on with other patches on the topic20:30
guilhermespI'd like to discuss quickly about your suggestions ( no worrie, it is sunday so if you prefer we can talk tomorrow )20:30
guilhermespops, actually wrong patch20:31
guilhermespis that one https://review.opendev.org/#/c/657029/20:31
noonedeadpunkit's ok) sure, we can discuss now20:31
guilhermespall right so20:31
guilhermespyou suggest changing the second condition and add run_once20:32
guilhermespI suppose run_once would replace that second condition?20:32
guilhermespso we make the code simpler?20:32
noonedeadpunkyep, sure20:32
guilhermespnice, I was thinking correctly then. I will test it locally and make the changes :)20:33
guilhermespthat's is noonedeadpunk20:33
guilhermespthat's it*20:33
noonedeadpunkI was just referencing to ceilometer job at once, but this role has service list, that's where comment regarding intersect came from:)20:33
guilhermespneat20:33
guilhermespthx for the clarification!20:33
noonedeadpunkbtw, seems, that we have some tempest problem with octavia for a while.... was trying to locate what's wrong, but probably I should continue tomorrow...20:35
guilhermespyeah, I need to take a look at the integration of placement in openstack-ansible-tests to be able to unblock https://review.opendev.org/#/c/654942/20:36
guilhermespthat's an initial idea https://review.opendev.org/#/c/661179/120:36
noonedeadpunkoh, yep, I see20:38
noonedeadpunkI think that dependency on https://review.opendev.org/#/c/661179/1 may not work, due to the way we clone it20:42
guilhermespyeah, I need to figure out the best way to do it. Maybe merge that patch and then recheck tempest patch. But I need to be sure all files are modified as expected in that patch. I still have a feeling that something is missing20:46
guilhermespbtw noonedeadpunk I saw that the other patches mnaser did he added the run_once in the main task https://review.opendev.org/#/c/657036/7/tasks/main.yml20:47
guilhermespfor that reason I will change only glance patch to behave the same way20:47
noonedeadpunkrun_once in main task won't work afaik20:47
noonedeadpunkbut it's smth worth checking one more time20:48
guilhermespactually only keystone patch has run_once in main20:48
noonedeadpunkI think that merging patch to ansible-tests in by far the only way all-in-all20:48
guilhermespwould I expect like, running the tests locally, the first time I will see changed status and the second run, skip20:49
guilhermespI can do it now with keystone patch btw and see how it goes, if works, replicate to the other patches20:49
*** radeks_ has quit IRC20:50
noonedeadpunkI'm wondering if serial run somehow affects run_once...20:52
guilhermespdoes serial runs by default?20:53
guilhermespthat's something I'm a bit confusing now... here we have conditions https://review.opendev.org/#/c/657038/7/tasks/main.yml, and here we just have run_once https://review.opendev.org/#/c/657036/7/tasks/main.yml20:53
guilhermespI'd expect a reason for that. But if we don't have a reason, we need to apply a pattern20:54
guilhermespto make things consistent20:54
noonedeadpunkguilhermesp: I think it is, at least for keystone...20:54
noonedeadpunkI'd vote for run_once, as this condition is smth not really easy to read and unerstand, while run_once is more readable and do exactly required thing (at least supposed to)20:56
guilhermespI'm running tests locally here. As I told ya, I'd expect this first time to be changed status and the second run, to be skip. If so, we have our answer :)20:56
noonedeadpunkWhen I've checked for ceilometer - run_once didn't work for me for include - I had to place it for block and it was ok then20:57
guilhermespI see a run_once in mq_setup tho https://github.com/openstack/openstack-ansible-os_ceilometer/blob/bc0a2619e4065460357d42797fe54e0f1346685f/tasks/main.yml#L9620:58
guilhermespmaybe works because we change from include to import_tasks?20:59
noonedeadpunkYeah, this might be the case:) Or I just missed smth - who knows now:)21:00
guilhermespmaybe I'd have answers soon :)21:00
logan-The difference is run_once will run multiple times if serial is used21:02
logan-(It will run once per serial batch)21:02
noonedeadpunklogan-: but I think it won't if run_once is set for block....21:02
noonedeadpunkinside import...21:03
noonedeadpunkYeah, let's just wait for results:)21:03
logan-The gate results won’t show you anything because there is only one serial batch21:04
guilhermespwould I expect  a different behavior running local with run_tests logan- ?21:04
noonedeadpunkwith run_tests - not likely, unless you've got multi node aio configured21:05
logan-If you execute the tasks in a playbook with multiple serial batches then yes you will see a difference between those conditionals and a run_once21:05
logan-I can build a poc playbook to show you later21:05
guilhermespthat would be nice logan- thanks in advance21:05
guilhermespi'm still just wondering why some roles uses two conditionals instead of run_once like keystone21:06
guilhermespfor both db_setup and mq_setup21:06
logan-keystone playbook isn’t serialized right?21:07
jrosseron the subject of serial, this has to be a bug? https://github.com/openstack/openstack-ansible/blob/master/playbooks/os-cinder-install.yml#L2821:07
jrosseri would expect some [ ] there21:07
logan-Because the role itself handles serialized orchestration on certain tasks21:07
logan-jrosser: yep I agree21:08
guilhermespI can't see something explicit about serial  in keystone21:08
logan-guilhermesp: yeah the playbook is not serialized so run_once is effectively the same as the conditional in that situation21:09
guilhermespall right by consequence the others that uses when are serialized, I just can't see this explicitly btw21:10
openstackgerritJonathan Rosser proposed openstack/openstack-ansible master: Correct os-cinder-install task serialisation  https://review.opendev.org/66150221:14
Pilouguilhermesp: besides serial, there is one difference between two conditionals and run_once: tasks could be executed on different servers21:14
guilhermesphum Pilou If I understood correctly, if I have tree nodes in my lb cool, run_once will take any of them, with these conditionals https://review.opendev.org/#/c/657038/7/tasks/main.yml I will pick one specific server to run the task21:15
noonedeadpunkyep, that's true, but in this case we're delegating task, so we shouldn;t care about htis21:15
guilhermesplb pool* ( lb is cool anyways ) :P21:16
*** tosky has quit IRC21:17
jrosser"When used together with “serial”, tasks marked as “run_once” will be run on one host in each serial batch. If it’s crucial that the task is run only once regardless of “serial” mode, use when: inventory_hostname == ansible_play_hosts[0] construct."21:20
guilhermespthat clarifies a lot jrosser thanks. But I'm just trying to point out where we identify if role X is serialized and Y is not ( e.g os_glance and os_keystone respectively )21:22
noonedeadpunkBut once we allow deployer to override serial we probably shoudnt rely on run_once then:(21:25
jrosserYes there are a bunch of overrides for serial21:25
guilhermespthat's a good point noonedeadpunk21:25
jrosserI’m not sure if they are important for upgrades21:26
jrosserSimilarly for any reordering of tasks for db setup, I have distant memeories of comments that things are ordered as they are to handle both greenfield and upgrades OK21:27
jrosserBut I’ve not really thought about it enough to know what is right21:27
guilhermespto conclude my thoughts about run_once. I think executing db or mq stuff could be ok to perform in any of the nodes of the cluster. If you agree with that, I'd vote to convert the other tasks to run_once.  noonedeadpunk point of allowing deployers makes run_once preferable tho21:32
*** markvoelker has joined #openstack-ansible21:47
logan-guilhermesp: regarding your question about what’s serialized and what’s not.. serialization is always controlled in the playbook, never in roles or tasks. In general, for these mq/db tasks, we should not use run_once since it is less efficient in many of our playbooks21:55
guilhermespok logan- so, with that said then, would be better to replace run_once in keystone task to make things consistence ( noonedeadpunk just read it wrong, you said the opposite, we shoudn't use run_once since we allow override serial )21:58
logan-yeah if you are planning to use the same task file everywhere i would not use run_once22:03
logan-in something like keystone where it is not serialized both of these will behave identically, in something like nova/neutron/cinder/etc, the conditional will behave more like we want than run_once22:04
guilhermespas I result of the discussion logan- yeah, I'd prefer to keep it consistent across all roles, since conditional will offer us more then run_once :)22:04
guilhermespI will change the keystone role to conditionals and see how it goes locally22:04
guilhermespanyways, thanks Pilou noonedeadpunk jrosser and logan- enjoy the rest of your weekend!22:05
*** noonedeadpunk has quit IRC22:13
*** markvoelker has quit IRC22:20
*** hwoarang has quit IRC22:57
*** hwoarang has joined #openstack-ansible22:57
*** hwoarang has quit IRC23:04
*** hwoarang has joined #openstack-ansible23:04
djhankbIf I wanted to deploy a third party driver along with my Cinder-Volume container - is there a built-in mechanism for doing so? (I am specifically wanting to use this: https://github.com/iXsystems/cinder)23:17
djhankbI can configure a cinder-backend in the "openstack_user_config.yml" file which works perfectly if I let it fail the first time, copy the driver into the containers and then run it again.   I've found that you guys have built other stuff into the system (Like Horizom custom Theme installation) and was curious if Cinder Drivers is one of them.23:18
guilhermespdjhankb: I think that might be your case https://docs.openstack.org/openstack-ansible-os_cinder/latest/configure-cinder.html#configuring-cinder-to-use-dell-equallogic I used this one to add dell equallogic to serve as backend for the deployment.23:20
djhankbguilhermesp: Thank you - in that case the driver is already built in to the venv: /openstack/venvs/cinder-19.0.0.0rc2/lib/python2.7/site-packages/cinder/volume/drivers/dell_emc/ps.py23:22
djhankbwhat I am asking, is if there is a mechanism to copy a third party driver *into* the venv upon creation, so I don't have to manually copy the driver into the  /openstack/venvs/cinder-19.0.0.0rc2/lib/python2.7/site-packages/cinder/volume/drivers/ folder manually, after the container is created.23:23
*** hwoarang has quit IRC23:29
*** hwoarang has joined #openstack-ansible23:30

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!