Monday, 2015-09-21

*** vivek-ebay has quit IRC00:06
*** vivek-ebay has joined #openstack-barbican00:20
*** su_zhang has quit IRC00:40
*** vivek-ebay has quit IRC00:42
*** chlong has joined #openstack-barbican00:42
*** zz_dimtruck is now known as dimtruck01:20
*** dimtruck is now known as zz_dimtruck01:21
*** zz_dimtruck is now known as dimtruck01:22
*** vivek-ebay has joined #openstack-barbican01:43
*** dimtruck is now known as zz_dimtruck01:45
*** vivek-ebay has quit IRC01:47
*** su_zhang has joined #openstack-barbican02:06
*** kebray has joined #openstack-barbican02:19
*** mragupat has joined #openstack-barbican02:34
*** mragupat_ has joined #openstack-barbican02:35
*** mragupat has quit IRC02:39
*** everjeje has quit IRC02:42
*** vivek-ebay has joined #openstack-barbican02:52
*** mragupat_ has quit IRC02:56
*** su_zhang has quit IRC03:05
*** vivek-ebay has quit IRC03:10
*** vivek-ebay has joined #openstack-barbican03:28
*** vivek-eb_ has joined #openstack-barbican03:33
*** vivek-ebay has quit IRC03:34
*** su_zhang has joined #openstack-barbican04:11
*** vivek-eb_ has quit IRC04:32
*** vivek-ebay has joined #openstack-barbican04:32
openstackgerritJohn Wood proposed openstack/barbican: Add missing X-xxxx HTTP headers to the unauth context
*** Nirupama has joined #openstack-barbican04:42
*** vivek-eb_ has joined #openstack-barbican05:11
*** vivek-ebay has quit IRC05:11
*** vivek-eb_ has quit IRC05:37
*** edtubill has joined #openstack-barbican05:54
*** kebray has quit IRC06:11
*** edtubill has quit IRC06:38
*** shohel has joined #openstack-barbican06:46
*** su_zhang has quit IRC06:48
*** jamielennox is now known as jamielennox|away07:09
*** chlong has quit IRC07:17
rm_workBTW just merged so let me know if anyone sees gate issues07:38
rm_workredrobot: ^^07:38
*** tkelsey has joined #openstack-barbican07:57
*** su_zhang has joined #openstack-barbican08:06
*** su_zhang has quit IRC08:10
*** shohel has quit IRC08:16
*** shohel has joined #openstack-barbican08:18
*** jaosorior has joined #openstack-barbican08:30
*** chlong has joined #openstack-barbican08:44
*** darrenmoffat has quit IRC08:44
*** darrenmoffat has joined #openstack-barbican08:45
*** lisaclark has quit IRC08:53
*** lisaclark_ has quit IRC08:53
*** shohel has quit IRC08:55
*** shohel has joined #openstack-barbican08:56
*** tkelsey has quit IRC08:59
*** lisaclark has joined #openstack-barbican09:32
*** lisaclark_ has joined #openstack-barbican09:32
*** shohel has quit IRC09:34
*** shohel has joined #openstack-barbican09:34
*** jaosorior has quit IRC10:55
*** jaosorior has joined #openstack-barbican10:55
*** shohel has quit IRC11:04
*** shohel has joined #openstack-barbican11:04
*** shohel has quit IRC12:01
*** jaosorior has quit IRC12:02
*** shohel has joined #openstack-barbican12:02
*** jaosorior has joined #openstack-barbican12:02
zigoHi there!12:16
zigoIs Barbican working well with Falcon 3.0.0?12:16
zigoThe package maintainer of Mailman wishes me to upload version 3.0.0 to Debian (as Mailman 3 uses Falcon 3.0.0).12:17
zigoredrobot: ^12:17
*** haypo has joined #openstack-barbican12:26
openstackgerritVictor Stinner proposed openstack/barbican: py3: Fix python34 check job
haypohi! does anyone work on the python 3 support in Barbican?12:37
haypoi found a first change written by Pradeep Kumar Singh12:37
openstackgerritVictor Stinner proposed openstack/barbican: py3: Fix python34 check job
haypooh, there is a blueprint, cool. i linked my change to it:12:38
*** dave-mccowan has joined #openstack-barbican12:40
jaosoriorhaypo: There are a bunch of commits from Pradeep that are pending review. So the work is on-going12:44
haypojaosorior: cool12:45
jaosoriorhaypo: I'll try to poke people to see if we could get those to land soon.12:45
haypojaosorior: i propose a change to add a non-voting python34 check job,
haypojaosorior: later, we should make it voting to avoid python 3 regressions (if you are ok with that)12:46
jaosoriorBut, of course, if you can help out both reviewing and coding, it would be greatly appreciated12:47
jaosoriorhaypo: Anyway, if you come up with patches, feel free to ping me and I'll review. I'm pretty interested in that work12:50
jaosoriorhaypo: +1ed the gate job CR12:51
haypojaosorior: really? great :-) did you read ?12:51
jaosoriorhaypo: I haven't; checking it out12:51
jaosoriordave-mccowan: ping12:53
haypojaosorior: forget my change, please approve instead (it already has two +2)12:53
haypojaosorior: well, i don't know your status on the feature freeze. i don't know the barbican project at all :-) but it doesn't look to have stable branches yet12:54
dave-mccowanhaypo jaosorior i've looked through Pradeep's patches.  they look good and get us close to running with py3.  one problem, is most of our cores aren't familiar with py2/3 compatibility stuff.  if you're reviewing those, it would be great if you would add comments with pointers on why each change is done.  it would help us review and approve those.12:54
jaosoriorhaypo: Well, there is still some work we would like to get into this release.12:54
jaosoriordave-mccowan: Got a +1 for this one?
haypodave-mccowan: FYI i'm working on the wiki page since 1 or 2 years. it may answer to some of you questions, especially the "Common patterns" section12:55
dave-mccowanhaypro  good stuff.  i have it book marked and  i've been looking at that as I've reviewed the patches. :-)12:56
dave-mccowanjaosorior, haypo i think py3 should be the first thing we finish for Mitaki milestone1.  we already have too many moving parts for Liberty Release.12:59
haypoi will review pradeep patches, but later. right now, i'm checking the status of *each* openstack project12:59
haypodave-mccowan: no problem to wait for Mitaki milestone112:59
haypodave-mccowan: i know well the problem is making the code stable ;)13:00
haypomore change = more bugs13:00
haypoin th python3 wiki page, i see that python-barbicanclient  works on python3. cool :)13:02
haypoit's a good start13:02
aleedave-mccowan, ping13:03
aleedave-mccowan, morning - is waiting for you to +2 and +W it.13:04
dave-mccowanalee done.13:05
aleedave-mccowan, looking at your follow on patch now13:05
dave-mccowanalee, jaosorior: here's a list of patches to review:
jaosoriordave-mccowan: Thanks for the link. Will check em out13:07
aleedave-mccowan, thanks dave-mccowan - going through them13:17
openstackgerritDave McCowan proposed openstack/barbican: Combine exit codes of the two functional test runs
openstackgerritMerged openstack/barbican: Replace dict.iteritems() with dict.items()
*** woodster_ has joined #openstack-barbican13:33
*** kfarr has joined #openstack-barbican13:35
*** Nirupama has quit IRC13:40
woodster_alee, dave-mccowan , jaosorior : can you guys take a look at this tiny CR?:
openstackgerritMerged openstack/barbican: Fix ca related controllers
dave-mccowanwoodster_ I think to be complete you'll also need X-Role-Id13:46
dave-mccowanwoodster_ with a couple Liberty features, there is now a service-admin in addition to admin, with different permissions.13:47
jaosoriorwoodster_: Sure13:47
woodster_dave-mccowan: So we handle X-Role-Ids (plural) a few lines above the changes I put in...but is X-Role-Id different?13:48
aleedave-mccowan, reviewed the latest global ca patch13:48
woodster_dave-mccowan: as for the service-admin are you ok with that being a different CR than this one?13:49
jaosoriorwoodster_: I remember there were some functional tests for unauth context. Why not add some tests there?13:49
*** haypo has left #openstack-barbican13:50
aleedave-mccowan, I dont understand your question on line 30 in
dave-mccowanalee on Friday we talked about what GET /preferred/ should return.  A list, A ref, or an object.  We agreed on object, but i think we were wrong.  If a user has only the object, he has no good way to get the ref.  And, he might need the ref.13:52
woodster_jaosorior: I think unauth context functional tests would require their own gate (to not deploy keystone middleware)?13:52
*** su_zhang has joined #openstack-barbican13:53
jaosoriorwoodster_: true. Then we need that gate then.13:54
jaosoriorwoodster_: Do you know if many people are actually using the unauthed context? That is a blocker to start using the openstackCLI13:54
dave-mccowanwoodster_ nevermind on roles.  I see X-roles is already party of context.13:54
jaosoriorsince I haven't figured out how to inject headers with it13:55
aleedave-mccowan, when we return an object, do we ever return the ref as a location header?13:55
aleejaosorior, woodster_ ^^13:55
jaosorioralee: Which part of the code are you referring to?13:55
woodster_alee, I think we are supposed to be doing that anyway13:56
aleejaosorior, in general13:56
aleeyeah - thats what I thought too -- whether we actually are ..13:57
jaosorioralee: Honestly; I have no idea. I know that we should be doing that, but I don't think we are.13:57
*** edtubill has joined #openstack-barbican13:58
woodster_jaosorior: you have to provide all the X-xxxx headers manually if you use the un-auth context. We use it here because we have a proxy that sits in front of barbican (repose)13:58
aleedave-mccowan, so I think the answer to your question about whether to retrun a list of refs, or a ref or an object, is that we should be returning an object as we agreed and we should be setting the ref in the Location field.13:58
woodster_alee, yeah that should probably be verified in our tests as well13:59
woodster_sounds like a good paper cut :)13:59
jaosoriorwoodster_: I know you have to provide the headers manually; But IIRC you cannot bypass keystone auth in the openstack CLI, which is why we cannot yet replace our CLI with a plugin in the unified openstack cli.13:59
jaosoriorwoodster_: +1 for a papercut14:00
*** david-ly_ is now known as david-lyle14:01
woodster_jaosorior: if the openstack CLI is passing keystone tokens to barbican, then we just need to always deploy barbican with the keystone middleware when using that CLI. Are you thinking of non-keystone/auth deployment support then?14:01
jaosoriorwoodster_: yeah, that would be nice14:01
jaosoriorwoodster_: Buuut yeah, this commit has been pending for a while
woodster_jaosorior: why can14:03
aleedave-mccowan, woodster_ jaosorior - looks like we manually set the Loaction header in a handful of places.  Specifically when creating secrets, orders, subcas14:03
woodster_'t we have both ours and there's until they relax keystone only support?14:03
jaosoriorwoodster_: We could14:03
jaosoriorwoodster_: That's not a blocker for my commit. it's just a blocker for fully using the openstack CLI exclusively14:03
jaosoriorwhich is something I would like14:04
jaosoriorI see no sense in supporting repeated functionality, if it's already there in the openstack cli14:04
aleedave-mccowan, you going to amend your preferred ca patch to include the Location header?14:04
*** spotz_zzz is now known as spotz14:04
woodster_jaosorior: sounds like we need to talk to their CLI folks then14:05
jaosoriorwell, if someone could take that up in the summit it would be cool. I'm not going :/14:06
*** everjeje has joined #openstack-barbican14:06
dave-mccowanalee sounds good. that meets my concerns that 1) user can get the ref, and 2) consistent with 'somthing'   :-)14:06
openstackgerritMerged openstack/barbican: Change roles to rules in policy.json file
woodster_jaosorior: I added a paper cut to create an unauth gate btw.14:10
jaosoriorwoodster_: Excellent :D14:10
jaosoriorwoodster_: By the way, How have you been?14:11
*** vivek-ebay has joined #openstack-barbican14:11
woodster_dave-mccowan : if you are ok with deferring the system-admin part of unauth middleware for now, please consider a +2 on :)14:11
dave-mccowanalee i'd rather start a new patch to add the location field to returned CA object.  OK?14:12
woodster_jaosorior: we've been pretty busy over here making a big push for production14:12
*** nelsnelson has joined #openstack-barbican14:12
jaosoriordave-mccowan: I think starting a new patch is not unreasonable. Keeps the patch shorter and hopefully the adding of the location field merges fairly quickly.14:13
aleedave-mccowan, sounds good to me14:13
jaosoriorwoodster_: damn, any idea when things get calmer?14:13
*** zz_dimtruck is now known as dimtruck14:13
dave-mccowanwoodster_ speaking of deployment... when you have a few minutes, i'd really like to learn some best practices on deploying barbican with HA.  do you have a something you can post?14:14
woodster_jaosorior: hopefully in the next 2 to 3 weeks it will14:17
woodster_dave-mccowan: I haven't been the most involved in the HA side of things, we we are just planning to use load balancers in front of the API nodes for the most part. We are using postgres for the db, so master/slave with a lb in front of that14:18
woodster_dave-mccowan: HSM is the toughest part, since the safenet driver we use has issues with network outtages.14:19
*** vivek-ebay has quit IRC14:21
*** david-lyle has quit IRC14:22
*** rellerreller has joined #openstack-barbican14:23
*** pglass has joined #openstack-barbican14:24
openstackgerritMonty Taylor proposed openstack/castellan: Change ignore-errors to ignore_errors
*** david-lyle has joined #openstack-barbican14:26
openstackgerritMonty Taylor proposed openstack/kite: Change ignore-errors to ignore_errors
dave-mccowanwoodster_ i withdraw my comment on system-admin.  it's already covered in existing code, a few lines above your patch.14:30
*** silos has joined #openstack-barbican14:31
*** diazjf has joined #openstack-barbican14:37
openstackgerritDave McCowan proposed openstack/barbican: Adding Functional Tests and Supporting Fixes for Global Preferred CAs
openstackgerritMerged openstack/barbican: Add filter to secret list for acl secrets
*** xek has quit IRC14:53
openstackgerritMonty Taylor proposed openstack/python-kiteclient: Change ignore-errors to ignore_errors
*** jkf has quit IRC14:54
*** jkf has joined #openstack-barbican14:54
*** shohel has quit IRC14:55
redrobotgood (ugt) mornin' folks14:58
jaosoriorredrobot: sup duuuuude14:58
*** jorge_munoz has quit IRC14:58
redrobotready to review all the things jaosorior14:58
dave-mccowanredrobot we're keeping a running list here:
*** kebray has joined #openstack-barbican15:02
aleedave-mccowan, on success for the tests, retval returns 0 or 1?15:05
dave-mccowanalee 0 is success in bash.15:05
aleedave-mccowan, ok commented on that patch.15:06
dave-mccowanalee this patch has become important because of all our skipping for parallel tests.  if there is a CA or Quotas functional test failure, the gate still passes, since those tests are skipped in the second run.15:07
openstackgerritDave McCowan proposed openstack/barbican: Combine exit codes of the two functional test runs
*** jorge_munoz has joined #openstack-barbican15:11
aleejaosorior, needs a re-review15:13
redrobotalee dave-mccowan seems that's the only showstopper for liberty-rc1 ?15:15
aleeredrobot, which one?15:15
redrobotalee ?15:15
dave-mccowanredrobot, alee: i think there are still some CA to-dos that are showstoppers.15:15
jaosorioralee: Looks good. Will workflow once it passes the gate15:16
aleedave-mccowan, which ones?15:16
dave-mccowanalee there are still functional tests that are skipped because they don't pass15:16
redrobotdave-mccowan which ones?  ...  If there's too much stuff outstanding we may want to defer to mitaka ..15:16
aleedave-mccowan, right I just +2'd that patch15:17
aleeredrobot, so how many rc's are we planning on having?15:18
alee(and whens the last one?)15:18
redrobotalee RCs should be a true Release Candidate15:18
redrobotalee if it's known to be broken, we should not cut it15:18
aleeredrobot, for instance, I would like to get an update to the dogtag plugin to support subcas.  But thats not ready yet.   But I'm not sure that we want to wait until it is to cut a rc1.15:20
redrobottdink ping15:20
aleeso where does that leave us for options?15:20
redrobotalee would you be OK with that going into Mitaka?15:20
redrobotalee RC2+ should be for critical bugs found in the RC1 only15:20
diazjfredrobot, dave-mccowan, speaking of Mitaka, any mention yet on the schedule for the fish bowl sessions.15:20
tdinkredrobot: pong15:21
jaosorioralee, redrobot; If we have some support for subCAs already working with some test plugins. I think it's OK. But if we have an RC2 it would be good to get the dogtag plugin in there15:21
redrobottdink just checking on the progress of the content-type bug?15:21
aleeredrobot, so I'd really like to get it into Liberty.15:21
tdinkredrobot: didnt get to work on it much on thurs/fri though ti was going to be locked out of test for a longer time, i will look at it today though15:21
redrobotalee what's the soonest you could have it ready? ... I have to meet with the relmgr today to get an estimate for RC115:22
aleeredrobot, prob by end of tomorrow15:22
aleeredrobot, theres a lot to get together on the dogtag side of things15:23
aleeredrobot, but maybe it makes sense to cut rc1 and then then update for rc2+15:23
aleedave-mccowan, any of the other ca things that are rc1 blockers ..15:24
dave-mccowanredrobot question: when rc1 is cut, is that when the branch is split and we have to start double-commits?15:24
redrobotdave-mccowan yep, once RC1 is cut, master becomes mitaka15:25
*** stevemar has joined #openstack-barbican15:25
*** stevemar has left #openstack-barbican15:25
aleedave-mccowan, redrobot jaosorior - on the to-do list, things that should go into liberty -- 7, 8 for sure15:25
* redrobot is looking forward to Juno EOL15:25
alee5 is a good idea, 2 most likely15:26
alee3 would be great15:26
redrobotalee dave-mccowan  do we have bugs filed for those bullet points?15:26
aleeI guess we could always backport fixes to liberty ..15:27
aleeredrobot, prob not yet15:27
redrobotalee dave-mccowan I'll try to push RC1 for a couple of days...  hopefully I can get more time from the boss to work on this stuff.15:27
alee7 is practically in - waiting for workflow, 8 is something dave-mccowan is writing a patch for is should be practivcally a one -liner15:28
aleedave-mccowan, any chance you can work on either 5 or 2?15:29
*** chadlung has joined #openstack-barbican15:29
aleeand I'll work on 3 ..15:29
dave-mccowanalee probably.  i can look.  what about the to-dos in functional tests:     @testtools.skip("Skip test until ca behaviors tracks project cas")15:31
aleedave-mccowan, yeah - that would be good to get in but not critical --I happen to know that the functional test works.  Its just that it wont be idempotent.15:32
aleedave-mccowan, but you've had some experience in getting those working - so if you can get it in - great15:33
aleeI'll look at 3 and 2/15:33
dave-mccowani'll see what i can do about 5, 8, and 915:35
dave-mccowanlooks like 9 and 1 might be the same thing15:35
aleedave-mccowan, yes they are15:44
aleeso that will be great thanks .. I'll work on 2 and 315:44
dave-mccowanalee do you expect #5 to work, or do you expect a bug?15:45
*** ccneill has joined #openstack-barbican15:46
aleedave-mccowan, I expect it to work I think15:49
aleedave-mccowan, let me see ..15:50
dave-mccowandave-mccowan, woodster_ jaosorior  back to our ca_ref discussion.  it looks like the location header is returned on POST for other objects.  Not as part of a GET.15:57
jaosoriorredrobot: dave-mccowan: Should it be part of get? I didn't think it was needed.15:58
jaosoriorIf you already accessed a resource through GET; It would be implied that you already have the addres, thus you wouldn't need the location15:58
*** silos1 has joined #openstack-barbican15:59
aleejaosorior, thats true in most cases.  But we're looking at things like GET /cas/preferred15:59
dave-mccowanjaosorior the use case is:  what should GET /cas/preferred return and how?    a list, a ref, or an object.  if an object, how does the user know his ref.15:59
aleeGET /cas/global-preferred15:59
*** diazjf has quit IRC15:59
jaosoriorah! that16:00
jaosoriorTrue, in that case it actually makes sense.16:00
aleejaosorior, originally it was returning a list of refs -- which is a little strange because its a single ref.16:01
aleejaosorior, dave-mccowan , redrobot we could make it return a single ref16:01
jaosorioryeah, for the preferred case it doesn't really make sense16:01
*** silos has quit IRC16:01
aleeor we can do what we decided last week and make it return the object16:01
*** diazjf has joined #openstack-barbican16:01
aleebut then we need a Location16:01
jaosoriorSo one of two options; Either we return the attributes of the CA, witht he X-Location header set. Or we return the ref16:01
jaosorioralee, exactly16:02
*** gyee has joined #openstack-barbican16:02
jaosoriorI would go for the returning of the object with the header set16:02
aleeI suggest object + ref16:02
dave-mccowan{"ca_ref" : "http://foo"}  seems to be the most common format in Barbican.16:02
aleedave-mccowan, I think we usually return lists of refs ..16:03
dave-mccowanalee, jaosorior  has that been done before?  i don't want make our API any more inconsistent.16:03
jaosoriordave-mccowan: well, depends on what you're referring to16:03
aleedave-mccowan, jaosorior , redrobot - anyways I dont have a strong preference  - if its more consistent tostick with whats been done beofre, I'm ok with that16:03
jaosoriorif we are talking about secrets. Donig a GET /secrets/<secret-id> will actually return the metadata for the secret and on the other hand, I think it sets the header for the location16:04
aleedave-mccowan, jaosorior fwiw though, I dont think we've returned this kind of object elsewhere before in the api16:04
aleejaosorior, no - I dont think it does ..16:05
aleejaosorior, I saw only POST cases where the location is explicitly set16:05
jaosoriorI see16:05
jaosoriorin that case...16:05
dave-mccowanalee, jaosorior, redrobot.  According to wikipedia, X-location is to be used for 1) redirects, 2) newly created resources16:06
jaosoriordave-mccowan: I see16:06
aleeelmiko, you there?16:06
elmikoalee: yo16:07
jaosoriordave-mccowan, alee: Is there a difference in the policy for who is able to view the info of a CA and who is able to view the preferred ones?16:07
aleeelmiko, when is the Location header supposed to be set?16:07
elmikoalee: most frequently it is set after a resource creation from a POST16:08
elmiko(with the location of the new resourcE)16:08
elmikobut i think there are also some cases where it would be used from a PUT16:08
aleeelmiko, what about a GET?16:09
elmikoalee: like, i would do a GET /some/resource and the Location header would be set on return?16:10
*** su_zhang has quit IRC16:11
aleeelmiko, so the case here we are considering is GET /cas/preferred16:11
aleefor which we have two options16:12
alee1. return a ca_ref16:12
alee2. return the ca object and add ref to the Location header16:12
aleeelmiko, which is preferred/ more standard?16:12
elmikoi think in general returning a Location header from a GET would be non-standard, or maybe unexpected would be a better way to put it.16:13
aleeelmiko, fair enough ..16:13
aleedave-mccowan, jaosorior ^^ seems like a ca_ref is the way to go then.16:14
jaosorioralee: Seems legit16:14
elmikofrom my understanding, the Location header should be used when a new resource is created, or an operation needs to redirect the return (which may be close to what is happening here).16:14
aleedave-mccowan, you gonna fix it ?16:14
dave-mccowanOption 1:  {"cas": ["http://foo"]}     List of one is weird, but consistent with GET /cas16:15
dave-mccowanOption 2: {"ca_ref": "http://foo"}     Not weird.16:15
dave-mccowanalee, yea i'll code whatever we agree to.16:15
dave-mccowanelmiko, jaosorior ^^ between #1 and #216:16
aleeOption 3: {"ca" : "http://foo" } not weird and more consistent with 'cas"16:16
jaosoriorI would go for #216:16
jaosoriorWe've been using ca_ref all around16:17
elmiko#2 does seem clear, assuming there will only be 1 returned16:17
aleeok with me .. option 216:17
jaosoriorGET /cas is like doing a list_cas(). While GET /cas/preferred already asumes that we only have one preferred (which is actually the case)16:17
dave-mccowanLOL.  Do we need to change GET /cas/ to {"ca_refs" : ["http://foo", "http://bar"] ?16:18
jaosoriorunless we want to add capabilities for the service admin to list all the preferred CAs of all projects. But I don't think that's the case16:18
elmikodave-mccowan: that is the maximally explicit response ;)16:18
dave-mccowanNew Meme:  I don't always design APIs, but when I do it's hours before release candidate deadlines.16:20
aleedave-mccowan, I'm ok with that too - although you'll need to make sure to change the client too16:20
aleedave-mccowan, and I dont know if others - like magnum for insatnce are already using it16:20
dave-mccowanalee i was kidding on GET /cas/ response.  user can deal with that.16:21
jaosoriordave-mccowan: hahahaha that was a pretty accurate description of what's going on16:21
dave-mccowanelmiko thanks.  alee jaosorior i think our bike shed is shiny enough.16:22
jaosoriordave-mccowan: hahaha it didn't take aaaaas long16:23
jaosoriorcould have been worse16:23
dave-mccowanit's all good.  it'll save time on the code review, since we've already agreed.16:24
jaosoriorWell, add me to the review. Imma go get some dinner and probably a drink too16:25
jaosoriorHave a good day people :D16:26
*** jaosorior has quit IRC16:27
aleedave-mccowan, I think you're going to run into a bug on #516:30
aleedave-mccowan, the code to check if the subca is valid for the user is not there yet I think16:30
dave-mccowanjaosorior later ozz.  catch you later.16:31
aleechecking validator code ..16:31
dave-mccowanalee cool.  since you just looked at the code, if you can add hints/pointers to the etherpad, I'll use them.16:31
*** vivek-ebay has joined #openstack-barbican16:32
aleedave-mccowan, will do16:32
*** vivek-ebay has quit IRC16:33
*** vivek-ebay has joined #openstack-barbican16:34
*** kebray has quit IRC16:44
*** rellerreller has quit IRC16:46
*** rellerreller has joined #openstack-barbican16:46
*** chlong has quit IRC16:50
*** chlong has joined #openstack-barbican17:02
*** su_zhang has joined #openstack-barbican17:09
openstackgerritMerged openstack/barbican: Initialize Database Before Running Quota Enforcer Unit Tests
*** silos1 has quit IRC17:18
openstackgerritKaitlin Farr proposed openstack/castellan: Add ManagedObjectNotFoundError
*** diazjf has quit IRC17:20
*** diazjf has joined #openstack-barbican17:20
openstackgerritKaitlin Farr proposed openstack/castellan: Update Barbican functional tests
*** jorge_munoz has quit IRC17:24
arunkant@here..does anybody know why barbicanclient commits are failing at neutron tempest gate. I see all barbicanclient recent builds are failing at this gate17:24
diazjfarunkant, trailed it down to the following:  [ERROR] /opt/stack/new/devstack/inc/python:178 The following LIBS_FROM_GIT were not installed correct: python-barbicanclient17:26
arunkantdiazf: yes, I saw that earlier. Not able to see any place which indicates the reason for error. Trying to find out how to investigate this further as its happening for all recent builds17:31
diazjfYeah its a big problem, do you think may have anything to do with it17:32
aleeredrobot, ping17:33
aleeredrobot, please workflow as oz is not here.17:33
openstackgerritMerged openstack/barbican: Add missing X-xxxx HTTP headers to the unauth context
openstackgerritKaitlin Farr proposed openstack/castellan: Update Barbican functional tests
*** mmdurrant_ has joined #openstack-barbican17:42
arunkantdiazf: Can't tell if the issue can be related to this change as barbican-devstack-dsvm gate is successful. May be rm_work has a better idea on this17:45
diazjfrm_work -> here is the logfile, any ideas on if adding the barbican-client to devstack added this error?17:46
arunkantrm_you ^^^17:49
aleereaperhulk, hey - is there a way to create a pkcs7 cert chain from cert objects using  pyopenssl?17:59
*** kebray has joined #openstack-barbican18:00
*** rellerreller has quit IRC18:02
*** silos has joined #openstack-barbican18:13
*** vivek-ebay has quit IRC18:14
*** tasalasc has joined #openstack-barbican18:17
*** tasalasc has left #openstack-barbican18:17
openstackgerritMerged openstack/barbican: Combine exit codes of the two functional test runs
*** jhfeng has joined #openstack-barbican18:19
*** jorge_munoz has joined #openstack-barbican18:23
openstackgerritElvin Tubillara proposed openstack/python-barbicanclient: barbican help needs authentication
*** xaeth_afk is now known as xaeth18:33
*** igueths has joined #openstack-barbican18:35
openstackgerritElvin Tubillara proposed openstack/python-barbicanclient: barbican help needs authentication
*** su_zhang has quit IRC18:45
*** vivek-ebay has joined #openstack-barbican18:45
*** su_zhang has joined #openstack-barbican18:49
*** su_zhang has quit IRC19:00
*** xaeth is now known as xaeth_afk19:05
*** rellerreller has joined #openstack-barbican19:13
*** mmdurrant_ has quit IRC19:14
*** vivek-ebay has quit IRC19:15
dave-mccowanalee ping19:22
dave-mccowanalee if a project has no project ca, but there is a global-preferred-ca set, what should GET /cas/preferred return?19:22
redrobotalee pong looking19:23
aleedave-mccowan, huh ..19:25
aleedave-mccowan, who currently has perms to get the preferred ca?19:26
aleedave-mccowan, is it project admins or anyone?19:26
openstackgerritMerged openstack/castellan: Change ignore-errors to ignore_errors
openstackgerritOpenStack Proposal Bot proposed openstack/castellan: Updated from global requirements
dave-mccowanalee project preferred should be anyone.  it's basically saying "what is my default?"  i would think that 404 would only come if there were no CAs at all.  otherwise it would be the first found of: [project preferred, global preferred, first created CA]19:38
openstackgerritMerged openstack/castellan: Updated from global requirements
dave-mccowanalee same as the logic for what CA to use when none is created.  or.... do we need both a /preferred/ and a /default/ ?19:39
dave-mccowanalee or, i guess, is there no reason for a use to know his default?   and /preferred/ should act RESTfullly with set/unset preferred-ca operations.19:41
*** vivek-ebay has joined #openstack-barbican19:47
redrobotmaybe y'all covered this already, but why are we using verb routes?  Ie create-xxx and delete-xxx instead of using POST/DELETE ?19:53
redrobotweekly meeting is starting now in #openstack-meeting-alt20:01
*** su_zhang has joined #openstack-barbican20:09
*** su_zhang has quit IRC20:13
rm_workarunkant: hmmmm20:13
rm_workarunkant: that is interesting20:13
rm_workarunkant: I am not sure -- is python-barbicanclient in LIBS_FROM_GIT in the barbican gate? I don't THINK I changed that part20:14
arunkantrm_work..this is a recent change at devstack side..
arunkantrm_work: Do we need to add something on barbican devstack side to handle this additional check/validation20:15
*** vivek-ebay has quit IRC20:15
rm_workah hmm20:17
rm_workLIBS_FROM_GIT isn't set in the barbican gate for anything20:17
rm_workis it set in the python-barbicanclient gate?20:18
openstackgerritDave McCowan proposed openstack/barbican: Changes to Preferred CA Features
arunkantrm_work: No idea, I just noticed that this is a recent change which is generating the error.20:18
*** kebray has quit IRC20:18
rm_workwell, barbican still does this:
rm_worknot sure if it interferes20:20
rm_workthat was always there20:20
*** maxabidi has joined #openstack-barbican20:21
rm_workis this normal too?
rm_workin dsvm i thought all requirements were supposed to be handled by stack.sh20:21
rm_worknot sure though20:22
*** kebray has joined #openstack-barbican20:22
arunkantrm_work, may be install is there but that new valdiation is looking for the values from that variable which is likely missing barbicanclient install infor20:22
rm_workI am not super familiar with the operation of the LIBS_FROM_GIT but some people on my team might be20:24
rm_workI will ask them20:24
arunkantrm_work, great..thanks20:25
diazjfarunkant, rm_work, seems as though you can't apt-get python-barbicanclient as you can with all the rest as seen in
diazjfIts always gonna fail in LIBS_FROM_GIT20:36
*** su_zhang has joined #openstack-barbican20:37
arunkantdiazjf, can we add barbicanclient as additional git branch here? or it needs to be injected by barbican devstack setup somehow.20:41
rm_workit is already injected by barbican devstack setup AND barbicanclient devstack script20:41
rm_workthe issue is the LIBS_FROM_GIT check that was added is maybe not possible for us to pass? i am looking20:42
*** rellerreller has quit IRC20:43
rm_workI am not seeing where python-barbicanclient is actually *added* to LIBS_FROM_GIT though20:43
rm_worknot in any of the scripts of gate job definitions i saw for either barbican or barbicanclient20:43
rm_workcrap i didn't actually check the correct one20:44
rm_worknot sure where that job is defined20:44
rm_worki REALLY can't look at this right now though20:45
rm_workI have an internal fire burning with a deadline of *today*20:45
rm_workbut that is probably the issue -- remove it from LIBS_FROM_GIT in that job definition in project-config20:45
rm_workbecause python-barbicanclient's gate script handles itself20:46
arunkantrm_work ...remove it or add it ? because that check will fail if it did not find it20:46
rm_workor, try to fix its gate script to handle it the same way other projects do20:46
rm_workwell i think that gate job adds it to LIBS_FROM_GIT but then python-barbicanclient's dsvm script installs itself from local, so it doesn't look like a -egit20:47
rm_workso just get rid of python-barbicanclient from the list of LIBS_FROM_GIT for that gate job20:47
rm_workOR, figure out if there is a more correct way to handle installation in the python-barbicanclient dsvm script that doesn't overwrite the LIBS_FROM_GIT install20:48
kfarrthink job is defined here:
kfarrthe tempest-dsvm-neutron-src-{name} job, I mean20:50
rm_workyeah i see20:50
rm_workthat is what i thought20:50
rm_workbasically i think this is killing the git install:
rm_workbecause that won't be -egit20:51
rm_workso the check in won't see it right20:51
rm_workso maybe the post-test-hook there needs to be changed to match other projects?20:52
rm_worki assume other projects do not have this problem20:52
arunkantsomehow need to figure out how/where this LIBS_FROM_GIT is defined.20:55
*** vivek-ebay has joined #openstack-barbican20:57
diazjftake a look at
dave-mccowanrm_work.  fyi: landed.  i believe this is a feature you wanted for LBaaS.20:59
rm_workand neat21:00
rm_worknot sure if we actually need it though21:00
rm_workbut thanks for the heads up21:00
diazjfarunkant, do you think removing will be enough since it creates it with I'm gonna put up a simple doc patch thats failing with that change as well just to check21:16
diazjfwhen doing pip-freeze it will have a git repo rather than a version if this is done21:16
diazjfwe are picking up the src install21:17
rm_workthat seems correct21:19
reaperhulkalee: unfortunately I don't know if pyopenssl has that... Probably should implement PKCS7 eneveloping in cryptography soon, hmm21:20
reaperhulkenveloping even21:20
aleereaperhulk, as far as I can tell , it doesn't - which perhaps shouldn't surprise me21:21
*** vivek-ebay has quit IRC21:21
aleereaperhulk, but yeah, thats not a bad idea21:21
reaperhulkECDH, CRL, and a new KDF are on the top of the queue right now (along with a lot of infra work for shipping more binary wheels), but I'll keep it in mind, hehe21:22
*** mmdurrant_ has joined #openstack-barbican21:33
openstackgerritFernando Diaz proposed openstack/python-barbicanclient: Fix barbican-client README.rst
diazjfarunkant, rm_work, ok so the problem should be resolved with it should install the package from GIT, lets see what happens21:35
arunkantdiazjf, great..let's see how neutron gate reacts to this..21:36
rm_workyep let's cross our fingers :)21:39
*** vivek-ebay has joined #openstack-barbican21:39
*** silos has left #openstack-barbican21:39
*** vivek-ebay has quit IRC21:46
openstackgerritDave McCowan proposed openstack/barbican: Changes to Preferred CA Features
*** kebray has quit IRC21:54
diazjfarunkant, rm_work, still fails, but I have 1 more trick  up my sleeve21:55
openstackgerritFernando Diaz proposed openstack/python-barbicanclient: Fix barbican-client README.rst
*** vivek-ebay has joined #openstack-barbican22:05
*** igueths has quit IRC22:10
openstackgerritMerged openstack/barbican: Adding Functional Tests and Supporting Fixes for Global Preferred CAs
*** kebray has joined #openstack-barbican22:15
*** jorge_munoz has quit IRC22:15
*** kebray has quit IRC22:16
*** kebray has joined #openstack-barbican22:19
*** kebray has quit IRC22:22
*** kebray has joined #openstack-barbican22:22
openstackgerritFernando Diaz proposed openstack/python-barbicanclient: Fix barbican-client README.rst
*** jorge_munoz has joined #openstack-barbican22:25
diazjfkeep an eye on
*** edtubill has quit IRC22:27
*** su_zhang has quit IRC22:27
*** diazjf has left #openstack-barbican22:27
*** jorge_munoz has quit IRC22:27
*** su_zhang has joined #openstack-barbican22:27
*** spotz is now known as spotz_zzz22:32
*** su_zhang_ has joined #openstack-barbican22:36
*** pglass has quit IRC22:37
*** su_zhang has quit IRC22:38
*** dimtruck is now known as zz_dimtruck22:40
*** kfarr has quit IRC22:48
*** edtubill has joined #openstack-barbican22:55
*** su_zhang has joined #openstack-barbican23:03
openstackgerritFernando Diaz proposed openstack/python-barbicanclient: Fix barbican-client README.rst
*** vivek-ebay has quit IRC23:06
*** su_zhang_ has quit IRC23:06
*** chadlung has quit IRC23:08
*** su_zhang has quit IRC23:09
*** su_zhang has joined #openstack-barbican23:10
*** vivek-ebay has joined #openstack-barbican23:10
*** vivek-ebay has quit IRC23:14
*** jamielennox|away is now known as jamielennox23:23
*** ccneill has quit IRC23:28
*** vivek-ebay has joined #openstack-barbican23:44

Generated by 2.14.0 by Marius Gedminas - find it at!