14:00:27 #startmeeting sahara 14:00:28 Meeting started Thu Jan 10 14:00:27 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:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:32 The meeting name has been set to 'sahara' 14:00:42 o/ 14:01:16 thanks jeremyfreudberg for joining at the exact right time, I almost lost track of time 14:01:26 hi 14:01:33 hi! 14:01:45 me too, 10 minutes ago I knew about this meeting and I was fixing a commit message and I forgot 14:02:00 hi all 14:02:04 #topic News/Updates 14:03:24 I'm really focused on getting the split plugin patch to merge 14:03:29 a) helping with the bureacratic part of the plugin splitting (done, we have the new repositories); writing the APIv2 support for both tempest tests (almost done, thanks jeremyfreudberg and tellesnobrega for the fixes) and scenario tests (basically working, waiting for multihost results) 14:03:56 also worked on some enhancements on apiv2 14:04:38 i was deep into apiv2 with a patch finally coming out last night; i spent the rest of the time marvelling at tosky's productivity 14:05:03 jeremyfreudberg, he is amazing 14:05:07 come on, I couldn't have done anything without your (both) fixes 14:06:24 moving on 14:06:32 #topic APIv2 14:06:51 we got some really good progress yesterday 14:07:01 we have some merged patches, some under review 14:07:18 what is missing at this point? 14:07:52 Jeremy's patch with the fixes, and your patches with OSC support 14:07:57 policies inconsistencies, osc, the polish of apiv2 and microversioning 14:07:59 I think I may found another smaller issues 14:08:09 on osc? 14:08:10 with job binaries (see my last comment) 14:08:30 the same thing that I touched; waiting for the next results from sahara-v2 tempest tests 14:08:44 microversioning is probably more relevant (pending the answer from the TC) 14:09:07 is the policy fixes something that affects the API, or is it something that we can better recheck next week? 14:09:31 it doesn't affect the API itself 14:10:23 it is just policy checking, I guess we can wait a little more 14:10:25 doesn't affect the api itself, but it is part of making the api ready and great... since it is server side i would give it more priority than anything client-side, for the purposes of m2 14:11:09 that makes sense too 14:11:09 client-side == the OSC patch? 14:12:16 client side is the OSC patch, plus some currently not-yet-written dashboard patches (I think telles's patch covers everything for osc, but i didn't look) 14:13:04 jeremyfreudberg, I think it covers, but as usual, when you get too close you may not see clearly 14:13:14 so please take a look whenever you can 14:14:58 so, just to put it clearly, the server side stuff is my new patch, policy things, and microversion / declaration of stable 14:15:37 i didn't quite understand what the concern yesterday with microversion was, can someone sum it up again? 14:17:01 we have two pending patches, declaration of stable and microversion 14:17:51 the question is: in order to reduce the amount of work, and especially if some final touches are needed for the microversioning patch, 14:18:34 if we land the 'declaration of stable' now before M2, and discuss and merge the microversion patch next week, will this break the API? 14:18:44 or is it allowed? 14:18:57 in any case, if we can merge the microversion support now, so be it 14:20:30 i see, i don't know the official advice (But I know you have gone looking for it), but i wouldn't want to declare stable without the microvresions (i consider it a breaking change to add the microversions later, since some headers will go from failing silently to failing loudly) 14:21:07 jeremyfreudberg, do you think we can make microversion get in today? 14:21:53 i think the microversions patch is mergable toay-- we only didn't merge it in the summer because i wanted more time to fixup apiv2 before naming 2.00-- with last night's patch i guess the fixups are there now 14:22:34 awesome, if that is the case, all concern is pointless since we can make it all happen today 14:22:52 which is the best case scenario 14:23:10 tosky, does it make sense? 14:23:41 that all being said, it does still require some blind confidence to declare it stable and declare 2.00 -- because then there is no going back 14:24:09 jeremyfreudberg: sure 14:24:22 and that's the reason why I'd like to have the tempest tests working :) 14:24:33 scenario tests seems to be fine, but I'm waiting for the multinode results 14:25:01 even if we don't merge the sahara-tests patch 14:25:22 right 14:25:27 but at least so far the API itself seems fine (the endpoints and the results, at least) 14:26:17 my hunch is that we are in good shape, but doubting can be useful at times 14:26:43 for what it's worth, i have much more confidence in the plugin split than apiv2 being 100.0% perfect (i'd guess 99%) 14:27:56 jeremyfreudberg, I would say that is pretty high, but we are close :) 14:28:47 ok, any more admisitrative comments on apiv2? if not, we should take a second to discuss the policy names 14:29:07 jeremyfreudberg: can you please rebase the "Give the illusion of microversion support" on top of the "Some polish for APIv2" patch, so that I can test both? 14:29:48 yes, i can do that 14:30:44 thanks, I don't have other questions for now 14:31:02 jeremyfreudberg, anything else on apiv2? 14:31:18 tellesnobrega: just the policy names 14:31:36 go ahead 14:34:06 the idea is that with apiv2 we have made big efforts to entire rename jobs->job_templates and job_executions->jobs, but the policy names are still in the old way: a job-executions policy controls the v2 jobs endpoints 14:34:19 i think we all agree that accurate naming is best 14:34:49 i guess the problem (in my head, anyway) is that we can't create a "jobs" policy for v2 jobs because that policy name is already taken for the v1 thing 14:35:08 yes 14:35:41 I only see one way out of this, is to create a jobs_v2 policy 14:35:55 and once we drop v1 we can change that back 14:36:35 are we sure we can change it back? 14:36:48 well, maybe following the deprecation policies 14:37:01 tosky: yea, policies can be deprecated 14:37:04 do policies support aliases? 14:38:57 it looks like not, but i could be wrong 14:39:13 i'm reading the "naming policies" section here, by the way: https://docs.openstack.org/oslo.policy/latest/user/usage.html#naming-policies 14:39:24 and i guess i found the solution 14:39:32 because the resource name should be _singular_ 14:39:36 as in, not plural 14:40:27 so job? 14:41:33 yeah, at the very least apiv2 jobs would be controlled by "job"... for ultimate consistency we could deprecate all the old stuff and use singular nouns for everytinhg 14:41:54 sounds good 14:43:07 yeah, as long as we do the deprecation properly i think that that is best 14:43:14 maybe it should wait till after m2 though 14:43:21 tosky, any thought? 14:43:29 for deprecating stuff, yes 14:43:45 I can fix the inconsistencies now by adding the job policy for v2 14:43:50 if we can do it without breaking the API, sure 14:43:54 talking about APIv2, did anyone have some time to check that small quirck with /plugins endpoint that I pointed out last time? 14:44:07 or was it just a non-issue? 14:44:16 i don't recall what it was 14:44:47 and we start deprecating the rest after m2? makes sense? 14:44:56 tosky, I don't recall either, sorry 14:46:48 uh, maybe we discussed it outside the meeting 14:47:40 ok, so I guess we need a) deploy with unversioned endpoint b) fix quirks by Jeremy c) microversioning support d) stable 14:47:43 as basic requirements 14:48:56 yes 14:49:07 and I'm fixing the policy patches as well 14:49:30 tosky, if you end up remembering the /plugins quirk, let us know 14:49:36 scenario tests with APIv2 passed, in the meantime; both single (fake) and simple multinode (spark) 14:50:00 tellesnobrega, i'm in the process of commenting on the policy patch 14:50:01 I'm waiting for a rebase of the microversion patch to test it too 14:50:11 jeremyfreudberg, awesome 14:50:19 tosky: i'm mid-rebase now 14:50:30 should we merge first the APIv2 patches before the plugin split? 14:50:30 awesome tosky 14:50:56 yes, I can rebase it after the apiv2 merges 14:51:04 probably yes, better APIv2, then split (which is "just" one patch right now) 14:51:30 yes 14:51:37 the big work with split will be next week, with the cascade breakages in the deployment systems (puppet, ansible, tripleo) and packaging 14:52:30 tosky, count me in for that 14:52:45 not sure how much help I will be, but I can try 14:52:56 playing with tripleo has been on my list forever 14:52:59 let's discuss it next week :) 14:53:36 yeah 14:53:41 7 minutes left 14:53:55 split-plugins seems pretty straight forward now 14:54:03 I'm disabling grenade job for it to pass 14:54:16 not a huge deal, we can fix it later 14:54:24 yes, and better recheck it after APIv2 as just said 14:54:32 of course 14:54:32 so we know that everything is more or less fine 14:54:58 btw, split plugins patch passed tempest 14:55:45 yep, noticed 14:55:54 we need to refine the jobs, but *after* 14:56:05 yeah 14:56:41 I guess we have a good definition of what we need to get it done today 14:56:53 lets keep the focus and make it happen 14:57:56 thanks jeremyfreudberg and tosky 14:58:18 I know it has been a crazy cycle, but it most certainly will be a great one for Sahara 14:58:46 crossing fingers 14:59:14 thanks again, you both have been great :D 14:59:42 #endmeeting