Thursday, 2015-05-07

*** DCWillia_ has quit IRC00:02
*** SheenaG has quit IRC00:04
*** rm_work is now known as rm_work|away00:35
*** everjeje has quit IRC00:36
*** DCWilliams_VA has joined #openstack-barbican00:40
*** shakamunyi has quit IRC01:02
*** kebray has joined #openstack-barbican01:10
*** kebray has quit IRC01:10
*** kebray has joined #openstack-barbican01:11
*** DCWilliams_VA has quit IRC01:12
*** kebray has quit IRC01:16
*** kebray has joined #openstack-barbican01:16
*** shakamunyi has joined #openstack-barbican02:10
*** crc32 has quit IRC02:30
*** kebray has quit IRC02:47
openstackgerritDave McCowan proposed openstack/barbican: Add Multi-user support and ACL coverage in Functional Tests
*** dave-mccowan has quit IRC04:24
*** woodster_ has quit IRC05:30
openstackgerritArun Kant proposed openstack/barbican: Removed per ACL operations and added support for PUT method.
*** everjeje has joined #openstack-barbican06:58
*** rm_work|away is now known as rm_work07:07
*** nickrmc83 has joined #openstack-barbican07:34
*** darrenmoffat has quit IRC10:06
*** darrenmoffat has joined #openstack-barbican10:12
*** woodster_ has joined #openstack-barbican11:46
*** jaosorior has joined #openstack-barbican11:52
*** openstackgerrit has quit IRC11:52
*** openstackgerrit has joined #openstack-barbican11:52
therveHi all12:01
therveI noticed that the default policy is to only allow admins to do secret:delete12:01
therveWhat's the reasoning behind not allowing creator?12:01
jaosoriortherve: probably arunkant would be able to answer that question12:05
therveCool :)12:05
jaosoriorand I think he's in US timezone so he will hopefully be online soon12:05
thervejaosorior, Unrelated, but do you have any feedback on ?12:06
jaosorioractually I was about to start reviewing12:06
jaosoriorlet me take a look12:06
jaosoriorI guess to be able to properly test that, we would need your other CR to land, right?12:07
jaosoriorwell, to properly test it in the gate12:08
jaosoriormeaning, this:
therveI don't think that patch changes the gate situation12:20
therveIt helps testing in devstack, though12:21
*** dave-mccowan has joined #openstack-barbican12:24
jaosoriorwhich I would like12:26
jaosoriorI'll check that first12:26
woodster_jaosorior: Ozz can you look at
jaosoriorwoodster_: sure12:51
jaosoriortherve: ping12:52
jaosoriorwoodster_: ping13:05
*** nkinder has quit IRC13:14
*** david-lyle has quit IRC13:19
thervejaosorior, Yep! Sorry was away13:24
*** openstackstatus has quit IRC13:25
*** openstackstatus has joined #openstack-barbican13:25
*** ChanServ sets mode: +v openstackstatus13:25
jaosoriortherve: no problem13:27
jaosoriortherve: can you add some placeholder to the config for the snakeoil configuration options in the etc/barbican/barbican-api.conf? I was initially gonna discuss testing, since I would like to have the snakeoil ca plugin tested in the gate, but then I figured that it's better to either discuss it in the summit, or just do it at some point13:32
thervejaosorior, I believe you only need to set  the enabled_certificate_plugins option13:33
thervedefault values of the snakeoild_ca plugin should work13:33
therveAh you need to set the values to something though13:34
jaosoriorand there are no default values set in the config file13:35
jaosoriorso, it would be nice if as part of the fix, if you want, you could add those13:35
jaosoriorjust thought it would fit the CR13:35
jaosoriortherve: thanks man13:38
*** joesavak has joined #openstack-barbican13:39
*** chlong has joined #openstack-barbican13:39
openstackgerritThomas Herve proposed openstack/barbican: Fix snakeoil_ca plugin
thervejaosorior, ^^^13:42
jaosoriortherve: checked13:51
*** jamielennox is now known as jamielennox|away13:51
*** pglass has joined #openstack-barbican14:05
*** nkinder has joined #openstack-barbican14:08
woodster_jaosorior: I'm back14:23
*** rellerreller has joined #openstack-barbican14:32
openstackgerritDave McCowan proposed openstack/barbican: Add Multi-user support and ACL coverage in Functional Tests
openstackgerritJuan Antonio Osorio Robles proposed openstack/barbican: Add project_id to Secret model
openstackgerritThomas Herve proposed openstack/barbican: Fix snakeoil_ca plugin
thervejaosorior, So I removed those values. You actually don't need them to test the plugin14:48
therve(And the tests failed in a weird way that I couldn't reproduce)14:48
jaosorioryou don't need them to test the plugin, but it would have been nice to have them (even if commented) just for documentation14:48
jaosorioranyway, that's alright14:48
therveI'm really wondering what's happening in the gate for those files to be loaded14:49
openstackgerritJuan Antonio Osorio Robles proposed openstack/barbican-specs: Move data-remove-tenant-secret-assoc to Liberty
*** jsavak has joined #openstack-barbican14:53
jaosoriorwoodster_: where's the etherpad for the liberty summit?14:53
woodster_jaosorior: Here it is:
jaosoriorand, do you think it's valuable to talk about adding tests for the snakeoil plugin to the functionaltests or should that just be done?14:54
woodster_jaosorior: it's fair game to talk about testing anything in our repository I figure. Please add to the list..I think there is some other testing related things out there too14:55
*** joesavak has quit IRC14:55
*** joesavak has joined #openstack-barbican14:56
woodster_jaosorior: it seems we do need a way to select from multiple cert plugins in our testing. The ca_id work alee_ and others have done helps out with that14:56
woodster_hockeynut: tdink ^^^^14:57
*** darrenmoffat has left #openstack-barbican14:57
hockeynutwoodster_ yep, we don't play with any of that...yet14:57
*** jsavak has quit IRC14:58
*** xaeth_afk is now known as xaeth15:01
jaosoriorwe don't, and we should :O15:12
*** kebray has joined #openstack-barbican15:12
*** SheenaG has joined #openstack-barbican15:22
*** igueths has joined #openstack-barbican15:34
*** rm_work is now known as rm_work|away15:40
*** nelsnelson has joined #openstack-barbican15:41
*** tkelsey has joined #openstack-barbican15:47
tkelseyhey Barbican folks, can I just check what the status of certificates is in Kilo ?15:48
hockeynutbarbicaneers - looking for some review on two functional test CRs: and
*** nickrmc83 has quit IRC15:50
*** jsavak has joined #openstack-barbican16:05
*** joesavak has quit IRC16:08
*** rm_work|away is now known as rm_work16:13
openstackgerritJohn Wood proposed openstack/barbican: Port the Architecture, Dataflow, and Project Strucure docs
*** joesavak has joined #openstack-barbican16:23
*** jsavak has quit IRC16:26
*** shakamunyi has quit IRC16:29
kragnizheads up, folk, we're looking at getting barbican and glance together :)16:31
redrobotkragniz \o/16:31
kragnizI should finish off those oslo CRs...16:32
*** rm_work is now known as rm_work|away16:32
woodster_tkelsey: Ade (alee_) has done a lot of work with Dogtag for certs in Kilo. Thomas (therve) has done work with a snake-oil plugin, good for demo/local-dev work. I've added a dev-mode retry functionality that can support development of extended workflows with CAs to generate certs.16:41
chellygelhey redrobot / jvrbanac re: pragma no cover only removes coverage for line 280, not for 281 -- so i still only see 98%. Should i leave it as an exclude in the RC or should i add pragma no cover twice? also on line 281?16:41
tkelseywoodster_: ok thanks for the info, so we can request certs through Barbican and hit one of the available plugins?16:43
woodster_tkelsey: you would need to configure things from the default/out-of-the-box configs to make things work. Are you interested in the Dogtag CA plugin or the snakeoil one?16:44
tkelseyeither, I'm just interested in where things are with it in general :)16:45
tkelseyis there a document some place with details of how to kick the tires with the snake oil CA ?16:47
tkelseythan i can go RTFM :)16:48
woodster_tkelsey: unfortunately docs have not caught up to the relatively new features. alee_, therve or jaosorior can you guys provide more guidance on setting up these features?16:57
woodster_tkelsey: in fact, therve has a CR up to fix the snakeoil plugin:
tkelseythanks woodster_ I'll take a look16:58
openstackgerritDave McCowan proposed openstack/barbican: Refactor Stored Key Certificate Order Validator Code
*** joesavak has quit IRC17:03
woodster_tkelsey: That CR looks complete (i.e. you could probably pull it down and play with it), except that I noticed that the barbican configs for it were removed (patch 4 has them, the latest doesn't) which you would need to run this locally I believe.17:04
*** crc32 has joined #openstack-barbican17:05
tkelseyok woodster_ thanks :)17:06
*** crc32 has quit IRC17:06
*** joesavak has joined #openstack-barbican17:07
woodster_elmiko: thanks for the assist in the api-wg meeting...I didn't know if they were going to have a general topics part at the end or not17:15
elmikowoodster_: np =)17:15
openstackgerritChelsea Winfree proposed openstack/python-barbicanclient: Adding new tests to cover failure scenarios
*** crc32 has joined #openstack-barbican17:32
*** rellerreller has quit IRC17:32
*** rellerreller has joined #openstack-barbican17:35
*** notmyname has joined #openstack-barbican17:36
notmynamehmm..this looks like the right place17:36
notmynameSheena_: SheenaG: ping17:36
notmynameI'm looking at the barbican panel slides now17:36
SheenaGnotmyname: pong17:37
SheenaGnotmyname: welcome to the room!  You've made it!17:37
notmynamewell, more like I finally made it to looking at this particular summit thing :-)17:38
SheenaGnotmyname: that's a way bigger congratulations17:38
SheenaGnotmyname: I'm positive that diagram I made is totally wrong - just let me know what to change and I'll get it fixed, you're welcome to amend the deck directly17:38
notmynameso now we gotta whip the swift part into shape :-)17:38
notmynameyeah, it is kinda totally wrong17:39
SheenaGnotmyname: hahahahahaha17:39
SheenaGnotmyname: I figured.  I was having a terrible time translating it, I'm sorry.  I did rm_work|away's from a scribble, I thought I could do anything17:39
SheenaGnotmyname: I learned my lesson17:40
SheenaGnotmyname: also, could you send me your availability/unavailability for next week?  I want to schedule our first run through today if possible, before peoples' schedules fill up17:41
notmynameI've got one or two things on the calendar that week ;-)
notmynamesunday afternoon would be great17:43
SheenaGI'm only seeing the summit calendar - is next week (before the summit) nuts too?17:43
SheenaGI see "herding" - I hope that's "herding cats"17:43
notmynameah, ok. next week17:43
notmynamemuch easier next week :-)17:43
SheenaGHuman Genome Sequencing?17:44
SheenaGYour calendar is so much cooler than mine.17:44
notmynameyeah, it's really cool. Swift is integrated into some of the gene sequencers so they can dump directly to swift
*** anteaya has quit IRC17:45
SheenaGThat's awesome.17:45
SheenaGAdding to my talks to attend...17:46
notmynamealso, you might suspect why "encryption" is getting some attention in swift ;-)17:46
*** everjeje has quit IRC17:46
SheenaGIt certainly makes intuitive sense17:47
notmynameso, yeah, next weeks is pretty open. wednesday pm I have the hardest time17:47
notmynamealso, I'm in pacific time zone, so I can generally do later (if you're in central)17:47
SheenaGI'm in Mountain View, CA right now - so I'm on your time17:48
notmynameoh cool17:48
SheenaGI'll see about scheduling Tuesday or Thursday - it looks like either of those work for the other attendees.17:48
SheenaGMaybe both if I can - I'd like to do two full walkthroughs before the actual conference if possible17:49
notmynameSheena_: yeah, tuesday or wed are ok. wednesday is a little tricky, but not too back17:54
notmynameSheenaG: shall we go over the swift slide now?17:56
SheenaGnotmyname: I'm in a meeting for another 4 minutes, but can chat immediately following17:56
*** arunkant_ has joined #openstack-barbican17:56
notmynamehmm..looking at the diagram again, it's actually not too bad18:01
SheenaGnotmyname: don't try to make me feel better about my hideous diagram18:01
notmynamethe order if the columns isn't what I was expecting, but overall it's close to what actually happens18:01
SheenaGnotmyname: I can take the criticism18:01
SheenaGnotmyname: haha - do you want to chat on here or do Hangouts for review?18:02
notmynamewell, the column order is not what I was expecting, and there's one part missing, but that missing part isn't too far off from the functional things that are shown18:02
notmynameyour call18:02
notmynamehangouts might be better. higher bandwidth communication gets things done faster18:02
SheenaGTrue - I'll send you a link18:03
jaosoriorwoodster_: sorry for the late reply, was in the forest haha. Sure tomorrow I can see if I can answer tkelsey ' s questions18:25
*** jsavak has joined #openstack-barbican18:35
openstackgerritChelsea Winfree proposed openstack/python-barbicanclient: Adding new tests to cover failure scenarios
notmynameI tagged the 2 swift design sessions on encryption with babican, so you should see it in your schedule too18:37
SheenaGNice, thanks notmyname18:37
notmynamehmmm...looks like there might be a conflict18:37
notmynameI'll see what I can do18:37
*** joesavak has quit IRC18:39
*** joesavak has joined #openstack-barbican18:39
*** jsavak has quit IRC18:41
*** jsavak has joined #openstack-barbican18:41
*** tkelsey has quit IRC18:43
*** joesavak has quit IRC18:45
*** rm_work|away is now known as rm_work18:52
*** joesavak has joined #openstack-barbican19:02
rm_workSheenaG: hey, my "scribble" was beautiful, not my fault you don't appreciate art when you see it :P19:02
*** jsavak has quit IRC19:03
SheenaGrm_work: and you wonder why people call you crazy19:05
rm_workpeople call me crazy because when people observe brilliance outside their level of understanding, they ascribe it to insanity19:08
notmynameout of curiosity, how much should I worry about barbican storing/managing a few million keys? or more19:23
elmikogood question, it's using sqlalchemy, so i imagine as long as you have faith in your db it would be ok. not sure about the scale of retrieving those keys, depending on density.19:26
rm_workI think in production it would use MySQL or such usually?19:29
rm_workso really it's that19:29
rm_workerr, sorry yeah misread that statement, elmiko is correct :P19:29
elmikoyea i wouldn't be worried about the mysql or postgresql db, i'd be more worried about the density of calls to the server. but that might not be an issue either.19:30
redrobotnotmyname should be fine if using a backend that leverages the Database.  The KMIP plugin, for example would be limited by the storage space in your KMIP device.19:31
elmikohas anyone ever brought up HA barbican?19:31
notmynameredrobot: at what point will I see problems? what if I need to store a billion keys?19:31
redrobotnotmyname depends on hardware choice.  there's two classes of storage backends:  Those that use the DB for storage, and those that use an external device for storage.  In both cases you'll be limited by the actual space, but the DB storage is much easier to scale.19:34
notmynamesingle machine? single drive?19:34
notmynameI'm curious from a deployment perspective19:34
notmynamein a few months when I have swift+barbican and I want to encrypt all the things, I'll need to store a _lot_ of keys19:35
notmynameso if I have a million container, get a new key per container per month, and store it for a few years, I've got a pretty large key cardinality19:35
notmynameso I'm curious if that's just not suitable at this point (ie keep problem scope and cluster size down) or if the answer is "sure, np. just add some more boxes"19:36
notmynameso if eg bank of america uses swift+barbican to encrypt every customer record they store, is that reasonable or not19:37
* notmyname doesn't know if BoA uses swift or not, but it's reasonable (and they should!)19:37
redrobotwe're limiting key size to be very small19:37
*** tkelsey has joined #openstack-barbican19:38
redrobotthe reference limit is 10kb19:38
notmynamesize of the key or cardinality of the keys?19:38
redrobotso 1 billion keys at 10kb ~ 10 TB for storage19:38
notmynamewhat does that mean? what's a reference limit?19:38
redrobotlimit is configurable19:38
redrobotbut we're recommending small limits so people don't use Barbican as the "encrypted swift" :)19:39
notmynamethat's what swift is for!19:39
notmynamehow is that storage done? all in one place? in a DB that is/can be sharded? something else that's more horizontally scalable?19:40
notmynamehmm...maybe I'm thinking of something different for "key" than you are19:40
redrobotnotmyname so the storage depends on the backend choice.19:40
notmynameI'm thinking of the key that's used to do the encypt/decrypt19:40
notmynamewhat are the backend options?19:40
redrobotso you need to choose a "Secret Store".  Current choices are DB+PCKS#11 device, or KMIP device, or DogTag19:41
notmynameclearly, /me hasn't read much on barbican's implementation ;-)19:41
*** tkelsey has quit IRC19:42
redrobotso for the DB+PCKS#11 backend, we provision an data-encryption-key for the project/tenant, which we call the KEK19:42
redrobotthe KEK is encrypted in the PKCS#11 device with a Master Key19:42
redrobotthe Master Key never leaves the PCKS#11 device19:43
redrobotthe KEK is stored in the DB after it's encrypted19:43
redrobotwhen a user sends us a "secret" (for your case, probably one of the billion keys you're using to encrypt things)19:43
redrobotwe retrieve the encrypted KEK19:44
redrobotsend it to the PKCS11 device19:44
woodster_notmyname: yep, so the HSM is not storing much data at all19:44
redrobotdecrypt it with the master key, leave KEK in-memory19:44
redrobotthen send the "secret" to be encrypted with the KEK.19:44
redrobotand we store the now-encrypted secret in DB19:44
redrobotthe other two backends are different in that they store both the KEK and "secret" in the external device.19:45
redrobotand dedicated security devices won't scale like a DB does.  So for super high storage requirements, you definitely want to use the DB storage19:46
notmynameso my understanding is that there is the "key" that is used to encrypt/decrypt and it has a key_id. so swift sends a request to barbican for the key associated with a particular key_id and then uses that to decrypt the data19:46
redrobotnotmyname yep, "key" for you is "secret" for us19:46
notmynameand on the initial write, swift sends *something* to barbican to get a new key and key_id. swift encrypts with the key and stores the key_id19:46
redrobotnotmyname so, if you want Barbican to provision the "key" you will use, then you send us an Order19:48
notmynameso swift asks for either a new secrect/id pair or the secret associated with an ID19:48
notmynameand what's in an order?19:48
redrobotnotmyname all the metadata we need to generate an appropriate key.  So if you want to do symmetric encryption, you would tell us that you want to do AES-256-CBC for example.19:49
redrobotthen barbican provisions the key, and creates a new "secret"19:49
redrobotso you send Order, and get an Order ID.  Once the Order is processed, you can use the Order ID to retrieve the Secret ID for the secret that was created.19:50
notmynamehow about I send you an ID of my own choosing and you send back the secret for that or a new secret for it?19:50
redrobotwith the Secret ID you can get the key back to do your encryption.19:50
notmynameso orders are async? I wonder how that will/can work with something that's in the read/write data path19:51
redrobotnotmyname you'd get an existing key back, or a 404.19:51
redrobotnotmyname orders are async because some secrets take a long time to provision e.g. x509 cert from a CA19:52
notmynameah, so if I get a 404 then I make a new connection with an order?19:52
woodster_notmyname: you can give the secret a name of your choosing, and then search by that name later if that's what you mean?19:52
notmynamewoodster_: yeah, that sounds good19:52
chellygelstepping away, need to get some paperwork finished for my trip. will be back19:53
notmynameI'm thinking of a unique key per (account, container, month) tuple. I'll send that to barbican asking for a key19:53
redrobotnotmyname yep.  secret IDs include a UUID.  They'll 404 if the uuid doesn't exist, and they will also 404 if you set an expiration date that has past.19:54
notmynameit would be _really_ nice if I could have a key created and returned if it didn't already exist. my secrets will _never_ expire, and they will all be symetric19:54
notmynameoh, and I need to handle 10-15K of these every second (which is why the extra http connection is bad for me) ;-)19:55
redrobotnotmyname you could achieve that by setting the "name" on your secret to be "account-container-month", and then filter your secrets by that name.  You'll either get one or more secrets that match, or an empty list.19:55
redrobotnotmyname hehe, yeah, that's a lot of keys19:56
notmynamewell, I know steady-state swift clusters today doing around that much traffic. so actually that's a lower bound ;-)19:56
notmynameredrobot: thanks for the info. it sounds like, for now, most of the functionality is there. and the appropriate scale is yet to be tested. lots of variables19:58
* notmyname would still really like the equiv of INSERTORUPDATE to avoid extra http requests19:59
elmiko10-15k a second, that's awesome =)19:59
notmynameI guess in this case it's a get_key_or_create_if_it_doesnt_exist()19:59
rm_worknotmyname: that'd require an order to be created, not sure that's SUPER feasible20:00
rm_worksince orders are async20:00
notmynamerm_work: even if the scope is limited to a secret that doesn't expire, has one kind of algo, and is symetric?20:01
rm_worknotmyname: all generation of secrets is via Orders, and all Orders are async, at the moment20:02
rm_workredrobot: ^^ confirm?20:02
notmynameactually, why do you need the algorithm? I need a symetric key to use, and of course that needs to be big enough for the algo, but I'll be doing the actual encryption20:03
notmynamewe're using aes-256 in ctr mode20:03
woodster_rm_work: that's correct. 10-15k generation / second is a very high rate. The HSMs are a major bottleneck to all of this. They have limited memory, and since we store a enryption key per project, we can only store the MKEK in the HSM and then decrypt/unwrap that project KEK for each secret operation. That is several hops to the HSM to decrypt and encrypt20:05
woodster_secrets (or your data encryption keys).20:05
redrobotnotmyname we only really need the bit_length to provision a correct key in this case.    We ask for algorithm and mode as metadata, in the event that sometime in the future you change the algorithm/mode you can use the metadata with the key to remember what you were doing with it.  rm_work is right though, currently all provisioning is async.20:05
woodster_notmyname: so if you need to create this many unique secrets per second I think that will be a challenge. We would need to ask the HSM to generate the secret/DEK, then have it unwrap the secret's project KEK, then encrypt the secret with that project KEK, then store that secret along with its cypher text.  The reverse process is needed when the secret is20:07
*** chadlung has joined #openstack-barbican20:11
hockeynutdave-mccowan ping20:19
dave-mccowanhockeynut pong20:19
notmynamewoodster_: rm_work: thanks for the info20:20
hockeynutdave-mccowan looking at the acl user/multiuser CR20:20
hockeynutcan we break that up into 2?  one for just multiuser and then one for acl?20:20
notmynamewoodster_: rm_work: also, this is ongoing work in swift right now. not something that is at all finished. there's a lot to do in swift beyond talking to barbican20:20
notmynamegood stuff to think about over the next few months20:20
hockeynutdave-mccowan the reason I ask is that we can get a lot of good stuff for general RBAC testing out of what you have but its kinda tied closely with ACL users and we can generalize it20:21
dave-mccowan2 CRs?  or functionally break up code?   +1 I want it to be generalized.20:21
woodster_notmyname: I don't mean to scare you off btw! It would be good to talk details with you, reaperhulk at others at the summit, regarding your particular needs. I know you've had conversations with reaperhulk along those lines already too20:21
notmynameoh you aren't scaring me off (yet)20:22
jaosoriorjvrbanac: ping20:22
hockeynutdave-mccowan 2 CRs - ACL would be dependent on multiuser20:22
hockeynutthen we could take multiuser piece and use that for generalized RBAC testing beyond just ACL20:23
hockeynutyou've done some good stuff there that we really need in more than just 1 place20:23
*** rellerreller has quit IRC20:24
reaperhulknotmyname: I need to talk to you about some ideas around seekable authenticated encryption too ;)20:24
jvrbanacjaosorior, sup20:24
notmynamereaperhulk: I understand some of those words20:24
reaperhulkhaha :)20:24
jaosoriorjvrbanac: hey man, regarding this CR what entry are you talking about? O_O20:24
hockeynutdave-mccowan I'll put some comments in the CR you have now - then we can stew on them for a bit :-)20:25
jvrbanacjaosorior, oh... oops! brain fart. Sorry, I thought we had to specify the specs in the source/index20:26
jaosoriorjvrbanac: I was looking for it and got pretty confused haha20:26
jvrbanacjaosorior, lol yeah20:27
jaosoriorlol happens20:27
dave-mccowanhockeynut  i'm definitely on board with using this framework for more general testing.  (i'm also willing to write more test cases.)  i'm willing to refactor the code to make that easier, if i have inadvertently tied it too closely to ACL.   not sure how two CRs will help the cause, but i'm open to be influenced. :-)20:28
openstackgerritMerged openstack/barbican-specs: Move data-remove-tenant-secret-assoc to Liberty
hockeynutdave-mccowan If nothing else it breaks up into 2 distinct functional enhancements.  Combining too much in one CR could also lead to global warming.20:30
redrobothockeynut everyone knows global warming is a myth ;)20:30
hockeynutfor now...but what happens if we end up combining all kinds of stuff into a single CR?  Anarchy and then global warming20:31
hockeynutat least thats what Algore says20:31
woodster_so any available reviewers for arunkant 's CR?:
woodster_lots of comments out there so far, but would be good to get folk's general opinion about the changes suggested out there20:37
dave-mccowanhockeynut one question for you.  jaosorior talked a while back about having the test sestup code add users on the fly (execute "keystone user-create")   is this what you have in mind?20:53
hockeynutdave-mccowan I would except that could be painful for folks who don't have the authority to create users on-the-fly21:00
hockeynutdave-mccowan so your way would work better - assume the users exist already21:01
dave-mccowanhockeynut cool.  i wrote code that did implemented it, and it made a mess of my dev environment when ever a test failed.   did you have anything in mind w.r.t. your comment on barbican-functional.conf to make it less integrated with the code?21:03
jaosorioranybody has time to check this one out?
redrobotjaosorior looking21:04
hockeynutdave-mccowan would love to have the users be a list where each element of the list is the id/pw/proj but not sure how to do that w/oslo config21:05
dave-mccowanhockeynut, yea that would be nicer.  although, i think the test cases would still be somewhat hardcoded, since it needs to know the expected behavior for each test for each user.21:08
hockeynutdave-mccowan yes, that is true21:08
hockeynutfor now I think its aok - then if we see an opportunity for refactor later then we can jump on it21:09
jaosoriorredrobot: thanks mr.21:12
*** xaeth is now known as xaeth_afk21:13
jaosoriorarunkant, or whoever can answer this. By the way, why is it so that in the policy file, for the secret delete, it's admin only, and not admin and creator role?21:15
jaosoriorso why "secret:delete": "rule:admin ..." and not "secret:delete": "rule:admin_or_creator_role ..." ?21:15
redrobotjaosorior creator is different than admin because creator cannot delete21:18
redrobotjaosorior otherwise, creator would be the same as admin, so no point in having two roles with the same permissions.21:19
jaosoriorbuuuut, why wouldn't I be able to delete my own secret?21:21
redrobotjaosorior because roles are used per-project21:21
jaosoriorforgot that detail21:21
jaosoriorthanks man21:22
atiwariredrobot, all getting "ArgsAlreadyParsedError: arguments already parsed: cannot register CLI option" error while running Barbican under Apache. any idea?21:22
jaosoriortherve had asked this question and I didn't know what was up there21:22
atiwari is the full exception21:22
*** kebray has quit IRC21:46
SheenaGalee_ alee_dinner: would you give me your schedule for early next week when you get back?  I want to set up a dry run time for the presentation with woodster_21:47
jaosoriorredrobot: thanks for the review man :D21:49
dave-mccowanatiwari, that error shows up in the troubleshoot guide:
*** chadlung has quit IRC21:54
*** david-lyle has joined #openstack-barbican21:56
atiwaridave-mccowan, I looked at it and I am not changing any code21:57
*** chadlung has joined #openstack-barbican21:57
atiwariI think, it some find need at
openstackgerritMerged openstack/barbican: Add Barbican configs for SQLAlchemy pool settings
openstackgerritMerged openstack/barbican: Removed extraneous
*** chlong has quit IRC21:59
*** chadlung has quit IRC22:04
*** igueths has quit IRC22:10
*** nelsnelson has quit IRC22:11
*** kebray has joined #openstack-barbican22:12
*** nkinder has quit IRC22:18
*** chadlung has joined #openstack-barbican22:29
*** pglass has quit IRC22:38
*** joesavak has quit IRC22:38
*** david-lyle has quit IRC22:38
*** kebray has quit IRC22:41
*** rm_work is now known as rm_work|away22:42
*** chadlung has quit IRC23:07
*** chadlung has joined #openstack-barbican23:08
*** chadlung has quit IRC23:12
*** arunkant_ has quit IRC23:18
*** chlong has joined #openstack-barbican23:24
openstackgerritOpenStack Proposal Bot proposed openstack/barbican: Updated from global requirements
*** nkinder has joined #openstack-barbican23:34
*** tkelsey has joined #openstack-barbican23:39
*** tkelsey has quit IRC23:43
*** rellerreller has joined #openstack-barbican23:52

Generated by 2.14.0 by Marius Gedminas - find it at!