Tuesday, 2014-08-26

openstackgerritSteve Martinelli proposed a change to openstack/barbican: Move to oslotest  https://review.openstack.org/11670000:24
hockeynutredrobot 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.gz00:59
hockeynutmakes me sad01:06
*** lisaclark1 has joined #openstack-barbican01:14
*** alee_dinner is now known as alee01:45
*** woodster_ has quit IRC02:15
*** bdpayne has joined #openstack-barbican02:20
*** ryanpetrello has quit IRC02:21
*** ryanpetrello has joined #openstack-barbican02:27
*** gyee has quit IRC02:47
*** juantwo has quit IRC03:12
*** alee has quit IRC04:06
*** lisaclark1 has quit IRC04:07
*** alee has joined #openstack-barbican04:19
*** kebray has quit IRC05:31
*** bdpayne has quit IRC05:50
*** bdpayne has joined #openstack-barbican05:54
*** Nirupama has joined #openstack-barbican06:08
*** bdpayne has quit IRC06:59
*** jamielennox is now known as jamielennox|away08:03
*** Nirupama has quit IRC08:13
*** tkelsey has joined #openstack-barbican09:37
tkelseyhello Barbican people, anyone know if somthing has changed recently that would make the quick start curl examples fail?09:38
tkelseythe ones from here: https://github.com/cloudkeep/barbican/wiki/Barbican-Quick-Start-Guide09:39
tkelseyrunning them used to work but now just barfs up a 400 :-(09:39
*** denis_makogon has joined #openstack-barbican11:13
*** juantwo has joined #openstack-barbican12:10
*** juantwo has quit IRC12:12
*** juantwo has joined #openstack-barbican12:12
*** SheenaG1 has joined #openstack-barbican12:30
openstackgerritTim Kelsey proposed a change to openstack/barbican: Adding a plugin to interact with HP Atalla ESKM  https://review.openstack.org/11687812:30
*** jaosorior has joined #openstack-barbican12:33
*** SheenaG11 has joined #openstack-barbican12:37
*** SheenaG1 has quit IRC12:39
openstackgerritTim Kelsey proposed a change to openstack/barbican: Adding a plugin to interact with HP Atalla ESKM  https://review.openstack.org/11687812:39
*** denis_makogon has quit IRC12:41
openstackgerritTim Kelsey proposed a change to openstack/barbican: Adding a plugin to interact with HP Atalla ESKM  https://review.openstack.org/11687812:42
*** sld has quit IRC13:08
*** nkinder has quit IRC13:18
*** lisaclark1 has joined #openstack-barbican13:19
*** akoneru_ has joined #openstack-barbican13:37
*** paul_glass has joined #openstack-barbican13:45
*** lisaclark1 has quit IRC13:52
*** lisaclark1 has joined #openstack-barbican13:53
*** denis_makogon has joined #openstack-barbican13:57
*** denis_makogon has quit IRC13:57
*** SheenaG11 has quit IRC14:01
*** akoneru_ has quit IRC14:06
*** SheenaG1 has joined #openstack-barbican14:11
*** nkinder has joined #openstack-barbican14:12
*** SheenaG11 has joined #openstack-barbican14:12
*** SheenaG1 has quit IRC14:15
*** atiwari has joined #openstack-barbican14:17
*** akoneru_ has joined #openstack-barbican14:21
*** lisaclark1 has quit IRC14:24
*** woodster_ has joined #openstack-barbican14:31
*** akoneru_ has quit IRC14:33
*** lisaclark1 has joined #openstack-barbican14:34
openstackgerritTim Kelsey proposed a change to openstack/barbican: Adding a plugin to interact with HP Atalla ESKM  https://review.openstack.org/11687814:36
*** denis_makogon has joined #openstack-barbican14:41
*** kebray has joined #openstack-barbican14:45
*** kebray has quit IRC14:46
*** kebray has joined #openstack-barbican14:46
hockeynuthi tkelsey - we've recently removed tenant ID from the URLs - seems that the wiki needs to catch up.14:52
hockeynutremove those tenant IDs and you should be ok14:52
tkelseythanks hockeynut, I have it working now, need to add X-Project-Id header as well14:53
hockeynutcoolness14:53
tkelseyanyone know why this change was not done as api v2? could have maintained compatibility for anyone using v1 that way14:54
jaosoriorhello people15:00
*** kebray has quit IRC15:02
*** rellerreller has joined #openstack-barbican15:03
chellygelhey jaosorior!15:16
chellygelwelcome back! how was vacation?15:16
jaosoriorwell, I'm sunburned, exhausted and stinky15:18
jaosoriorit was awesome! :P15:18
jaosorior8 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 business15:19
chellygelwhoa, thats intense15:20
*** kebray has joined #openstack-barbican15:21
jaosoriorhow's it going over there?15:22
chellygelso far so good, if you ask me :)15:22
jaosoriorexcellent :D15:26
*** akoneru has joined #openstack-barbican15:29
woodster_jaosorior: welcome back!15:32
jaosoriorwoodster_: Thanks Mr.!15:34
redrobottkelsey 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
redrobottkelsey 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
redrobotjaosorior welcome back, guey!15:50
tkelseyredrobot: that makes sense, good to know thanks15:50
jaosoriorredrobot: gracias wei :D15:51
tkelseyredrobot: worth noting that some projects are starting the adopt Barbican now, e.g. https://review.openstack.org/#/c/104339/15:53
jaosoriorredrobot, 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
redrobotjaosorior actually, yes.  rm_work has been doing a lot of work on the client.15:55
redrobotjaosorior I'd like your thoughts on http://specs.openstack.org/openstack/barbican-specs/specs/juno/client-refactor-models.html when you get a chance15:56
redrobotjaosorior rm_work has some CRs implementing that BP up for review15:56
redrobottkelsey noted.  thanks for the heads up15:56
tkelseyredrobot: no problem, the client work sounds good15:57
jaosoriorredrobot: 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 stuff15:58
jaosoriorThough first I should fix the issue of the lack of cold beer in my apartment...15:58
*** gyee has joined #openstack-barbican16:05
rm_workjaosorior: Barcelona is one of my favorite world cities :)16:09
rm_workjaosorior: 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 signatures16:09
jaosoriorexcellent16:10
jaosoriorrm_work: Barcelona is damn awesome!16:10
jaosoriorbut anyway16:10
jaosoriorrm_work: most likely tomorrow I will be able to give feedback on your stuff16:10
rm_workjaosorior: ok. I am here tomorrow and then I fly tomorrow night to Seattle for PAX :)16:11
rm_workafter which I'll be back on... the next Tuesday I think16:11
rm_workI 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
jaosoriorI can try to review them today16:12
rm_workfortunately the client isn't subject to J3 freeze16:12
*** bdpayne has joined #openstack-barbican16:12
jaosoriorjust need to get my beer issue sorted out, and then I'm ready to read :P16:12
rm_workso I don't think it's a huge deal16:12
rm_workheh kk16:12
jaosoriorredrobot, rm_work: why does the secrets and orders need to have different names for persisting the object? (store and submit)16:14
rm_workjaosorior: i bitched about that, you're going to have to take it up with redrobot16:15
rm_workI preferred having it be consistent16:15
rm_workI thought .save() on everything would be good16:15
jaosoriorredrobot: I think we even talked about having a consistent name when we discussed some of the refactoring stuff on the mid-cycle meetup16:15
rm_workjaosorior: that is an easy fix though if we decide to do that :()16:16
rm_work* :)16:16
jaosoriorredrobot: is the etherpad of the discussion around somewhere?16:16
jaosoriorAnd, 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 IRC16:18
rm_work?16:18
rm_workdefine lazy initialization?16:18
rm_workI don't lazy-load the basic data on stuff, but i do lazy-load secret payload or any sub-objects16:19
jaosorioroh, alright, well, it's more or less that; what I meant16:20
*** lisaclark1 has joined #openstack-barbican16:24
rm_workalright, refactor done16:25
rm_workcheck out the review that's about to come up16:25
rm_workoh, question16:25
rm_workon the setter for bit_length on an order, I'm doing some validation:16:26
rm_workif 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_workshould I just... not, and leave validation to the server on a .store() ?16:26
jaosoriorI'm actually reviewing this one at the moment: https://review.openstack.org/#/c/11508016:26
rm_workyeah that's it16:26
rm_worki'm JUST NOW submitting a patch16:26
jaosoriorok, I'll leave my comments there, and review the newer patch16:27
jaosoriorhaha, well, one comment :P16:27
rm_workwell, I guess I could wait until you comment?16:27
rm_workcan you tell me what it is and I'll just fix whatever it is in this patch? :P16:28
jaosorioranyway, I didn't finish reviewing16:28
rm_workheh16:28
rm_workalright16:28
rm_worksubmitting16:28
jaosoriorI'll read what you upload next16:28
openstackgerritAdam Harwell proposed a change to openstack/python-barbicanclient: Refactor client models in python-barbicanclient  https://review.openstack.org/11508016:28
woodster_can I get a review of this CR?: https://review.openstack.org/#/c/115715/16:28
rm_workjust changed the factory methods16:28
jaosoriorwoodster_: sure, but now I'm serious about the beer thing haha, off to the store now :P16:29
rm_worklol16:29
woodster_nice!16:31
aleewoodster_, ping16:34
woodster_alee: hello16:34
aleewoodster_, hey -- I have a WIP patch that rests on top of the two patches you already have out there.16:35
aleewoodster_, it puts in the processing for once you recieve a cert16:35
woodster_alee: oh the web we weave! :)16:35
aleeand also a start at the processing when the ca is not avilable16:36
woodster_alee: excellent! Just need some reviewers16:36
aleeand when return waiting_for_ca16:36
rm_workI 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 orders16:37
aleeI say a start becauase it basically identfies what object, method, args, time  need to be retried16:37
aleeok good16:37
aleebut doesn't have the actual scheduler code16:37
*** kebray has quit IRC16:37
aleethats something that needs to be added16:37
aleeanyways - 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
aleeand 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
aleewoodster_, I just identified what needs to be in it16:41
*** nkinder has quit IRC16:41
aleewoodster_, I'll ping you once its up16:42
redrobotjaosorior 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
redrobotI 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_workredrobot: uhh, would the CLI need to change to match the API (the API of the client code, I mean)?16:47
* redrobot shrugs16:47
rm_workI don't see why it necessarily has to16:47
redrobotrm_work depends on how much "consistency" we want ;)16:47
rm_workI vote CLI uses the verbs you want16:47
woodster_redrobot, jaosorior: secret store or save seems ok to me. Order submit is better to me.16:47
rm_workand the client-API just uses "save()"16:47
aleewoodster_, ok16:48
woodster_so add the dashes in there, like secret-save? :)16:48
* redrobot does not like dashes16:48
woodster_but other projects are using it! I don't like it either though16:49
redrobotwe should look to see what the unified CLI is doing16:50
aleewoodster_, ping16:56
aleewoodster_, I'm trying to submit my patch but its not working because its trying to submit your patch too.16:57
aleeand that patch hasn't changed16:58
aleedoes that make sense?16:58
jaosoriorwoodster_: openstackclient doesn't use the dash notation, many other projects do, but I'm hoping the unified client will gain more traction :O16: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 IRC17:01
aleewoodster_, no - I got your rebased copy17:01
aleewoodster_, the problem is that gerrit is trying to send both your and my cr in at the same time17:02
aleewoodster_, as I have not changed yours, gerrit rejects it17:02
aleewoodster_,  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
reaperhulkis that other commit in another CR? It should allow you to submit that and it will show up as a dependency in gerrit17: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
aleewoodster_, right - thats the other option17:05
aleewoodster_, reaperhulk interesting how gerrit allows (or wants to allow) me to modify uyour cr17:06
aleereaperhulk, so woodster_ has a cr thats in review17:06
aleereaperhulk, I have a cr that goes on top of that17:06
aleeI want to post my cr for review, but woodster's cr is not yet merged17:07
aleeso git review wants to submit both crs17:07
alee(woodsters and mine)17:07
aleeand right now is choking because woodsters cr has not been changed17:08
reaperhulkthat...shouldn't matter.17:08
*** lisaclark1 has quit IRC17:08
aleereaperhulk, :)17:08
redrobotalee there's a way to mark your commmit as dependent on woodster's17:08
reaperhulkthe existence of an identical commit is what gerrit uses as a key to know it's a dependency17:09
reaperhulkor at least that's how it worked a few months ago, haha17:09
redrobotalee have you tried https://wiki.openstack.org/wiki/Gerrit_Workflow#Add_dependency17:09
reaperhulkgit review -R maybe? rm_work has done this for several recent CRs so he may know as well17:09
aleeok -- 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-workflows17:10
woodster_I think rm_work uses this flow: https://wiki.openstack.org/wiki/Gerrit_Workflow#Rebase_On_Dependent17:11
rm_workyes so17:12
rm_workeasiest way is:17:12
rm_workget your commit hash17:12
woodster_rm_work: ^^^^17:12
rm_workgit review -d <ID of dependent>17:12
woodster_rm_work: sorry, trying to multitask, didn't see your response17:12
rm_workgit cherry-pick <your commit hash>17:12
rm_workgit review17:12
rm_work:)17:12
rm_workso like17:13
rm_workgit review -d 11339317:13
rm_workwould pull down https://review.openstack.org/#/c/113393/517:13
rm_workthen git cherry-pick 7462e1f3bf07b40455dd9e304ef4add988a6b4cf17:13
rm_workwould put your commit on top17:13
rm_workand then git review and you're set17:13
*** rellerreller has joined #openstack-barbican17:13
rm_workbe 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_workalee: ^^17:14
reaperhulkshouldn't you branch after the -d?17:14
rm_workno17:14
rm_workit doesn't matter at all17:14
rm_workthe local branch stuff is completely ignored by gerrit17:14
rm_workand then next time you do "git review -d <ID>" it'll overwrite it anyway17:15
rm_workit rebuilds the local branch every time17:15
reaperhulkthat annoys me.17:15
rm_workheh17:15
reaperhulkbut makes sense, thanks rm_work17:15
rm_workgerrit is wonky. live within its rules OR SUFFER17: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_workerr17:15
rm_workjust start over from the beginning, yes17:16
rm_workany time the dependent commit changes, just git review -d it and cherry-pick your hash again17:16
openstackgerritAde Lee proposed a change to openstack/barbican: Additional work on certificate processing  https://review.openstack.org/11695617:16
rm_workwhen 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 you17:16
aleehey - it worked :)17:16
reaperhulkwoo, dependency!17:16
woodster_probably best to commit local changes, get the new commit ID, and then cherry pick I'd think17:17
rm_workyeah we have HUGE dependency chains in Neutron, so I've gotten quite proficient with this process :)17:17
rm_workwoodster_: yes17:17
rm_workwell17:17
aleethanks all!17:17
rm_workessentially >_> you get used to it17:17
aleewoodster_, so its up there for for you to take a look at ..17:17
rm_workwoodster_: I go back and forth locally on my own dep chains a lot too17:17
rm_workjust keep track of which hashes are your latest and it's fine :)17:18
reaperhulknow to review https://review.openstack.org/#/c/115715/ so we can review alee's work ;)17:18
aleereaperhulk, woodster_ like woodster's cr , still wip17:19
aleebut gives you an idea as to the direction17:19
reaperhulkah, I see you gave it the workflow tag17:19
aleereaperhulk, yeah - before anyone pings me about failing tests17:20
aleeor lack of additional tests17:20
aleethey're coming - I just want to make sure what I'm doing is sane17:21
openstackgerritAdam Harwell proposed a change to openstack/python-barbicanclient: Add Containers to python-barbicanclient  https://review.openstack.org/11339317:22
rm_workstill need tests but otherwise that CR is also ready for review jaosorior17:22
redrobotwoodster_ 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
openstackgerritJohn Wood proposed a change to openstack/barbican: Initial connect orders resource to certificate processing  https://review.openstack.org/11571517:37
woodster_ugh, some rebase glitch on this CR: https://review.openstack.org/#/c/11571517:38
woodster_reaperhulk: ^^^^ Thanks for pointing out the missing code17:38
reaperhulknp17:38
jaosoriorwoodster_: https://review.openstack.org/#/c/115715/4/barbican/tasks/certificate_resources.py line 6617:41
reaperhulkwoodster_: so is it possible to exercise that code via unit test or is this a models issue?17:41
jaosoriorwoodster_: 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 before17:48
*** tkelsey has quit IRC17: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,cm17:49
reaperhulkah, cool17:50
reaperhulkwell, I'll give this a +2 now then17:50
woodster_jaosorior: that's correct. Both types of orders POSTS are supported.17:50
jaosoriorand eventually the meta approach will only be used, right?17:51
*** paul_glass has quit IRC17:51
woodster_that's correct17:53
jaosorioralright, then I guess your CR covers what it intends to cover17:54
jaosorior-1'd it for VERY minor things though (sorry)17:54
reaperhulkthose look like changes worth making to me17:56
jaosoriorBy the way, I intend to rename the URI bit from the clit, in favor of ref, do people dig the idea?17:58
jaosoriorseveral 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 idea18:03
*** bdpayne has quit IRC18:04
*** nkinder has joined #openstack-barbican18:04
*** bdpayne has joined #openstack-barbican18:04
*** akoneru is now known as akoneru_lunch18:24
*** tkelsey has joined #openstack-barbican18:39
*** paul_glass has joined #openstack-barbican18:40
*** lisaclark1 has joined #openstack-barbican18:42
openstackgerritArun Kant proposed a change to openstack/barbican: Adding keystone notification listener support  https://review.openstack.org/11081718:42
*** tkelsey has quit IRC18:44
openstackgerritJohn Wood proposed a change to openstack/barbican: Initial connect orders resource to certificate processing  https://review.openstack.org/11571518:47
*** kebray has joined #openstack-barbican18:51
woodster_jaosorior: ^^^^ that should address your concerns.18:55
*** lisaclark1 has quit IRC18:57
aleewoodster_, had  chance to look at my CR yet?18:59
redrobotjaosorior refactor the clit... >_>19:03
*** rellerreller has quit IRC19:09
redrobotmy new glasses are pretty spiffy! :D19:19
jaosorior* cli19:19
rm_worklol yes I caught that too :P19:20
rm_workwoodster_ / reaperhulk: so you guys are cool with the main client refactor CR?19:21
rm_workguessing so since you both +2'd it :P19:21
reaperhulkpretty much.19:21
rm_workkk19:23
rm_workwaiting to hear what jaosorior thinks19:23
rm_workjaosorior: https://review.openstack.org/#/c/115080/19:23
*** akoneru_lunch is now known as akoneru19:24
jaosoriorrm_work, well, it seems good mostly19:27
jaosoriorthough I just think that here https://review.openstack.org/#/c/115080/8/barbicanclient/base.py line 2119:28
jaosorioryou could use a parentheses (generator) instead of creating a list of objects19:28
jaosoriorit would be a little performance improvement19:29
jaosorioroh, wait, I had forgotten about one function in your code, I'll add the comments there19:30
jaosoriorby the way, is there a reason why the refs we use are full URLs and not just the uuids?19:32
*** kebray has quit IRC19:34
rm_workjaosorior: umm.. yes? because we're supposed to be using full HATEOAS refs everywhere19:35
rm_workI actually had to push a patch to containers just last week to fix one place where it was giving back IDs instead of full refs19:35
rm_workjaosorior: ha, line 21 there is code woodster_ copy/pasted to me and told me to use :P19:36
jaosorioruhm, yeah, but you could kind of assume most part of the URI and construct it where needed19:36
rm_workjaosorior: not necessarioly19:36
rm_work*necessarily19:36
rm_worksupposedly you could interlink Barbican repositories19:37
rm_worki think maybe that was a future plan?19:37
rm_workbut it came up in talks I had with redrobot19:37
rm_workand full URIs are used pretty much everywhere anyway19:37
jaosorioryeah, they are19:37
redrobotjaosorior full hrefs are preffered.19:38
jaosoriorcan you elaborate?19:38
redrobotthe href fully describes the location of the object19:38
rm_workjaosorior: on the other function you commented on, I am not even 100% sure I should be doing the validation at all19:38
rm_workwhat do you think?19:39
redrobotif you had data in two different data centers for example,19:39
redrobotthe hosts may be different19:39
redrobotin which case, you wouldn't be able to know which is the right host for a particualr uuid19:39
redrobotat least, that was my understanding of it19:39
jaosorioruhm, aren't you putting anyway the url of barbican as a parameter?19:40
*** gyee has quit IRC19:40
redrobotnot sure if you can have a container that has secrets across environments?19:40
jaosoriorI guess it kind of makes sense if you assume barbican could be federated19:40
redrobotjaosorior that's a good point.19:40
rm_workredrobot: it might work, as long as the auth is the same19:40
jaosoriorbut then why give the url of barbican at all?19:40
rm_worksince 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 URI19:41
redrobotI don't have a good answer for that...19:41
rm_work^^\19:41
rm_workwhat I just said, is why19:41
rm_workyou need a starting point19:41
rm_workbut from there, the resources could live in other repos19:41
rm_workspecifically it is an issue for containers19:41
redrobotI think that ideally we should be getting the url from keystone's catalog19:41
rm_workmaybe not as much for pure secrets19:41
jaosoriorrm_work, what about the project_id?19:41
rm_workI guess we have to assume that we're talking about different DCs within the same system, so project-id would be the same19:42
jaosoriorredrobot: that19:42
rm_worklike I have some secrets in ORD and DFW, and put them in a container in IA19:42
rm_work*IAD19:42
rm_workproject-id and auth would be the same19:42
rm_workwell actually... would auth-tokens be the same across DCs? I don't remember if they're shared across DCs or not19:43
redrobotrm_work yep... but not LON... :-\19:43
rm_workI *think* they are?19:43
rm_worklol yes LON19:43
rm_workLON is the red-headed stepchild of RAX19:43
rm_workI still don't understand why it's set up that way T_T19:43
rm_workEU law?19:43
* redrobot shrugs19:44
redrobotthere was a patch in flight that would add catalog data to the keystone session19:44
jaosoriorrm_work19:45
redrobotif it's landed we could refactor that now19:45
jaosoriorI think you should remove the bit_length validation19:45
jaosoriorit wasn't there before, and I think there is no actual constraint about the bits needing to form full bytes19:46
rm_workk19:46
rm_workit says so in the API docs, but heh19:46
rm_workyeah19:46
jaosoriorit says so?19:46
jaosoriorreaperhulk could help with this, maybe19:47
reaperhulkoptimistic19:47
reaperhulkwhat's up19:47
reaperhulkbits do not need to form full bytes that is correct, although storing them is somewhat tricky without doing so :D19:48
rm_workhttps://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface#orders-resource19:48
rm_workerr, i think it was in there somewhere19:48
rm_worklooking for it again19:48
reaperhulkPresumably anything generating non-byte aligned keys would know how to strip the padded bits though19:48
rm_workValues 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_workand "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_workis that incorrect?19:49
jaosoriorrm_work: props to your memory19:49
rm_workbut my real question was whether I should do the validation myself in the client or pass the responsibility down the chain to the server19:50
rm_workthough I guess "is this actually a requirement at all" is now a thing19:50
rm_workthe docs could be wrong -- they have been wrong before :P19:50
jaosoriorI would say server19:50
jaosoriornot the most optimal thing, but it would make things consistent19:51
redrobotI would argue client, since we could save users a trip to the server if we know it's going to fail19:51
rm_workredrobot: 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 decisions19:51
rm_workso we don't make a wrong choice in the client, or have to maintain separate validation rules in the client19:52
rm_workIE, rules change on the server -> have to update the client in parallel19:52
jaosoriorwell, 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 want19:52
rm_workI guess I am ok with just leaving both and going as-is19:53
jaosoriorpeople are going to start debugging with curl and will not get appropriate responses from the server if it doesn't have these validations19:53
rm_workyeah the server *should* already do this19:53
rm_workthough technically it still has nothing to do with this CR even if it doesn't19:53
jaosoriorindeed19:53
redrobotjaosorior validation happens on the server, and there's work being done to defer validation to the plugin19:53
jaosoriorcool19:53
rm_workjaosorior: would you mind removing your -1 if it were to stay as-is?19:53
jaosoriorbut now the question remains19:53
jaosoriorshould there be that validation at all??19:54
rm_workah, right19:54
rm_workis that validation correct19:54
rm_workor is it completely unnecessary19:54
rm_workreaperhulk is my best bet on answering that I think?19:54
redrobotthere's a todo for changing bit length to byte length somehwere...19:54
rm_workheh19:55
rm_workwell, at that point this needs a refactor anyway19:55
reaperhulksorry, 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_workso the check could be removed then19:55
jaosoriorredrobot: I thought someone had said that bit_length should be kept X_x19:55
reaperhulkredrobot: we should remove that todo19:55
reaperhulkyeah we're not gonna make that transition19:55
rm_workreaperhulk: 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_workonly for orders19:55
rm_workand the code in question is only on orders19:55
reaperhulkOh okay19:55
reaperhulkI 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 practical19:56
rm_workk19:56
rm_workthen jaosorior, are we good on this CR?19:56
rm_workI don't think the [] -> () change is really meaningful :/19:56
jaosoriorwell, basically my only comments left on your CR are nits, address them if you want19:56
jaosoriorand the readability of that validation thing19:56
rm_workwe're talking about a function that is used once per save, and is on a list of max size like, 1019:56
redrobotI do like the idea of having a generator19:57
*** rellerreller has joined #openstack-barbican19:57
rm_work>_<19:57
rm_workdamnit redrobot19:57
redrobotesp, if we're fetcthing every time19:57
redrobotsorry, haven't looked at the code...19:58
rm_workwait, which are you talking about19:58
* redrobot looks19:58
jaosoriorlol19:58
rm_workpublished my responses19:58
rm_workwhich are essentially what I said here, just on the code for posterity19:58
jaosoriorrm_work: cool20:00
jaosorioranyway, I could take the -1 off, it really is not a big deal20:00
rm_workI think I vote for that20:00
rm_workjust go through as-is20:01
jaosorioryeah, 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 messy20:01
jaosoriorthis is only one instance, but what if we decide to validate other parameters to optimize20:02
jaosoriorSo I would rather get rid of that validation and let the server deal with it20:02
rm_workthat was what I mentioned earlier20:05
rm_workwe'd be in a state of having to maintain two sets of validation code20:06
rm_workand keeping it synced20:06
jaosorioror we would end up with a validation library or something like this that both client and server import20:07
jaosoriorbut anyway, yeah, point is, it's better in the server20:07
rm_workredrobot: final vote20:08
rm_workredrobot: do you want to keep it in the client or not20:08
redrobot#nopressure20:09
rm_worklol k i'm removing it20:09
redrobotyeah, I think it would be better without it20:11
rm_workjaosorior: changing from [] to () apparently breaks it in py3320:11
rm_workso I am keeping []20:11
jaosoriorok20:12
openstackgerritAdam Harwell proposed a change to openstack/python-barbicanclient: Refactor client models in python-barbicanclient  https://review.openstack.org/11508020:12
rm_workkk20:12
rm_workeveryone go +2 ;P20:12
rm_workbrb20:12
jaosoriorI will -1 it just for the lolz20:13
jaosoriorI'm kidding, good work dude :D20:16
*** lisaclark1 has joined #openstack-barbican20:16
*** lisaclark1 has quit IRC20:21
*** lisaclark1 has joined #openstack-barbican20:24
*** lisaclark1 has quit IRC20:25
*** paul_glass has quit IRC20:26
*** lisaclark1 has joined #openstack-barbican20:27
*** gyee has joined #openstack-barbican20:40
rm_workmissing that reaperhulk +2 from earlier :P20:50
woodster_rm_work: I think he's kiting right about now20:54
woodster_rm_work: redrobot had to leave, but might be on later20:54
rm_workheh np no REAL hurry20:54
rm_workI know code gets better with age, like a good scotch :)20:55
redrobotwoodster_ rm_work  I'm here20:57
redrobothad to pick up my glasses earlier20:57
rm_workman, i need to get new glasses really badly20:57
rm_workhaven't worn mine in over a year and i'm starting to feel it20:57
redrobotalways feels a little weird getting a new perscription..20:57
rm_workeyes get a bit stressed20: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_workhockeynut: apparently list comprehensions are hard to comprehend, even I missed the second one you missed in that containers review :P20:59
rm_workand I wrote it! :P20:59
hockeynutcomprehentions are, by defintion, incomprehensible :-)20:59
rm_worki really like them <_<20:59
hockeynutyou need to get out more :-)21:01
*** lisaclark1 has quit IRC21:01
hockeynut+1d it21:03
*** lisaclark1 has joined #openstack-barbican21:03
rm_workwell, another patch or two coming anyway, but thanks :)21:03
jvrbanacrm_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
hockeynutgood point jvrbanac.21:08
rm_workjvrbanac: 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-comp21:08
rm_workwhich is more clear in an editor I think, because it feels less cluttered to me21:09
rm_workthan the gerrit review page21:09
*** juantwo has quit IRC21:10
*** lisaclark1 has quit IRC21:11
*** lisaclark1 has joined #openstack-barbican21:12
*** kebray has joined #openstack-barbican21:14
rellerrellerDid anyone else know that Secrets do not have a type associated with them?21:15
rellerrellerDoes anyone else feel like they should?21:15
woodster_a class/model type?21:16
rellerrellerThe Secret model does not have a type column.21:16
*** lisaclark1 has quit IRC21:16
rellerrellerI feel like it should, so we can distinguish between symmetric, public, and private keys21:17
rellerrellerI was reviewing atwari's CR 111412, and I noticed this21:17
woodster_I think typed containers were supposed to help with that21:18
woodster_but at the secret level, it was just considered to be data with metadata associated with it21:18
rellerrellerYes, I saw that. It looks like the "name" column will provide the type21:18
rm_workessentially, yes21:18
rm_workbut yeah, the actual Secret is just... a generic Secret thing21:19
rellerrellerI 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 enum21:19
rellerrellerI think my concern is that you cannot iterate through the Secret table and tell what the type is of a secret21:20
rellerrellerWhat 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 stored21:21
rellerrellerBut 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
rellerrellerSo 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
aleewoodster_, ?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 storage21:27
aleerellerreller, I think you're touching on some of the concerns I raised yesterday21:28
woodster_alee: rellerreller is talking about maybe adding types to secrets21:28
aleeyes - I think thats a definite possibility21:29
woodster_I think those would be good to flesh out for K at the design summit21:29
aleewoodster_, agreed21:29
* rm_work wishes he was going to be at the design summit <_<21:29
aleewoodster_, have you had a chance to look at my cr?21:29
rellerrellerwoodster_ agreed21:29
woodster_alee: looking at it now actually21:30
aleewoodster_, cool - let me know if you have questions -- or if anything I do does not make sense.21:30
aleewoodster_, but I've tried to identify some things that I think are needed to make this more complete --21:31
aleethe scheduling system, and  a substatus21:31
woodster_alee: adding more meat to the skeleton, good stuff21:31
aleewoodster_, yeah - we'll got about half a body ..21:32
aleewoodster_, kinda like the Mummy ..21:32
woodster_alee: nicer analogy than calling it a zombie for sure21:32
openstackgerritDonald Stufft proposed a change to openstack/barbican: Test the secret model using an in memory database  https://review.openstack.org/11703021:39
*** atiwari has quit IRC21:48
*** kebray has quit IRC21:50
aleewoodster_, so does everything I do make sense?21:57
*** rellerreller has quit IRC22:02
*** SheenaG11 has quit IRC22:04
*** SheenaG1 has joined #openstack-barbican22:18
*** SheenaG11 has joined #openstack-barbican22:19
*** SheenaG1 has quit IRC22:23
*** hockeynut has quit IRC22:37
*** openstackgerrit has quit IRC22:43
*** jaosorior has quit IRC22:52
*** SheenaG11 has quit IRC23:14
*** SheenaG1 has joined #openstack-barbican23:14
*** juantwo has joined #openstack-barbican23:15
*** juantwo has quit IRC23:21
*** juantwo has joined #openstack-barbican23:22
*** SheenaG1 has quit IRC23:27
*** bdpayne has quit IRC23:33
woodster_alee, rellerreller, jaosorior, chellygel: just make a lot of comments on your CR: https://review.openstack.org/#/c/11695623:33
*** bdpayne has joined #openstack-barbican23:34
*** akoneru has quit IRC23:59

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