20:01:55 <redrobot> #startmeeting barbican
20:01:55 <openstack> Meeting started Mon Jan  5 20:01:55 2015 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:59 <openstack> The meeting name has been set to 'barbican'
20:02:16 <tsv> o/
20:02:17 <redrobot> Happy New Year everyone!
20:02:18 <greghaynes> O/
20:02:21 <tkelsey> o/
20:02:23 <elmiko> \o/
20:02:27 <jaosorior> Happy new year and stuff! :D
20:02:29 <rellerreller> o/
20:02:41 <redrobot> Feels good to come back from vacation. :)
20:02:56 <dave-mccowan> o/
20:03:04 <woodster_> o/
20:03:05 <woodster_> Happy new baby rellerreller!
20:03:11 <rellerreller> Thanks!
20:03:14 <jvrbanac> u/
20:03:23 <redrobot> Lots of barbicaneers here today!  ...  Much better than last week. :)
20:03:31 <redrobot> Yeah!  Congratulations rellerreller !!
20:04:30 <redrobot> Also I want to give a shout out to chellygel (even though she isn't here) for taking over meeting duties while I was away
20:04:39 <elmiko> +1
20:04:48 <redrobot> ok, let's get this party started
20:04:54 <redrobot> as usual the agenda can be found here:
20:05:00 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican
20:05:10 <redrobot> #topic Kilo Milestone 1 released
20:05:38 <redrobot> Kilo-1 was released by Thierry right before Christmas
20:05:45 <redrobot> #link https://launchpad.net/barbican/kilo/kilo-1
20:06:17 <redrobot> many thanks to everyone who made the release possible!
20:06:30 <redrobot> Any questions/comments about Kilo-1 ?
20:07:04 <jaosorior> noup
20:07:09 <redrobot> Just as a heads up, we have exactly one month before Kilo-2 is due
20:07:12 <redrobot> #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule
20:07:59 <redrobot> ok, moving on
20:08:40 <redrobot> #topic Quota Blueprint
20:08:40 <redrobot> #link https://blueprints.launchpad.net/barbican/+spec/quota-support-on-barbican-resources
20:08:44 <redrobot> #link https://review.openstack.org/#/c/132091/
20:08:52 <redrobot> woodster_ do you want to talk about this BP?
20:09:26 <redrobot> I thought I saw tsv raise a hand earlier
20:09:34 <tsv> redrobot, woodster, Juan added a comment to my spec to use the oslo common quota implementation
20:09:50 <woodster_> tsv, awesome!
20:10:02 <tsv> i looked at that one and it seems very much usable. it also has user+project level support. do we need user level quota support ?
20:10:21 <woodster_> tsv, do you think you'll have cycles to work on that bp for Kilo?
20:10:27 <hyakuhei_> Per project quota can be tricky when you have no way to ensure the number of projects that can be created by one $bad_guy. I think te proposal makes sense to stop accidental resource consumption though
20:10:39 <tsv> yes. sorry about the delay last year. am now back to work on it
20:11:16 <woodster_> I'm thinking project vs user level is also related to the per-secret RBAC blueprint work
20:11:17 <tsv> hyakuhei_, thanks. that makes sense. so we have project, user and class level quotas
20:11:40 <woodster_> maybe not...seems we can keep those concerns separate
20:11:48 <tsv> ok
20:13:00 <tsv> i am now checking if the config entries I put in the spec is covered by the oslo common code. if not, those needs to be added by an extension
20:13:17 <redrobot> does this BP need to be re-written to reflect Oslo-quota usage?
20:13:36 <tsv> redrobot, yes. i got to do that yet
20:13:45 <redrobot> tsv ok
20:14:04 <redrobot> #action tsv to update Quota BP to use oslo quota
20:15:00 <redrobot> any other questions/comments about this BP?
20:15:36 <tsv> redrobot, not from me
20:15:42 <redrobot> ok, moving on...
20:15:53 <redrobot> #topic Bug 1376469
20:15:56 <alee> so just to confirm, this BP only relates to project quotas?
20:15:56 <uvirtbot> Launchpad bug 1376469 in barbican "Creating a "key" type order without a name set in "meta" produces a null when retrieved" [Low,Incomplete] https://launchpad.net/bugs/1376469
20:16:26 <tsv> alee, yes. project and project+class level quotas
20:16:39 <jaosorior> Yeah, even though it's low prio, just stumbled upon that bug and wanted to get some input before doing anything
20:16:49 <alee> tsv, ok thanks
20:17:15 <woodster_> I'm agreeing with jaosorior that secret name should be optional, and not auto-filled out by Barbican with a UUID or what not
20:18:06 <redrobot> So the open question is, should auto-populating the name with the secret UUID be removed?  And if so, what should the default value be when the name is not provided?
20:18:18 <jaosorior> basically for both secrets and Containers, if the name is left empty, when retrieving it the UUID is shown... yet, in reality the name is actually empty in the database
20:18:34 <jaosorior> so what happens is that if someone tries to use that UUID to query for the entity, it will not work
20:18:47 <redrobot> I'm in favor of removing the logic that assings the UUID to the name.  I think an empty string would be a sensible default (as opposed to a null value)
20:18:51 <jaosorior> so I would like to get rid of this fake auto-population
20:19:23 <alee> jaosorior, sounds good to me.
20:19:32 <elmiko> empty string seems reasonable, especially if the db entry is empty
20:19:36 <rellerreller> What are the properties of a name? Does a name have any uniqueness properties?
20:19:36 <jaosorior> alright, so what could be done is to have an empty string as a default value, and change the model to be non-nullable
20:20:23 <alee> jaosorior, why do we even want an empty string?  why can't it be null?
20:20:24 <jaosorior> wait up, gotta recheck
20:20:45 <woodster_> So if not specified, the name is an empty string? So when that secret meta is retrieved, a 'name' attribute would be returned even if not specified in the original secret?
20:20:59 <jaosorior> why would we want to check for nulls if null semantically represents the same as an empty string
20:21:10 <woodster_> I'm preferring not to return fields that are optional and not specified originally
20:21:18 <jaosorior> the name is not an empty string, it would end up as null
20:21:55 <rellerreller> Null and empty string are not the same to me. Null mean no user input. Empty string may or may not have been set by user.
20:22:06 <redrobot> woodster_ I would prefer to return a standard response, than to selectively return different responses depending on what was populated
20:22:31 <redrobot> no reason why it couldn't be Null... I'm just not a fan of null values.
20:22:37 <alee> rellerreller, exactly -- which is why I would prefer null.
20:22:38 <alee> if user specifies nothing
20:22:59 <alee> redrobot, I'd prefer not to output anything if the user specified nothing
20:23:01 <jaosorior> alee, rellerreller: I see your point, but what
20:23:17 <jaosorior> what's the added value in having that? It would end up in some extra checks
20:23:28 <jaosorior> as opposed as having it simplified by not having null values
20:23:41 <woodster_> rellerreller, I agree when the fields are part of some standard form/template, but metadata about a secret is more user customizable in my mind
20:24:36 <rellerreller> It only matters if someone cares if a value has been set or not.
20:24:37 <woodster_> well, if folks are ok with seeing 'name': '' returned for secret metadata always, even if the 'name' wasn't originally supplied, that is ok with me.
20:24:52 <alee> can I search for secrets with name = "" ?
20:25:02 <rellerreller> It does not matter much to me either way. I was just stating that to me null and "" are not the same.
20:25:03 <redrobot> woodster_ it would say "name": null
20:25:29 <rellerreller> Why not set default name to UUID string?
20:25:44 <rellerreller> That way names are more unique
20:26:01 <woodster_> redrobot, in that case nulls all the way through would work...we'd jsut remove the bit of code that strips name if it is null when the secret model is returned to client
20:26:08 <jaosorior> alee: yup
20:26:12 <jaosorior> at least list them
20:26:29 <alee> it doesn't matter much to me, but I do think that we should treat all optional fields in the same way.  What do we do for other optional fields?
20:26:37 <redrobot> rellerreller the argument was that UUID can't be queried, so there's not much use to setting the name to be a UUID
20:26:38 <woodster_> rellerreller, the name field is free form wrt clients...they could create all their secrets with same name or no name
20:27:13 <jaosorior> redrobot: Actually, the argument was that the UUID that was being displayed cannot be queried the way it is implemented now
20:27:13 <woodster_> If we want UUID default, we'd need to populate that in the database as well so it could be queried
20:27:34 <jaosorior> I wouldn't mind having the UUID as a default value, as long as it's documented, and actually persisted in the database, which at the moment it's not
20:27:45 <rellerreller> I think if we are going to return a default value then that should be the value in the DB
20:27:57 <jaosorior> rellerreller: exactly
20:28:02 <rellerreller> Otherwise we may search for default values that are set
20:28:06 <rellerreller> but not be able to find them.
20:28:39 <redrobot> rellerreller I think we're all in agreement on that point
20:28:42 <jaosorior> well... I guess we all agree that what we display to the user should be what's in the database
20:29:01 <elmiko> jaosorior: +1
20:29:01 <redrobot> yeah, the question then is, what should the default Name be when no name is provided by the user
20:29:04 <rellerreller> So really the change will come in the put or post method?
20:29:19 <jaosorior> now, who's into the idea of returning null values?
20:29:35 <woodster_> well, what is the purpose of the 'name' field anyway? Originally it was just an optional convenience info to add to a secret. If that is still the case, I'm favoring leaving it unspecified (null) if not provided by the client.
20:29:35 <redrobot> options are 1) UUID, 2) Blank Name, 3) Null value
20:29:56 <alee> I vote 3
20:30:03 <rellerreller> +1 3
20:30:04 <jaosorior> redrobot: thanks... that's actually more efficient than what I was doing
20:30:11 <woodster_> I vote null, as it represents the absence of a selection...an opt-out if you will.
20:30:16 <jvrbanac> 1 or 3
20:30:23 <woodster_> +1 3
20:30:31 <jaosorior> 2
20:30:43 <jaosorior> anybody else?
20:30:44 <dstufft> +1
20:30:56 <redrobot> dstufft +1 to # ?
20:31:00 <woodster_> dstufft +1 on 1? :)
20:31:08 <greghaynes> Just a general +1 on the voting? :p
20:31:08 <dstufft> 3 sorry
20:31:21 <dstufft> I'm also +1 on voting in general ;)
20:31:23 <jaosorior> OK, so I guess it's quite clear that 3 wins
20:31:39 <jaosorior> I'll upload a patch soon then
20:31:44 <redrobot> jaosorior I was on board with #2 with you, but it seems we're outnumbered :)
20:31:53 <rellerreller> So will optional values be returned or have a null value?
20:31:59 <woodster_> I think we are also saying to always return 'name' in the returned metadata...so 'name': null would be possible
20:32:14 <jaosorior> woodster_: indeed
20:32:41 <woodster_> I'm ok with that one...but we'll need to be consistent with other optional fields too
20:32:43 <jaosorior> well, this sort of stuff could be filtered in the client
20:32:57 <redrobot> yes, I would prefer that well defined fields (such as name in a secret) always be returned.  So "name": null should be returned for secrets where no name was provided
20:33:09 <woodster_> +1 on that
20:33:09 <jvrbanac> Am I the only one that feels like nulls coming back is a bit ugly
20:33:15 <alee> what do we do with the other optonal values?
20:33:37 <jaosorior> jvrbanac: redrobot and me thought so too, but people have voted
20:33:38 <woodster_> alee, we do suppress other optional fields...so those would need to change too
20:34:00 <alee> woodster_, I would suggest suppressing this one too
20:34:00 <elmiko> jvrbanac: seems a little ugly, but if the user requested nothing maybe it's the most appropriate
20:34:01 <dstufft> null is the absence of vlaue value
20:34:11 <woodster_> jvrbanac, do you mean nulls coming back vs not returning an optional field if it is null?
20:34:13 <jaosorior> so I guess what would end up now is to always return the optional values, and if there's null it should say so
20:34:28 <alee> treat it like every other optional field
20:34:40 <alee> if there is no value, don't return anything
20:34:41 * dstufft thinks option fields should always return null
20:34:50 <dstufft> unless there is a value
20:35:23 <jvrbanac> I normally wouldn't even present the value if it was null,
20:35:26 <redrobot> alee what is the benefit of omitting fields?
20:35:30 <greghaynes> Agreed with dstufft, if its optional it should be nullable, if you return empty string its effectively mandatory with a '' default which seems like an unecessary constraint
20:35:49 <alee> redrobot, whats the benefit of returning fields with null values?
20:35:51 <woodster_> so just be clear, if the field is null, we are saying we want that field to be returned anyway, as 'field_name': null, correct?
20:36:10 <dstufft> alee: it makes it easier to figure out when exploring the API what values can be returned
20:36:20 <redrobot> alee It's easier to parse a secret, for example, if you know that all fields will always be present
20:36:30 <jaosorior> woodster_: uh... that's what I had understood, but now I'm a bit confused
20:36:36 <jaosorior> dstufft: +1
20:36:37 <redrobot> alee instead of having to check whether a field exists in the response for every optional field
20:37:30 <woodster_> folks should be using barbican client anyway :)
20:37:30 <redrobot> woodster_ yes, I would like to see nulled fields in the responses.  alee would like to see them removed from the responses.
20:38:36 <jaosorior> I went ahead and set the bug as invalid, since we are now going for the null values
20:38:37 <jaosorior> now
20:38:38 <woodster_> as long as there aren't a lot of optional fields returned (which we don't have now), I'm ok with that.
20:38:43 <dstufft> I mena in python you'll just do a data.get("optional") or something, but still, it makes things nicer I think to hav enulled fields, there's no question about what can be returned, and you can use data["foo"[ instead of .get() which means if you accidently type data["ofo"] instead of data.get("ofo") you'll get an immediate error instead of silently not returning anything
20:38:47 <alee> redrobot, I'm open either way -- from an interface point of view, I think its cleaner to omit the nulls.
20:39:10 <jvrbanac> I agree with alee, I think it's clean to omit as well
20:39:19 <jvrbanac> ^cleaner
20:39:42 <redrobot> jvrbanac cleaner how?  It makes for uglier code when parsing the responses...
20:39:43 <jaosorior> OK, A) show all values, B) omit null values
20:39:51 <redrobot> +1 A
20:39:53 <jaosorior> +1 A
20:40:00 <dstufft> +1 A
20:40:02 <jvrbanac> +1 B
20:40:04 <elmiko> +1 A
20:40:09 <alee> +1 B
20:40:20 <greghaynes> +1 A
20:40:25 <woodster_> +1 A
20:40:26 <tsv> +1 A
20:40:32 <redrobot> +1000 Democracy :)
20:40:38 <jaosorior> That was easy
20:40:40 <redrobot> I think we've got this sorted out
20:40:51 <woodster_> So....is this an API contract change? :)
20:40:52 <jaosorior> Alright, so I'll upload a CR with this change
20:40:57 <redrobot> any other questions jaosorior ?
20:41:19 <alee> just curious but how does the client code handle if an optional field is ever removed?
20:41:21 <woodster_> I think we've only documented example responses in our API docs so far...no verbiage about this behavior though
20:41:24 <redrobot> woodster_ I don't think so... the structure of the response does not change.
20:42:14 <redrobot> alee I think removing a field would be a breaking change... would have to be dealt with accordingly.
20:42:19 <woodster_> jaosorior, would that CR just focus on 'name', or apply to all secret meta fields?
20:42:27 <jaosorior> redrobot: not that I can think of. I guess now only thing I need to do is push some code :P
20:42:46 <jaosorior> as far as I remember, name was the only one with the weird behaviour
20:42:51 <jaosorior> which is also the case for Containers
20:43:01 <jaosorior> but I can check the rest of the fields, no problem
20:43:04 <alee> redrobot, just pointing out that not checking for the existence of an attribute in the client makes it more rigid
20:43:37 <alee> redrobot, you may ultimately have to check for attribute existence in any case.
20:43:50 <alee> but democracy has spoken ..
20:43:59 <redrobot> alee noted
20:44:53 <woodster_> will this break any func tests? :)
20:46:07 <redrobot> woodster_ I doubt it...  but I'm sure jaosorior would fix any breaking tests. :)
20:46:24 <redrobot> ok, moving on...
20:46:36 <jaosorior> woodster_: I'm actually not sure, but if that's the case no biggie, would need to fix them anyway
20:46:47 <woodster_> sounds good, thanks
20:46:52 <redrobot> #topic Blueprint Status
20:47:17 <redrobot> woodster_ I think you added this topic?
20:47:34 <woodster_> yep, just a general 'where are we at?' on those essential BP CRs
20:47:46 <redrobot> #link https://blueprints.launchpad.net/barbican
20:48:12 <redrobot> we can go down the list I suppose?
20:48:22 <redrobot> alee how is the common certificate API coming along?
20:48:32 <woodster_> I think alee has been updating those, just more if folks have open questions to air out here. Otherwise we can continue to discuss in our IRC channel
20:48:48 <jaosorior> woodster_: Actually, seems like null name is untested in the functional test, I'll add that
20:48:55 <rellerreller> One not listed on there yet is the content type spec. I will have that out today or tomorrow.
20:49:07 <woodster_> rellerreller, nice!
20:49:10 <alee> redrobot, well -- the blueprint for that is approved
20:49:21 <alee> redrobot, working on impl
20:49:37 <greghaynes> I think the spec doesnt match impl at this point though, right?
20:49:48 <woodster_> rellerreller, does that have a corresponding https://blueprints.launchpad.net/barbican entry?
20:50:05 <rellerreller> woodster_ I'm not sure
20:50:09 <alee> greghaynes, right -- I'll update once the second impl patch is merged
20:50:19 <rellerreller> If not then it will be created today or tomorrow as well
20:50:52 <alee> redrobot, but from a bp point of view - its pretty much done right now.
20:50:53 <woodster_> rellerreller, if not, we should add that one so we can set it's priority...maybe we could decide the priority now?
20:51:04 <redrobot> alee thanks!
20:51:18 <alee> identify-cas is approved, starting to working on impl patches
20:51:22 <redrobot> Looks like there's only two BPs with Essential priority still in review...
20:51:30 <redrobot> #link https://blueprints.launchpad.net/barbican/+spec/add-per-secret-policy
20:51:39 <woodster_> So could we vote on the priority to assign to rellerreller's BP? Or do we all think it is essential?
20:51:41 <alee> add-per-secret-policy has a bunch of comments
20:51:42 <redrobot> #link https://blueprints.launchpad.net/barbican/+spec/add-worker-retry-update-support
20:51:51 <alee> I'm incorporating those and will have new version out today or tommorow
20:52:26 <redrobot> woodster_ I think the Content-Type BP is essential
20:52:53 <woodster_> redrobot, sounds good.
20:53:02 <rellerreller> redrobot woodster_ I think essential as well since it could affect the secret stores and API
20:53:15 <alee> agreed
20:54:26 <redrobot> Ok, we're running low on time for this week...
20:54:32 <redrobot> any last minute questions/comments?
20:54:42 <elmiko> yea, i'm curious about the origins of docs/src/wadl/Barbican.wadl
20:54:47 <woodster_> redrobot, regarding the add-worker-retry BP...that one merged already. I'll add the link to the bp to LaunchPad
20:55:02 <elmiko> is that file hand hacked or auto-generated?
20:55:37 <redrobot> elmiko hand-hacked by one of Rackspace's technical writers... but I don't think she's had much time to work on it lately
20:56:08 <elmiko> redrobot: ok, no worries. i'm doing some work on creating a swagger ref for barbican. just doing some background research about the wadl.
20:56:17 <redrobot> elmiko the API working group is interested in using something like Swagger to try to automate the WADL generation... but we're still figuring that out...
20:56:24 <elmiko> heh ;)
20:56:39 <woodster_> elmiko, I'll be taking a look at that along with the tech writer.
20:56:40 <redrobot> elmiko are you working with the API WG folks?
20:56:44 <elmiko> i have an auto-generator for sahara and i'm working one up for barb
20:56:52 <elmiko> redrobot: yea
20:57:08 <woodster_> elmiko, that sounds nice! I'd like to talk more about that after this meeting if you can
20:57:11 <elmiko> woodster_: ok, maybe i could ping you if i get further along?
20:57:26 <elmiko> woodster_: sure, #openstack-barbican?
20:57:26 <woodster_> elmiko, please do, I'd appreciate that
20:57:38 <woodster_> elmiko, yes that works
20:57:47 <elmiko> cool, that's all i had. thanks
20:58:05 <redrobot> ok, guys, thanks for coming out.  See y'all back here next week!
20:58:14 <redrobot> #endmeeting