20:01:05 <redrobot> #startmeeting barbican
20:01:06 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:10 <openstack> The meeting name has been set to 'barbican'
20:01:19 <redrobot> #topic Roll Call
20:01:37 <edtubill> o/
20:01:38 <mp1> o/
20:01:46 <diazjf> o/
20:01:49 <silos> \o/
20:02:01 <rellerreller> o/
20:02:07 <jhfeng> o/
20:02:08 <kfarr> o/
20:02:10 <jkf> o/
20:02:33 <arunkant> o/
20:03:27 <redrobot> quite a few barbicaneers here today
20:03:32 <rm_work> o/ (semi-here)
20:03:32 <woodster_> o/
20:03:36 <redrobot> let's start with
20:03:41 <redrobot> #topic Action Items
20:03:54 <redrobot> I really need to do a better job of following up with these
20:04:06 <redrobot> #action redrobot to check on status of reported security bug
20:04:28 <redrobot> so the bug is fixed with jkf 's pcks#11 changes that landed during the midcycle
20:04:34 <maxabidi> o/
20:04:44 <redrobot> we still need to figure out what/how to backport it
20:04:49 <panatl> o/
20:04:58 <redrobot> so if anyone wants to help let me know, otherwise I'm going to punt
20:05:23 <redrobot> #action redrobot to ping ccneill about the nova+cinder security bug
20:05:27 <jkf> I believe the patch I sumitted with that applies to kilo.
20:05:37 <redrobot> I don't actually remember what the nova+cinder bug was about ...  :- \
20:05:39 <jkf> and maybe Juno, but needs to be tested.
20:05:49 <redrobot> jkf cool!
20:06:09 <redrobot> #action redrobot to touch base with Designate folks
20:06:48 <redrobot> 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 <redrobot> I should probably go to the next designate IRC meeting and follow up there.
20:07:50 <redrobot> ok, moving on
20:07:57 <redrobot> #topic Liaison Updates
20:08:07 <redrobot> I missed the oslo meeting this morning, so no updates from me
20:08:42 <redrobot> pdesai isn't here so I'll skip her.  she's working on documentation updates with the docs team
20:09:07 <redrobot> alee isn't here either, so no updates from Magnum
20:09:23 <redrobot> hockeynut any updates from QE land?
20:09:37 <hockeynut> redrobot nothing new sir
20:09:49 <redrobot> hockeynut awesome, thanks
20:10:01 <redrobot> ok, moving on
20:10:18 <redrobot> to today's agenda items
20:10:36 <redrobot> #topic Add support for internal interface
20:10:56 <redrobot> So currently, and for as long as I can remember, Barbican has only ever had a single endpoint
20:11:14 <redrobot> the host_href setting in the conf file controls that endpoint
20:11:40 <redrobot> so that every URL provided in links as references all use the host_href setting
20:12:12 <redrobot> There was a bug reported last week regarding the Version endpoint, which did not use the host_href setting
20:12:43 <redrobot> 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 <redrobot> 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 <arunkant> redrobot: I have added related bug https://bugs.launchpad.net/barbican/+bug/1541118
20:13:34 <openstack> Launchpad bug 1541118 in Barbican "Barbican single host setting does not work with internal and public endpoints" [Undecided,New]
20:13:46 <redrobot> arunkant thanks for the link
20:14:19 <redrobot> 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 <redrobot> 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 <arunkant> 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 <rellerreller> When you say internal what does that mean? Internal to what?
20:16:36 <redrobot> 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 <arunkant> rellerreller: internal means here..like other openstack services e.g. cinder which are deployed in same control plane
20:16:56 <rellerreller> Thanks!
20:17:03 <jkf> 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 <woodster_> 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 <redrobot> woodster_ yes, that's the idea
20:17:38 <arunkant> jkf: That's what was the way implemented on version controller side but not href side
20:18:30 <arunkant> jkf: last week, it was changed from using header, its using hard coded url in config.
20:18:37 <redrobot> 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 <redrobot> 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 <arunkant> redrobot: I am not talking about specific company. That's the way its being currently done in keystone as well.
20:20:30 <redrobot> arunkant  I'm only mentioning specific deployments here, because we need a solution that works for those
20:21:02 <redrobot> 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 <woodster_> 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 <woodster_> arunkant: ...desired behavior that is
20:21:39 <diazjf> 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 <redrobot> 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 <panatl> yes diazjf
20:22:30 <woodster_> Perhaps just not specifying it would provide the dynamic behavior?
20:22:32 <arunkant> diazjf: Yes..that's the discussion we had that last week
20:23:11 <diazjf> redrobot, agreed, just thinking of a temp fix so hpe is happy until a spec is made :)
20:24:26 <arunkant> woodster_, keystone has something like this https://github.com/openstack/keystone/blob/master/keystone/common/wsgi.py#L371
20:25:06 <redrobot> 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 <arunkant> So, bugfix can be around that change .
20:26:36 <redrobot> arunkant I'm not sure I understand your last statement...
20:26:50 <redrobot> arunkant but yes, the goal is to be able to support an internal URL
20:26:53 <arunkant> 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 <redrobot> spec approval has been rather slow... :( ... doesn't mean we should stop writing specs though
20:29:10 <arunkant> redrobot: I am not sure change like need a spec. I can write details in implementation.
20:30:19 <arunkant> redrobot: will that work ?
20:30:37 <redrobot> arunkant I feel like this is not just a bugfix for the reasons I explained above
20:31:38 <redrobot> arunkant but if you really don't want to write a spec, I suppose an implementation will have to do.
20:32:19 <arunkant> redrobot: okay. I will clarify whatever aspect needs to be covered in commit comments.
20:33:17 <arunkant> redorobot: that's it about this topic from my side.
20:33:28 <redrobot> ok, moving on
20:33:32 <redrobot> #topic Setup a Barbican Guild meeting
20:34:36 <redrobot> diazjf ping
20:34:43 <diazjf> 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 <diazjf> 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 <redrobot> diazjf let me check with the boss for a good day y'all could come down
20:36:04 <diazjf> redrobot, awesome! yeah let me know
20:36:05 <redrobot> #action redrobot to ask the rackspace overlords for a time to get the guild together
20:36:18 <redrobot> diazjf sounds good
20:36:19 <jhfeng> redrobot: code freeze date for Mitaka is on 3/4, right ?
20:36:25 <redrobot> jhfeng correct
20:36:36 <jhfeng> thx
20:37:13 <redrobot> jhfeng http://releases.openstack.org/mitaka/schedule.html
20:37:36 <redrobot> jhfeng ideally it would be on March 1
20:37:59 <diazjf> redrobot, we are making good progress so far!
20:38:13 <redrobot> ok, moving on
20:38:26 <redrobot> #topic  KMIP Key Manager for Castellan
20:38:35 <redrobot> #link https://review.openstack.org/#/c/246546/
20:38:40 <silos> \o/
20:38:48 <redrobot> silos go ahead
20:39:32 <silos> 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 <redrobot> silos do you need it for some other project to use in Mitaka?
20:39:56 <redrobot> silos because Castellan does not follow the release cycle
20:40:11 <silos> ah yea. I keep forgetting. No no dependency.
20:40:15 <rellerreller> silos I can review. Keep pinging me.
20:40:23 <silos> rellerreller: thanks.
20:40:55 <kfarr> silos, same
20:41:05 <redrobot> awesome, thanks kfarr and rellerreller !
20:41:07 <silos> kfarr: thanks.
20:41:14 <redrobot> silos  anything else on this topic?
20:41:20 <silos> nope.
20:41:36 <redrobot> ok, moving on
20:41:37 <redrobot> #topic Required configuration options without a default value
20:41:44 <redrobot> #link https://review.openstack.org/#/c/273863/
20:41:45 <redrobot> rellerreller
20:42:02 <rellerreller> Yes, we had a question come up about this code.
20:42:16 <rellerreller> There is a configuration option that is mandatory, but it provides no default.
20:42:31 <diazjf> https://review.openstack.org/#/c/273863/8/castellan/common/utils.py line 35
20:42:35 <rellerreller> Should we specify a default or is it ok to force deployer to choose.
20:42:55 <rellerreller> If nothing is set in conf file then exception will be raised.
20:43:07 <rellerreller> We are wondering what the precedent is for this scenario.
20:43:33 <rellerreller> If there is precendent.
20:43:59 <rellerreller> So the question is, "should we provide a default?"
20:44:33 <arunkant> is it any different from kmip_plugin setting in barbican.conf ?
20:45:16 <arunkant> error will be raised if kmip_plugin is selected but not configured.
20:45:45 <redrobot> 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 <rellerreller> This is a top-level configuration option whereas the KMIP section is only active if the secret store type is KMIP.
20:45:53 <rellerreller> It is a good point.
20:45:56 * redrobot is not an oslo.conf expert
20:46:29 <kfarr> rellerreller, diazjf, I think having to specify a value there will make integration more difficult
20:46:37 <rellerreller> 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 <diazjf> 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 <diazjf> kfarr, like if we set it always to be token, we need to make sure the token is also passed.
20:48:55 <diazjf> kfarr, but I see what you mean, so to not break anything we should just pass the oslo.context object
20:48:56 <rellerreller> That's true, but it is likely to be the most used option.
20:48:58 <diazjf> by default
20:49:03 <kfarr> 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 <kfarr> 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 <kfarr> what do you think?
20:50:27 <rellerreller> kfarr the problem is that it is tough to override that. The calling code must now decide what to do.
20:50:48 <rellerreller> Whereas this approach allows the configuration option to choose it and reuse code.
20:51:04 <diazjf> 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 <rellerreller> 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 <rellerreller> So redrobot the answer seems that it does not matter?
20:52:17 <rellerreller> We can debate the rest of this on the code review or in chat if there are other topics.
20:52:38 <diazjf> rellerreller, sounds good. Thanks for adding this to the agenda
20:53:19 <redrobot> 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 <rellerreller> 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 <rellerreller> 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 <diazjf> I vote no default, but we can hash it out in the reviews
20:55:42 <redrobot> rellerreller ah, I see...  I would think no default seems like a good option.
20:56:00 <redrobot> better to fail early than to use the wrong auth methinks
20:56:23 <rellerreller> I'm ok with that.
20:56:39 <redrobot> +1 ship it!
20:57:22 <redrobot> okay, sounds like we're done here for the day.
20:57:27 <redrobot> thanks everyone!
20:57:30 <redrobot> #endmeeting