Tuesday, 2014-10-14

*** kaitlin-farr has quit IRC00:07
*** kebray has joined #openstack-barbican00:13
*** juantwo has joined #openstack-barbican00:23
*** bdpayne has quit IRC00:24
*** kebray has quit IRC00:28
*** lisaclark1 has joined #openstack-barbican01:03
*** lisaclark1 has quit IRC01:05
*** lisaclark1 has joined #openstack-barbican01:05
*** woodster_ has quit IRC01:10
*** jorge_munoz has quit IRC01:10
*** jorge_munoz has joined #openstack-barbican01:13
*** juantwo_ has joined #openstack-barbican01:34
*** juantwo_ has quit IRC01:34
*** juantwo_ has joined #openstack-barbican01:35
*** juantwo has quit IRC01:37
*** bdpayne has joined #openstack-barbican02:17
*** gyee has quit IRC02:37
*** rm_you| has joined #openstack-barbican02:46
*** jaosorior_ has joined #openstack-barbican02:49
*** bdpayne_ has joined #openstack-barbican02:51
*** d0ugal_ has joined #openstack-barbican02:52
*** bdpayne has quit IRC02:54
*** jaosorior has quit IRC02:54
*** dimtruck has quit IRC02:54
*** jenkins-keep has quit IRC02:54
*** jillysciarilly has quit IRC02:54
*** rm_you has quit IRC02:54
*** reaperhulk has quit IRC02:54
*** jvrbanac has quit IRC02:54
*** lbragstad has quit IRC02:54
*** russell_h has quit IRC02:54
*** d0ugal has quit IRC02:54
*** d0ugal_ is now known as d0ugal02:54
*** jaosorior_ is now known as jaosorior02:54
*** d0ugal is now known as Guest8588702:54
*** jorge_munoz has quit IRC02:55
*** jvrbanac has joined #openstack-barbican02:57
*** jenkins-keep has joined #openstack-barbican03:04
*** lisaclark1 has quit IRC03:20
*** reaperhulk has joined #openstack-barbican03:21
*** russell_h has joined #openstack-barbican03:21
*** dimtruck has joined #openstack-barbican03:21
*** jillysciarilly has joined #openstack-barbican03:21
*** lbragstad has joined #openstack-barbican03:23
*** bubbva has quit IRC03:34
*** bubbva has joined #openstack-barbican03:34
*** ayoung has quit IRC03:42
*** dimtruck is now known as zz_dimtruck04:08
*** juantwo_ has quit IRC05:08
*** bdpayne_ has quit IRC05:19
*** bdpayne has joined #openstack-barbican05:19
*** russell_h has quit IRC05:27
*** russell_h has joined #openstack-barbican05:27
*** bdpayne has quit IRC06:10
*** Guest85887 has quit IRC07:32
*** Guest50275 has joined #openstack-barbican07:32
*** Guest50275 has quit IRC07:35
*** dmatthews__ has joined #openstack-barbican07:36
*** dmatthews__ has quit IRC07:46
*** dmatthews__ has joined #openstack-barbican07:47
*** dmatthews__ has quit IRC07:52
*** d0ugal has joined #openstack-barbican07:53
*** d0ugal is now known as Guest5692207:53
*** Guest56922 is now known as d0ugal07:54
*** d0ugal has joined #openstack-barbican07:54
*** davidhadas has joined #openstack-barbican09:23
*** ajc_ has joined #openstack-barbican10:34
*** ajc_ has quit IRC10:35
*** SheenaG1 has joined #openstack-barbican12:03
*** juantwo has joined #openstack-barbican12:36
*** juantwo has quit IRC12:40
*** juantwo has joined #openstack-barbican12:41
*** akoneru has quit IRC13:03
*** ayoung has joined #openstack-barbican13:14
*** paul_glass has joined #openstack-barbican13:42
*** SheenaG1 has quit IRC13:43
*** lisaclark1 has joined #openstack-barbican13:55
*** alee has quit IRC13:58
*** alee has joined #openstack-barbican14:10
*** zz_dimtruck is now known as dimtruck14:20
*** paul_glass has quit IRC14:34
*** atiwari has joined #openstack-barbican14:35
*** paul_glass has joined #openstack-barbican14:42
*** JeffF has joined #openstack-barbican14:44
*** jorge_munoz has joined #openstack-barbican14:51
*** tdink has joined #openstack-barbican14:52
*** kebray has joined #openstack-barbican14:57
*** paul_glass has quit IRC15:00
*** paul_glass has joined #openstack-barbican15:04
*** lisaclark1 has quit IRC15:04
*** lisaclark1 has joined #openstack-barbican15:15
*** gyee has joined #openstack-barbican15:20
*** lisaclark1 has quit IRC15:22
*** lisaclark1 has joined #openstack-barbican15:24
*** tdink has quit IRC15:24
*** lisaclark1 has quit IRC15:24
*** SheenaG1 has joined #openstack-barbican15:26
*** dimtruck is now known as zz_dimtruck15:32
*** zz_dimtruck is now known as dimtruck15:34
*** lisaclark1 has joined #openstack-barbican15:37
*** lisaclark1 has quit IRC15:40
*** lisaclark1 has joined #openstack-barbican15:40
*** woodster_ has joined #openstack-barbican15:58
*** SheenaG11 has joined #openstack-barbican16:00
*** SheenaG1 has quit IRC16:02
*** davidhadas has quit IRC16:06
*** paul_glass has quit IRC16:06
*** paul_glass has joined #openstack-barbican16:11
*** bdpayne has joined #openstack-barbican16:33
*** kgriffs|afk is now known as kgriffs16:34
*** paul_glass has quit IRC16:41
*** kebray has quit IRC16:47
*** paul_glass has joined #openstack-barbican16:49
*** lisaclark1 has quit IRC16:57
*** bdpayne_ has joined #openstack-barbican17:06
*** bdpayne has quit IRC17:09
*** bdpayne_ has quit IRC17:11
*** tdink has joined #openstack-barbican17:13
*** SheenaG11 has quit IRC17:19
*** bdpayne has joined #openstack-barbican17:31
*** paul_glass has quit IRC17:41
*** tdink has quit IRC18:00
*** d0ugal has quit IRC18:04
*** d0ugal has joined #openstack-barbican18:06
*** d0ugal is now known as Guest8657818:06
*** SheenaG1 has joined #openstack-barbican18:07
*** lisaclark1 has joined #openstack-barbican18:09
*** lisaclark1 has quit IRC18:09
*** SheenaG11 has joined #openstack-barbican18:11
*** SheenaG1 has quit IRC18:11
*** paul_glass has joined #openstack-barbican18:12
*** lisaclark1 has joined #openstack-barbican18:15
*** lisaclark1 has quit IRC18:17
*** lisaclark1 has joined #openstack-barbican18:17
*** lisaclark1 has quit IRC18:30
*** nkinder is now known as not_jamielennox18:34
*** not_jamielennox is now known as nkinder18:37
openstackgerritAde Lee proposed a change to openstack/barbican-specs: Spec for secret pre-encryption  https://review.openstack.org/12840118:40
*** lisaclark1 has joined #openstack-barbican18:41
aleerm_work, ping18:49
aleeredrobot, ping18:49
redrobotalee png18:50
aleeredrobot, hey -can we restore the cert api spec for kilo?18:50
aleeredrobot, used to be in juno ..18:50
aleewoodster_, rm_work - got a couple of specs that you'll probably be interested in - https://review.openstack.org/#/c/127353/ and https://review.openstack.org/#/c/128401/18:52
aleeredrobot, also, had a chance to look at the dogtag recipe?18:53
rm_workalee: I really feel like the per-secret should be done at the keystone level, but i guess it's possible we may not be able to count on that happening essentially ever18:53
rm_workalee: and it'd also need to allow for per-container18:53
aleerm_work, even keystone has logic to do policy per target.18:54
rm_workerr, internally?18:54
rm_workbecause they don't seem to support it externally :/18:54
aleerm_work, yup18:54
rm_workyeah but keystone would HAVE to, since it'd be Keystone that should do it for us too :P18:55
aleerm_work, we defer to keystone for auth/authz and that gives us the top level policy18:55
aleebut we are responsible for our own poicy.json18:55
rm_workyeah but Keystone should really be adding per-resource policies/trusts18:56
rm_workI am tempted to agree with adding this BP in the meantime though, since "the meantime" could be the next several years18:56
aleerm_work, I'm really not sure centralizing it at that level is scaleable18:56
aleeseems like each service should control per-resource policies for their own resource18:57
rm_workalee: it'd be the same number of calls, which is really where i'd worry about scalability18:57
rm_workthey can add a few extra rows to their DB18:57
jaosorioralee: just read this one: https://review.openstack.org/#/c/128401/1 So far seems to be good stuff, would just like it to pass the gate, and then I'll re-read it to give proper input18:57
rm_workDB Scaling is fairly well solved18:57
rm_workat least on this scale18:57
rm_workwe're not talking about google-level scaling here :P18:58
aleejaosorior, cool - will get it through gate ..18:58
nkinderrm_work: so what is it that you would expect keystone to maintain to allow per-secret/container policy?18:58
rm_worknkinder: i believe there was a BP a while back that never made it anywhere, let me see if I can find it18:59
openstackgerritA change was merged to openstack/barbican: Cleaning up secret functional tests  https://review.openstack.org/12543519:00
rm_worknkinder: failing at finding it (my spec searching skills aren't up to par, apparently)19:02
rm_worknkinder: but essentially, expanding the role mapping system to include mapping roles for specific resources19:02
nkinderrm_work: https://blueprints.launchpad.net/keystone/+spec/attribute-access-privilege-based-on-role ?19:02
rm_worksimilar maybe, but not the one I was thinking of19:03
*** kebray has joined #openstack-barbican19:04
rm_workso right now the role mapping is like, barbican-admin:some_user19:04
openstackgerritAde Lee proposed a change to openstack/barbican-specs: Spec for secret pre-encryption  https://review.openstack.org/12840119:04
aleejaosorior, that should pass the gate.19:04
rm_worknkinder: essentially, right?19:05
rm_workI'd assume it'd need to be split such that the existing mapping would equate to: barbican-admin:some_project:some_user:*19:06
rm_workand you could also do: barbican-admin:some_project:some_user:containers/27AC6A30-9747-422A-9D50-64B766A4DBC519:06
nkinderok, but where would that be stored?19:07
rm_workwherever keystone stores the role mappings currently?19:07
nkinderso you want keystone to keep track of the container IDs for barbican?19:08
rm_worknot all of them19:08
rm_workbut when a user wants to trust a specific service or other user with a specific resource, then yes19:08
nkinderAnd to communicate that information, we would need to shove the specifics in the token19:08
nkinderso tokens get large (which is already a big problem)19:08
nkinderI see barbican being the owner of the containers19:09
rm_workwhen a user auths, they get a token, they pass the token to barbican, doesn't barbican then go ask keystone "is this token valid for this user, this role, etc"?19:09
rm_workcan't that query include "this resource"?19:09
nkinderbut that requires registering every resource inside of Keystone (for every service that wants to work this way)19:10
rm_worki'm thinking of this as literally just a string19:10
jaosorioralee: awesome, ill give it a thought and then comment. But so far seems good. Gotta go now19:10
rm_workonly the specific resources that people want to share in this way would be mapped like that19:10
aleejaosorior, thanks19:11
rm_workas I was saying, the current wide-open mapping would just be *19:11
nkinderrm_work: but at a large scale, that has the potential to be a lot of info19:11
rm_workeverything that exists now, would only grow in size by one character19:11
rm_workso it's whatever potential usage the feature would see19:11
rm_workand Trusts using * would still exist19:12
rm_workso any case where users want EVERY resource mapped, they just use that and it's also the same as present19:12
rm_workthe only case where additional info is generated is the case where specific resources need to be shared19:12
rm_workwhich I think might be a somewhat popular use-case (hard to tell, since nothing similar is available currently) but since it's specifically in the middle between "no change" and "no change", I don't see it being that massive19:13
nkinderThere's sort of a related discussion on -dev about policy right now, at least with regards to embedding things like capabilities into tokens (it seems simlar enough to resources)19:13
nkinderrm_work: why shouldn't baribican just have the ability to define who can access a particular resource that it manages?19:14
nkinderrm_work: similar to keeping an "owner" of a container19:14
rm_worknkinder: it just feels like an auth->keystone-y thing19:14
nkinder...but "allowed_users" or similar19:14
rm_worknkinder: if you really don't feel like it's something keystone should or ever will manage19:14
rm_workthen we should by all means go ahead and do it19:15
nkindersort of, but the endpoints like barbican are responsible for enforcement and management of their own resources19:15
rm_workbut it feels like an opportunity to prevent splintering the way that functionality works19:15
rm_workwhich is about to happen19:15
rm_workand to prevent a lot of duplication of effort19:15
rm_workwell, we manage our own resources with regard to "this role is required", but19:16
nkinderI do see keystone as being a good central place for policy, but it comes down to the endpoint to perform the enforcement.  I'd need to see how other projects like nova use oslo.policy's "target" capabilities19:16
rm_workin this case it'd just be keystone granting that particular role to someone else :)19:16
nkinderdon't you also perform project/tenant comparisons to see who owns a container?19:16
rm_workwe do now, but only because we don't have another option IMO19:17
rm_workif including the resource in keystone was an option, i'd at least personally prefer to do that19:17
rm_workanyway, I'm *ok* doing it internally, but I feel like it's not the optimal approach19:18
nkinderrm_work: we're going to have a keystone policy session at the summit, so this would be a good topic to discuss there in more detail19:18
rm_worknkinder: yeah, wish I was able to go >_<19:19
rm_workI was going originally, but my trip got canned last-minute19:19
rm_workthis is about the third thing that i'd like to participate in discussion on but won't be able to19:19
rm_workah well19:19
aleerm_work, incidentally just responded to your comment to https://review.openstack.org/#/c/127823/119:22
nkinderrm_work: so it looks like nova does some basic stuff with oslo.policy like this - "admin_or_owner":  "is_admin:True or project_id:%(project_id)s"19:23
nkinderrm_work: so that's matching the project_id from the token with the project_id of the target resource19:23
nkinderkeystone does some more advanced things to leverage the target functionality of oslo.policy19:23
rm_workbut they do still query back to keystone to check key validity/etc right?19:24
nkinderrm_work: key validitity?19:25
rm_workalee: yeah I don't know what Cinder is doing right now, entirely possible they *are* making copies of secrets19:25
rm_worknkinder: IE, the key the user passed me isn't expired or made up19:25
nkinderrm_work: if a token is valid, then the project_id in the token is trusted to be correct19:25
nkinderrm_work: It depends on the token format.  If it's a UUID token, a basic UUID is provided by the user.19:26
nkinderYou have to fetch the token from keystone using that UUID blob, and you get the token back19:26
rm_worknkinder: yeah but doesn't the service have to make a call back to keystone to validate that the token is, well, vaiid? not expired, not bade up19:26
rm_work*made up19:26
nkinderIf it's a PKI token, the user gives you a signed token19:26
nkinderyou just check the signature using the matching public key (cert)19:27
rm_workis the expiration time of the token included IN the token?19:27
aleerm_work, looks like they are. so it will be useful to see what they decide they like better19:27
nkinderand you can fetch a revocation list on a normal interval, just like CRLs in the PKI world19:27
rm_worksomehow that contains the validity time and project ID in a verifiable and non-forgeable way?19:27
nkinderrm_work: that is not a PKI token19:28
rm_workok, I guess we don't use PKI tokens19:28
rm_workthe tokens we use are just UUIDs19:28
nkinderit's a configuration option, so you might have either type19:28
rm_workmy assumption is that the service takes the UUID from the header and checks it with keystone19:28
rm_workat call-time19:28
nkinderYes, that is correct for UUID tokens (or it has cached copies)19:29
nkinderit's a "validate" call19:29
rm_workok, so the point being that while it wouldn't be a big deal to add this functionality i'm discussing to the UUID tokens, for PKI tokens it would be problematic19:29
nkinderand if it's valid, you get a copy of the user19:29
nkinderuser's token19:29
nkinderthe token format is the same either way though inside19:30
nkinderyou want the validate call to take an additional argument, right?19:30
rm_workbut since that wouldn't be called with the PKI token, it'd be problematic because the PKI token would be HUGE if it included a list of every viable resource for a user19:30
rm_workwhich I think was your point19:30
rm_workbut for the UUID tokens with a validate call, it could return a token with just the requested resource19:31
rm_workbecause it knows what resource is being tested19:31
nkinderyes, if keystone had the ability for those resources ot be registered with it19:31
rm_workbut if it has to work for both types of tokens, we're still hosed since PKI doesn't work19:31
rm_work1/2 is not good enough :/19:32
rm_workso I guess my misconception was that UUID tokens and their associated validation workflow were the only method19:32
rm_worksince that's all i've seen19:32
nkinderrm_work: yeah, PKI was the default in Icehouse19:33
nkinderIt's switched back to UUID, mainly due to token size problems19:33
nkinderbut they are both available, and both valid use cases19:33
nkinderrm_work: maybe get some other barbican folks to come to our policy session and we can discuss this problem some at the summit.  Bummer you won't be there. :(19:34
rm_workalee: I see their code there, I just wonder WHY they're using copy_key19:35
rm_worknkinder: yeah, I'll bug redrobot to go represent my interests, if he's not swamped being the new PTL :)19:35
nkinderrm_work: I think anything we can do to avoid having to use trusts for this basic case would be ideal19:36
rm_workalee: if they're using copy_key to make a copy of end-user data, then that's what registration is for19:36
rm_worknkinder: agreed19:36
rm_workalee: if they're using copy_key to make copies of internal data, then... wtf19:37
nkinderrm_work: I'd much prefer if I could just create a secret and say "let this LBaaS user ID access this secret" at secret creation time19:37
rm_worknkinder: yeah, that'd be good19:37
rm_worknkinder: though I doubt users will know at creation every service that'll need access19:38
rm_workso it'd be 50:50 calling barbican to add a user to a secret, vs. calling keystone to do it19:38
nkinderrm_work: yeah, one would need to be able to grant access to other users after the fact19:40
aleerm_work, well in the spec, I note that the users allowed can be modified after the fact19:40
nkinderrm_work: but I'm assuming that there is already an update call for containers/secrets19:40
aleeusing the PUT operation19:40
rm_worknkinder: containers/secrets are immutable19:40
nkinderyeah, standard U from CRUD19:40
nkinderoh, interesting19:41
rm_workpossibly metadata?19:41
rm_workbut right now it's not common to update them19:41
nkinderif metadata linked to the container/secret?19:41
rm_workso, I just finished rewriting the client19:41
aleerm_work, the secresta are immutable, but not the metadata19:41
rm_workand there's definitely no way to have it do an update :P19:41
rm_workjust FYI19:41
rm_workso if that's incorrect, we need to make some changes to python-barbicanclient :)19:42
rm_workI have literally *never* done anything but POST and GET to Barbican19:42
aleerm_work, so we don't support the 2 step secret creation process?19:43
nkinderis there an API doc for barbican?19:43
rm_workalee: err... ok, that might be in there19:43
aleenkinder, there is a PUT operation ..19:43
aleefor secrets19:43
rm_workI never tested it personally though, the unit tests did pass :)19:43
aleerm_work, I plan to start poking around in the client very soon to start adding the transport cert stuff. that will require looking at the PUT operation.19:44
rm_workOK Yeah, the two step does a PUT19:44
rm_workbut that's the only one19:44
rm_workContainers has no way to do a PUT right now19:44
aleerm_work, right - we'll probably need to add that19:45
aleeits probably not in the api yet19:45
rm_worknkinder: https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface19:45
*** lisaclark1 has quit IRC19:45
nkinderrm_work: thanks!19:46
rm_workyeah, order/container have no PUT currently19:46
rm_workand for Secrets: Note that a PUT request can only be performed once after a POST call that does not include a payload.19:46
rm_workso... yeah19:46
nkinderyeah, most things are immutable19:47
rm_workall objects are immutable except a very special case for Secrets19:47
nkinderso that would need to change, as you now have a reason for something to be updated at a later point in time.  The majority of things would still be immutable though19:47
rm_workthough I might be more amenable to adding a subresource for auth stuff19:48
rm_workit doesn't need to be returned by default IMO19:48
rm_workI'd do secrets/<uuid>/allowed_users19:48
rm_workor something like that19:48
nkinderthat's a valid approach, and provides some separation19:48
rm_workprobably modeled similarly to the register subresource19:49
rm_workPOST to add (idempotent), DELETE to remove19:49
rm_workthough I may be one of the very few fans of DELETE by Body19:50
rm_workconsidering I had to change the delete functions to even be able to pass a body <_<19:50
rm_workalee: were you going to take the coding tasks for that BP if it goes through?19:51
rm_workalee: I might be able to do it, if you weren't set on it (depends on how I frame it in my sprint meeting :P)19:51
aleerm_work, some of them perhaps.  I'm hoping to recruit others -- like you :)19:52
rm_workok, cause my brain is already coding it in my subconscious]19:52
aleerm_work, I didn;t want to put you down till you volunteered :)19:52
* redrobot catches up19:52
redrobotalee plese re-submit any juno BPs that need to be re-reviewed for Kilo19:53
redrobotalee also, have not had time to look at chef stuff... I may not be able to get to it until Paris... might be better anyway so I can bug you if/when I get stuck.19:53
aleeredrobot, well its not originally my BP -- and it would be nice to keep the comments.19:53
aleeredrobot, there is a lot of useful stuff in the comments -- if we can keep them, that would be super.19:54
rm_workwoo, Openbook >_>19:54
* rm_work heads to the coolaid19:55
redrobotalee we had agreed a while back to re-write blueprints for the new cycle.  You can always point to the previous review in the new BP.  Will that work for you?19:56
redrobotrm_work you get more vacation, and I get more vacation, MORE VACATION FOR EVERYBODY!19:56
aleeredrobot, I suppose - I think we need to revisit that procedure though .. if there is an easy way to move a blueprint to the new release, then we shoudl do that.19:59
*** JeffF has quit IRC20:02
*** lisaclark1 has joined #openstack-barbican20:05
aleeatiwari, ping20:06
*** lisaclark1 has quit IRC20:06
*** JeffF has joined #openstack-barbican20:08
*** lisaclark1 has joined #openstack-barbican20:08
*** SheenaG11 has quit IRC20:14
JeffFhey alee or chellygel or woodster_ when we are ready to submit our work, what do we need to do in order to contribute our work to OpenStack.  Do we need rights to checkin?  Email? Gerrit Review process? PIP installable module? what?20:24
chellygelhey JeffF!20:25
chellygeltheres actually a great setup guide on the wiki for getting gerrit rolling -- i think20:25
chellygelYou'll have to sign  up for the OpenStack foundation... if you ahvent done that already20:25
JeffFI was skimming over that this morning for a few minutes20:25
*** paul_glass has quit IRC20:25
chellygelthen you'll have to edit your commits for the e-mail associated w/ OpenStack foundation e-mail (or you'll have to add that e-mail in addition)20:25
chellygelyou will more than likely install git-review20:26
JeffFchellygel: is that at this page? https://github.com/cloudkeep/barbican/wiki/Gerrit-Review-Process20:26
chellygelthen all you have to do is just "git review" and away the code goes into gerrit -- have you seen the reviews page yet?20:26
chellygelJeffF, yes -- also there is a gerrit one for openstack proper let me link it to you20:27
chellygel^This is where the reviews for gerrit are done -- you sign in w / your openstack foundation information20:28
chellygeli suggest following the projects: "openstack/barbican", "openstack/barbican-specs",and "openstack/python-barbicanclient"20:28
JeffFok.  I'll go sign up for that soon.20:29
chellygelJeffF,  https://wiki.openstack.org/wiki/Gerrit_Workflow this has a more top level explanation on gerrit20:29
chellygeland should help you get set up w/ OS foundation20:29
JeffFwe aren't quite ready yet, but I just didn't want to wait until the last minute not knowing exactly how to package and check-in.20:30
chellygeli highly recommend checking by reviewing some code first (using your +1 powers!)20:30
chellygeland you are more than welcome to send it up for early review (-1 workflowing it) so that people can get eyes on to start voting ahead of time20:30
chellygeldon't hesitate to reach out to me when you want to set it up -- i'd be happy to walk you through it :D20:31
*** kebray has quit IRC20:31
chellygelwe can even jump on a call or hangouts if thats easiest20:31
JeffFok, that will be helpful I'm sure.  so we've created a module that talks to our API.  should I create a setup for it so it's pip'able, or what?20:31
JeffFit's very similar to the symantec client, symantecssl20:32
chellygelfor symantec we have our own external api library for thatttt....20:32
JeffFyes, we have created one very similar to that that talks to our API.  should I create a setup for this so it can be PIP installed?20:33
JeffFbecause it will have to accompany our barbican plugin20:33
JeffFis that the correct pattern?20:34
chellygelno, it isnt required to be that way20:34
chellygelbut sure -- why not? if you want? if you think your library will be generally used :D20:35
*** paul_glass has joined #openstack-barbican20:36
JeffFwho knows, but since the barbican plugin depends on it, then I guess it should be easy to setup.20:36
*** lisaclark1 has quit IRC20:36
*** openstackgerrit has quit IRC20:36
JeffFok.  last thing, just a few minutes ago, we got orders for other business priorities for the next short term.  so I'm redirecting back to DigiCert priorities and we'll be back to wrap up openstack after a bit. so if you don't hear from me in the next little while, I'll be back.20:37
JeffFthank you so much for your help chellygel!20:38
chellygelno worries JeffF -- i would suggest putting that code in for early review so you can get feedback int he meantime!!20:38
JeffFgood idea20:38
chellygelJeffF, more than happy to !!20:38
*** lisaclark1 has joined #openstack-barbican20:42
*** kebray has joined #openstack-barbican20:48
*** gyee has quit IRC20:57
*** juantwo has quit IRC21:03
atiwarialee, whats up. sorry did not see your ping21:07
*** lisaclark1 has quit IRC21:08
*** ryanpetrello has quit IRC21:11
*** ryanpetrello has joined #openstack-barbican21:11
*** jaosorior has quit IRC21:13
*** SheenaG1 has joined #openstack-barbican21:15
*** ryanpetrello has quit IRC21:15
*** atiwari has quit IRC21:17
*** SheenaG11 has joined #openstack-barbican21:18
*** ryanpetrello has joined #openstack-barbican21:19
*** SheenaG1 has quit IRC21:19
*** gyee has joined #openstack-barbican21:30
*** lisaclark1 has joined #openstack-barbican21:32
*** JeffF has left #openstack-barbican21:36
ryanpetrellowho's PTL for K?21:45
chellygelthe wonderful redrobot !21:46
chellygel^( ^_^) that guy21:46
*** paul_glass has quit IRC21:54
*** juantwo has joined #openstack-barbican22:03
*** ayoung has quit IRC22:03
rm_workalee: put my thoughts together cohesively as a comment on https://review.openstack.org/#/c/127353/22:05
rm_worksince it looks like handling it internally is the direction we'll need to go22:05
rm_workredrobot: did you guys end up doing tacos today?22:07
redrobotrm_work nope, sprint planning + hotdogs for lunch22:07
redrobotrm_work we grilled the dogs in the break room22:07
rm_workwell, I could treat you guys to some tacos tomorrow if you guys are down :P22:07
redrobothell to the m-f yeah!22:07
redrobotchellygel ^^22:07
chellygelo/ is in22:08
chellygelerick's is actually open on wednesdays22:08
rm_worklookin' forward to some corn on a cup22:08
chellygelyou get it rm_work !!!22:09
chellygelthe looks i get calling corn on a cup are priceless22:09
*** lisaclark1 has quit IRC22:09
rm_workit's *technically* correct22:09
rm_workit is *on* the surface of the cup22:10
rm_work"in a cup" is a subset of "on a cup" :P22:10
rm_workthough it is amusing that they still haven't bothered to fix the sign :P22:10
*** lisaclark1 has joined #openstack-barbican22:11
redrobotI don't think Erick is aware the sign is broken22:12
*** jorge_munoz has quit IRC22:13
*** lisaclark1 has quit IRC22:24
*** openstackgerrit has joined #openstack-barbican23:02
*** dimtruck is now known as zz_dimtruck23:02
*** kebray has quit IRC23:13
*** SheenaG11 has quit IRC23:45
*** lisaclark1 has joined #openstack-barbican23:57
*** lisaclark1 has quit IRC23:57

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