14:00:51 <markwash> #startmeeting glance
14:00:52 <openstack> Meeting started Thu Aug 29 14:00:51 2013 UTC and is due to finish in 60 minutes.  The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:53 <flaper87> o/
14:00:55 <openstack> The meeting name has been set to 'glance'
14:01:00 * markwash waits for folks
14:02:32 <nikhil> some folks were not sure if the meeting was at 14utc or later
14:02:57 <nikhil> however, they were communicated (and i hope they realized it)
14:03:16 <markwash> alas
14:03:18 * flaper87 almost forgot about it
14:03:51 <markwash> I guess I should set up an automatic reminder
14:03:55 <nikhil> markwash: until wish to update a bit on the task flow
14:04:07 <nikhil> we played around with the examples day before
14:04:23 <nikhil> however, wanted to make sure if we could be able to couple it with glance rightly
14:04:39 <markwash> nikhil: how did that go?
14:04:56 <nikhil> could not do that yesterday as we needed some input on how the async TaskFactory should look like
14:05:05 <nikhil> we've a conflict in a way
14:05:11 <iccha> hey
14:05:16 <nikhil> the task that is created for import
14:05:29 <nikhil> need image record before setting the data (ideally)
14:05:58 <nikhil> so should that be inherited from ImageFactory or what else would be a better option
14:06:01 <nikhil> ?
14:06:21 <ameade> \ /
14:06:25 <ameade> /o\
14:06:35 <nikhil> as doing image.setdata and repo.save might look good at that level
14:06:57 <markwash> nikhil: hmm. . I probably just need to look at the code again
14:07:02 <nikhil> ok sure
14:08:04 <ameade> I have some ideas so maybe we can bug you markwash as we push through today
14:08:09 <markwash> nikhil: it is a bit difficult
14:08:27 <markwash> in a way, the synchronous script for image import needs access to a whole cross section of the domain
14:09:07 <markwash> so maybe having it live on Factory or Image itself doesn't quite work. . .
14:09:09 <ameade> markwash: is that a problem though? could we just have that script use gateway to create the iamge?
14:09:16 <ameade> just like the api layer would?
14:09:35 <markwash> ameade: right.  if its a script, the problem sort of goes away
14:10:04 <ameade> k, we can work out the impl as the day goes by then :)
14:10:05 <nikhil> hmm. taskflow might make it kinda not a script
14:10:27 <ameade> nikhil: i think even still we could treat it the same way but i'm not sure
14:11:23 <ameade> and sorry i kinda jumped into the meeting sounding like 'lets not talk about this right now'
14:11:55 <markwash> I suppose we should take a look at the status of our blueprints
14:12:00 <markwash> #topic h-3 blueprints
14:12:15 <markwash> everything that's specifically targeted to H3 is in review
14:12:39 <ameade> wooo, no blockers?
14:12:45 <markwash> regarding glance-scrubber, I talked to zhiyan earlier this week
14:12:58 <zhiyan> markwash: TBH, i'm not sure lcoation-status is, sine John like it landing in h also ..
14:12:58 <markwash> it looks like the code is doing the right thing, but I personally find the scrubber so hard to understand
14:13:19 <markwash> zhiyan: hey there you are! I couldn't tab-select you before :-)
14:13:31 <zhiyan> markwash: yes, i have committed a new version, it using  the way which we talked yesterday (my tz)
14:13:49 <zhiyan> sorry, i'm little late :)
14:13:52 <markwash> zhiyan: great, so another review is in order
14:14:04 <zhiyan> thanks.
14:14:27 <markwash> looks like this is not blocked
14:14:33 <zhiyan> markwash: btw, and i'm not sure this is also in your/team list : https://review.openstack.org/#/c/43899/
14:15:27 <zhiyan> markwash: a separated patch from location-status. and i consider it will resolve some defect which live in multi-location situation ...
14:15:39 <markwash> zhiyan: looks important, can you target it to a (possibly new) bug?
14:15:47 <zhiyan> markwash: i mean registry v1 api
14:15:49 <markwash> and target that bug to h-3?
14:16:43 <zhiyan> markwash: ok....but you really think a bug record is important :) currently it be traced by location-status bp
14:16:53 <markwash> zhiyan: yes, please :-)
14:17:13 <markwash> it doesn't really feel like part of location-status. . is it?
14:17:44 <zhiyan> markwash: sure thing. btw for the defect also pls team give some eyes on https://review.openstack.org/#/c/42896/ . ok back to bp
14:17:50 <zhiyan> markwash: yes i think it is
14:18:56 <markwash> zhiyan: hmm. . well I wanna get this right for priority purposes. . is it a bug right now that we aren't encrypting multiple locations, only the first location? or does that bug only come in based on other location/status changes?
14:19:05 <zhiyan> markwash: do you like talk about location-status change ? if you had checked it..
14:20:07 <markwash> zhiyan: not just yet
14:20:11 <zhiyan> markwash: for bug, yes it is. it not only for location-status, it's for any multi-location situation
14:20:18 <markwash> okay cool
14:20:43 <zhiyan> ok, i'm sure John like it. but seems he is not here yet ...
14:20:51 <markwash> so another bp in the crosshairs is jbresnah's quota bp
14:21:04 <markwash> this was looking pretty great yesterday when I checked, looks like it will go in very soon
14:21:21 <markwash> and the other bp I wanna check in on is iccha's protected properties
14:21:37 <iccha> i appreciate the feedback received on bp so far
14:21:57 <iccha> hemanth: and me will be working on addresseing comments and pushing up patches today
14:22:23 <iccha> also markwash on the side what name would u prefer instead od owner_specified :)
14:22:51 <markwash> iccha: hmm
14:22:52 <iccha> btw markwash bourke is working on v1 side of things
14:23:46 <markwash> iccha: we could even use something as short as "x_"
14:24:17 <markwash> I'm a little nervous about the v1 side. . does it make sense to make this kind of change to the v1 api?
14:24:39 <ameade> markwash: no it doesn't :P
14:24:42 * markwash had always imagined this as a v2 only kind of deal
14:24:48 <bourke> Hi
14:24:50 <markwash> though the dissonance hadn't occured to me before
14:25:28 <bourke> One concern I had around adding this to v1 is there's no way of querying the protected props (i.e. as there is with the json schemas in v2)
14:25:39 <markwash> iccha (or even "x_owner_" or "x_user_")
14:25:54 <bourke> so if a user adds a mix of protected / non protected they may be confused as to the protected ones aren't appearing
14:25:55 <iccha> markwash: sounds good
14:26:48 <markwash> bourke: hmm yeah its a bit difficult
14:27:03 <bourke> s/as to/as to why/
14:27:03 <ameade> can I ask what the motivation for adding it to v1 is?
14:27:24 <iccha> some companies still use v1 i guess
14:28:08 <zhiyan> iccha: +1 like some product/team in ours
14:28:09 <ameade> that's what should change, IMHO
14:28:25 <ameade> i'm not sure what the difficulties of switching are though
14:28:58 <markwash> it makes sense that people still use v1, but. . . it feels like a violation of the v1 contract
14:29:19 <markwash> . . this might explain some of the back and forth with smclaren earlier
14:29:42 <ameade> i'm thinking that and it could be unecessary work/focusing on the wrong problem
14:29:49 <ameade> sorry i'm being really opinionated atm
14:29:54 <ameade> jacked up on coffee
14:29:58 <markwash> haha
14:30:01 <rosmaita> the protected props are entirely optional, we decided months ago that the cloud provider would communicate policy
14:30:07 <rosmaita> since it is so configurable
14:30:59 <markwash> rosmaita: I suppose that would cover it
14:31:02 <markwash> thanks
14:32:01 <markwash> the close links between v1 and v2 make these funny situations
14:32:04 <iccha> zhiyan: bourke is there any plan to switch to v2?
14:32:26 <iccha> what are the blockers for the switch?
14:32:32 <bourke> iccha: not that I'm aware of for the near future unfortunately
14:32:46 <bourke> I think stuart could give better input on that but he's tied up atm
14:32:51 <iccha> i kinda agree with ameade , we cant keep back porting features to previous versions
14:33:21 <iccha> but if there is a real problem on the switching we should be working on that
14:33:22 <zhiyan> iccha: i'm ok for that. i don't like it break v1 spec TBH
14:33:48 <markwash> one issue I'm worried about here is
14:33:57 <iccha> one of the issues esheffield has been looking at nova using glance v2
14:34:10 <markwash> the "default" for v2 is to not allow any old property to be added
14:34:12 <iccha> go for it markwash
14:34:19 <markwash> you have to actually configure it to be that permissive in your schema
14:34:38 <markwash> and prot props is taking that as the given  with its default config, I believe iiuc
14:34:57 <rosmaita> iiuc == ?
14:35:00 <markwash> adding an exception for the whole namespace of "^owner_specified.*" or whatever we settle on
14:35:08 <markwash> if i understand correctly
14:35:56 <iccha> markwash: if that soemthing we convey in documentation?
14:36:08 <iccha> and check for the config is additionalproperties allowed
14:36:11 <markwash> iccha: will the v1 changes make it so that arbitrary properties are generally disallowed?
14:36:52 <iccha> btw the namespace can be deployer specific since its only a config value
14:37:10 <markwash> iccha: agreed, but I don't want the default config values to break existing v1 deployments
14:37:32 <markwash> *existing v1 default deployments
14:37:43 <markwash> maybe we have to make turning on property protections in v1 optional
14:37:50 <markwash> bourke: ^^ does that make sense?
14:38:31 <rosmaita> markwash: are yo usaying that protected props should be independently configurable for v1 and v2
14:38:46 <rosmaita> i.e., someone could want them on in v2 but off in v1?
14:39:01 <bourke> markwash: yes off by default sounds reasonable to me
14:39:12 <markwash> rosmaita: we might be forced to support that. . the whole idea of restricting properties is kind of v2-only at this point
14:39:23 <esheffield> that sounds - kinda terrible
14:39:25 <iccha> hmm so are we assuming that there might be deployments which use both versdions?
14:39:36 <iccha> and it would be enabled in one and disabled in other?
14:40:18 <iccha> so bottom line do we want it in v1 or not?
14:40:27 <esheffield> you really don't want a situation where you can use one version to break the protections of the other
14:40:35 <iccha> markwash: bourke mclaren  ^
14:40:38 <mclaren> iccha: we want it in v1
14:40:39 <markwash> esheffield: in effect that is what we have right now
14:40:51 <markwash> before prop protections are added
14:41:00 <mclaren> iccha: and Paul is writing the code.
14:41:04 <markwash> I am allowed to add anything I want to v1, but v2 would stop me
14:41:16 <markwash> with the default config
14:41:21 <mclaren> Apologies, I was late to the party...what's the issue with v1 support?
14:41:56 <rosmaita> markwash is afraid it could break v1 contract
14:42:16 <mclaren> In which sense?
14:42:29 <markwash> by default, in v1 I can add anything today
14:42:39 <markwash> by default, in v2, I can't add arbitrary properties
14:42:43 <mclaren> oh ok, yeah I raised that
14:42:47 <markwash> so protected properties relaxes v2
14:42:49 <markwash> but constrains v1
14:43:37 <mclaren> and you said we should trawl through existing properties to ensure there was no conflict if I remember?
14:44:20 <markwash> I think we just have to make sure that we don't have a default config that is too restrictive for v1
14:44:21 <zhiyan> mclaren: but this may break existing spec..
14:44:42 <markwash> hence the possible need for different configs for v1 and v2 behavior
14:45:08 <markwash> ugh this is a bright red flag :-(
14:45:40 <mclaren> I'm fine on however we do it, but kinda need it for v1
14:46:04 <rosmaita> mclaren has a point we agreed long ago that it would be in v1
14:46:18 <ameade> mclaren: why do you need it in v1?
14:46:25 <markwash> iccha: maybe by default property protections should not change the namespaces at all by default
14:46:30 <markwash> by default
14:46:30 <mclaren> ameade: hpcloud.com?
14:46:34 <markwash> (had to say it one more time)
14:46:46 <iccha> mclaren: we can set whatever u want default config to be
14:47:00 <iccha> markwash: i mean
14:47:20 <mclaren> I'm fine with any config file contortions
14:47:53 <iccha> its just a config file and the deployer can make it as restrictive or relaxed. by default if protecty propetection config is not turned on it behaves like like nothing pp excists
14:47:58 <iccha> all properties allowed
14:48:23 <markwash> I think if we just configure it off by default, we're good for now
14:48:27 <markwash> okay
14:48:31 <iccha> markwash: what are ur concerns exactly? having it v1 ? or its effects if implemented in v1?
14:48:58 <markwash> I'm worried about the default settings breaking the v1 api backwards compatibilty
14:49:55 <markwash> so, in other bp news
14:49:58 <iccha> the default setting is pp is off and system behaves like nothing ever was implemented.
14:50:04 <markwash> okay cool
14:50:18 <mclaren> ok, thanks folks :-)
14:50:31 <markwash> rosmaita: nikhil: it sounds like you guys are getting close to having all of import ready for review in H3, does that sound right?
14:50:55 <rosmaita> markwash: so can we summarize the decision about pp?
14:51:21 <rosmaita> (meaning can u summarize your understanding)
14:51:49 <markwash> rosmaita: sure. . . something to the tune of "we will ensure that all property protections are off by default to avoid breaking compatibility with the default configuration of the v1 and v2 apis"
14:52:21 <rosmaita> markwash: and it is cool that if you configure pp, it will affect both v1 and v2 ?
14:52:23 <markwash> keep in mind that distros may view stuff in upstream etc/ as defaults
14:53:05 <markwash> rosmaita: it is meh (tolerable). . we need to put big warnings in the config file that changes to that can break backwards compatibliilty, especially easily with v1
14:53:23 <rosmaita> i'm unclear about hte backwards compat break
14:53:42 <rosmaita> isn't this like changing the settting for # metadata items on an image?
14:53:48 <nikhil> markwash: yeah, so once we've a good understanding of the cross section, we can update flwang about it
14:53:51 <rosmaita> i mean the value
14:54:04 <rosmaita> maybe i should just shut up and we will move on
14:54:11 <rosmaita> i will make sure docs are explicit
14:54:37 <nikhil> and hoping to get feedback on the existing patches so that they do not block the rest (basically, there is a linear dependency of the patches now)
14:54:37 <markwash> rosmaita: right now I can add anything I want to a v1 image, but the prot props config in glance/etc only wants me to be able to add anything I want if it is prefixed with owner_specified_
14:54:52 <rosmaita> only if you configure it that way
14:55:05 <rosmaita> i will shut up
14:55:12 <markwash> rosmaita: it looked to me like the config in glance/etc had it configured that way
14:55:23 <markwash> but that config is supposed to reflect the default behavior
14:55:34 <bourke> markwash: the default property_protection.conf option in glance-api.conf is commented out though
14:55:41 <iccha> bourke: +1
14:55:42 <bourke> which in my mind equals off by default?
14:55:51 <markwash> commented out means "this is the default, so you don't need to set it"
14:56:00 <markwash> for example, if the default quota is 0 (unlimited) the config will say
14:56:06 <markwash> # This is your image quota
14:56:10 <markwash> #image_quota = 0
14:56:13 <iccha> markwash: the file doesnt exist by default in code base
14:56:17 <bourke> I think any operator worth their salt would check the docs before uncommenting :)
14:56:19 <iccha> property-protections.conf
14:56:29 <iccha> maybe should make non as explicitly defaul
14:56:39 <markwash> if you want it off by default it should say
14:56:55 <markwash> #property-protections-conf-file =
14:56:58 <markwash> (empty)
14:57:13 <markwash> and the one that's in etc should be suffixed with ".sample"
14:57:28 <markwash> so maybe we just need to make that change
14:57:51 <iccha> ok sounds good. we can move on to other topics now i guess :)
14:58:04 <markwash> #topic open discussion!
14:58:10 <nikhil> and venkatesh's patch can probably abandoned once all the changes are incorporated
14:58:11 <markwash> :-)
14:58:30 <nikhil> (sorry there were 3 comments in between that pp discussion wind up)
14:58:41 <markwash> nikhil: okay, thanks for the update
14:58:43 <nikhil> or rather 2 in between and the one above
14:58:48 <markwash> haha
14:58:52 <nikhil> :)
14:59:05 <zhiyan> markwash: FFE list?
14:59:26 <markwash> currently empty with the hopes of staying that way
14:59:45 <markwash> thanks to everybody for these last minute pushes
14:59:55 <markwash> this is the last week before we have to stop adding new features
15:00:04 <zhiyan> markwash: ok, so need you help review on scrubber-refactoring ...
15:00:10 <markwash> absolutely I do
15:00:15 <nikhil> thanks for the input markwash , ameade and I will work on this a bit ore today
15:00:19 <zhiyan> markwash: thanks again
15:00:33 <iccha> thanks for quick reviews folks
15:00:41 <iccha> that helps the pushing faster :p
15:00:48 <zhiyan> thank you iccha :)
15:00:54 <markwash> I think its time to make way
15:00:57 <nikhil> push -f
15:01:03 <markwash> (or maybe nobody is following us, can't remember)
15:01:06 <markwash> #endmeeting