| *** openstackgerrit has quit IRC | 00:21 | |
| *** openstackgerrit has joined #openstack-barbican | 00:21 | |
| *** david-lyle is now known as david-lyle_afk | 00:28 | |
| *** kgriffs is now known as kgriffs|afk | 00:35 | |
| *** kebray has quit IRC | 00:51 | |
| *** openstackgerrit has quit IRC | 01:05 | |
| *** openstackgerrit has joined #openstack-barbican | 01:05 | |
| *** gyee has quit IRC | 01:12 | |
| *** bdpayne has joined #openstack-barbican | 01:44 | |
| *** bdpayne has quit IRC | 01:46 | |
| *** openstackgerrit has quit IRC | 02:20 | |
| *** openstackgerrit has joined #openstack-barbican | 02:21 | |
| *** openstackgerrit has quit IRC | 03:20 | |
| *** openstackgerrit has joined #openstack-barbican | 03:20 | |
| *** dimtruck is now known as zz_dimtruck | 03:24 | |
| *** zz_dimtruck is now known as dimtruck | 03:34 | |
| *** dimtruck is now known as zz_dimtruck | 03:51 | |
| *** zz_dimtruck is now known as dimtruck | 03:52 | |
| *** dimtruck is now known as zz_dimtruck | 04:01 | |
| *** kebray has joined #openstack-barbican | 04:57 | |
| *** kebray has quit IRC | 04:58 | |
| *** kebray has joined #openstack-barbican | 05:05 | |
| *** Nirupama has joined #openstack-barbican | 05:15 | |
| *** jaosorior has joined #openstack-barbican | 08:14 | |
| *** chlong has quit IRC | 08:36 | |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican: Fix error in "tenants to projects" migration script https://review.openstack.org/151145 | 08:59 |
|---|---|---|
| *** woodster_ has quit IRC | 09:13 | |
| *** kebray has quit IRC | 09:26 | |
| *** chlong has joined #openstack-barbican | 10:13 | |
| *** chlong has quit IRC | 10:27 | |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican: Fix downgrade for revision 254495565185 https://review.openstack.org/151172 | 10:40 |
| *** chlong has joined #openstack-barbican | 10:45 | |
| *** chlong has quit IRC | 11:39 | |
| *** chlong has joined #openstack-barbican | 12:06 | |
| *** Nirupama has quit IRC | 12:29 | |
| *** woodster_ has joined #openstack-barbican | 12:45 | |
| *** alee_dinner has quit IRC | 13:41 | |
| *** darrenmoffat has quit IRC | 13:44 | |
| *** darrenmoffat has joined #openstack-barbican | 13:45 | |
| *** nkinder has quit IRC | 14:21 | |
| *** alee_dinner has joined #openstack-barbican | 14:31 | |
| *** lisaclark1 has joined #openstack-barbican | 14:31 | |
| *** alee_dinner is now known as alee | 14:32 | |
| *** lisaclark1 has quit IRC | 14:39 | |
| *** lisaclark1 has joined #openstack-barbican | 14:49 | |
| *** lisaclark1 has quit IRC | 14:52 | |
| *** lisaclark1 has joined #openstack-barbican | 14:55 | |
| *** zz_dimtruck is now known as dimtruck | 14:55 | |
| alee | rm_work, woodster_ ping | 15:02 |
| alee | rm_work, woodster_ I added a comment/question on the per-secret spec. Please take a look. | 15:03 |
| alee | https://review.openstack.org/#/c/127353 | 15:03 |
| *** paul_glass has joined #openstack-barbican | 15:03 | |
| alee | woodster_, also - I have a couple of questions for my other crs | 15:03 |
| *** kgriffs|afk is now known as kgriffs | 15:04 | |
| *** nkinder has joined #openstack-barbican | 15:07 | |
| *** rellerreller has joined #openstack-barbican | 15:15 | |
| *** rellerreller has quit IRC | 15:32 | |
| alee | woodster_, ? | 15:34 |
| jaosorior | rellerreller | 15:37 |
| jaosorior | you around? | 15:37 |
| redrobot | mornin' | 15:39 |
| woodster_ | alee: I'll take a look shortly | 15:47 |
| alee | woodster_, thanks -- I also need your help in trying to figure out how to write some code when you get a chance | 15:48 |
| alee | woodster_, specifically, you'll notice that my CR https://review.openstack.org/#/c/147981/ now fails unit tests because the code is trying to do an insert into the data tables instead of an update. | 15:49 |
| alee | I'm trying to understand how to make it do an update instead. | 15:50 |
| alee | jaosorior, ^^ you might know too perhaps? | 15:50 |
| *** lisaclark1 has quit IRC | 15:51 | |
| jaosorior | alee: I can give it a look when I get home. I'm in the bus off the office | 15:52 |
| alee | jaosorior, thanks | 15:53 |
| jaosorior | ... and I'm heading to climb. So I'll ping you in a couple of hours. | 15:53 |
| alee | jaosorior, don't fall :) | 15:53 |
| *** SheenaG1 has joined #openstack-barbican | 15:54 | |
| jaosorior | Haha it's inevitable if I want to train for harder routes. But I don't fall in hard ground (usually) so it's ok | 15:55 |
| jaosorior | alee: you should try out out. It's pretty fun | 15:57 |
| alee | jaosorior, fair enough -- if you do fall, make sure not to land on your head, so youcan review my CRs :) | 15:57 |
| *** lisaclark1 has joined #openstack-barbican | 15:58 | |
| alee | jaosorior, does sound like fun | 15:58 |
| *** lisaclark1 has joined #openstack-barbican | 16:00 | |
| *** SheenaG1 has quit IRC | 16:04 | |
| *** lisaclark2 has joined #openstack-barbican | 16:04 | |
| *** lisaclark1 has quit IRC | 16:04 | |
| *** SheenaG1 has joined #openstack-barbican | 16:15 | |
| woodster_ | alee, looking at error.... | 16:16 |
| rm_work | alee: so I am ok with everything there except i am concerned about the ACL DB Table structure | 16:19 |
| rm_work | it looks like you are planning to store a LIST of users inside each column? | 16:19 |
| rm_work | and have only one row per secret_id? | 16:19 |
| alee | woodster_, the test is failing now because we put that uniqueness constraint into the db. (good thing we did). | 16:19 |
| alee | rm_work, yes | 16:19 |
| rm_work | I am more in favor of the structure: secret_id, access_type, user_id | 16:19 |
| rm_work | where rows would look like: | 16:20 |
| rm_work | secretA_uuid | read | john_uuid | 16:20 |
| rm_work | secretA_uuid | read | bill_uuid | 16:20 |
| rm_work | that allows you to actually do decent JOIN filtering operations | 16:20 |
| alee | what about groups and projects? | 16:21 |
| rm_work | secret_id, access_type, user_id, group_id, project_id | 16:21 |
| rm_work | secretA_uuid | read | john_uuid | NULL | NULL | 16:21 |
| rm_work | secretA_uuid | read | NULL | NULL | johns_project_uuid | 16:21 |
| rm_work | little less clean but still works for JOINs | 16:22 |
| rm_work | doing it in a list inside one column makes it a multi-step process no matter what | 16:22 |
| alee | rm_work, there is also the other question about how to do private secrets | 16:22 |
| rm_work | you have to get a semi-complete list and then do a bunch of parsing and list modifying after that | 16:23 |
| rm_work | alee: define a private secret | 16:23 |
| rm_work | I thought that was just… one that isn't shared <_< | 16:23 |
| rm_work | no ACL entries = project-private? | 16:23 |
| alee | rm_work, a secret which I create and only I (not my project) can access | 16:23 |
| rm_work | uhh | 16:23 |
| rm_work | hmm | 16:23 |
| rm_work | was that in this spec? | 16:24 |
| alee | that was the other use case we were trying to solve | 16:24 |
| redrobot | alee that seems like something we shouldn't support | 16:24 |
| rm_work | I must have missed that | 16:24 |
| rm_work | I am not sure how that is possible with a WHITELIST | 16:24 |
| redrobot | alee if you don't want to share your secret, you should create a project on which only you have roles | 16:24 |
| rm_work | it would have to probably be a different mechanism | 16:24 |
| alee | redrobot, yes -- we thought about that and decided that was a terrible idea | 16:24 |
| rm_work | maybe if the secret entry itself just had another column "creator_only" that was a boolean | 16:25 |
| rm_work | i just don't see how the whitelist ACL thing would help accomplish that | 16:25 |
| alee | rm_work, originally the idea was that you didn't need a special role to use the whitelist | 16:26 |
| rm_work | that actually seems like a separate spec/BP/CR to me | 16:26 |
| *** lisaclark2 has quit IRC | 16:26 | |
| woodster_ | where 'creator' is the *user* that stored the secret, correct? Just making sure :) | 16:26 |
| alee | woodster_, yes | 16:26 |
| rm_work | alee: still not sure how that would have helped | 16:26 |
| rm_work | woodster_: i assume so :P | 16:26 |
| *** kebray has joined #openstack-barbican | 16:26 | |
| alee | rm_work, simple -- you would specify the whitelist to only include your uid | 16:26 |
| rm_work | uh | 16:27 |
| rm_work | so you were planning for every new secret to by default have a whitelist entry for the secret's project, unless the creator specified otherwise? | 16:27 |
| alee | correct | 16:27 |
| *** lisaclark1 has joined #openstack-barbican | 16:27 | |
| rm_work | hmm | 16:27 |
| woodster_ | yes, default to how things work now essentially | 16:28 |
| alee | we also had talked about changing that default to only creator in v2 | 16:28 |
| rm_work | so the read-shared role throws a wrench in that plan because it would not be on every user by default? | 16:28 |
| alee | rm_work, right | 16:28 |
| woodster_ | correct | 16:29 |
| rm_work | i still feel like the ACLs might not be the right approach to accomplish that specific thing | 16:29 |
| rm_work | but i see how you had originally planned it to work | 16:29 |
| rm_work | hmm | 16:29 |
| rm_work | I can't decide it splitting it out makes this more or less complex | 16:29 |
| alee | rm_work, well its all controlling access - which is what an acl and policy does | 16:29 |
| woodster_ | the current behavior without a whitelist has to work correctly for v1 | 16:29 |
| rm_work | *decide if | 16:29 |
| woodster_ | standup meeting...be back in a few minutes | 16:30 |
| *** dimtruck is now known as zz_dimtruck | 16:30 | |
| alee | we could add another "creator_only" boolean .. | 16:31 |
| alee | that was also one of the original ideas .. | 16:31 |
| rm_work | yeah | 16:31 |
| rm_work | i feel like that might be better, functionally | 16:31 |
| woodster_ | that is explicit for sure | 16:33 |
| alee | (creator_only and user=creator) or (not_creator_only and ((project=creator_project) or ((read_shared) and (user,group,project in whitelist))) | 16:34 |
| *** zz_dimtruck is now known as dimtruck | 16:34 | |
| alee | can we make the policy more complex ? :/ | 16:35 |
| alee | its certainly a lot more complex than --> (user,group,project) in whitelist | 16:36 |
| alee | which was the original intent. | 16:37 |
| rm_work | yeah well | 16:38 |
| rm_work | <_< | 16:38 |
| *** ametts has joined #openstack-barbican | 16:40 | |
| alee | rm_work, anyways, please comment on the spec about the table format -- and we'll see what others think | 16:40 |
| rm_work | k | 16:40 |
| alee | rm_work, I'll do the same about creator_only | 16:41 |
| alee | rm_work, the extra complexity isn't necessarily bad as it makes things explicit | 16:41 |
| alee | but it also is somewhat less powerful | 16:42 |
| alee | woodster_, need to go to a meeting in 5 mins. Please take a look at the failing CR and let me know how to make sqlalchemy do an update (instead of an insert) | 16:43 |
| alee | woodster_, and also comment on the per-secret spec | 16:43 |
| rm_work | is there some syntax i can put in a comment in gerrit to tell it i'm doing code or something and to not wrap my lines? | 16:45 |
| rm_work | anywho, commented | 16:47 |
| *** david-lyle_afk is now known as david-lyle | 16:49 | |
| *** tkelsey has joined #openstack-barbican | 16:55 | |
| *** hyakuhei has joined #openstack-barbican | 16:55 | |
| *** lisaclark1 has quit IRC | 16:55 | |
| *** bdpayne has joined #openstack-barbican | 17:00 | |
| *** rellerreller has joined #openstack-barbican | 17:01 | |
| *** kebray has quit IRC | 17:07 | |
| rm_work | bbl loonch | 17:18 |
| *** jkf has joined #openstack-barbican | 17:38 | |
| *** jkf has quit IRC | 17:40 | |
| *** ayoung is now known as misanthrope | 17:49 | |
| *** misanthrope is now known as ayoung | 17:49 | |
| *** tkelsey has quit IRC | 17:51 | |
| *** hyakuhei has quit IRC | 17:55 | |
| *** hyakuhei has joined #openstack-barbican | 17:59 | |
| *** hyakuhei has quit IRC | 18:00 | |
| *** jkf has joined #openstack-barbican | 18:02 | |
| *** dimtruck is now known as zz_dimtruck | 18:03 | |
| *** zz_dimtruck is now known as dimtruck | 18:09 | |
| bdpayne | Just curious... what's the motivation behind requiring pecan (and a bleeding edge version at that) for Barbican rather than using deps more common to the rest of OpenStack? | 18:15 |
| *** bdpayne has quit IRC | 18:19 | |
| *** rellerreller has quit IRC | 18:29 | |
| *** bdpayne has joined #openstack-barbican | 18:43 | |
| woodster_ | bdpayne, we are matching global reqs right now: https://github.com/openstack/requirements/blob/master/global-requirements.txt#L82 | 18:49 |
| *** openstackgerrit has quit IRC | 18:50 | |
| *** openstackgerrit has joined #openstack-barbican | 18:51 | |
| *** kgriffs is now known as kgriffs|afk | 18:53 | |
| *** kgriffs|afk is now known as kgriffs | 18:53 | |
| *** ayoung has quit IRC | 18:53 | |
| jaosorior | back | 18:59 |
| alee | woodster_, jaosorior hey | 19:09 |
| alee | woodster_, so any thought on the code? | 19:09 |
| jaosorior | lemme recheck the CR | 19:09 |
| *** nkinder has quit IRC | 19:10 | |
| woodster_ | alee, I got distracted by lunch :) I'll take a look now.... | 19:11 |
| woodster_ | alee, rm_work, I did add comment to your rbac blueprint comments.... | 19:13 |
| alee | woodster_, jaosorior - so the issue is that in that one test I want to do an update | 19:13 |
| alee | woodster_, but end up calling save() which ends up doing an insert | 19:13 |
| alee | I need to know how to do an update() | 19:14 |
| jaosorior | lol, I thought you wanted me to recheck this CR https://review.openstack.org/#/c/146611 | 19:14 |
| rm_work | bdpayne: yeah, I thought pecan WAS what openstack required (or at least, recommended)? | 19:14 |
| jaosorior | got confused | 19:14 |
| jaosorior | bdpayne: If you're implying that pecan is no longer what Barbican requires, I would be glad to start coding the way out of it. It has caused me some problems. Damn it | 19:15 |
| woodster_ | alee, all deletes are soft deletes right now...so your update-entity code is not removing any records, just trying to add new ones of the same ca_id and key | 19:15 |
| jaosorior | woodster_: Why are they soft deletes? I could see it from the code, but never really understood why it is the way it is | 19:16 |
| woodster_ | jaosorior, there was concern early on about hard removing secrets out of barbican vs tagging them as deleted so they could be recovered if needed. | 19:16 |
| rm_work | jaosorior: something something HORRIBLE ACCIDENT something | 19:17 |
| alee | woodster_, I see - well in that case, it will run afoul of the uniqueness constraint we put in | 19:17 |
| rm_work | though from a security perspective it *is* possibly worrying if there's literally no way to do a hard-delete | 19:17 |
| rm_work | from a customer's perspective | 19:17 |
| woodster_ | yeah something like that. However, that is baked into the base model of all our entities right now. So all entities inherit that behavior, whether or not they should or not. | 19:17 |
| jaosorior | rm_work: exactly... | 19:17 |
| rm_work | woodster_: I hadn't realized we weren't doing queries directly, but compiling a list ahead of time -- in that case, I guess it's not a big deal to do lists in the columns | 19:18 |
| woodster_ | rm_work, well that is why we perpetually bring up the notion of soft vs hard deletes in barbican :) | 19:18 |
| redrobot | bdpayne we got a lot of grief during incubation for not using Pecan. AFAIK, Pecan is the recommended lib for new OpenStack projects. | 19:18 |
| jaosorior | woodster_: Yup, I noticed. And the fact that it might be a security issue is what concerns me | 19:18 |
| alee | woodster_, so would you propose we drop the constraint? | 19:18 |
| woodster_ | rm_work, yeah the way the policy stuff works now is you pull all the data it needs to operate on into context, and then it chew on it via those policy.json rules | 19:19 |
| alee | woodster_, or improve the constraint to only include non-deleted keys? | 19:19 |
| alee | not sure how to do that .. | 19:19 |
| woodster_ | one option is to not inherit that base behavior for key/value pairs, or else to manage it only via the mapping of the parent entity as we do in other parts of the code...let me look for an examp;le | 19:20 |
| jaosorior | Or to divide the Base class. I think dstufft also had an issue with some class, where he chose not to use the Base class | 19:21 |
| dstufft | yea I did a thing for that | 19:22 |
| dstufft | I just copy/pasted from the base class | 19:22 |
| jaosorior | So, the base class could be divided, so the new base would contain the real basics for a model, while a subclass would contain all this added behaviour that not all models need. Such as the class that dstufft was working on, and now the ones that alee is working on | 19:23 |
| dstufft | yea | 19:23 |
| dstufft | the ModelBase or w/e it is has soft delete functionality in it that Ididn't want | 19:23 |
| dstufft | that could probably jsut be a mixin | 19:23 |
| dstufft | for SoftDeleteMixin | 19:23 |
| dstufft | or w/e | 19:23 |
| jaosorior | dstufft: Which is exactly what alee doesn | 19:24 |
| jaosorior | doesn't want either | 19:24 |
| *** kebray has joined #openstack-barbican | 19:24 | |
| jaosorior | so I would go for that mixing approach | 19:24 |
| alee | dstufft, did you check in some code to do this? | 19:24 |
| woodster_ | alee, so this stores order plugin meta: https://github.com/openstack/barbican/blob/master/barbican/tasks/certificate_resources.py#L264 which eventually calls this: https://github.com/openstack/barbican/blob/master/barbican/model/repositories.py#L963 | 19:25 |
| jaosorior | alee: He didn't. He just copied the base class stuff that he needed into his model | 19:25 |
| dstufft | yea just copy/paste https://github.com/openstack/barbican/blob/master/barbican/model/models.py#L553-L572 | 19:26 |
| woodster_ | alee, so sqlalchemy should be managing the mapping records for us. I'd say change your code to not delete things first and instead mimic what is in the second link there, and then see if that constraint violation occurs | 19:26 |
| alee | woodster_, looking .. | 19:26 |
| alee | jaosorior, dstufft , woodster_ I suppose at worst I could just override the delete() method? | 19:27 |
| woodster_ | that base model also uses UUIDs for the PK ID, which is not needed everywhere | 19:27 |
| alee | in my model subclass .. | 19:27 |
| dstufft | there's not much reason _not_ to use UUID pks though | 19:27 |
| woodster_ | alee, well, I'd prefer it if you could do the approach in that second link and let sqlalchemy handle things under the hood if possible | 19:27 |
| alee | woodster_, yup - looking | 19:28 |
| woodster_ | dstufft that was my thinkig originally, but I've heard folks say it can be less efficient for databases vs a monotonically increasing ID. With indexing that shouldn't affect queries though. | 19:29 |
| jaosorior | woodster_, dstufft: If I remember correctly, morganfainberg has something to say about that. | 19:30 |
| jaosorior | Or at least he said something last time this was mentioned | 19:30 |
| alee | woodster_, there are a few differences here . | 19:30 |
| alee | woodster_, I actually do something very similar to that | 19:31 |
| dstufft | woodster_: if the DB doesn't have a UUID type and it's represented as a string it can be yea | 19:31 |
| dstufft | my answer to that is generally use a better database :D | 19:31 |
| alee | woodster_, it works for OrderMetadata because we have no uniqueness constraint | 19:31 |
| jaosorior | dstufft: https://github.com/openstack/barbican/blob/master/barbican/model/models.py#L95 | 19:32 |
| woodster_ | dstufft, interesting...we are using the a string type for the ID in our base model now...I don't think sqlalchemy has a native UUID type? | 19:33 |
| woodster_ | jaosorior, they the | 19:33 |
| alee | woodster_, and I was actually wondering whether we should delete the entries in the order_metadata first .. | 19:33 |
| woodster_ | that's it | 19:33 |
| dstufft | woodster_: it does for postgresql | 19:33 |
| alee | woodster_, I suspect that we really should | 19:34 |
| jaosorior | dstufft: I haven't found a uuid type for sqlalchemy | 19:34 |
| jaosorior | :( | 19:34 |
| jaosorior | it exists, but as a dialect | 19:34 |
| jaosorior | from sqlalchemy.dialects.postgresql import UUID | 19:34 |
| alee | woodster_, this worked fine when I did not have the constraint in there. I suspect order_meta is doing the smae thing | 19:35 |
| jaosorior | dstufft, woodster: What could be done is this: http://sqlalchemy.readthedocs.org/en/improve_toc/core/custom_types.html#backend-agnostic-guid-type | 19:36 |
| woodster_ | alee, I see. You should be able to set your dict on their directly (well, except for converting the value to the entity type), and sqlalchemy should handle removes/adds/updates for you. I'd try that out if you can. Worst case a hard-delete of the record should work, just messier | 19:37 |
| woodster_ | alee, you might be right about that | 19:37 |
| alee | woodster_, I think its the right thing to have the constraint in there. but for that to work, we need a real delete. | 19:38 |
| woodster_ | jaosorior, oh that's some loveliness there! No need for sqlalchemy to add a UUID type to do that for me :) | 19:38 |
| alee | woodster_, or to somehow make the constraint soft-delete-aware. | 19:39 |
| woodster_ | alee, conditionals in constraints, oh no!!! :) | 19:39 |
| dstufft | conditional constraints are great | 19:40 |
| dstufft | and conditional indexes | 19:40 |
| woodster_ | dstufft can you even express that in sqlalchemy? | 19:40 |
| dstufft | with a postgresql dialect yet :| | 19:40 |
| alee | woodster_, I propose either 1) overriding delete() in my model 2)adding an optional parameter in the base delete() to allow for a hard-delete | 19:40 |
| jaosorior | woodster_: Well, it's their docs | 19:40 |
| dstufft | you just add a postgresql_where to the constraint clause | 19:41 |
| jaosorior | alee: I propose implementing the SoftDeleteMixing approach that we were talking about earlier | 19:41 |
| jaosorior | *Mixin | 19:41 |
| woodster_ | alee, what a mess. Can you try to set your dict of key/wrapped(values) directly onto the parent entity and see if sqlalchemy handles things correctly via that mapped collection? | 19:41 |
| alee | interesting -- let me see .. | 19:42 |
| woodster_ | jaosorior, mixin makes sense in general, but for those key/value mappings, sqlalchemy should really be able to handle that merging and to hard delete records we don't need | 19:44 |
| rm_work | So, the Consumers thing uses soft-delete and does UPDATE instead of INSERT if it needs to | 19:44 |
| rm_work | you could look at how that works maybe? >_> | 19:44 |
| woodster_ | rm_work, well I think it tries to insert first and if gets constraint violation then does the update correct? | 19:45 |
| jaosorior | anybody has time to review these ones? https://review.openstack.org/#/c/150756/2 I'm using the subsequent additions to the barbican-db-manage.py (and its commands) to work easier with fixing the bugs I've found in the migration scripts... and since I need them, the dependency chain is getting pretty long | 19:45 |
| rm_work | yeah I think that was what I opted for | 19:45 |
| rm_work | but I would have to check, it has been a while | 19:45 |
| woodster_ | rm_work, I'd prefer to not attempt the insert on a key/value pair if I know it's already there, to avoid that exception handling logic/overhead | 19:46 |
| rm_work | yeah, but the whole situation is not ideal | 19:46 |
| jaosorior | woodster_: +1 | 19:46 |
| rm_work | I miss UPSERT operations :P | 19:46 |
| rm_work | MySQL doesn't seem to support them IIRC | 19:46 |
| alee | woodster_, so right now - the code looks like this -- | 19:47 |
| alee | session = self.get_session(session) | 19:47 |
| alee | for k, v in old_ca.ca_meta.items(): | 19:47 |
| alee | v.delete(session) | 19:47 |
| alee | session.commit() | 19:47 |
| alee | for key in parsed_ca: | 19:47 |
| alee | meta = models.CertificateAuthorityMetadatum(key, parsed_ca[key]) | 19:47 |
| alee | old_ca.ca_meta[key] = meta | 19:47 |
| alee | old_ca.save(session) | 19:47 |
| alee | your'e suggesting I try -- > old_ca.ca_meta = parsed_ca | 19:48 |
| alee | old_ca.save(session) | 19:48 |
| woodster_ | alee, so I'd say not do the delete stuff at all in that first loop, build up a new dict in the second loop, and then do this: old_ca.ca_meta = new_dict_thinggy | 19:49 |
| alee | right -- thats what that line was .. | 19:49 |
| woodster_ | alee, I don't think you can do = parsed_ca directly (try it though) as I'm pretty sure sqlalchemy requires the model.CertificateAuth...() thing on the values in the mapping | 19:50 |
| alee | woodster_, ok - let me try .. | 19:50 |
| *** atiwari1 has joined #openstack-barbican | 19:54 | |
| woodster_ | alee: fingers crossed | 19:55 |
| *** atiwari has quit IRC | 19:56 | |
| alee | woodster_, nope it did not work | 20:00 |
| *** dstufft|vpn has joined #openstack-barbican | 20:00 | |
| *** dimtruck is now known as zz_dimtruck | 20:01 | |
| alee | woodster_, still get unique constraint | 20:02 |
| alee | woodster_, still get unique constraint violation | 20:02 |
| *** openstackgerrit has quit IRC | 20:04 | |
| woodster_ | Alee: Hmmm that's too bad :( | 20:05 |
| *** openstackgerrit has joined #openstack-barbican | 20:05 | |
| alee | woodster_, yeah -- I guess I can try the SoftDelete mixin thing | 20:05 |
| *** kgriffs is now known as kgriffs|afk | 20:05 | |
| *** arunkant_work has joined #openstack-barbican | 20:06 | |
| woodster_ | alee: I wonder if something is missing in sqlalchemy config wise? At any rate a hard delete would work | 20:07 |
| morganfainberg | rm_work: upsert? Update or insert? | 20:19 |
| openstackgerrit | Brianna Poulos proposed openstack/castellan: Add openstack/common log and policy modules https://review.openstack.org/151371 | 20:19 |
| *** arunkant_work has quit IRC | 20:21 | |
| morganfainberg | rm_work: you mean something like "insert <blah> on duplicate key update"? | 20:21 |
| alee | morganfainberg, yup | 20:22 |
| morganfainberg | alee: yeah. It works mostly in MYSQL. | 20:24 |
| openstackgerrit | Brianna Poulos proposed openstack/castellan: Copy cinder.keymgr to castellan https://review.openstack.org/148742 | 20:27 |
| openstackgerrit | Brianna Poulos proposed openstack/castellan: Copy cinder.keymgr to castellan https://review.openstack.org/148742 | 20:35 |
| bdpayne | woodster_ rm_work jaosorior redrobot Interesting. And here's I've been running an OpenStack cloud for years and have never needed Pecan until now. Are other projects going to be changing over or ?? | 20:36 |
| *** arunkant_work has joined #openstack-barbican | 20:44 | |
| openstackgerrit | Brianna Poulos proposed openstack/castellan: Add openstack/common log and policy modules https://review.openstack.org/151371 | 20:46 |
| openstackgerrit | Brianna Poulos proposed openstack/castellan: Copy cinder.keymgr to castellan https://review.openstack.org/148742 | 20:47 |
| alee | woodster_, there seems to be something in sqlalchemy called merge() | 20:51 |
| alee | woodster_, http://docs.sqlalchemy.org/en/rel_0_8/orm/session.html | 20:52 |
| alee | woodster_, it would seem that you could resolve all this by calling session.merge() instead of session.add() in save(), but doing this leads to all kinds of other tests failing | 20:53 |
| redrobot | bdpayne https://wiki.openstack.org/wiki/PecanStackForgeTransition | 20:54 |
| *** SheenaG1 has quit IRC | 20:55 | |
| redrobot | bdpayne actually, never mind, I thought that was more helpful than it really is... I'm trying to dig up where the recommendation for Pecan came from... | 20:55 |
| openstackgerrit | Brianna Poulos proposed openstack/castellan: Copy cinder.keymgr to castellan https://review.openstack.org/148742 | 21:00 |
| redrobot | bdpayne so digging through my notes, it seems Ceilometer is the only project that currently uses Pecan. | 21:02 |
| redrobot | bdpayne it looks like there was a design session in Hong Kong about moving Nova to Pecan, but I'm not sure what the result of that was... http://icehousedesignsummit.sched.org/event/4a7316a4f5c6f783e362cbba2644bae2#.VMqf3cbFtoB | 21:02 |
| bdpayne | interesting, thanks | 21:03 |
| bdpayne | OpenStack is an interesting ecosystem ;-) | 21:03 |
| dstufft|vpn | should switch to asyncio and python 3 only! | 21:04 |
| dstufft|vpn | >:] | 21:04 |
| bdpayne | heh, clearly | 21:04 |
| greghaynes | redrobot: I think ironic uses pecan | 21:13 |
| greghaynes | redrobot: and wsme | 21:13 |
| greghaynes | Re: ACL's, postgres now has row level ACL's so we should clearly just switch to that and let the db handle it ;) | 21:18 |
| dstufft|vpn | I would be a very happy person if Openstack just mandated postgresql | 21:23 |
| dstufft|vpn | db portability is not something I'm a fan of :| | 21:23 |
| greghaynes | Yea, I dont think openstack generally is too crazy about that either, ive heard removing pg support brought up many times | 21:24 |
| dstufft|vpn | awe, I would hope they'd go the other way ;( but I'm a big pg fan so ;P | 21:25 |
| greghaynes | The reality is were basically tied to mysql, no one actually runs pg deployments AFAICT | 21:25 |
| * greghaynes is too | 21:25 | |
| dstufft|vpn | supporting only MySQL is probably better than supporting the subset of SQL that works between PostgreSQL and MySQL and whatever other DBs that are supported | 21:25 |
| greghaynes | json support and row level acls = awesome for rest services | 21:26 |
| greghaynes | once people start using it | 21:26 |
| greghaynes | totally | 21:26 |
| greghaynes | The least common denominator between them is pretty crappy and its a lot of extra work for not much benefit | 21:26 |
| *** kebray has quit IRC | 21:27 | |
| dstufft|vpn | yea | 21:27 |
| *** nkinder has joined #openstack-barbican | 21:55 | |
| *** dstufft|vpn has quit IRC | 22:01 | |
| *** jamielennox|away is now known as jamielennox | 22:03 | |
| *** kgriffs|afk is now known as kgriffs | 22:04 | |
| alee | woodster_, ping | 22:06 |
| *** chlong has quit IRC | 22:08 | |
| *** kebray has joined #openstack-barbican | 22:09 | |
| *** kgriffs is now known as kgriffs|afk | 22:10 | |
| *** zz_dimtruck is now known as dimtruck | 22:11 | |
| alee | woodster_, nm - got it | 22:14 |
| *** kgriffs|afk is now known as kgriffs | 22:17 | |
| *** lisaclark1 has joined #openstack-barbican | 22:21 | |
| *** lisaclark1 has quit IRC | 22:21 | |
| openstackgerrit | Ade Lee proposed openstack/barbican: Add code to populate CA tables and select plugin based on ca_id https://review.openstack.org/150070 | 22:26 |
| openstackgerrit | Ade Lee proposed openstack/barbican: Added new repository classes and controller classes for CAs https://review.openstack.org/147981 | 22:26 |
| openstackgerrit | Thomas Dinkjian proposed openstack/python-barbicanclient: Initial directory changes and files for python-babricanclient functional tests https://review.openstack.org/151409 | 22:26 |
| alee | woodster_, jaosorior updated patches with mixin class to do soft-delete | 22:27 |
| *** kgriffs is now known as kgriffs|afk | 22:34 | |
| rm_work | morganfainberg: ah, so apparently I just didn't know the correct keywords for MySQL UPSERT :) cool | 22:36 |
| rm_work | I will check this out -- though I doubt it works with portable SQL via SQLAlchemy | 22:36 |
| morganfainberg | rm_work, never know. might work in SQLA | 22:36 |
| dstufft | UPSERT is generally a MySQL specific feature | 22:36 |
| dstufft | postgresql is working on adding support for it though as I understand | 22:37 |
| *** paul_glass has quit IRC | 22:40 | |
| *** crc32 has joined #openstack-barbican | 22:51 | |
| *** openstackgerrit has quit IRC | 22:51 | |
| *** openstackgerrit has joined #openstack-barbican | 22:51 | |
| *** crc32 has quit IRC | 23:24 | |
| *** crc32 has joined #openstack-barbican | 23:27 | |
| *** ametts has quit IRC | 23:39 | |
| *** chlong has joined #openstack-barbican | 23:53 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!