20:00:13 <sbalukoff> #startmeeting Octavia
20:00:14 <openstack> Meeting started Wed Sep 10 20:00:13 2014 UTC and is due to finish in 60 minutes.  The chair is sbalukoff. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:17 <openstack> The meeting name has been set to 'octavia'
20:00:28 <sbalukoff> Ok, folks!  This is our agenda for today:  https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Agenda
20:01:10 <sballe> o/
20:01:16 <rm_work> o/
20:01:17 <sballe> I was on the wrong IRC ;-)
20:01:18 <TrevorV> o/
20:01:20 <blogan> hi
20:01:21 <crc32> hello
20:01:22 <sbalukoff> #topic Discuss: Use storyboard instead of launchpad for blueprints?
20:01:22 <johnsom> o/
20:01:24 <rohara> hi
20:01:26 <rm_work> (we should really have a "roll call" topic for a minute or so)
20:01:32 <tmc3inphilly> good day
20:01:32 <masteinhauser> o/
20:01:36 <sbalukoff> Haha!
20:01:36 <dlundquist> o/
20:01:43 <davidlenwell> o/
20:01:44 <sbalukoff> Ok, so!
20:01:51 <blogan> dlundquist: you're back from iceland?
20:01:56 <dlundquist> blogan: yep
20:02:02 <dougwig> o/
20:02:06 <sbalukoff> I would like to propose using StoryBoard for project management and blueprints instead of launchpad.
20:02:10 <jamiem> hi all
20:02:12 <blogan> welcome back!
20:02:17 <sballe> dlundquist, Where you on the plane the pilot took and flew around the volcano?
20:02:17 <rm_work> "iceland? isn't that in finland?" --random person on Yahoo Answers
20:02:31 <dougwig> sbalukoff: have you asked anyone in infra whether it's ready for that?
20:02:35 <xgerman> storyboard: https://wiki.openstack.org/wiki/StoryBoard/Roadmap
20:02:52 <xgerman> the lack of cross-outs make me +1 dougwig
20:02:57 <sbalukoff> dougwig: I have not, but I do know that other "official" OpenStack projects already are.
20:03:06 <davidlenwell> I've been using storyboard to manage refstack development for months now .. its been a lot better than trying to use launchpad
20:03:14 <dougwig> sbalukoff: which ones?  have you talked to those folks?
20:03:20 <blogan> sbalukoff: according to that roadmap it looks like infra isn't ready for other projects, but I could be wrong
20:03:24 <johnsom> I feel that we already have a start in launchpad and storyboard does not seem ready.  It looks like there are at least a few releases before they plan for projects to use it
20:03:28 <jwarendt> Hi everyone - new member of HP LBaaS team.
20:03:38 <barclaac> Hi all
20:03:39 <blogan> jwarendt: welcome!
20:03:40 <dougwig> jwarendt: hiya, welcome
20:03:42 <sballe> I agree storyboard is not ready as far as I know
20:03:56 <ajmiller> Hi, another new HP LBaaS Person here -- Al Miller.
20:03:57 <davidlenwell> I dissagree .. I feel its ready for use..
20:04:05 <dougwig> ajmiller: hiya, welcome
20:04:08 <vivek-ebay> welcome
20:04:16 <sbalukoff> I would say that launchpad is not ready as a tool for project management, but then I am opinionated.
20:04:32 <blogan> arent we all
20:04:34 <davidlenwell> sbalukoff: +2
20:04:35 <sballe> before we switch I want to get a confirmaiton from Monty who is actually in charge of making StoryBoard happen
20:04:42 <sbalukoff> I'm especially opinionated.
20:04:46 <johnsom> Launchpad is not great, but it has the basic features.
20:04:58 <xgerman> sballe +1
20:04:59 <johnsom> Storyboard is missing links to specs and subscriptions
20:05:17 <blogan> ill definitely want to move to storyboard, not sure now is the right time
20:05:19 <dougwig> i'm of the opinion that whoever has to wrangle it for making milestones can make the call, but you'd better be ready to fall back, and not ride it into the ground of your opinionation.
20:05:25 <sbalukoff> launchpad is very clunky to use. It doesn't provide a good, standard way to split up blueprints into tasks and assign those tasks to different people.
20:05:47 <xgerman> sbalukoff we hear you
20:05:53 <sbalukoff> It doesn't provide any native mechanism to discuss a given blueprint. You have to turn to external systems for that which is a huge disruption in workflow.
20:06:01 <xgerman> but I am not in the camp anyhting is better than launchpad :-)
20:06:07 <rm_work> I've been using launchpad for a bit with Barbican, and the auto-linkages and such seem to work fine, it might not be perfect but it definitely works -- i would vote to wait at least for a few remaining features in storyboard to show up and for confirmation that it's "ready for general use" from the maintainers
20:06:08 <blogan> etherpad!
20:06:09 <sballe> sbalukoff, I am IM with mordred
20:06:19 <johnsom> Milestone support in StoryBoard is still two releases out....
20:06:23 <dougwig> we're really talking launchpad+gerrit specs vs storyboard, right?
20:06:28 <sballe> and the answer is "no. it's not ready for that yet"
20:06:32 <sbalukoff> We're still going to use gerrit.
20:06:37 <mordred> sup?
20:06:40 <dougwig> because launchpad is nothing more than a link organizer, really.
20:06:42 <sballe> my question was: @mordred Is storyboard ready? in our Octavia meeting today some people are talking about using Storyboard instead of launchpad. Does that even make sense
20:06:43 <sbalukoff> It would be StoryBoard + gerrit.
20:06:46 <mordred> storyboard is not ready yet
20:06:53 <mordred> we're getting close to moving infra on to it
20:06:56 <sballe> mordred, Thanks Monty
20:07:02 <mordred> sorry - wish it was
20:07:05 <mordred> it's getting close!
20:07:09 <dougwig> mordred: thank you
20:07:11 <davidlenwell> mordred: refstack has been using it successfully for a while
20:07:14 <dougwig> sbalukoff: i can't support switching, given that.  :)
20:07:22 <barclaac> Launchpad it is then.
20:07:23 <xgerman> dougwig +1
20:07:29 <mordred> one sec
20:07:56 <rm_work> dougwig +1
20:07:58 <sballe> dougwig, +1
20:08:06 <sballe> mordred, +1
20:08:14 <sbalukoff> mordred: Is there something else you wanted to add?
20:08:22 <johnsom> dougwig +1
20:08:22 <mordred> yeah - hang on just a sec ...
20:08:25 <sbalukoff> Ok.
20:08:52 <tmc3inphilly> is moving ot launchpad amid a very busy dev cycle worth the potential impact to velocity or can we get by with what we have for the near-term?
20:08:53 <mordred> ok. yeah. what I said
20:09:38 <blogan> tcm3inphilly: it really wouldn't be impactful of velocity, the move at least
20:09:39 <sballe> sbalukoff, I would like fo rus in the future not to make choice based on opinion but on facts.changing to StoryBoard could have been horrible for us at this point
20:09:48 <blogan> if it isn't ready and it meltsdown then that woudl be an issue
20:09:52 <sbalukoff> mordred: It would be less pain to switch now, while we really don't have much in launchpad. We're still bootstrapping this project. Does that change your opinion at all?
20:11:30 <sbalukoff> sballe: Ironically, we're making this decision based on the opinion of mordred. (Who is probably the most informed of us, but still, I hesitate to call it "fact.")
20:11:51 <sballe> mordred is in charge of the project so he is in the know He runs hte project
20:11:52 <blogan> well I think that roadmap wiki also backs it up
20:12:00 <rm_work> well, if someone came in and asked us to use LBaaS in production at our 0.5 milestone, what would we say? would it be opinion? :P
20:12:14 <sballe> sbalukoff, He has all the "facts" around storyboard
20:12:29 <sbalukoff> sballe: Which is why we trust his opinion.
20:12:43 <blogan> so its a very educated opinion
20:12:50 <sbalukoff> blogan: Exactly.
20:12:55 <davidlenwell> So I actually have some facts here
20:12:57 <sballe> sbalukoff, Yes but again his opinion is backed up byfacts...
20:12:58 <sbalukoff> Anyway, so:
20:13:03 <dlundquist> I think we are getting off topic here
20:13:08 <sballe> I agree
20:13:10 <dougwig> dlundquist: +1
20:13:11 <rohara> dlundquist: agree
20:13:13 <xgerman> dlunquist +1
20:13:13 <krotscheck> eh? wha?
20:13:14 <sbalukoff> #agreed we stick with launchpad for project managment for now.
20:13:25 <TrevorV> +1 sbalukoff
20:13:29 <sballe> sbalukoff, Great! +1
20:13:31 <davidlenwell> fact 1 .. switching from lp to storyboard cause a marked increase in vilocity and orginization
20:13:45 <sballe> mordred, Thaks for jumping in with so short notice :-)
20:13:47 <sbalukoff> #topic Vote on whether haproxy.cfg should be rendered in the amphora or the amphora driver
20:14:21 <sballe> sbalukoff, can you remind me the three options; Yes, No, abstain?
20:14:27 <dougwig> i think we just cut off davidlenwell.  perhaps move that discussion to the ML?
20:14:31 <sbalukoff> Is anyone not up to speed with the discussion which happened on the mailing list regarding this topic last last week?
20:14:45 <sballe> sbalukoff, +1 on speed up
20:14:58 <TrevorV> sbalukoff, I'm not caught up in emails... I've been working on a blueprint really intimately :D
20:15:01 <blogan> does everyone know what an amphora is?
20:15:09 <xgerman> or short amp
20:15:13 <rm_work> I hope so :P
20:15:23 <dougwig> option 4: don't care as long as there is an interface in-between either way.
20:15:24 <barclaac> If not, then not eligible to vote :-P
20:15:24 <sballe> xgerman, -1 on amp
20:15:33 <dougwig> and by interface, i mean driver.
20:15:45 <sbalukoff> dougwig: So, I see two topics we should probably vote on.
20:16:11 <sbalukoff> xgerman: Correct me if I'm wrong, but one of the central features of your argument is that you don't want an amphora driver layer, is that correct?
20:16:18 <sbalukoff> If so, then we should vote on that first.
20:16:26 <dougwig> votes are not consensus, and whether we structure it with an interface should not be a vote.  where we render it, i really don't care.
20:16:28 <sbalukoff> Where we render haproxy.cfg is actually a secondary problem.
20:16:41 <davidlenwell> dougwig I was cut off.. but that is okay..  having actually ptl'd a project that successfully uses storyboard and never touched launchpad I do have a lot of information on the subject and am always happy to talk about it.. but if nobody wants to listen I won't waste my breath going on abou tit
20:16:46 <crc32> what where the vote topics?
20:17:01 <sbalukoff> crc32: I'm introducing those now.
20:17:36 <sbalukoff> xgerman: Do you want to say anything before we vote on that?
20:17:46 <xgerman> sure
20:17:53 <sbalukoff> Please be brief.
20:17:55 <sbalukoff> :)
20:18:22 <xgerman> I think that REST is a much better interface than some drive rin the comtroller. That doesn't preclude having drivers on the amphora
20:18:45 <sbalukoff> xgerman: That was discussed, in both models, the API on the amphora will be RESTful.
20:19:07 <blogan> i think the only thing that makes rendering on the controller, is that minor updates do not result it having to update thousands of amphora
20:19:10 <dougwig> that only works if every amphora implements the same rest interface.  that is horribly limiting.
20:19:33 <sbalukoff> blogan: That's the second voting topic.
20:19:48 <blogan> well then im confused
20:20:01 <blogan> we're voting on whether we want a driver layer in the controller first?
20:20:03 <TrevorV> sbalukoff, what is the first vote then exactly?
20:20:07 <sbalukoff> So here's what I see us voting on in a moment:  First vote will be:  Should we use a driver layer when interfacing with the amphora? Yes No Abstain
20:20:12 <blogan> and then where the rendering is done second?
20:20:21 <xgerman> works for me
20:20:23 <sbalukoff> Second vote will be: Should we render the haproxy config on the controller / driver or on the amphora? Yes No aAbstain
20:20:27 <sbalukoff> Ok!
20:20:35 <blogan> okay
20:20:36 <sbalukoff> #startvote Should we use a driver layer when interfacing with the amphora? Yes No Abstain
20:20:37 <openstack> Begin voting on: Should we use a driver layer when interfacing with the amphora? Valid vote options are Yes, No, Abstain.
20:20:38 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:20:41 <crc32> #abstain
20:20:45 <sbalukoff> #vote Yes
20:20:46 <blogan> #vote Yes
20:20:46 <dougwig> #vote Yes
20:20:46 <rm_work> #vote Yes
20:20:47 <TrevorV> sbalukoff, forgive me, but wouldn't the voting be moot if we don't vote to have a driver?
20:20:49 <barclaac> #vote Yes
20:20:55 <TrevorV> #vote Yes
20:20:58 <sbalukoff> TrevorV: No, it's unrelated.
20:21:00 <sballe> #vote Yes
20:21:00 <crc32> #vote abstain
20:21:00 <xgerman> #vote No
20:21:01 <rohara> #vote Yes
20:21:04 <davidlenwell> #vote Yes
20:21:12 <dlundquist> #vote No -- This will require defining an additional interface this early in development
20:21:12 <tmc3inphilly> #vote Yes
20:21:13 <jamiem> #vote No
20:21:14 <openstack> dlundquist: No -- This will require defining an additional interface this early in development is not a valid option. Valid options are Yes, No, Abstain.
20:21:18 <sbalukoff> 60 seconds until voting is closed.
20:21:23 <rm_work> lol dlundquist
20:21:29 <dlundquist> #vote No
20:21:30 <xgerman> dlundquist +1
20:21:35 <dougwig> i'm glad i didn't editorialize mine.
20:21:36 <johnsom> #vote abstain
20:21:58 <ajmiller> #vote No
20:22:09 <sballe> dougwig, lol
20:22:23 <sbalukoff> #endvote
20:22:24 <openstack> Voted on "Should we use a driver layer when interfacing with the amphora?" Results are
20:22:25 <openstack> Yes (10): rm_work, sballe, tmc3inphilly, sbalukoff, TrevorV, barclaac, dougwig, rohara, davidlenwell, blogan
20:22:26 <openstack> Abstain (2): crc32, johnsom
20:22:28 <openstack> No (4): xgerman, dlundquist, ajmiller, jamiem
20:22:36 <sbalukoff> Ok, So we're using a driver layer.
20:22:39 <sbalukoff> Next vote...
20:23:00 <sbalukoff> #startvote Shoud we render the haproxy.cfg in the driver layer or the amphora? Driver Amphora Abstain
20:23:01 <openstack> Begin voting on: Shoud we render the haproxy.cfg in the driver layer or the amphora? Valid vote options are Driver, Amphora, Abstain.
20:23:02 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:23:05 <blogan> #vote yes
20:23:06 <openstack> blogan: yes is not a valid option. Valid options are Driver, Amphora, Abstain.
20:23:07 <dougwig> #vote Abstain
20:23:09 <sbalukoff> #vote Driver
20:23:11 <rm_work> #vote Driver
20:23:14 <dlundquist> #vote Driver
20:23:19 <barclaac> #vote Amphora
20:23:20 <sballe> #vote Driver
20:23:21 <blogan> #vote Driver
20:23:21 <TrevorV> #vote Driver
20:23:27 <xgerman> #vote Amphora
20:23:35 <crc32> #vote abstain
20:23:41 <tmc3inphilly> #vote Driver
20:23:42 <rohara> #vote Driver
20:23:42 <ajmiller> #vote Amphora
20:23:58 <davidlenwell> #vote Driver
20:24:01 <crc32> #vote driver
20:24:12 <sbalukoff> 60 seconds until voting is closed
20:24:32 <VijayB> #vote Amphora
20:24:52 <johnsom> #vote abstain
20:25:12 <sbalukoff> #endvote
20:25:13 <openstack> Voted on "Shoud we render the haproxy.cfg in the driver layer or the amphora?" Results are
20:25:14 <openstack> Amphora (4): xgerman, barclaac, ajmiller, VijayB
20:25:15 <openstack> Abstain (2): dougwig, johnsom
20:25:16 <openstack> Driver (10): rm_work, tmc3inphilly, sbalukoff, TrevorV, sballe, dlundquist, crc32, rohara, davidlenwell, blogan
20:25:28 <sbalukoff> Ok, we're rendering the haproxy.cfg in the driver
20:25:48 <VijayB> my vote's assuming that hopefully, coming in late, I understand Amphora right
20:26:00 <juliancash_> #vote Abstain
20:26:02 <dougwig> amphora == vm/container/backend/appliance.
20:26:04 <sbalukoff> VijayB: you can see the discussion on this on the mailing list.
20:26:11 <sbalukoff> Crap, did we just have a netsplit?
20:26:13 <blogan> the amphora is a vase
20:26:26 <sbalukoff> :)
20:26:29 <crc32> yea a netsplit right in a vote too.
20:26:41 <blogan> i think the vote captured everyone's vote
20:26:47 <sbalukoff> I think it did, too.
20:26:50 <sbalukoff> From what I can tell.
20:26:50 <dlundquist> net split?
20:26:52 <sbalukoff> :P
20:26:55 <VijayB> dougwig, blogan: thanks - so, is it the controller or the backend VM that will run haproxy?
20:27:05 <dougwig> VijayB: backend VM
20:27:09 <VijayB> sbalukoff: Yes, I'll take a look at the MLs...
20:27:16 <sbalukoff> #topic Vote on whether we should keep meetings in IRC or move back to webex
20:27:18 <rm_work> ...
20:27:30 <blogan> VijayB: i was being sarcastic, a sore loser, the amphora is the VM that is hosting the haproxy instance
20:27:32 <crc32> #vote abstain
20:27:33 <blogan> instances
20:27:37 <dlundquist1> #vote IRC
20:27:38 <davidlenwell> #vote IRC
20:27:41 <sbalukoff> crc32: Hold on
20:27:42 <blogan> vote hasn't started it
20:27:45 <VijayB> dougwig: ok, how many entities will actually update a single amphora?
20:27:46 <dougwig> lol
20:27:49 <sbalukoff> I actually need to start the vote.
20:27:55 <rm_work> #vote IRC
20:27:56 <sballe> ;-)
20:28:03 <barclaac> #vote abstain
20:28:07 <blogan> sbalukoff: hold up lets make sure VijayB understand what the amphora is
20:28:10 <dougwig> VijayB: likely multiple api controllers, similar to neutron-server
20:28:11 <sbalukoff> The topid hasn't been changed yet, so I think the bot got split
20:28:12 <xgerman> #vote webex
20:28:24 <sballe> #vote webex
20:28:32 <vivek-ebay> hold on
20:28:35 <davidlenwell> you can't use webex and expect other developers in openstack to participate
20:28:37 <davidlenwell> period..
20:28:41 <TrevorV> You guys realize he has to start the vote still right?  H aha
20:28:45 <barclaac> sbalukoff - start the vote already :-)
20:28:58 <davidlenwell> if you want larger community support you have to have irc meetings.
20:29:03 <sbalukoff> barclaac: Ok, I'll try, but I think the bot got netsplit
20:29:04 <xgerman> I though he was counting with his fingers
20:29:12 <crc32> let the votehappen. IRC is gonna win anyways.
20:29:15 <blogan> up up down down left right left right a b select start
20:29:15 <TrevorV> davidlenwell, hence one of the reasons to vote for keeping it IRC or not.
20:29:17 <sbalukoff> #startvote Where should we hold our weekly meetings? IRC Webex Abstain
20:29:19 <openstack> Begin voting on: Where should we hold our weekly meetings? Valid vote options are IRC, Webex, Abstain.
20:29:20 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:29:20 <TrevorV> :)
20:29:23 <dougwig> #vote IRC
20:29:23 <dlundquist> #vote IRC
20:29:24 <rm_work> #vote IRC
20:29:26 <VijayB> dougwig, blogan: Ok.. so we can have multiple controllers firing off simultaneous requests for haproxy.cfg rewrites - these would need to be serialized at some place... one place to do that is the MQ, the other, in the VM running the haproxy..
20:29:27 <barclaac> #vote abstain
20:29:28 <sbalukoff> #vote Abstain
20:29:29 <blogan> #vote IRC
20:29:29 <TrevorV> #vote Abstain
20:29:29 <crc32> #vote abstain
20:29:33 <rohara> #vote IRC
20:29:35 <tmc3inphilly> #vote IRC
20:29:36 <xgerman> #vote Webex
20:29:36 <davidlenwell> I do not understand why this is even a question
20:29:49 <dlundquist> I will point out that holding this vote on IRC does result in a certain bias
20:29:50 <jamiem> #vote IRC
20:29:50 <rohara> davidlenwell: +1
20:29:55 <rm_work> davidlenwell: me either but we vote because we vote
20:29:57 <ajmiller> #vote abstain
20:29:57 <johnsom> #vote IRC
20:30:00 <jamiem> dlundquist: +1 :)
20:30:05 <jwarendt> #vote abstain
20:30:05 <sbalukoff> dlundquist: We've held the vote in webex, on gerrit and now on IRC.
20:30:07 <dougwig> dlundquist: similar to how it went when we held it in webex?  :)
20:30:13 <sbalukoff> So, we have all flavors of bias represented.
20:30:14 <VijayB> I'm confused about what all the voting is for :'(
20:30:23 <rm_work> VijayB: where our meetings are
20:30:28 <sbalukoff> 60 seconds until voting closes
20:30:28 <VijayB> rm_work: ok :)
20:30:32 <dlundquist> yeah, atleast I dont' need a VM to join these meetings
20:30:43 <rm_work> if we continue to hold the meetings on IRC, or if we go back to holding meetings on Webex
20:30:44 <VijayB> #vote IRC
20:30:45 <sballe> #vote wenex
20:30:46 <openstack> sballe: wenex is not a valid option. Valid options are IRC, Webex, Abstain.
20:30:47 <davidlenwell> dlundquist: +2
20:30:52 <sballe> #vote wenex#vote webex
20:30:53 <openstack> sballe: wenex#vote webex is not a valid option. Valid options are IRC, Webex, Abstain.
20:30:58 <TrevorV> davidlenwell, all I can say is both have pros and cons, and in this case we're voting to see where it ends up.  Whether or not you understand its necessity is irrelevant at this point
20:30:59 <sballe> #vote webex
20:31:02 <rm_work> :P
20:31:16 <sballe> TrevorV, +1
20:31:21 <tmc3inphilly> ICQ?
20:31:26 <rm_work> woo
20:31:32 <davidlenwell> icq meetings for the win
20:31:34 <crc32> telegraph
20:31:39 <sbalukoff> #endvote
20:31:40 <openstack> Voted on "Where should we hold our weekly meetings?" Results are
20:31:41 <davidlenwell> pony express
20:31:42 <openstack> Abstain (6): jwarendt, sbalukoff, TrevorV, barclaac, ajmiller, crc32
20:31:43 <openstack> IRC (9): jamiem, rm_work, tmc3inphilly, johnsom, dougwig, VijayB, dlundquist, rohara, blogan
20:31:43 <sbalukoff> HAHA
20:31:44 <openstack> Webex (2): xgerman, sballe
20:31:45 <TrevorV> #vote morse-code
20:31:55 <sbalukoff> Ok, so, It looks like IRC wins.
20:31:57 <blogan> webex is dead!!!!!!!! hip hip hooray!
20:32:01 <davidlenwell> yay
20:32:07 <blogan> sorry
20:32:10 <sbalukoff> So, we'll be keeping our meetings in IRCS for the time being.
20:32:14 <xgerman> well, I need to work on my writing skills then :-(
20:32:17 <dougwig> we should likely move these meetings to a slot on the actually meeting channels at some point.
20:32:21 <rm_work> we can still use webex/gchat for day to day discussions on the fly...
20:32:21 <sbalukoff> #topic Discuss use of Pecan, WSME, and jsonschema for the API
20:32:34 <TrevorV> sbalukoff, I have one question first
20:32:39 <TrevorV> Before we switch to this
20:32:45 <sbalukoff> TrevorV: Ok.
20:32:46 <dougwig> sbalulkoff, type "#undo"
20:32:50 <sbalukoff> #undo
20:32:50 <xgerman> rm_work this is like you still finished the race
20:32:51 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x326b050>
20:32:55 <sballe> blogan, When we do IRC meetings we neve discus thing in a lot of details and laways end up differing to the ML where nothing happens. the few time we have met in webex/google hangout we have been better at making decidsion
20:33:02 <rm_work> xgerman: lol
20:33:05 <dlundquist> sbalukoff: could you clarify which API we are talking about
20:33:10 <TrevorV> The meeting minutes are different than the recordings of the conversations in the meeting, right?
20:33:12 <rm_work> xgerman: I got that a lot as a kid <_<
20:33:14 <TrevorV> Are both captured by the bot?
20:33:18 <rm_work> during, you know, actual races
20:33:22 <blogan> sballe: i nkow and when something needs to be discussed that in depth we should do a webex
20:33:30 <sbalukoff> dlundquist: Can we wait until open discussion to talk about that?
20:33:40 <dougwig> TrevorV: yes
20:33:47 <sbalukoff> TrevorV:
20:33:50 <sbalukoff> Yes.
20:33:51 <sbalukoff> Haha
20:34:03 <rm_work> #trevorv Yes
20:34:13 <sbalukoff> Yes, so, the meetbot makes "minutes" which are just a summary of the stuff we explicitly tell it to log with #commands
20:34:15 <TrevorV> sbalukoff, dougwig, awesome, okay.  I was just going to ask if it would be necessary for me to write up the meeting notes or not still.
20:34:20 <TrevorV> Looks like I don't have to do that :D
20:34:28 <blogan> you sound like you enjoyed doing that
20:34:35 <rm_work> he did
20:34:36 <sbalukoff> TrevorV: You don't have to do that, but if you want to, that's certainly welcome.
20:34:37 <dougwig> TrevorV: check out the links after stephen does the end meeting, or browse eavesdrop.openstack.org
20:34:41 <rm_work> I think we should still make him do it
20:34:42 <TrevorV> Honestly, it helped me learn quite a bit more than I would normally
20:34:43 <dlundquist> sbalukoff: I just wanted clarification on what which API was meant by "the API", operator facing, internal (controller - amphora) or both
20:34:49 <crc32> rm_work: I agree
20:34:53 <xgerman> trevorV you should have voted webx -- wonder what blogan is paying you guys :-)
20:34:59 <blogan> dlundquist: operator
20:35:01 <blogan> for now at least
20:35:02 <sbalukoff> TrevorV: Your meeting minutes are higher quality than the ones auto-generated by the meetbot.
20:35:07 <blogan> lol
20:35:11 <dlundquist> blogan: thanks
20:35:13 <sbalukoff> Mostly because I suck at remembering to tell it what to log.
20:35:27 <TrevorV> #action TrevorV to suck it up and make meeting minutes anyway
20:35:34 <sbalukoff> Haha!
20:35:36 <barclaac> sbalukoff can we discuss the single driver per controller we discussed last week?
20:35:38 <dougwig> the quality of the irc minutes is in large part controlled by the use of the meta tagging by the chair.  :)
20:35:49 <rm_work> #startvote Should TrevorV still have to make IRC minutes? Yes Abstain
20:35:50 <openstack> Only the meeting chair may start a vote.
20:35:50 <sbalukoff> barclaac: Let's do that after the next topic.
20:35:55 <barclaac> k thx
20:36:02 <blogan> ok we're getting off topic now
20:36:06 <sballe> #vote yes
20:36:07 <sbalukoff> #topic Discuss use of Pecan, WSME, and jsonschema for the API
20:36:10 <blogan> okay
20:36:13 <rm_work> :P
20:36:18 <sbalukoff> #chair blogan
20:36:18 <openstack> Current chairs: blogan sbalukoff
20:36:28 <sbalukoff> Go for it, eh!
20:36:39 <blogan> so I don't think we need to use jsonschema yet because from what I can tell so far WSME's built in validation will give us what we need
20:37:09 <blogan> also I am going with Pecan adn WSME since it appears that is what the newer projects are going with
20:37:16 <blogan> does anyone have any issues with that?
20:37:25 <sbalukoff> blogan: None from me!
20:37:35 <dougwig> i'm good with that.  pecan was announced as the new standard at the last summit
20:37:51 <sballe> blogan, What are the other OpenStack project using? I have hear a lot abut PECAN
20:37:58 <davidlenwell> blogan: I don't think that wsme pecan is a bad idea.. but I also dissagree that we should choose a technology just because "its what the other projects are doing"
20:38:06 <davidlenwell> so the merrits of each should be discussed
20:38:09 <sbalukoff> davidlenwell: +1
20:38:11 <blogan> sballe: the newer ones are using Pecan, and I believe a lot are using WSME
20:38:12 <xgerman> +1
20:38:18 <vivek-ebay> PECAN +1
20:38:20 <sballe> blogan, thx
20:38:22 <blogan> the older projects are supposed to switch to pecan
20:38:27 <TrevorV> davidlenwell, that argument is somewhat invalidated by your IRC opinion earlier ;)
20:38:38 <sballe> PECAN+1 since that is where the OpenStack tooling is going
20:38:41 <xgerman> he can change his mind :-)
20:39:17 <blogan> davidlenwell: you're correct and thats why I am bringing it up here, it is what I have chosen, but I would like people to voice their concerns about it
20:39:21 <dougwig> davidlenwell: eh, it's a rest framework, not exactly the height of innovation.  debating them tends to come to personal biases, when it's mostly six and one-half dozen.  now if we can talk about using ruby...
20:39:36 <davidlenwell> lol
20:39:37 * blogan kicks dougwig
20:39:40 <sballe> :-)
20:39:48 * davidlenwell facepalms
20:40:10 * TrevorV kicks dougwig after blogan
20:40:16 <blogan> so does anyone have any concerns about it?
20:40:19 <sbalukoff> blogan: Do you want to vote on this, or are you comfortable just going with Pecan?
20:40:28 <dougwig> trolling aside (though i do love ruby), i think there is value in standardizing on the commodity libraries.
20:40:38 <blogan> HP people I know you use pecan and possibly wsme in libra, any issues you've had that might make this a bad choice for us?
20:40:40 <xgerman> dougwig +1
20:40:40 <sbalukoff> blogan: I'm not really hearing any objections.
20:40:53 <xgerman> well, SSL was sketchy
20:41:02 <sballe> dougwig, +1
20:41:23 <blogan> xgerman: because of pecan or wsme?
20:41:37 <davidlenwell> I don't object
20:41:57 <xgerman> more because it needs to run in some app server
20:42:07 <davidlenwell> I've done apis for projects with flask, pecan .. it is largly 6 one way half a dozon the other
20:42:14 <xgerman> also the wsme syntax needs getting used to. Flask, etc. are more clear
20:42:33 <TrevorV> I'm confused, is anyone against Pecan/WSME?
20:42:38 <ctracey> +1 davidlenwell
20:42:38 <davidlenwell> no
20:42:45 <sbalukoff> TrevorV: I don't think so.
20:42:49 <blogan> xgerman: agreed and I prefer flask's but pecan isn't so bad now, its just different than flask
20:42:50 <TrevorV> Then what is the discussion covering right now?
20:42:53 <davidlenwell> I wrote the original python libra api with it for a reason
20:43:04 <johnsom> I have no issue with pecan
20:43:06 <xgerman> we are talking wsme
20:43:21 <crc32> #vote abstain
20:43:25 <sbalukoff> blogan: Anything else you want to discuss here, or would it be OK to move on to the next topic?
20:43:29 <xgerman> but I bow to what OpenStack decided
20:43:37 <TrevorV> xgerman, WSME as in pro/con WSME?  or alternatives to it?
20:43:47 <blogan> sbalukoff: I have another, but I'll add it to the end if we have time
20:43:59 <sbalukoff> blogan: Ok.
20:44:08 <blogan> sounds like no vote is needed though
20:44:12 <sbalukoff> #topic dlundquist's question about APIs
20:44:24 <blogan> already answered
20:44:28 <sbalukoff> Ok,
20:44:31 <dlundquist> I already did -- just wanted clearification on which API previous was discussing
20:44:39 <sbalukoff> #topic barclaac discussion of multiple controllers idea
20:44:46 <sbalukoff> barclaac: Go for it!
20:44:49 <blogan> single driver on controller!
20:45:04 <dlundquist> blogan: +1 as a starting point
20:45:14 <xgerman> +1
20:45:15 <sballe> blogan, +1
20:45:16 <barclaac> Right. So given we were originally talking about controllers having multiple drivers
20:45:16 <dlundquist> once we have that working we can move on
20:45:18 <sbalukoff> Agreed, as a starting point.
20:45:23 <johnsom> blogan +1
20:45:28 <barclaac> it seems to be a simplification to restrict to a single driver.
20:45:30 <blogan> dlundquist: i was more clarifying, but yes single driver only at first, until octavia is more mature
20:45:31 <crc32> #vote abstain
20:45:41 <barclaac> If you want another driver type at the same time then start a new controller
20:45:52 <rohara> blogan: +1
20:45:52 <xgerman> baclaac +1
20:46:14 <sbalukoff> barclaac: How does the user / operator API know which controller to talk to?
20:46:18 <VijayB> -1 for having to start a new controller for a new driver type
20:46:18 <dougwig> mildly dislike, but accept the initial simplification.
20:46:20 <barclaac> we'll have multiple controllers in the system anyway so this makes it much simpler but doesn't prevent multiple driver types
20:46:28 <sballe> +1
20:46:32 <VijayB> that could get restrictive
20:46:47 <rm_work> VijayB +1, not sure why that's a good ideas
20:46:49 <rm_work> *idea
20:46:57 <VijayB> neutron already supports multiple driver types doesn't it? So why do we need to limit ourselves?
20:47:06 <barclaac> We've got to look in the DB anyway to figure out which controller because not every controller knows every LB
20:47:10 <sbalukoff> barclaac: So are you proposing to use a dispatcher-like service (ie. as in the v1.0 preliminary design document) for determining which controller to talk to?
20:47:13 <xgerman> well, if you have a controller running driver A and B -- you have to restart the controller just to update driver A even if B stays the same
20:47:16 <barclaac> Right
20:47:25 <sbalukoff> Ok.
20:47:45 <rm_work> Controller is for the Amphora type (VM / Container / etc), Driver is for the Software inside the Amphora (HAProxy, nginx, etc), right?
20:47:52 <VijayB> each type can have its own implementation of the plugin_driver that will let it choose the appropriate driver
20:47:55 <dougwig> xgerman: driver changes are rare, so that's not a big deal.
20:48:05 <xgerman> I disagree
20:48:06 <dougwig> rm_work: no
20:48:16 <rm_work> dougwig: ok, maybe I need another explanation for this then
20:48:30 <rohara> we're talking about 0.5, though, right? seems like everyone agrees that this would be a simplifcation that can be address lates
20:48:31 <sbalukoff> rm_work: No
20:48:41 <barclaac> It's the 90% solution.
20:48:42 <rm_work> sbalukoff: yes, dougwig just said that. WTB clarification :P
20:48:48 <dougwig> controller (api) has driver (talks to amphora).  amphora might have a driver layer, but that's outside the scope of this discussion.
20:48:52 <barclaac> If the 10% is an issue we can go to multiple drivers later
20:49:03 <rm_work> hmm k
20:49:04 <sbalukoff> rohara: +1
20:49:07 <xgerman> I guess we should vote agian. people didn't know what they were voting for/against :-)
20:49:13 <blogan> i think the best solution is to go with a single driver right now, and explore whether the controller can handle multiple drivers easily when octavia is more mature
20:49:16 <TrevorV> +1 barclaac
20:49:17 <sbalukoff> rm_work: Sorry, catching up on reading.
20:49:23 <rohara> blogan: +1
20:49:23 <rm_work> dougwig: but the driver doesn't know whether the Amphora is a comtainer or VM right?
20:49:24 <dougwig> barclaac: i think it's the 30% solution, but i'm mildly ok with it initially because that's more than the 0% we have now.
20:49:32 <TrevorV> +1 blogan
20:49:34 <rm_work> dougwig: the controller is in charge of that?
20:49:37 <sbalukoff> blogan: +1
20:49:48 <VijayB> can someone confirm/edit this workflow: neutron-controller->neutron octavia driver -> octavia controller -> driver on amphora ?
20:49:48 <sbalukoff> dougwig: +1
20:49:50 <dougwig> the driver is the only part of the controller that knows the details of the amphora.
20:49:52 <dougwig> rm_work:
20:50:07 <rm_work> dougwig: so the *driver* is actually in charge of spinning up the Amphora?
20:50:13 <sbalukoff> VijayB: That's correct, from a high level.
20:50:13 <barclaac> VijayB you missed the dispatcher
20:50:21 <rm_work> dougwig: and ALSO in charge of configuring the software inside it?
20:50:23 <dougwig> rm_work: no.
20:50:29 <sbalukoff> barclaac: Dispatcher doesn't come into play until v1.0
20:50:31 <VijayB> barclaac: which dispatcher is this? Within neutron?
20:50:36 <rm_work> dougwig: what layer spins up the Amphora (VM / Container / etc)?
20:50:43 <sbalukoff> VijayB: It's in the 1.0 design.
20:50:54 <dougwig> rm_work: that's the controller.
20:50:56 <rm_work> ...
20:50:59 <barclaac> VijayB an additional component in sbalukoff's arch. Listen to him, not me (one time offer only ;-)
20:51:09 <rm_work> and what layer communicates with the software inside it (HAProxy, nginx, etc)?
20:51:11 <sbalukoff> VijayB: So, it doesn't really affect the v0.5 workflow per se, though it is probably where we will end up in later versions.
20:51:12 <rm_work> dougwig: ^^
20:51:15 <VijayB> sbalukoff: ok
20:51:32 <dougwig> rm_work: that's up to the driver/amp combo.
20:51:35 <rm_work> dougwig: so then that's exactly what I said in the beginning :P maybe I just didn't word it well
20:51:38 <sbalukoff> rm_work: There will be a RESTful agent on the amphora
20:51:42 <sballe> sbalukoff, +1
20:51:50 <rm_work> right
20:51:52 <VijayB> sbalukoff: so now the voting will be for how many octavia driver instances do we support in the neutron controller to talk to the octavia controller?
20:51:57 <barclaac> All I'm trying to do with the single driver approach is to simplify to make the 0.5 actually happen with a speed that doesn't get me fired.
20:52:20 <rm_work> so the Controller spins up the Amphora (as a VM / Container / etc), the Driver renders the config for the Software inside the Amphora (HAProxy, nginx, etc) and passes it to the Amphora
20:52:22 <xgerman> ok, I think we agreed on that
20:52:23 <blogan> barclaac: i think we're all in agreement to not worry about multiple drivers until after 0.5
20:52:23 <sbalukoff> VijayB: I'm hoping we don't have to vote on that just yet. I don't think the project is mature enough to need to decide that yet.
20:52:38 <sbalukoff> barclaac: +1
20:52:41 <dougwig> rm_work: yes.
20:52:43 <rm_work> ok
20:52:45 <blogan> and if after 0.5 we decide multiple drivers is not worth the hassle, we won't do it
20:52:52 <rm_work> that's exactly what I was trying to say originally
20:52:57 <rm_work> I guess my wording was just slightly off
20:53:07 <xgerman> yeah, but you voted for irc :-)
20:53:07 <rm_work> I just made it a little bit more clear :P
20:53:12 <barclaac> blogan +1
20:53:16 <johnsom> rm_work, yes, that is my understanding
20:53:18 <xgerman> blogan +1
20:53:20 <sbalukoff> Please tell me if this is incorrect:
20:53:24 <sballe> sbalukoff, Can we agree to postpone this decision until after 0.5? and do 1 driver for 0.5?
20:53:36 <rm_work> sballe: I'd vote for that :)
20:53:37 <xgerman> sballe +1
20:53:38 <sbalukoff> #agreed We will develop a single driver per controller for the v0.5 release, re-evaluate afterward.
20:53:47 <xgerman> yeah!!
20:53:51 <sballe> !!!
20:53:52 <openstack> sballe: Error: "!!" is not a valid command.
20:53:58 <barclaac> So let's vote on the 0.5 decision and that we'll revisit for 1.0
20:54:17 <dougwig> i think we have full consensus.
20:54:21 <rm_work> but... voting
20:54:22 <blogan> yes we do
20:54:24 <sballe> dougwig, I agree
20:54:29 <rm_work> we just got the voting stuff working :P
20:54:35 <sballe> ;-)
20:54:38 <sbalukoff> Ok!
20:54:40 <xgerman> yeah, it's exciting
20:54:40 * rm_work wants to #vote
20:54:42 <dougwig> when you've got a hammer...
20:54:47 <sbalukoff> Only 5 minutes left... so...
20:54:48 <barclaac> dougwig +1
20:54:55 <sbalukoff> #topic blogan's next question
20:55:02 <sbalukoff> Feel free to change that topic. ;)
20:55:23 <blogan> #topic support json only, and json format
20:55:31 <rm_work> #vote Yes
20:55:32 <blogan> topic not working
20:55:38 <sbalukoff> I think it is.
20:55:41 <sballe> sbalukoff, I have a question around hte Paris design summit sessions.Has anybody heard anythign about any deadlines/
20:55:41 <sbalukoff> Maybe?
20:55:43 <sbalukoff> I dunno.
20:55:52 <blogan> i eblieve we had an unofficial consensus before, but do we want to support xml?
20:56:00 <xgerman> no xml
20:56:07 <sballe> xgerman, +1
20:56:11 <sbalukoff> blogan: So, I think that it should be valid for someone to develop some interfaces that are not RESTful if they can justify it.
20:56:13 <blogan> ok better question, does anyone feel strongly about supporting xml?
20:56:13 <johnsom> xgerman +1
20:56:17 <ajmiller> xgerman +1
20:56:20 <sbalukoff> Like the HMAC-signed UDP health checks and whatnot.
20:56:33 <xgerman> for the operator API?
20:56:34 <barclaac> blogan: I feel strongly about not supporting xml :-)
20:56:35 <sbalukoff> But otherwise, we should default to RESTful unless deviation from that is justified.
20:56:44 <sbalukoff> And yes, XML is the devil.
20:56:46 <blogan> barclaac: i think most of us do
20:56:53 <xgerman> sbalukoff that would be up to the driver how to talk to the amphora
20:56:54 <sballe> sbalukoff, +1
20:57:02 <blogan> ok just making sure nobody really wants it
20:57:04 <blogan> also
20:57:04 <sbalukoff> xgerman: True.
20:57:06 <blogan> about json
20:57:16 <barclaac> ASN.1 ?
20:57:19 <sbalukoff> xgerman: but for the drivers we write, let's follow that standard. :)
20:57:42 <xgerman> \me likes them to be asynchronous and update the db straight
20:57:49 <sbalukoff> #agreed XML is the devil and should die in a fire.
20:57:50 <blogan> what format do most people prefer: {"load_balancer": {"name": "some load balancer"}} or {"name": "some load balancer"}
20:57:53 <dougwig> xml is a child of the 00's.
20:58:04 <rm_work> blogan: root tags?
20:58:09 <blogan> yes
20:58:16 <blogan> i dont now if that is the official name, but thats what i call them
20:58:34 <rm_work> Barbican does not use root tags
20:58:40 <rm_work> (for POSTs)
20:58:41 <dougwig> i prefer no root tags, and then adding them to batch api calls as needed (i.e., if you add a call that fetches the entire LB tree, they go in there.)
20:58:44 <rm_work> it DOES return with root tags
20:58:58 <dougwig> yuck.  it should post what it returns.
20:59:00 <blogan> rm_work: i don't like that inconsistency
20:59:08 <rm_work> it makes sense when you're using it
20:59:13 <blogan> I'm fine with either, but it should be consistent
20:59:34 <sbalukoff> Isn't root-tagging in some ways less DRY?
20:59:46 <blogan> sbalukoff: yes, bc the resource is in the url
20:59:47 <sbalukoff> I mean, don't you know it's a "loadbalancer" from the URL?
20:59:51 <dougwig> it's redundant, for sure.
20:59:52 <sbalukoff> Right.
21:00:05 <xgerman> we have one minute - ML?
21:00:05 <sbalukoff> So, no root tags. :)
21:00:11 <sbalukoff> xgerman: Yeah, ML.
21:00:16 <rohara> I like root tags, but I do not feel strongly
21:00:19 <rm_work> oh, hmm maybe it doesn't... wonder why i was getting root tags on GET before in python
21:00:20 <blogan> i still like them because pulling from the url isn't as easy as just parsing json
21:00:29 <rm_work> well, ignore me then -- Barbican uses no root tags
21:00:37 <sbalukoff> Ok, we've got to end the meeting.
21:00:40 <sbalukoff> #endmeeting