Monday, 2014-08-25

*** juantwo has quit IRC00:42
*** juantwo has joined #openstack-barbican00:43
*** kebray has joined #openstack-barbican01:39
*** kebray has quit IRC01:54
*** kebray has joined #openstack-barbican02:05
*** kebray has quit IRC02:07
*** woodster_ has joined #openstack-barbican02:34
*** kebray has joined #openstack-barbican03:06
openstackgerritA change was merged to openstack/barbican: fix all the log statments to use %s fomatting  https://review.openstack.org/11534503:51
*** kebray has quit IRC04:18
openstackgerritA change was merged to openstack/barbican-specs: Update doc theme for barbican-specs  https://review.openstack.org/11189904:21
*** kebray has joined #openstack-barbican04:27
openstackgerritA change was merged to openstack/barbican: Allow devstack to do git clone of barbican  https://review.openstack.org/11512204:45
*** kebray has quit IRC05:32
openstackgerritOpenStack Proposal Bot proposed a change to openstack/barbican: Imported Translations from Transifex  https://review.openstack.org/11643206:09
*** Nirupama has joined #openstack-barbican06:28
openstackgerritA change was merged to openstack/barbican: Fix Container list to properly format secret_refs  https://review.openstack.org/11581906:37
openstackgerritA change was merged to openstack/barbican: fix for bug #1359197  https://review.openstack.org/11571306:38
*** nkinder has quit IRC06:50
*** nkinder has joined #openstack-barbican06:51
rm_younice06:55
rm_youwoot06:55
*** jamielennox is now known as jamielennox|away07:33
*** fish_ has quit IRC10:56
*** SheenaG1 has joined #openstack-barbican11:07
*** SheenaG11 has joined #openstack-barbican11:09
*** SheenaG1 has quit IRC11:11
*** nkinder has quit IRC11:36
*** Nirupama has quit IRC12:01
*** nkinder has joined #openstack-barbican12:01
*** ryanpetrello has quit IRC12:21
*** ryanpetrello has joined #openstack-barbican12:26
*** nkinder has quit IRC13:33
*** alee_out is now known as alee13:41
*** nkinder has joined #openstack-barbican13:48
*** SheenaG11 has quit IRC14:11
*** akoneru has joined #openstack-barbican14:12
*** gregsharek has joined #openstack-barbican14:28
*** jraim__ has joined #openstack-barbican14:29
*** electrichead has joined #openstack-barbican14:31
*** xaeth has joined #openstack-barbican14:32
*** jenkins-keep has quit IRC14:32
*** dolphm has quit IRC14:32
*** jillysciarilly has quit IRC14:32
*** lbragstad has quit IRC14:32
*** jraim has quit IRC14:32
*** xaeth_ has quit IRC14:32
*** arunkant has quit IRC14:32
*** russellb has quit IRC14:32
*** reaperhulk has quit IRC14:32
*** redrobot has quit IRC14:32
*** lbragstad has joined #openstack-barbican14:32
*** dolphm has joined #openstack-barbican14:32
*** reaperhulk_ has joined #openstack-barbican14:32
*** jillysciarilly has joined #openstack-barbican14:32
*** arunkant has joined #openstack-barbican14:33
*** russellb has joined #openstack-barbican14:33
*** SheenaG1 has joined #openstack-barbican14:46
*** jillysciarilly has quit IRC14:50
*** lbragstad has quit IRC14:50
*** dolphm has quit IRC14:50
*** jillysciarilly has joined #openstack-barbican14:50
*** lbragstad has joined #openstack-barbican14:50
*** dolphm has joined #openstack-barbican14:50
aleewoodster_, ping14:52
woodster_alee: good morning14:53
aleegood morning :)14:53
aleewoodster_, I responded to your email about the talk btw.14:53
woodster_alee: ha, I was just looking at it14:53
aleewoodster_, cool -- I wanted to ask a few questions about the certificate flow.14:54
woodster_alee: no problem14:54
aleewoodster_, so -- once the certificate is received, what are we supposed to do with it14:54
aleewe being barbican-core14:54
aleeis it stored in a container?14:54
aleeI noticed that there were such things as certificate containers ..14:55
aleeie.. container with type = certificate14:56
woodster_yes, store in a container and update the order with that container_ref, so that it shows up in order retrieves14:56
*** kebray has joined #openstack-barbican14:57
aleewoodster_, 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 reference14:58
*** kebray has quit IRC14:58
woodster_soft FKs to the respective entities14: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-barbican14:59
aleesure - and we want to return the container_id14:59
aleebut how do I store the certificate in the container ? as a reference to a secret?15:00
aleeor just add an attribute with the base 64 encoded cert in it?15:00
aleewoodster_, for asymm keys, for example, the container contains two (or three) secret references named "public", "private" and "passsphrase"15:01
aleeso each of the keys are stored in a secret, and the relevant reference is filled out15:02
*** gregsharek has left #openstack-barbican15:02
aleewoodster_, right now the fields in a Container look like this:15:03
aleedef _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.name15:03
alee                        if hasattr(container_secret, 'name') else None15: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.URL15:03
alee                    } for consumer in self.consumers if not consumer.deleted15:03
alee                ]}15:03
electricheadalee http://paste.openstack.org/ is your friend15:04
*** electrichead is now known as redrobot15:04
aleeelectrichead, yeah - sorry for the spam15:04
aleejust lazy ..15:04
redrobotnp :)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
aleewoodster_, 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 module15:05
aleeright - 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
aleewell in this case we're talking about the certificate15:07
aleenot the public key15: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
aleeand 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  secret15:09
*** mikedillion has joined #openstack-barbican15:09
woodster_but how would a client access that certificate? via a different API than secrets?15:09
*** atiwari has joined #openstack-barbican15:10
woodster_a new certificates resource perhaps?15:10
aleeyeah - I'm kinda thinking that.15:10
aleethe reason is that certificates are by their very nature public15:11
aleeoften folks will want to publish certs15:11
aleeand it seems like a lot of work to do all that encryption /decryption to get the cert15:11
*** kebray has joined #openstack-barbican15:12
aleewoodster_, the other option I thought of was storing it in the order metadata but this would tie the cert to the order forever15:12
aleeand 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 for15:17
woodster_barbican...it seems like some other system should handle such content delivery.15:17
aleewoodster_, 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
aleewoodster_, a certificate is not a secret - quite the opposite in fact.15:20
aleewoodster_, for now, we can store it as a secret. but we can consider whether this makes sense in K15:21
aleethe publishing should likely be done by the backend CA15:22
*** atiwari has quit IRC15: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 K15:31
openstackgerritArvind Tiwari proposed a change to openstack/barbican: Reorganize code to use store crypto plug-in  https://review.openstack.org/11141215:35
*** samuelbercovici has joined #openstack-barbican15:35
aleewoodster_, 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
aleewoodster_, the fact that none of these really seem to apply is an indication that maybe we shouldn't be storing it as a secret15: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
aleewoodster_, sure - I dont think thats really a concern.  Just pointing out that having a bunch of fields that dont apply is messy.15:43
aleebut I guess we can fix that in K15:44
*** atiwari has joined #openstack-barbican15: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
aleeyeah15:47
aleewoodster_, 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
aleewoodster_, 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 helpful15:53
aleewoodster_, so you're think of moving these fields to the secret_metadata table?15:55
*** paul_glass has quit IRC15:56
*** paul_glass has joined #openstack-barbican15:58
*** SheenaG1 has quit IRC16:01
*** SheenaG1 has joined #openstack-barbican16:01
*** samuelbercovici has quit IRC16:01
*** SheenaG11 has joined #openstack-barbican16:06
*** SheenaG1 has quit IRC16:08
woodster_alee: well, the secret meta data in intended for persistence on behalf of secret_store.py plugins16: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 attribute16:17
aleewoodster_, 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
aleeunless you want to add intermediates as a client facing metadata attribute of the certificate16:21
aleewhich makes more sense16: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
aleewoodster_, I like the idea of a client facing metadata field.16:24
openstackgerritA change was merged to openstack/barbican: Minor cleanup and moving around code for clarity  https://review.openstack.org/11538716:24
*** paul_glass has quit IRC16:24
openstackgerritA change was merged to openstack/barbican: Imported Translations from Transifex  https://review.openstack.org/11643216:25
*** paul_glass has joined #openstack-barbican16:26
*** paul_glass has quit IRC16:30
*** paul_glass has joined #openstack-barbican16:33
*** paul_glass has quit IRC16:33
*** reaperhulk_ is now known as reaperhulk16:37
*** openstackgerrit has quit IRC17:00
*** nkinder has quit IRC17:05
rm_workalee / woodster_ : re: certificate storage in Barbican...17:11
rm_workhonestly, i think the amount of complexity around making another interface for certificates would not be worth the effort17:11
rm_workBarbican is a secure storage system -- so it has two facets, storage, and security17:12
woodster_rm_work, alee: yeah, I think Ade was suggesting treating such info as certs and intermediates as metadata on true secrets within Barbican17:12
rm_workthe 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 think17:12
rm_workI think changing it would add extra complexity to fix a "non-broken" thing17:13
rm_workwe thought about this a bit when we did the certificate containers and such to begin with17:13
*** openstackgerrit has joined #openstack-barbican17:13
rm_workas 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
aleewoodster_, well I was thinking of intermediates as metadata on certs.  certs would need to be entities in their own right.17:14
rm_workyeah, right now intermediates are also just another secret in the "Certificate" typed containers17: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_workyeah, but we then have to manage multiple types of entities? Secret / Nonsecret? interchangably in containers17:15
*** mikedill_ has joined #openstack-barbican17:15
rm_workwhich… seems much more complicated, for the express purpose of, what, not spending encrypt/decrypt resources? I guess that's marginally important17:16
rm_workbut the size of the related things is so tiny17:16
rm_workI don't really know the performance impact/gain17: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_workyes17:16
rm_workthough this breaks the nice hard FK relationship we liked17:16
rm_workI think?17:17
rm_workI guess maybe if we're smart enough it can be done and still maintain a good relationship17: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 entity17:17
rm_workto which base entity?17:18
rm_workor are you saying secrets/containers are both based on the same thing in the revised model? ah, yeah you are, ok17:18
rm_workjust got the polymorphism reference you made earlier :P17:18
*** mikedillion has quit IRC17:19
rm_workwould 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_workor just keep them in the DB as meta?17:19
woodster_the latter I'd think17:21
rm_workanyway, i see that it would definitely work, I just don't quite understand the advantage gained from doing that17:21
rm_workI guess maybe the terminology is cleaner -- someone doesn't wonder why their Cert is "Secret" :P17:22
aleerm_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
aleeone way to do this is using metadata17:22
rm_workyeah, though that doesn't help for the myriad of other types of secrets that aren't symmetric keys17:23
aleethat way something like even a generic passphrase doesn't have to be burdened with useless fields like algorithm.17:23
rm_workerr17:23
rm_workbut you'd want passphrase to be a Secret still… right?17:23
*** nkinder has joined #openstack-barbican17:24
rm_workyou wouldn't want it stored as unencrypted meta?17:24
aleeoh yes - just maybe with different metadata17: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_workagain, all that metadata is optional -- it doesn't really hurt to have it just be null <_<17:24
aleewe can store certs there too -- with there own metadata or we can decide to expose them as a separate resource17:25
aleethats something we need to decide on at K17:25
aleebut if we were to store the cert as a secret for example, then the "intermediates" would be stored as a piece of metadata17:26
aleemetadata that is specific to certs17:26
rm_workI 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
aleerm_work, ultimately cleaner code and models makes for more maintainable code.17:27
*** bdpayne has joined #openstack-barbican17:27
rm_workwell, as a user it seems simpler to me to do: new Secret(my_privkey, algorithm, bit_length, etc), new Secret(my_passphrase) -> Container17:28
rm_workrather than figuring out the specific object type I need?17:28
rm_workbecause everything is already optional :P17:28
rm_workthough I guess it's a weak argument to say i couldn't look up one additional word in the docs17:29
aleeyup17:30
rm_worki just don't like changing things unless I see a significantly improved use-case17:30
rm_workand i've yet to hear anything that sounds significantly improved17:30
rm_workI guess that puts me with woodster -- i'd like to see the use-cases where that actually improves the experience / flow17:31
aleerm_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
aleeoverall I think the code is better off as a result.17:32
rm_workhmm17:33
aleebut we can debate this as K approaches -- for now, we'll just store everything in secrets17:33
rm_workyeah, 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 jewelry17:34
rm_workbut if the safe is that big anyway, it doesn't make a huge difference17:34
rm_workI don't see it as shoe-horning code-wise, just functional-wise17:35
rm_workif it was a code hack, i'd totally agree17:35
aleerm_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
aleerm_work, I need to think about use cases to justify 117:40
aleebut I think there is a case for adding sometbing like a metadata table to achieve 2.17:41
aleeif a secret is a secret - then lets store it as a secret and not a symmetric key17:42
rm_workI 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 set17:42
rm_workit's already plenty generic to store plaintext or symm keys17:42
rm_workit'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-barbican17:48
*** ryanpetrello has quit IRC17:48
aleerm_work, yeah - I need to think about whether #1 is justified ..17:50
aleerm_work, #2 for me is an internal cleanup that helps eliminate code like this ..17:50
aleehttps://review.openstack.org/#/c/115715/2/barbican/api/controllers/orders.py,cm17:51
alee(except for secrets instead of orders)17:51
rm_workall the NA stuff?17:51
aleeyup17:51
rm_workwell17:51
*** akoneru is now known as akoneru_lunch17:51
rm_workit makes sense on *Orders* if they are specifically for geenerating symm keys17:52
rm_workno real need for Orders to generate you a passphrase or something17:52
rm_workhmm though it looks like Orders are for more than that?17:52
rm_workI think in that case, it might make sense to have multiple types of ORDERS17:52
aleerm_work, we made orders more generic by introducing a meta_data object and providing a type17:53
rm_workbut they can all use the same generic secrets in the background17:53
aleecertificate, asymm key, symm key17:53
aleeI'm merely suggesting the same type of mechanism for secrets17:53
*** ryanpetrello has joined #openstack-barbican17:53
*** bdpayne has quit IRC17:53
rm_workah17:55
rm_workwell, for Orders it made sense because in some cases these fields actually WERE required17:55
rm_worksimilar to the Certificates17:55
rm_work*Certificates Container type17:55
*** bdpayne has joined #openstack-barbican17:55
rm_workbut for secrets, none of the fields are EVER required, right?17:55
rm_workthey're always just meta17:55
rm_workit seems like it's mostly for validation purposes?17:56
aleewell some things are required probably - like status and maybe expiration17:57
rm_workwell, status isn't user-editable anyway17:58
rm_workexpiration should be available for ANYTHING, i'd think17:58
rm_workbut in Secrets themselves expiration isn't *required*17:58
rm_worksince the cert has already been created (creation time is when the expiration would have been required)17:59
aleerm_work, lets defer this till later -- I'll write something up making my case, and we can go from there.17:59
rm_workkk18:00
rm_workI mean, I'm just a guy with too much time on my hands at the moment anyway :P18:00
rm_workI'd defer to the cores anyway18: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
aleewoop woop18:25
woodster_nice! That's all, carry on....18:27
*** paul_glass has joined #openstack-barbican18:34
*** paul_glass has quit IRC18:38
openstackgerritSteve Martinelli proposed a change to openstack/barbican: Move to oslotest  https://review.openstack.org/11670018:43
*** lisaclark1 has joined #openstack-barbican18:44
*** akoneru_lunch is now known as akoneru18:50
*** lisaclark2 has joined #openstack-barbican19:02
*** lisaclark1 has quit IRC19:04
*** nkinder has quit IRC19:15
*** jamielennox|away has quit IRC19:30
*** jamielennox|away has joined #openstack-barbican19:32
*** kebray has quit IRC19:37
*** mikedill_ has quit IRC19:41
*** kaitlin-farr has joined #openstack-barbican19:51
*** paul_glass has joined #openstack-barbican19:58
*** paul_glass has quit IRC19:58
*** rellerreller has joined #openstack-barbican20:00
SheenaG11redrobot: meeting time!20:00
redrobotSheenaG11 indeed!20:01
*** nkinder has joined #openstack-barbican20:06
openstackgerritArun Kant proposed a change to openstack/barbican: Adding keystone notification listener support  https://review.openstack.org/11081720:11
openstackgerritA change was merged to openstack/barbican: Add order plugin metadata entity and logic  https://review.openstack.org/11607820:13
*** lisaclark2 has quit IRC20:20
*** mikedillion has joined #openstack-barbican20:23
openstackgerritPaul Kehrer proposed a change to openstack/barbican: Add a py3pep8 tox job. This will verify py3 compliant syntax.  https://review.openstack.org/11672520:53
openstackgerritPaul Kehrer proposed a change to openstack/barbican: Add a py3pep8 tox job. This will verify py3 compliant syntax  https://review.openstack.org/11672520:56
rm_workwoodster_: 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_workthat breaks my most recent architecture a little bit21:06
rm_worknot to mention causes problems for Typed Containers in general21:06
openstackgerritArvind Tiwari proposed a change to openstack/barbican: Reorganize code to use store crypto plug-in  https://review.openstack.org/11141221:20
*** rellerreller has quit IRC21:20
atiwariwoodster_, I have fixed your comment. Please let me know if that looks ok?21:21
*** mikedillion has quit IRC21:21
*** kaitlin-farr has quit IRC21:26
aleewoodster_, ping21:34
chellygelhe's in a discussion right now atiwari and alee. he sh ould be done shortly!21:35
atiwarichellygel, np21:36
aleechellygel, thanks21:36
SheenaG11Oh man, I'm third in line21:36
SheenaG11I was trying to ping him too21:36
SheenaG11Does 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
aleewoodster_, 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
aleeand we simply update the order status.21:39
aleewoodster_, 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 look21:47
atiwariwoodster_, thanks21: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 though21:48
aleewoodster_,  right - that will  happen.21:49
woodster_alee: so the code in certificate_resource.py should do the creation of the container and its secrets21:49
aleewoodster_,  in this case, say the ca_cert_request is pending ..21:49
aleewoodster_,  already coded the case where the cert is generated (and the container created)21:50
aleewoodster_, 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
aleewoodster_,  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 ACTIVE21:51
aleeie. in the case that we get back -- if cert.CertificateStatus.WAITING_FOR_CA == result.status21:51
woodster_alee: oh got it. So the WAITING_FOR_CA result status case, correct?21:51
aleeyup21:52
woodster_alee: got it. in that case we would just do a retry to check back again in the future21:52
aleewoodster_, 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 time21: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
aleewoodster_,  how do we distinguish the states ,, WAITING_FOR_CA and CA_UNAVAILABLE ?21:54
aleewoodster_, 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
openstackgerritSheena Gregson proposed a change to openstack/barbican: Updated Get Orders request and response  https://review.openstack.org/11673621:59
SheenaG11Alright, folks - I'm doing these little bastards piecemeal to avoid making unreasonably large CRs21:59
woodster_SheenaG11: thanks for being merciful!22:00
openstackgerritSheena Gregson proposed a change to openstack/barbican: Updated Get Orders request and response  https://review.openstack.org/11673622:01
SheenaG11I HATE WHITESPACE22:01
SheenaG11woodster_: you're welcome22:01
*** jamielennox|away has quit IRC22:01
SheenaG11We 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
aleewoodster_, well waiting_for_ca implies that someone on the ca needs to approve the cert request22:03
*** jamielennox|away has joined #openstack-barbican22:03
aleewoodster_,  if it doesn't change, that isnt barbican's fault.22:04
aleewoodster_, 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
aleewoodster_, which is why I was thinking of updating the order status22:05
aleewoodster_, or if not that, updating a field in the order metadata to indicates that we are waiting on the ca22:05
aleewoodster_, or maybe some kind of status_message ? or status_reason ?22:07
aleewoodster_, whaddaya thunk?22:09
*** alee is now known as alee_dinner22:14
*** SheenaG11 has quit IRC22:21
*** kebray has joined #openstack-barbican22: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 clients22:37
*** akoneru has quit IRC23:10
openstackgerritJohn Wood proposed a change to openstack/barbican: Remove config parameter from secret_store.py interface  https://review.openstack.org/11638723:15
*** jamielennox|away is now known as jamielennox23:17
openstackgerritJohn Wood proposed a change to openstack/barbican: Remove config parameter from secret_store.py interface  https://review.openstack.org/11638723:18
rm_workwoodster_: did you see my question earlier about containers?23:19
rm_workand named secrets?23:19
rm_workjust 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*internally23: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_workwoodster_: yeah, but are you saying an "RSA" container could have three private keys and 6 public keys?23:21
rm_workas long as they're all named "private_key" and "public_keu" in the container?23:22
rm_work*public_key23:22
woodster_rm_work: it shouldn't...only one 'private key' for example23:22
rm_workok23:22
rm_workso then, the method _get_secret_by_name() should be good23:22
woodster_rm_work: so the typed container is supposed to be rigorous23:22
rm_workit is only called by Typed Containers23:22
woodster_oh, got you23:23
rm_workthough for non-typed containers there is no such restriction?23:23
woodster_I thought at was on the generic container23:23
rm_workthey could have four secrets named "bob"?23:23
woodster_yep23:23
rm_workwoodster_: the method is on the generic container, yes23:23
rm_workbut it is private23:23
rm_workand is only called by subclassed objects23:23
rm_workthough I need to re-do the secret_cache design then, because i put it back into a dictionary by name <_<23:24
rm_workneeds to switch BACK to being a list of Tuples (really lame)23:24
rm_workI think I had it that way in like, patchset 523:24
rm_workerr, patch 423:24
woodster_hmmm....that is still confusing to me then. For non-typed containers, that method would throw not implemented?23:24
rm_workno...23:25
woodster_rm_work: I pushed for a map instead of a list, but folks didn't like that23:25
rm_workbut it's not public23:25
rm_workI mean, insomuch as python methods can BE private23:25
rm_worknote the underscore :P23:25
woodster_rm_work: so how it is used then? Just by typed containers?23:25
rm_workyes23:25
rm_workso...23:26
rm_workI could do an isinstance check23:26
woodster_rm_work: isn't there a typed container sub-class?23:26
rm_workerr but I couldn't23:26
rm_worknm23:26
rm_workyes23:26
rm_workthey're sub-classes of the generic container23:26
woodster_rm_work: why can't that method be on the sub-class then?23:26
rm_workit could23:26
rm_workbut23:26
rm_workit'd have to be on all of them23:26
rm_workDRY23:26
woodster_on all typed sub-classes you mean?23:27
rm_workso, there is `class Container`23:27
rm_workerr23:27
rm_workso, there is `class Container(object)`23:27
rm_workand then `class RSAContainer(Container)`23:27
rm_workand then `class CertificateContainer(Container)`23:27
rm_workContainer() has the method _get_named_secret()23:27
rm_workwhich can be called by both subclasses23:28
rm_workI don't know of a way to make it "NotImplemented" in the parent class23:28
rm_workbut still keep it in one spot23:28
rm_workan isinstance(my_rsacontainer_object, Container) would return True, right?23:28
rm_worksince it's a subclass?23:28
rm_workor is ininstance() more specific23: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 match23:28
woodster_...an no isinstance foo to worry about :)23:29
rm_workI guess <_<23:29
woodster_I think that is very Python Zen 8^)23:29
rm_workalright, I can make that change when I do the refactor tomorrow23:30
rm_worktoday was a bit of technical debt and a bunch of hullabaloo with an inova instance disappearing23:30
openstackgerritJohn Wood proposed a change to openstack/barbican: Initial connect orders resource to certificate processing  https://review.openstack.org/11571523:34
woodster_rm_work: tech debt, never fun to pay that back23:35
woodster_atiwari: https://review.openstack.org/111412 looks good to me...will +2 when Jenkins is done23:37
atiwariwoodster_, thanks23:38
atiwarisorry I was busy in internal stuff, that is why did not join the meeting23:38
woodster_no worries23:39
*** atiwari has quit IRC23:41
*** bdpayne has quit IRC23:49

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