20:01:05 #startmeeting barbican 20:01:06 Meeting started Mon Feb 8 20:01:05 2016 UTC and is due to finish in 60 minutes. The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:10 The meeting name has been set to 'barbican' 20:01:19 #topic Roll Call 20:01:37 o/ 20:01:38 o/ 20:01:46 o/ 20:01:49 \o/ 20:02:01 o/ 20:02:07 o/ 20:02:08 o/ 20:02:10 o/ 20:02:33 o/ 20:03:27 quite a few barbicaneers here today 20:03:32 o/ (semi-here) 20:03:32 o/ 20:03:36 let's start with 20:03:41 #topic Action Items 20:03:54 I really need to do a better job of following up with these 20:04:06 #action redrobot to check on status of reported security bug 20:04:28 so the bug is fixed with jkf 's pcks#11 changes that landed during the midcycle 20:04:34 o/ 20:04:44 we still need to figure out what/how to backport it 20:04:49 o/ 20:04:58 so if anyone wants to help let me know, otherwise I'm going to punt 20:05:23 #action redrobot to ping ccneill about the nova+cinder security bug 20:05:27 I believe the patch I sumitted with that applies to kilo. 20:05:37 I don't actually remember what the nova+cinder bug was about ... :- \ 20:05:39 and maybe Juno, but needs to be tested. 20:05:49 jkf cool! 20:06:09 #action redrobot to touch base with Designate folks 20:06:48 so I only kinda touched base through a proxy who said they said they were probably ok with waiting for the /sign functionality to land next cycle. 20:07:23 I should probably go to the next designate IRC meeting and follow up there. 20:07:50 ok, moving on 20:07:57 #topic Liaison Updates 20:08:07 I missed the oslo meeting this morning, so no updates from me 20:08:42 pdesai isn't here so I'll skip her. she's working on documentation updates with the docs team 20:09:07 alee isn't here either, so no updates from Magnum 20:09:23 hockeynut any updates from QE land? 20:09:37 redrobot nothing new sir 20:09:49 hockeynut awesome, thanks 20:10:01 ok, moving on 20:10:18 to today's agenda items 20:10:36 #topic Add support for internal interface 20:10:56 So currently, and for as long as I can remember, Barbican has only ever had a single endpoint 20:11:14 the host_href setting in the conf file controls that endpoint 20:11:40 so that every URL provided in links as references all use the host_href setting 20:12:12 There was a bug reported last week regarding the Version endpoint, which did not use the host_href setting 20:12:43 which led to a discussion by arunkant regarding the support of an "internal endpoint" which as I understand is a Keystone concept 20:13:16 whereby the Keystone service is able to be accessed by both an internal and external endpoint, which can potentially have completely different URLs 20:13:33 redrobot: I have added related bug https://bugs.launchpad.net/barbican/+bug/1541118 20:13:34 Launchpad bug 1541118 in Barbican "Barbican single host setting does not work with internal and public endpoints" [Undecided,New] 20:13:46 arunkant thanks for the link 20:14:19 as I understand it, it is a requirement for HPE to be able to deploy barbican in a similar manner with support for an internal endpoint 20:15:03 although I think this is more of a new feature than a bugfix, since the internal endpoint is not broken, per se, but rather we never implemented the ability to have more than one endpoint. 20:15:33 redrobot: yes, its the same barbican instance. Differentiation is from client access pespectivve i.e. .just depends on which network/ interface, its accessed from i.e. internal or public 20:15:52 When you say internal what does that mean? Internal to what? 20:16:36 rellerreller Internal, in this case is the classification that the Keystone catalog uses for endpoints which can only be accessed from within the control plane network 20:16:39 rellerreller: internal means here..like other openstack services e.g. cinder which are deployed in same control plane 20:16:56 Thanks! 20:17:03 How do other openstack components handle generating self-referential links? Most web apps that I know of tend to use the Host header to get the name that was used to call the service, instead if hard coding the hostname. 20:17:06 so the barbican controller would need to know what network the request came from, and then serve up HATEOAS links appropriate for those respective networks? 20:17:27 woodster_ yes, that's the idea 20:17:38 jkf: That's what was the way implemented on version controller side but not href side 20:18:30 jkf: last week, it was changed from using header, its using hard coded url in config. 20:18:37 in the bugfix discussion for the Versions bug, arunkant pointed out that the way that the reference was being constructed (by looking into the request to retrieve the endpoint the request was originally intended for) was working for the HPE deployment 20:19:37 however, that will not work for all deployments. In the Rackspace deployment, for example, we use Docker containers to run the barbican API process. In this case, merely reflecting the URL that comes in from the request will not work 20:19:48 redrobot: I am not talking about specific company. That's the way its being currently done in keystone as well. 20:20:30 arunkant I'm only mentioning specific deployments here, because we need a solution that works for those 20:21:02 so, while it appears to arunkant that the way Versions endpoint was working was correct for him, it did not work for us 20:21:14 so it seems if that href is specified in configs, then it is used as the ref host, otherwise it would be dynamically generated? 20:21:31 arunkant: ...desired behavior that is 20:21:39 maybe for a temporary fix we can have a switch in the conf that tells Barbican which url to use "from conf" or "from request" 20:22:07 woodster_ diazjf I think that to be able to arrive at a solution that works for both of these scenarios we should spec it out, instead of trying to guess the solution here. 20:22:26 yes diazjf 20:22:30 Perhaps just not specifying it would provide the dynamic behavior? 20:22:32 diazjf: Yes..that's the discussion we had that last week 20:23:11 redrobot, agreed, just thinking of a temp fix so hpe is happy until a spec is made :) 20:24:26 woodster_, keystone has something like this https://github.com/openstack/keystone/blob/master/keystone/common/wsgi.py#L371 20:25:06 arunkant do you want to write a spec outlining the changes needed so that Barbican can also use that method of generating URLs ? 20:25:20 So, bugfix can be around that change . 20:26:36 arunkant I'm not sure I understand your last statement... 20:26:50 arunkant but yes, the goal is to be able to support an internal URL 20:26:53 redrobot: I was thinking of implementing the way, its mentioned in above link. I am not sure how soon spec approval is going to be. 20:27:23 spec approval has been rather slow... :( ... doesn't mean we should stop writing specs though 20:29:10 redrobot: I am not sure change like need a spec. I can write details in implementation. 20:30:19 redrobot: will that work ? 20:30:37 arunkant I feel like this is not just a bugfix for the reasons I explained above 20:31:38 arunkant but if you really don't want to write a spec, I suppose an implementation will have to do. 20:32:19 redrobot: okay. I will clarify whatever aspect needs to be covered in commit comments. 20:33:17 redorobot: that's it about this topic from my side. 20:33:28 ok, moving on 20:33:32 #topic Setup a Barbican Guild meeting 20:34:36 diazjf ping 20:34:43 redrobot, so silos, edtubill_ and I have a bunch of code we want to get into Mitaka, so far its going pretty well :) 20:35:21 We wanted to head over to San Antonio sometime next week and get feedback so we have time to get everything in before code freeze 20:35:45 diazjf let me check with the boss for a good day y'all could come down 20:36:04 redrobot, awesome! yeah let me know 20:36:05 #action redrobot to ask the rackspace overlords for a time to get the guild together 20:36:18 diazjf sounds good 20:36:19 redrobot: code freeze date for Mitaka is on 3/4, right ? 20:36:25 jhfeng correct 20:36:36 thx 20:37:13 jhfeng http://releases.openstack.org/mitaka/schedule.html 20:37:36 jhfeng ideally it would be on March 1 20:37:59 redrobot, we are making good progress so far! 20:38:13 ok, moving on 20:38:26 #topic KMIP Key Manager for Castellan 20:38:35 #link https://review.openstack.org/#/c/246546/ 20:38:40 \o/ 20:38:48 silos go ahead 20:39:32 I'm trying to get this into Mitaka. I just wanted to put out a reminder of some specs are still pending including this one. 20:39:46 silos do you need it for some other project to use in Mitaka? 20:39:56 silos because Castellan does not follow the release cycle 20:40:11 ah yea. I keep forgetting. No no dependency. 20:40:15 silos I can review. Keep pinging me. 20:40:23 rellerreller: thanks. 20:40:55 silos, same 20:41:05 awesome, thanks kfarr and rellerreller ! 20:41:07 kfarr: thanks. 20:41:14 silos anything else on this topic? 20:41:20 nope. 20:41:36 ok, moving on 20:41:37 #topic Required configuration options without a default value 20:41:44 #link https://review.openstack.org/#/c/273863/ 20:41:45 rellerreller 20:42:02 Yes, we had a question come up about this code. 20:42:16 There is a configuration option that is mandatory, but it provides no default. 20:42:31 https://review.openstack.org/#/c/273863/8/castellan/common/utils.py line 35 20:42:35 Should we specify a default or is it ok to force deployer to choose. 20:42:55 If nothing is set in conf file then exception will be raised. 20:43:07 We are wondering what the precedent is for this scenario. 20:43:33 If there is precendent. 20:43:59 So the question is, "should we provide a default?" 20:44:33 is it any different from kmip_plugin setting in barbican.conf ? 20:45:16 error will be raised if kmip_plugin is selected but not configured. 20:45:45 I think that, as long as the error makes it obvious as to why it's happening, then we should be ok? 20:45:49 This is a top-level configuration option whereas the KMIP section is only active if the secret store type is KMIP. 20:45:53 It is a good point. 20:45:56 * redrobot is not an oslo.conf expert 20:46:29 rellerreller, diazjf, I think having to specify a value there will make integration more difficult 20:46:37 That's fine with us. That's what we had, but I was not sure if OpenStack rules specified that things must work out of the box. 20:47:41 redrobot, rellerreller, I'm thinking an error should be thrown specifing the appropriate types. kfarr, I don't think defaulting any auth_type would work since the rest of the variables are specific to the auth_type. 20:48:06 kfarr, like if we set it always to be token, we need to make sure the token is also passed. 20:48:55 kfarr, but I see what you mean, so to not break anything we should just pass the oslo.context object 20:48:56 That's true, but it is likely to be the most used option. 20:48:58 by default 20:49:03 diazjf, I think the factory logic could be modified, so that if you pass in a context object, it will always return a KeystoneToken credential that pulled the values from the context object 20:49:38 and if you only pass in a conf object, then you'd look at what auth type is set, then make sure the appropriate conf values are there 20:49:44 what do you think? 20:50:27 kfarr the problem is that it is tough to override that. The calling code must now decide what to do. 20:50:48 Whereas this approach allows the configuration option to choose it and reuse code. 20:51:04 kfarr, I'm thinking about it. I'm going to setup a POC with swift encryption and checkout how the flow works and get jrichli to review it 20:51:10 Otherwise the other services will all have common code that says if auth type is context then send it, else do not. 20:51:52 So redrobot the answer seems that it does not matter? 20:52:17 We can debate the rest of this on the code review or in chat if there are other topics. 20:52:38 rellerreller, sounds good. Thanks for adding this to the agenda 20:53:19 I think I'm missing more context to have a good answer... I recall we were aiming to just have client code (eg swift code) just pass the CONF object to Castellan (probably during instantiation) and Castellan would know what to look for, and instantiate the right auth based on what it finds in the CONF ? 20:53:26 I personally don't care too much one way or the other. I think we should just pick one way or the other by COB tomorrow (or pick some other date) and go with it. 20:54:25 redrobot that is correct. The issue is whether or not the correct auth type must have a default in the code if none is found in the conf. 20:55:01 I vote no default, but we can hash it out in the reviews 20:55:42 rellerreller ah, I see... I would think no default seems like a good option. 20:56:00 better to fail early than to use the wrong auth methinks 20:56:23 I'm ok with that. 20:56:39 +1 ship it! 20:57:22 okay, sounds like we're done here for the day. 20:57:27 thanks everyone! 20:57:30 #endmeeting