| *** juantwo has quit IRC | 00:42 | |
| *** juantwo has joined #openstack-barbican | 00:43 | |
| *** kebray has joined #openstack-barbican | 01:39 | |
| *** kebray has quit IRC | 01:54 | |
| *** kebray has joined #openstack-barbican | 02:05 | |
| *** kebray has quit IRC | 02:07 | |
| *** woodster_ has joined #openstack-barbican | 02:34 | |
| *** kebray has joined #openstack-barbican | 03:06 | |
| openstackgerrit | A change was merged to openstack/barbican: fix all the log statments to use %s fomatting https://review.openstack.org/115345 | 03:51 |
|---|---|---|
| *** kebray has quit IRC | 04:18 | |
| openstackgerrit | A change was merged to openstack/barbican-specs: Update doc theme for barbican-specs https://review.openstack.org/111899 | 04:21 |
| *** kebray has joined #openstack-barbican | 04:27 | |
| openstackgerrit | A change was merged to openstack/barbican: Allow devstack to do git clone of barbican https://review.openstack.org/115122 | 04:45 |
| *** kebray has quit IRC | 05:32 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/barbican: Imported Translations from Transifex https://review.openstack.org/116432 | 06:09 |
| *** Nirupama has joined #openstack-barbican | 06:28 | |
| openstackgerrit | A change was merged to openstack/barbican: Fix Container list to properly format secret_refs https://review.openstack.org/115819 | 06:37 |
| openstackgerrit | A change was merged to openstack/barbican: fix for bug #1359197 https://review.openstack.org/115713 | 06:38 |
| *** nkinder has quit IRC | 06:50 | |
| *** nkinder has joined #openstack-barbican | 06:51 | |
| rm_you | nice | 06:55 |
| rm_you | woot | 06:55 |
| *** jamielennox is now known as jamielennox|away | 07:33 | |
| *** fish_ has quit IRC | 10:56 | |
| *** SheenaG1 has joined #openstack-barbican | 11:07 | |
| *** SheenaG11 has joined #openstack-barbican | 11:09 | |
| *** SheenaG1 has quit IRC | 11:11 | |
| *** nkinder has quit IRC | 11:36 | |
| *** Nirupama has quit IRC | 12:01 | |
| *** nkinder has joined #openstack-barbican | 12:01 | |
| *** ryanpetrello has quit IRC | 12:21 | |
| *** ryanpetrello has joined #openstack-barbican | 12:26 | |
| *** nkinder has quit IRC | 13:33 | |
| *** alee_out is now known as alee | 13:41 | |
| *** nkinder has joined #openstack-barbican | 13:48 | |
| *** SheenaG11 has quit IRC | 14:11 | |
| *** akoneru has joined #openstack-barbican | 14:12 | |
| *** gregsharek has joined #openstack-barbican | 14:28 | |
| *** jraim__ has joined #openstack-barbican | 14:29 | |
| *** electrichead has joined #openstack-barbican | 14:31 | |
| *** xaeth has joined #openstack-barbican | 14:32 | |
| *** jenkins-keep has quit IRC | 14:32 | |
| *** dolphm has quit IRC | 14:32 | |
| *** jillysciarilly has quit IRC | 14:32 | |
| *** lbragstad has quit IRC | 14:32 | |
| *** jraim has quit IRC | 14:32 | |
| *** xaeth_ has quit IRC | 14:32 | |
| *** arunkant has quit IRC | 14:32 | |
| *** russellb has quit IRC | 14:32 | |
| *** reaperhulk has quit IRC | 14:32 | |
| *** redrobot has quit IRC | 14:32 | |
| *** lbragstad has joined #openstack-barbican | 14:32 | |
| *** dolphm has joined #openstack-barbican | 14:32 | |
| *** reaperhulk_ has joined #openstack-barbican | 14:32 | |
| *** jillysciarilly has joined #openstack-barbican | 14:32 | |
| *** arunkant has joined #openstack-barbican | 14:33 | |
| *** russellb has joined #openstack-barbican | 14:33 | |
| *** SheenaG1 has joined #openstack-barbican | 14:46 | |
| *** jillysciarilly has quit IRC | 14:50 | |
| *** lbragstad has quit IRC | 14:50 | |
| *** dolphm has quit IRC | 14:50 | |
| *** jillysciarilly has joined #openstack-barbican | 14:50 | |
| *** lbragstad has joined #openstack-barbican | 14:50 | |
| *** dolphm has joined #openstack-barbican | 14:50 | |
| alee | woodster_, ping | 14:52 |
| woodster_ | alee: good morning | 14:53 |
| alee | good morning :) | 14:53 |
| alee | woodster_, I responded to your email about the talk btw. | 14:53 |
| woodster_ | alee: ha, I was just looking at it | 14:53 |
| alee | woodster_, cool -- I wanted to ask a few questions about the certificate flow. | 14:54 |
| woodster_ | alee: no problem | 14:54 |
| alee | woodster_, so -- once the certificate is received, what are we supposed to do with it | 14:54 |
| alee | we being barbican-core | 14:54 |
| alee | is it stored in a container? | 14:54 |
| alee | I noticed that there were such things as certificate containers .. | 14:55 |
| alee | ie.. container with type = certificate | 14:56 |
| woodster_ | yes, store in a container and update the order with that container_ref, so that it shows up in order retrieves | 14:56 |
| *** kebray has joined #openstack-barbican | 14:57 | |
| alee | woodster_, is it stored as a reference to a secret or as its own attribute? | 14:57 |
| woodster_ | the Orders entity has both a secret_id and a container_id reference | 14:58 |
| *** kebray has quit IRC | 14:58 | |
| woodster_ | soft FKs to the respective entities | 14:58 |
| woodster_ | ...so you'd just have to fill out the container_id one once that is created. | 14:59 |
| *** paul_glass has joined #openstack-barbican | 14:59 | |
| alee | sure - and we want to return the container_id | 14:59 |
| alee | but how do I store the certificate in the container ? as a reference to a secret? | 15:00 |
| alee | or just add an attribute with the base 64 encoded cert in it? | 15:00 |
| alee | woodster_, for asymm keys, for example, the container contains two (or three) secret references named "public", "private" and "passsphrase" | 15:01 |
| alee | so each of the keys are stored in a secret, and the relevant reference is filled out | 15:02 |
| *** gregsharek has left #openstack-barbican | 15:02 | |
| alee | woodster_, right now the fields in a Container look like this: | 15:03 |
| alee | def _do_extra_dict_fields(self): | 15:03 |
| alee | """Sub-class hook method: return dict of fields.""" | 15:03 |
| alee | return {'container_id': self.id, | 15:03 |
| alee | 'name': self.name or self.id, | 15:03 |
| alee | 'type': self.type, | 15:03 |
| alee | 'secret_refs': [ | 15:03 |
| alee | { | 15:03 |
| alee | 'secret_id': container_secret.secret_id, | 15:03 |
| alee | 'name': container_secret.name | 15:03 |
| alee | if hasattr(container_secret, 'name') else None | 15:03 |
| alee | } for container_secret in self.container_secrets], | 15:03 |
| alee | 'consumers': [ | 15:03 |
| alee | { | 15:03 |
| alee | 'name': consumer.name, | 15:03 |
| alee | 'URL': consumer.URL | 15:03 |
| alee | } for consumer in self.consumers if not consumer.deleted | 15:03 |
| alee | ]} | 15:03 |
| electrichead | alee http://paste.openstack.org/ is your friend | 15:04 |
| *** electrichead is now known as redrobot | 15:04 | |
| alee | electrichead, yeah - sorry for the spam | 15:04 |
| alee | just lazy .. | 15:04 |
| redrobot | np :) | 15:04 |
| woodster_ | cloud irc auto-pastes for you I've found. So yes, you'd create the secrets first, and then create the cert-type container with those secrets placed in there. | 15:05 |
| alee | woodster_, anyways it doesn't seem right to store the certificate as a secret .. | 15:05 |
| woodster_ | that would be done in that tasks/certificate_resources.py module | 15:05 |
| alee | right - but the certificate isn't really a secret. | 15:06 |
| woodster_ | alee: everything gets stored as a secret in barbican now. Are you saying securely storing the public key is overkill? | 15:06 |
| alee | well in this case we're talking about the certificate | 15:07 |
| alee | not the public key | 15:07 |
| woodster_ | Barbican currently doesn't care what the data is, it will store it the same way always. A future feature might consider relaxed RBAC access to public sorts of info, but that isn't the case now. | 15:09 |
| alee | and yeah - it seems overkill to first contact the ca to get the certificate, then contact the kra or whatever plugin to store it as a secret | 15:09 |
| *** mikedillion has joined #openstack-barbican | 15:09 | |
| woodster_ | but how would a client access that certificate? via a different API than secrets? | 15:09 |
| *** atiwari has joined #openstack-barbican | 15:10 | |
| woodster_ | a new certificates resource perhaps? | 15:10 |
| alee | yeah - I'm kinda thinking that. | 15:10 |
| alee | the reason is that certificates are by their very nature public | 15:11 |
| alee | often folks will want to publish certs | 15:11 |
| alee | and it seems like a lot of work to do all that encryption /decryption to get the cert | 15:11 |
| *** kebray has joined #openstack-barbican | 15:12 | |
| alee | woodster_, the other option I thought of was storing it in the order metadata but this would tie the cert to the order forever | 15:12 |
| alee | and so the client would have to keep track of the order_id, which makes no sense. | 15:13 |
| woodster_ | alee: yeah, the order is more like a job queue to me. So for K it seems we might want to consider a new entity type and/or resource to deal with certificates. I'm curious about the 'publishing' use case though...are you thinking barbican would provide a public URL to the cert, perhaps with no RBAC whatsoever? If so, I'm not sure that is a good use case for | 15:17 |
| woodster_ | barbican...it seems like some other system should handle such content delivery. | 15:17 |
| alee | woodster_, well - I think that as we expand barbican's role to manage certs, we are moving beyond barbican's core role as a repo of secrets. | 15:19 |
| alee | woodster_, a certificate is not a secret - quite the opposite in fact. | 15:20 |
| alee | woodster_, for now, we can store it as a secret. but we can consider whether this makes sense in K | 15:21 |
| alee | the publishing should likely be done by the backend CA | 15:22 |
| *** atiwari has quit IRC | 15:27 | |
| woodster_ | I think it would be great to explore that expanded role at the design summit. | 15:30 |
| woodster_ | That would make barbican a pretty solid system by K | 15:31 |
| openstackgerrit | Arvind Tiwari proposed a change to openstack/barbican: Reorganize code to use store crypto plug-in https://review.openstack.org/111412 | 15:35 |
| *** samuelbercovici has joined #openstack-barbican | 15:35 | |
| alee | woodster_, so in terms of storing the certiifcate as a secret -- there are multiple columns -- name, expiration, algorithm, bit_length, mode -- what goes into each of those? | 15:37 |
| alee | woodster_, the fact that none of these really seem to apply is an indication that maybe we shouldn't be storing it as a secret | 15:39 |
| woodster_ | alee: well, the most import data is getting the secret ref name in the container matched up to the right secret. Within the secret itself, this meta data is not required. The expiration date could be set to match the cert's, but that would mean the secret/cert would not be retrievable after that date if that is a concern. | 15:41 |
| alee | woodster_, sure - I dont think thats really a concern. Just pointing out that having a bunch of fields that dont apply is messy. | 15:43 |
| alee | but I guess we can fix that in K | 15:44 |
| *** atiwari has joined #openstack-barbican | 15:44 | |
| woodster_ | well, it's the same situation as with regular secrets that clients upload...barbican currently let's clients upload secrets with whatever metadata they chose (or none at all) | 15:45 |
| alee | yeah | 15:47 |
| alee | woodster_, that said -- its one thing if we do it, and another if a client chooses to. The difference is that the fields simply do not apply. | 15:49 |
| alee | woodster_, but I'll beat that horse at the summit .. | 15:49 |
| woodster_ | alee: That horse is going down it seems! My thinking is that until business logic is identified that depends on those meta fields (beyond expiration of course), these field settings will not be key information for secrets. But if we can identify those scenarios at the conference, that would be helpful | 15:53 |
| alee | woodster_, so you're think of moving these fields to the secret_metadata table? | 15:55 |
| *** paul_glass has quit IRC | 15:56 | |
| *** paul_glass has joined #openstack-barbican | 15:58 | |
| *** SheenaG1 has quit IRC | 16:01 | |
| *** SheenaG1 has joined #openstack-barbican | 16:01 | |
| *** samuelbercovici has quit IRC | 16:01 | |
| *** SheenaG11 has joined #openstack-barbican | 16:06 | |
| *** SheenaG1 has quit IRC | 16:08 | |
| woodster_ | alee: well, the secret meta data in intended for persistence on behalf of secret_store.py plugins | 16:15 |
| woodster_ | alee: client-facing metadata isn't intended to store there. If more client-centric secret meta data is needed beyond those secrets entity attributes though, we might want to introduce a metadata JSON attribute | 16:17 |
| alee | woodster_, incidentally, for now at least we're going to need to store the "intermediates" field as well as a secret. That also seems wrong to me. | 16:20 |
| alee | unless you want to add intermediates as a client facing metadata attribute of the certificate | 16:21 |
| alee | which makes more sense | 16:21 |
| woodster_ | alee: yeah, seems like a whole new entity is needed for sure...maybe a formal Metadata type entity that hangs off of secrets and containers? | 16:23 |
| alee | woodster_, I like the idea of a client facing metadata field. | 16:24 |
| openstackgerrit | A change was merged to openstack/barbican: Minor cleanup and moving around code for clarity https://review.openstack.org/115387 | 16:24 |
| *** paul_glass has quit IRC | 16:24 | |
| openstackgerrit | A change was merged to openstack/barbican: Imported Translations from Transifex https://review.openstack.org/116432 | 16:25 |
| *** paul_glass has joined #openstack-barbican | 16:26 | |
| *** paul_glass has quit IRC | 16:30 | |
| *** paul_glass has joined #openstack-barbican | 16:33 | |
| *** paul_glass has quit IRC | 16:33 | |
| *** reaperhulk_ is now known as reaperhulk | 16:37 | |
| *** openstackgerrit has quit IRC | 17:00 | |
| *** nkinder has quit IRC | 17:05 | |
| rm_work | alee / woodster_ : re: certificate storage in Barbican... | 17:11 |
| rm_work | honestly, i think the amount of complexity around making another interface for certificates would not be worth the effort | 17:11 |
| rm_work | Barbican is a secure storage system -- so it has two facets, storage, and security | 17:12 |
| woodster_ | rm_work, alee: yeah, I think Ade was suggesting treating such info as certs and intermediates as metadata on true secrets within Barbican | 17:12 |
| rm_work | the storage part is what we need in that case, and having extra security doesn't harm the storage in any way just because it's unnecessary in this case, i don't think | 17:12 |
| rm_work | I think changing it would add extra complexity to fix a "non-broken" thing | 17:13 |
| rm_work | we thought about this a bit when we did the certificate containers and such to begin with | 17:13 |
| *** openstackgerrit has joined #openstack-barbican | 17:13 | |
| rm_work | as far as "all the extra fields on secrets that don't apply", like bit_length and algorithm and such -- who cares? passphrases are valid secrets, are plaintext, and also don't have any of these things. that's why they're optional. | 17:14 |
| alee | woodster_, well I was thinking of intermediates as metadata on certs. certs would need to be entities in their own right. | 17:14 |
| rm_work | yeah, right now intermediates are also just another secret in the "Certificate" typed containers | 17:14 |
| woodster_ | rm_work, alee: I think Ade is suggesting that barbican could be more than just a secret store repo: " I think that as we expand barbican's role to manage certs, we are moving beyond barbican's core role as a repo of secrets." | 17:14 |
| rm_work | yeah, but we then have to manage multiple types of entities? Secret / Nonsecret? interchangably in containers | 17:15 |
| *** mikedill_ has joined #openstack-barbican | 17:15 | |
| rm_work | which… seems much more complicated, for the express purpose of, what, not spending encrypt/decrypt resources? I guess that's marginally important | 17:16 |
| rm_work | but the size of the related things is so tiny | 17:16 |
| rm_work | I don't really know the performance impact/gain | 17:16 |
| woodster_ | well, we'd probably have to introduce polymorphism to our datamodel...but that might not be a bad idea...containers could contain other containers, for example. | 17:16 |
| rm_work | yes | 17:16 |
| rm_work | though this breaks the nice hard FK relationship we liked | 17:16 |
| rm_work | I think? | 17:17 |
| rm_work | I guess maybe if we're smart enough it can be done and still maintain a good relationship | 17:17 |
| woodster_ | actually it reinforces it. For example, the Orders entity would no longer need separate nullable secret and container FK ids...there could just be one true FK to the base entity | 17:17 |
| rm_work | to which base entity? | 17:18 |
| rm_work | or are you saying secrets/containers are both based on the same thing in the revised model? ah, yeah you are, ok | 17:18 |
| rm_work | just got the polymorphism reference you made earlier :P | 17:18 |
| *** mikedillion has quit IRC | 17:19 | |
| rm_work | would you have an additional backend for storage of non-secrets? like Redis or something? | 17:19 |
| woodster_ | there would need to be a base secret thinggy entity...then other tables would inherit that one and add whatever attributes they require...but there would be one true PK under the hood. I know Hibernate handles the polymorphic ORM work, I recall that SQLAlchemy does too. | 17:19 |
| rm_work | or just keep them in the DB as meta? | 17:19 |
| woodster_ | the latter I'd think | 17:21 |
| rm_work | anyway, i see that it would definitely work, I just don't quite understand the advantage gained from doing that | 17:21 |
| rm_work | I guess maybe the terminology is cleaner -- someone doesn't wonder why their Cert is "Secret" :P | 17:22 |
| alee | rm_work, the basic point I was making was that the secrets table right now is really designed for symmetric keys. On the other hand, we are trying to store secrets that are more generic. | 17:22 |
| alee | one way to do this is using metadata | 17:22 |
| rm_work | yeah, though that doesn't help for the myriad of other types of secrets that aren't symmetric keys | 17:23 |
| alee | that way something like even a generic passphrase doesn't have to be burdened with useless fields like algorithm. | 17:23 |
| rm_work | err | 17:23 |
| rm_work | but you'd want passphrase to be a Secret still… right? | 17:23 |
| *** nkinder has joined #openstack-barbican | 17:24 | |
| rm_work | you wouldn't want it stored as unencrypted meta? | 17:24 |
| alee | oh yes - just maybe with different metadata | 17:24 |
| woodster_ | yeah :) To me it more about use cases around how folks would manage certificates and intermediates via barbican...Ade's vision above for example. It would help me to understand that better so we could see if it really makes sense to add a new interaction mode to Barbican vs what amount to shoe-horning a feature into the current secrets-centric approach. | 17:24 |
| rm_work | again, all that metadata is optional -- it doesn't really hurt to have it just be null <_< | 17:24 |
| alee | we can store certs there too -- with there own metadata or we can decide to expose them as a separate resource | 17:25 |
| alee | thats something we need to decide on at K | 17:25 |
| alee | but if we were to store the cert as a secret for example, then the "intermediates" would be stored as a piece of metadata | 17:26 |
| alee | metadata that is specific to certs | 17:26 |
| rm_work | I don't disagree that it'd be cleaner, but once you start adding a ton of extra high-level types for things, you add a lot of extra code to the project for what amounts to "making optional fields more optional" | 17:26 |
| alee | rm_work, ultimately cleaner code and models makes for more maintainable code. | 17:27 |
| *** bdpayne has joined #openstack-barbican | 17:27 | |
| rm_work | well, as a user it seems simpler to me to do: new Secret(my_privkey, algorithm, bit_length, etc), new Secret(my_passphrase) -> Container | 17:28 |
| rm_work | rather than figuring out the specific object type I need? | 17:28 |
| rm_work | because everything is already optional :P | 17:28 |
| rm_work | though I guess it's a weak argument to say i couldn't look up one additional word in the docs | 17:29 |
| alee | yup | 17:30 |
| rm_work | i just don't like changing things unless I see a significantly improved use-case | 17:30 |
| rm_work | and i've yet to hear anything that sounds significantly improved | 17:30 |
| rm_work | I guess that puts me with woodster -- i'd like to see the use-cases where that actually improves the experience / flow | 17:31 |
| alee | rm_work, this is a bit like the refactoring of the plugin framework. We could have shoe horned the dogtag/kmip plugin to fit the existing flow. Instead we refactored to make the interactions with the plugins clearer and made it easier to understand how to extend things for certs. | 17:32 |
| alee | overall I think the code is better off as a result. | 17:32 |
| rm_work | hmm | 17:33 |
| alee | but we can debate this as K approaches -- for now, we'll just store everything in secrets | 17:33 |
| rm_work | yeah, i guess i don't see "storing everything as secrets" to be that much of a shoe-horn -- basically it's just like storing your entire house in a safe, instead of just your jewelry | 17:34 |
| rm_work | but if the safe is that big anyway, it doesn't make a huge difference | 17:34 |
| rm_work | I don't see it as shoe-horning code-wise, just functional-wise | 17:35 |
| rm_work | if it was a code hack, i'd totally agree | 17:35 |
| alee | rm_work, there are two questions - 1) whether to store the cert as a separate resource 2) whether the secrets table is generic enough. | 17:40 |
| alee | rm_work, I need to think about use cases to justify 1 | 17:40 |
| alee | but I think there is a case for adding sometbing like a metadata table to achieve 2. | 17:41 |
| alee | if a secret is a secret - then lets store it as a secret and not a symmetric key | 17:42 |
| rm_work | I thought #2 is fine -- secrets have a few extra fields that apply to specific scenarios, but they're all optional and don't show up if they're not set | 17:42 |
| rm_work | it's already plenty generic to store plaintext or symm keys | 17:42 |
| rm_work | it's #1 (also maybe described as "there are things that aren't secrets, maybe they should be another resource"?) that I could maybe see' | 17:43 |
| *** gyee has joined #openstack-barbican | 17:48 | |
| *** ryanpetrello has quit IRC | 17:48 | |
| alee | rm_work, yeah - I need to think about whether #1 is justified .. | 17:50 |
| alee | rm_work, #2 for me is an internal cleanup that helps eliminate code like this .. | 17:50 |
| alee | https://review.openstack.org/#/c/115715/2/barbican/api/controllers/orders.py,cm | 17:51 |
| alee | (except for secrets instead of orders) | 17:51 |
| rm_work | all the NA stuff? | 17:51 |
| alee | yup | 17:51 |
| rm_work | well | 17:51 |
| *** akoneru is now known as akoneru_lunch | 17:51 | |
| rm_work | it makes sense on *Orders* if they are specifically for geenerating symm keys | 17:52 |
| rm_work | no real need for Orders to generate you a passphrase or something | 17:52 |
| rm_work | hmm though it looks like Orders are for more than that? | 17:52 |
| rm_work | I think in that case, it might make sense to have multiple types of ORDERS | 17:52 |
| alee | rm_work, we made orders more generic by introducing a meta_data object and providing a type | 17:53 |
| rm_work | but they can all use the same generic secrets in the background | 17:53 |
| alee | certificate, asymm key, symm key | 17:53 |
| alee | I'm merely suggesting the same type of mechanism for secrets | 17:53 |
| *** ryanpetrello has joined #openstack-barbican | 17:53 | |
| *** bdpayne has quit IRC | 17:53 | |
| rm_work | ah | 17:55 |
| rm_work | well, for Orders it made sense because in some cases these fields actually WERE required | 17:55 |
| rm_work | similar to the Certificates | 17:55 |
| rm_work | *Certificates Container type | 17:55 |
| *** bdpayne has joined #openstack-barbican | 17:55 | |
| rm_work | but for secrets, none of the fields are EVER required, right? | 17:55 |
| rm_work | they're always just meta | 17:55 |
| rm_work | it seems like it's mostly for validation purposes? | 17:56 |
| alee | well some things are required probably - like status and maybe expiration | 17:57 |
| rm_work | well, status isn't user-editable anyway | 17:58 |
| rm_work | expiration should be available for ANYTHING, i'd think | 17:58 |
| rm_work | but in Secrets themselves expiration isn't *required* | 17:58 |
| rm_work | since the cert has already been created (creation time is when the expiration would have been required) | 17:59 |
| alee | rm_work, lets defer this till later -- I'll write something up making my case, and we can go from there. | 17:59 |
| rm_work | kk | 18:00 |
| rm_work | I mean, I'm just a guy with too much time on my hands at the moment anyway :P | 18:00 |
| rm_work | I'd defer to the cores anyway | 18:00 |
| woodster_ | alee: thanks for using my CR as an example of code that could be improved BTW. :) Seriously though, that is a good example of data showing up from one use case as extra noise in another general use case. At any rate, let's take a good look at this for K for sure. | 18:23 |
| woodster_ | so speaking of things metadata, can I get a woop woop for this CR?: https://review.openstack.org/#/c/116078/ | 18:24 |
| alee | woop woop | 18:25 |
| woodster_ | nice! That's all, carry on.... | 18:27 |
| *** paul_glass has joined #openstack-barbican | 18:34 | |
| *** paul_glass has quit IRC | 18:38 | |
| openstackgerrit | Steve Martinelli proposed a change to openstack/barbican: Move to oslotest https://review.openstack.org/116700 | 18:43 |
| *** lisaclark1 has joined #openstack-barbican | 18:44 | |
| *** akoneru_lunch is now known as akoneru | 18:50 | |
| *** lisaclark2 has joined #openstack-barbican | 19:02 | |
| *** lisaclark1 has quit IRC | 19:04 | |
| *** nkinder has quit IRC | 19:15 | |
| *** jamielennox|away has quit IRC | 19:30 | |
| *** jamielennox|away has joined #openstack-barbican | 19:32 | |
| *** kebray has quit IRC | 19:37 | |
| *** mikedill_ has quit IRC | 19:41 | |
| *** kaitlin-farr has joined #openstack-barbican | 19:51 | |
| *** paul_glass has joined #openstack-barbican | 19:58 | |
| *** paul_glass has quit IRC | 19:58 | |
| *** rellerreller has joined #openstack-barbican | 20:00 | |
| SheenaG11 | redrobot: meeting time! | 20:00 |
| redrobot | SheenaG11 indeed! | 20:01 |
| *** nkinder has joined #openstack-barbican | 20:06 | |
| openstackgerrit | Arun Kant proposed a change to openstack/barbican: Adding keystone notification listener support https://review.openstack.org/110817 | 20:11 |
| openstackgerrit | A change was merged to openstack/barbican: Add order plugin metadata entity and logic https://review.openstack.org/116078 | 20:13 |
| *** lisaclark2 has quit IRC | 20:20 | |
| *** mikedillion has joined #openstack-barbican | 20:23 | |
| openstackgerrit | Paul Kehrer proposed a change to openstack/barbican: Add a py3pep8 tox job. This will verify py3 compliant syntax. https://review.openstack.org/116725 | 20:53 |
| openstackgerrit | Paul Kehrer proposed a change to openstack/barbican: Add a py3pep8 tox job. This will verify py3 compliant syntax https://review.openstack.org/116725 | 20:56 |
| rm_work | woodster_: so, clarifying again, containers have no validation or requirement that the names given to secrets (in the container, not the secret) have to be unique? | 21:05 |
| rm_work | that breaks my most recent architecture a little bit | 21:06 |
| rm_work | not to mention causes problems for Typed Containers in general | 21:06 |
| openstackgerrit | Arvind Tiwari proposed a change to openstack/barbican: Reorganize code to use store crypto plug-in https://review.openstack.org/111412 | 21:20 |
| *** rellerreller has quit IRC | 21:20 | |
| atiwari | woodster_, I have fixed your comment. Please let me know if that looks ok? | 21:21 |
| *** mikedillion has quit IRC | 21:21 | |
| *** kaitlin-farr has quit IRC | 21:26 | |
| alee | woodster_, ping | 21:34 |
| chellygel | he's in a discussion right now atiwari and alee. he sh ould be done shortly! | 21:35 |
| atiwari | chellygel, np | 21:36 |
| alee | chellygel, thanks | 21:36 |
| SheenaG11 | Oh man, I'm third in line | 21:36 |
| SheenaG11 | I was trying to ping him too | 21:36 |
| SheenaG11 | Does anybody know off the top of their head if a secret_ref is returned in a getOrders call if the order is in PENDING state? | 21:37 |
| alee | woodster_, so - if a cert_request is successful, then the order.container_id is updated with the new container. If the cert request is successful, but the request is in pending state, then presumably we dont create a container. | 21:39 |
| alee | and we simply update the order status. | 21:39 |
| alee | woodster_, so my question is -- how should we update the order status ? is there an order status field? | 21:40 |
| woodster_ | atiwari: I'll take a look | 21:47 |
| atiwari | woodster_, thanks | 21:47 |
| woodster_ | alee: the overall Order status should go to ACTIVE once that container-id is set. I'll look at the core logic around that though | 21:48 |
| alee | woodster_, right - that will happen. | 21:49 |
| woodster_ | alee: so the code in certificate_resource.py should do the creation of the container and its secrets | 21:49 |
| alee | woodster_, in this case, say the ca_cert_request is pending .. | 21:49 |
| alee | woodster_, already coded the case where the cert is generated (and the container created) | 21:50 |
| alee | woodster_, so I think that I need to set order status to PENDING ? | 21:50 |
| woodster_ | alee: so why would the CA order still be pending after the certificate is generated? | 21:50 |
| alee | woodster_, sorry not being clear -- I am trying to code what happens when the cert has not yet been generated. | 21:51 |
| woodster_ | alee: you could still generate the container/secrets while the order is still PENDING, but the clients would not think the order is ready until it goes ACTIVE | 21:51 |
| alee | ie. in the case that we get back -- if cert.CertificateStatus.WAITING_FOR_CA == result.status | 21:51 |
| woodster_ | alee: oh got it. So the WAITING_FOR_CA result status case, correct? | 21:51 |
| alee | yup | 21:52 |
| woodster_ | alee: got it. in that case we would just do a retry to check back again in the future | 21:52 |
| alee | woodster_, ok - so the order is already in pending state? | 21:53 |
| woodster_ | alee: in particular, it will call back to the check_certificate_status() method on the certificate plugin at some future time | 21:53 |
| woodster_ | alee: yes, the intent would be for the Order record to stay PENDING until the very end...so once a certificate is stored (so to ACTIVE), or a fatal error occurs (so to ERROR) | 21:54 |
| alee | woodster_, how do we distinguish the states ,, WAITING_FOR_CA and CA_UNAVAILABLE ? | 21:54 |
| alee | woodster_, or in the CA_UnAVAILABLE case, do we retry X number of times before setting ERROR? | 21:55 |
| woodster_ | alee: that later would be the case in the original concept. | 21:56 |
| woodster_ | alee: also, the original concept had the plugins managing their state via info stored in the plugin_meta data. Now that things are pulled into barbican core, we might want to add the last result status to the meta data for the plugin to see in the future calls. | 21:58 |
| openstackgerrit | Sheena Gregson proposed a change to openstack/barbican: Updated Get Orders request and response https://review.openstack.org/116736 | 21:59 |
| SheenaG11 | Alright, folks - I'm doing these little bastards piecemeal to avoid making unreasonably large CRs | 21:59 |
| woodster_ | SheenaG11: thanks for being merciful! | 22:00 |
| openstackgerrit | Sheena Gregson proposed a change to openstack/barbican: Updated Get Orders request and response https://review.openstack.org/116736 | 22:01 |
| SheenaG11 | I HATE WHITESPACE | 22:01 |
| SheenaG11 | woodster_: you're welcome | 22:01 |
| *** jamielennox|away has quit IRC | 22:01 | |
| SheenaG11 | We have a couple of months to get these ready - I may not be joining you folks in Paris, but these docs will be! | 22:01 |
| woodster_ | alee: WAITING_FOR_CA would mean just retrying the current method at some point in the future, with probably a very long period to wait before giving up with ERROR. CA_UNAVAILABLE would also retry current method, but probably have a much shorter overall timeout period before ERROR. | 22:02 |
| alee | woodster_, well waiting_for_ca implies that someone on the ca needs to approve the cert request | 22:03 |
| *** jamielennox|away has joined #openstack-barbican | 22:03 | |
| alee | woodster_, if it doesn't change, that isnt barbican's fault. | 22:04 |
| alee | woodster_, but it would be nice for the client to know that the request has been made and that we are waiting for the ca to issue the cert, | 22:04 |
| alee | woodster_, which is why I was thinking of updating the order status | 22:05 |
| alee | woodster_, or if not that, updating a field in the order metadata to indicates that we are waiting on the ca | 22:05 |
| alee | woodster_, or maybe some kind of status_message ? or status_reason ? | 22:07 |
| alee | woodster_, whaddaya thunk? | 22:09 |
| *** alee is now known as alee_dinner | 22:14 | |
| *** SheenaG11 has quit IRC | 22:21 | |
| *** kebray has joined #openstack-barbican | 22:30 | |
| woodster_ | alee: there's be a discussion about adding sub_status and sub_status_message attributes to the Order entity, to allow clients to track the progress of their order over time. | 22:35 |
| woodster_ | alee: the overall Order status would be PENDING throughout, but the sub-status would vary over time. | 22:35 |
| woodster_ | alee: so better to have these as first class attributes on the Order rather than mixed in with the plugin metadata that isn't directly displayed to clients | 22:37 |
| *** akoneru has quit IRC | 23:10 | |
| openstackgerrit | John Wood proposed a change to openstack/barbican: Remove config parameter from secret_store.py interface https://review.openstack.org/116387 | 23:15 |
| *** jamielennox|away is now known as jamielennox | 23:17 | |
| openstackgerrit | John Wood proposed a change to openstack/barbican: Remove config parameter from secret_store.py interface https://review.openstack.org/116387 | 23:18 |
| rm_work | woodster_: did you see my question earlier about containers? | 23:19 |
| rm_work | and named secrets? | 23:19 |
| rm_work | just to be clear, we're saying that in a typed container it is possible to have multiple secrets with the same "linkage" name (obviously the secrets themselves could have whatever name they wanted internallu) | 23:20 |
| rm_work | *internally | 23:20 |
| woodster_ | rm_work: I thought for typed containers, we check that required names have a secret for then. Only untyped secrets do we not check the names. | 23:21 |
| rm_work | woodster_: yeah, but are you saying an "RSA" container could have three private keys and 6 public keys? | 23:21 |
| rm_work | as long as they're all named "private_key" and "public_keu" in the container? | 23:22 |
| rm_work | *public_key | 23:22 |
| woodster_ | rm_work: it shouldn't...only one 'private key' for example | 23:22 |
| rm_work | ok | 23:22 |
| rm_work | so then, the method _get_secret_by_name() should be good | 23:22 |
| woodster_ | rm_work: so the typed container is supposed to be rigorous | 23:22 |
| rm_work | it is only called by Typed Containers | 23:22 |
| woodster_ | oh, got you | 23:23 |
| rm_work | though for non-typed containers there is no such restriction? | 23:23 |
| woodster_ | I thought at was on the generic container | 23:23 |
| rm_work | they could have four secrets named "bob"? | 23:23 |
| woodster_ | yep | 23:23 |
| rm_work | woodster_: the method is on the generic container, yes | 23:23 |
| rm_work | but it is private | 23:23 |
| rm_work | and is only called by subclassed objects | 23:23 |
| rm_work | though I need to re-do the secret_cache design then, because i put it back into a dictionary by name <_< | 23:24 |
| rm_work | needs to switch BACK to being a list of Tuples (really lame) | 23:24 |
| rm_work | I think I had it that way in like, patchset 5 | 23:24 |
| rm_work | err, patch 4 | 23:24 |
| woodster_ | hmmm....that is still confusing to me then. For non-typed containers, that method would throw not implemented? | 23:24 |
| rm_work | no... | 23:25 |
| woodster_ | rm_work: I pushed for a map instead of a list, but folks didn't like that | 23:25 |
| rm_work | but it's not public | 23:25 |
| rm_work | I mean, insomuch as python methods can BE private | 23:25 |
| rm_work | note the underscore :P | 23:25 |
| woodster_ | rm_work: so how it is used then? Just by typed containers? | 23:25 |
| rm_work | yes | 23:25 |
| rm_work | so... | 23:26 |
| rm_work | I could do an isinstance check | 23:26 |
| woodster_ | rm_work: isn't there a typed container sub-class? | 23:26 |
| rm_work | err but I couldn't | 23:26 |
| rm_work | nm | 23:26 |
| rm_work | yes | 23:26 |
| rm_work | they're sub-classes of the generic container | 23:26 |
| woodster_ | rm_work: why can't that method be on the sub-class then? | 23:26 |
| rm_work | it could | 23:26 |
| rm_work | but | 23:26 |
| rm_work | it'd have to be on all of them | 23:26 |
| rm_work | DRY | 23:26 |
| woodster_ | on all typed sub-classes you mean? | 23:27 |
| rm_work | so, there is `class Container` | 23:27 |
| rm_work | err | 23:27 |
| rm_work | so, there is `class Container(object)` | 23:27 |
| rm_work | and then `class RSAContainer(Container)` | 23:27 |
| rm_work | and then `class CertificateContainer(Container)` | 23:27 |
| rm_work | Container() has the method _get_named_secret() | 23:27 |
| rm_work | which can be called by both subclasses | 23:28 |
| rm_work | I don't know of a way to make it "NotImplemented" in the parent class | 23:28 |
| rm_work | but still keep it in one spot | 23:28 |
| rm_work | an isinstance(my_rsacontainer_object, Container) would return True, right? | 23:28 |
| rm_work | since it's a subclass? | 23:28 |
| rm_work | or is ininstance() more specific | 23:28 |
| woodster_ | so if you rename that to _get_first_named_secret() I think that would be more clear...typed sub-classes would know that only one name is possible, non-typed would know that it just grabs the secret with the first name match | 23:28 |
| woodster_ | ...an no isinstance foo to worry about :) | 23:29 |
| rm_work | I guess <_< | 23:29 |
| woodster_ | I think that is very Python Zen 8^) | 23:29 |
| rm_work | alright, I can make that change when I do the refactor tomorrow | 23:30 |
| rm_work | today was a bit of technical debt and a bunch of hullabaloo with an inova instance disappearing | 23:30 |
| openstackgerrit | John Wood proposed a change to openstack/barbican: Initial connect orders resource to certificate processing https://review.openstack.org/115715 | 23:34 |
| woodster_ | rm_work: tech debt, never fun to pay that back | 23:35 |
| woodster_ | atiwari: https://review.openstack.org/111412 looks good to me...will +2 when Jenkins is done | 23:37 |
| atiwari | woodster_, thanks | 23:38 |
| atiwari | sorry I was busy in internal stuff, that is why did not join the meeting | 23:38 |
| woodster_ | no worries | 23:39 |
| *** atiwari has quit IRC | 23:41 | |
| *** bdpayne has quit IRC | 23:49 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!