Tuesday, 2018-08-07

*** pbourke has quit IRC01:17
*** pbourke has joined #openstack-barbican01:18
*** dave-mccowan has quit IRC03:31
*** phuongnh has joined #openstack-barbican03:36
*** jaosorior has quit IRC05:26
*** Luzi has joined #openstack-barbican05:47
*** jaosorior has joined #openstack-barbican06:05
*** pcaruana has joined #openstack-barbican06:36
*** velizarx has joined #openstack-barbican06:56
*** serlex has joined #openstack-barbican07:03
*** velizarx has quit IRC07:13
*** velizarx has joined #openstack-barbican07:24
*** jaosorior has quit IRC07:49
*** slunkad has quit IRC07:58
*** jaosorior has joined #openstack-barbican08:02
*** dayou has quit IRC08:12
*** sayalilunkad has joined #openstack-barbican08:31
*** salmankhan has joined #openstack-barbican08:56
*** jaosorior has quit IRC09:02
*** velizarx has quit IRC09:03
*** velizarx has joined #openstack-barbican09:07
openstackgerritNguyen Hung Phuong proposed openstack/barbican master: Adding the unit-tests of OVO for Barbican [2]  https://review.openstack.org/57833710:40
*** dayou has joined #openstack-barbican10:42
*** jaosorior has joined #openstack-barbican10:46
*** velizarx has quit IRC10:46
*** phuongnh has quit IRC10:47
*** dave-mccowan has joined #openstack-barbican10:51
*** velizarx has joined #openstack-barbican10:59
*** abishop has joined #openstack-barbican11:44
*** jaosorior has quit IRC11:59
ade_lee#startmeeting12:00
openstackade_lee: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee'12:00
ade_lee#startmeeting barbican12:00
openstackMeeting 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
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.12:00
openstackThe meeting name has been set to 'barbican'12:00
redroboto/12:00
ade_lee#topic roll call12:00
ade_leehey redrobot12:00
redrobotmornin' ade_lee12:00
ade_leedave-mccowan, ?12:01
ade_leeanyone else around for barbican meeting?12:02
*** raildo has joined #openstack-barbican12:02
*** raildo has quit IRC12:03
ade_leewe'll wait a minute or so more ..12:03
ade_leeredrobot, looks like its just the two of us today12:04
redrobotheh12:04
redrobotanything on the agenda on your side?12:05
ade_lee#topic rocky12:05
ade_leejust rocky release12:05
ade_leethis is rc1 prep week12:05
redrobotwhen is RC1 due?12:05
ade_leesupposed to cut an rc1 release by the end of the week12:05
redroboto_O12:05
ade_leehttps://releases.openstack.org/rocky/schedule.html12:05
ade_leewhich means we have a bunch of stuff we need to get reviewed and in by the end of the week12:06
*** raildo has joined #openstack-barbican12:06
ade_leethe ideal situation would be to have most things in by the end of the week12:06
redrobotack, I'll get some review time scheduled in for sure.12:07
ade_leeI've been looking at https://tinyurl.com/yctfozgh12:07
*** raildo has quit IRC12:07
ade_leeto 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_leebut -- the most important things I can see are ;;12:08
ade_leehttps://review.openstack.org/57580012:08
ade_leeall the ovo patches12:08
ade_leemaybe the patch you are working on redrobot to parmeterze a lot of the pkcs11 parameters12:10
ade_leeand maybe https://review.openstack.org/58810412:10
ade_leethere are a few random other ones - but those seem to be ones we most want to get in12:11
ade_leeredrobot, any others you want to call out?12:11
redrobotthe one I'll be posting today/tomorrow ... :D12:12
ade_leeyup - I mentioned that :)12:12
ade_leeok -- thats the most important thing right now.12:13
ade_leeI dont have anything else on the agenda12:13
ade_leeI 'll send the etherpad link to redrobot dave-mccowan and jaosorior later today12:14
redrobotcool12:14
ade_leeanything else?12:14
redrobotJust thinking about algorithm compatibility for PKCS#1112:14
ade_lee#topic anything else?12:14
redrobotI really need to look at OVO, to see if that's good enough to version encrypted secrets12:14
*** raildo has joined #openstack-barbican12:15
redrobotwe'll likely need additional metadata to ensure we're using the correct algorithm for decryption12:15
redrobotmy use case is someone who changes algorithms and already had some previously encrypted data in the db12:15
ade_leereally?  wont that just depend on the plugin?12:15
redrobothmm... well kinda12:16
redrobotI'm not even sure that use case is a realistic one12:16
ade_leeredrobot, they could always define another plugin -- remember we have multiple plugin support12:16
redrobotcan we have 2 instances of PKCS#11 plugin?12:16
redrobotor N instances12:16
ade_leethat I'm not sure about ..12:17
ade_leebut we do have plugin metadata12:17
redrobotSo 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_leethat is a metadata object that is written by the plugin to include all the details it needs to retrieve and decrypt a secret12:18
*** jaosorior has joined #openstack-barbican12:18
ade_leewell - what we could do is have the pkcs11 plugin write the algorithm used in the plugin metadata for the secret12:19
ade_leeif its there on retrieval, then we use that to decrypt.  if not, then we assume some value12:19
redrobotyeah, 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 migration12:19
ade_leeredrobot, I don't think we need more tables / fields12:20
redrobotgood12:20
ade_leemetadata should be sufficient12:20
ade_lee(thats why we put it there :))12:20
redrobotit's been a while... ;-P12:20
ade_leeack :)12:21
ade_leeok - anything else?12:21
redrobotthat's all I've got12:21
ade_leecool --- laters112:21
redrobotpeace out!12:21
ade_lee#endmeeting12:21
openstackMeeting ended Tue Aug  7 12:21:49 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)12:21
openstackMinutes:        http://eavesdrop.openstack.org/meetings/barbican/2018/barbican.2018-08-07-12.00.html12:21
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/barbican/2018/barbican.2018-08-07-12.00.txt12:21
openstackLog:            http://eavesdrop.openstack.org/meetings/barbican/2018/barbican.2018-08-07-12.00.log.html12:21
*** jaosorior has quit IRC12:27
*** velizarx has quit IRC12:34
*** velizarx has joined #openstack-barbican12:35
*** jaosorior has joined #openstack-barbican12:42
*** sapcc-bot3 has joined #openstack-barbican12:46
*** d063130_ has quit IRC12:50
*** sapcc-bot has quit IRC12:50
*** ade_lee has quit IRC13:13
*** velizarx has quit IRC13:16
*** velizarx has joined #openstack-barbican13:16
*** namnh has joined #openstack-barbican13:27
*** serlex has quit IRC13:37
*** ade_lee has joined #openstack-barbican14:02
namnhade_lee: Hi Ade, are you around?14:34
ade_leenamnh, hey14:34
ade_leenamnh, I was hoping to run into you ..14:34
ade_leenamnh, so how are things on the ovo patches?14:34
namnhade_lee: yeah, sorry for no updating OVO recently time.14:35
ade_leenamnh, this week is rc1 time, so we're getting to crunch time14:36
ade_leeif we're going to make it in14:36
ade_leeas 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 review14:37
ade_leethere is also a patch to change some stuff in barbican-manage to make it multi-step14:37
ade_leewhat else is missing/ coming?14:37
namnhyes, I understand the situation for now.14:39
namnhat 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:0814:39
namnhso, i would like to hear your option about this.14:40
ade_leenamnh, so if I understand your argument correctly, we can claim rolling upgrade because there are no db changes from P-> R?14:42
namnhade_lee: yes14:43
ade_leenamnh, but more likely than not, there will be db changes needed for R->S14:43
ade_leenamnh, to account for this -- for instance -- https://review.openstack.org/58660614:43
ade_leeand another change to allow changing owership of secrets14:44
ade_leeso while it would have been great to get ovo in for rocky, it becomes really important to get it in in early stein14:45
ade_leeso we can get these other features in14:45
ade_leenamnh, I think I agree with dave-mccowan that its premature to ask for the rolling-upgrade flag without ovo14:46
ade_leedave-mccowan, redrobot ^^?14:47
*** FrankZhang has joined #openstack-barbican14:51
*** jaosorior has quit IRC15:01
dave-mccowanade_lee namnh something else we'll need before applying for the tag is documentation on how to do a rolling upgrade.15:04
dave-mccowanhere's cinder's doc: https://docs.openstack.org/cinder/latest/upgrade.html15:04
dave-mccowanwe can write something similar15:04
dave-mccowanonly 6 projects so far have gotten tagged for rolling upgrades15:04
*** Luzi has quit IRC15:07
*** pcaruana has quit IRC15:11
namnhade_lee: yeah, i understood15:12
*** v1k0d3n has joined #openstack-barbican15:44
ade_leelxkong, ping16:03
*** namnh has quit IRC16:10
ade_leeredrobot, dave-mccowan , https://trello.com/invite/b/P3TfeidC/01defd8a60aabec795d1381d3ee656a4/barbican-rocky-work16:29
ade_leeredrobot, 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_leeredrobot, dave-mccowan let me know if anything does not make sense on the board -- and feel free to add stuff as needed16:31
*** velizarx has quit IRC16:47
*** salmankhan has quit IRC16:48
*** ThomasWhite has quit IRC17:15
*** openstackgerrit has quit IRC18:49
rm_workade_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_workany other comments on that patch, at a high level? does it make sense as-implemented?19:15
rm_workdave-mccowan: ^^ also19:15
rm_workI 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 href19:16
rm_workwith the ability to force the href to be honored if so chosen19:17
rm_workand does that also require a CLI flag?19:17
rm_workneed to know fairly soon what direction to go / if i should try to get all of that done -- otherwise will be out of time19:18
ade_leerm_work, ack - reading patch now ..19:19
*** raildo has quit IRC20:02
ade_leerm_work, ping20:02
rm_workpong20:05
ade_leerm_work, so was talking with redrobot about your patch.20:06
*** raildo has joined #openstack-barbican20:07
rm_workuh-oh20:07
rm_work;)20:07
ade_leeso 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 projects20:07
ade_leebecause we thought at some point of having "barbican federation"20:08
ade_leethough barbican federation is not really a thing20:08
rm_workcorrect20:08
rm_workthe essence of what i was doing in that patch is ... just treating a ref that comes in as a UUID :P20:09
ade_leeso -- it seems like the cleanest ultimate solution would be to allow the client to accept a UUID20:09
rm_workmaybe?20:09
redrobotI agree with ade_lee.  I don't think the option to set federation=whatever is necessary20:09
redrobotsince it doesn't exist20:10
rm_workbut really the whole system needs to be changed to use that20:10
rm_workok so20:10
ade_leewe could have logic like -- get (thing) --> if thing looks like href, go to href, if uuid go to uuid20:10
rm_workin the short term though20:10
rm_workservice clients are using data passed in by users which is in HREF form20:10
rm_workso either the services all have to do a stripping of the UUID out of the href20:10
ade_leeack -- I realize that would require changes in all the other services20:10
rm_workor... we need to do it in the client short term20:10
rm_workpersonally I vote client :P20:11
redrobotsame20:11
ade_leeI think thats a reasonable argument20:11
rm_workwhich is where my patch comes in20:11
rm_workso you're just saying ... remove the option20:11
rm_workand have it do it ALWAYS20:11
ade_leethe question is -- are we going to break anyone if we change the behavior?20:12
rm_workright20:12
rm_workthat was pretty much exactly my question20:12
ade_leeI have no idea how to even answer that20:12
ade_leethat said - we know folks are broken now without the change20:13
redrobotget("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_workhmmm20:14
rm_workok so, one extra call to verify that we have somewhere to go first20:14
redrobotwhich we could do once when the client is initialized20:14
rm_workwhich, sure, if people were using barbican outside of the service catalog (is that a thing?) then this could break them otherwise20:14
redrobotI don't think the catalog changes too often?20:14
rm_workwell20:14
rm_workright20:15
rm_workand this isn't a service, it's a client20:15
rm_workso even long-lived clients would be ... short-ish20:15
rm_workwell i guess that's not true if someone has a barbican client singleton in their service :P20:15
rm_workstill i don't think they change much20:16
ade_leeredrobot, we need a story to clean up the url/ uuid thing20:16
ade_leeredrobot, lets get thta fixed for stein20:17
redrobotade_lee, we have one for the client ... let me find it20:17
ade_leeand then services can start using that20:17
redrobothttps://storyboard.openstack.org/#!/story/200275420:18
ade_leerm_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 it20:18
rm_worki checked to see where it was used20:19
rm_workthere's nowhere that would cause a problem...20:19
rm_workseems non-DRY20:19
ade_leerm_work, seems confusing20:19
rm_workwell20:19
ade_leevalidate() sometimes returns true , sometimes returns uuid20:20
*** openstackgerrit has joined #openstack-barbican20:20
openstackgerritDoug Hellmann proposed openstack/castellan master: import zuul job settings from project-config  https://review.openstack.org/58868220:20
openstackgerritDoug Hellmann proposed openstack/castellan master: add python 3.6 unit test job  https://review.openstack.org/58958720:20
rm_workafter my change it only ever returns UUID20:20
rm_workhow could it return "True"?20:20
rm_workit's "UUID" or Raise20:20
redrobotfor 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_leethen lets call it get_uuid() :)20:20
rm_works/validate_ref/validate_ref_and_return_uuid/20:20
ade_leesure20:21
* redrobot seems to have gone on a tangent20:21
* ade_lee agrees redrobot on a tangent20:21
ade_leeso -- we agreed on how to move forward?20:22
rm_workumm20:23
rm_worki need to do this for all types, right?20:23
rm_worki am looking at doing it at a lower level20:23
rm_worklike, in the _request function or something20:23
ade_leeeh?  you mean for secrets and containers?20:24
rm_workyes20:25
ade_leeseems like it yes20:26
*** raildo has quit IRC20:28
ade_leerm_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 issues20:29
ade_leethat will be tricky to diagnose20:30
ade_leerm_work, by the way, dont forget to add a release note20:30
rm_workah right yes20:30
redrobotI 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_workade_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_workwhich would break that use-case20:31
rm_workbut maybe that is a stretch lol20:31
ade_leerm_work, redrobot ok - fair enough - the suggested solution seems to minimize the possible harm20:32
ade_leeand we can get UUID support in early stein20:33
ade_leeso the other services can use it20: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_workhaha21:05
*** FrankZhang has quit IRC21:05
rm_workconsumers already do this21:05
rm_workhref = '{0}/{1}/consumers'.format(self._entity, container_ref.split('/')[-1])21:05
*** abishop has quit IRC21:31
rm_worksoooo many tests >_<21:42
*** ade_lee has quit IRC22:00
*** strigazi has joined #openstack-barbican22:20
*** strigazi has quit IRC22:21
*** strigazi has joined #openstack-barbican22:21
*** strigazi has quit IRC22:27
*** strigazi has joined #openstack-barbican22:28
*** strigazi has quit IRC22:28
*** strigazi has joined #openstack-barbican22:29
*** strigazi has quit IRC22:32
*** strigazi has joined #openstack-barbican22:33
rm_workredrobot: do I need to do the ACL endpoint too?23:17
rm_workgot secrets/containers/orders23:17
rm_workit looks like i probably do23:17
rm_workwill submit this for now and get to the ACL stuff tomorrow23:17
openstackgerritAdam Harwell proposed openstack/python-barbicanclient master: Allow fetching by UUID, and respect interface  https://review.openstack.org/58810423:36
openstackgerritAdam Harwell proposed openstack/python-barbicanclient master: Allow fetching by UUID, and respect interface  https://review.openstack.org/58810423:47

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!