| *** _edmund has joined #openstack-barbican | 00:23 | |
| *** _edmund has quit IRC | 00:23 | |
| *** dave-mccowan has quit IRC | 02:33 | |
| *** dimtruck is now known as zz_dimtruck | 02:50 | |
| openstackgerrit | Merged openstack/barbican: Add Barbican Verification to Install Guide https://review.openstack.org/361693 | 03:14 |
|---|---|---|
| openstackgerrit | Merged openstack/barbican: Fix typo in barbican/tests/keys.py https://review.openstack.org/361610 | 03:22 |
| *** diazjf has joined #openstack-barbican | 04:25 | |
| *** stevemar has quit IRC | 04:28 | |
| *** diazjf has quit IRC | 04:44 | |
| *** jaosorior has joined #openstack-barbican | 05:12 | |
| *** openstackgerrit has quit IRC | 05:18 | |
| *** openstackgerrit has joined #openstack-barbican | 05:19 | |
| *** stevemar has joined #openstack-barbican | 06:06 | |
| *** stevemar has quit IRC | 06:11 | |
| *** pcaruana has joined #openstack-barbican | 06:34 | |
| *** stevemar has joined #openstack-barbican | 06:44 | |
| *** andreas_s has joined #openstack-barbican | 06:54 | |
| *** woodster_ has quit IRC | 07:39 | |
| *** stevemar_ has joined #openstack-barbican | 08:07 | |
| *** stevemar_ has quit IRC | 08:12 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/barbican: Imported Translations from Zanata https://review.openstack.org/364734 | 08:12 |
| *** openstackgerrit has quit IRC | 08:34 | |
| *** openstackgerrit has joined #openstack-barbican | 08:34 | |
| jamespage | for reference, the cause of the unit test failures i asked about yesterday is https://bugs.launchpad.net/oslo.context/+bug/1620963 | 09:01 |
| openstack | Launchpad bug 1620963 in oslo.context "requires positional >= 1.1.0" [Undecided,New] | 09:01 |
| jamespage | min version spec of positional is not sufficient for oslo.context | 09:01 |
| *** stevemar_ has joined #openstack-barbican | 09:08 | |
| *** stevemar_ has quit IRC | 09:13 | |
| jaosorior | jamespage: thanks for digging into it | 09:37 |
| jamespage | jaosorior, np - I figured it was some dependency type issue, just took me a while to dig it out | 09:37 |
| jaosorior | jamespage: are you planning to submit a fix to the requirements repo? | 09:38 |
| jamespage | jaosorior, doing that now | 09:39 |
| jaosorior | jamespage: awesome, thanks! | 09:39 |
| openstackgerrit | Merged openstack/barbican: Imported Translations from Zanata https://review.openstack.org/364734 | 09:41 |
| jamespage | jaosorior, https://review.openstack.org/366631 for reference | 09:42 |
| jaosorior | jamespage: ack | 09:43 |
| *** jsheeren has joined #openstack-barbican | 09:49 | |
| *** jsheeren has left #openstack-barbican | 09:49 | |
| jaosorior | jamespage: seems you'll need to send a mail | 10:00 |
| jaosorior | jamespage: to get an FFE for that bump | 10:00 |
| jamespage | apparenlty so | 10:00 |
| jamespage | I'll do that later - have toduck out for a meeting | 10:01 |
| *** jsheeren has joined #openstack-barbican | 10:06 | |
| *** jsheeren has quit IRC | 10:06 | |
| *** jsheeren has joined #openstack-barbican | 10:06 | |
| *** dgonzalez has quit IRC | 10:45 | |
| *** jsheeren has quit IRC | 10:55 | |
| *** dgonzalez has joined #openstack-barbican | 10:57 | |
| *** stevemar_ has joined #openstack-barbican | 11:09 | |
| openstackgerrit | Merged openstack/castellan: Remove unused requirements https://review.openstack.org/357944 | 11:09 |
| *** stevemar_ has quit IRC | 11:13 | |
| *** jsheeren has joined #openstack-barbican | 11:22 | |
| *** dave-mccowan has joined #openstack-barbican | 11:41 | |
| *** dave-mccowan has quit IRC | 11:46 | |
| *** chlong has joined #openstack-barbican | 12:05 | |
| *** stevemar_ has joined #openstack-barbican | 12:10 | |
| *** stevemar_ has quit IRC | 12:14 | |
| *** jsheeren has quit IRC | 12:40 | |
| *** woodster_ has joined #openstack-barbican | 12:42 | |
| *** jaosorior has quit IRC | 12:49 | |
| *** jaosorior has joined #openstack-barbican | 12:50 | |
| *** jkf has joined #openstack-barbican | 12:57 | |
| *** stevemar_ has joined #openstack-barbican | 13:10 | |
| *** stevemar_ has quit IRC | 13:15 | |
| *** su_zhang has joined #openstack-barbican | 13:21 | |
| *** kfarr has joined #openstack-barbican | 13:31 | |
| jamespage | jaosorior, -dev emailed for FFE | 13:44 |
| jamespage | although this is a bug, not a feature - but I understand the need to communicate it well! | 13:45 |
| jaosorior | jamespage: I did try to explain to one of the infra dudes that this is a bug actually. But he just said it's part of the protocol. So the mail was necessary anyway | 13:47 |
| jaosorior | jamespage: thanks for looking into this | 13:47 |
| jamespage | jaosorior, its fine - mail is low cost :-) | 13:48 |
| jamespage | jaosorior, I think this is the 3rd or 4th lower bounds type bug we've discovered from CI testing of branchs against Ubuntu this cycle | 13:48 |
| jamespage | hopefully that's adding value rather than noise :-) | 13:48 |
| *** michauds has joined #openstack-barbican | 13:52 | |
| *** jmckind has joined #openstack-barbican | 14:03 | |
| jamespage | fyi - https://launchpad.net/ubuntu/+source/barbican/1:3.0.0~b3-0ubuntu1 | 14:03 |
| jamespage | now in ubuntu | 14:03 |
| jamespage | :-) | 14:03 |
| alee | kfarr, ping | 14:05 |
| kfarr | alee pong | 14:05 |
| alee | kfarr, any progress on the volume encryption problem? | 14:05 |
| kfarr | alee, yeah some | 14:05 |
| kfarr | it has to do with oslo config | 14:05 |
| alee | kfarr, ok ...? | 14:07 |
| kfarr | alee, trying to find relevant links | 14:07 |
| kfarr | alee, when https://review.openstack.org/#/c/341914/13/cinder/utils.py added the keymgr import in the utils file, it changed how config opts are loaded | 14:08 |
| kfarr | alee when it creates the key manager in that utils file, it's almost like it uses a config object that hasn't read the options from disk yet | 14:09 |
| *** randallburt has joined #openstack-barbican | 14:10 | |
| kfarr | and so it always tries to override api_class with ConfKeyManager | 14:10 |
| kfarr | alee so I am working on a patch that does the backwards compatibility logic more robustly | 14:10 |
| alee | kfarr, ok | 14:11 |
| *** randallburt1 has joined #openstack-barbican | 14:11 | |
| alee | kfarr, let me know when you have something up | 14:11 |
| kfarr | alee, I'll post updates here, though this isn't the final version: https://review.openstack.org/#/c/366750/ | 14:12 |
| alee | kfarr, ok thanks - I'll keep an eye on it | 14:13 |
| kfarr | alee do you know if there was a bug report opened? otherwise, I'll open one | 14:13 |
| alee | kfarr, I dont think so - so please open one | 14:14 |
| *** randallburt has quit IRC | 14:14 | |
| *** jgrassler has quit IRC | 14:20 | |
| *** su_zhang has quit IRC | 14:20 | |
| *** su_zhang has joined #openstack-barbican | 14:21 | |
| *** spotz_zzz is now known as spotz | 14:24 | |
| *** su_zhang has quit IRC | 14:26 | |
| *** kfarr has quit IRC | 14:40 | |
| *** zz_dimtruck is now known as dimtruck | 14:42 | |
| *** jgrassler has joined #openstack-barbican | 14:44 | |
| arunkant | alee: can you please provide input to multi-backend API docs comments https://review.openstack.org/#/c/341803/ . I will address this accordingly. | 15:16 |
| alee | arunkant, sure - in a meeting right now - but will look afterwards | 15:17 |
| arunkant | alee: thanks | 15:17 |
| arunkant | redrobot, kfarr: KMIP plugin support in newton branch is broken.. check bug https://bugs.launchpad.net/barbican/+bug/1620860 . | 15:22 |
| openstack | Launchpad bug 1620860 in Barbican "KMIP plugin broken in newton branch" [Undecided,New] | 15:22 |
| arunkant | alee: ^^^ this will be issue with dogtag_plugin as well as it has similar key material storage mechanism similar to kmip. | 15:23 |
| *** andreas_s has quit IRC | 15:25 | |
| *** stevemar_ has joined #openstack-barbican | 15:33 | |
| *** stevemar_ has quit IRC | 15:34 | |
| *** su_zhang has joined #openstack-barbican | 15:39 | |
| *** chlong has quit IRC | 15:41 | |
| *** pcaruana has quit IRC | 16:01 | |
| *** su_zhang has quit IRC | 16:02 | |
| *** su_zhang has joined #openstack-barbican | 16:02 | |
| *** DandyPandy has joined #openstack-barbican | 16:02 | |
| *** su_zhang_ has joined #openstack-barbican | 16:06 | |
| *** su_zhang has quit IRC | 16:07 | |
| *** su_zhang_ has quit IRC | 16:07 | |
| *** su_zhang has joined #openstack-barbican | 16:08 | |
| *** su_zhang has quit IRC | 16:08 | |
| *** su_zhang has joined #openstack-barbican | 16:08 | |
| *** su_zhang has quit IRC | 16:09 | |
| *** su_zhang has joined #openstack-barbican | 16:09 | |
| openstackgerrit | Pankaj Khandar proposed openstack/barbican: Remove consumer check for project_id to match containers https://review.openstack.org/251168 | 16:10 |
| *** su_zhang has quit IRC | 16:11 | |
| *** su_zhang has joined #openstack-barbican | 16:11 | |
| *** DandyPandy has left #openstack-barbican | 16:12 | |
| *** DandyPandy has joined #openstack-barbican | 16:15 | |
| *** DandyPandy has left #openstack-barbican | 16:15 | |
| *** su_zhang has quit IRC | 16:16 | |
| *** jaosorior has quit IRC | 16:33 | |
| *** sigmavirus is now known as irvirus | 16:40 | |
| *** irvirus is now known as sigmavirus | 16:40 | |
| *** jmckind_ has joined #openstack-barbican | 17:24 | |
| *** jmckind has quit IRC | 17:27 | |
| *** kfarr has joined #openstack-barbican | 17:33 | |
| kfarr | alee, fix is up https://review.openstack.org/#/c/366750/2 | 17:34 |
| kfarr | alee, I was testing it manually, seems like it solves the problem | 17:35 |
| arunkant | kfarr : ping | 17:36 |
| kfarr | arunkant pong | 17:36 |
| arunkant | kfarr: Looks like kmip plugin support is broken in newton branch.. check this bug ..https://bugs.launchpad.net/barbican/+bug/1620860 | 17:37 |
| openstack | Launchpad bug 1620860 in Barbican "KMIP plugin broken in newton branch" [Undecided,New] | 17:37 |
| kfarr | arunkant, I'm pretty sure I fixed that? let me look into more. You were able to reproduce the issue recently? | 17:38 |
| arunkant | kfarr: Can you please check if you see the similar behavior. | 17:38 |
| arunkant | kfarr: the change is is master branch.. | 17:38 |
| kfarr | arunkant, https://review.openstack.org/#/c/303202/ | 17:39 |
| kfarr | ^^ I thought that fixed it, but maybe I am wrong | 17:39 |
| arunkant | kfarr: Let me check as I was using mitaka branch which has cherry-pick change from newton.. | 17:40 |
| *** su_zhang has joined #openstack-barbican | 17:51 | |
| *** jkf has left #openstack-barbican | 17:53 | |
| arunkant | kfarr: I was able to verify that change successfully for my error case as well. thanks for pointing out the review for correct fix. I have invalidated that bug. | 17:56 |
| alee | kfarr, looking | 17:56 |
| alee | arunkant, I'm fine with the field name as it is | 17:57 |
| alee | redrobot, ^^ | 17:58 |
| arunkant | alee, thanks. | 17:58 |
| redrobot | arunkant alee are we talking about renaming store_plugin to secret_store_plugin? I've been asking for that change since early drafts of the BP. I really would like for the terminology to be consistent... | 18:00 |
| arunkant | redrobot: yes ..this review comment ..https://review.openstack.org/#/c/341803/12/doc/source/api/reference/store_backends.rst | 18:01 |
| arunkant | redrboot: field name is in context of secret-store data so not sure why we need to have prefix with secret here. | 18:02 |
| redrobot | alee arunkant it's a minor change. Not sure why the push back? Anyways, I'd like to see that change before I +2. If other cores want to merge it anyway then go for it. I'll still submit a patch to rename if that happens. | 18:03 |
| alee | arunkant, redrobot I dont have a strong preference either way, but redrobot seems to. | 18:05 |
| arunkant | redrobot: There is no need to do that. I am not convinced myself around the need. I will make the change. | 18:05 |
| redrobot | arunkant cool deal | 18:06 |
| arunkant | redrobot: Do you want me to rename crypto_plugin field in response to be 'secret_crypto_plugin' as well ? | 18:06 |
| redrobot | arunkant no, we call cryptographic plugins just crypto plugins everywhere else | 18:07 |
| arunkant | redrobot: okay..will do that. | 18:07 |
| redrobot | arunkant my concern is with matching docs to the fields. for secret stores we always call them "secret stores" see http://docs.openstack.org/developer/barbican/plugin/secret_store.html | 18:08 |
| redrobot | arunkant for crypto plugins we always call them crypto plugins see http://docs.openstack.org/developer/barbican/plugin/crypto.html | 18:08 |
| arunkant | redrobot: Here names used are individual fields which are used to refer plugin in context of secret stores. I am not sure what else it can mean here. Anyhow, will make the change. | 18:12 |
| alee | kfarr, interesting -- looks like its failing CI | 18:12 |
| kfarr | alee in my experience, the vendor plugin gates are unreliable and most fail | 18:13 |
| alee | kfarr, so they are not gating? | 18:14 |
| alee | or non-voting? | 18:14 |
| kfarr | alee yeah.. | 18:16 |
| openstackgerrit | Arun Kant proposed openstack/barbican: Adding API docs for multiple backend support changes. https://review.openstack.org/341803 | 18:26 |
| *** su_zhang has quit IRC | 18:42 | |
| *** diazjf has joined #openstack-barbican | 18:55 | |
| *** su_zhang has joined #openstack-barbican | 19:13 | |
| *** su_zhang has quit IRC | 19:18 | |
| openstackgerrit | Arun Kant proposed openstack/barbican: Adding functional tests for multiple backend changes (Part 5) https://review.openstack.org/360202 | 19:54 |
| openstackgerrit | Arun Kant proposed openstack/barbican: Central logic to sync secret store data with conf data (Part 3) https://review.openstack.org/357544 | 19:54 |
| openstackgerrit | Arun Kant proposed openstack/barbican: Adding multiple backend db model and repository support (Part 1) https://review.openstack.org/348092 | 19:54 |
| openstackgerrit | Arun Kant proposed openstack/barbican: Adding rest API for secret-stores resource (Part 4) https://review.openstack.org/358162 | 19:54 |
| openstackgerrit | Arun Kant proposed openstack/barbican: Changes for multiple backend conf and friendly plugin names (Part 2) https://review.openstack.org/354285 | 19:54 |
| arunkant | redrobot, alee, _woodster: addressed the issue for API doc review . Can that (https://review.openstack.org/#/c/341803/) be reviewed and possibly merged. | 19:57 |
| *** diazjf has quit IRC | 19:57 | |
| arunkant | alee, woodster_ : ^^^ addressed the comments in multiple backend part 1 review , | 19:58 |
| woodster_ | redrobot: can you review/merge https://review.openstack.org/#/c/341803/ | 20:00 |
| arunkant | woodster_ : For part 2 review comment on line #47 (https://review.openstack.org/#/c/354285/12/barbican/plugin/util/multiple_backends.py), do you prefer it to moved to config module . | 20:03 |
| *** diazjf has joined #openstack-barbican | 20:03 | |
| *** diazjf has quit IRC | 20:04 | |
| *** openstackgerrit has quit IRC | 20:04 | |
| arunkant | woodster_ : I don't have strong preference either way..so will adjust code to whatever is preferred to get +2 .. | 20:04 |
| *** openstackgerrit has joined #openstack-barbican | 20:04 | |
| woodster_ | arunkant: I'm ok with that code staying put, but the camel case var I'd like to see changed...that other change you reference slipped in inadvertently | 20:06 |
| arunkant | woodster_ : Yes..I just noticed that as well..working on addressing it ..will have new patch for that | 20:06 |
| woodster_ | arunkant: alee redrobot kfarr Overall your multiple backends impl seems to be sync db tables with config file settings, which seems a little odd to me, but maybe that's the best way to go for now. Just curious what other folks think though | 20:07 |
| arunkant | woodster_ : I need to capture available plugin configuration for multiple backend case. So I am just reading the conf and applying it to db tables. This is needed so that project specific preference for a secret store can be defined. What's the concern here? | 20:12 |
| woodster_ | arunkant: it's just odd to me to have config in config files, that is then copied into the db, and then the db is used by the the API calls thereafter. Seems like an add way to seed data into the db. I don't think that's enough to halt progress for this release, but might be good to revisit in the future. | 20:14 |
| woodster_ | s/add/odd | 20:14 |
| *** diazjf has joined #openstack-barbican | 20:17 | |
| woodster_ | arunkant: so in other words it seems cleaner to be 100% run the API from info pulled from config files (but have issue with primary key/ref IDs) or 100% from data seeded into the database (but have issue of needing to have an admin script to populate the database). So your approach blends those two sides. Again not a show stopper for this cycle necessarily, | 20:18 |
| woodster_ | but I did want to point that out to other contribs alee diazjf kfarr redrobot ^^^^ | 20:18 |
| arunkant | woodster_ : We already have config properties for referring various plugins available in a deploymemt . Now for multiple backend case, there is just a new structure defined for supported plugins. | 20:18 |
| randallburt1 | arunkant: I'd have to agree with woodster_ though. Why have that information in two places? Seems like you'd list the supported plugins and the default one in the config file and then just record which one is used by a project in the project table or am I missing something. | 20:20 |
| woodster_ | arunkant: before though those config settings were use used programmatically to auto select plugins...so they were read into memory and then used thereafter that way. There wasn't a database representation, or an API that could dynamically change things. | 20:20 |
| *** su_zhang has joined #openstack-barbican | 20:23 | |
| woodster_ | arunkant: not trying to hassle you just to hassle you, rather I think this high level viewpoint will help when other folks are reviewing those code parts. | 20:24 |
| randallburt1 | same. just being nosey really ;) | 20:24 |
| woodster_ | randallburt1: one complicating factor is that each plugin selection needs to have a unique ID associated with them, so they can be manipulated via API later. | 20:25 |
| arunkant | woodster_ : I am trying to understand what you have mentioned...let me share my understanding of this comment. | 20:25 |
| randallburt1 | woodster_: aren't they loaded by stevedore? those plugin names already have to be unique in the namespace | 20:27 |
| arunkant | woodster_ : The preference is either to have API for populating which plugins are available in a deployment ... OR basically seed the secret_store database table via some admin script .. Is that correct? | 20:27 |
| arunkant | randarllburt1 : yes those plugins are loaded via steverdore | 20:28 |
| randallburt1 | woodster_: but I also understand we're trying to get this shoved in before rc, so yeah, if it works, then we can argue db optimization later I suppose. Bad Thing(TM) is that once its in the database, its hard to get it out again later | 20:28 |
| randallburt1 | arunkant: I'd be loath to have an api to populate which plugins are available. That's a very very very operator-centric configuration that should never be changed without much due consideration and testing | 20:29 |
| randallburt1 | arunkant: you'd also want to prevent taking away a plugin that someone is already using | 20:30 |
| woodster_ | randallburt1: well, another complicating factor is that there are two levels of plugins...an outer secret-store layer (KMIP, Dogtab) and an inner layer (the 'crypto' plugins like the HSM and software-only. To use the crypto layer plugins, you need to have a crypto adapter plugin installed at the outer secret-store level. arunkant is allowing us to have these | 20:30 |
| woodster_ | run all the same time...e.g. KMIP plugin, Dogtag plugin, crypto-adapter plugin to HSM, crypto-adapter plugin to software-only | 20:30 |
| arunkant | randallburt1 : Yes, there is a validation added which checks if any of the plugin is already used as preferred secret store when deleted during initialization | 20:31 |
| woodster_ | randallburt1: so each of those has to have a unique ID...that's defined by the db in this implementation | 20:31 |
| randallburt1 | woodster_: yeah, I get that part too | 20:31 |
| randallburt1 | woodster_: I posited earlier that their stevedore plugin name suffices for that IMO | 20:31 |
| woodster_ | randallburt1: I think earlier concerns were that concatenation these stevedore names would be awkward to clients, esp. if we later allow clients to specific per secret, per project which backend to store their secret in. We wanted to treat these various backend options as secret backend 'flavors' essentially | 20:33 |
| * woodster_ flavors with cleansed UUID ref things, instead of a bit awkward setup.cfg names | 20:34 | |
| randallburt1 | woodster_: sure sure, and that's fair. I still think the client and/or a little more config mangling would also do the trick, but I'm not fussed I guess. Really seems awkward though from an operator's perspective and easy enough to get out of sync | 20:36 |
| arunkant | randallburt1: So there is logic which keeps configured plugins (specified in barbican.conf) in sync with related db table data whenever barbican starts.. | 20:38 |
| woodster_ | arunkant: actually, it might be helpful to paste in an example config file that supports the various backend options above. That way folks have an sense of what that looks like before hand. Maybe just add as a comment to the part 1 CR? | 20:38 |
| randallburt1 | woodster_: +1 | 20:38 |
| alee | woodster_, randallburt1 , arunkant -- I understand the issue you're bring up. It is confusing and protentionaly problematic to have the config in two places. | 20:38 |
| *** jmckind_ has quit IRC | 20:39 | |
| alee | what makes this ok-ish for now is that there is no interface to change the plugins other than through the config file | 20:39 |
| woodster_ | alee: I think the config would still be (effectively) in one place as far as operators are concerned. The magic is in the db syncing logic that arunkant has in there. | 20:39 |
| arunkant | woodster_ : Are you looking for line 39-58 in https://review.openstack.org/#/c/341803/13/doc/source/setup/plugin_backends.rst | 20:40 |
| alee | woodster_, right it would be in the config file which gets synced | 20:40 |
| woodster_ | alee: that's true, and the only dynamic elements (project default) are handled via db update and API | 20:40 |
| alee | arunkant, I have not looked at the sync code yet -- but I could see problems possibly arising .. | 20:41 |
| alee | for instance -- what if someone removes a config store -- but some project is still using it ? | 20:41 |
| alee | what happens then? | 20:41 |
| woodster_ | arunkant: cool thanks | 20:41 |
| alee | woodster_, randallburt1 , arunkant -- the advantage of having the secret stores in a db is that you can do checks to ensure consistency -- | 20:43 |
| arunkant | alee, there is logic which does the validation if its in use (line # 912 in https://review.openstack.org/#/c/357544/7/barbican/plugin/util/multiple_backends.py). | 20:43 |
| *** michauds has quit IRC | 20:43 | |
| woodster_ | alee: agreed | 20:44 |
| woodster_ | so has this all gotten an official FFE? | 20:45 |
| woodster_ | I'm thinking this series of CRs, and the lbaas integration one (https://review.openstack.org/#/c/251168/) should try to make Newton | 20:46 |
| arunkant | alee, woodster_ : I will think that people will add backend configuration than removing it . But logic still tries to address that situation | 20:46 |
| woodster_ | arunkant: I think you have some amount of config file change testing in there IIRC | 20:46 |
| arunkant | woodster_ : I did talk to redrobot about FFE 2 weeks before and he mentioned he will allow it and probably file for it if needed. | 20:47 |
| alee | arunkant, so in case of misconfig here - the service will not come up? | 20:48 |
| arunkant | alee: yes | 20:48 |
| alee | arunkant, thats ok for now I guess. to woodster_ point though, we can remove this sync code if the source is in the db only | 20:49 |
| alee | and we have an admin tool to change things | 20:50 |
| alee | that admin tool could check for inconsistencies before adding / removing/ modifying secret stores | 20:50 |
| randallburt1 | alee: how would we bootstrap that configuration? install and then make admin api calls? | 20:51 |
| alee | randallburt1, we could figure something out -- I could write something in puppet or chef or whatever .. we already do things like a dbpsync | 20:52 |
| alee | db-sync | 20:52 |
| alee | randallburt1, keep in mind that this feature is not enabled by default | 20:53 |
| arunkant | alee: We still need to provide a mechanism to specify which plugins are in use by service ..sync keeps it automatic as generally plugin configuration addition requires restart. Having another tool means two separate files to keep in sync | 20:53 |
| randallburt1 | alee: a bit cludgy but if everyone thinks the db is the place to store config then so be it. | 20:53 |
| randallburt1 | alee: fair enough | 20:53 |
| alee | randallburt1, the thing is that you have db tables that use the config. putting the config in db makes consistency checks possible | 20:54 |
| alee | randallburt1, as well as eventally allowing for things like HA / multiple nodes .. | 20:54 |
| alee | arunkant, well after the initial population , the data is in the db | 20:55 |
| alee | arunkant, the tools would be able to list plugins | 20:56 |
| randallburt1 | alee: they're not *impossible* without db config, if it were, you couldn't do that startup check for consistency between the config and db tables. That being said, I'm not going to argue anything on the review given that the folks with the +2 powers are ok with it | 20:56 |
| alee | arunkant, yup -- I'm ok with the approach for now - mostly also because I expect changes in this config to be relatively rare | 20:57 |
| arunkant | alee: I meant if you want to add plugin in multiple backend..there has to be mechanism to add it and same goes for removal case (assuming its not used by any project) | 20:57 |
| alee | arunkant, right - that could be a to-be-developed future tool | 20:59 |
| alee | arunkant, or we could end up just using the config file - and then we use stevedore-uniqueness | 20:59 |
| alee | arunkant, randallburt1 woodster_ if we were to use config file, you could use stevedore uniqueness for the id, and the plugin friendly name for user display | 21:01 |
| alee | what you lose is straightforward db consistency checks | 21:01 |
| alee | which would be the advantage of db | 21:02 |
| arunkant | alee: I think steverdore uniqueness is not sufficient here as the issue is associated with 2 levels of plugins..so mapping is not always 1 to 1 . There is same secret store plugin used for pkcs11 as well as for software-only. Somewhere that combination needs to be defined and can be linked on a per project level | 21:02 |
| alee | arunkant, well sure -- it would be secret_store_plugin_name + crypto_plugin_name | 21:03 |
| alee | arunkant, I'm not advocating this necessarily -- seems like it would be clunky | 21:03 |
| arunkant | alee: yes..something like that but as discussed earlier around concatenating name, its not client friendly and clunky | 21:05 |
| alee | arunkant, well client friendliness can be solved with the plugin friendly name | 21:05 |
| alee | which we had to add in any case | 21:05 |
| alee | anyways I agree with randallburt1 that changing to solely db will be disruptive to operators | 21:06 |
| alee | I think we're stuck with config file | 21:07 |
| arunkant | alee , okay . | 21:07 |
| arunkant | woodster_ : Addressed previously missed comments in part 2 (https://review.openstack.org/#/c/354285/) ..please check | 21:15 |
| *** alee is now known as alee_run | 21:18 | |
| *** spotz is now known as spotz_zzz | 21:29 | |
| *** kfarr has quit IRC | 21:34 | |
| *** su_zhang has quit IRC | 21:37 | |
| *** su_zhang has joined #openstack-barbican | 21:38 | |
| *** su_zhang has quit IRC | 21:38 | |
| *** su_zhang has joined #openstack-barbican | 21:38 | |
| *** spotz_zzz is now known as spotz | 21:38 | |
| *** su_zhang has quit IRC | 22:01 | |
| *** su_zhang has joined #openstack-barbican | 22:05 | |
| *** chlong has joined #openstack-barbican | 22:13 | |
| *** diazjf has quit IRC | 22:20 | |
| *** su_zhang has quit IRC | 22:23 | |
| *** diazjf has joined #openstack-barbican | 22:25 | |
| *** diazjf has quit IRC | 22:25 | |
| *** dimtruck is now known as zz_dimtruck | 22:27 | |
| *** spotz is now known as spotz_zzz | 22:37 | |
| openstackgerrit | ChangBo Guo(gcb) proposed openstack/python-barbicanclient: Handle container list command correctly https://review.openstack.org/264659 | 22:47 |
| *** randallburt1 has quit IRC | 22:48 | |
| *** zz_dimtruck is now known as dimtruck | 22:54 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!