14:00:01 <tellesnobrega> #startmeeting sahara
14:00:01 <openstack> Meeting started Thu Mar 14 14:00:01 2019 UTC and is due to finish in 60 minutes.  The chair is tellesnobrega. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:05 <openstack> The meeting name has been set to 'sahara'
14:00:13 <jeremyfreudberg> o/
14:00:35 <tosky> o/
14:01:22 <tellesnobrega> hi folks
14:01:29 <tellesnobrega> lets get it started
14:02:01 <tellesnobrega> #topic News/Updates
14:02:58 <tellesnobrega> So, I finally got the python 3 patch working
14:03:15 <tellesnobrega> we are very close to getting that in so we can complete the community goal
14:04:06 <tellesnobrega> after some trouble we were able to cut a release for all plugins
14:06:29 <tellesnobrega> jeremyfreudberg, tosky any updates?
14:07:27 <tosky> with some help from openstack-ansible people I managed to send a patch which should unlock os_sahara gates and support the plugins
14:08:25 <tellesnobrega> awesome
14:08:35 <jeremyfreudberg> not much updates, no. but i did read through the community goal (open for review in the governance repo) on project deletion and thought a bit about sahara fits in
14:08:51 <tosky> only puppet-sahara and kolla need plugin support
14:09:14 <tellesnobrega> jeremyfreudberg, I did not see it yet, can you explain a little more?
14:10:00 <tosky> there was a call for reviewing it, also directed to specific teams, if I remember correctly; but I didn't follow it
14:10:07 <jeremyfreudberg> potentially in the Train cycle there will be a new mechanism to delete a project and all the resources which it owns in a clean way
14:10:57 <jeremyfreudberg> i think the goal is a good idea and i'm happy for sahara to participate, there were just two things to look out for
14:11:05 <jeremyfreudberg> sahara support in openstacksdk
14:11:07 <jeremyfreudberg> and
14:11:30 <jeremyfreudberg> the current inability of admin/system user to delete Sahara resources owned by a different project
14:11:40 <tosky> the openstacksdk goal seems to be restricted to few projects (or just glance?) in Train
14:12:08 <jeremyfreudberg> tosky, if i understood the project deletion goal, it also wants to have support for all services in sdk, but i may be wrong
14:12:09 <tellesnobrega> I will take a look after the meeting
14:12:24 <tellesnobrega> but does sound like something interesting for sahara
14:12:33 <tosky> uh, I thought they were unrelated
14:12:45 <tosky> but sure, no problem
14:13:04 <jeremyfreudberg> they are somewhat co-mingled
14:13:16 <jeremyfreudberg> we can discuss it again later, this was just my update, not the final discussion
14:14:15 <tellesnobrega> nice
14:15:04 <tellesnobrega> we can continue to discuss this
14:17:03 <tellesnobrega> moving on
14:17:07 <moisa> exit
14:17:26 <tellesnobrega> #topic Python 3
14:19:32 <tellesnobrega> so tosky, at this point, what is missing for us to merge the python3 patch?
14:22:45 <tosky> I didn't recheck the patch after my last comment; there is a piece of code were stdout (and then stderr) is decoded, but in case of failure nothing happens
14:22:59 <tosky> but then the value may not be correct when/if it is used later
14:23:33 <jeremyfreudberg> i had a concern about the try/except logic as well -- do we expect the decoding to sometimes fail, or is the try/except only about if the object even has the attribute .decode ?
14:23:39 <jeremyfreudberg> s/concern/question
14:26:04 <tellesnobrega> I can double check that, and we may not even need that try again
14:26:15 <tellesnobrega> I will send a new patch and see how it goes
14:27:45 <jeremyfreudberg> cool
14:30:22 <tellesnobrega> do you have any specific topics for today?
14:30:50 <jeremyfreudberg> i have two little notes, not really full-fledged topics; they can be "open discussion"
14:31:21 <tellesnobrega> sure
14:31:25 <tellesnobrega> lets go
14:31:28 <tosky> I have a request for suggestions about few zuul patches too
14:31:34 <tosky> I will ask at the end
14:31:34 <tellesnobrega> #topic Open Discussion
14:31:49 <jeremyfreudberg> https://storyboard.openstack.org/#!/story/2005194
14:32:24 <jeremyfreudberg> i was surprised to see this story -- the sahara-db-manage cli is just a thin wrapper around alembic
14:32:47 <jeremyfreudberg> and i think a problem with migrations would also be caught be grenade, but maybe not
14:33:01 <jeremyfreudberg> has anybody looked into it?
14:33:23 <tosky> only if the tests execute something related to a database field which was affected by the migration
14:33:44 <tosky> but we can at least check the logs
14:34:44 <jeremyfreudberg> maybe we can add a simple check in the grenade job which explicitly makes use of the boot from volume fields (i.e., create a node group template with these values)
14:35:12 <jeremyfreudberg> (boot from volume is the only change to db schema in recent history)
14:36:42 <tosky> sahara-db-manage is called by grenade
14:37:07 <tosky> logs in few seconds
14:37:50 <tosky> from https://review.openstack.org/#/c/639202/, which can be merged now as heat tests are not executed anymore, I can see this:
14:38:02 <tosky> http://logs.openstack.org/02/639202/9/check/sahara-grenade/793c34b/logs/grenade.sh.txt.gz#_2019-03-09_00_59_46_381
14:38:42 <tosky> this is ^^ the call in the new environment, which means that sahara-db-manage is called against a rocky environment and it upgrads to head/master
14:38:49 <tosky> let me check a stable/rocky review
14:39:51 <tosky> from https://review.openstack.org/#/c/641616/, merged yesterday: http://logs.openstack.org/16/641616/1/gate/sahara-grenade/3110fe5/logs/grenade.sh.txt.gz#_2019-03-12_19_38_19_707
14:41:32 <jeremyfreudberg> yup, so the upgrade command works, it may just be this strange check_migration command
14:41:34 <tosky> but that's upgrade, not check_migration
14:41:37 <jeremyfreudberg> yup
14:42:04 <tosky> I wonder if it is supposed to show anything
14:42:21 <jeremyfreudberg> it boils down to (i think) the alembic branches command
14:42:28 <jeremyfreudberg> not that i know much about alembic
14:44:25 <tosky> ok, action item: does anyone want to answer and/or investigate?
14:45:40 <jeremyfreudberg> it should be as simple as rewinding the db one migration and then trying the command mentioned in the story, i think
14:45:51 <jeremyfreudberg> i can probably get to investigating it, at some point
14:46:27 <tellesnobrega> thanks jeremyfreudberg it will be great if you can
14:46:35 <jeremyfreudberg> yup, will do
14:46:38 <tellesnobrega> let me know if you are too busy and I can give it a try
14:47:27 <tosky> we don't support downgrades, but a possible way may be deploying a stable version and then switch the source to a newer branch or master
14:47:35 <tosky> anyway
14:47:41 <jeremyfreudberg> got it
14:47:43 <tosky> you mentioned two notes
14:47:59 <jeremyfreudberg> yeah, the other note was just about a final release of pike
14:48:21 <jeremyfreudberg> someone on the mailing list helpfully compiled a list of all our unreleased patches, https://etherpad.openstack.org/p/sahara-stable-pike-em
14:49:07 <jeremyfreudberg> i don't recall if the final pike release will be automatic (when extended maintenance begins) or if we have to do it ourself
14:49:08 <tosky> oh, ignore that :)
14:49:39 <tosky> we were waiting for few devstack fixes to deploy tempest correctly from master when testing against a stable branch
14:50:14 <tosky> the last patch landed few hours ago, and our pending patches for pike are being merged right now (2 already merged, I proposed other 2 lingering on my system, they are almost merged)
14:50:20 <jeremyfreudberg> got it
14:50:43 <jeremyfreudberg> i figured tosky would have it under control, just wanted to mention it to be sure
14:50:49 <tellesnobrega> when all is done we can release a new pike
14:50:59 <tosky> and a new queens, maybe
14:51:05 <tosky> we have a long pile of patches
14:51:31 <tellesnobrega> yes
14:52:39 <tellesnobrega> tosky, you have the floor now
14:53:03 <jeremyfreudberg> yes, the zuul stuff
14:53:45 <tosky> it's related to the previous point: I was waiting for this pike patch https://review.openstack.org/#/c/643176/ to send out this fix for sahara-tests: http://paste.openstack.org/show/747783/
14:54:35 <tosky> so that we use again the job named sahara-tests-scenario in  consistent way, but it use the correct python (this is the python for the sahara-scenario command, not the devstack deployment)
14:54:46 <tosky> now, there are two other zuul patches pending for sahara-tests, namely:
14:55:08 <tosky> - more gating jobs (API v2 and py3.7): https://review.openstack.org/#/c/640101/
14:55:59 <tosky> - more python 3, with a multinode py3 job: https://review.openstack.org/#/c/642799/
14:56:34 <tosky> do you prefer if I submit a new patch, or can I merge http://paste.openstack.org/show/747783/ with https://review.openstack.org/#/c/642799/ ?
14:57:38 <tellesnobrega> tosky, whatever you think it works best
14:57:48 <jeremyfreudberg> same
14:57:55 <jeremyfreudberg> no need for a new patch, feel free to combine things
14:58:37 <tosky> oki, thanks
14:58:58 <tellesnobrega> I will keep an eye and review as soon as you have them up
14:59:48 <tellesnobrega> we are running out of time
14:59:54 <tosky> there are few ready for review, when you wait between job runs :)
14:59:57 <tosky> nothing else from me
15:00:04 <jeremyfreudberg> nor from me
15:00:28 <tellesnobrega> see you all next week
15:00:31 <tosky> o/
15:00:33 <tellesnobrega> thanks all
15:00:45 <tellesnobrega> #endmeeting