| openstackgerrit | Steve Martinelli proposed a change to openstack/barbican: Move to oslotest https://review.openstack.org/116700 | 00:24 |
|---|---|---|
| hockeynut | redrobot looking at the patch above from SteveM - it passed devstack gate yet I see that integrityerror in the logs: http://logs.openstack.org/00/116700/1/check/gate-barbican-devstack-dsvm/4c1368b/logs/screen-barbican.txt.gz | 00:59 |
| hockeynut | makes me sad | 01:06 |
| *** lisaclark1 has joined #openstack-barbican | 01:14 | |
| *** alee_dinner is now known as alee | 01:45 | |
| *** woodster_ has quit IRC | 02:15 | |
| *** bdpayne has joined #openstack-barbican | 02:20 | |
| *** ryanpetrello has quit IRC | 02:21 | |
| *** ryanpetrello has joined #openstack-barbican | 02:27 | |
| *** gyee has quit IRC | 02:47 | |
| *** juantwo has quit IRC | 03:12 | |
| *** alee has quit IRC | 04:06 | |
| *** lisaclark1 has quit IRC | 04:07 | |
| *** alee has joined #openstack-barbican | 04:19 | |
| *** kebray has quit IRC | 05:31 | |
| *** bdpayne has quit IRC | 05:50 | |
| *** bdpayne has joined #openstack-barbican | 05:54 | |
| *** Nirupama has joined #openstack-barbican | 06:08 | |
| *** bdpayne has quit IRC | 06:59 | |
| *** jamielennox is now known as jamielennox|away | 08:03 | |
| *** Nirupama has quit IRC | 08:13 | |
| *** tkelsey has joined #openstack-barbican | 09:37 | |
| tkelsey | hello Barbican people, anyone know if somthing has changed recently that would make the quick start curl examples fail? | 09:38 |
| tkelsey | the ones from here: https://github.com/cloudkeep/barbican/wiki/Barbican-Quick-Start-Guide | 09:39 |
| tkelsey | running them used to work but now just barfs up a 400 :-( | 09:39 |
| *** denis_makogon has joined #openstack-barbican | 11:13 | |
| *** juantwo has joined #openstack-barbican | 12:10 | |
| *** juantwo has quit IRC | 12:12 | |
| *** juantwo has joined #openstack-barbican | 12:12 | |
| *** SheenaG1 has joined #openstack-barbican | 12:30 | |
| openstackgerrit | Tim Kelsey proposed a change to openstack/barbican: Adding a plugin to interact with HP Atalla ESKM https://review.openstack.org/116878 | 12:30 |
| *** jaosorior has joined #openstack-barbican | 12:33 | |
| *** SheenaG11 has joined #openstack-barbican | 12:37 | |
| *** SheenaG1 has quit IRC | 12:39 | |
| openstackgerrit | Tim Kelsey proposed a change to openstack/barbican: Adding a plugin to interact with HP Atalla ESKM https://review.openstack.org/116878 | 12:39 |
| *** denis_makogon has quit IRC | 12:41 | |
| openstackgerrit | Tim Kelsey proposed a change to openstack/barbican: Adding a plugin to interact with HP Atalla ESKM https://review.openstack.org/116878 | 12:42 |
| *** sld has quit IRC | 13:08 | |
| *** nkinder has quit IRC | 13:18 | |
| *** lisaclark1 has joined #openstack-barbican | 13:19 | |
| *** akoneru_ has joined #openstack-barbican | 13:37 | |
| *** paul_glass has joined #openstack-barbican | 13:45 | |
| *** lisaclark1 has quit IRC | 13:52 | |
| *** lisaclark1 has joined #openstack-barbican | 13:53 | |
| *** denis_makogon has joined #openstack-barbican | 13:57 | |
| *** denis_makogon has quit IRC | 13:57 | |
| *** SheenaG11 has quit IRC | 14:01 | |
| *** akoneru_ has quit IRC | 14:06 | |
| *** SheenaG1 has joined #openstack-barbican | 14:11 | |
| *** nkinder has joined #openstack-barbican | 14:12 | |
| *** SheenaG11 has joined #openstack-barbican | 14:12 | |
| *** SheenaG1 has quit IRC | 14:15 | |
| *** atiwari has joined #openstack-barbican | 14:17 | |
| *** akoneru_ has joined #openstack-barbican | 14:21 | |
| *** lisaclark1 has quit IRC | 14:24 | |
| *** woodster_ has joined #openstack-barbican | 14:31 | |
| *** akoneru_ has quit IRC | 14:33 | |
| *** lisaclark1 has joined #openstack-barbican | 14:34 | |
| openstackgerrit | Tim Kelsey proposed a change to openstack/barbican: Adding a plugin to interact with HP Atalla ESKM https://review.openstack.org/116878 | 14:36 |
| *** denis_makogon has joined #openstack-barbican | 14:41 | |
| *** kebray has joined #openstack-barbican | 14:45 | |
| *** kebray has quit IRC | 14:46 | |
| *** kebray has joined #openstack-barbican | 14:46 | |
| hockeynut | hi tkelsey - we've recently removed tenant ID from the URLs - seems that the wiki needs to catch up. | 14:52 |
| hockeynut | remove those tenant IDs and you should be ok | 14:52 |
| tkelsey | thanks hockeynut, I have it working now, need to add X-Project-Id header as well | 14:53 |
| hockeynut | coolness | 14:53 |
| tkelsey | anyone know why this change was not done as api v2? could have maintained compatibility for anyone using v1 that way | 14:54 |
| jaosorior | hello people | 15:00 |
| *** kebray has quit IRC | 15:02 | |
| *** rellerreller has joined #openstack-barbican | 15:03 | |
| chellygel | hey jaosorior! | 15:16 |
| chellygel | welcome back! how was vacation? | 15:16 |
| jaosorior | well, I'm sunburned, exhausted and stinky | 15:18 |
| jaosorior | it was awesome! :P | 15:18 |
| jaosorior | 8 day reggae festival and then a couple of days in Barcelona. Excellent food, good music, good parties, had a great time :D but now back in business | 15:19 |
| chellygel | whoa, thats intense | 15:20 |
| *** kebray has joined #openstack-barbican | 15:21 | |
| jaosorior | how's it going over there? | 15:22 |
| chellygel | so far so good, if you ask me :) | 15:22 |
| jaosorior | excellent :D | 15:26 |
| *** akoneru has joined #openstack-barbican | 15:29 | |
| woodster_ | jaosorior: welcome back! | 15:32 |
| jaosorior | woodster_: Thanks Mr.! | 15:34 |
| redrobot | tkelsey this change was done as a v1 since we're still in incubation. we figured it would be easier to break compatibility instead of keeping backwards compat with an api that nobody is using in production. | 15:49 |
| redrobot | tkelsey we also agreed to support the API that will be released for Juno. So I would not expect breaking changes like this after Juno. | 15:50 |
| redrobot | jaosorior welcome back, guey! | 15:50 |
| tkelsey | redrobot: that makes sense, good to know thanks | 15:50 |
| jaosorior | redrobot: gracias wei :D | 15:51 |
| tkelsey | redrobot: worth noting that some projects are starting the adopt Barbican now, e.g. https://review.openstack.org/#/c/104339/ | 15:53 |
| jaosorior | redrobot, judging by tkelsey's concerns and by that commit... from which I guess more will come, I think more emphasis should come on getting the client stuff refactored and nicely done. Has there been any advances there? And, need any help with that? | 15:55 |
| redrobot | jaosorior actually, yes. rm_work has been doing a lot of work on the client. | 15:55 |
| redrobot | jaosorior I'd like your thoughts on http://specs.openstack.org/openstack/barbican-specs/specs/juno/client-refactor-models.html when you get a chance | 15:56 |
| redrobot | jaosorior rm_work has some CRs implementing that BP up for review | 15:56 |
| redrobot | tkelsey noted. thanks for the heads up | 15:56 |
| tkelsey | redrobot: no problem, the client work sounds good | 15:57 |
| jaosorior | redrobot: sure, I'll check them out. I have just started reviewing stuff now that I'm home. At the moment I'm checking out this fellow https://review.openstack.org/#/c/110817 , but then I'll go for the client stuff | 15:58 |
| jaosorior | Though first I should fix the issue of the lack of cold beer in my apartment... | 15:58 |
| *** gyee has joined #openstack-barbican | 16:05 | |
| rm_work | jaosorior: Barcelona is one of my favorite world cities :) | 16:09 |
| rm_work | jaosorior: welcome back, would love feedback on my client CRs. about to do some refactoring to them right now actually to make the factory methods have more useful signatures | 16:09 |
| jaosorior | excellent | 16:10 |
| jaosorior | rm_work: Barcelona is damn awesome! | 16:10 |
| jaosorior | but anyway | 16:10 |
| jaosorior | rm_work: most likely tomorrow I will be able to give feedback on your stuff | 16:10 |
| rm_work | jaosorior: ok. I am here tomorrow and then I fly tomorrow night to Seattle for PAX :) | 16:11 |
| rm_work | after which I'll be back on... the next Tuesday I think | 16:11 |
| rm_work | I will be able to do some minor work while I am there though to address comments on the CR as long as it isn't hours of refactoring :) | 16:12 |
| jaosorior | I can try to review them today | 16:12 |
| rm_work | fortunately the client isn't subject to J3 freeze | 16:12 |
| *** bdpayne has joined #openstack-barbican | 16:12 | |
| jaosorior | just need to get my beer issue sorted out, and then I'm ready to read :P | 16:12 |
| rm_work | so I don't think it's a huge deal | 16:12 |
| rm_work | heh kk | 16:12 |
| jaosorior | redrobot, rm_work: why does the secrets and orders need to have different names for persisting the object? (store and submit) | 16:14 |
| rm_work | jaosorior: i bitched about that, you're going to have to take it up with redrobot | 16:15 |
| rm_work | I preferred having it be consistent | 16:15 |
| rm_work | I thought .save() on everything would be good | 16:15 |
| jaosorior | redrobot: I think we even talked about having a consistent name when we discussed some of the refactoring stuff on the mid-cycle meetup | 16:15 |
| rm_work | jaosorior: that is an easy fix though if we decide to do that :() | 16:16 |
| rm_work | * :) | 16:16 |
| jaosorior | redrobot: is the etherpad of the discussion around somewhere? | 16:16 |
| jaosorior | And, I don't really see the lazy initialization concept that was initially proposed mentioned in the spec, will that be considered? or is that a different spec? | 16:18 |
| *** lisaclark1 has quit IRC | 16:18 | |
| rm_work | ? | 16:18 |
| rm_work | define lazy initialization? | 16:18 |
| rm_work | I don't lazy-load the basic data on stuff, but i do lazy-load secret payload or any sub-objects | 16:19 |
| jaosorior | oh, alright, well, it's more or less that; what I meant | 16:20 |
| *** lisaclark1 has joined #openstack-barbican | 16:24 | |
| rm_work | alright, refactor done | 16:25 |
| rm_work | check out the review that's about to come up | 16:25 |
| rm_work | oh, question | 16:25 |
| rm_work | on the setter for bit_length on an order, I'm doing some validation: | 16:26 |
| rm_work | if value < 8 or value % 8 != 0 or type(value) != int: | 16:26 |
| rm_work | raise ValueError("bit_length must be an integer multiple of 8") | 16:26 |
| rm_work | should I just... not, and leave validation to the server on a .store() ? | 16:26 |
| jaosorior | I'm actually reviewing this one at the moment: https://review.openstack.org/#/c/115080 | 16:26 |
| rm_work | yeah that's it | 16:26 |
| rm_work | i'm JUST NOW submitting a patch | 16:26 |
| jaosorior | ok, I'll leave my comments there, and review the newer patch | 16:27 |
| jaosorior | haha, well, one comment :P | 16:27 |
| rm_work | well, I guess I could wait until you comment? | 16:27 |
| rm_work | can you tell me what it is and I'll just fix whatever it is in this patch? :P | 16:28 |
| jaosorior | anyway, I didn't finish reviewing | 16:28 |
| rm_work | heh | 16:28 |
| rm_work | alright | 16:28 |
| rm_work | submitting | 16:28 |
| jaosorior | I'll read what you upload next | 16:28 |
| openstackgerrit | Adam Harwell proposed a change to openstack/python-barbicanclient: Refactor client models in python-barbicanclient https://review.openstack.org/115080 | 16:28 |
| woodster_ | can I get a review of this CR?: https://review.openstack.org/#/c/115715/ | 16:28 |
| rm_work | just changed the factory methods | 16:28 |
| jaosorior | woodster_: sure, but now I'm serious about the beer thing haha, off to the store now :P | 16:29 |
| rm_work | lol | 16:29 |
| woodster_ | nice! | 16:31 |
| alee | woodster_, ping | 16:34 |
| woodster_ | alee: hello | 16:34 |
| alee | woodster_, hey -- I have a WIP patch that rests on top of the two patches you already have out there. | 16:35 |
| alee | woodster_, it puts in the processing for once you recieve a cert | 16:35 |
| woodster_ | alee: oh the web we weave! :) | 16:35 |
| alee | and also a start at the processing when the ca is not avilable | 16:36 |
| woodster_ | alee: excellent! Just need some reviewers | 16:36 |
| alee | and when return waiting_for_ca | 16:36 |
| rm_work | I started to review that and then realized the best I could do on that section is nitpick grammar and style, since I don't know what's going on there yet :( | 16:37 |
| woodster_ | alee: chellygel is working on PUT to /orders to modify certificate orders | 16:37 |
| alee | I say a start becauase it basically identfies what object, method, args, time need to be retried | 16:37 |
| alee | ok good | 16:37 |
| alee | but doesn't have the actual scheduler code | 16:37 |
| *** kebray has quit IRC | 16:37 | |
| alee | thats something that needs to be added | 16:37 |
| alee | anyways - it doesn't pass all the tests yet -- some tests need to be modified - and many more need to be added, but I'm going to try to rebase now and I'll put it up. | 16:38 |
| alee | and we can review whats there and what more is needed. | 16:39 |
| woodster_ | alee: I can put up a CR to add the periodic tasks to the worker processes....it will run at whatever frequency is desired. We had used that feature for an internal project. We hadn't planned to add that until Sept sometime, but if you can use it sooner, we can make it a priority. | 16:40 |
| woodster_ | alee: did you take a crack at the retry table as well? | 16:41 |
| alee | woodster_, I just identified what needs to be in it | 16:41 |
| *** nkinder has quit IRC | 16:41 | |
| alee | woodster_, I'll ping you once its up | 16:42 |
| redrobot | jaosorior rm_work RE: consistent naming, we also have to take the CLI into account. woodster_ originally pushed for "store" being the verb used to save a secret to barbican. I would be OK with save, but keep in mind the CLI would also have to change to be "barbican secret save --blah". | 16:43 |
| redrobot | I also think that "submitting" an order more accurately describes what is going on. | 16:45 |
| redrobot | "saving" an order is not as descriptive. I'm not sure that I'm OK with an ambiguous verb for the sake of consistency. | 16:45 |
| woodster_ | alee: sounds good! A quirk to think about is the RPC methods themselves...right now tasking is setup for for general actions on orders, such as begin-order and update-order. If plugins are specifying the retry methods, we would either need to add tasks keyed to those methods, or else map them to the generic order tasks. | 16:46 |
| rm_work | redrobot: uhh, would the CLI need to change to match the API (the API of the client code, I mean)? | 16:47 |
| * redrobot shrugs | 16:47 | |
| rm_work | I don't see why it necessarily has to | 16:47 |
| redrobot | rm_work depends on how much "consistency" we want ;) | 16:47 |
| rm_work | I vote CLI uses the verbs you want | 16:47 |
| woodster_ | redrobot, jaosorior: secret store or save seems ok to me. Order submit is better to me. | 16:47 |
| rm_work | and the client-API just uses "save()" | 16:47 |
| alee | woodster_, ok | 16:48 |
| woodster_ | so add the dashes in there, like secret-save? :) | 16:48 |
| * redrobot does not like dashes | 16:48 | |
| woodster_ | but other projects are using it! I don't like it either though | 16:49 |
| redrobot | we should look to see what the unified CLI is doing | 16:50 |
| alee | woodster_, ping | 16:56 |
| alee | woodster_, I'm trying to submit my patch but its not working because its trying to submit your patch too. | 16:57 |
| alee | and that patch hasn't changed | 16:58 |
| alee | does that make sense? | 16:58 |
| jaosorior | woodster_: openstackclient doesn't use the dash notation, many other projects do, but I'm hoping the unified client will gain more traction :O | 16:59 |
| woodster_ | alee: well, I've been having to rebase it periodically since it's been sitting out there for a while. :) I wonder if that is playing havoc with your dependent CR? | 17:01 |
| *** rellerreller has quit IRC | 17:01 | |
| alee | woodster_, no - I got your rebased copy | 17:01 |
| alee | woodster_, the problem is that gerrit is trying to send both your and my cr in at the same time | 17:02 |
| alee | woodster_, as I have not changed yours, gerrit rejects it | 17:02 |
| alee | woodster_, what gerrit suggests is that I squash the changes -- I can do that and then we'll just have one CR to review. | 17:04 |
| reaperhulk | is that other commit in another CR? It should allow you to submit that and it will show up as a dependency in gerrit | 17:04 |
| woodster_ | alee: ....or we can get my CR approved/merged...just sayin' I think squashing would make for a pretty big CR though, wouldn't it? | 17:05 |
| alee | woodster_, right - thats the other option | 17:05 |
| alee | woodster_, reaperhulk interesting how gerrit allows (or wants to allow) me to modify uyour cr | 17:06 |
| alee | reaperhulk, so woodster_ has a cr thats in review | 17:06 |
| alee | reaperhulk, I have a cr that goes on top of that | 17:06 |
| alee | I want to post my cr for review, but woodster's cr is not yet merged | 17:07 |
| alee | so git review wants to submit both crs | 17:07 |
| alee | (woodsters and mine) | 17:07 |
| alee | and right now is choking because woodsters cr has not been changed | 17:08 |
| reaperhulk | that...shouldn't matter. | 17:08 |
| *** lisaclark1 has quit IRC | 17:08 | |
| alee | reaperhulk, :) | 17:08 |
| redrobot | alee there's a way to mark your commmit as dependent on woodster's | 17:08 |
| reaperhulk | the existence of an identical commit is what gerrit uses as a key to know it's a dependency | 17:09 |
| reaperhulk | or at least that's how it worked a few months ago, haha | 17:09 |
| redrobot | alee have you tried https://wiki.openstack.org/wiki/Gerrit_Workflow#Add_dependency | 17:09 |
| reaperhulk | git review -R maybe? rm_work has done this for several recent CRs so he may know as well | 17:09 |
| alee | ok -- let me try that .. | 17:10 |
| woodster_ | not sure if this is still accurate anymore: https://github.com/cloudkeep/barbican/wiki/Gerrit-Review-Process#advanced-workflows | 17:10 |
| woodster_ | I think rm_work uses this flow: https://wiki.openstack.org/wiki/Gerrit_Workflow#Rebase_On_Dependent | 17:11 |
| rm_work | yes so | 17:12 |
| rm_work | easiest way is: | 17:12 |
| rm_work | get your commit hash | 17:12 |
| woodster_ | rm_work: ^^^^ | 17:12 |
| rm_work | git review -d <ID of dependent> | 17:12 |
| woodster_ | rm_work: sorry, trying to multitask, didn't see your response | 17:12 |
| rm_work | git cherry-pick <your commit hash> | 17:12 |
| rm_work | git review | 17:12 |
| rm_work | :) | 17:12 |
| rm_work | so like | 17:13 |
| rm_work | git review -d 113393 | 17:13 |
| rm_work | would pull down https://review.openstack.org/#/c/113393/5 | 17:13 |
| rm_work | then git cherry-pick 7462e1f3bf07b40455dd9e304ef4add988a6b4cf | 17:13 |
| rm_work | would put your commit on top | 17:13 |
| rm_work | and then git review and you're set | 17:13 |
| *** rellerreller has joined #openstack-barbican | 17:13 | |
| rm_work | be careful though if there have been changes below you, you will need to repeat this process or you will trample all over the commit you're dependent on, which is annoying for that person :) | 17:14 |
| rm_work | alee: ^^ | 17:14 |
| reaperhulk | shouldn't you branch after the -d? | 17:14 |
| rm_work | no | 17:14 |
| rm_work | it doesn't matter at all | 17:14 |
| rm_work | the local branch stuff is completely ignored by gerrit | 17:14 |
| rm_work | and then next time you do "git review -d <ID>" it'll overwrite it anyway | 17:15 |
| rm_work | it rebuilds the local branch every time | 17:15 |
| reaperhulk | that annoys me. | 17:15 |
| rm_work | heh | 17:15 |
| reaperhulk | but makes sense, thanks rm_work | 17:15 |
| rm_work | gerrit is wonky. live within its rules OR SUFFER | 17:15 |
| woodster_ | rm_work: if I rebase that dependent CR after this process, would you just do git review -d 113393 again? (hoping that does a ff-only sort of merge)? | 17:15 |
| rm_work | err | 17:15 |
| rm_work | just start over from the beginning, yes | 17:16 |
| rm_work | any time the dependent commit changes, just git review -d it and cherry-pick your hash again | 17:16 |
| openstackgerrit | Ade Lee proposed a change to openstack/barbican: Additional work on certificate processing https://review.openstack.org/116956 | 17:16 |
| rm_work | when you do "git review" it'll complain about multiple commits, just check the hashes to make sure they are correct, and say yes, and it will not affect the commit below you | 17:16 |
| alee | hey - it worked :) | 17:16 |
| reaperhulk | woo, dependency! | 17:16 |
| woodster_ | probably best to commit local changes, get the new commit ID, and then cherry pick I'd think | 17:17 |
| rm_work | yeah we have HUGE dependency chains in Neutron, so I've gotten quite proficient with this process :) | 17:17 |
| rm_work | woodster_: yes | 17:17 |
| rm_work | well | 17:17 |
| alee | thanks all! | 17:17 |
| rm_work | essentially >_> you get used to it | 17:17 |
| alee | woodster_, so its up there for for you to take a look at .. | 17:17 |
| rm_work | woodster_: I go back and forth locally on my own dep chains a lot too | 17:17 |
| rm_work | just keep track of which hashes are your latest and it's fine :) | 17:18 |
| reaperhulk | now to review https://review.openstack.org/#/c/115715/ so we can review alee's work ;) | 17:18 |
| alee | reaperhulk, woodster_ like woodster's cr , still wip | 17:19 |
| alee | but gives you an idea as to the direction | 17:19 |
| reaperhulk | ah, I see you gave it the workflow tag | 17:19 |
| alee | reaperhulk, yeah - before anyone pings me about failing tests | 17:20 |
| alee | or lack of additional tests | 17:20 |
| alee | they're coming - I just want to make sure what I'm doing is sane | 17:21 |
| openstackgerrit | Adam Harwell proposed a change to openstack/python-barbicanclient: Add Containers to python-barbicanclient https://review.openstack.org/113393 | 17:22 |
| rm_work | still need tests but otherwise that CR is also ready for review jaosorior | 17:22 |
| redrobot | woodster_ RE https://review.openstack.org/#/c/108163/ how do you feel about just adding a additional field to the response, instead of having two different responses in the same resource? | 17:29 |
| openstackgerrit | John Wood proposed a change to openstack/barbican: Initial connect orders resource to certificate processing https://review.openstack.org/115715 | 17:37 |
| woodster_ | ugh, some rebase glitch on this CR: https://review.openstack.org/#/c/115715 | 17:38 |
| woodster_ | reaperhulk: ^^^^ Thanks for pointing out the missing code | 17:38 |
| reaperhulk | np | 17:38 |
| jaosorior | woodster_: https://review.openstack.org/#/c/115715/4/barbican/tasks/certificate_resources.py line 66 | 17:41 |
| reaperhulk | woodster_: so is it possible to exercise that code via unit test or is this a models issue? | 17:41 |
| jaosorior | woodster_: just to have it clear, the result of your CR is backwards compatible, right? so that means that you can still create orders with the same logic as before | 17:48 |
| *** tkelsey has quit IRC | 17:49 | |
| woodster_ | reaperhulk: this is models stuff, which does need to get tested eventually. This CR is taking a crack at such testing btw: https://review.openstack.org/#/c/110817/11/barbican/tests/tasks/test_keystone_consumer.py,cm | 17:49 |
| reaperhulk | ah, cool | 17:50 |
| reaperhulk | well, I'll give this a +2 now then | 17:50 |
| woodster_ | jaosorior: that's correct. Both types of orders POSTS are supported. | 17:50 |
| jaosorior | and eventually the meta approach will only be used, right? | 17:51 |
| *** paul_glass has quit IRC | 17:51 | |
| woodster_ | that's correct | 17:53 |
| jaosorior | alright, then I guess your CR covers what it intends to cover | 17:54 |
| jaosorior | -1'd it for VERY minor things though (sorry) | 17:54 |
| reaperhulk | those look like changes worth making to me | 17:56 |
| jaosorior | By the way, I intend to rename the URI bit from the clit, in favor of ref, do people dig the idea? | 17:58 |
| jaosorior | several people had brought up that URI could have a better naming in the client, and I had postponed changing it until the moving to cliff landed, so now I could do the change (dependant on rm_work's commit) if people think it would be a good idea | 18:03 |
| *** bdpayne has quit IRC | 18:04 | |
| *** nkinder has joined #openstack-barbican | 18:04 | |
| *** bdpayne has joined #openstack-barbican | 18:04 | |
| *** akoneru is now known as akoneru_lunch | 18:24 | |
| *** tkelsey has joined #openstack-barbican | 18:39 | |
| *** paul_glass has joined #openstack-barbican | 18:40 | |
| *** lisaclark1 has joined #openstack-barbican | 18:42 | |
| openstackgerrit | Arun Kant proposed a change to openstack/barbican: Adding keystone notification listener support https://review.openstack.org/110817 | 18:42 |
| *** tkelsey has quit IRC | 18:44 | |
| openstackgerrit | John Wood proposed a change to openstack/barbican: Initial connect orders resource to certificate processing https://review.openstack.org/115715 | 18:47 |
| *** kebray has joined #openstack-barbican | 18:51 | |
| woodster_ | jaosorior: ^^^^ that should address your concerns. | 18:55 |
| *** lisaclark1 has quit IRC | 18:57 | |
| alee | woodster_, had chance to look at my CR yet? | 18:59 |
| redrobot | jaosorior refactor the clit... >_> | 19:03 |
| *** rellerreller has quit IRC | 19:09 | |
| redrobot | my new glasses are pretty spiffy! :D | 19:19 |
| jaosorior | * cli | 19:19 |
| rm_work | lol yes I caught that too :P | 19:20 |
| rm_work | woodster_ / reaperhulk: so you guys are cool with the main client refactor CR? | 19:21 |
| rm_work | guessing so since you both +2'd it :P | 19:21 |
| reaperhulk | pretty much. | 19:21 |
| rm_work | kk | 19:23 |
| rm_work | waiting to hear what jaosorior thinks | 19:23 |
| rm_work | jaosorior: https://review.openstack.org/#/c/115080/ | 19:23 |
| *** akoneru_lunch is now known as akoneru | 19:24 | |
| jaosorior | rm_work, well, it seems good mostly | 19:27 |
| jaosorior | though I just think that here https://review.openstack.org/#/c/115080/8/barbicanclient/base.py line 21 | 19:28 |
| jaosorior | you could use a parentheses (generator) instead of creating a list of objects | 19:28 |
| jaosorior | it would be a little performance improvement | 19:29 |
| jaosorior | oh, wait, I had forgotten about one function in your code, I'll add the comments there | 19:30 |
| jaosorior | by the way, is there a reason why the refs we use are full URLs and not just the uuids? | 19:32 |
| *** kebray has quit IRC | 19:34 | |
| rm_work | jaosorior: umm.. yes? because we're supposed to be using full HATEOAS refs everywhere | 19:35 |
| rm_work | I actually had to push a patch to containers just last week to fix one place where it was giving back IDs instead of full refs | 19:35 |
| rm_work | jaosorior: ha, line 21 there is code woodster_ copy/pasted to me and told me to use :P | 19:36 |
| jaosorior | uhm, yeah, but you could kind of assume most part of the URI and construct it where needed | 19:36 |
| rm_work | jaosorior: not necessarioly | 19:36 |
| rm_work | *necessarily | 19:36 |
| rm_work | supposedly you could interlink Barbican repositories | 19:37 |
| rm_work | i think maybe that was a future plan? | 19:37 |
| rm_work | but it came up in talks I had with redrobot | 19:37 |
| rm_work | and full URIs are used pretty much everywhere anyway | 19:37 |
| jaosorior | yeah, they are | 19:37 |
| redrobot | jaosorior full hrefs are preffered. | 19:38 |
| jaosorior | can you elaborate? | 19:38 |
| redrobot | the href fully describes the location of the object | 19:38 |
| rm_work | jaosorior: on the other function you commented on, I am not even 100% sure I should be doing the validation at all | 19:38 |
| rm_work | what do you think? | 19:39 |
| redrobot | if you had data in two different data centers for example, | 19:39 |
| redrobot | the hosts may be different | 19:39 |
| redrobot | in which case, you wouldn't be able to know which is the right host for a particualr uuid | 19:39 |
| redrobot | at least, that was my understanding of it | 19:39 |
| jaosorior | uhm, aren't you putting anyway the url of barbican as a parameter? | 19:40 |
| *** gyee has quit IRC | 19:40 | |
| redrobot | not sure if you can have a container that has secrets across environments? | 19:40 |
| jaosorior | I guess it kind of makes sense if you assume barbican could be federated | 19:40 |
| redrobot | jaosorior that's a good point. | 19:40 |
| rm_work | redrobot: it might work, as long as the auth is the same | 19:40 |
| jaosorior | but then why give the url of barbican at all? | 19:40 |
| rm_work | since you hit one Barbican endpoint, get a container, it has secrets from another repo, when it fetches the secrets it *does* use the URL from the URI | 19:41 |
| redrobot | I don't have a good answer for that... | 19:41 |
| rm_work | ^^\ | 19:41 |
| rm_work | what I just said, is why | 19:41 |
| rm_work | you need a starting point | 19:41 |
| rm_work | but from there, the resources could live in other repos | 19:41 |
| rm_work | specifically it is an issue for containers | 19:41 |
| redrobot | I think that ideally we should be getting the url from keystone's catalog | 19:41 |
| rm_work | maybe not as much for pure secrets | 19:41 |
| jaosorior | rm_work, what about the project_id? | 19:41 |
| rm_work | I guess we have to assume that we're talking about different DCs within the same system, so project-id would be the same | 19:42 |
| jaosorior | redrobot: that | 19:42 |
| rm_work | like I have some secrets in ORD and DFW, and put them in a container in IA | 19:42 |
| rm_work | *IAD | 19:42 |
| rm_work | project-id and auth would be the same | 19:42 |
| rm_work | well actually... would auth-tokens be the same across DCs? I don't remember if they're shared across DCs or not | 19:43 |
| redrobot | rm_work yep... but not LON... :-\ | 19:43 |
| rm_work | I *think* they are? | 19:43 |
| rm_work | lol yes LON | 19:43 |
| rm_work | LON is the red-headed stepchild of RAX | 19:43 |
| rm_work | I still don't understand why it's set up that way T_T | 19:43 |
| rm_work | EU law? | 19:43 |
| * redrobot shrugs | 19:44 | |
| redrobot | there was a patch in flight that would add catalog data to the keystone session | 19:44 |
| jaosorior | rm_work | 19:45 |
| redrobot | if it's landed we could refactor that now | 19:45 |
| jaosorior | I think you should remove the bit_length validation | 19:45 |
| jaosorior | it wasn't there before, and I think there is no actual constraint about the bits needing to form full bytes | 19:46 |
| rm_work | k | 19:46 |
| rm_work | it says so in the API docs, but heh | 19:46 |
| rm_work | yeah | 19:46 |
| jaosorior | it says so? | 19:46 |
| jaosorior | reaperhulk could help with this, maybe | 19:47 |
| reaperhulk | optimistic | 19:47 |
| reaperhulk | what's up | 19:47 |
| reaperhulk | bits do not need to form full bytes that is correct, although storing them is somewhat tricky without doing so :D | 19:48 |
| rm_work | https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface#orders-resource | 19:48 |
| rm_work | err, i think it was in there somewhere | 19:48 |
| rm_work | looking for it again | 19:48 |
| reaperhulk | Presumably anything generating non-byte aligned keys would know how to strip the padded bits though | 19:48 |
| rm_work | Values for bit_length must be integer multiples of eight (8, 16, 24, etc). Other values will be rejected with an HTTP 400 error. | 19:48 |
| rm_work | and "Note however that unlike with the secrets resource, the algorithm, bit_length and mode attributes are validated, to ensure that a secret can be generated per these specifications." | 19:49 |
| rm_work | is that incorrect? | 19:49 |
| jaosorior | rm_work: props to your memory | 19:49 |
| rm_work | but my real question was whether I should do the validation myself in the client or pass the responsibility down the chain to the server | 19:50 |
| rm_work | though I guess "is this actually a requirement at all" is now a thing | 19:50 |
| rm_work | the docs could be wrong -- they have been wrong before :P | 19:50 |
| jaosorior | I would say server | 19:50 |
| jaosorior | not the most optimal thing, but it would make things consistent | 19:51 |
| redrobot | I would argue client, since we could save users a trip to the server if we know it's going to fail | 19:51 |
| rm_work | redrobot: that's what prompted me to do it to begin with, but now all the stuff about validation in the server makes me wonder if we want to leave it up to the server and thus the specific plugins to make any validation decisions | 19:51 |
| rm_work | so we don't make a wrong choice in the client, or have to maintain separate validation rules in the client | 19:52 |
| rm_work | IE, rules change on the server -> have to update the client in parallel | 19:52 |
| jaosorior | well, I think that check should be on the server, for sure (if it isn't already), if you want to optimize the client, do so if you want | 19:52 |
| rm_work | I guess I am ok with just leaving both and going as-is | 19:53 |
| jaosorior | people are going to start debugging with curl and will not get appropriate responses from the server if it doesn't have these validations | 19:53 |
| rm_work | yeah the server *should* already do this | 19:53 |
| rm_work | though technically it still has nothing to do with this CR even if it doesn't | 19:53 |
| jaosorior | indeed | 19:53 |
| redrobot | jaosorior validation happens on the server, and there's work being done to defer validation to the plugin | 19:53 |
| jaosorior | cool | 19:53 |
| rm_work | jaosorior: would you mind removing your -1 if it were to stay as-is? | 19:53 |
| jaosorior | but now the question remains | 19:53 |
| jaosorior | should there be that validation at all?? | 19:54 |
| rm_work | ah, right | 19:54 |
| rm_work | is that validation correct | 19:54 |
| rm_work | or is it completely unnecessary | 19:54 |
| rm_work | reaperhulk is my best bet on answering that I think? | 19:54 |
| redrobot | there's a todo for changing bit length to byte length somehwere... | 19:54 |
| rm_work | heh | 19:55 |
| rm_work | well, at that point this needs a refactor anyway | 19:55 |
| reaperhulk | sorry, being pulled a bunch of directions at once here, is the question about whether we should do validation requiring byte alignment for bit length of keys in the metadata? | 19:55 |
| rm_work | so the check could be removed then | 19:55 |
| jaosorior | redrobot: I thought someone had said that bit_length should be kept X_x | 19:55 |
| reaperhulk | redrobot: we should remove that todo | 19:55 |
| reaperhulk | yeah we're not gonna make that transition | 19:55 |
| rm_work | reaperhulk: yeah so the API docs say "Values for bit_length must be integer multiples of eight (8, 16, 24, etc). Other values will be rejected with an HTTP 400 error." | 19:55 |
| rm_work | *for ORDERS* | 19:55 |
| rm_work | only for orders | 19:55 |
| rm_work | and the code in question is only on orders | 19:55 |
| reaperhulk | Oh okay | 19:55 |
| reaperhulk | I don't think it's unreasonable to leave that restriction on orders. Non-byte aligned keys have lots of issues and should be discouraged as much as is practical | 19:56 |
| rm_work | k | 19:56 |
| rm_work | then jaosorior, are we good on this CR? | 19:56 |
| rm_work | I don't think the [] -> () change is really meaningful :/ | 19:56 |
| jaosorior | well, basically my only comments left on your CR are nits, address them if you want | 19:56 |
| jaosorior | and the readability of that validation thing | 19:56 |
| rm_work | we're talking about a function that is used once per save, and is on a list of max size like, 10 | 19:56 |
| redrobot | I do like the idea of having a generator | 19:57 |
| *** rellerreller has joined #openstack-barbican | 19:57 | |
| rm_work | >_< | 19:57 |
| rm_work | damnit redrobot | 19:57 |
| redrobot | esp, if we're fetcthing every time | 19:57 |
| redrobot | sorry, haven't looked at the code... | 19:58 |
| rm_work | wait, which are you talking about | 19:58 |
| * redrobot looks | 19:58 | |
| jaosorior | lol | 19:58 |
| rm_work | published my responses | 19:58 |
| rm_work | which are essentially what I said here, just on the code for posterity | 19:58 |
| jaosorior | rm_work: cool | 20:00 |
| jaosorior | anyway, I could take the -1 off, it really is not a big deal | 20:00 |
| rm_work | I think I vote for that | 20:00 |
| rm_work | just go through as-is | 20:01 |
| jaosorior | yeah, thing is, if validation is done both on client and on the server, they might end up differing at some point and maintenance is gonna be messy | 20:01 |
| jaosorior | this is only one instance, but what if we decide to validate other parameters to optimize | 20:02 |
| jaosorior | So I would rather get rid of that validation and let the server deal with it | 20:02 |
| rm_work | that was what I mentioned earlier | 20:05 |
| rm_work | we'd be in a state of having to maintain two sets of validation code | 20:06 |
| rm_work | and keeping it synced | 20:06 |
| jaosorior | or we would end up with a validation library or something like this that both client and server import | 20:07 |
| jaosorior | but anyway, yeah, point is, it's better in the server | 20:07 |
| rm_work | redrobot: final vote | 20:08 |
| rm_work | redrobot: do you want to keep it in the client or not | 20:08 |
| redrobot | #nopressure | 20:09 |
| rm_work | lol k i'm removing it | 20:09 |
| redrobot | yeah, I think it would be better without it | 20:11 |
| rm_work | jaosorior: changing from [] to () apparently breaks it in py33 | 20:11 |
| rm_work | so I am keeping [] | 20:11 |
| jaosorior | ok | 20:12 |
| openstackgerrit | Adam Harwell proposed a change to openstack/python-barbicanclient: Refactor client models in python-barbicanclient https://review.openstack.org/115080 | 20:12 |
| rm_work | kk | 20:12 |
| rm_work | everyone go +2 ;P | 20:12 |
| rm_work | brb | 20:12 |
| jaosorior | I will -1 it just for the lolz | 20:13 |
| jaosorior | I'm kidding, good work dude :D | 20:16 |
| *** lisaclark1 has joined #openstack-barbican | 20:16 | |
| *** lisaclark1 has quit IRC | 20:21 | |
| *** lisaclark1 has joined #openstack-barbican | 20:24 | |
| *** lisaclark1 has quit IRC | 20:25 | |
| *** paul_glass has quit IRC | 20:26 | |
| *** lisaclark1 has joined #openstack-barbican | 20:27 | |
| *** gyee has joined #openstack-barbican | 20:40 | |
| rm_work | missing that reaperhulk +2 from earlier :P | 20:50 |
| woodster_ | rm_work: I think he's kiting right about now | 20:54 |
| woodster_ | rm_work: redrobot had to leave, but might be on later | 20:54 |
| rm_work | heh np no REAL hurry | 20:54 |
| rm_work | I know code gets better with age, like a good scotch :) | 20:55 |
| redrobot | woodster_ rm_work I'm here | 20:57 |
| redrobot | had to pick up my glasses earlier | 20:57 |
| rm_work | man, i need to get new glasses really badly | 20:57 |
| rm_work | haven't worn mine in over a year and i'm starting to feel it | 20:57 |
| redrobot | always feels a little weird getting a new perscription.. | 20:57 |
| rm_work | eyes get a bit stressed | 20:57 |
| rm_work | (it's a pretty minor prescription, but I do have to lean in to my monitors a bit, and can't use higher than 1080p on my Retina display) | 20:58 |
| rm_work | hockeynut: apparently list comprehensions are hard to comprehend, even I missed the second one you missed in that containers review :P | 20:59 |
| rm_work | and I wrote it! :P | 20:59 |
| hockeynut | comprehentions are, by defintion, incomprehensible :-) | 20:59 |
| rm_work | i really like them <_< | 20:59 |
| hockeynut | you need to get out more :-) | 21:01 |
| *** lisaclark1 has quit IRC | 21:01 | |
| hockeynut | +1d it | 21:03 |
| *** lisaclark1 has joined #openstack-barbican | 21:03 | |
| rm_work | well, another patch or two coming anyway, but thanks :) | 21:03 |
| jvrbanac | rm_work, my rule of thumb, if they are too complex to understand quickly, then they aren't a good candidate for a list comp. | 21:05 |
| hockeynut | good point jvrbanac. | 21:08 |
| rm_work | jvrbanac: i think these are pretty simple, it's just remembering to look one line down to see if there's a variable in scope from the list-comp | 21:08 |
| rm_work | which is more clear in an editor I think, because it feels less cluttered to me | 21:09 |
| rm_work | than the gerrit review page | 21:09 |
| *** juantwo has quit IRC | 21:10 | |
| *** lisaclark1 has quit IRC | 21:11 | |
| *** lisaclark1 has joined #openstack-barbican | 21:12 | |
| *** kebray has joined #openstack-barbican | 21:14 | |
| rellerreller | Did anyone else know that Secrets do not have a type associated with them? | 21:15 |
| rellerreller | Does anyone else feel like they should? | 21:15 |
| woodster_ | a class/model type? | 21:16 |
| rellerreller | The Secret model does not have a type column. | 21:16 |
| *** lisaclark1 has quit IRC | 21:16 | |
| rellerreller | I feel like it should, so we can distinguish between symmetric, public, and private keys | 21:17 |
| rellerreller | I was reviewing atwari's CR 111412, and I noticed this | 21:17 |
| woodster_ | I think typed containers were supposed to help with that | 21:18 |
| woodster_ | but at the secret level, it was just considered to be data with metadata associated with it | 21:18 |
| rellerreller | Yes, I saw that. It looks like the "name" column will provide the type | 21:18 |
| rm_work | essentially, yes | 21:18 |
| rm_work | but yeah, the actual Secret is just... a generic Secret thing | 21:19 |
| rellerreller | I feel like if we add a type column to Secret then it can be public, private, symmetric, opaque or whatever else is in the SecretType enum | 21:19 |
| rellerreller | I think my concern is that you cannot iterate through the Secret table and tell what the type is of a secret | 21:20 |
| rellerreller | What if I wanted to return all of my public keys? Or symmetric keys? | 21:20 |
| woodster_ | the problem with adding a type though is that it implies that barbican should validate that the secret really is that type when it is stored | 21:21 |
| rellerreller | But it could also allow for richer policy and access control. We could have default policy that allows anyone to access a public key for example. If we do not have the type then a little more difficult. | 21:23 |
| rellerreller | So if a user stores a public key with us I guess they will have to follow that up with another call to share with everyone since we do not know the type. | 21:26 |
| alee | woodster_, ? | 21:26 |
| woodster_ | alee was discussing this a bit yesterday...he makes a case for a new type or metadata to handle some info, such as public secrets and intermediates...that aren't really secrets perse and thus don't really need to be placed in secure storage | 21:27 |
| alee | rellerreller, I think you're touching on some of the concerns I raised yesterday | 21:28 |
| woodster_ | alee: rellerreller is talking about maybe adding types to secrets | 21:28 |
| alee | yes - I think thats a definite possibility | 21:29 |
| woodster_ | I think those would be good to flesh out for K at the design summit | 21:29 |
| alee | woodster_, agreed | 21:29 |
| * rm_work wishes he was going to be at the design summit <_< | 21:29 | |
| alee | woodster_, have you had a chance to look at my cr? | 21:29 |
| rellerreller | woodster_ agreed | 21:29 |
| woodster_ | alee: looking at it now actually | 21:30 |
| alee | woodster_, cool - let me know if you have questions -- or if anything I do does not make sense. | 21:30 |
| alee | woodster_, but I've tried to identify some things that I think are needed to make this more complete -- | 21:31 |
| alee | the scheduling system, and a substatus | 21:31 |
| woodster_ | alee: adding more meat to the skeleton, good stuff | 21:31 |
| alee | woodster_, yeah - we'll got about half a body .. | 21:32 |
| alee | woodster_, kinda like the Mummy .. | 21:32 |
| woodster_ | alee: nicer analogy than calling it a zombie for sure | 21:32 |
| openstackgerrit | Donald Stufft proposed a change to openstack/barbican: Test the secret model using an in memory database https://review.openstack.org/117030 | 21:39 |
| *** atiwari has quit IRC | 21:48 | |
| *** kebray has quit IRC | 21:50 | |
| alee | woodster_, so does everything I do make sense? | 21:57 |
| *** rellerreller has quit IRC | 22:02 | |
| *** SheenaG11 has quit IRC | 22:04 | |
| *** SheenaG1 has joined #openstack-barbican | 22:18 | |
| *** SheenaG11 has joined #openstack-barbican | 22:19 | |
| *** SheenaG1 has quit IRC | 22:23 | |
| *** hockeynut has quit IRC | 22:37 | |
| *** openstackgerrit has quit IRC | 22:43 | |
| *** jaosorior has quit IRC | 22:52 | |
| *** SheenaG11 has quit IRC | 23:14 | |
| *** SheenaG1 has joined #openstack-barbican | 23:14 | |
| *** juantwo has joined #openstack-barbican | 23:15 | |
| *** juantwo has quit IRC | 23:21 | |
| *** juantwo has joined #openstack-barbican | 23:22 | |
| *** SheenaG1 has quit IRC | 23:27 | |
| *** bdpayne has quit IRC | 23:33 | |
| woodster_ | alee, rellerreller, jaosorior, chellygel: just make a lot of comments on your CR: https://review.openstack.org/#/c/116956 | 23:33 |
| *** bdpayne has joined #openstack-barbican | 23:34 | |
| *** akoneru has quit IRC | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!