14:01:12 #startmeeting glance 14:01:14 Meeting started Thu Nov 17 14:01:12 2016 UTC and is due to finish in 60 minutes. The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:18 The meeting name has been set to 'glance' 14:01:27 #topic roll call 14:01:35 hello jokke_ , alex_bash 14:01:39 \o 14:01:45 morning 14:02:11 let's wait another minute or so 14:02:14 \o 14:03:28 #topic updates 14:03:46 first, no meeting next week (Nov 24) 14:03:54 Thanksgiving holiday in USA 14:04:10 will probably also be low availability of reviewers 14:04:31 oh it's next week 14:04:50 second, Spec freeze is next week, 23:59 UTC 25 November 2016 14:05:09 i'm going to devote tomorrow to reviewing all open specs 14:05:28 will probably ping cores directly for key specs that need review 14:05:48 I'm assuming the freeze does not affet the amendments 14:05:50 or, motivated persons can look themselves 14:05:55 #link https://review.openstack.org/#/q/project:openstack/glance-specs+status:open 14:05:59 jokke_: correct 14:06:51 final update: O-1 update and roadmap changes 14:07:03 #link https://etherpad.openstack.org/p/ocata-glance-prioritization-and-roadmap 14:07:13 key changes 14:07:24 we missed O-1 for Community Images 14:07:31 sorry for that :( 14:07:42 but, thanks to abhishek_k and alex_bash we did get the "community" goal accomplished 14:08:01 big hand guys 14:08:13 thank you : 14:08:43 o/ 14:08:43 we'll talk more about the Community Images situation in a bit 14:09:05 but for now, i'd like to get it merged the week of Nov 28 14:09:34 don't want to stop momentum 14:09:55 ok, that's all the updates 14:10:26 #topic Virtual Design Session wrapup 14:11:00 alex_bash and hemanth|pto held a virtual design session to showcase their zero-downtime database update work 14:11:15 for those who couldn't make it, there's a recording available 14:11:27 there's a link on the session etherpad: 14:11:40 #link https://etherpad.openstack.org/p/ocata-glance-zero-downtime-db-upgrade 14:12:09 this is a key priority for Ocata, so i encourage everyone to take a look 14:12:39 (and now, i will pause 90 sec for comments or questions) 14:14:09 ok, moving on 14:14:28 #topic Community Images: discuss design decision of default visibility = 'shared' 14:14:45 i'll put up the links first, then some talking 14:15:15 #link https://review.openstack.org/#/c/396919/ (spec update) 14:15:27 #link https://review.openstack.org/#/c/369110/ (code) 14:16:04 ok, the short story is that during development, we decided that the default visibility an image should be created in should be 'shared' 14:16:16 apologies for being late 14:16:18 the spec update explains why, so please take a look 14:16:25 sigmavirus: np 14:16:51 jokke_ had some good questions that i think have helped clarify why this is a good idea 14:17:12 so at this point, i think that everyone is currently onboard with default visibility of 'shared' 14:17:15 but 14:17:50 there's an open question about how the migration of legacy images should work 14:18:05 so that's what's holding things up ATM 14:18:18 the change will affect operators, so we've decided to ask them for input 14:18:31 So this is one of those things which just smells bad to me ... (like the fact that currently our shared images are claimed to be visibility private) ... and my biggest fear is that this is one of those decisions we will some day curse looking back "Who ever thought this would be ok" but based on the feedback/pressure for example from Horizon and infra, we really don't have options 14:19:03 that is for the default 14:19:10 right 14:19:39 i don't disagree about the smell, but i think for backward compat we're kind of stuck 14:19:49 at least the new default is a bit more honest 14:19:56 ^ ++ 14:20:00 but specially end user perspective I'm super against transitioning all currently Private images to Shared 14:20:27 understood 14:21:05 i think the letter i sent to the operators list summarizes the situation fairly, both good and bad aspects of the proposal, so anyone not up to speed on the controversy, please check it out 14:21:19 #link http://lists.openstack.org/pipermail/openstack-operators/2016-November/012107.html 14:21:31 (for those not subscribed to the operators' list) 14:21:56 let's see what kind of feedback we get 14:22:12 since no meeting next week, i'll update the ML when i've got some responses 14:22:29 one more issue related to this 14:22:30 thank Brian 14:22:34 np 14:23:18 do I understand correctly, then, that we're not goign to land this for o-1? 14:23:26 sigmavirus: correct 14:23:33 sigmavirus: yes, aiming for week of Nov 28 now 14:23:46 so there's nothing blocking 14.0.0.0b1 then, yes? 14:23:59 sigmavirus: we can't land it without the db migrations, and what ever we merge on the db side we're stuck with 14:24:09 jokke_: how do you mean? 14:24:50 sigmavirus: the db migrations are "immutable" even between milestone releases 14:25:24 jokke_: sure, but we could add another migration atop the previous one to get to the desired end state 14:25:44 we should not break rolling o-1 -> o-2 -> o-3 and same time N -> O needs to look the same 14:25:45 sure that's not optimal but databases are going to migrate, might as well land something for a beta release that people can test 14:26:07 jokke_: N-> Ob1 should look the same as N->O? 14:26:13 Since when? Where is this documented? 14:26:38 (we have a light agenda, so let's continue this now, it's worth figuring out) 14:26:39 sigmavirus: so when you do visibility = "shared" when visibility = "private" ... how do you fix that on the next migration? 14:27:15 sigmavirus: N -> O-[1..3] -> O should look db wise the same as N -> O 14:27:18 jokke_: i think the idea is that you shouldn't run a beta in production? 14:27:22 for what it's worth, if we move to Alembic migrations in Ocata, then the N->Ob1 and N->O will look different anyway 14:28:04 alex_bash: see above ... anything breaking that, I will happily block ;) 14:28:31 it would be good to get some guidance from the release mgmt team about this to guide future development plans 14:28:43 i.e., sigmavirus 's request for where this is written down 14:28:52 anyone want to take that action item? 14:28:53 rosmaita: in theory we claim that we're on CI/CD and one could cut release almost at any point of the repos and get working cloud :P 14:29:04 Okay, so I agree that without an idea of where we'll land with private images after the migration to default to shared would be tricky to migrate back 14:29:24 jokke_: who is "we"? I've never heard glance claim that as reality but as a goal 14:29:34 sigmavirus: as 14:29:43 sigmavirus: we as OpenStack 14:29:57 jokke_: further, the migrations run to upgrade to O will be all the migrations added in O-1, O-2, and O-3 14:30:08 that's why we have all this gating to ensure that any patch does not break the functionality 14:30:17 So if migrating to each individual milestone and then to O final provides different results, I'd be really surprised 14:30:34 jokke_: sure, but when adding new functionality, it's highly unlikely it'll just work perfectly out of the box 14:30:45 brb 14:31:07 sigmavirus: Exactly ... cause they are "immutable" or "sacred" how ever you want to put that .... so we can't just go and change the migration script that landed O-1 in O-2 14:31:22 No, because they're deterministic 14:31:38 jokke_: No one in this discussion is advocating for modifying an existing migration script 14:31:51 You're tilting at windmills 14:31:56 i thought the migration scripts weren't "immutable" until actual release? 14:32:32 sigmavirus: well that was what I said why we are not landing the community images by O-1 and you disagreed that we could change it in O-2 14:32:56 at this point we're starting to go in circles 14:33:08 rosmaita: that's a good point. I don't know which is the right answer 14:33:12 anyone want to take the action item to find a definitive statement about this? 14:33:26 maybe an email to the release team? 14:33:36 rosmaita: as liaison, I'll start writing that right now 14:33:41 sigmavirus: ty 14:34:08 #action sigmavirus to contact release mgmt team about what db changes are allowable for milestone releases 14:34:18 I guess we're just not going to come to a decision for this until after our deadline for O-1 has passed 14:34:21 or between milestone releases 14:34:28 or whatever was discussed above 14:34:37 yeah, the ship has sailed for O-1 14:34:46 sigmavirus: oh, we are ... I still have the -2 on the change itself 14:34:47 but this is a good issue to have clarity on 14:35:00 ok, back to community images ... 14:35:06 sigmavirus: so feel free prep O-1, the work will not be ready to merge on time 14:35:14 the final point has to do with the naming of the 'shared' identified 14:35:24 whether it should be 'shared' or 'shareable' 14:35:40 which used to seem important, but i'm pretty much sold on 'shared' now 14:35:51 if we really want to make it shreable, then we need shared as well 14:36:13 but, i sent a message to the i18n team asking whether either one is a big deal conceptually trnaslation wise 14:36:31 #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/107437.html 14:36:38 'cause neither of them is accurate on the model we are planning for them 14:36:42 jokke_: i'm dead set against that 14:36:50 and actually, 'shared' is accurate 14:37:00 a 'shared' image is always accessible to all image members 14:37:17 sometimes the member list is empty 14:37:23 but the statement is still true 14:37:34 rosmaita: I'm against having 2 as well, I'm just saying shareable is perhaps even worse than shared 14:37:38 that's why I'm +1 on 'shared' 14:37:50 jokke_: ok, i'm with you on that one 14:38:23 and, i've only asked for advice, we still will go with what makes sense using our best engineering knowledge in light of the available evidence 14:38:32 shareable is as bad opiions as our current usage of "private" 14:39:14 ok, any questions 14:39:25 (only waiting 20 sec this time) 14:39:27 just want to bring up that hemanth|pto has another suggestion to get us out of the impasse 14:39:38 since the topic has been established as dead 14:39:42 I don't see a point to talking about it 14:40:04 remove 'shared' visibility from community images change completely 14:40:36 i'm pretty much 100% against that 14:40:53 we'll face the same issue again for hierarchical sharing 14:41:07 that alex_bash is valid point if we were at the stage of fighting it in week before release deadline 14:41:27 i think we're close to a realistic settlement here, so let's continue on course 14:41:47 now we actually have time to figure this out without rushing the work in that is the key point of the change 14:41:52 rosmaita: ++ 14:42:13 ok, moving on 14:42:25 #topic Release O-1 (14.0.0.0b1) 14:42:39 ok, to answer sigmavirus 's question from earlier 14:43:11 i'd like to see https://review.openstack.org/#/c/368192/ in O-1, but as the lite-spec isn't approved, i think we've missed the boat on that 14:43:31 i believe O-1 has to be tagged today, in like a few hours or so? 14:43:41 yes 14:44:17 rosmaita: Is there anything blocking us merging those two like now and tagging after they merge? 14:44:30 jokke_: nope 14:44:45 jokke_: maybe reviews 14:44:51 what sigmavirus said 14:45:00 i don't want to rush stuff through 14:45:25 but it would be good to get the lite-spec merged ASAP 14:45:36 it has one +2 now 14:45:53 and 2 +1s 14:46:35 I think there is logic error in that spec 'though 14:46:41 but I need to double check 14:46:50 ok, then def don't want to rush this 14:47:08 IIRC our locations code replace is delete+add (like what happens in the code) 14:47:43 which would cause the first rule permitting the second on 'queued' state 14:48:05 ok, let's discuss this on the lite-spec 14:48:18 sounds good, I need to double check the code as well 14:48:24 image locations are bad enough without us making them worse! 14:48:32 ++ 14:49:12 so key accomplishment for O-1 (repeating for sigmavirus who wasn't here earlier) is 14:49:27 "community goal" accomplished thanks to abhishek_k and alex_bash 14:49:38 heh yeah, that's for the client 14:50:01 good point, so we hit a project goal, but not something in the glance code 14:50:18 it's work, anyway 14:50:26 ok, moving along 14:50:31 #topic open discussion 14:52:32 https://review.openstack.org/397793 is our review for O-1 release 14:53:20 I just want to thanks rosmaita for taking the time yesterday and bending the railroad for me about what's going on around that visibility 14:53:35 s/thanks/thank/ 14:53:47 np, i think the discussion brought some clarity 14:54:08 it was easier to explain the motivation/issues to operators after working all that out 14:55:03 "We know that we screw this up for you and we did that intentinally as we figured out a way which could have been way worse" :P 14:56:33 looks like we're done. Thanks all! :) 14:56:52 ok, bye everyone! no meeting next week, but keep an eye on the ML 14:57:04 #endmeeting