14:01:12 <nikhil_k> #startmeeting glance drivers
14:01:13 <openstack> Meeting started Tue Sep 29 14:01:12 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:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:16 <openstack> The meeting name has been set to 'glance_drivers'
14:01:21 <dhellmann> o/
14:01:25 <nikhil_k> Courtesy Glance Drivers' meeting reminder: nikhil_k, flaper87, sigmavirus24, rosmaita, mclaren
14:01:29 <rosmaita> o/
14:01:45 <flaper87> o/
14:02:16 <nikhil_k> #topic agenda
14:02:21 <nikhil_k> #link https://etherpad.openstack.org/p/glance-drivers-meeting-agenda
14:02:40 <nikhil_k> dhellmann: if you wish to add your nick there for reminders
14:02:44 <nikhil_k> fyi :)
14:02:54 <dhellmann> nikhil_k: cool, thanks
14:02:58 <nikhil_k> just one pre-added topic there
14:03:07 <nikhil_k> that was by me
14:03:36 <nikhil_k> #topic inheritable admin prop
14:03:42 <nikhil_k> #link https://review.openstack.org/#/c/206431/
14:03:52 <flaper87> I haven't read that one yet but I will
14:03:55 <flaper87> is there a tl;dr ?
14:04:01 <nikhil_k> yes
14:04:07 <nikhil_k> I will try to give a quick one
14:04:26 <nikhil_k> This is somewhat broken experience afaict
14:05:02 <nikhil_k> The way to inherit certain prop (via nova) in today's deployments is if you have separate glance-api running and they have their own individual prot files
14:05:16 <nikhil_k> so, in devstack inheritance won't work
14:05:57 <flaper87> gotcha
14:05:58 <nikhil_k> the proposal is in nova, and I think the TODOs from our side are to ensure if the CRUD granularity supports this purpose
14:06:02 <rosmaita> i guess it hasn't come up before because property protections are "off" by default
14:06:20 <nikhil_k> and yes, we would want to have appropriate defaults
14:06:47 <nikhil_k> possibly certain published org.openstack.my_prop_list to avoid collisions
14:06:57 <flaper87> That sounds fair enough. I'll give it a detailed read this week
14:07:02 * nikhil_k done for now
14:07:29 <flaper87> by quickly glancing at the spec, it seems they want to add a new config option w/ a list of properties
14:07:35 <rosmaita> in nova
14:07:49 <flaper87> That way of aligning services hasn't work well in the past. Or better, it's proven to be painful
14:07:50 <flaper87> rosmaita: yes
14:07:54 <flaper87> rosmaita: in nova
14:07:58 <rosmaita> but you know, it would be really cool if we could figure out a way for nova to do this while using user credentials
14:08:00 <nikhil_k> please see line 118
14:08:01 <flaper87> that's an important note to have
14:08:08 <rosmaita> the proposal is to have nova use admin creds
14:08:09 <flaper87> rosmaita: exactly
14:08:15 <nikhil_k> we should ensure that the images proxy behaves consistently
14:08:54 <nikhil_k> I think there are some other use cases for adding support for service tokens
14:09:23 <nikhil_k> that way we are less exposing admin creds over the wire, minimize the risk
14:09:26 <dhellmann> if it's a configuration option, it will be deployment-specific. will that matter?
14:09:39 <nikhil_k> it's a long shot but if efforts are in momentum we should attempt for that
14:10:42 * sigmavirus24 apologizes for being late
14:10:45 <flaper87> dhellmann: that's the other concern I have
14:10:54 <flaper87> I mean, some properties are already deployment specific
14:10:56 <rosmaita> dhellmann: shouldn't matter, it's already a deployment-specific option what properties to protect and wehther to protect any at all
14:10:58 <dhellmann> does the user need to know which of these options are inherited and/or locked? (I'm not clear on all the use cases for these properties)
14:11:14 <dhellmann> rosmaita: interesting, ok
14:11:16 <rosmaita> dhellmann: up to now it's been communicated via documentation
14:11:22 <nikhil_k> dhellmann: deployment specific sounds like a sane requirement as the licensing stuff would be quite contextual to those clouds. I think api wise, this should not matter but we can expose discoverability of those prop
14:11:23 <rosmaita> dhellmann: could use metadefs, though
14:11:44 <dhellmann> nikhil_k: I like adding a discoverability api
14:12:08 <nikhil_k> does extending schemas sounds sane?
14:12:17 <nikhil_k> (for discoverability)
14:12:24 <flaper87> mmh, probably
14:12:26 <rosmaita> dhellmann: our advice has been to do it by convention, e.g., don't use com.rackspace as a prefix for your personal properties
14:12:34 <sigmavirus24> dhellmann: e.g. JSON Home?
14:12:44 <dhellmann> rosmaita: makes sense
14:12:47 <rosmaita> but if you use metadefs to describe the properties, i think that would work
14:12:59 <nikhil_k> I like that idea
14:13:14 <dhellmann> sigmavirus24: is that already being used in glance?
14:13:18 <sigmavirus24> oh for properties in general
14:13:21 <sigmavirus24> dhellmann: not quite, no
14:13:23 <nikhil_k> but I guess that adds a precedence for mandatory deployment and exposure of metadefs
14:13:30 <sigmavirus24> there's only one or two projects that use it and that's controversial for other reasons
14:13:33 <flaper87> rosmaita: I'm curious to know how it'd work but we can take it offline
14:13:38 <sigmavirus24> dhellmann: feel free to hop into #openstack-api to talk about that more =P
14:13:43 <rosmaita> flaper87: sure
14:13:45 <jokke_> but they will need to be able to determine that inheritance in Nova no matter how it's done
14:13:46 <flaper87> Glance doesn't use json-home
14:14:01 <rosmaita> jokke_: it would be via configuration option
14:14:31 <jokke_> rosmaita: what I mean is Nova needs to do the setting of those properties
14:14:49 <nikhil_k> sigmavirus24: my question is, is json home recommended for such purposes by API_WG?
14:14:56 <flaper87> One more thing that worries me is that this work may have some conflicts with the v1 -> v2 work. We'll have to make sure we help these 2 specs moving forward
14:15:02 <rosmaita> jokke_: yes, the proposal is that there would be a list, like the current non-inheritable properties list, to tell nova what to do
14:15:02 <sigmavirus24> nikhil_k: we haven't reached agreement on that last I checked
14:15:10 <nikhil_k> gotcha, thanks
14:15:27 <sigmavirus24> The RFC for JSON Home was half-abandoned and never revised so there's disagreement as to whether it is useful since none of those projects' clients use it
14:15:39 <sigmavirus24> It's an involved topic :P
14:15:54 <nikhil_k> #chair flaper87
14:15:55 <openstack> Current chairs: flaper87 nikhil_k
14:15:56 <flaper87> sigmavirus24: FWIW, I personally emailed the author like a year ago and yeah, it's quite abandoned
14:16:11 <rosmaita> sigmavirus24: plus, the RFC is headache-inducing
14:16:17 <sigmavirus24> Yeah, mnot was definitely focused on HTTPBis at that point
14:16:24 <flaper87> nikhil_k: thanks :D you can keep leading it, fwiw!
14:16:39 <nikhil_k> haha, sure
14:16:42 <sigmavirus24> rosmaita: I read RFCs the way some people eat bread, so they rarely induce headaches for me (unless it's crypto related)
14:17:09 <rosmaita> sigmavirus24: remind me not to take you to lunch
14:17:16 <flaper87> rosmaita: ++
14:17:19 <nikhil_k> LOL
14:17:31 <sigmavirus24> lol
14:17:35 <nikhil_k> alternate topping :)
14:17:40 <rosmaita> i just added an agenda item
14:18:17 <nikhil_k> cool
14:18:17 <rosmaita> it's lakshmi's patch/bugfix/spec-lite change
14:18:27 <nikhil_k> #topic image member notifications
14:18:32 <nikhil_k> #link https://review.openstack.org/#/c/221307/
14:19:17 <nikhil_k> There are good compelling arguments both ways. I perceived it as a bug as I am aware about notifications being exposed in certain clouds.
14:19:19 <flaper87> I mentioned to lakshmi that we'd provide feedback on our meeting on thursday but it's good to have a short discussion now to collect thoughts
14:19:33 <rosmaita> so in one way, i can see this as a bug, in that notifications were forgotten when the image-memmber v2 code was done
14:19:49 <rosmaita> but, as flaper87 points out, it's a fairly significant change
14:19:55 <flaper87> It's a bug from SearchLight/Horizon POv but for Glance it really isn't.
14:19:57 <nikhil_k> I think this converges into a discussion around lite-specs
14:20:05 <rosmaita> though, as nikhil_k points out, it does seem kind of innocuous
14:20:11 <jokke_> flaper87: ++
14:20:12 <flaper87> but I don't want to get stuck on that specific point rather than the size of the change
14:20:21 <rosmaita> but yes, let's discuss lite-specs so this doesn't happen again
14:20:29 <rosmaita> or happens a different way, i mean
14:20:39 <dhellmann> this does look like a surprising amount of code just to add notifications on edits
14:21:08 <rosmaita> dhellmann: well, glance has this domain model ...
14:21:08 <flaper87> I honestly don't feel comfortable backporting this change for RC2
14:21:15 <nikhil_k> dhellmann: the reason is that bad coupling that exists (Existed) between images and image member entities
14:21:16 <flaper87> but I'd like to hear others opinions
14:21:39 <flaper87> s/backporting/proposing/
14:21:43 <flaper87> you get my point
14:21:44 <flaper87> :D
14:21:44 <nikhil_k> so, the onion layer is sorta tangled with images and image members at this point
14:22:16 <jokke_> and anything we try to do ;)
14:22:24 <nikhil_k> I found it surprising when I saw the image member get method being statified at the API level
14:22:26 <flaper87> Also, the change was proposed on Sept 8 and the bug has been opened since Kilo
14:22:39 <jokke_> we would need a year of waterfall approach and rewrite that :P
14:23:01 <flaper87> which kinda makes me think, on good faith (obviously), that this could have been taken care of a bit earlier in the cycle and not for RC2
14:23:16 <flaper87> Again, saying that on good faith and I'm not trying to point fingers to anyone
14:23:26 <flaper87> but probably, it wasn't a high prio until now
14:23:40 <nikhil_k> the feedback I had was that it was hard change
14:24:09 <sigmavirus24> flaper87: searchlight is also operating with fewer developers/reviewers than we are
14:24:22 <nikhil_k> I too find it inconvenient that a lot of the non-related code has to be changed to fix this
14:24:22 <sigmavirus24> And so I'm certain this isn't in bad faith and was merely a matter of finding time to address it appropriately
14:24:27 <flaper87> sigmavirus24: yup, I keep that in mind,really.
14:24:36 <sigmavirus24> That said, I too am against backporting such a large change to RC2
14:25:08 <flaper87> it seems that they have a fallback plan in case this isn't backported
14:25:08 <dhellmann> rosmaita, nikhil_k : is "domain model" related to "onion layer" in some way here?
14:25:17 <nikhil_k> ok, can we please have -1, +1, +2, -2s on the patch to better understand the RC2 waitlist
14:25:18 <nikhil_k> ?
14:25:19 <flaper87> so, I'd probably go with that
14:25:29 <flaper87> nikhil_k: ++
14:25:36 <jokke_> sigmavirus24: tbh I don't care why it came this late but I had my concerns to the intrusiveness that change has at the last moment before release :(
14:25:37 <sigmavirus24> dhellmann: might be easier to explain in -glance
14:25:42 <nikhil_k> dhellmann: it's the onion architecture, with all the business buses
14:25:44 <dhellmann> sigmavirus24: ack
14:25:47 <sigmavirus24> jokke_: agreed
14:25:58 <rosmaita> dhellmann: http://docs.openstack.org/developer/glance/domain_model.html
14:26:13 <dhellmann> rosmaita: awesome, thanks
14:26:17 <sigmavirus24> flaper87: the other thing to consider is that for at least two cycles now, this is the way Glance tends to work. Letting large changes in at the last minute because of pressure by a group of developers
14:26:22 <rosmaita> dhellmann: the onion is the way the domain layer gets explained
14:26:44 <sigmavirus24> rosmaita: I know we call it the onion model, but it really is turtles all the way down ;)
14:26:58 <flaper87> sigmavirus24: ain't gonna happen anymore.
14:26:59 <rosmaita> sigmavirus24: onion-eating turtles
14:26:59 <nikhil_k> right from this blog post (a general PSA)
14:27:00 <nikhil_k> #link http://jeffreypalermo.com/blog/the-onion-architecture-part-1/
14:27:25 <sigmavirus24> nikhil_k: ++ I had never seen that before
14:27:32 <flaper87> dhellmann: http://docs.openstack.org/developer/glance/domain_model.html
14:27:39 <flaper87> #link http://docs.openstack.org/developer/glance/domain_model.html
14:27:40 <jokke_> It's called onion model because every time you try to cut through it, you just burst into tears ;)
14:27:51 <rosmaita> jokke_: ++
14:27:52 <nikhil_k> jokke_: :P
14:27:55 <flaper87> jokke_: ++
14:27:57 <flaper87> lol
14:28:00 <flaper87> hilarious
14:28:02 * flaper87 claps
14:28:22 <flaper87> anyway, that's discussion probably for N or even O
14:28:30 <sigmavirus24> No wonder my office always smells bad =P
14:28:37 <nikhil_k> I read that as 0 :P
14:28:48 * rosmaita notes another reason not to lunch with sigmavirus24
14:28:50 <nikhil_k> limit n->inf (1/n) :P
14:28:50 <flaper87> I'll vote on the review and provide feedback
14:29:05 <sigmavirus24> nikhil_k: A+ maths
14:29:14 <nikhil_k> :P
14:29:18 <sigmavirus24> (spoken as a person with a BS and MS in Pure Maths)
14:29:58 <nikhil_k> also as it fits N and O :P
14:30:01 * flaper87 has nothing else
14:30:10 * sigmavirus24 either
14:30:16 <flaper87> btw!
14:30:17 * sigmavirus24 needs to find more coffee so he can be less silly
14:30:28 <flaper87> This patch here can land as long as it's not proposed for RC
14:30:28 <nikhil_k> we are out of time
14:30:35 <flaper87> my comments are not about this patch but the backport
14:30:40 <sigmavirus24> flaper87: yep
14:30:47 <flaper87> If this patch lands in master, that'll be part of mitaka
14:30:57 <flaper87> just want to make sure eeryone knows that
14:31:01 <nikhil_k> true, we need comments on the bug then!
14:31:05 <flaper87> so please, comment on the bug and lets remove the tag
14:31:11 <flaper87> (the rc-potential tag)
14:31:45 <nikhil_k> thanks all for joining!
14:31:49 <flaper87> woohoo
14:31:51 <nikhil_k> #endmeeting