14:00:05 <tellesnobrega> #startmeeting sahara
14:00:06 <openstack> Meeting started Thu Apr 12 14:00:05 2018 UTC and is due to finish in 60 minutes.  The chair is tellesnobrega. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:09 <openstack> The meeting name has been set to 'sahara'
14:00:47 <jeremyfreudberg> o/
14:00:58 <shuyingya> o/
14:01:49 <tellesnobrega> tosky?
14:01:50 <tosky> o/
14:01:56 <tellesnobrega> there he is
14:02:09 <tellesnobrega> #topic News/Updates
14:02:34 <tellesnobrega> I'm working on plugins split and also on boot from volume feature
14:02:58 <tellesnobrega> also fixing some bugs (tosky went crazy on bug reporting today)
14:03:20 <tosky> it's just that I implemented something that I should have done before
14:03:52 <tosky> as I had troubles with my testing setup, I compared the list of packages produced by sahara-image-pack and sahara-image-create
14:04:15 <tosky> I'm going to do it for the other backends
14:04:22 <tellesnobrega> cool
14:04:24 <tosky> so as you can imagine I'm testing
14:04:29 <shuyingya> I am not working on upstream task this two week because of fighting for a certification. so no news to update
14:04:52 <jeremyfreudberg> not much to say from me either, just occasional talks with evgeny about ci stuff
14:05:02 <tosky> shuyingya: in the last review that you sent I left a small comment, that's why I didn't +2 it; could you please review it, so that we can move forward with that review?
14:05:43 <tosky> jeremyfreudberg: I may have a bug for you, but I guess that we can speak about it when we change the topic
14:05:47 <shuyingya> oops, sorry tosky. I didn't get the notification. I will update it asap
14:06:37 <tellesnobrega> if no more news lets move on
14:06:45 <tellesnobrega> #topic Sahara CI
14:06:53 <shuyingya> https://bugs.launchpad.net/sahara/+bug/1763241 this bug caused by mis-configuration.
14:06:54 <openstack> Launchpad bug 1763241 in Sahara "Can't login to node on Sahara cluster from queens" [Undecided,Invalid]
14:07:02 <tellesnobrega> jeremyfreudberg, do you have any updates on CI from your talks with Evgeny?
14:07:51 <tellesnobrega> shuyingya, can you ask your colleague to report that on storyboard?
14:08:03 <shuyingya> sure
14:08:08 <tellesnobrega> thanks
14:08:14 <tellesnobrega> we can come back to it a little lates
14:08:16 <tellesnobrega> later
14:08:21 <jeremyfreudberg> tellesnobrega: not any great update though (we mostly were talking about some apparent requirements from nodepool but mostly got ourselves confused)
14:08:36 <shuyingya> I help him solve this problem today. I will talk with him tomorrow to update it
14:08:44 <tellesnobrega> shuyingya, perfect
14:09:18 <tellesnobrega> jeremyfreudberg, I see. from evgeny last email seems like going with current ci scripts (after some tweaks) will be the fastest way to go
14:10:10 <jeremyfreudberg> yes, and i think that's fine
14:10:26 <tellesnobrega> My follow up question on it is, how much faster? does it make sense to spend time on it now and later spend time to upgrade to zuulv3? or makes sense to spend a little more time and have zuulv3?
14:10:53 <jeremyfreudberg> that's a fair question
14:11:32 <jeremyfreudberg> i'm not sure which of the zuulv3 features would really be needed
14:11:54 <jeremyfreudberg> or strongly wanted
14:12:23 <tellesnobrega> that's another fair question
14:12:26 <tellesnobrega> I have no idea
14:12:32 <jeremyfreudberg> tosky?
14:13:06 <jeremyfreudberg> oh, actually i thought of one (little) thing myself
14:13:11 <tosky> regarding the deployment time, I've seen the notice of the first non-openstack (public) deployment of zuul few weeks ago on infra channel
14:13:43 <tosky> so I understand that it may be complicated
14:13:54 <jeremyfreudberg> or rather i reminded myself of it, the new kind of depends-on message
14:14:54 <tosky> that said, sharing job definitions could be useful
14:15:27 <jeremyfreudberg> i agree, that would be very nice
14:15:42 <tellesnobrega> true
14:15:48 <tosky> if the job definitions from the current scripts (jjb) don't need many changes, then it's not a problem; if they need tuning, uh
14:16:08 <tosky> but I never deployed any of the zuul versions
14:16:53 <tosky> in fact, there are few scripts that I wanted to kill that are/were used only for the old jenkins jobs and then legacy zuul v3 jobs
14:17:04 <tosky> but they can stay for now
14:17:42 <tosky> it also depend on the platform: software factory has zuul v3 support, I don't know if they updated it to the official version (they started adding it as pre-release)
14:17:52 <tosky> it probably depends also on the chosen base platform
14:20:29 <tosky> that said... open to do anything, just I know that we will want to switch to zuul v3 in less than 1 year
14:20:49 <tellesnobrega> I think that we are always wondering and never making a decision on this :)
14:21:06 <jeremyfreudberg> all that sounds good, but is also would really feel good to just have something working soon (instead of nothing)
14:21:20 <tellesnobrega> ok, I will say
14:21:28 <tosky> that's why I'm open to do anything
14:21:32 <tellesnobrega> let try to make a decision
14:21:40 <tellesnobrega> quick deploy now with current scripts
14:22:47 <tellesnobrega> and try to move to zuulv3 in the next couple of months
14:22:58 <tellesnobrega> all in favor say "I"
14:23:52 <tosky> I'm fine, but I abstain
14:24:00 <jeremyfreudberg> aye
14:24:15 <tellesnobrega> ok, so lets go with this plan
14:24:34 <tellesnobrega> so we don't waste too much time wondering and postponing the deplo
14:24:36 <tellesnobrega> deploy
14:27:04 <tellesnobrega> lets move on
14:28:02 <jeremyfreudberg> yup
14:28:08 <tellesnobrega> #topic Rocky 1
14:28:19 <tellesnobrega> just a reminder that rocky 1 is coming up
14:28:36 <tellesnobrega> next week
14:28:40 <tellesnobrega> April 19th
14:29:50 <tellesnobrega> if you have specs that need to be worked on, lets try to get them in before thursday
14:30:00 <tellesnobrega> not a blocker but it would be nice to have them all there
14:30:06 <tellesnobrega> or at least a first patch
14:30:34 <jeremyfreudberg> i'll try
14:30:36 <tellesnobrega> and that is it
14:30:41 <tosky> all the specs for rocky?
14:31:02 <tellesnobrega> not all, but as many as possible
14:31:05 <tellesnobrega> the big ones
14:31:46 <tellesnobrega> I'll try to get the plugins split one done
14:33:04 <tellesnobrega> let's all take a look later on the rocky etherpad so we don't lose track of what we planned
14:33:37 <tellesnobrega> #topic Open Discussion
14:34:54 <tellesnobrega> any topics to discuss here?
14:34:54 <tosky> RDO people, while trying to update the requirements for rocky, found a change in oslo.config which breaks the compatibility code for keystone_authtoken
14:35:03 <jeremyfreudberg> tosky: about the "my" bug, do we have to actually fix it for [keystone_authtoken], or can we exempt ourselves from the rules of assert:follows-standard-deprecation
14:35:11 <tosky> the issue is described here: https://storyboard.openstack.org/#!/story/2001835 and I took the liberty to assign jeremyfreudberg to it
14:36:03 <tosky> jeremyfreudberg: I don't know; this is about installers too, we shipped the new thing in queens, but neither pupper-sahara or openstack-ansible_os_sahara deployed the new section
14:36:11 <tosky> so a lot of users still have the old configuration
14:36:19 <tosky> only devstack users saw the change
14:36:47 <jeremyfreudberg> right, but is oslo config 6 in queens requirements
14:36:50 <tosky> that's why I'd prefer to have another cycle where the new configuration is finally fixed
14:37:01 <tosky> no, it's not
14:37:56 <tosky> but people who deployed queens only saw the warning for the first time; they should not have seen it (but we didn't fix the puppet and ansible modules)
14:38:34 <jeremyfreudberg> i see what you mean
14:38:56 <jeremyfreudberg> uh, it will most likely be easy enough to write even more hacky code which can handle any oslo.config version
14:39:32 <tosky> now I'm not sure how it works with the end of syncing, but maybe we can just raise oslo.config in lower-requirements.txt
14:39:38 <tosky> and support only one codepath
14:40:10 <jeremyfreudberg> i'm not sure how doing funny stuff like that with requirements translates to packagers
14:40:25 <tosky> packagers checks the changed requirements and bump them
14:40:41 <tosky> if random breakages happens, they would for sure look at the changed requirements
14:40:52 <tosky> and at least for RDO, tellesnobrega and me are packagers too
14:40:54 <tosky> :D
14:41:24 <jeremyfreudberg> yeah, and the debian guy is pretty responsive/responsible too
14:41:48 <jeremyfreudberg> ok, yeah, let's try it like that, by bumping our own requirements
14:42:03 <tellesnobrega> I didn't see the bug yet, so I don't have an opinion now
14:42:07 <tosky> so do you have some time to spend on this fix?
14:42:15 <tosky> (question for jeremyfreudberg)
14:43:12 <jeremyfreudberg> yeah, seems like it should be "trivial enough" (famous last words)
14:43:31 <jeremyfreudberg> certainly it will help me get back some lost momentum with writing patches
14:43:49 <tellesnobrega> jeremyfreudberg, let me know if you need help
14:44:32 <jeremyfreudberg> will do
14:44:42 <tosky> thanks!
14:44:53 <tellesnobrega> anything else for today? shuyingya? tosky? jeremyfreudberg?
14:45:00 <jeremyfreudberg> nothing from me
14:45:02 <tosky> apart from that, we have a bunch of patches with just one +2, so feel free to review and merge them :)
14:45:11 <tellesnobrega> awesome
14:45:37 <shuyingya> nothing from me
14:46:36 <tosky> oh, by the way, I opened the bug against puppet-sahara and openstack-ansible_os_sahara about the trustee section
14:46:54 <tosky> at least the one for puppet-sahara got an assignee, so keep an eye there too for the review
14:46:58 <tosky> and that's it from my side
14:47:10 <tellesnobrega> great, thanks tosky
14:48:22 <jeremyfreudberg> thanks all, gtg
14:48:37 <tellesnobrega> thanks all
14:48:41 <tellesnobrega> lets close
14:49:07 <tosky> o/
14:49:13 <tellesnobrega> #endmeeting