20:00:14 <redrobot> #startmeeting barbican
20:00:15 <openstack> Meeting started Mon Jun  1 20:00:14 2015 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:19 <openstack> The meeting name has been set to 'barbican'
20:00:25 <redrobot> #topic Roll Call
20:00:38 <igueths> o/
20:00:40 <elmiko> heyo/
20:00:46 <dave-m___> \o
20:01:23 <chellygel> ＼| ￣ヘ￣|／
20:01:25 <jvrbanac> o/
20:01:37 <elmiko> chellygel, always something creative ;)
20:01:47 <silos> o/
20:02:15 <redrobot> Not a whole lot of core peeps today. :-\  ... oh well, we'll still have an awesome meeting anyway :D
20:02:21 <redrobot> as usual the agenda can be found here:
20:02:23 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican#Agenda
20:02:30 <chellygel> elmiko, life is too short for boring arm raises ;)
20:02:42 <elmiko> chellygel, hells yea!
20:02:45 <redrobot> #topic Vancouver Summit Recap
20:03:07 <rellerreller> o/
20:03:10 <redrobot> The summit was a great success, I think.  Thanks to everyone who was able to make it!
20:03:12 <arunkant> o/
20:03:26 <redrobot> I've collected all the etherpads that were used during the summit at this wiki page:
20:03:31 <redrobot> #link https://wiki.openstack.org/wiki/Barbican/Liberty
20:03:33 <elmiko> no more liquorice though... ;)
20:04:33 <redrobot> I sent out some emails last Friday to contributors who signed up for action items for LIberty, so hopefully y'all received those.
20:05:16 <redrobot> Also, I've started an etherpad for the next Cycle (M), it currently has all the things we punted at the summit
20:05:23 <redrobot> #link https://etherpad.openstack.org/p/barbican-m-design-sessions
20:05:54 <redrobot> Feel free to add any topics for the next summit... ( I know, we're thinking way ahead... )
20:06:04 <redrobot> any questions/comments about the summit?
20:06:45 <elmiko> big thumbs up to the barbican team =)
20:07:01 <redrobot> thanks elmiko!
20:07:06 <alee> o/
20:07:21 <redrobot> Yeah, I feel we got a lot more done than at the Paris summit.
20:07:34 <redrobot> ok, moving on...
20:07:41 <elmiko> the work sessions were great
20:07:45 <redrobot> #topic New Core Reviewers
20:08:25 <redrobot> In case you missed it on the mailing ilst, we have two new core reviewers:  Kaitlin Farr (kfarr) from JHAPL, and Chelsea Winfree (chellygel) from Rackspace
20:08:40 <elmiko> congrats!
20:08:47 <redrobot> well deserved imho
20:08:47 <jvrbanac> w00t
20:09:05 <rellerreller> Congrats!
20:09:06 <chellygel> \o/ :)
20:09:14 <kfarr> thanks! :D
20:09:33 <redrobot> now you know who to bug for +2s and +Workflows
20:09:38 <redrobot> :0
20:09:39 <elmiko> hehe
20:09:41 <chellygel> *＼( *ω*)┓ (for you elmiko )
20:10:01 <elmiko> excellent lol
20:10:04 <redrobot> which brings me to the next topic ...
20:10:10 <redrobot> #topic Is Barbican too Slow?
20:10:35 <redrobot> I had a couple of people at different time express dissatisfaction with the turnaround speed on Gerrit reviews
20:11:16 <redrobot> alee, jaosorior and I were talking about possible solutions to this at the summit
20:11:16 <elmiko> i think that's a fair criticism
20:11:25 <redrobot> elmiko +1
20:11:35 <kfarr> Barbican is not nearly as bad some other projects
20:11:48 <redrobot> kfarr agreed.
20:12:00 <woodster_> o/
20:12:03 <redrobot> I think that with the new cores, we should hopefully see more reviews.
20:12:19 <alee> kfarr, true - but now that we have a number of core reviewers, we can probably do better.
20:12:31 <redrobot> one suggestion that alee jaosorior and I had was around the need for 3 reviewers for a CR
20:12:37 <elmiko> from my perspective, i'm hesitant to review barbican stuff because i'm a little worried about not knowing enough in the domain
20:12:47 <chellygel> ^ i think this is everyone's concern elmiko
20:12:51 <elmiko> haha
20:13:12 <elmiko> at least i'm not alone then ;)
20:13:28 <redrobot> the suggestion was to ask the +Workflow 3rd reviewer to just do a high-level review, not an in-depth one, and trust that the other two core reviewers did their due dilligence.
20:13:49 <jvrbanac> redrobot, I think 3 reviewers is appropriate for a project like Barbican.
20:13:52 <woodster_> that's why doc reviews are so important...that helps with making sure we have the requirements correct at least. No code knowledge needed
20:14:27 <rellerreller> redrobot How does that compare to other projects?
20:14:29 <woodster_> 2.5 reviewers
20:14:29 <chellygel> redrobot, what would we define "due diligence" as and "high level" as
20:14:45 <rellerreller> chellygel +1
20:14:50 <jkf> Greetings
20:15:13 <redrobot> due dilligence = line-by-line review, also possibly pulling down the patch and running it locally
20:15:15 <arunkant> woodster_, +1, I could not agree more. We need better and upto date API docs.
20:15:35 <redrobot> high level = not line-by-line, more of a general "does this change make sense for barbican?"
20:15:54 <chellygel> i'm afraid code reviews would take significantly longer if people were pulling down patches though. I think its a good idea, but if the concern is time, that may not solve that issue
20:15:58 <alee> jvrbanac, we're the only project which requires 3 reviewers.  the compromise here is that we would get the benefit of having several cores being familiar with whats going on, but not a slowdown of the process.
20:16:04 <redrobot> rellerreller almost all other projects only recquire 2 core reviewers.
20:16:04 <chellygel> I'm not sure how many of us have actually pulled changes ?
20:16:50 <elmiko> chellygel: i did for some of the testing patches, but those were easy
20:17:03 <chellygel> My concern is some / most of these won't be easy
20:17:07 <rellerreller> I think a 2.5 review sounds good to me. I remember when I first started that I thought it was only 2 core reviews and a workflow.
20:17:10 <elmiko> chellygel: +1
20:17:15 <chellygel> example: my HSM change -- that requires an HSM to actually test
20:17:39 <redrobot> chellygel agreed.  thus the "possibly" qualifier. :)
20:17:48 <alee> chellygel, sometimes it makes sense to pull a change down and test locally. soemtimes not.
20:17:58 <rellerreller> I have not been running changes locally. I thought Gerrit would take of that.
20:18:15 <jvrbanac> Personally, I expect more reviewers on code that goes into something like a key manager
20:18:18 <chellygel> i understand, but I'd have to say I don't think many people do pull the changes down... easy or hard redrobot / alee
20:18:25 <jvrbanac> Considering the implications
20:18:29 <redrobot> rellerreller I like to when it's an APIImpact review to actually see the request/response
20:19:04 <rellerreller> redrobot Good to know. That's cool.
20:19:14 <alee> rellerreller, redrobot - so some of the changes in process we suggested for api changes will help in that regard too.
20:19:40 <woodster_> one approach would be for folks to list the areas they are 'domain experts' or really interested in, and if a CR is reviewed for one of these areas, then at least one of those people should be a +2 or workflow for it.
20:20:03 <redrobot> woodster_ I would think that would increase the bus factor
20:20:14 <redrobot> woodster_ ie. so-and-so isn't here so nobody wants to review the patch.
20:20:18 <chellygel> Well, aside from just changing the number of reviewers -- what are other solutions to this problem?
20:20:20 <rellerreller> What is the exact problem? Which part of the process takes the longest?
20:20:29 <chellygel> rellerreller, i think we are on the same wavelength today :P
20:20:30 <rellerreller> First review? All reviews?
20:20:46 <redrobot> rellerreller I think the concern was around submitting the patch to finally having it merged.
20:20:49 <chellygel> I have noticed on reviews when one receives a -1 it takes time for the code submitter to address them and submit a new patch.
20:20:50 <woodster_> redrobot: well, I'd hope more than one person signed up for a given area, but no guarantee
20:21:02 <elmiko> from my perspective, the few small patches i submitted had early +1's but then it took awhile to push them over the top.
20:21:10 <chellygel> So, we will receive a -1 and it may take 1 week for them to address the issues and push back
20:21:22 <igueths> woodster_: Which would leave one having to define an /area/
20:21:23 <chellygel> but also, when a review has a -1 -- i find that other reviewers do not touch it
20:21:31 <rellerreller> chellygel I have seen that too
20:21:43 <elmiko> chellygel: that seems pretty common across projects to me
20:22:08 <chellygel> So, in my mind -- the best solution is to submit a comment to address the -1, or a new patch... that seems to kick things off again.
20:22:35 <chellygel> or asking all reviewers (not just cores) to pick through -1'd reviews as well
20:22:38 <redrobot> chellygel I admit I'm guilty of not clicking through -1s on my dashboard when there's other things to review.
20:23:01 <woodster_> we've also talked about mentioning CRs that need reviews during out weekly IRC...maybe just the top 3 oldest ones perhaps, and celebrating the ones that were merged since last week
20:23:02 <rellerreller> I do not review something that has -1.
20:23:09 <elmiko> maybe devote a small portion of this meeting to pointing out reviews that are stagnating?
20:23:12 <chellygel> i have seen patches get up to 10+ because one person was nit picked and then later someone has discovered a logical flaw
20:23:18 <chellygel> +1 elmiko
20:23:33 <woodster_> rellerreller: but you might disagree with the -1, therefore missing out on bike shed opportunities :)
20:23:56 <redrobot> woodster_ elmiko +1 to mentioning high-priority CRs in this meeting.  Usually when a contributor is interested they'll throw a link in the agenda
20:24:00 <rellerreller> woodster_ That is true, and I love bike shedding :)
20:24:18 <woodster_> rellerreller: you and me both!
20:24:20 <chellygel> redrobot, alee before changing the number -- i'd like to see us try other solutions (as we are discussing here)
20:24:31 <jvrbanac> +1 chellygel
20:24:35 <redrobot> chellygel k
20:24:36 <chellygel> perhaps 2 weeks to see if things get better?
20:24:49 <rellerreller> I would like to see someone set a date where they are available for fixing.
20:25:01 <redrobot> I just wanted to relay the concerns I heard at the summit.  We can table this for a couple of weeks.
20:25:02 <chellygel> rellerreller, for fixing -1's?
20:25:09 <rellerreller> I like when person is available for quick turnarounds to make me happy
20:25:18 <rellerreller> chellygel yes
20:25:25 <elmiko> redrobot: i was thinking in addition to high-prio stuff, just an agenda item that links to the search url for all open barbican reviews. something that could be brought up quickly and maybe a few could be cherry picked.
20:25:30 <alee> chellygel, redrobot - actually I was more concerned about the velocity of the project and not individual reviews per -se
20:25:50 <rellerreller> My memory is terrible. If a -1 is not resolved in a day or two then I forget what I reviewed and I get frustrated.
20:26:03 <alee> if I look at the last cycle, it seemed like there was a long period of relative inactivity after the summit
20:26:07 <redrobot> alee yeah, I think that's a different agenda item... one that I can probably cover next :)
20:26:24 <alee> followed by frantic activity after the mid-cycle
20:26:26 <elmiko> redrobot: i think that's fair too, i mean the folks putting patches up should be on top of posting new patchsets or responding to comments.
20:26:41 <woodster_> #segue
20:27:00 <alee> redrobot, its related, because if we fix the turnaround time , maybe the velocity problem will be fixed too.
20:27:13 <elmiko> er, i meant to reply to rellerreller. sorry
20:28:04 <redrobot> I'm ready to move on to the next topic.  We'll revisit this topic again in a couple of weeks to see how we're feeling about it.
20:28:14 <redrobot> #topic Mid-Cycle Sprint
20:28:22 <alee> redrobot, either way - I think we need to devote part of this meeting to calling out reviews
20:28:28 <alee> that have languished
20:28:48 <redrobot> alee agreed, I'll make it a point to talk about those during the meeting.  Maybe the last 10 minutes or so.
20:29:05 <redrobot> the mid-cycle sprint has been scheduled
20:29:29 <redrobot> It will be August 5-7 in Laurel, Maryland
20:29:40 <rellerreller> I have to run o/
20:29:44 <redrobot> many thanks to the JHAPL folks for hosting it
20:30:08 <redrobot> one goal that we want for the mid cycle is to land all specs before it happens
20:30:26 <redrobot> one concern that alee mentioned is that last cycle we put off a lot of things because we could "talk about it at the mid-cycle"
20:30:32 <woodster_> that was our goal last cycle :)
20:30:41 <redrobot> because of that, a lot of specs lingered for a while
20:30:54 <woodster_> we wanted the last mid cycle to just be a hackathon as I recall
20:30:54 <redrobot> and we were in a crunch to land code for the last release
20:32:20 <woodster_> so this needs to complete before M3 for any feature?: BP (with API doc verbiage as needed), then doc CR, then server code CR, then client CR?
20:32:43 <alee> redrobot, when are the liberty-1, 2 , 3 deadlines?
20:32:51 <alee> woodster_, dont forget functional tests
20:33:09 <redrobot> #link https://wiki.openstack.org/wiki/Liberty_Release_Schedule
20:33:11 <redrobot> ^^ alee
20:33:22 <woodster_> alee: I lumped that in the server CR but better to break it out for sure
20:34:07 <redrobot> I would like to see all BPs landed by liberty-1.  It would be ok for some BPs to slip to liberty-2.  However, after liberty-2 all pending specs should be punted.
20:34:15 <woodster_> so it seems that the BP and doc CRs should be merged before before the mid cycle to have a hope of meeting M3?
20:34:28 <woodster_> redrobot: got it
20:34:34 <alee> redrobot, may I suggest we aim for blueprints/specs to be in by L-1, doc and functional tests by L-2?
20:34:44 <redrobot> alee +1  I like that
20:35:01 <alee> (and ideally code too)
20:35:16 <woodster_> so two months
20:35:41 <alee> that way we can actually be reviewing code in the midcycle
20:35:54 <redrobot> woodster_ one month to iterate on spec, and one month to iterate on docs/functional tests seems like plenty of time.
20:36:37 <woodster_> I figure it depends on the feature for sure
20:36:41 <redrobot> then hopefully review and/or write code CRs at the mid-cycle.
20:37:51 <alee> woodster_, well - non-api related changes dont need functional tests or even docs sometimes ..
20:38:10 <woodster_> alee: that's true
20:38:28 <alee> but the advantage of writing the functional tests first for api changes is that you have an agreed upon goal to code to
20:39:08 <alee> woodster_, rather than having to scramble at the last minute because what was coded did not match what we were thinking for content types
20:39:12 <alee> for inatnce
20:39:45 <alee> or that certain scenarios were not actually covered in functional tests
20:40:32 <woodster_> alee: I still think api docs are the very best way to review things...even non-coders can participate in the reviews. Functional/unit tests are nice after that though
20:40:54 <alee> woodster_, I'm not saying not to code during the first two months -- just to try to get specs, fucntional tests, api docs done by L-2
20:41:17 <alee> woodster_, agreed - you cant write the functional tests without the api docs
20:41:24 <woodster_> alee: that sounds good
20:41:34 <alee> otherwise how would someone review them?
20:42:06 <chellygel> (afk -- 2 secs!)
20:42:27 <redrobot> ok, so to summarize:
20:42:39 <redrobot> #agreed We'll aim to land Blueprint Specs by liberty-1
20:42:59 <redrobot> #agreed We'll aim to land Documentation CRs for APIImpact specs by liberty-2
20:43:12 <redrobot> #agreed We will not be landing specs at the mid-cycle
20:43:37 <alee> redrobot, doc crs + functional tests please :)
20:44:38 <redrobot> #agreed Functional tests should be submitted with or shortly after the Docs CR
20:45:41 <chellygel> (back)
20:45:59 <redrobot> any comments/questions about the mid-cycle or the milestone goals?
20:46:28 <redrobot> ok, moving on...
20:46:37 <redrobot> #topic CR Reviews
20:47:06 <redrobot> since we're out of topics, let's start the habit of mentioning high priority or long running CRs
20:47:26 <redrobot> I'll start.  We really need to land the ACL fixes so we can backport them to Kilo and cut a new release
20:47:30 <redrobot> #link https://review.openstack.org/#/q/owner:%22Arun+Kant%22+status:open,n,z
20:47:47 <redrobot> thanks to arunkant for all the work he's put into these.
20:48:39 <alee> redrobot, as you're going to cur a new release with arunkant changes, can you also backport the fix I put in for dogtag?
20:49:24 <elmiko> do we have time for a quick chat about barbican.sh ?
20:49:26 <redrobot> #action redrobot to backport dogtag fix to Kilo branch
20:49:30 <alee> redrobot, https://review.openstack.org/#/c/181786/
20:50:20 <alee> redrobot, and agreed - we need to get arunkant changes in -- they've been pending awhile
20:50:41 <redrobot> elmiko sure thing... we have 10 min before the end of meeting
20:50:45 <alee> redrobot, which CRs ? there are many?
20:50:54 <arunkant> Will appreciate if folks can review ACl changes there are 3 CRs related ( 1 doc, 2 code CR)
20:51:38 <elmiko> so, i'm helping alee with some packaging issues and i'm curious about the deprecation of barbican-all, and if it would acceptable to create a cli.py module that we could generate some wrapper scripts from?
20:52:02 <elmiko> also, if uwsgi is the "default" deployment option for a single instance/stand alone barbican?
20:52:11 <redrobot> #topic barbican.sh
20:52:53 <elmiko> basically, it makes life very easy for an openstack-barbican package if we can have a script to start the service from, systemd for example.
20:53:10 <elmiko> and i thought barbican-all would be nice, but i'm curious about it's deprecation
20:53:24 <redrobot> elmiko yeah... I think xaeth had some similar concerns for Fedora packaging
20:53:59 <redrobot> uwsgi is not a requirement.  just happens to be what Rackspace will be using.  I've heard of HP folks successfully running Barbican in Apache
20:54:01 <elmiko> also, i've seen other projects use the setup.cfg to create the script files from python code so that we don't need to carry a bunch of extra scripts. i'm just curious how people feel about this.
20:54:29 <elmiko> i'm fine with uwsgi as it provides a nice stand alone option, apache seems better for integrated options
20:54:31 <redrobot> elmiko I'm on board for moving some scripts into the code tree where it makes sense.
20:54:44 <elmiko> ok, should i create a blueprint/spec or just bug and CR ?
20:55:09 <alee> elmiko, I'm ok with bug and cr ..
20:55:16 <elmiko> cool
20:55:17 <redrobot> I think that the RDO and Debian packaging folks would prefer that we support Apache, since I think all of openstack runs on apache out of the box
20:55:31 <elmiko> i'm still experimenting, but i have a feeling i can come up with some clean and straight forward.
20:55:46 <elmiko> redrobot: agreed, and i don't want to change that.
20:55:58 <alee> redrobot, interesting -- even barbican -- I may talk to you abiout that - because I'm looking at apache for rdo.
20:56:16 <elmiko> but we do have cases where users might install just the barbican package, and i think a script would be helpful for that.
20:56:45 <redrobot> elmiko agreed.  another request that the packagers had was to drop the .py suffix from our scripts
20:57:11 <elmiko> right, using the setup.cfg tools could make it really clean that way
20:57:15 <redrobot> I know xaeth had to do a couple of custom patches for the Fedora package.
20:57:23 <elmiko> (i'm blanking on the package name right now)
20:57:43 <elmiko> setuptools
20:58:07 <redrobot> elmiko yeah, with entry_points that point to a module in the code tree...  definitely a nice setup.
20:58:15 <elmiko> right
20:58:35 <elmiko> ok, i'll keep hacking and hopefully throw up a bug/cr sometime in the next 2 weeks
20:58:45 <redrobot> #action elmiko to file bug to move some management scripts from bin/ to entry_points
20:58:52 <redrobot> ok, just about out of time y'all
20:58:54 <elmiko> thanks
20:58:54 <redrobot> thanks for coming!
20:59:10 <redrobot> #endmeeting