14:00:38 <nikhil_k_> #startmeeting glance
14:00:39 <openstack> Meeting started Thu Sep 10 14:00:38 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:00:39 <jokke_> o/
14:00:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:43 <openstack> The meeting name has been set to 'glance'
14:00:44 <mfedosin> o/
14:00:44 <harshs> o/
14:00:45 <bpoulos> o/
14:00:45 <nikhil_k_> #topic agenda
14:00:46 <jecarey> o/
14:00:50 <kairat> o/
14:00:50 <nikhil_k_> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:00:53 <nikhil_k_> Welcome all
14:01:01 <dshakhray> O/
14:01:04 <abhishekk> 0/
14:01:05 <hemanthm_> o/
14:01:06 <mclaren> o/
14:01:19 <flaper87> o/
14:01:33 <rosmaita> o/
14:02:27 <nikhil_k_> Let's get started
14:02:30 <nikhil_k_> #topic Updates
14:02:34 <jcook> o/
14:02:39 <nikhil_k_> #info artifacts updates
14:03:00 <mfedosin> hi! just a couple of things
14:03:03 <sigmavirus24_awa> o/
14:03:21 <mfedosin> as you may know we have successfully ported artifacts in murano client
14:03:21 <bunting> o/
14:03:37 <mfedosin> and everything works fine there
14:03:46 <flaper87> mfedosin: awesome!
14:03:58 <mfedosin> but also we have many commits on review
14:04:08 <mfedosin> https://etherpad.openstack.org/p/fastTrackPatches
14:04:33 <mfedosin> and and their number is increasing
14:05:23 <mfedosin> I haven't reviewed all of them, neither did Alex
14:05:34 <sigmavirus24> mfedosin: sounds like Fast Track isn't so fast eh?
14:05:35 <mfedosin> but we have several critical there
14:05:53 <mfedosin> sigmavirus24, kind of :)
14:05:59 <nikhil_k_> that looks like a good compilation
14:06:03 <nikhil_k_> mfedosin: so, we need to wait on config changes, api changes and other important stuff until after RC is cut (just fyi)
14:06:12 <nikhil_k_> RC period is intensive testing and bug fixing
14:06:24 <mfedosin> I will prepare a list of changes that we need asap
14:06:35 <nikhil_k_> we wouldn't want other stuff blocking and interfering with it
14:06:39 <mfedosin> if it's possible they have to be merged this week
14:06:51 <nikhil_k_> mfedosin: a sub-heading in that etherpad should help with critical fixes
14:06:52 <mfedosin> other commit may wait
14:06:53 <jokke_> mfedosin: bugfixes?
14:07:30 <mfedosin> jokke_, yep, some of them with security issues
14:07:51 <mfedosin> *other commits
14:08:28 <flaper87> mfedosin: pls, don't disclose the security fixes here (just a friendly reminder)
14:08:44 * flaper87 has seen that in the past (not from mfedosin, though)
14:08:46 <flaper87> :D
14:08:47 <mfedosin> it's an experimental api
14:08:52 * flaper87 is paranoid
14:08:58 <mfedosin> no one cares about it :)
14:09:08 <jokke_> mfedosin: feel free to ping me as well if you get some things popping up. I have not focused that closely t oartifacts as we have had our own client crisis ongoing
14:09:19 <mfedosin> that's why we disabled v3 by default
14:09:29 <nikhil_k_> let's not discuss anything about security issues here
14:09:31 <mfedosin> jokke_, cool, thanks!
14:09:45 <mfedosin> nikhil_k_, lol, okay
14:10:07 <nikhil_k_> thank you.
14:10:16 <nikhil_k_> #info drivers updates
14:10:26 <nikhil_k_> So, we had a small meeting this tuesday
14:10:27 <sigmavirus24> flaper87: what do you mean we shouldn't discuss security problems in public logged channels? Isn't that standard operating procedure for this project?
14:10:54 <flaper87> sigmavirus24: I'll open a security bug to track that and we can talk about it in our next meeting
14:10:59 <sigmavirus24> :D
14:11:20 <jokke_> sigmavirus24: I din't care what your "tenant" does but here in OpenStack we prefer not to do that :P
14:11:35 <jokke_> don't even
14:11:40 <mfedosin> even the bug is not declared as private, I think we can discuss it here
14:11:51 <flaper87> mfedosin: ah, :(
14:11:59 <rosmaita> speaking of security issues, i want to nominate hemanthm_ for the glance security team
14:12:14 <flaper87> anyway, lets stay on topic (drivers updates)
14:12:27 <flaper87> I know FFE was granted for the OVF work
14:12:41 <mfedosin> flaper87, https://bugs.launchpad.net/glance/+bug/1489902
14:12:43 <openstack> Launchpad bug 1489902 in Glance "Artifacts: public artifact may be modified by any user" [Undecided,In progress] - Assigned to Alexander Tivelkov (ativelkov)
14:12:51 <nikhil_k_> so, we asked for some action items from the ova-lite tem and they have the updated spec. FFE was granted after that.
14:13:24 <flaper87> nikhil_k_: I've been keeping an eye on the code, I just did a quick review
14:13:28 <flaper87> and I'll keep doing so
14:13:35 <nikhil_k_> So, now the follow up on that should be a update twice a week till 25th on the status of the spec changes
14:13:50 <flaper87> we should keep track of the progress and be ready to take a step back if we're getting too close to RC1 and the patch is not ready
14:13:51 <nikhil_k_> they have agreed to work with flaper87 and sabari
14:13:59 <nikhil_k_> so, thanks flaper87 !
14:14:04 <flaper87> I don't think we'll have to do that but...
14:14:08 <nikhil_k_> flaper87: agreed
14:14:09 <flaper87> np
14:14:18 <nikhil_k_> on both fronts
14:14:50 <nikhil_k_> we also discussed a bit on lite-specs and some process changes for mitaka. the plan is to discuss them after RC period
14:15:11 <flaper87> ++
14:15:14 <mclaren> sounds good
14:15:15 <nikhil_k_> however, I have a few request on the FFE possibly using the lite-specs concept
14:15:32 <nikhil_k_> so, we can discuss the possiblity of the same in the open discussion
14:15:59 <nikhil_k_> moving on to next topic
14:16:17 <nikhil_k_> #topic py-client 1.x.x back-compat like changes
14:16:31 <nikhil_k_> here's the email to openstack-operators list
14:16:35 <nikhil_k_> #link https://etherpad.openstack.org/p/glanceclient-1.x.x-back-compact
14:16:52 <nikhil_k_> there are some replies that have +1 on having back-compat
14:17:07 <nikhil_k_> so, my duckduckgo did not get me a link to the thread
14:17:12 <nikhil_k_> however, the subject is
14:17:24 <nikhil_k_> [Openstack-operators] Adding v1 LIKE support to python-glanceclient releases 1.x.x
14:17:49 <flaper87> #link http://lists.openstack.org/pipermail/openstack-operators/2015-September/008079.html
14:17:57 <nikhil_k_> thanks
14:18:24 <bunting> This is we should aim to be backwards-compatable as possible, because this is exactly what our users want to see
14:18:54 <nikhil_k_> http://lists.openstack.org/pipermail/openstack-operators/2015-September/thread.html#8079
14:19:30 <mclaren> +1
14:19:48 <mfedosin> is it for cli only?
14:19:55 <sigmavirus24> mfedosin: I'd hope so
14:19:56 <nikhil_k_> so, I am inclining towards having those changes. However, the catch there is
14:20:02 <mclaren> (thanks for reaching out nikhil_k_)
14:20:07 <nikhil_k_> shell api is supposed to be stable api
14:20:28 <jokke_> nikhil_k_: you mean CLI?
14:20:39 <nikhil_k_> so what we have in 1.x.x is likely going to stay for say 5 years (if not more). but that's just an estimate
14:20:55 <nikhil_k_> mclaren: np
14:21:30 <flaper87> IMHO, the CLI api should be intuitive enough and it does not need to match 1:1 the server API
14:21:40 <nikhil_k_> yep, I am trying to prefix the word "API" with specifics  to be explicit and more clear. essentially CLI
14:21:53 <flaper87> The difference between adding all this backwards compat changes now rather than later is that once we added them, we can't just take them back
14:22:17 <bunting> Why would we want to ever take them back?
14:22:21 <nikhil_k_> I think the concern is to add them prior to stable cut
14:22:42 <flaper87> bunting: because we're humans and we make mistakes and what we think makes sense now might be a pain to maintain later
14:22:47 <jokke_> ok so we have client API and we have client CLI
14:22:54 <flaper87> Not all "compatible band aids" are good
14:23:09 <nikhil_k_> jokke_: well elaborated
14:23:10 <flaper87> I'm not saying we shouldn't add them at all. I'm just asking to not rush this
14:23:24 <jokke_> as in Abbreviation of Program Interface and CommandLine Interface ;)
14:23:30 <mfedosin> by the way, what do you think about openstack-client?
14:23:40 <mclaren> if we don't add them before we cut stable, their usefulness is somewhat diminished
14:23:44 <flaper87> jokke_: yup, that's always been the case. That's one of the reasons why I like openstackclient, it just takes the CLI out of the *library*
14:24:01 <nikhil_k_> bunting: yes, so that's a good pointer. is there a way you can use py-openstackclient instead ?
14:24:07 <flaper87> and helps people to reason about libraries for what they are
14:24:27 <jokke_> well my point is if we talk about cli lets keep the talk in cli not cli api or shell api etc. it's not api it's cli
14:24:48 <jokke_> at least I get hwell of mixed up no matter how hard I try to follow
14:25:45 <jokke_> So I'd like to remind couple of things here what I keep hearing over and over
14:26:17 <jokke_> we as in community want to have Glance Images API v2 stabilized and consumed and v1 deprecated
14:26:38 <nikhil_k_> bunting: so the response from Clayton O'Neill in the ethedpad suggested that py-os client was a possibility
14:26:41 <nikhil_k_> mclaren: ^
14:26:44 <jokke_> this is not just day dream of glance to get rid of that burden but OpenStack community widely
14:27:06 <mclaren> jokke_: so you don't think backwards compatability is important in this case?
14:27:29 <flaper87> I don't think anyone is advocating for not being compatible
14:27:54 <jokke_> that in mind I don't think we should implement certain inconsistencies to our v2 specially that --is-public is we will be stuck with it
14:27:57 <flaper87> I think the discussion here goes around: 1) 1.0 being a major release 2) Being pragmatic 3) Trying to fix some of our g'old mistakes
14:28:14 <jokke_> if we will be stuck with it even
14:28:57 <jokke_> I think it's way more important to consider long term impact at this point vs. short term inconveniences
14:29:09 <nikhil_k_> so, here's the alternative
14:29:12 <mclaren> So, I spoke with Duncan Thomas (who works for HP and is a long standing cinder core). I asked specifically what Cinder would do in the case of is-public. they would maintain backwards compatability -- like our users are asking for
14:29:26 <nikhil_k_> what if we release 0.19.x based on commit prior to default being v2
14:29:32 <nikhil_k_> and cut stable out of it
14:29:39 <nikhil_k_> fix bugs there
14:30:26 <jokke_> and if we need to maintain all that compatibility layer for years and keep having binary command line options for non binary values just because we decided once in 2015 to help out few script writers who did not read release notes of major release, I do not think that's sustainablwe
14:30:47 <mclaren> jokke_: let's talk offline
14:31:06 <flaper87> nikhil_k_: I don't think that'll take us anywhere in our hope to migrate to v2
14:31:19 <nikhil_k_> flaper87: why so?
14:31:53 <nikhil_k_> I mean, is client version the only blocker and is that the most important blocker?
14:31:56 <flaper87> Because switching the default is also to raise awarness that there's a v2 API that is the currently maintained one
14:32:08 <flaper87> it's not to just release the major
14:32:30 <nikhil_k_> I doubt if it's a good programmatic way of conveying that message
14:32:44 <nikhil_k_> the supportability status is the source of truth
14:32:45 <jokke_> the major version bump was consequence, not the goal
14:32:51 <nikhil_k_> yep
14:32:58 <bunting> I think it comes down to do operators particually care about what version they are runnin or that it just works?
14:33:32 <nikhil_k_> I think both, depending on who your users are
14:34:00 <mclaren> Operators actually want to spend as little time as possible thinking about OpenStack. Ideally it should 'just work'.
14:34:01 <nikhil_k_> if it's just the dashboard your user then no, it can be internal team with good awareness on what's happening with your versioning
14:34:14 <flaper87> I'd keep the things the way they are going, discuss each patch specifically and then do minor client releases if any of those patches land
14:34:24 <nikhil_k_> mclaren: I agree that those are majority ones
14:34:29 <flaper87> mclaren: I agree w/ that, FWIW
14:34:35 <nikhil_k_> but not necessarily all
14:35:01 <mclaren> Ok, so what are folks thoughts on Niall's patch overall?
14:35:07 * mclaren looks for link
14:35:20 <bunting> #link https://review.openstack.org/#/c/219802/
14:36:09 <mclaren> thx
14:36:50 <flaper87> I think we'll have to evaluate each of those additions separatedly
14:36:59 <nikhil_k_> so flaper87 besides the awareness of versioning, do we have any other blockers for cutting 0.19.1,2 stable/ ?
14:37:37 <nikhil_k_> jokke_: mclaren bunting ^
14:38:05 <nikhil_k_> I think we can do is establish that awareness period for stable/mitaka to not have such back compat changes
14:38:10 <jokke_> I was in general pro it until I heard that every single one of those we merge we're stuck with, as it was supposed to be migration path, not granted functionality maintained until non-foreseeable future
14:38:11 <mfedosin> folks, one question about list validation
14:38:35 <flaper87> nikhil_k_: I don't think that will solve this issue/discussion but postpone it until mitaka
14:38:36 <mfedosin> we have disabled it, afair
14:38:42 <nikhil_k_> looks like the tradeoff is small, maintain something for 1 cycle vs maintain back-compat for 10 years
14:38:47 <jokke_> nikhil_k_: I don't think that either
14:39:13 <flaper87> but I might be missing one piece
14:39:17 <flaper87> not sure :D
14:39:25 <mfedosin> so, there is a patch to enable validation for list https://review.openstack.org/#/c/217113/
14:39:26 <nikhil_k_> flaper87: jokke_ : you guys think, we will need to keep back compat in 1.x.x even in that case! ?
14:39:41 <jokke_> nikhil_k_: I don't see how we would get around that
14:39:49 <flaper87> ++
14:40:02 <flaper87> we already released it
14:40:14 <flaper87> I need some extra time to think about this, TBH
14:40:18 <nikhil_k_> why can't we give 1 cycle time to scripter to change scripts, send email to ML
14:40:21 <flaper87> I think I was not around when this was first proposed
14:40:26 <flaper87> (cutting stable from 0.19
14:40:28 <flaper87> )
14:40:28 <nikhil_k_> ok, I need to know more from all the concerned individuals why so
14:40:49 <nikhil_k_> flaper87: it was , just a few mins ago
14:41:09 <nikhil_k_> ok, let's give some time to other topic
14:41:13 <nikhil_k_> topics*
14:41:22 <flaper87> nikhil_k_: please, thanks. I'll put thoughts around this
14:41:23 <nikhil_k_> #topic     FFE https://review.openstack.org/#/c/186769/ ?
14:41:28 <nikhil_k_> cool
14:41:32 <nikhil_k_> mclaren: you ?
14:41:33 <mclaren> that's me!
14:41:37 <nikhil_k_> cool
14:41:51 <mclaren> So, I'm wondering what the chances of landing this is?
14:42:01 <jokke_> nikhil_k_: so has defcore told you that we need to stick and support our stable/liberty for ever or we need to support what ever functionality we are releasing in our client?
14:42:16 <mclaren> If it was just glance_store it might be, but I'd need a global requirements bump on swiftclient to 2.6.0
14:42:29 <mclaren> is it worth proposing the swiftclient change?
14:42:30 <nikhil_k_> jokke_: we need to tell defcore, but we can talk more on that offline
14:43:04 <flaper87> mclaren: I think reqs freeze was a while back
14:43:12 <flaper87> if you need to bump it, it'll be really hard
14:43:21 <mclaren> yeah, kinda guessed as much
14:43:21 <flaper87> probably worth waiting till mitaka in that case
14:44:32 <nikhil_k_> yeah, I can't find a way around this for Liberty
14:44:47 <mclaren> sure. had to ask!
14:45:09 <nikhil_k_> thanks
14:45:15 <nikhil_k_> #topic Reviews, Bugs and Releases
14:45:16 <flaper87> mclaren: sorry :(
14:45:25 <nikhil_k_> we already discussed client release
14:45:35 <nikhil_k_> #info glance-store 0.9.1 released
14:45:44 <nikhil_k_> who proposed that?
14:45:58 <flaper87> nikhil_k_: Matt, I believe.
14:46:02 <flaper87> 0.9.0 broke the gate
14:46:05 <flaper87> and .1 has the fix
14:46:10 <flaper87> AFAIK
14:46:22 <flaper87> s/AFAIK/AFAIR/
14:46:27 <jokke_> Matt Riedemann
14:46:34 <nikhil_k_> excellent
14:46:35 <flaper87> jokke_: thanks, I had forgotten his lastname
14:46:52 <jokke_> yes it broke rdb gate so matt fixed it and requested release ...
14:48:25 <nikhil_k_> there's a email to openstack-announce on the release 0.9.1 that I can't find in this hurry
14:48:38 <nikhil_k_> anyways, moving on if nothing more here
14:48:52 <nikhil_k_> #link https://review.openstack.org/#/c/195820/
14:48:52 <wokuma1> Just wanted to remind cores to review https://review.openstack.org/#/c/195820/ for Liberty...thanks mclaren for reviewing...
14:49:02 <mclaren> np
14:49:14 <wokuma1> It's been listed here as critical: https://etherpad.openstack.org/p/glance-liberty-rc-reviews
14:49:27 <flaper87> #link http://lists.openstack.org/pipermail/openstack-announce/2015-September/000613.html (glance_store 0.9.1)
14:49:43 <nikhil_k_> haha, awesome flaper87
14:49:55 <flaper87> nikhil_k_: :D
14:50:00 <nikhil_k_> wokuma1: yeah, I think we need that in before rc1
14:50:24 <flaper87> wokuma1: I'll review
14:50:36 <wokuma1> nikhil_k: agree
14:50:42 <nikhil_k_> hopefully there's no migration for artifacts in the pipe currently, mfedosin ?
14:50:43 <wokuma1> flaper87: thans
14:50:55 <mfedosin> nope
14:51:04 <wokuma1> s/thans/thanks
14:51:21 <mfedosin> but they will be in Mitaka
14:51:28 <nikhil_k_> thanks
14:51:30 <nikhil_k_> #link https://bugs.launchpad.net/python-glanceclient/+bug/1493859
14:51:31 <openstack> Launchpad bug 1493859 in python-glanceclient "The glance client should not raise HTTP errors" [Undecided,Opinion] - Assigned to Niall Bunting (niall-bunting)
14:51:52 <bunting> I discovered that the client raises http errors
14:52:00 <nikhil_k_> I think this fix makes sense
14:52:07 <nikhil_k_> bug is in opinion
14:52:18 * flaper87 clicks
14:52:25 <bunting> I was just wondering what people thought about removing this
14:52:29 <bunting> as it seems confusing to me
14:52:49 <nikhil_k_> bunting: you should check nova/cinder about this atleast
14:53:16 <nikhil_k_> may be even horizon, ironic
14:53:43 <flaper87> I'll review that too. I agree w/ jokke_ that we need to be careful becasue we may break the library
14:53:58 <nikhil_k_> nova used locations in few places
14:54:08 <flaper87> nikhil_k_: it still does
14:54:10 <flaper87> :D
14:54:11 <nikhil_k_> if they are expecting exc.HTTPNotFound('Unknown URL(s): %s' % list(missing_locs))
14:54:23 <nikhil_k_> oops, I meant _uses_
14:54:27 <jokke_> yes my problem is that this change _is_ actually breaking backwards compatibility, while being sensible idea but by the looks of it, the way those are done looks very intentional mocking HTTL responses ... anyone remembers long enough backwards for reasoning for those?
14:54:29 <flaper87> nikhil_k_: gotcha
14:54:36 <nikhil_k_> good catch, thanks
14:55:16 <nikhil_k_> jokke_: we will have to discover
14:55:24 <flaper87> nikhil_k_: ++
14:55:29 <nikhil_k_> :)
14:55:29 <flaper87> further tests and reviews are needed
14:55:47 <flaper87> other than that, it seems sensible
14:55:49 <nikhil_k_> last one on the agenda, a very late addition so will go in open discussion
14:55:56 <nikhil_k_> #topic open discussion
14:55:59 <nikhil_k_> #link https://review.openstack.org/#/c/196240/
14:56:08 <nikhil_k_> hemanthm_: ^
14:56:17 <hemanthm_> I wanted to see if there a way of getting this into L.
14:56:30 <hemanthm_> At a point we were waiting for lite-specs and now it looks like it won't happen in L.
14:57:01 <jcook> it's a borderline bug / feature
14:57:03 <hemanthm_> jcook ^
14:57:03 <mclaren> hmm 'So,
14:57:06 <mclaren> this change also monkey patches essential python modules.'
14:57:24 <jcook> true
14:57:38 <hemanthm_> mclaren: that's more a bug fix.
14:58:00 <hemanthm_> those modules should have been monkeypatched any way
14:58:00 <jcook> in the scrubber, which is a tiny code base
14:58:17 <nikhil_k_> yeah, but they are in scrubber. I think api does this already
14:58:20 <jcook> and which cause incorrecet behavior
14:58:29 <nikhil_k_> the worry part for me is the config
14:58:35 <jcook> true, it adds a config
14:58:42 <jcook> that is why I say it's borderline
14:58:48 <nikhil_k_> yeah
14:58:53 <flaper87> If there's a spec for it, I'd be happy to consider a late FFE
14:58:54 <nikhil_k_> a good lit-spec
14:59:17 <jcook> we can create a spec, would it follow same process or would there be deltas with current spec process?
14:59:18 <flaper87> too bad we don't have lite-specs, I guess a normal spec but short should be enough
14:59:20 <hemanthm_> flaper87: there isn't one yet. But, I can write one soon
14:59:23 <nikhil_k_> yeah, if people wanna do ffe consideration rather than lite-spec, that works for me
14:59:38 <flaper87> I'd be ok w/ a FFE for this
14:59:42 <jcook> we can absolutely do that
14:59:46 <nikhil_k_> cool
14:59:53 <jcook> thanks!
14:59:55 <mclaren> I'd probably lean slightly against, but if others disagree that's ok
14:59:55 <flaper87> I agree it's borderline and it doesn't break the current behavior
15:00:01 <nikhil_k_> jcook: let's discuss detils offline
15:00:06 <jcook> sounds good
15:00:08 <nikhil_k_> details*
15:00:09 <hemanthm_> thanks
15:00:20 <nikhil_k_> thanks all, we are out of time
15:00:25 <jokke_> around the FFE ... I'd really like to hear positive statement from doc folks before giving my +1
15:00:36 <nikhil_k_> sg
15:00:40 <jcook> jokke_: we can reach out
15:00:40 <nikhil_k_> #endmeeting