14:00:06 #startmeeting glance 14:00:07 Meeting started Thu Sep 15 14:00:06 2016 UTC and is due to finish in 60 minutes. The chair is nikhil. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:08 #topic roll call 14:00:10 The meeting name has been set to 'glance' 14:00:25 \o 14:00:34 \o 14:00:50 o/ 14:01:19 o/ 14:01:27 let's get started 14:01:31 #topic agenda 14:01:39 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:01:43 o/ 14:01:46 short agenda again 14:01:54 but we may have some additional discussions 14:02:16 there's one more slot / topic that can be added to the agenda 14:02:20 FCFS 14:02:48 #topic Newton RC-1 Updates (nikhil) 14:03:09 A couple of lingering reviews are pending 14:03:26 * rosmaita had to look up First Come First Served ... thought it was Future Cloud For Something 14:03:28 #link https://review.openstack.org/#/q/status:open+project:openstack/glance+branch:master+topic:newton-rc-potential 14:03:38 :) 14:04:05 #info here's everything planned to go in for rc1 https://review.openstack.org/#/q/project:openstack/glance+topic:newton-rc-potential 14:04:48 #info I've removed this https://review.openstack.org/366995 from rc1 potential as it was getting complicated for RCs 14:04:58 (added to the agenda) 14:05:05 (and we can discuss it in a bit) 14:05:56 someone had brought up a store bug pending since early aug for last min release: 14:05:57 https://bugs.launchpad.net/glance-store/+bug/1620999 14:05:58 Launchpad bug 1620999 in glance_store "swift driver ignores user_domain_name and project_domain_name settings" [High,Triaged] 14:06:21 But we have frozen quite early and the workaround seems the right thing to do atm 14:06:50 more comments on the review and bug -- for why not have it in newton and the right way to progress 14:07:24 Thanks to all those who participated in the Sept Bug Days: 14:07:27 #link https://etherpad.openstack.org/p/newton-glance-sept-bug-days 14:07:59 We did not find any critical bugs to target for newton RCs nonetheless, great work on cleaning up the queue! 14:08:55 About tagging RC1 : I'm planning to propose the release as soon as the Bump followed by release notes review merges. 14:09:58 #action glance-cores: please review asap towards workflow for https://review.openstack.org/350809 and https://review.openstack.org/366973 14:10:04 nikhil: you have release notes patch as WIP ... is it too early for reviews? 14:10:14 sorry, was about to say.. 14:10:33 the release notes patch is still WIP but I've made the updates for older release notes 14:10:49 I would love some opinion on what formatting/rearrangement works best 14:11:00 ok 14:11:07 that way while I work on writing the new release notes, I can edit the old ones in parallel 14:11:36 that's it from my end. 14:11:41 more comments/questions? 14:11:44 i +A'd 350809 while we were talking ... hope that's ok 14:12:05 rosmaita: woot! thanks much. 14:12:17 welcome to Images 2.4 everyone! 14:12:46 \o/ 14:13:26 #topic Import Refactor Updates (nikhil) 14:13:38 So, I think it's about time to throttle on this work. 14:13:56 I've been caught up last week in rc1, bugs, emails and some personal things. 14:14:21 But next week, I would like to arrange a meeting (say on wednesday -- but doodle coming soon). 14:14:48 Let's see who is available for the next 7 days from then and we can discuss plans to code, reviews, etc. 14:15:05 o/ 14:15:20 \o 14:15:28 I will likely send out a email to ML about defcore + import-work-in-progress situation early next week (once I'm not hands full with administrative responsibilities). 14:16:11 I will keep it short today, there's no real progress on it yet. But good to keep ourselves updated and motivated for the same. 14:16:27 comments/ques? 14:16:36 +1 to motivation 14:16:46 :) 14:17:08 #topic Community Images Updates (tsymanczyk) 14:17:24 * nikhil hands the mic to tsymanczyk 14:17:39 so i've been working on an experimental changeset 14:18:03 it occurred to me over the weekend that since it was SO DIFFICULT to "fix" so many tests even with nikhil's help, that probably something fundamentally had to be wrong 14:18:37 * nikhil smiles on the fundamentally wrong part 14:18:56 * nikhil thinks all the is_public hacks/workarounds in v1 are fundamentally wrong 14:19:09 since the original changeset had been my first real work on glance, i had to make a lot of guesses and assumptions. a lot of those were probably wrong. 14:19:30 and rather than go through and try to unravel that, i thought the shortest path forward was to just start again. 14:19:47 and even though i've only been working on the new one for 3 days, i think the progress has already surpassed the original changeset. 14:19:59 py34 already passes CLEANLY. and it's a much much simpler, much cleaner set of changes. 14:20:04 i'm happy with the progress, finally. 14:20:14 i don't expect this one to take very long. 14:20:28 very cool 14:20:31 and it shouldn't be that bad to port the second "add community / shared statuses" to this new one. 14:20:32 great news 14:20:36 but i've been wrong before. 14:20:39 fingers crossed. 14:20:43 that's all i have. 14:21:01 https://review.openstack.org/#/c/369110/ 14:21:05 is the new oine 14:22:16 * nikhil hopes to find time to review it this week 14:22:47 Thanks tsymanczyk . you just made my day! 14:22:51 :) 14:23:09 any more comments/ques? 14:23:39 #topic Location updates (dharinic) 14:24:07 * nikhil waits for dharinic 14:24:12 here's the link: 14:24:15 * dharinic is here 14:24:17 #link https://review.openstack.org/#/c/366995/ 14:24:30 dharinic: you want to elaborate or want me to? 14:24:58 Will put it in brief. Do add stuff that I miss. 14:25:14 sure, please go ahead 14:25:36 I was working on restricting updates(remove, replace) to custom location of images. 14:26:03 Adding a location to an image had been restricted to images that are "queued" and "active" 14:26:23 So the work was to restrict access to removing and replacing. 14:27:05 While trying to get those changes, realized that we cannot actually restrict replacing of image locations to only "active" images (which was th intended goal) 14:27:59 Reason being backward compatibility. And also cos few functional tests that were testing other functionalities depended on a queued image being replaced 14:28:56 So the solution as of now was to allow "replacing" image locations for both "queued" and "active" images (though allowing replacement of an image location of a queued image makes no sense) 14:29:04 * nikhil not too worried about functional tests 14:29:19 Some of the discussions were what "replacing" could actually mean.. 14:29:35 Yeah.. functional tests can be changed.. 14:29:57 I tend to go both ways on this. 14:30:02 ok, so I want to elaborate a bit on the 'replacing' part 14:30:13 So if "replacing" means that we are replacing an empty location with a non-empty image location, it makes sense to be permitting that on queued images 14:30:22 * nikhil waits 14:30:41 makes sense, it's like allowing upload of image data to a queued image 14:30:42 1. Replacing image locations is not the only way to put a queued image into active. We can do that by adding locations too. So, there another way and probably a more appropriate way to do the same 14:30:56 * dharinic pauses. nikhil: you can elaborate :) 14:31:18 the issue is something we probably should discuss with API_WG because: 14:31:24 2. Does this fall into the category "something that isn't supposed to work but does"? 14:31:29 quick question, this is done via the PATCH command, right? 14:31:34 PATCH used for updates but the PATCH is on the 'image 14:31:39 rosmaita: yes 14:31:44 not on the image-location 14:31:55 so the update is technically on the image (and locations is part of it) 14:32:06 but the details of the update makes it icky 14:32:12 and the image locations is a list, is that right? 14:32:49 https://review.openstack.org/#/c/366995/4/glance/tests/unit/v2/test_images_resource.py 14:33:29 thanks 14:34:05 I think the usage is wrong, but technically it's correct 14:34:21 to elaborate more, update on location for queued image is wrong 14:34:33 but update on a queued image to a location to put it to active is NOT wrong 14:35:12 As hemanthm said, replacing image locations is not the only way to put a queued image into active 14:36:31 * nikhil 's hunch says that we will stick with what exists today 14:36:45 * dharinic agrees. 14:36:55 * hemanthm agrees too 14:37:19 i thought there was a proposal at some point that someone was going to gather the actual use cases for image locations? 14:37:33 because it's really hard to see what makes sense and what doesn't 14:37:43 without understanding what we're trying to accomplish here 14:37:54 +1 14:37:57 * rosmaita hopes he wasn't the guy who was supposed to do this 14:38:11 I agree with you rosmaita 14:38:15 nikhil: any way, if one is patching the image to replace locations explicitly, then the intent it quite clear. We should be more worried if there's way for users to shoot themselves in the foot 14:38:46 hemanthm: indeed 14:39:28 I think the update issue isn't as bad as 'add' to non-active/queued (which is fixed! thanks to mfedosin 's initiative) 14:40:34 rosmaita: what do you think about only fixing the removal of locations? 14:40:44 rosmaita: we can potentailly skip the updates to when we know more 14:40:59 removal use case is pretty straightford and alings with glance design today 14:41:15 isn't removal essentially a no-op? 14:41:17 so when you say "fixing the removal" ? 14:41:27 removal for queued I mean 14:41:47 if image.status not in ('active'): 14:41:50 removal of locations is allowed only for "active" images as of the latest PS 14:41:54 is what we will go with 14:42:06 == dharinic 14:42:25 the confusion was with replacing.. Looks like we shall be permitting "replacing" for "active" and "queued" 14:42:27 because "I think" this affects deactivated 14:42:46 o/ for the last minutes 14:43:01 yeah.. 14:43:15 mike's patch has merged that prohibits the only location being removed from an active image, right? 14:43:34 rosmaita: that only is for 'add' to locations 14:43:43 rosmaita: dharinic 's patch deals with replace and remove 14:45:42 so, let's fix this quickly because if it's a security issue for deactivated we shouldn't stall on the patch 14:45:47 (public security) 14:45:59 moving on for now 14:46:03 #topic open discussion 14:47:19 just to add to the locations discussion, we do not want to let replace locations either (as we have no way to verify that one original location is still there) 14:47:59 Hi im tamil vanan , newbie can i have a question here regarding one of the the glance bug 14:48:34 hi tamilhce, welcome and shoot! 14:48:40 Jokke_: yeah... something for discussion :) 14:48:47 tamilhce: during open discussion just jump in 14:48:51 Regarding : https://bugs.launchpad.net/nova/+bug/1616539 14:48:53 Launchpad bug 1616539 in OpenStack Compute (nova) "architecture not validated in "openstack image create"" [Undecided,In progress] - Assigned to tamil vanan (tamilhce) 14:49:09 ha.. Jokke_ is saying exactly what I was typing, only faster 14:49:27 is it necessary to validated the architecture value while creating image 14:49:45 nikhil: imo we should just discuss deprecating all user location commands due to the security issues ... as soon as we get around one, next pops up 14:50:07 tamilhce: does glance know what the valid architecture values are? 14:50:50 Jokke_: yes, like rosmaita mentioned above there was supposed to be a spec to be proposed on this (for some sort of location use cases and design methodology) 14:51:00 if need we can restrict the user with set of architecture values 14:51:08 Jokke_: may be we can timebox it, if we don't see a spec in next 6 weeks, we will deprecate locations 14:51:29 tamilhce: sure, but how do we know we are using the "right" values? 14:51:38 I don't think the issue can be scoped to architure then 14:51:46 I have just committed a fix https://review.openstack.org/#/c/362861/ 14:52:11 tamilhce: I think the question is : what is the source of truth for identifying those values? 14:53:16 openstack docs list the supported architecture as well as i this values are hardcoded in nova 14:53:24 *lists 14:53:46 true but glance is not limited to nova :) 14:54:29 nikhil: well I think no-one else but nova cares about that property either ;) 14:54:37 tamilhce: the reason there's a doc ref in the schema is that docs can move faster than code 14:54:39 also if we do have openstack official list, we need it in a central repository and not in individual projects 14:54:52 metadefs! 14:54:56 so if there is definite list, we could just add that to schema and get the validation 14:55:40 well today it's architecture, tomorrow it's something else -- ramdisk! 14:56:17 nikhil: yeah, that's called progress or evolution :P 14:56:25 tamilhce: i think what we need is a proposal to use metadefs, which are configurable and discoverable, to govern the values put into particular image properties 14:56:27 no, this is bad design 14:56:45 @rosmaita the definite list is available in nova/arch 14:57:14 tamilhce: you know that it will not change? and how do we get it? 14:57:31 yeap 14:57:38 like nikhil said, the list needs to be in a centralized discoverable location 14:57:58 like config file! :P 14:58:05 ew 14:58:10 it's not a base property 14:58:17 Jokke_: ;) 14:58:19 yeah you guys are correct 14:58:36 out config files will explode in a few cycles 14:58:39 our* 14:58:43 it should be centralized 14:58:48 a feature masquerading as a bug 14:58:51 tamilhce: we're sympathetic to your use case, but i think we need some kind of more robust solution 14:58:53 tamilhce: so before we run out of time, you can assume it as "wont-fix" at Glance end for now 14:58:56 indeed stevelle 14:59:11 I agree with stevelle and rosmaita 14:59:18 we do care 14:59:28 tamilhce: i'm serious about the metadefs approach 14:59:30 but not for a short term fix 14:59:36 but it needs to be thought out more carefully 14:59:43 sure @jokke, if need i can explore more and come up with better solution 14:59:45 well, rosmaita :) 14:59:55 ok, time's up 15:00:02 tamilhce: way to go! we will look forward to your proposal! 15:00:06 tamilhce: specs repo for Ocata is open, we might approve it after Pike ;) 15:00:08 we made progress on different things today 15:00:12 let's keep working further 15:00:15 thanks all for joining! 15:00:21 #endmeeting