20:01:03 #startmeeting barbican 20:01:04 Meeting started Mon Sep 15 20:01:03 2014 UTC and is due to finish in 60 minutes. The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:08 The meeting name has been set to 'barbican' 20:01:31 Hi everyone! As usual the agenda for today can be found here: 20:01:31 #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:01:37 #topic Roll Call 20:01:57 o/ 20:02:26 \o/ _o_ /o/ 20:02:38 o/ after a looong time! 20:02:57 0/ 20:03:10 welcome malini ! 20:03:35 reaperhulk kinda looks like YMCA? 20:03:42 :) 20:04:00 o/ 20:04:29 got a couple of barbicaneers here setting up after a meeting 20:04:43 I'm going to wait just a minute or two before we get started. 20:06:56 I think woodster_ is online now 20:06:59 let's get started 20:06:59 o/ 20:07:06 #topic jenkins.cloudkeep.io 20:07:30 malini: welcome back! 20:07:47 So the cloudkeep.io domain is owned by the Rackspace Barbican team 20:08:06 and we've set up a jenkins server to start working towards our 3rd party testing for Gerrit 20:08:35 eventually we want to be able to run functional tests on barbican with an HSM backend 20:08:41 to test the PKCS11 plugin 20:09:02 so you may notice keep-jenkins in the #openstack-barbican channel complaining about failing builds 20:09:32 for those of you who don't use Cloud Cafe, we do have a lot of tests in that framework. 20:09:43 and that's what jenkins is using now 20:09:45 #link http://jenkins.cloudkeep.io/job/openstack-barbican-cloudcafe/ 20:09:56 unfortunately the test suite seems to be failing :( 20:10:55 I mainly just wanted everyone to be aware that we're starting to build up our test infrastructure for 3rd party testing, and the goal will be to eventually make this a voting gate. 20:11:03 any questions/comments about this? 20:12:57 going once 20:13:17 ok, moving on 20:13:52 #topic Metadata Storage 20:14:23 Not sure who added this to the agenda? 20:14:29 woodster_ alee? 20:14:41 I think chellygel did 20:14:52 sorry that was from last week! 20:15:06 I the idea was to flesh that out for discussion in Paris 20:15:13 ^ +1 20:15:35 #link https://etherpad.openstack.org/p/barbican_metadata 20:15:50 We're going to go over it more in depth @ Paris to solidify the best option for us 20:16:00 but for now we can skip it, unless alee or woodster_ wants to elaborate here 20:16:07 otherwise, please feel free to take al ook and add your thoughts! 20:16:11 so for the purpose of this meeting, is it fair to say we just want to share the etherpad link so we can start brainstorming for paris? 20:16:24 yes 20:17:06 Ok, cool. So everyone, please check out that etherpad when you have time. We'll probably be talking about this in depth at the Summit. 20:17:09 moving on 20:17:11 will do 20:17:28 #topic API Stability 20:17:57 I think we should start adding IRC handles next to the items in the agenda, because I don't know who added this either. 20:18:12 redrobot, it was me 20:18:17 usually the wiki emails me when someone edits it, but for some reason I haven't been getting emails lately. 20:18:38 atiwari go head then 20:19:11 wondering what are the plans, right now the API are unstable and keep changing. 20:19:27 in that case we can think about a serous integration 20:19:44 any thoughts there? 20:20:00 the only major change I can think of was Orders, which was discussed last summit 20:20:26 we all agreed that it was ok to move forward with this breaking change 20:20:45 we've also previously agreed to support the Juno release as v1 20:21:01 so any breaking changes to the API during the Kilo cycle will require a v2 20:21:05 redrobot, correct but in near future can we assume we are not going to break it again. 20:21:41 atiwari yes, you can start integrating with the Juno release 20:21:41 since it is not yet integrate project, that we can not commit? 20:22:12 atiwari no, we have to commit to a stable v1 in Juno, so that integration can happen during Kilo 20:22:29 reaperhulk, that is great news 20:22:31 thanks 20:23:13 redrobot, next one is mine too 20:24:01 #info Juno release will be considered the stable v1 API. We will observe versioning rules for breaking changes moving forward. 20:24:15 #topic Documentation sync up with new API 20:24:20 atiwari go ahead 20:25:17 docs are not in sync with latest changes, any thoughts on updating the docs? 20:25:47 unfortunately, yes. the documentation does need some TLC 20:26:15 this will be especially important as we try to graduate again next cycle, since the TC will be looking for good documentation 20:26:59 as far as documenting the API goes. My preference is that the people who are making the API changes should also update the documentation, since they're the experts on what is changing. 20:27:22 redrobot, +1 20:27:49 can everyone start looking in to it? 20:28:33 redrobot, do you mean sphinx docs within the barbican repo? 20:28:36 we will be doing some documentation work in the near future here at Rackspace, so yes, we will be looking into 20:28:44 it 20:29:00 we actually have a doc writer who has been sending pull requests to us for doc changes 20:29:07 so it would be good to pay attention to those 20:29:28 woodster_ yes, sphinx docs as well as docbook docs 20:29:39 and wiki docs as well 20:29:57 redrobot, is that mean API developer is off the hook? 20:30:20 all will be done by doc writer 20:30:28 no I don't think so 20:31:05 I'm not sure that our doc writer will have enough bandwidth to fix all documentation for changes from all contributors 20:31:21 ok, then we will wait for more instructions? 20:31:33 is there something in particular you want to work on? 20:31:44 our doc writer will only be working on docbook documentation 20:32:03 that includes the deployer guide, and the api guide 20:32:23 she won't be working on sphinx documentation, that will still be up for the developers making the changes. 20:32:28 redrobot, order api doc will be soon obsoleted 20:32:42 I think that need some work 20:33:02 yes, we definitely want to document all the work you and others have done 20:33:29 atiwari it would be good for you to chime in on the doc CRs from Constanze 20:33:41 ok 20:34:15 how about adding doc bugs so such things can be tracked and if possible even fixed 20:34:34 malini I like that idea 20:34:34 malini, +1 20:35:29 that seems like a good way to track things 20:36:53 #agreed known documentation problems should be filed as bugs 20:37:28 atiwari can you add a bug for fixing the orders documentation. We'll want to fix it in the docbook source. 20:37:44 redrobot, I will do 20:38:55 ok, moving on guys 20:39:35 #topic Remove custom auth façade from python-barbicanclient 20:39:55 this one is woodster_'s go head. 20:40:48 I was just pointed out that we have added to that juno roadmap discussion 20:41:09 ...just wanted folks to be aware of the changes. That barbicanclient task was added today. 20:41:32 Keystone has recently made a lot of headway on making auth components we can use in barbican client. 20:41:47 So no need for us to make custom one-offs in barbican. 20:41:58 That could clean up the code quite a bit. 20:41:59 yep... i think that once we get rm_work's patches merged, the auth layer in barbicanclient will be the last major change so we can release a client 3.0 20:42:14 what is the priority on client work right now? 20:42:54 rm_work highest priority is getting stuff needed for the RCs and Juno final for Barbican proper 20:42:58 since we don't control that 20:43:06 right 20:43:09 so, still "lowish"? 20:43:30 I am holding off on bothering you guys about client stuff until I get the go-ahead that most of the other bits are cleared 20:43:35 lowesque 20:43:49 (to some degree, obviously not ENTIRELY) 20:43:54 yeah... I want to target barbicanclient 3.0 for the same day as Juno final, but I'm ok with pushing the client by a few days 20:43:59 kk 20:44:15 I'm doing some rework to try to deal with your objections redrobot 20:44:19 I 20:44:24 I'll bring it up again in a few days 20:44:27 rm_work <3 20:44:28 or next week 20:44:39 redrobot: don't <3 yet, you haven't seen it :P 20:44:59 I didn't say "caving in" :) 20:45:04 frienemies! 20:45:23 I enjoy our banter. Anyway, we can move on I think 20:45:49 ok, moving on 20:45:49 Unless there was something else woodster_ had on the subject? 20:46:13 #topic Kilo Design Summit etherpad 20:46:22 #link https://etherpad.openstack.org/p/barbican-kilo-design-sessions 20:46:23 not really, I would ask that folks re-review that etherpad for items that might have slipped in there since you last looked.... 20:47:09 So even more stuff has been getting added to the kilo etherpad...please review/add as you see fit 20:47:42 I've been trying to go thru my old notes to pull out items that would be good to tackle in the run up to (hopeful) integration in Kilo. 20:48:10 It's looking like we'll be plenty busy for the entire Summit... There's a ton of stuff there to keep us busy. 20:48:48 and I'm looking at the action items from last week and totally slacked off on them 20:48:48 yeah, at some point we'll probably want to vote on that most important ones for Kilo 20:49:22 Quota management is necessary for VM instance launch, storage (block and object), networking .. is there some common oslo support that Barbican can leverage 20:49:22 I'd just ask that folks add their names to the etherpad (on the right) 20:49:28 so I still don't know how many sessions we'll be having. I think we will be getting a table/hub like last time, so that will be awesome. 20:51:26 malini that's a good point. We should definitely go into these discussions thinking about reusing what other OS projects have done. 20:53:28 any more questions comments on this? 20:53:57 We only have one more item in the agenda, but I don't think we'll have time to discuss it here. 20:54:20 so take a look at https://review.openstack.org/#/c/118697/ and discuss on the review. 20:56:59 ok then, thanks for joining us, everyone! 20:57:04 #endmeeting