21:00:49 <adrian_otto> #startmeeting Solum Team Meeting
21:00:53 <openstack> Meeting started Tue Mar 10 21:00:49 2015 UTC and is due to finish in 60 minutes.  The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:57 <openstack> The meeting name has been set to 'solum_team_meeting'
21:01:21 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2015-03-10_2100_UTC Our Agenda
21:01:32 <adrian_otto> #topic Roll Call
21:01:34 <datsun180b> Ed Cranford
21:01:35 <adrian_otto> Adrian Otto
21:01:36 <thomasem> Thomas Maddox
21:01:42 <mkam> Melissa Kam
21:01:43 <james_li> James Li
21:01:45 <muralia> Murali Allada
21:01:51 <kebray> Keith Bray
21:01:53 <devkulkarni> Devdatta Kulkarni
21:02:07 <hblixt> Henrik Blixt
21:02:17 <adrian_otto> thomasem: Welcome. Were you here for Magnum or Solum?
21:02:35 <thomasem> adrian_otto: Oh, sorry. Lost track of time >.> Thanks daylight savings time.
21:02:44 <thomasem> I'm here for Magnum
21:02:47 * thomasem creeps back into his corner.
21:02:58 * hblixt joins thomasem
21:03:08 <gpilz> Gilbert Pilz
21:03:09 <adrian_otto> hi hblixt devkulkarni kebray james_li mkam and datsun180b
21:03:17 <adrian_otto> hi gpilz
21:03:18 <Roshan> Roshan Agrawal
21:03:27 <adrian_otto> ok, Magnum will meet in 1 hour.
21:03:36 <adrian_otto> yay for DST.
21:04:33 <adrian_otto> #topic Announcements
21:04:42 <adrian_otto> any announcements from team members?
21:05:09 <adrian_otto> #topic Review Action Items
21:05:11 <adrian_otto> (none)
21:05:23 <adrian_otto> #topic Blueprint/Task Review
21:05:43 <adrian_otto> ok, before we dive in I have a request to resurface
21:06:01 <adrian_otto> that for each review we submit we link it to a bug or blueprint in the commit message.
21:06:15 <adrian_otto> this is so when we tag releases, all of our progress is clearly tracked.
21:06:33 <adrian_otto> sorry for all my -1 votes on your merge quality code
21:06:34 <datsun180b> Understood. My --json patch was something I wanted to add; I've been awful about bugs and bps lately
21:06:50 <adrian_otto> it's not only you datsun180b
21:06:51 <devkulkarni> sounds good to me.
21:07:05 <datsun180b> but it's at least me
21:07:10 <adrian_otto> I just wnat to reinforce that it's important to me to make sure everyone is getting credit for their work
21:07:34 <adrian_otto> ok, so the first task I want to visit is:
21:07:39 <adrian_otto> #link https://review.openstack.org/154614 Adds a --json flag to request JSON output
21:07:52 <adrian_otto> so this one got a +2 vote, and a very long delay with no additional comments
21:08:07 <adrian_otto> so I think it is worth a look now to see if we can approve this for merge
21:09:07 <adrian_otto> my question about async delete was answered, so a 202 response seems appropriate.
21:09:18 <adrian_otto> any discussion on this topic?
21:09:27 <devkulkarni> I have looked at this patch before
21:09:28 <kebray> it doesn't look like anyone else has reviewed the patch.
21:09:37 <kebray> doh, I misspoke
21:09:48 <devkulkarni> but haven't got time to dig into the details. sorry about that.
21:09:59 <devkulkarni> datsun180b: I will look at it asap
21:10:04 <datsun180b> cool
21:10:15 <datsun180b> it'll be easier to parse output
21:10:23 <devkulkarni> sure
21:10:27 <datsun180b> and to autogenerate examples and debug output
21:10:41 <devkulkarni> makes sense. it is a good addition
21:11:40 * kebray says, adrian_otto, Roshan and I want to tag a topic on to the end of the agenda: "unique vs. non-unique plan/LP names"
21:11:54 <adrian_otto> ok, I will be going through all the reviews again now that almost all of them have the right commit message links.
21:12:08 <adrian_otto> kebray: ok.
21:12:27 <muralia> cool. I want to discuss that too
21:12:37 <adrian_otto> are there anoy BP's or Tasks that need team review today?
21:12:50 <adrian_otto> s/anoy/other/
21:13:49 <adrian_otto> #topic Unique/non-Unique plan/lp names
21:14:02 <adrian_otto> kebray and Roshan proceed
21:14:18 <kebray> Ok.. so, adrian_otto you may be able to help...
21:14:34 <kebray> I want Solum to be consitent with how it handles LP names and App names.
21:14:36 <Roshan> Murali and I discussed so far to enforce uniqueness
21:14:55 <adrian_otto> ok, why?
21:14:57 <Roshan> within a tenant
21:14:57 <kebray> So, either we allow non-unique names, or we enforce unique names... I don't want inconsistent behavior.
21:15:22 <adrian_otto> I can express an argument for non-unique app names
21:15:47 <kebray> adrian_otto, I contend that it is a better user experience to have the behavior across "noun create" and "noun list" be the same where possible.
21:16:08 <kebray> adrian_otto, I want non-unique app names too.
21:16:14 <adrian_otto> if we plan to support Green/Blue deployment, it is useful to have two versions of the same app running concurrently.
21:16:15 <kebray> but, more importantly I want consistency.
21:16:22 <Roshan> adrian_otto: what is the argument for non unique names?
21:16:33 <adrian_otto> the unique attribute in that case is id/uuid
21:16:39 <kebray> ++ adrian_otto
21:16:42 <adrian_otto> whereas name is simply a shortcut to the id
21:17:09 <adrian_otto> our code allows for operating on a resource by name or id.
21:17:12 <kebray> I also think that non-unique names is the default for most other things in openstack, e.g. Glace images, Heat stacks, etc.
21:17:24 <adrian_otto> in the event taht you attempt to delete by name and there are multiple matches, an exception raises
21:17:32 <datsun180b> seems anyone creating an ambiguous situation by naming two resources the same thing is attaching a hook and winch to their own petard
21:17:34 <adrian_otto> kebray: true.
21:17:36 <kebray> so, I'd like to see App and LP be consistent with the rest of openstack
21:17:56 <datsun180b> that is, if they intend to continue to refer to the resources strictly by name
21:18:08 <Roshan> would it not be confusing to user to have 2 apps with same name?
21:18:14 <devkulkarni> Roshan, Murali: what was the reasoning behind enforcing unique LP names?
21:18:20 <adrian_otto> as long as referenced to the LP also support (name | id) usage, I suggest we allow non-unique names
21:18:39 <muralia> I don't like it. as a developer, Its good practice to not create two apps or LPs with the same name. as this would confuse me
21:18:40 <adrian_otto> in a case where the selection is ambiguous, raise an exception.
21:18:43 <kebray> Roshan, my argument is it isn't for us to decide.  There's nothing preventing a user from always uniquely naming their apps.
21:18:50 <datsun180b> i'm with adrian, names are a convenience, ids are unique
21:19:17 <adrian_otto> there isa possible compromise too
21:19:25 <Roshan> Do we expect users to reference apps mostly by names or Id's? I would think it would be by name
21:19:35 <kebray> muralia, can you be specific about the use case?  You can still practice the good practice of not naming two apps the same thing, even if we allow non-unique names.
21:19:43 <adrian_otto> the code could all allow non-unique names… and there could be a config option to disallow unique names which would add an additional creation constraint.
21:20:06 <adrian_otto> that way operators who prefer unique names could get them by activating that option.
21:20:24 <muralia> kebray: sure, but then i need to remember to do that. if i use the same planfile to spin up multiple instances of my app, i will end up with 2 instances with the same name
21:20:32 <Roshan> Why would a user or operator want duplicate names?
21:20:55 <datsun180b> and as soon as you say "app show foo" you'll get a "hey you've got two foos, asdfasf and fasdadff. Which did you mean?"
21:20:57 <adrian_otto> Roshan, see above regarding green/blue deploy
21:21:06 <devkulkarni> kebray, muralia: if I understand correctly, for apps we are not enforcing unique names but only for LPs
21:21:11 <Roshan> I didn't fully understand
21:21:14 <Roshan> can you elaborate
21:21:17 <muralia> i dont think the reason 'consistency with other openstack services' is a good reason here.
21:21:31 <muralia> yes, i've implemented uniqness check for LP
21:21:38 <muralia> but app's dont have that check yet
21:21:39 <adrian_otto> ok, if you have an app that has deplyoed, and you modify it, and choose to deploy a second copy of it, you don't want to rename it
21:21:46 <Roshan> + 1 to muralia
21:21:50 <adrian_otto> you intentionally have two copies of the same app (different versions) running at once
21:22:20 <adrian_otto> until all connections are cut over to the new version
21:22:25 <muralia> but in the real world, most devs wont deploy with the same name.
21:22:29 <adrian_otto> or in the case of canary deploy
21:22:35 <adrian_otto> same logic applis in that case.
21:22:36 <kebray> muralia, I'd argue it's bad practice to use the same plan file to spin up different apps that you want named differently.  The "name" is in the plan file.
21:22:51 <adrian_otto> name can be a parameter
21:22:55 <gpilz> "name" doesn't have to be the same as the plan file
21:23:02 <gpilz> beat me to it
21:23:03 <adrian_otto> it does  not have to be hard coded in a plan
21:23:05 <devkulkarni> kebray: I disagree. you could use name plan file to create different apps
21:23:14 <devkulkarni> s/name/same/
21:23:30 <adrian_otto> devkulkarni: +1
21:23:39 <kebray> ok.. fair enough on the reuse of the plan file.
21:23:42 <gpilz> {"plan_uri": "../foo/…", "name": "other_name"}
21:24:04 <kebray> So, name doesn't have to be in the file.. my argument for consistency still stands, or operator choice as adrian_otto suggested.
21:24:24 <devkulkarni> kebray: consistency between apps and LPs or consistency with other openstack services?
21:24:33 <kebray> devkulkarni both
21:24:35 <adrian_otto> my vote would be to allow non-unique by default, and add an option to restrict names to unique.
21:24:48 <kebray> +1
21:24:57 <Roshan> so is the proposal that an operator (say Rackspace) choose to enforce uniqueness?
21:25:03 <kebray> Roshan yes
21:25:19 <Roshan> cool
21:25:35 <adrian_otto> you could even get fancy with taht
21:26:10 <muralia> hmm, why add a flag for something as simple as this. we as designers should just decide. wasn't there a push in openstack to reduce the number of config options.
21:26:14 <devkulkarni> I would like to hear why Roshan and Muralia had unique LP name requirement initially. it was driven by something..
21:26:16 <adrian_otto> and base the restriction on role, etc. So maybe admin users can do it… anyway… not to complicate matters too much. This leaves room for policy to be formed around that later.
21:26:30 <adrian_otto> because the code will accommodate both styles of use.
21:26:36 <devkulkarni> yeah, agree that such a config flag is unncessary
21:26:44 <kebray> Roshan, keep in mind that the rest of Rackspace openstack services don't enforce name uniqueness.  You can have duplicate database names, duplicate image names, duplicate heat stack names, etc.
21:26:51 <muralia> dev: the main reason we added uniqueness in LPs was to allow easy sharing of LPs between users.
21:27:13 <Roshan> also, a LP can be referenced by name
21:27:33 <muralia> kebray, thats probably because we dont use DBs using the name. we have a unique url.
21:27:34 <Roshan> if name is not unique, how do you decide which LP is referenced
21:27:35 <adrian_otto> sharing of glance images is a new feature in RAX cloud. It shares by id.
21:27:47 <muralia> where as in solum, we are allowing users to use LPs with either the name or uuid
21:28:06 <muralia> here's a scenario.
21:28:08 <kebray> muralia, not true.. Cloud Databases (Trove) references databases by non-unique name or ID.
21:28:11 <datsun180b> but the purpose of the uuid is to be universally unique
21:28:34 <datsun180b> in the database these resources also bear an incremented id that we don't expose anywhere
21:28:39 <datsun180b> is this not the purpose of uuids
21:28:59 <datsun180b> that is, if the name isn't sufficient we still have an absolute fallback
21:29:08 <kebray> Roshan, you seach by name, if only one match, it's a match.  If more than one match, you error.  In the case of duplicate named LPs, the user would have to use ID to tell the Solum control plane which one they meant.
21:29:35 <muralia> if user1 and user2 , both belonging to the same tenant create LPs. user1 creates a LP names python and uses the LP name in a planfile. user2 comes along and creates python2. now user1 needs to go back and change his planfile to use uuids and not name as the name is not unique
21:29:51 <adrian_otto> fwiw, Magnum just implemented name-or-id actions.
21:30:00 <adrian_otto> and it works exactly as kebray described.
21:30:12 <Roshan> kebray: use of Id is not very user friendly, UUID's are hard to remember.
21:30:16 <devkulkarni> good example muralia
21:30:28 <Roshan> We should not force users to use UUID's
21:30:34 <datsun180b> and we don't
21:30:42 <Roshan> they should be able to work with names
21:30:53 <gpilz> < can't remember names any better than UUIDs; just cuts & pastes everything
21:31:00 <datsun180b> gpilz++
21:31:03 <kebray> muralia, you are talking about sub-users sharing a single domain.  I don't think we need to be concerned much about that. It'll be very clear on a given account when you list LPs that you have two with the same name, and the error of trying to reference by name will be clear.
21:31:46 <kebray> Roshan, we aren't forcing users to use UUIDs... we are giving them a choice to name things uniquely, or not.. and where they don't, they get extended functionaity by having the option to use UUIDs.
21:31:58 <muralia> yes exactly, so if im the first to create and use a LP, im now affected by someone else in another team creating an LP with the same name
21:32:16 <kebray> gpilz++
21:32:47 <adrian_otto> muralia: good use case. I agree that's suboptimal user experience. I also agree with kebray that such conflicts will be infrequent. One way to balance this is with clear documentation to only use id's in your plan file if you want deterministic behavior, and that if you use names, they may conflict, citing your example as a reason not to do that.
21:32:48 <devkulkarni> good point muralia
21:32:50 <kebray> muralia, differnt teams shoulsn't share the same tenant.  Now that's "bad" practice.
21:33:11 <devkulkarni> kebray: I think muralia meant different person within the same tenant
21:33:13 <muralia> ok, different users within the same tenant
21:33:59 <muralia> here's another scenario.
21:34:02 <adrian_otto> it may also be possible to raise warnings when duplicate names are created
21:34:07 <muralia> if we use a name in the planfile
21:34:19 <kebray> so, two differnt folks within the same team working on the same projects both create an LP with the same name.  I think they should expect their files that reference LPs by name to break.  And, we can always implement later the operator override flag to enforce unique names "if" we find it's a problem with customers/users.
21:34:43 <devkulkarni> -1 to operator override flag
21:34:48 <muralia> i can make updated to lp's (security updates for example)  and continue using the name and be assured that i'll always reference the latest LP
21:34:53 <adrian_otto> devkulkarni: why?
21:35:16 <devkulkarni> seems too much for an issue that can be resolved by proper design choice
21:35:20 <kebray> devkulkarni, not suggesting we implement that right now... but there's a path to easily extending to support use-case to enforce unique names later if it were to become a problem.
21:35:26 <muralia> dev +1
21:35:56 <kebray> devkulkarni, muralia , the design choice adrian_otto and I are arguing for allows for flexibility.  why is that not a good design choice?
21:36:05 <adrian_otto> I might add another bite of food for thought
21:36:15 <adrian_otto> we don't currently have the concept of tags
21:36:36 <adrian_otto> this is how systems like docker handle non-unique names
21:36:44 <devkulkarni> kebray: that design choice just complicates things that an operator needs to keep track of
21:36:52 <adrian_otto> at least for images
21:37:11 <adrian_otto> do say you have two images foo and foo
21:37:22 <adrian_otto> you can tag the first as foo:1 and the second as foo:2
21:37:27 <kebray> devkulkarni, again, I'm NOT advocating that we implement it now. And, we are talking about a single config option that isn't required for the operator.
21:37:45 <adrian_otto> and now you essentially have an alias to the name that can be reassigned to another image
21:37:51 <adrian_otto> we could do that with LPs
21:38:02 <kebray> adrian_otto, overkill for the short term?
21:38:07 <devkulkarni> so then kebray what will be default value of this flag?
21:38:16 <adrian_otto> :latest
21:38:27 <adrian_otto> you automatically add that tag if none specified
21:38:29 <devkulkarni> we will be back to deciding whether it *should* allow non-unique names or *should not* allow themm
21:38:35 <kebray> devkulkarni, default will be consistent behavior with openstack, which is allow non-unique names.
21:38:43 <adrian_otto> kebray: you could defer that, but it's another solution to this
21:39:16 <kebray> adrian_otto agreed... but, it's a future feature "if" use cases bare out operator need to enforce name resolution via tags.
21:39:28 <adrian_otto> HTTP also has a concept of this called entity tags, which can be soft or hard references
21:40:10 <adrian_otto> kebray: we agree
21:40:10 <devkulkarni> roshan, muralia: thoughts?
21:40:16 <adrian_otto> devkulkarni: I want clarity on your position
21:40:32 <adrian_otto> you want unique names by default?
21:40:39 <devkulkarni> adrian_otto: my position is that I agree we need to be consistent between apps and lps
21:40:54 <devkulkarni> I don't quite necessarily agree that we need to be consistent with other openstack services
21:41:01 <muralia> devkulkarni +1
21:41:01 <kebray> devkulkarni, I'm advocating for a single decision now, which provides options for supporting both decisions later. ....  vs. picking a single decision now where we would reverse the decision later.
21:41:05 <lifeless> can I ask a question ?
21:41:11 <muralia> sure
21:41:15 <devkulkarni> I am okay if we introduce a config option
21:41:17 <adrian_otto> lifeless: yes!
21:41:21 <lifeless> It seems to me there is a security issue
21:41:40 <lifeless> which is that if you enforce uniqueness cross-tenant you necessarily leak other-tenant data to users
21:41:49 <datsun180b> I see
21:41:52 <lifeless> because they can probe for names that they can't use
21:41:59 <adrian_otto> lifeless: good point
21:42:03 <devkulkarni> good point
21:42:10 <kebray> lifeless, good point, but we are still discussing uniqueness within a single tenant
21:42:15 <muralia> uniquiness is only within a tenants namespace
21:42:20 <muralia> not across tenants
21:42:22 <Roshan> lifeless: the uniqueness proposal is for within a given tenant, not across tenants
21:42:24 <lifeless> ok cool
21:42:29 <lifeless> sorry for my confusion :)
21:42:33 <kebray> no worries :-)
21:42:40 <adrian_otto> so when documenting the unique name feature, we should disclose that sideband leak as a risk of that use.
21:42:42 <muralia> good point though. thanks lifeless
21:43:08 <kebray> so, any opposition to having the default be we support non-unique app and lp names?
21:43:10 <devkulkarni> kebray, adrian_otto: I am okay if we go the config option route
21:43:27 <kebray> great.. thx devkulkarni .  muralia ?
21:43:33 <muralia> sure. that works.
21:44:02 <lifeless> is that config option a deployer option or user option? If its a deployer option, won't that make the behaviour of clouds harder to predict?
21:44:12 <devkulkarni> ++ lifeless
21:44:33 <adrian_otto> lifeless: I conceived that as a cloud operator option (global)
21:44:38 <lifeless> One of the things I consistently hear about OpenStack is how hard it is to write things to it - to predict the way you should use its APIs. I worry, in dicussions like that, that we're not addressing that.
21:44:43 <adrian_otto> but it could be set per tenant
21:44:48 <lifeless> s/like that/like this/
21:45:07 <kebray> lifeless, I don't think anyone is going to come along and actually implement the flag... but, the option to implement is there if providers find that customer uses cases necessitate it for their needs.
21:45:20 <lifeless> I think a reasonable principle here would be that if the option doesn't *impact* operators, it shouldn't be an operator option.
21:45:39 <devkulkarni> btw, I am sure roshan and muralia initially proposal was informed based on some user feedback
21:45:47 <lifeless> So in this case I'd argue that if there is an option, it should be an option for tenants to use themselves, not operators.
21:45:59 <kebray> devkulkarni, evidence?
21:46:00 <adrian_otto> operators should know enough to decide what defaults are sensible for their users
21:46:11 <adrian_otto> the setting could be a default behaviour per tenant
21:46:12 <kebray> lifeless, I like your suggestion.  makes sense.
21:46:18 <adrian_otto> and the tentant coudl be given the option to change the default?
21:46:26 <devkulkarni> kebray: I am just making a guess.. otherwise why would the proposal been made in the first place?
21:46:40 <kebray> devkulkarni, because no proposal means nothing gets done :-)
21:46:51 <lifeless> adrian_otto: that would meet the constraint I'm proposing, though at that point I think one could ask why we need a configurable default :)
21:47:08 <muralia> devkulkarni, kebray: our design was based on making it easy for users to use and share LPs with both uuids and names at all times.
21:47:09 <adrian_otto> fair enough
21:47:41 <devkulkarni> muralia: got it. thanks
21:47:50 <lifeless> adrian_otto: e.g. if we said 'default is unique [because its more restrictive], and tenants may opt in to non-unique anytime they want'
21:48:17 <kebray> muralia, I've seen little fleshed out with regard to LP sharing. there is, however, good precident with image sharing, and it's done by ID.  There's also good evidence of other kinds of sharing, from files/containers/repos, and those are done by unique URI, not name.
21:48:30 <devkulkarni> lifeless: valid point
21:48:35 <adrian_otto> and de facto operators can decide how to set that option each time they create a tenant
21:48:50 <lifeless> adrian_otto: right, they can definitely do that if they felt the urge
21:49:06 <lifeless> adrian_otto: and we'd save a oslo.config option on disk, documentation, and code.
21:49:25 <adrian_otto> yep
21:50:14 <kebray> lifeless, I'm not understanding the difference between starting with the default being restrictive vs. not restrictive?  what's the advantage?
21:50:17 <adrian_otto> ok, should I record a #agreed?
21:50:47 <datsun180b> please do
21:50:51 <muralia> kebray: if i create a planfile for an app that i deploy to production. i want to know it will work exactly the same everytime. i dont want it to break when someone creates a new LP with the same name. im also on with allowing non-unique names, but then only accepting uuids in planfiles.
21:50:59 <kebray> other than it's harder to have a user with duplicate names switch to restrictive mode.
21:51:02 <adrian_otto> kebray: with that approach you are not out of policy when the setting is changed to be more permissive.
21:52:46 <kebray> so, I can be ok with that, assuming we drive consistency.. but, we we would acknowledge that we are diverging from default openstack behavior elsewhere, and I don't have any valid use case to back that up.
21:53:08 <kebray> sorry, let me repharse.
21:53:11 <kebray> repharse
21:53:19 <lifeless> rephrase?
21:53:38 <kebray> Valid use cases have been presented today.. .but, what I mean to say is they aren't vetted, in my opinion, with a large enough target user sample size.
21:53:45 <adrian_otto> #agreed LP and App names shall be non-unique. In the event that an ambiguous name is used to act on an LP or App, an exception shall be raised, suggesting the use of the uuid to identify the resource to act on. We reserve the option to implement an option for per-tenant unique name restrictions to be evaluated at resource creation time.
21:54:08 <adrian_otto> I can undo that if we are actually not in agreement.
21:54:09 <kebray> +1 adrian_otto
21:54:56 <adrian_otto> devkulkarni, muralia are you in agreement?
21:54:57 <devkulkarni> +1
21:55:01 <muralia> +1
21:55:06 <adrian_otto> tx
21:55:13 <kebray> thanks for the help lifeless
21:55:23 <adrian_otto> I'm going to advance us to open discussion
21:55:30 <adrian_otto> #topic Open Discussion
21:56:53 <adrian_otto> ok, we can wrap up a few minutes early if we don't have more topics to cover
21:57:33 <adrian_otto> Our next meeting will be on 2015-03-17 at 2100 UTC. Thanks everyone for attending.
21:57:41 <adrian_otto> #endmeeting