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