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