| *** kaitlin-farr has quit IRC | 00:07 | |
| *** kebray has joined #openstack-barbican | 00:13 | |
| *** juantwo has joined #openstack-barbican | 00:23 | |
| *** bdpayne has quit IRC | 00:24 | |
| *** kebray has quit IRC | 00:28 | |
| *** lisaclark1 has joined #openstack-barbican | 01:03 | |
| *** lisaclark1 has quit IRC | 01:05 | |
| *** lisaclark1 has joined #openstack-barbican | 01:05 | |
| *** woodster_ has quit IRC | 01:10 | |
| *** jorge_munoz has quit IRC | 01:10 | |
| *** jorge_munoz has joined #openstack-barbican | 01:13 | |
| *** juantwo_ has joined #openstack-barbican | 01:34 | |
| *** juantwo_ has quit IRC | 01:34 | |
| *** juantwo_ has joined #openstack-barbican | 01:35 | |
| *** juantwo has quit IRC | 01:37 | |
| *** bdpayne has joined #openstack-barbican | 02:17 | |
| *** gyee has quit IRC | 02:37 | |
| *** rm_you| has joined #openstack-barbican | 02:46 | |
| *** jaosorior_ has joined #openstack-barbican | 02:49 | |
| *** bdpayne_ has joined #openstack-barbican | 02:51 | |
| *** d0ugal_ has joined #openstack-barbican | 02:52 | |
| *** bdpayne has quit IRC | 02:54 | |
| *** jaosorior has quit IRC | 02:54 | |
| *** dimtruck has quit IRC | 02:54 | |
| *** jenkins-keep has quit IRC | 02:54 | |
| *** jillysciarilly has quit IRC | 02:54 | |
| *** rm_you has quit IRC | 02:54 | |
| *** reaperhulk has quit IRC | 02:54 | |
| *** jvrbanac has quit IRC | 02:54 | |
| *** lbragstad has quit IRC | 02:54 | |
| *** russell_h has quit IRC | 02:54 | |
| *** d0ugal has quit IRC | 02:54 | |
| *** d0ugal_ is now known as d0ugal | 02:54 | |
| *** jaosorior_ is now known as jaosorior | 02:54 | |
| *** d0ugal is now known as Guest85887 | 02:54 | |
| *** jorge_munoz has quit IRC | 02:55 | |
| *** jvrbanac has joined #openstack-barbican | 02:57 | |
| *** jenkins-keep has joined #openstack-barbican | 03:04 | |
| *** lisaclark1 has quit IRC | 03:20 | |
| *** reaperhulk has joined #openstack-barbican | 03:21 | |
| *** russell_h has joined #openstack-barbican | 03:21 | |
| *** dimtruck has joined #openstack-barbican | 03:21 | |
| *** jillysciarilly has joined #openstack-barbican | 03:21 | |
| *** lbragstad has joined #openstack-barbican | 03:23 | |
| *** bubbva has quit IRC | 03:34 | |
| *** bubbva has joined #openstack-barbican | 03:34 | |
| *** ayoung has quit IRC | 03:42 | |
| *** dimtruck is now known as zz_dimtruck | 04:08 | |
| *** juantwo_ has quit IRC | 05:08 | |
| *** bdpayne_ has quit IRC | 05:19 | |
| *** bdpayne has joined #openstack-barbican | 05:19 | |
| *** russell_h has quit IRC | 05:27 | |
| *** russell_h has joined #openstack-barbican | 05:27 | |
| *** bdpayne has quit IRC | 06:10 | |
| *** Guest85887 has quit IRC | 07:32 | |
| *** Guest50275 has joined #openstack-barbican | 07:32 | |
| *** Guest50275 has quit IRC | 07:35 | |
| *** dmatthews__ has joined #openstack-barbican | 07:36 | |
| *** dmatthews__ has quit IRC | 07:46 | |
| *** dmatthews__ has joined #openstack-barbican | 07:47 | |
| *** dmatthews__ has quit IRC | 07:52 | |
| *** d0ugal has joined #openstack-barbican | 07:53 | |
| *** d0ugal is now known as Guest56922 | 07:53 | |
| *** Guest56922 is now known as d0ugal | 07:54 | |
| *** d0ugal has joined #openstack-barbican | 07:54 | |
| *** davidhadas has joined #openstack-barbican | 09:23 | |
| *** ajc_ has joined #openstack-barbican | 10:34 | |
| *** ajc_ has quit IRC | 10:35 | |
| *** SheenaG1 has joined #openstack-barbican | 12:03 | |
| *** juantwo has joined #openstack-barbican | 12:36 | |
| *** juantwo has quit IRC | 12:40 | |
| *** juantwo has joined #openstack-barbican | 12:41 | |
| *** akoneru has quit IRC | 13:03 | |
| *** ayoung has joined #openstack-barbican | 13:14 | |
| *** paul_glass has joined #openstack-barbican | 13:42 | |
| *** SheenaG1 has quit IRC | 13:43 | |
| *** lisaclark1 has joined #openstack-barbican | 13:55 | |
| *** alee has quit IRC | 13:58 | |
| *** alee has joined #openstack-barbican | 14:10 | |
| *** zz_dimtruck is now known as dimtruck | 14:20 | |
| *** paul_glass has quit IRC | 14:34 | |
| *** atiwari has joined #openstack-barbican | 14:35 | |
| *** paul_glass has joined #openstack-barbican | 14:42 | |
| *** JeffF has joined #openstack-barbican | 14:44 | |
| *** jorge_munoz has joined #openstack-barbican | 14:51 | |
| *** tdink has joined #openstack-barbican | 14:52 | |
| *** kebray has joined #openstack-barbican | 14:57 | |
| *** paul_glass has quit IRC | 15:00 | |
| *** paul_glass has joined #openstack-barbican | 15:04 | |
| *** lisaclark1 has quit IRC | 15:04 | |
| *** lisaclark1 has joined #openstack-barbican | 15:15 | |
| *** gyee has joined #openstack-barbican | 15:20 | |
| *** lisaclark1 has quit IRC | 15:22 | |
| *** lisaclark1 has joined #openstack-barbican | 15:24 | |
| *** tdink has quit IRC | 15:24 | |
| *** lisaclark1 has quit IRC | 15:24 | |
| *** SheenaG1 has joined #openstack-barbican | 15:26 | |
| *** dimtruck is now known as zz_dimtruck | 15:32 | |
| *** zz_dimtruck is now known as dimtruck | 15:34 | |
| *** lisaclark1 has joined #openstack-barbican | 15:37 | |
| *** lisaclark1 has quit IRC | 15:40 | |
| *** lisaclark1 has joined #openstack-barbican | 15:40 | |
| *** woodster_ has joined #openstack-barbican | 15:58 | |
| *** SheenaG11 has joined #openstack-barbican | 16:00 | |
| *** SheenaG1 has quit IRC | 16:02 | |
| *** davidhadas has quit IRC | 16:06 | |
| *** paul_glass has quit IRC | 16:06 | |
| *** paul_glass has joined #openstack-barbican | 16:11 | |
| *** bdpayne has joined #openstack-barbican | 16:33 | |
| *** kgriffs|afk is now known as kgriffs | 16:34 | |
| *** paul_glass has quit IRC | 16:41 | |
| *** kebray has quit IRC | 16:47 | |
| *** paul_glass has joined #openstack-barbican | 16:49 | |
| *** lisaclark1 has quit IRC | 16:57 | |
| *** bdpayne_ has joined #openstack-barbican | 17:06 | |
| *** bdpayne has quit IRC | 17:09 | |
| *** bdpayne_ has quit IRC | 17:11 | |
| *** tdink has joined #openstack-barbican | 17:13 | |
| *** SheenaG11 has quit IRC | 17:19 | |
| *** bdpayne has joined #openstack-barbican | 17:31 | |
| *** paul_glass has quit IRC | 17:41 | |
| *** tdink has quit IRC | 18:00 | |
| *** d0ugal has quit IRC | 18:04 | |
| *** d0ugal has joined #openstack-barbican | 18:06 | |
| *** d0ugal is now known as Guest86578 | 18:06 | |
| *** SheenaG1 has joined #openstack-barbican | 18:07 | |
| *** lisaclark1 has joined #openstack-barbican | 18:09 | |
| *** lisaclark1 has quit IRC | 18:09 | |
| *** SheenaG11 has joined #openstack-barbican | 18:11 | |
| *** SheenaG1 has quit IRC | 18:11 | |
| *** paul_glass has joined #openstack-barbican | 18:12 | |
| *** lisaclark1 has joined #openstack-barbican | 18:15 | |
| *** lisaclark1 has quit IRC | 18:17 | |
| *** lisaclark1 has joined #openstack-barbican | 18:17 | |
| *** lisaclark1 has quit IRC | 18:30 | |
| *** nkinder is now known as not_jamielennox | 18:34 | |
| *** not_jamielennox is now known as nkinder | 18:37 | |
| openstackgerrit | Ade Lee proposed a change to openstack/barbican-specs: Spec for secret pre-encryption https://review.openstack.org/128401 | 18:40 |
|---|---|---|
| *** lisaclark1 has joined #openstack-barbican | 18:41 | |
| alee | rm_work, ping | 18:49 |
| alee | redrobot, ping | 18:49 |
| redrobot | alee png | 18:50 |
| alee | redrobot, hey -can we restore the cert api spec for kilo? | 18:50 |
| alee | redrobot, used to be in juno .. | 18:50 |
| alee | woodster_, 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 |
| alee | redrobot, also, had a chance to look at the dogtag recipe? | 18:53 |
| rm_work | alee: 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 ever | 18:53 |
| rm_work | alee: and it'd also need to allow for per-container | 18:53 |
| alee | rm_work, even keystone has logic to do policy per target. | 18:54 |
| rm_work | err, internally? | 18:54 |
| rm_work | because they don't seem to support it externally :/ | 18:54 |
| alee | rm_work, yup | 18:54 |
| rm_work | yeah but keystone would HAVE to, since it'd be Keystone that should do it for us too :P | 18:55 |
| alee | rm_work, we defer to keystone for auth/authz and that gives us the top level policy | 18:55 |
| alee | but we are responsible for our own poicy.json | 18:55 |
| rm_work | yeah but Keystone should really be adding per-resource policies/trusts | 18:56 |
| rm_work | I am tempted to agree with adding this BP in the meantime though, since "the meantime" could be the next several years | 18:56 |
| alee | rm_work, I'm really not sure centralizing it at that level is scaleable | 18:56 |
| alee | seems like each service should control per-resource policies for their own resource | 18:57 |
| rm_work | alee: it'd be the same number of calls, which is really where i'd worry about scalability | 18:57 |
| rm_work | they can add a few extra rows to their DB | 18:57 |
| jaosorior | alee: 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 input | 18:57 |
| rm_work | DB Scaling is fairly well solved | 18:57 |
| rm_work | at least on this scale | 18:57 |
| rm_work | we're not talking about google-level scaling here :P | 18:58 |
| alee | jaosorior, cool - will get it through gate .. | 18:58 |
| nkinder | rm_work: so what is it that you would expect keystone to maintain to allow per-secret/container policy? | 18:58 |
| rm_work | nkinder: i believe there was a BP a while back that never made it anywhere, let me see if I can find it | 18:59 |
| openstackgerrit | A change was merged to openstack/barbican: Cleaning up secret functional tests https://review.openstack.org/125435 | 19:00 |
| rm_work | nkinder: failing at finding it (my spec searching skills aren't up to par, apparently) | 19:02 |
| rm_work | nkinder: but essentially, expanding the role mapping system to include mapping roles for specific resources | 19:02 |
| nkinder | rm_work: https://blueprints.launchpad.net/keystone/+spec/attribute-access-privilege-based-on-role ? | 19:02 |
| rm_work | hmm | 19:03 |
| rm_work | similar maybe, but not the one I was thinking of | 19:03 |
| *** kebray has joined #openstack-barbican | 19:04 | |
| rm_work | so right now the role mapping is like, barbican-admin:some_user | 19:04 |
| openstackgerrit | Ade Lee proposed a change to openstack/barbican-specs: Spec for secret pre-encryption https://review.openstack.org/128401 | 19:04 |
| rm_work | err | 19:04 |
| alee | jaosorior, that should pass the gate. | 19:04 |
| rm_work | barbican-admin:some_project:some_user | 19:04 |
| rm_work | nkinder: essentially, right? | 19:05 |
| rm_work | I'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_work | and you could also do: barbican-admin:some_project:some_user:containers/27AC6A30-9747-422A-9D50-64B766A4DBC5 | 19:06 |
| nkinder | ok, but where would that be stored? | 19:07 |
| rm_work | wherever keystone stores the role mappings currently? | 19:07 |
| nkinder | so you want keystone to keep track of the container IDs for barbican? | 19:08 |
| rm_work | not all of them | 19:08 |
| rm_work | but when a user wants to trust a specific service or other user with a specific resource, then yes | 19:08 |
| nkinder | And to communicate that information, we would need to shove the specifics in the token | 19:08 |
| nkinder | so tokens get large (which is already a big problem) | 19:08 |
| rm_work | hmm | 19:09 |
| nkinder | I see barbican being the owner of the containers | 19:09 |
| rm_work | well | 19:09 |
| rm_work | when 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_work | can't that query include "this resource"? | 19:09 |
| nkinder | but that requires registering every resource inside of Keystone (for every service that wants to work this way) | 19:10 |
| rm_work | i'm thinking of this as literally just a string | 19:10 |
| jaosorior | alee: awesome, ill give it a thought and then comment. But so far seems good. Gotta go now | 19:10 |
| rm_work | only the specific resources that people want to share in this way would be mapped like that | 19:10 |
| alee | jaosorior, thanks | 19:11 |
| rm_work | as I was saying, the current wide-open mapping would just be * | 19:11 |
| nkinder | rm_work: but at a large scale, that has the potential to be a lot of info | 19:11 |
| rm_work | well | 19:11 |
| rm_work | everything that exists now, would only grow in size by one character | 19:11 |
| rm_work | so it's whatever potential usage the feature would see | 19:11 |
| rm_work | and Trusts using * would still exist | 19:12 |
| rm_work | so any case where users want EVERY resource mapped, they just use that and it's also the same as present | 19:12 |
| rm_work | the only case where additional info is generated is the case where specific resources need to be shared | 19:12 |
| rm_work | which 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 massive | 19:13 |
| nkinder | There'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 |
| nkinder | rm_work: why shouldn't baribican just have the ability to define who can access a particular resource that it manages? | 19:14 |
| nkinder | rm_work: similar to keeping an "owner" of a container | 19:14 |
| rm_work | nkinder: it just feels like an auth->keystone-y thing | 19:14 |
| nkinder | ...but "allowed_users" or similar | 19:14 |
| rm_work | nkinder: if you really don't feel like it's something keystone should or ever will manage | 19:14 |
| rm_work | then we should by all means go ahead and do it | 19:15 |
| nkinder | sort of, but the endpoints like barbican are responsible for enforcement and management of their own resources | 19:15 |
| rm_work | but it feels like an opportunity to prevent splintering the way that functionality works | 19:15 |
| rm_work | which is about to happen | 19:15 |
| rm_work | and to prevent a lot of duplication of effort | 19:15 |
| rm_work | well, we manage our own resources with regard to "this role is required", but | 19:16 |
| nkinder | I 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" capabilities | 19:16 |
| rm_work | in this case it'd just be keystone granting that particular role to someone else :) | 19:16 |
| rm_work | hmm | 19:16 |
| nkinder | don't you also perform project/tenant comparisons to see who owns a container? | 19:16 |
| rm_work | we do now, but only because we don't have another option IMO | 19:17 |
| rm_work | if including the resource in keystone was an option, i'd at least personally prefer to do that | 19:17 |
| rm_work | anyway, I'm *ok* doing it internally, but I feel like it's not the optimal approach | 19:18 |
| nkinder | rm_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 detail | 19:18 |
| rm_work | nkinder: yeah, wish I was able to go >_< | 19:19 |
| rm_work | I was going originally, but my trip got canned last-minute | 19:19 |
| rm_work | this is about the third thing that i'd like to participate in discussion on but won't be able to | 19:19 |
| rm_work | ah well | 19:19 |
| alee | rm_work, incidentally just responded to your comment to https://review.openstack.org/#/c/127823/1 | 19:22 |
| nkinder | rm_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 |
| nkinder | rm_work: so that's matching the project_id from the token with the project_id of the target resource | 19:23 |
| nkinder | keystone does some more advanced things to leverage the target functionality of oslo.policy | 19:23 |
| rm_work | but they do still query back to keystone to check key validity/etc right? | 19:24 |
| nkinder | rm_work: key validitity? | 19:25 |
| rm_work | alee: yeah I don't know what Cinder is doing right now, entirely possible they *are* making copies of secrets | 19:25 |
| rm_work | nkinder: IE, the key the user passed me isn't expired or made up | 19:25 |
| nkinder | rm_work: if a token is valid, then the project_id in the token is trusted to be correct | 19:25 |
| nkinder | rm_work: It depends on the token format. If it's a UUID token, a basic UUID is provided by the user. | 19:26 |
| nkinder | You have to fetch the token from keystone using that UUID blob, and you get the token back | 19:26 |
| rm_work | nkinder: 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 up | 19:26 |
| rm_work | *made up | 19:26 |
| nkinder | If it's a PKI token, the user gives you a signed token | 19:26 |
| nkinder | you just check the signature using the matching public key (cert) | 19:27 |
| rm_work | is the expiration time of the token included IN the token? | 19:27 |
| nkinder | yes | 19:27 |
| rm_work | so | 19:27 |
| alee | rm_work, looks like they are. so it will be useful to see what they decide they like better | 19:27 |
| rm_work | 27AC6A30-9747-422A-9D50-64B766A4DBC5 | 19:27 |
| nkinder | and you can fetch a revocation list on a normal interval, just like CRLs in the PKI world | 19:27 |
| rm_work | somehow that contains the validity time and project ID in a verifiable and non-forgeable way? | 19:27 |
| nkinder | rm_work: that is not a PKI token | 19:28 |
| rm_work | ok, I guess we don't use PKI tokens | 19:28 |
| rm_work | the tokens we use are just UUIDs | 19:28 |
| nkinder | it's a configuration option, so you might have either type | 19:28 |
| rm_work | my assumption is that the service takes the UUID from the header and checks it with keystone | 19:28 |
| rm_work | at call-time | 19:28 |
| nkinder | Yes, that is correct for UUID tokens (or it has cached copies) | 19:29 |
| nkinder | it's a "validate" call | 19:29 |
| rm_work | ok, 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 problematic | 19:29 |
| nkinder | and if it's valid, you get a copy of the user | 19:29 |
| nkinder | user's token | 19:29 |
| nkinder | the token format is the same either way though inside | 19:30 |
| nkinder | you want the validate call to take an additional argument, right? | 19:30 |
| rm_work | essentially | 19:30 |
| rm_work | but 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 user | 19:30 |
| rm_work | which I think was your point | 19:30 |
| nkinder | exactly | 19:30 |
| rm_work | but for the UUID tokens with a validate call, it could return a token with just the requested resource | 19:31 |
| rm_work | because it knows what resource is being tested | 19:31 |
| nkinder | yes, if keystone had the ability for those resources ot be registered with it | 19:31 |
| rm_work | but if it has to work for both types of tokens, we're still hosed since PKI doesn't work | 19:31 |
| rm_work | 1/2 is not good enough :/ | 19:32 |
| rm_work | so I guess my misconception was that UUID tokens and their associated validation workflow were the only method | 19:32 |
| rm_work | since that's all i've seen | 19:32 |
| nkinder | rm_work: yeah, PKI was the default in Icehouse | 19:33 |
| nkinder | It's switched back to UUID, mainly due to token size problems | 19:33 |
| nkinder | but they are both available, and both valid use cases | 19:33 |
| nkinder | rm_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_work | alee: I see their code there, I just wonder WHY they're using copy_key | 19:35 |
| rm_work | nkinder: yeah, I'll bug redrobot to go represent my interests, if he's not swamped being the new PTL :) | 19:35 |
| nkinder | rm_work: I think anything we can do to avoid having to use trusts for this basic case would be ideal | 19:36 |
| rm_work | alee: if they're using copy_key to make a copy of end-user data, then that's what registration is for | 19:36 |
| rm_work | nkinder: agreed | 19:36 |
| rm_work | alee: if they're using copy_key to make copies of internal data, then... wtf | 19:37 |
| nkinder | rm_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 time | 19:37 |
| rm_work | nkinder: yeah, that'd be good | 19:37 |
| rm_work | nkinder: though I doubt users will know at creation every service that'll need access | 19:38 |
| rm_work | so it'd be 50:50 calling barbican to add a user to a secret, vs. calling keystone to do it | 19:38 |
| nkinder | rm_work: yeah, one would need to be able to grant access to other users after the fact | 19:40 |
| alee | rm_work, well in the spec, I note that the users allowed can be modified after the fact | 19:40 |
| rm_work | right | 19:40 |
| nkinder | rm_work: but I'm assuming that there is already an update call for containers/secrets | 19:40 |
| alee | using the PUT operation | 19:40 |
| rm_work | nkinder: containers/secrets are immutable | 19:40 |
| nkinder | yeah, standard U from CRUD | 19:40 |
| nkinder | oh, interesting | 19:41 |
| rm_work | possibly metadata? | 19:41 |
| rm_work | but right now it's not common to update them | 19:41 |
| nkinder | if metadata linked to the container/secret? | 19:41 |
| rm_work | so, I just finished rewriting the client | 19:41 |
| alee | rm_work, the secresta are immutable, but not the metadata | 19:41 |
| rm_work | and there's definitely no way to have it do an update :P | 19:41 |
| rm_work | just FYI | 19:41 |
| rm_work | so if that's incorrect, we need to make some changes to python-barbicanclient :) | 19:42 |
| rm_work | I have literally *never* done anything but POST and GET to Barbican | 19:42 |
| alee | rm_work, so we don't support the 2 step secret creation process? | 19:43 |
| nkinder | is there an API doc for barbican? | 19:43 |
| rm_work | alee: err... ok, that might be in there | 19:43 |
| alee | nkinder, there is a PUT operation .. | 19:43 |
| alee | for secrets | 19:43 |
| rm_work | I never tested it personally though, the unit tests did pass :) | 19:43 |
| alee | rm_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_work | OK Yeah, the two step does a PUT | 19:44 |
| rm_work | but that's the only one | 19:44 |
| rm_work | Containers has no way to do a PUT right now | 19:44 |
| alee | rm_work, right - we'll probably need to add that | 19:45 |
| alee | its probably not in the api yet | 19:45 |
| rm_work | nkinder: https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface | 19:45 |
| *** lisaclark1 has quit IRC | 19:45 | |
| nkinder | rm_work: thanks! | 19:46 |
| rm_work | yeah, order/container have no PUT currently | 19:46 |
| rm_work | and 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_work | so... yeah | 19:46 |
| nkinder | yeah, most things are immutable | 19:47 |
| rm_work | all objects are immutable except a very special case for Secrets | 19:47 |
| nkinder | so 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 though | 19:47 |
| rm_work | yep | 19:47 |
| rm_work | though I might be more amenable to adding a subresource for auth stuff | 19:48 |
| rm_work | it doesn't need to be returned by default IMO | 19:48 |
| rm_work | I'd do secrets/<uuid>/allowed_users | 19:48 |
| rm_work | or something like that | 19:48 |
| nkinder | that's a valid approach, and provides some separation | 19:48 |
| rm_work | probably modeled similarly to the register subresource | 19:49 |
| rm_work | POST to add (idempotent), DELETE to remove | 19:49 |
| rm_work | though I may be one of the very few fans of DELETE by Body | 19:50 |
| rm_work | considering I had to change the delete functions to even be able to pass a body <_< | 19:50 |
| rm_work | alee: were you going to take the coding tasks for that BP if it goes through? | 19:51 |
| rm_work | alee: 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 |
| alee | rm_work, some of them perhaps. I'm hoping to recruit others -- like you :) | 19:52 |
| rm_work | ok, cause my brain is already coding it in my subconscious] | 19:52 |
| alee | rm_work, I didn;t want to put you down till you volunteered :) | 19:52 |
| alee | awesome | 19:52 |
| * redrobot catches up | 19:52 | |
| redrobot | alee plese re-submit any juno BPs that need to be re-reviewed for Kilo | 19:53 |
| redrobot | alee 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 |
| alee | redrobot, well its not originally my BP -- and it would be nice to keep the comments. | 19:53 |
| alee | redrobot, there is a lot of useful stuff in the comments -- if we can keep them, that would be super. | 19:54 |
| rm_work | woo, Openbook >_> | 19:54 |
| * rm_work heads to the coolaid | 19:55 | |
| redrobot | alee 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 |
| redrobot | rm_work you get more vacation, and I get more vacation, MORE VACATION FOR EVERYBODY! | 19:56 |
| alee | redrobot, 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 IRC | 20:02 | |
| *** lisaclark1 has joined #openstack-barbican | 20:05 | |
| alee | atiwari, ping | 20:06 |
| *** lisaclark1 has quit IRC | 20:06 | |
| *** JeffF has joined #openstack-barbican | 20:08 | |
| *** lisaclark1 has joined #openstack-barbican | 20:08 | |
| *** SheenaG11 has quit IRC | 20:14 | |
| JeffF | hey 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 |
| chellygel | hey JeffF! | 20:25 |
| JeffF | hey | 20:25 |
| chellygel | theres actually a great setup guide on the wiki for getting gerrit rolling -- i think | 20:25 |
| chellygel | You'll have to sign up for the OpenStack foundation... if you ahvent done that already | 20:25 |
| JeffF | I was skimming over that this morning for a few minutes | 20:25 |
| *** paul_glass has quit IRC | 20:25 | |
| chellygel | then 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 |
| chellygel | you will more than likely install git-review | 20:26 |
| JeffF | chellygel: is that at this page? https://github.com/cloudkeep/barbican/wiki/Gerrit-Review-Process | 20:26 |
| chellygel | then 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 |
| chellygel | JeffF, yes -- also there is a gerrit one for openstack proper let me link it to you | 20:27 |
| JeffF | ok | 20:27 |
| chellygel | https://review.openstack.org/ | 20:28 |
| chellygel | ^This is where the reviews for gerrit are done -- you sign in w / your openstack foundation information | 20:28 |
| chellygel | i suggest following the projects: "openstack/barbican", "openstack/barbican-specs",and "openstack/python-barbicanclient" | 20:28 |
| JeffF | ok. I'll go sign up for that soon. | 20:29 |
| chellygel | JeffF, https://wiki.openstack.org/wiki/Gerrit_Workflow this has a more top level explanation on gerrit | 20:29 |
| chellygel | and should help you get set up w/ OS foundation | 20:29 |
| JeffF | we 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 |
| chellygel | i highly recommend checking by reviewing some code first (using your +1 powers!) | 20:30 |
| chellygel | and 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 time | 20:30 |
| chellygel | don't hesitate to reach out to me when you want to set it up -- i'd be happy to walk you through it :D | 20:31 |
| *** kebray has quit IRC | 20:31 | |
| chellygel | we can even jump on a call or hangouts if thats easiest | 20:31 |
| JeffF | ok, 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 |
| JeffF | it's very similar to the symantec client, symantecssl | 20:32 |
| chellygel | for symantec we have our own external api library for thatttt.... | 20:32 |
| chellygel | https://github.com/cloudkeep/symantecssl | 20:32 |
| JeffF | yes, 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 |
| JeffF | because it will have to accompany our barbican plugin | 20:33 |
| JeffF | is that the correct pattern? | 20:34 |
| chellygel | no, it isnt required to be that way | 20:34 |
| chellygel | but sure -- why not? if you want? if you think your library will be generally used :D | 20:35 |
| *** paul_glass has joined #openstack-barbican | 20:36 | |
| JeffF | who knows, but since the barbican plugin depends on it, then I guess it should be easy to setup. | 20:36 |
| *** lisaclark1 has quit IRC | 20:36 | |
| *** openstackgerrit has quit IRC | 20:36 | |
| JeffF | ok. 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 |
| JeffF | thank you so much for your help chellygel! | 20:38 |
| chellygel | no worries JeffF -- i would suggest putting that code in for early review so you can get feedback int he meantime!! | 20:38 |
| JeffF | good idea | 20:38 |
| chellygel | JeffF, more than happy to !! | 20:38 |
| *** lisaclark1 has joined #openstack-barbican | 20:42 | |
| *** kebray has joined #openstack-barbican | 20:48 | |
| *** gyee has quit IRC | 20:57 | |
| *** juantwo has quit IRC | 21:03 | |
| atiwari | alee, whats up. sorry did not see your ping | 21:07 |
| *** lisaclark1 has quit IRC | 21:08 | |
| *** ryanpetrello has quit IRC | 21:11 | |
| *** ryanpetrello has joined #openstack-barbican | 21:11 | |
| *** jaosorior has quit IRC | 21:13 | |
| *** SheenaG1 has joined #openstack-barbican | 21:15 | |
| *** ryanpetrello has quit IRC | 21:15 | |
| *** atiwari has quit IRC | 21:17 | |
| *** SheenaG11 has joined #openstack-barbican | 21:18 | |
| *** ryanpetrello has joined #openstack-barbican | 21:19 | |
| *** SheenaG1 has quit IRC | 21:19 | |
| *** gyee has joined #openstack-barbican | 21:30 | |
| *** lisaclark1 has joined #openstack-barbican | 21:32 | |
| *** JeffF has left #openstack-barbican | 21:36 | |
| ryanpetrello | who's PTL for K? | 21:45 |
| chellygel | the wonderful redrobot ! | 21:46 |
| redrobot | o/ | 21:46 |
| chellygel | ^( ^_^) that guy | 21:46 |
| *** paul_glass has quit IRC | 21:54 | |
| *** juantwo has joined #openstack-barbican | 22:03 | |
| *** ayoung has quit IRC | 22:03 | |
| rm_work | alee: put my thoughts together cohesively as a comment on https://review.openstack.org/#/c/127353/ | 22:05 |
| rm_work | since it looks like handling it internally is the direction we'll need to go | 22:05 |
| rm_work | redrobot: did you guys end up doing tacos today? | 22:07 |
| redrobot | rm_work nope, sprint planning + hotdogs for lunch | 22:07 |
| rm_work | ah | 22:07 |
| redrobot | rm_work we grilled the dogs in the break room | 22:07 |
| rm_work | well, I could treat you guys to some tacos tomorrow if you guys are down :P | 22:07 |
| redrobot | hell to the m-f yeah! | 22:07 |
| redrobot | chellygel ^^ | 22:07 |
| chellygel | o/ is in | 22:08 |
| chellygel | erick's is actually open on wednesdays | 22:08 |
| chellygel | #justsayin | 22:08 |
| rm_work | ^_^ | 22:08 |
| rm_work | lookin' forward to some corn on a cup | 22:08 |
| chellygel | you get it rm_work !!! | 22:09 |
| chellygel | the looks i get calling corn on a cup are priceless | 22:09 |
| *** lisaclark1 has quit IRC | 22:09 | |
| rm_work | it's *technically* correct | 22:09 |
| rm_work | it is *on* the surface of the cup | 22:10 |
| rm_work | "in a cup" is a subset of "on a cup" :P | 22:10 |
| rm_work | though it is amusing that they still haven't bothered to fix the sign :P | 22:10 |
| *** lisaclark1 has joined #openstack-barbican | 22:11 | |
| redrobot | I don't think Erick is aware the sign is broken | 22:12 |
| rm_work | lol | 22:13 |
| *** jorge_munoz has quit IRC | 22:13 | |
| *** lisaclark1 has quit IRC | 22:24 | |
| *** openstackgerrit has joined #openstack-barbican | 23:02 | |
| *** dimtruck is now known as zz_dimtruck | 23:02 | |
| *** kebray has quit IRC | 23:13 | |
| *** SheenaG11 has quit IRC | 23:45 | |
| *** lisaclark1 has joined #openstack-barbican | 23:57 | |
| *** lisaclark1 has quit IRC | 23:57 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!