Thursday, 2015-05-28

*** rellerreller has quit IRC00:36
*** kfox1111 has quit IRC00:47
*** SheenaG has joined #openstack-barbican01:04
*** gyee has quit IRC01:07
*** dave-mccowan has joined #openstack-barbican01:15
elmikowoodster_: hey, yea alee is heading things up. i'm just providing a little backup and testing01:20
woodster_elmiko: that's cool thanks01:22
*** SheenaG has quit IRC01:33
*** SheenaG has joined #openstack-barbican01:51
*** zz_dimtruck is now known as dimtruck01:55
*** SheenaG has quit IRC02:33
*** dimtruck is now known as zz_dimtruck03:24
*** woodster_ has quit IRC03:40
*** dave-mccowan has quit IRC04:03
*** kebray_ has joined #openstack-barbican04:35
*** kebray has quit IRC04:39
*** openstackgerrit has quit IRC04:50
*** openstackgerrit has joined #openstack-barbican04:50
*** epequeno has quit IRC05:04
openstackgerritOpenStack Proposal Bot proposed openstack/barbican: Imported Translations from Transifex  https://review.openstack.org/18628306:08
*** elmiko has quit IRC06:47
*** nickrmc83 has joined #openstack-barbican07:04
*** elmiko has joined #openstack-barbican07:16
*** everjeje has joined #openstack-barbican08:01
*** xek_ is now known as xek09:12
*** kebray_ has quit IRC11:16
*** darrenmoffat has quit IRC11:37
*** darrenmoffat has joined #openstack-barbican11:38
*** openstackgerrit has quit IRC11:39
*** openstackgerrit has joined #openstack-barbican11:39
*** woodster_ has joined #openstack-barbican11:42
*** dave-mccowan has joined #openstack-barbican12:23
zigoGuys, good news: barbican has been accepted into Debian Sid today !!! :)12:55
zigoPlease test the packages.12:55
zigoI have little knowledge with it, so I'd appreciate feedback.12:56
zigoI can help setting-up an openstack system in Debian if anyone needs.12:56
zigoRebuilding the package for Ubuntu should also work.12:56
woodster_zigo, thanks for the info!13:13
zigowoodster_: Will you be able to test the packages?13:13
woodster_zigo: I won't be able to, but I'll spread the word to folks today to get some feedback. Longer term though, I'm curious if there are automated/gate tests that can be made to verify proper operation on the Debian front?13:18
zigowoodster_: Is barbican integrated into tempest?13:19
zigowoodster_: I can add it to the list of packages that are automatically installed by my tempest suite, and then run functional testing on it...13:19
*** nkinder has quit IRC13:21
woodster_zigo: newer projects are moving out of tempest...so our devstack gate calls back to our repo to setup and run the functional tests. I thought things were pip installed for that though? If not, then it could just be a matter of making a new gate to test with Debian packages then?13:21
zigowoodster_: No pip install / tox things on the packaging level.13:22
zigowoodster_: Though if there's functional tests within the project, then it should be available once Barbican is installed, and then I should just run them...13:22
woodster_zigo: 'tox -e functional' on a barbican configured with Keystone will execute all the functional tests run by our devstack gate13:24
zigowoodster_: I see. So in fact: nosetests -v --processes=-1 --process-timeout=240 {toxinidir}/functionaltests {posargs}13:26
zigoEasy enough.13:26
* zigo is trying.13:26
woodster_zigo: it does require Keystone for auth though...we do have some info in the docs about setting this up13:28
zigowoodster_: I'll add automated setup for rabbit, db and keystone authtoken first.13:29
zigoI was leaving this for later ...13:29
*** jamielennox is now known as jamielennox|away13:29
zigoLater is now, I guess ! :)13:29
zigowoodster_: BTW, why isn't the project using a single generated barbican.conf?13:31
zigoWhat's the point of so many config files?13:31
zigoCurrently, the package doesn't even have config files... :(13:32
zigoOh, it does.13:34
woodster_zigo: we've been trying to clean things up, but there is only one config file currently: barbican-api.conf13:36
zigowoodster_: Why not call it just barbican.conf?13:36
woodster_zigo: well we were thinking we'd have one for the worker nodes (barbican-worker.conf) and we did have an admin one too...but just one now so we could move to barbican.conf I'd think13:37
zigowoodster_: It'd be a way better to do so, and then have each individual daemon to pick what they need from that unique file.13:38
zigoThat's what all other projects are doing.13:38
zigoFYI, there's a missing uwsgi dependency.13:39
* zigo corrects this right away.13:39
woodster_zigo: I'll add a bug to change that file13:39
woodster_zigo: uwsgi is what we have been deploying with, but it was pointed out that we should not depend on it directly so we've been removing that from rpm packaging I believe13:40
*** kfarr has joined #openstack-barbican13:43
zigowoodster_: It'd be super nice to have interactions between Murano apps and barbican.13:46
zigowoodster_: So that I could just click on Horizon, and get a site provisionned with SSL and all ...13:46
darrenmoffatwoodster_ what alternatives to uwsgi have been tested ?13:47
woodster_darrenmoffat: that's a good question actually, I recall at least one other was evaluated...redrobot jvrbanac hockeynut tdink do you recall what wsgi containers aside from uwsgi have been tested with Barbican?13:50
woodster_zigo: that would be nice! for demo/local-dev there is a simple cert plugin available. For production usage, only Dogtag is available now.13:51
*** rellerreller has joined #openstack-barbican13:56
*** pglass has joined #openstack-barbican14:05
*** nickrmc83 has quit IRC14:14
*** xaeth_afk is now known as xaeth14:18
*** zz_dimtruck is now known as dimtruck14:23
*** silos has joined #openstack-barbican14:27
*** nkinder has joined #openstack-barbican14:28
kfarrsilos, it was Jeff MacMillan from KeyNexus, though they were working with HSMs and not KMIP appliances14:34
openstackgerritSteve Heyman proposed openstack/barbican: Complete RBAC tests for containers  https://review.openstack.org/18641014:37
siloskfarr: thanks! Guess I'll tackle the KMIP  appliances then :-D14:40
*** nelsnelson has joined #openstack-barbican14:41
*** nelsnelson has quit IRC14:41
*** SheenaG has joined #openstack-barbican14:42
*** nelsnelson has joined #openstack-barbican14:42
*** nickrmc83 has joined #openstack-barbican14:52
redrobotzigo I was able to run using paste.httpserver.  And some folks had it running under apache with mod_wsgi.15:20
*** xaeth is now known as xaeth_afk15:21
*** kebray has joined #openstack-barbican15:23
*** xaeth_afk is now known as xaeth15:28
jvrbanacredrobot, you around?15:38
redrobotjvrbanac o/15:38
jvrbanacredrobot, are we suppose to drop the incubating theme?15:38
*** jorge_munoz has quit IRC15:38
redrobotjvrbanac Makes sense now that we're in the "big tent"15:39
openstackgerritMerged openstack/barbican: Imported Translations from Transifex  https://review.openstack.org/18628315:39
jvrbanacredrobot, ok... I just remember that people were upset with us before15:39
jvrbanacredrobot, I didn't want us to get in trouble again15:40
*** arunkant_ has joined #openstack-barbican15:41
*** gyee has joined #openstack-barbican15:43
chellygeljvrbanac, its barbican, we are, by nature, rebels. We will always be in trouble. Just wear your leather jacket with bride, throw on those aviators and start dropping legit openstack docs :D15:47
chellygelwith pride15:47
chellygelwow, brain dyslexic mutch15:47
jvrbanaclol15:47
chellygelmuch!15:48
chellygeli should get coffee..15:48
redrobotchellygel lol.  we could be the barbican t-birds15:49
woodster_my wife would love that...she watches Grease weekly I think15:49
redrobotwoodster_ you better shape up!15:50
chellygelwoodster_, your wife and I would be goooood friends :D15:51
*** jorge_munoz has joined #openstack-barbican15:51
woodster_redrobot: ha! That's what the chonklas are for15:51
chellygelon my previous team, we would sing grease (2) songs alllll the time15:51
woodster_chellygel: yeah *every* time she spots it on cable she watches it15:52
chellygeland for the record redrobot, i would love t-bird jackets15:53
*** chlong has quit IRC15:54
darrenmoffatI missed the last summit and haven't been following OpenStack stuff as closely as I'd like.  What is the relationship between Barbican and Castellan ?  Is Castellan basically the oslo client interface and Barbican the back end ? or are they competing in someway ?15:55
*** pglass has quit IRC15:58
woodster_arunkant: redrobot was the decision last week to update the ACL CRs to change from 'creator-only' to 'project-access', or to merge these CRs in first and then have follow on CRs to move to 'project-access'?15:58
redrobotwoodster_ merge first.  I can follow up with the project-access change15:58
woodster_darrenmoffat: Castellan is a neutral adapter that other projects can use it to provide key manager support. Barbican will be available as a plugin to Castellan, as will direct KMIP and HSM plugins eventually.15:59
woodster_darrenmoffat: so no competition between the two15:59
*** pglass has joined #openstack-barbican16:00
*** nickrmc83 has quit IRC16:00
darrenmoffatthey way you described it castellan sounds exactly like barbican to me :-)16:00
woodster_redrobot: ok, will do16:00
darrenmoffatso I'm still confused16:00
darrenmoffatwhy would both castellan and barbican need to have KMIP and HSM support ?16:01
woodster_darrenmoffat: some users would like to minimize dependence on code/libraries, so they would prefer to have direct-to-KMIP plugins for their deployments. Castellan is a lightweight adapter to allow that choice to be deployed.16:02
woodster_redrobot: I still haven't had a chance to look at your presentation, but would it provide more info for Castellan16:03
woodster_?16:03
darrenmoffatso castellan has no server component like barbican has ?16:03
woodster_darrenmoffat: that's correct16:03
*** tkelsey has joined #openstack-barbican16:04
redrobotdarrenmoffat Castellan is a client lib.  allows a developer writing an app that needs key management to provide pluggable key manager backends16:04
darrenmoffatso in the future someone with a KMIP server should probably plan on testing with both castellan and barbican16:04
redrobotdarrenmoffat KMIP support is a little different.16:04
redrobotdarrenmoffat with Castellan your app would talk to the KMIP device directly16:04
redrobotdarrenmoffat putting barbican in front of the kmip device gives you multi-tenancy and the ability to scale out the storage capacity16:06
woodster_darrenmoffat: so if someone already has a KMIP server they can choose which plugin to use. The Barbican plugin would provide a project-based auth approach that can support other crypto backends later. If that isn't required for a deployment though, they could just use a KMIP plugin directly.16:06
*** everjeje has quit IRC16:07
darrenmoffatthat helps a lot thanks!16:07
*** chlong has joined #openstack-barbican16:07
openstackgerritMerged openstack/barbican: Drop incubating theme from docs  https://review.openstack.org/18618816:08
*** kebray has quit IRC16:12
aleewoodster_, redrobot ping16:17
redrobotalee o/16:17
aleeredrobot, so I'm writing some api docs for certs as well as a quickstart doc for dogtag16:18
*** igueths has joined #openstack-barbican16:18
aleeredrobot, so once I have a doc, I compile it it using tox -e docs16:18
aleehow do I see what has been compiled?16:19
redrobotopen ./doc/build/html/index.html16:19
redrobotalee ^^16:20
aleeredrobot, thanks - trying16:20
*** gyee has quit IRC17:04
woodster_arunkant: alee redrobot jvrbanac hockeynut tdink dave-mccowan Please take a look at comments on the ACL doc CR here: https://review.openstack.org/#/c/178479   In particular, I've added a cover comment that summarizes what we discussed last week (I hope). The rest of the changes are mostly wordsmithing, but please note the 200 vs 201 and 404 comments in17:06
woodster_there...those really need to be clarified and agreed upon.17:06
woodster_rellerreller: kfarr ^^^ as I think you were involved in the ACL reviews as well17:08
*** kebray has joined #openstack-barbican17:09
arunkant_woodster_, about 201 vs 200 on PUT call. I was trying to follow http spec guidelines. https://tools.ietf.org/html/rfc7231#section-4.3.417:52
arunkant_woodster_, From that...related line is "If the target resource does not have a current representation and the17:54
arunkant_   PUT successfully creates one, then the origin server MUST inform the17:54
arunkant_   user agent by sending a 201 (Created) response."17:54
woodster_arunkant_: I would argue it does have a representation though, the empty dict17:58
woodster_arunkant_: if we can GET a representation without a 404, PUT and others should be similar IMHO17:59
arunkant_woodster_, actually resource does not have state in db..its just what we are returning in response. It is as good as no content.18:00
*** kebray has quit IRC18:01
*** nkinder has quit IRC18:03
woodster_arunkant_: I'd say that's an implementation detail. WRT the client it does have a representation. An alternative is to say the 'acl' resource is a zero or one resource. Then we'd need to return 404 on GETs instead of empty dict.18:03
arunkant_woodster_, 200 and 201 both are success state..just better way of informing client whether it was a create or update.18:04
woodster_arunkant_: hockeynut ^^^ The 404 route would make testing more difficult and be trickier for clients but more canonical probably18:04
woodster_arunkant_: it is a consistency issue to me though18:05
woodster_arunkant_: I think a acl is always there model is easier to use/test/document all the way around18:06
woodster_redrobot: alee ^^^18:06
arunkant_woodster_, we are only talking about ACL PUT request where 201 vs 200 is returned in response code..right?18:08
*** kfarr has quit IRC18:08
woodster_arunkant_: no need to change db approach just the API contract18:08
arunkant_woodster_, yes. Trying to understand why its inconsistent ..Its PUT request and different response code helps client to understand whether it was create or update.18:12
*** rellerreller has quit IRC18:13
openstackgerritMerged openstack/python-barbicanclient: Remove tempest config dependency in functional tests  https://review.openstack.org/18068618:13
woodster_arunkant_: what is inconsistent is that GET doesn't return 404 with no ACL. Back to back DELETEs to same ACL should return 404 as well.18:14
arunkant_woodster_, this can be useful especially as we no longer have POST call.18:15
woodster_arunkant_: I don't see what the no-ACL support buys you other than complexity. If we just say secrets always have an ACL but by default it  doesn't have settings (project-access = true will be implied) that makes things a lot easier18:16
*** gyee has joined #openstack-barbican18:17
arunkant_woodster_, I think client can have certain behavioral expectation from PUT call as per http spec. There are no default ACL defined for a new secret. I am not sure what will happen if other operations like 'list', 'write' are supported..what is default in that case.18:23
*** nkinder has joined #openstack-barbican18:24
*** kebray has joined #openstack-barbican18:26
*** kfox1111 has joined #openstack-barbican18:31
kfox1111Is the acl api posted anywhere?18:31
kfox1111I'm curious if you can add/remove specific users, or if you have to reupload the acl as a whole each time.18:31
kfox1111If the latter, its going to be a problem for heat.18:32
*** epequeno13 has joined #openstack-barbican18:32
*** epequeno13 is now known as epequeno18:33
*** tkelsey has quit IRC18:33
arunkant_kfox1111, I am working on API docs and its going through review. The list of users are added as a whole list. Users can be added if there are no users present in existing ACL.18:36
kfox1111bummer. thats not going to work. :/18:36
kfox1111think adding/removing an idividual from the list will be doable in the Liberty timeframe?18:37
kfox1111I'm worried about the race condtion that could happen if two instances are autoscaled into existance at the same time.18:37
kfox1111the heat resources could hit two different heat engines, each pull the acl, make their changes, and then race to put it back. One will get its stuff dropped.18:38
kfox1111Its worse on the instance delete case too. :/18:38
kfox1111Does that make sense? How should we work to resolve that? Bug report? Blueprint?18:44
arunkant_kfox1111, I think ACL PATCH behavior can be modified such that it always add 'users' to existing list. Not sure what to do for partial delete. May be use PUT call to replace whole list then18:44
kfox1111replacing the whole list would still be racy. If a delete and another update happens at the same time, the delete might get skipped. :/18:45
kfox1111the change to just the one user in the acl needs to be atomic. The only place I think that can be done is in the db. so it really needs an api for it. :/18:47
kfox1111do acl's have uuids currently?18:47
arunkant_woodster_, ^^^^  any suggestion how to address partial delete case18:47
kfox1111having crud for entries in the acl would solve it.18:48
*** nkinder has quit IRC18:49
woodster_kfox1111: arunkant_ it seems that we'd have to specialize the PATCH to support specific actions like that. You'd still have a race condition if two heat engines are trying to add and delete the same user at the same time though...Barbican couldn't solve that one for you :)18:56
kfox1111if the api provided crud for the stuff in the acl, then it could be dealt with in the db?18:57
woodster_kfox1111: arunkant_ My thoughts are that we should keep PUT/PATCH based on JSON the way it is now in the pending CR, but augment that with a way to add/delete individual users with a follow on bp/cr18:57
*** kebray has quit IRC18:57
kfox1111k.18:57
woodster_kfox1111: arunkant_ well that might be the way to do it...something like PATCH secrets/{UUID}/acl/add-user=12694817388 or some such18:58
woodster_redrobot: jvrbanac hockeynut ^^^^18:58
*** rellerreller has joined #openstack-barbican18:58
kfox1111I was just thinking Post /ACL/{UUID}/username and Delete18:59
kfox1111also, a follow up question. are acl's on containers too, or just secrets? IE, if I have a container, do I have to follow the links and put acls on every secret?19:00
woodster_kfox1111: arunkant_ well we moved away from separating all the things in the ACL via individual UUIDs to simplify the ACL model19:00
kfox1111I was afraid of that. Seems like it may be too simple now. :/19:00
arunkant_woodster_, so you are thinking of secrets/{UUID}/acl?add_user=12345678  or ?remove_user=1234567819:00
kfox1111that would work. just not very resty.19:01
*** nkinder has joined #openstack-barbican19:01
arunkant_woodster_ but then if decide to support more than read operation..then this has to be operation specific as well.19:01
kfox1111what about put/delete on secrets/{UUID}/acl/<userid> ?19:01
kfox1111the put can contain a doc with the roles.19:03
kfox1111That would be flexable enough to put a Heat resource around it.19:06
kfox1111Are there any other properties of a user in the acl besides a role?19:06
arunkant_kfox1111, acl has 'operation' field which has value of 'read' (operation supported currently)  , a flag (project_access behavior) and list of users.19:09
woodster_kfox1111: do you mean a Keystone-style role, or else an operation like 'read' or 'list'?19:09
kfox1111the latter.19:10
woodster_kfox1111: see Arun's CR for examples of the ACL JSON: https://review.openstack.org/#/c/178479/19:10
kfox1111k. looking...19:10
kfox1111ah. so the type of permission (what I called a role a minute ago) is at a higher level place in the document, and the list of users under it.19:12
woodster_kfox1111: that's correct19:12
kfox1111though from the perspective of the api, it probably doesnt matter if you start with the acl type or the user.19:12
kfox1111so post "{acls: ['read']}" > secrets/{UUID}/acl/{USERID} or delete secrets/{UUID}/acl/{USERID}19:14
*** dark1 has joined #openstack-barbican19:14
kfox1111but it could be secrets/{UUID}/acl/read/{USERID}19:14
kfox1111I was talking to the keystone folks and we're thinking the vm should use unscoped tokens unless scoping is needed. Will barbican acls work with an unscoped token?19:15
*** dark1 has quit IRC19:15
kfox1111(This vm-integration stuff with keystone is WAY more complicated then the other solution... :)19:16
kfox1111I'm still for it, but its going to be like 20 different reviews in the end I think. :/19:17
kfox1111Its already involving barbican, barbicanclient, heat, nova, keystone, keystoneclient, and horizon already.19:18
*** kebray has joined #openstack-barbican19:19
*** SheenaG has quit IRC19:30
*** insequent has joined #openstack-barbican19:35
*** tkelsey has joined #openstack-barbican19:46
*** tkelsey has quit IRC19:51
*** silos1 has joined #openstack-barbican19:57
*** silos has quit IRC19:59
*** nkinder has quit IRC19:59
*** SheenaG has joined #openstack-barbican20:22
*** xaeth is now known as xaeth_afk20:27
*** xaeth_afk is now known as xaeth20:45
openstackgerritMerged openstack/python-barbicanclient: Drop incubating theme from docs  https://review.openstack.org/18619720:46
openstackgerritDave McCowan proposed openstack/barbican-specs: Add Quota support for Barbican resources  https://review.openstack.org/18656220:48
*** nelsnelson has quit IRC20:50
*** SheenaG has quit IRC20:54
*** SheenaG has joined #openstack-barbican20:56
*** dimtruck is now known as zz_dimtruck20:58
woodster_dave-mccowan: Hey Dave, is this a similar blueprint to this one?: http://specs.openstack.org/openstack/barbican-specs/specs/kilo/quota-support-for-barbican-resources.html21:03
dave-mccowanyes.. i think same one.  the CR i just pushed was only a "git mv" from kilo/ to liberty.  it's not ready to merge yet; i'm going to make changes to the spec, but i wanted a clean base in the CR from the version that was approved in kilo.21:05
woodster_kfox1111: as long as barbican gets the user information passed to it, the ACL process should work. If the token is not scoped to barbican though, I think Keystone (via middleware) will reject attempts to talk to Barbican?21:06
*** dave-mccowan has quit IRC21:07
woodster_dave-mccowan: ok cool, just making sure you knew the other was there and didn't write that from scratch!21:07
*** nelsnelson has joined #openstack-barbican21:09
*** zz_dimtruck is now known as dimtruck21:12
*** insequent has quit IRC21:14
*** insequent has joined #openstack-barbican21:14
*** silos1 has left #openstack-barbican21:19
*** pglass has quit IRC21:22
*** pglass has joined #openstack-barbican21:23
*** epequeno has quit IRC21:24
*** kebray has quit IRC21:31
*** jamielennox|away is now known as jamielennox21:34
*** openstackgerrit has quit IRC21:36
*** openstackgerrit has joined #openstack-barbican21:37
*** rellerreller has quit IRC21:53
*** xaeth is now known as xaeth_afk22:03
*** nelsnelson has quit IRC22:11
*** igueths has quit IRC22:17
*** nkinder has joined #openstack-barbican22:17
*** barra204 has joined #openstack-barbican22:43
*** pglass has quit IRC22:48
*** chlong has quit IRC22:52
*** SheenaG has quit IRC22:53
*** SheenaG has joined #openstack-barbican22:58
*** barra204 has quit IRC23:01
*** kebray has joined #openstack-barbican23:04
*** dimtruck is now known as zz_dimtruck23:12
*** barra204 has joined #openstack-barbican23:16
kfox1111woodster_: I don't think keystone supports scoping to a service at all. only domains or projects at this point.23:34
kfox1111or unscoped.23:34
kfox1111 Ithink I'm just going to have to stand up a test barbican instance and see how it responds to the unscoped token.23:35
kfox1111a long with finding a spare bit of time to file like a million specs. :)23:35
*** zz_dimtruck is now known as dimtruck23:43
*** tkelsey has joined #openstack-barbican23:49
*** tkelsey has quit IRC23:54

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