| *** pbourke has quit IRC | 01:17 | |
| *** pbourke has joined #openstack-barbican | 01:18 | |
| *** dave-mccowan has quit IRC | 03:31 | |
| *** phuongnh has joined #openstack-barbican | 03:36 | |
| *** jaosorior has quit IRC | 05:26 | |
| *** Luzi has joined #openstack-barbican | 05:47 | |
| *** jaosorior has joined #openstack-barbican | 06:05 | |
| *** pcaruana has joined #openstack-barbican | 06:36 | |
| *** velizarx has joined #openstack-barbican | 06:56 | |
| *** serlex has joined #openstack-barbican | 07:03 | |
| *** velizarx has quit IRC | 07:13 | |
| *** velizarx has joined #openstack-barbican | 07:24 | |
| *** jaosorior has quit IRC | 07:49 | |
| *** slunkad has quit IRC | 07:58 | |
| *** jaosorior has joined #openstack-barbican | 08:02 | |
| *** dayou has quit IRC | 08:12 | |
| *** sayalilunkad has joined #openstack-barbican | 08:31 | |
| *** salmankhan has joined #openstack-barbican | 08:56 | |
| *** jaosorior has quit IRC | 09:02 | |
| *** velizarx has quit IRC | 09:03 | |
| *** velizarx has joined #openstack-barbican | 09:07 | |
| openstackgerrit | Nguyen Hung Phuong proposed openstack/barbican master: Adding the unit-tests of OVO for Barbican [2] https://review.openstack.org/578337 | 10:40 |
|---|---|---|
| *** dayou has joined #openstack-barbican | 10:42 | |
| *** jaosorior has joined #openstack-barbican | 10:46 | |
| *** velizarx has quit IRC | 10:46 | |
| *** phuongnh has quit IRC | 10:47 | |
| *** dave-mccowan has joined #openstack-barbican | 10:51 | |
| *** velizarx has joined #openstack-barbican | 10:59 | |
| *** abishop has joined #openstack-barbican | 11:44 | |
| *** jaosorior has quit IRC | 11:59 | |
| ade_lee | #startmeeting | 12:00 |
| openstack | ade_lee: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee' | 12:00 |
| ade_lee | #startmeeting barbican | 12:00 |
| openstack | Meeting started Tue Aug 7 12:00:28 2018 UTC and is due to finish in 60 minutes. The chair is ade_lee. Information about MeetBot at http://wiki.debian.org/MeetBot. | 12:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 12:00 |
| openstack | The meeting name has been set to 'barbican' | 12:00 |
| redrobot | o/ | 12:00 |
| ade_lee | #topic roll call | 12:00 |
| ade_lee | hey redrobot | 12:00 |
| redrobot | mornin' ade_lee | 12:00 |
| ade_lee | dave-mccowan, ? | 12:01 |
| ade_lee | anyone else around for barbican meeting? | 12:02 |
| *** raildo has joined #openstack-barbican | 12:02 | |
| *** raildo has quit IRC | 12:03 | |
| ade_lee | we'll wait a minute or so more .. | 12:03 |
| ade_lee | redrobot, looks like its just the two of us today | 12:04 |
| redrobot | heh | 12:04 |
| redrobot | anything on the agenda on your side? | 12:05 |
| ade_lee | #topic rocky | 12:05 |
| ade_lee | just rocky release | 12:05 |
| ade_lee | this is rc1 prep week | 12:05 |
| redrobot | when is RC1 due? | 12:05 |
| ade_lee | supposed to cut an rc1 release by the end of the week | 12:05 |
| redrobot | o_O | 12:05 |
| ade_lee | https://releases.openstack.org/rocky/schedule.html | 12:05 |
| ade_lee | which means we have a bunch of stuff we need to get reviewed and in by the end of the week | 12:06 |
| *** raildo has joined #openstack-barbican | 12:06 | |
| ade_lee | the ideal situation would be to have most things in by the end of the week | 12:06 |
| redrobot | ack, I'll get some review time scheduled in for sure. | 12:07 |
| ade_lee | I've been looking at https://tinyurl.com/yctfozgh | 12:07 |
| *** raildo has quit IRC | 12:07 | |
| ade_lee | to keep tracvk of things, but I think we're going to need either a trello board or etherpad to getth emost important things in there. | 12:08 |
| ade_lee | but -- the most important things I can see are ;; | 12:08 |
| ade_lee | https://review.openstack.org/575800 | 12:08 |
| ade_lee | all the ovo patches | 12:08 |
| ade_lee | maybe the patch you are working on redrobot to parmeterze a lot of the pkcs11 parameters | 12:10 |
| ade_lee | and maybe https://review.openstack.org/588104 | 12:10 |
| ade_lee | there are a few random other ones - but those seem to be ones we most want to get in | 12:11 |
| ade_lee | redrobot, any others you want to call out? | 12:11 |
| redrobot | the one I'll be posting today/tomorrow ... :D | 12:12 |
| ade_lee | yup - I mentioned that :) | 12:12 |
| ade_lee | ok -- thats the most important thing right now. | 12:13 |
| ade_lee | I dont have anything else on the agenda | 12:13 |
| ade_lee | I 'll send the etherpad link to redrobot dave-mccowan and jaosorior later today | 12:14 |
| redrobot | cool | 12:14 |
| ade_lee | anything else? | 12:14 |
| redrobot | Just thinking about algorithm compatibility for PKCS#11 | 12:14 |
| ade_lee | #topic anything else? | 12:14 |
| redrobot | I really need to look at OVO, to see if that's good enough to version encrypted secrets | 12:14 |
| *** raildo has joined #openstack-barbican | 12:15 | |
| redrobot | we'll likely need additional metadata to ensure we're using the correct algorithm for decryption | 12:15 |
| redrobot | my use case is someone who changes algorithms and already had some previously encrypted data in the db | 12:15 |
| ade_lee | really? wont that just depend on the plugin? | 12:15 |
| redrobot | hmm... well kinda | 12:16 |
| redrobot | I'm not even sure that use case is a realistic one | 12:16 |
| ade_lee | redrobot, they could always define another plugin -- remember we have multiple plugin support | 12:16 |
| redrobot | can we have 2 instances of PKCS#11 plugin? | 12:16 |
| redrobot | or N instances | 12:16 |
| ade_lee | that I'm not sure about .. | 12:17 |
| ade_lee | but we do have plugin metadata | 12:17 |
| redrobot | So let's say someone has an HSM that only supports CKM_AES_CBC... but then like next year their vendor adds CKM_AES_GCM support... then they want to start using that for Barbican because it's better/faster. | 12:18 |
| ade_lee | that is a metadata object that is written by the plugin to include all the details it needs to retrieve and decrypt a secret | 12:18 |
| *** jaosorior has joined #openstack-barbican | 12:18 | |
| ade_lee | well - what we could do is have the pkcs11 plugin write the algorithm used in the plugin metadata for the secret | 12:19 |
| ade_lee | if its there on retrieval, then we use that to decrypt. if not, then we assume some value | 12:19 |
| redrobot | yeah, that's what I was thinking that we'd need more metadata... I'll look into the plugin metadata, I think that may be sufficient. | 12:19 |
| * redrobot really hopes for not having to do a migration | 12:19 | |
| ade_lee | redrobot, I don't think we need more tables / fields | 12:20 |
| redrobot | good | 12:20 |
| ade_lee | metadata should be sufficient | 12:20 |
| ade_lee | (thats why we put it there :)) | 12:20 |
| redrobot | it's been a while... ;-P | 12:20 |
| ade_lee | ack :) | 12:21 |
| ade_lee | ok - anything else? | 12:21 |
| redrobot | that's all I've got | 12:21 |
| ade_lee | cool --- laters1 | 12:21 |
| redrobot | peace out! | 12:21 |
| ade_lee | #endmeeting | 12:21 |
| openstack | Meeting ended Tue Aug 7 12:21:49 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 12:21 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/barbican/2018/barbican.2018-08-07-12.00.html | 12:21 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/barbican/2018/barbican.2018-08-07-12.00.txt | 12:21 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/barbican/2018/barbican.2018-08-07-12.00.log.html | 12:21 |
| *** jaosorior has quit IRC | 12:27 | |
| *** velizarx has quit IRC | 12:34 | |
| *** velizarx has joined #openstack-barbican | 12:35 | |
| *** jaosorior has joined #openstack-barbican | 12:42 | |
| *** sapcc-bot3 has joined #openstack-barbican | 12:46 | |
| *** d063130_ has quit IRC | 12:50 | |
| *** sapcc-bot has quit IRC | 12:50 | |
| *** ade_lee has quit IRC | 13:13 | |
| *** velizarx has quit IRC | 13:16 | |
| *** velizarx has joined #openstack-barbican | 13:16 | |
| *** namnh has joined #openstack-barbican | 13:27 | |
| *** serlex has quit IRC | 13:37 | |
| *** ade_lee has joined #openstack-barbican | 14:02 | |
| namnh | ade_lee: Hi Ade, are you around? | 14:34 |
| ade_lee | namnh, hey | 14:34 |
| ade_lee | namnh, I was hoping to run into you .. | 14:34 |
| ade_lee | namnh, so how are things on the ovo patches? | 14:34 |
| namnh | ade_lee: yeah, sorry for no updating OVO recently time. | 14:35 |
| ade_lee | namnh, this week is rc1 time, so we're getting to crunch time | 14:36 |
| ade_lee | if we're going to make it in | 14:36 |
| ade_lee | as far as I can tell, the patches to add the ovo objects have been merged, and there are patches to add unit tests that are in review | 14:37 |
| ade_lee | there is also a patch to change some stuff in barbican-manage to make it multi-step | 14:37 |
| ade_lee | what else is missing/ coming? | 14:37 |
| namnh | yes, I understand the situation for now. | 14:39 |
| namnh | at two week ago, I told with Dave about a thing, can you check it http://eavesdrop.openstack.org/irclogs/%23openstack-barbican/%23openstack-barbican.2018-07-17.log.html#t2018-07-17T12:20:08 | 14:39 |
| namnh | so, i would like to hear your option about this. | 14:40 |
| ade_lee | namnh, so if I understand your argument correctly, we can claim rolling upgrade because there are no db changes from P-> R? | 14:42 |
| namnh | ade_lee: yes | 14:43 |
| ade_lee | namnh, but more likely than not, there will be db changes needed for R->S | 14:43 |
| ade_lee | namnh, to account for this -- for instance -- https://review.openstack.org/586606 | 14:43 |
| ade_lee | and another change to allow changing owership of secrets | 14:44 |
| ade_lee | so while it would have been great to get ovo in for rocky, it becomes really important to get it in in early stein | 14:45 |
| ade_lee | so we can get these other features in | 14:45 |
| ade_lee | namnh, I think I agree with dave-mccowan that its premature to ask for the rolling-upgrade flag without ovo | 14:46 |
| ade_lee | dave-mccowan, redrobot ^^? | 14:47 |
| *** FrankZhang has joined #openstack-barbican | 14:51 | |
| *** jaosorior has quit IRC | 15:01 | |
| dave-mccowan | ade_lee namnh something else we'll need before applying for the tag is documentation on how to do a rolling upgrade. | 15:04 |
| dave-mccowan | here's cinder's doc: https://docs.openstack.org/cinder/latest/upgrade.html | 15:04 |
| dave-mccowan | we can write something similar | 15:04 |
| dave-mccowan | only 6 projects so far have gotten tagged for rolling upgrades | 15:04 |
| *** Luzi has quit IRC | 15:07 | |
| *** pcaruana has quit IRC | 15:11 | |
| namnh | ade_lee: yeah, i understood | 15:12 |
| *** v1k0d3n has joined #openstack-barbican | 15:44 | |
| ade_lee | lxkong, ping | 16:03 |
| *** namnh has quit IRC | 16:10 | |
| ade_lee | redrobot, dave-mccowan , https://trello.com/invite/b/P3TfeidC/01defd8a60aabec795d1381d3ee656a4/barbican-rocky-work | 16:29 |
| ade_lee | redrobot, dave-mccowan we've got a few days -- lets see if we can get all the reviews in that trello through to done! | 16:29 |
| ade_lee | redrobot, dave-mccowan let me know if anything does not make sense on the board -- and feel free to add stuff as needed | 16:31 |
| *** velizarx has quit IRC | 16:47 | |
| *** salmankhan has quit IRC | 16:48 | |
| *** ThomasWhite has quit IRC | 17:15 | |
| *** openstackgerrit has quit IRC | 18:49 | |
| rm_work | ade_lee / redrobot: ah missed the meeting by a bit, but -- for https://review.openstack.org/#/c/588104/ i think i need to do the same for containers still -- and are you ok with the default being "disabled" (a change)? | 19:15 |
| rm_work | any other comments on that patch, at a high level? does it make sense as-implemented? | 19:15 |
| rm_work | dave-mccowan: ^^ also | 19:15 |
| rm_work | I say "a change", but ... it has been pointed out that federation isn't something that ever actually worked fully? so ... the "change" would just be that we'd be choosing in the client to essentially ignore anything but the UUID in the href | 19:16 |
| rm_work | with the ability to force the href to be honored if so chosen | 19:17 |
| rm_work | and does that also require a CLI flag? | 19:17 |
| rm_work | need to know fairly soon what direction to go / if i should try to get all of that done -- otherwise will be out of time | 19:18 |
| ade_lee | rm_work, ack - reading patch now .. | 19:19 |
| *** raildo has quit IRC | 20:02 | |
| ade_lee | rm_work, ping | 20:02 |
| rm_work | pong | 20:05 |
| ade_lee | rm_work, so was talking with redrobot about your patch. | 20:06 |
| *** raildo has joined #openstack-barbican | 20:07 | |
| rm_work | uh-oh | 20:07 |
| rm_work | ;) | 20:07 |
| ade_lee | so if I understand it correctly, this whole problem comes about because we decided to use complete hrefs instead of uuids like the rest of the projects | 20:07 |
| ade_lee | because we thought at some point of having "barbican federation" | 20:08 |
| ade_lee | though barbican federation is not really a thing | 20:08 |
| rm_work | correct | 20:08 |
| rm_work | the essence of what i was doing in that patch is ... just treating a ref that comes in as a UUID :P | 20:09 |
| ade_lee | so -- it seems like the cleanest ultimate solution would be to allow the client to accept a UUID | 20:09 |
| rm_work | maybe? | 20:09 |
| redrobot | I agree with ade_lee. I don't think the option to set federation=whatever is necessary | 20:09 |
| redrobot | since it doesn't exist | 20:10 |
| rm_work | but really the whole system needs to be changed to use that | 20:10 |
| rm_work | ok so | 20:10 |
| ade_lee | we could have logic like -- get (thing) --> if thing looks like href, go to href, if uuid go to uuid | 20:10 |
| rm_work | in the short term though | 20:10 |
| rm_work | service clients are using data passed in by users which is in HREF form | 20:10 |
| rm_work | so either the services all have to do a stripping of the UUID out of the href | 20:10 |
| ade_lee | ack -- I realize that would require changes in all the other services | 20:10 |
| rm_work | or... we need to do it in the client short term | 20:10 |
| rm_work | personally I vote client :P | 20:11 |
| redrobot | same | 20:11 |
| ade_lee | I think thats a reasonable argument | 20:11 |
| rm_work | which is where my patch comes in | 20:11 |
| rm_work | so you're just saying ... remove the option | 20:11 |
| rm_work | and have it do it ALWAYS | 20:11 |
| ade_lee | the question is -- are we going to break anyone if we change the behavior? | 20:12 |
| rm_work | right | 20:12 |
| rm_work | that was pretty much exactly my question | 20:12 |
| ade_lee | I have no idea how to even answer that | 20:12 |
| ade_lee | that said - we know folks are broken now without the change | 20:13 |
| redrobot | get("http...") -> then check keystone for a keymanager url, if it's there strip the host and use the keystone service index otherwise do a get on that host. I think that may only break for folks who have a bad service catalog entry? | 20:14 |
| rm_work | hmmm | 20:14 |
| rm_work | ok so, one extra call to verify that we have somewhere to go first | 20:14 |
| redrobot | which we could do once when the client is initialized | 20:14 |
| rm_work | which, sure, if people were using barbican outside of the service catalog (is that a thing?) then this could break them otherwise | 20:14 |
| redrobot | I don't think the catalog changes too often? | 20:14 |
| rm_work | well | 20:14 |
| rm_work | right | 20:15 |
| rm_work | and this isn't a service, it's a client | 20:15 |
| rm_work | so even long-lived clients would be ... short-ish | 20:15 |
| rm_work | well i guess that's not true if someone has a barbican client singleton in their service :P | 20:15 |
| rm_work | still i don't think they change much | 20:16 |
| ade_lee | redrobot, we need a story to clean up the url/ uuid thing | 20:16 |
| ade_lee | redrobot, lets get thta fixed for stein | 20:17 |
| redrobot | ade_lee, we have one for the client ... let me find it | 20:17 |
| ade_lee | and then services can start using that | 20:17 |
| redrobot | https://storyboard.openstack.org/#!/story/2002754 | 20:18 |
| ade_lee | rm_work, incidentally -- I'm not too keen on you multi-purposing the validate function to get the uuid -- just make a new function to get it | 20:18 |
| rm_work | i checked to see where it was used | 20:19 |
| rm_work | there's nowhere that would cause a problem... | 20:19 |
| rm_work | seems non-DRY | 20:19 |
| ade_lee | rm_work, seems confusing | 20:19 |
| rm_work | well | 20:19 |
| ade_lee | validate() sometimes returns true , sometimes returns uuid | 20:20 |
| *** openstackgerrit has joined #openstack-barbican | 20:20 | |
| openstackgerrit | Doug Hellmann proposed openstack/castellan master: import zuul job settings from project-config https://review.openstack.org/588682 | 20:20 |
| openstackgerrit | Doug Hellmann proposed openstack/castellan master: add python 3.6 unit test job https://review.openstack.org/589587 | 20:20 |
| rm_work | after my change it only ever returns UUID | 20:20 |
| rm_work | how could it return "True"? | 20:20 |
| rm_work | it's "UUID" or Raise | 20:20 |
| redrobot | for the API, I started adding "secret_id" in addition to "secret_ref" properties a long time ago, but I have no idea what the status is... they may not have ever gotten merged. | 20:20 |
| ade_lee | then lets call it get_uuid() :) | 20:20 |
| rm_work | s/validate_ref/validate_ref_and_return_uuid/ | 20:20 |
| ade_lee | sure | 20:21 |
| * redrobot seems to have gone on a tangent | 20:21 | |
| * ade_lee agrees redrobot on a tangent | 20:21 | |
| ade_lee | so -- we agreed on how to move forward? | 20:22 |
| rm_work | umm | 20:23 |
| rm_work | i need to do this for all types, right? | 20:23 |
| rm_work | i am looking at doing it at a lower level | 20:23 |
| rm_work | like, in the _request function or something | 20:23 |
| ade_lee | eh? you mean for secrets and containers? | 20:24 |
| rm_work | yes | 20:25 |
| ade_lee | seems like it yes | 20:26 |
| *** raildo has quit IRC | 20:28 | |
| ade_lee | rm_work, redrobot I'm inclined to the simpler solution of doing the uuuid all the time -- catalogs dont change often, but when they do, there will likely be issues | 20:29 |
| ade_lee | that will be tricky to diagnose | 20:30 |
| ade_lee | rm_work, by the way, dont forget to add a release note | 20:30 |
| rm_work | ah right yes | 20:30 |
| redrobot | I think as long as we LOG.Info the entity we're getting then it should be easy to troubleshoot when things go awry? | 20:31 |
| rm_work | ade_lee: well, i take his point that it's POSSIBLE someone *could* be relying on their own barbican that is not technically linked in the service catalog? | 20:31 |
| rm_work | which would break that use-case | 20:31 |
| rm_work | but maybe that is a stretch lol | 20:31 |
| ade_lee | rm_work, redrobot ok - fair enough - the suggested solution seems to minimize the possible harm | 20:32 |
| ade_lee | and we can get UUID support in early stein | 20:33 |
| ade_lee | so the other services can use it | 20:33 |
| -openstackstatus- NOTICE: Due to a bug, Zuul has been unable to report on cherry-picked changes over the last 24 hours. This has now been fixed; if you encounter a cherry-picked change missing its results (or was unable to merge), please recheck now. | 20:41 | |
| rm_work | haha | 21:05 |
| *** FrankZhang has quit IRC | 21:05 | |
| rm_work | consumers already do this | 21:05 |
| rm_work | href = '{0}/{1}/consumers'.format(self._entity, container_ref.split('/')[-1]) | 21:05 |
| *** abishop has quit IRC | 21:31 | |
| rm_work | soooo many tests >_< | 21:42 |
| *** ade_lee has quit IRC | 22:00 | |
| *** strigazi has joined #openstack-barbican | 22:20 | |
| *** strigazi has quit IRC | 22:21 | |
| *** strigazi has joined #openstack-barbican | 22:21 | |
| *** strigazi has quit IRC | 22:27 | |
| *** strigazi has joined #openstack-barbican | 22:28 | |
| *** strigazi has quit IRC | 22:28 | |
| *** strigazi has joined #openstack-barbican | 22:29 | |
| *** strigazi has quit IRC | 22:32 | |
| *** strigazi has joined #openstack-barbican | 22:33 | |
| rm_work | redrobot: do I need to do the ACL endpoint too? | 23:17 |
| rm_work | got secrets/containers/orders | 23:17 |
| rm_work | it looks like i probably do | 23:17 |
| rm_work | will submit this for now and get to the ACL stuff tomorrow | 23:17 |
| openstackgerrit | Adam Harwell proposed openstack/python-barbicanclient master: Allow fetching by UUID, and respect interface https://review.openstack.org/588104 | 23:36 |
| openstackgerrit | Adam Harwell proposed openstack/python-barbicanclient master: Allow fetching by UUID, and respect interface https://review.openstack.org/588104 | 23:47 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!