14:01:23 <nikhil_k> #startmeeting glance
14:01:23 <openstack> Meeting started Thu Aug 13 14:01:23 2015 UTC and is due to finish in 60 minutes.  The chair is nikhil_k. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:27 <openstack> The meeting name has been set to 'glance'
14:01:30 <nikhil_k> #topic agenda and roll call
14:01:36 <nikhil_k> o/
14:01:38 <bunting> o/
14:01:39 <dshakhray> o/
14:01:39 <flaper87> o/
14:01:44 <rosmaita> o/
14:02:13 <bpoulos> o/
14:02:25 <nikhil_k> As we are in the liberty-3 and trying to wrap things up with features and stability of Glance, guess we should give some time for that discussion. And we have a small agenda today
14:02:29 <nikhil_k> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:03:14 <nikhil_k> ativelkov: dshakhray : any one available for quick update on artifacts meeting notes? if anything important to be brought up now?
14:04:08 <bunting> I think there wasnt many people at it, so there wasnt much of a meeting
14:04:29 <ativelkov> nikhil_k: here, sorry for delay
14:04:49 <ativelkov> The meeting on monday didn't get much attendance
14:05:07 <ativelkov> General update: we have a bunch of bugs related to artifacts list filtering
14:05:27 <nikhil_k> Ah I see, can find 3 people on the list here: #link http://eavesdrop.openstack.org/meetings/glance_artifacts/2015/glance_artifacts.2015-08-10-14.03.html
14:05:50 * flaper87 wonders if meetbot can parse in-line tags
14:06:03 <ativelkov> nikhil_k: thanks for the link
14:06:18 <ativelkov> So, that minutes contain a list of open bugs I was talking about
14:07:07 <ativelkov> I am working on these bugs, some are already fixed and are waiting for more functional tests to be written
14:07:27 <ativelkov> mfedosin will be back from his PTO next week, will join us as well
14:07:41 <nikhil_k> ativelkov: I think we need triage on at least one of them. you got reviewers working with you on them?
14:07:59 <nikhil_k> cool, guess that answers it
14:08:24 <ativelkov> Yeah, I expect dshakhray to help me with that as well
14:08:34 <jokke_> o/ sry for being late
14:08:44 <nikhil_k> nice
14:09:16 <ativelkov> That's all from artifacts side
14:09:27 <nikhil_k> So, I had to be offline/afk on Tuesday as well but guessing we skipped the drivers meeting as I see no logs
14:09:38 <flaper87> nikhil_k: yeah
14:09:49 <nikhil_k> rosmaita: please correct me if I am wrong. I missed your ping and didn't get to it until late yday
14:09:52 <nikhil_k> thanks flaper87
14:10:06 <rosmaita> nikhil_k: you are correct
14:10:15 <nikhil_k> Thanks
14:10:26 <nikhil_k> Moving on.
14:10:33 <flaper87> I guess we could do a quick sync after the meeting or just wait till next week's
14:10:41 <nikhil_k> #topic changes still being accepted for V1?
14:10:55 <nikhil_k> flaper87: sure, after this meeting sg
14:11:15 <nikhil_k> bunting: guess, that's you?
14:11:23 <nikhil_k> #link https://review.openstack.org/#/c/211636/
14:11:34 <nikhil_k> #link https://review.openstack.org/#/c/203948
14:11:37 <bunting> Yeah, the patch i put up there has diffrent opinions on what should be allowed to change v1
14:11:46 <hemanthm> I've seen some of us giving -1 for v1 changes and others not
14:11:49 <flaper87> I was looking at those patches and I'm leaning towards generalizing the answer to that question as: We accept fixes for bugs with severity >=high
14:11:57 <flaper87> or prob medium?
14:12:09 <sigmavirus24> flaper87: I'd say >= high
14:12:17 <rosmaita> sigmavirus24: +1
14:12:19 <sigmavirus24> here's the thing, changing 200 to 403 doesn't seem acceptable
14:12:19 <flaper87> And I'm not saying just CVEs because I believe we can't do that until Nova moves to v2
14:12:23 <flaper87> sigmavirus24: +1
14:12:27 <sigmavirus24> fixing a 500 is fine
14:12:45 <sigmavirus24> Fixing a 500 probably shouldn't break other services
14:12:57 <sigmavirus24> Changing 200 to 403 seems more likely to have that affect
14:13:11 <nikhil_k> I think there is a bigger problem here
14:13:27 <jokke_> that's my view to it as well ... leaving known condition leading to 500 is not really acceptable as long as Nova is still relying on it, but that 200 ->403 is something we have blocked similars before
14:13:36 <nikhil_k> Nova stores the image ref in the immutable sys meta and if id changes then base ref for the snapshot can become useless
14:13:36 <mclaren> I think there's kind of two factors: impact of the bug and the risk/scope of the fix
14:14:08 <jokke_> mclaren: ++
14:14:16 <nikhil_k> So, it might be a catch22 if Nova needs this but other clients are affected in a way that 403 becomes unacceptable
14:14:25 <flaper87> While I agree with mclaren, I'd like us to not answer this with: "We'll evaluate on each bug"
14:14:37 <flaper87> because that creates confusion and we'll get back to this discussion later
14:15:12 <flaper87> if the bug has a reasonable impact, then lets set the severity to high and fix it regardless the impact of the fix
14:15:12 <nikhil_k> Agree that this becomes subjective to each bug.
14:15:14 <jokke_> should we make modified list based on the stable branch rules of acceptable changes to Images v1 API?
14:15:24 <flaper87> note that we're talking about master v1 here, not stable branches
14:15:39 <sigmavirus24> jokke_: yeah a good policy seems like something we need for v1
14:15:54 <sigmavirus24> especially since v1 is no longer current, but "supported"
14:16:00 <jokke_> flaper87: yes, that's why I said modified, but we seem to agree pretty close to stable ruleset on the v1 api already
14:16:15 <flaper87> jokke_: yeah, my message was supposed to arrive before yours
14:16:16 <flaper87> damnyou
14:16:37 <mclaren> yeah, something akin to 'stable' seams reasonable
14:16:42 <jokke_> no backwards incompatibilities, no big risky changes, no new functionalities
14:16:52 <flaper87> and properly triaged bugs
14:16:57 <flaper87> with severity >= high
14:17:21 <jokke_> I'm not sure if severity high is really reasonable
14:17:40 <jokke_> it is after all unfortunately still in Liberty our main production api
14:18:07 <nikhil_k> All this is subject to discussion per bug. Severity can be incresed or decreased as per requirement and they can be flexible per deployer.
14:18:38 <flaper87> nikhil_k: agreed but I'd like us to have a policy. Even stable backports are subject per patch/bug but we still have some guidelines
14:18:42 <nikhil_k> But agree that having a set of guidelines can be helpful
14:18:50 <flaper87> damn it, I should've waited
14:18:51 <flaper87> :P
14:19:17 <nikhil_k> I guess we can take this review as a starting point for drafting one
14:19:26 <sigmavirus24> yes please
14:19:30 <jokke_> nikhil_k: that's kind of why I'd like to leave that severity req away from there. I don't want us triaging the bug severity just based on that some bug happens to affect us and we want the fix in. If it can be flexible, lets just leave it away from requirements
14:20:27 <flaper87> but I think severity could be an important factor
14:20:44 <nikhil_k> #link https://etherpad.openstack.org/p/liberty-glance-v1-changes-policy
14:20:50 <flaper87> accepting a bug fix for a bug marked as low, as much as we don't want, could end up introducing a new bug
14:21:14 <flaper87> if we leave out wishlist/low/etc we reduce the chances to break v1 by fixing it
14:21:30 <flaper87> medium might be reasonable if we want it to be more flexible
14:21:46 <jokke_> flaper87: I'd like to see us finding the cycles to fix them mediums from the list first before we start worrying the low ones ;P
14:22:14 <flaper87> jokke_: we are not the only ones coding on Glance ;)
14:22:28 <flaper87> other contributors could pick bugs and work on them
14:22:49 <flaper87> if we leave low v1 bugs open, we're basically saying we're good with ppl fixing them
14:23:26 <jokke_> flaper87: I find hard time to prioritise them in my reviews and most probably it's really not low impact if someone has energy to bug me enough to review it :P
14:24:08 <flaper87> jokke_: and I have to disagree... *cough*patches give you free access to the summit*cough*
14:24:18 <flaper87> (just to mention one random case)
14:24:24 <flaper87> anyway... moving on
14:25:08 <nikhil_k> Okay, please add your coughs, oops I mean thoughts on the etherpad
14:25:24 <flaper87> rofl
14:25:32 <nikhil_k> :)
14:25:33 <nikhil_k> #topic Reviews, Bugs and Releases
14:25:43 <flaper87> may I go first?
14:25:48 <flaper87> I'll have to drop in a bit
14:25:51 <flaper87> erm, leave
14:25:54 <flaper87> you got it
14:26:06 <nikhil_k> go ahead
14:26:10 <flaper87> thank you
14:26:44 <jokke_> flaper87: I think that's a good point, we perhaps should start clening the bugs out as well
14:26:57 <flaper87> I just wanted to +1 what you said at the beginning of the meeting. lets focus on stabilizing and helping needed features to be completed. I'd like to bring to your attention the automatic task triggering spec: https://review.openstack.org/#/c/188388/
14:27:03 <flaper87> rosmaita: dropped some interesting comments
14:27:16 <rosmaita> ty
14:27:25 <flaper87> the reason I'm bringing it up again is because most the +1's on that spec, AFAICT, come from OPs
14:27:38 <flaper87> it's a needed feature and I believe we still have time
14:27:48 <flaper87> however, I'd love to hear your feedback on the impact and likelihood
14:28:06 <flaper87> that's it from me
14:28:09 <flaper87> and thanks :)
14:28:14 <jokke_> I think I need "Explain it to me like I'm five" run on that ... I have just really gard time to get grasp it
14:28:18 <nikhil_k> oh yeah, I never added thoughts from irc to the review. thanks for the reminder. I think there has been some dilemma in terms of how this can impact the behavior of Glance.
14:28:20 <jokke_> "of it"
14:28:54 <flaper87> nikhil_k: yeah, I'm happy to talk more about it if that helps
14:28:56 <nikhil_k> The main worry was we can establish the immutability clause but guess that is stil an open question on the feature
14:29:15 <flaper87> I don't think it'll change the way Glance operates but I might be missing something
14:29:23 <nikhil_k> Otherwise, I think we may need something like this for singleton API effort
14:29:48 <rosmaita> flaper87: i'm not clear on what the workflow is for using the trigger tasks
14:29:52 <flaper87> I'll reply to rosmaita comments later today but before submitting a new version, I'd like to collect other folks' comments too
14:29:59 <rosmaita> oops
14:30:03 <flaper87> :D
14:30:09 <nikhil_k> :)
14:30:16 <flaper87> I don't want to take the meeting time but I'll explain all that soon
14:30:24 <flaper87> at least what I've in mind, which could be completely wrong
14:30:26 <flaper87> :P
14:30:30 <jokke_> :D
14:30:45 <rosmaita> can someone give me an objective assessment of the current state of tasks?
14:30:50 <rosmaita> i am asking because
14:30:58 <rosmaita> at the time of the DefCore stuff for Kilo
14:31:29 <rosmaita> i was getting pushback from various non-glance people that tasks were not legitimate because they were "broken"
14:31:33 <rosmaita> in unspecified ways
14:31:51 <flaper87> rosmaita: I think there was a HUGE misconception of what tasks are
14:31:54 <flaper87> and how they work
14:31:54 <rosmaita> my concern is that the current tasks need to be solid before we extend the paradigm
14:31:59 <flaper87> and why we have them
14:32:02 <flaper87> and what Glance v2 is
14:32:06 <flaper87> and Glance
14:32:09 <flaper87> :P
14:32:12 <rosmaita> no kidding!
14:32:14 <mclaren> lol
14:32:17 <flaper87> I'm not kidding
14:32:22 <rosmaita> i agreee
14:32:23 <flaper87> but it's still fun
14:32:24 <flaper87> :D
14:32:27 <flaper87> or sad
14:32:56 <nikhil_k> I have been given the same response in a very specifically unspecific way - meaning the perspective is that Images API is immature. So, the decision on this spec is literally going to define the fate of tasks, glance and defcore
14:33:22 <rosmaita> ok, i will file a bug that "tasks docs are missing" and get a patch up so we can clarify things
14:33:31 <flaper87> rosmaita: +1
14:33:34 <flaper87> that sounds amazing
14:33:35 <nikhil_k> the above line defcore == defcore take on "images" api
14:34:06 <jokke_> Well second hand info, but I'm bit worried that there is no way clearing tasks from the list, failed or finished. That alone leaves quite a flimsy feeling of them as whole even if it was just the one thing
14:34:27 <hemanthm> jokke_: GB21 is working on that
14:34:29 <rosmaita> jokke_: there's work being done on that as we speak!
14:34:49 <flaper87> yeah
14:34:54 <hemanthm> https://review.openstack.org/#/c/209255/
14:35:06 <wokuma> I hate to bring up https://review.openstack.org/#/c/195820 again (like for the 4th time), but, this bug has become critical.
14:35:18 <jokke_> I know and it's great, that's just one of those things that might send bit harsh message out F.E. to defcore
14:35:23 <wokuma> I think it should also be back ported to Kilo.
14:35:39 <nikhil_k> ok, yes I think we need to give some time to wokuma
14:35:50 * flaper87 bows and thanks
14:36:24 <nikhil_k> I guess we can discussion more on this spec before drivers meeting next week to have few more comments.
14:36:34 <nikhil_k> can have*
14:36:41 <jokke_> wokuma: I'd had approved that earlier today if the only other +2 wasn't from mclaren ;)
14:36:42 <mclaren> anyone available to review wokuma's patch?
14:36:50 <wokuma> The bug explains the issue, but, you just need to install it and make sure you can not enter duplicate namespaces, objects, properties, tags and resource-types.
14:36:56 <nikhil_k> wokuma: the issue is prolly that it;s a scary big migration
14:37:08 <wokuma> Yes. Sorry.
14:37:41 <wokuma> It could/should be perhaps even bigger by one more constraint.
14:38:14 <rosmaita> 549 lines of migration code, but +915 lines of tests, so kind of balances out
14:38:53 <wokuma> I believe Eric Brown reported he had installed it and it works for him.
14:39:08 <nikhil_k> what's the remnant constraint?
14:39:14 <nikhil_k> and the upgrade of tags there kinda confused me
14:39:29 <nikhil_k> if we have duplicate tags, it doesn't hurt unless it gives 500s
14:39:34 <wokuma> a unique index on metadef_namespaces.display_name
14:40:25 <mclaren> wokuma: this really mainly just touches the metadef models?
14:40:28 <wokuma> Not sure if duplicate tags throws a 500 or not, will have to test that.
14:40:40 <wokuma> yes. just the metadef_xxx tables.
14:40:50 <mclaren> ie the chance of impacting 'images' is fairly non-existant?
14:41:06 <sigmavirus24> mclaren: right
14:41:19 <nikhil_k> it is for non-shared deployers
14:41:24 <wokuma> mclaren: I'm not touching any other tables than the metadef_xxx tables.
14:41:45 <nikhil_k> non-shared = metadef separate from images
14:41:51 <wokuma> mclaren: so i would say yes, pretty much non-existant.
14:42:11 <mclaren> wokuma: ok, thanks.
14:42:25 <wokuma> mclaren: np
14:43:55 <mclaren> so anyone willing to review? even if it's just a 'I'm happy that this won't break images' kind of way?
14:44:08 <wokuma> nikhil_k: should i add the metadef_namespaces.display_name unique index?
14:44:38 <wokuma> It will wipe out all the +1 and +2's.
14:44:58 <nikhil_k> thanks wokuma . I will try to allocate some time for this today if not sigmavirus24 has +Aed it that I don't mind being re-added EOB today
14:45:05 <jokke_> wokuma: if that's breaking something and needs to be fixed anyways, I'd say lets bite the bullet at once rather than you making another of these monsters for it :P
14:45:32 <wokuma> jokke_: ok
14:45:38 <nikhil_k> wokuma: does the index need to be added in the table properties?
14:46:17 <nikhil_k> btw, I think we need to give some more time for other reviews
14:46:23 <wokuma> nikhil_k: The index could be added after.
14:46:38 <nikhil_k> wokuma: if not as a part of the table args, may be it can be added later
14:46:47 <nikhil_k> it should be fairly small operation
14:47:06 <wokuma> I could add it in a subsequent script.
14:47:26 <nikhil_k> thanks
14:47:30 <nikhil_k> next are:
14:47:35 <wokuma> np
14:47:39 <nikhil_k> #link https://review.openstack.org/#/c/120866/
14:47:48 <nikhil_k> #link https://review.openstack.org/#/c/205632/
14:48:02 <nikhil_k> rosmaita: hemanthm jcook : anyone of you added those?
14:48:05 <hemanthm> those are bufferedreader spec and code
14:48:09 <hemanthm> nikhil_k: I did
14:48:11 <jcook> o/
14:48:13 <nikhil_k> thanks
14:48:32 <hemanthm> we chatted about this at the mid-cycle
14:49:08 <nikhil_k> just needs reivews?
14:49:11 <hemanthm> there was agreement that this looked like a decent way to fix retries
14:49:21 <hemanthm> just wanted to get more input from folks
14:50:32 <jcook> I think the patch looks good, just a minor nit by Erno and few questions myself
14:50:55 <hemanthm> Yeah, I'll fix the config option today.
14:51:37 <nikhil_k> Thanks
14:51:39 <mclaren> we talked about continuing to stream if the local cache is full, but that can be an add on...
14:51:54 <hemanthm> mclaren: yeah, I added that to the spec.
14:52:00 <mclaren> ah, nice
14:52:26 <nikhil_k> Who added the next link to agenda?
14:52:55 <mclaren> I added 1482371, it's not publically viewable yet
14:52:55 <jokke_> thanks hemanthm
14:53:01 <nikhil_k> :)
14:53:25 <hemanthm> jokke_: thanks for the review :)
14:53:34 <nikhil_k> mclaren: and you want to make it so?
14:53:44 <mclaren> Just wondering what the next step is?
14:54:05 <mclaren> Do we wait for some security paperwork, or just push up the fix?
14:55:04 <nikhil_k> mclaren: oops, I missed the proposed .patch. Will take a look and review. I think we need at least +2s before making a public review as a part of the workflow
14:55:07 <jokke_> mclaren: iiuc the paperwork needs to be ready and the patches will be pushed in at the moment of time specified in the paperwork
14:55:37 <sigmavirus24> mclaren: we shouldn't be talking about it in a public meeting then
14:55:58 <sigmavirus24> we shouldn't be referencing the bug number even if its not publicly viewable
14:56:10 <nikhil_k> agree
14:56:15 <mclaren> ok, my bad
14:56:16 <jokke_> as part of the process the patch will be provided to vendors so they can have their versions fixed around the time it becomes public
14:56:16 <nikhil_k> sigmavirus24: I think this needs to be public asap now. we also have a patch ready so should be good
14:56:41 <sigmavirus24> nikhil_k: are y'all coordinating with the VMT?
14:56:54 <sigmavirus24> If so, they'll be setting a public disclosure date
14:57:01 <jokke_> ^^
14:57:16 <nikhil_k> btw, whoever added subscribers to the bug -- please don't unless you get a approval from the openstack vulnerability team
14:57:22 <sigmavirus24> ^^
14:57:33 <sigmavirus24> I think our team needs to seriously review the guidelines the VMT has set forth
14:57:33 <hemanthm> nikhil_k: I added the first few
14:57:37 <sigmavirus24> No discussion in public logged channels
14:57:43 <sigmavirus24> Preferably no discussion on IRC
14:57:52 <sigmavirus24> Patch review on the bug report
14:57:53 <nikhil_k> please that notes in mind for all the private bugs
14:57:56 <nikhil_k> note*
14:57:57 <sigmavirus24> Only add trusted security cores
14:58:03 <nikhil_k> ++
14:58:14 <nikhil_k> sigmavirus24: I will
14:58:24 <nikhil_k> #action nikhil_k to talk to vmt about the bug
14:58:36 <nikhil_k> jokke_: we have a couple mins left :)
14:58:56 <wokuma> one last question, what about back port of https://review.openstack.org/#/c/195820 to Kilo. I feel it needs to be done.
14:59:04 <sigmavirus24> jokke_: ^?
14:59:04 <jokke_> yes so I'd like to get that already public one patched down
14:59:26 <jokke_> we provided the functionality with Liberty-1 & -2
14:59:41 <jokke_> and that vulnerability was already disclosed last weeks meeting
15:00:46 <nikhil_k> ok, lessons learnt from/by all. summary email coming on ml.
15:01:04 <nikhil_k> we are out of time.
15:01:07 <nikhil_k> Thanks all!
15:01:10 <nikhil_k> #endmeeting