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