19:59:56 <sbalukoff> #startmeeting Octavia
19:59:57 <openstack> Meeting started Wed Nov 19 19:59:56 2014 UTC and is due to finish in 60 minutes.  The chair is sbalukoff. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:59:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:01 <openstack> The meeting name has been set to 'octavia'
20:00:03 <sbalukoff> #topic Roll Call
20:00:05 <johnsom> o/
20:00:10 <ajmiller> o/
20:00:16 <xgerman> o/
20:00:18 <bedis> o/
20:00:24 <jorgem> oi!
20:00:25 <blogan> hello!
20:00:28 <bedis> \\o
20:00:30 <bedis> o//
20:00:35 <TrevorV> o/
20:00:39 <sbalukoff> This is our agenda today: https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda
20:00:45 <sbalukoff> #link https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda
20:01:19 <sbalukoff> #topic Octavia hack-a-thon in December
20:01:29 <xgerman> will be epic!
20:01:33 <sbalukoff> So, not a whole lot to say about this except that it's the week of Dec. 15
20:01:48 <sbalukoff> If you have not yet RSVPed yet, please do here:
20:01:51 <sbalukoff> #link Octavia hack-a-thon in December
20:01:55 <sbalukoff> Dangit.
20:02:06 <sbalukoff> #link Octavia hack-a-thon in December
20:02:08 <sbalukoff> ...
20:02:10 <blogan> i can't click on that link!
20:02:20 <rm_work> o/
20:02:23 <TrevorV> technical difficulties thre sbalukoff ?
20:02:27 <jorgem> I can
20:02:36 <bedis> http://Octavia%20hack-a-thon%20in%20December/
20:02:37 <jorgem> it just doesn't do anything :)
20:02:38 <bedis> :)
20:02:53 <xgerman> https://etherpad.openstack.org/p/octavia-kilo-meetup
20:03:10 <sbalukoff> #link https://etherpad.openstack.org/p/octavia-kilo-meetup
20:03:16 <sbalukoff> Yeah, that.
20:03:24 <sbalukoff> Ok! Anyone have questions about that at this time?
20:03:42 <jorgem> yes
20:03:46 <a2hill> o/
20:03:53 <jorgem> Can we setup a video channel of some sort?
20:03:57 <sbalukoff> Yes.
20:04:06 <sbalukoff> That is part of the plan, I think.
20:04:19 <jorgem> I'm going to try and book a VC room for us here at Rackspace so the other devs can participate.
20:04:42 <ajmiller> +1 even though I'm based in the HP Seattle office, I will be out-of-town for the first two days.  Would like to participate as best I can.
20:04:46 <a2hill> i was hoping it was a google hangout that we can join/dc as needed
20:04:47 <xgerman> ok, we should be able to have some hangout going
20:04:50 <jorgem> I've also been whiteboarding with then lately and would love to contribute :)
20:05:31 <sbalukoff> Yeah, I can definitely keep a hangout going all week, eh.
20:05:38 <a2hill> Perfect!
20:05:41 <sbalukoff> Any other questions about this?
20:06:05 <sbalukoff> (I'll be working on a list of tasks to accomplish as the date draws nearer-- probably makes sense to continue what we're already doing, just in high gear, eh.)
20:06:23 <jorgem> valé
20:06:26 <sbalukoff> Ok, moving on...
20:06:31 <sbalukoff> #topic Progress reports
20:06:31 <rm_work> I think the most useful thing we could do is spend the first three days whiteboarding >_>
20:06:40 <xgerman> rm_work +1
20:06:45 <sbalukoff> I will destroy you, rm_work
20:06:52 <rm_work> sbalukoff: I am not kidding tho <_<
20:06:58 <xgerman> let's use the high bandwith event for high bandwith tasks
20:06:59 <sbalukoff> Oh, really?
20:07:05 <rm_work> destroy me with your amazing whiteboarding :P
20:07:08 <sbalukoff> Haha
20:07:09 <jorgem> sbalukoff: Careful he's ambidextrous
20:07:16 <jorgem> :)
20:07:19 <sbalukoff> #undo
20:07:20 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x1fe3490>
20:07:26 <sbalukoff> What do you want to see whiteboarded?
20:07:27 <blogan> yeah we need to whiteboard a lot
20:07:35 <rm_work> A lot of the flows
20:07:39 <TrevorV> Seriously I might agree with rm_work here, since we should focus on nitty gritty details we've glossed over
20:07:45 <jorgem> We've been whiteboarding about agent stuff mostly
20:07:46 <sbalukoff> Got it.
20:07:50 <blogan> networking frontend is a big one
20:08:02 <blogan> also backend as well
20:08:06 <rm_work> there are a lot of "oh, right, we need something to deal with that" gotchas that we forget about, unless we trace flows from start to finish
20:08:14 <sbalukoff> All right. Can y'all start a list of things you'd like to see whiteboarded at the bottom of the RSVP etherpad?
20:08:17 <xgerman> well, we also might want to split the group into multiple whiteboarders
20:08:23 <jorgem> The all mighty controller layer needs to be figured out
20:08:31 <johnsom> Yes
20:08:33 <jorgem> sure
20:08:34 <rm_work> heartbeat
20:08:50 <xgerman> not for 0.5?
20:08:52 <johnsom> I hope to have a WIP out soon
20:08:58 <rm_work> xgerman: i think we need it for 0.5
20:09:05 <blogan> sure can
20:09:09 <rm_work> it ends up being pretty central to the way the amphorae work
20:09:20 <jorgem> 0.5 is just a milestone but we should whiteboard for 1.0 and then figure out how to split it up into 0.5 and 1.0 work
20:09:22 <sbalukoff> #action Everyone here who wants flows whiteboarded should start a list of the same on RSVP etherpad.
20:09:22 <rm_work> which becomes clear when you whiteboard an amphora's lifecycle
20:10:02 <blogan> i think we shouldn't try to implement 1.0 right now but we should definitely keep 1.0 in mind in that we make it easy to implement 1.0
20:10:12 <sbalukoff> Well, yes, and I'd like to see those flows documented in the project much the same way blogan has already started with the amphora lifecycle. :)
20:10:21 <sbalukoff> But we can do that after whiteboarding them.
20:10:34 <rm_work> I think a lot of things fall into the category of "ok, this isn't THAT much more complex, and it would save us a rewrite later" bucket
20:10:47 <jorgem> yes minimal tech debt please
20:10:48 <rm_work> err, bucket was a bit redundant there
20:10:48 <blogan> yeah we need a clear concrete path on how even the small details we glossed over are going to be implemented
20:10:52 <xgerman> let's hope so
20:11:01 <sbalukoff> Ok.
20:11:22 <rm_work> I am not sure there will be a clear line between 0.5 and 1.0
20:11:25 <rm_work> in reality
20:11:28 <sbalukoff> And here I thought y'all were getting sick of seeing more design documents
20:11:46 <sbalukoff> *shrug*
20:11:56 <rm_work> well, the whiteboarding is about the conversations that happen around it :P
20:12:07 <sbalukoff> There's also no reason we can't start this early (again, referencing blogan's work on the amphora life cycle thus far)
20:12:18 <jorgem> sbalukoff: Just yours :) eh! jk
20:12:18 <sbalukoff> Heh!
20:12:31 <rm_work> anyway, I think we're in agreement, lots of whiteboarding, we can go to your next point I think :)
20:12:35 <blogan> sbalukoff: yeah the amphora lifecycle needs discussions as well as the newtorking driver interfaec, which probably needs its own design doc
20:12:48 <sbalukoff> blogan: Agreed.
20:12:51 <rm_work> blogan: put it in the etherpad :)
20:12:59 <sbalukoff> Yes, please do!
20:13:12 <jorgem> good stuff
20:13:14 <sbalukoff> Ok! Anything else about the hack-a-thon right now?
20:13:16 <blogan> ill make a new etherpad for each one
20:13:17 <blogan> j/k
20:13:27 <xgerman> please link from main etherpad though
20:14:10 <sbalukoff> #topic Progress reports
20:14:24 <sbalukoff> blogan! Please update us on the operator-api
20:14:47 <blogan> its ready for massive amounts of time from everyone to review, though i need to rebase
20:14:59 <sbalukoff> 4500 lines...
20:15:01 <rm_work> did you make those TLS updates?
20:15:04 <sbalukoff> But a lot of that is tests.
20:15:35 <blogan> rm_work: yes
20:16:04 <crc32> Any one talking or am I netsplit?
20:16:10 <rm_work> crc32: we are talking
20:16:11 <blogan> crc32: i see you
20:16:22 <sbalukoff> #action blogan to rebase, and then we need people to review: https://review.openstack.org/#/c/121233/
20:17:16 <sbalukoff> blogan: How about the network driver interface?
20:17:25 <a2hill> I progress in reverse
20:17:40 <blogan> i just started research on that this week, put up a very early WIP last night, it needs a LOT of feedback from everyone
20:17:45 <sbalukoff> a2hill: Er... what?
20:17:51 <a2hill> heh, ignore me
20:18:00 <a2hill> been on 'internal' things
20:18:06 <sbalukoff> aah.
20:18:17 <blogan> because i don't really know much about nova-networks and there's a lot of unanswered questions about neutron as well, and this all needs to work for everyone
20:18:51 <xgerman> ok, we will check it out. Link?
20:18:57 <sbalukoff> blogan: Sounds good. Do you have a review link?
20:19:11 <blogan> #link https://review.openstack.org/#/c/130352/
20:19:18 <sbalukoff> Ok, cool.
20:19:24 <blogan> shit thats' trevors reveiw
20:19:28 <TrevorV> :D
20:19:32 <crc32> +1
20:19:34 <TrevorV> PS.  Review mine too
20:19:39 <sbalukoff> Haha
20:19:41 <blogan> #link https://review.openstack.org/#/c/135495/
20:19:47 <blogan> i was wondering why it got a +1
20:20:45 <sbalukoff> Ok, on the amphora API:  Well, I just got back from vacation, so I've been playing catch-up. However, I should have a final-ish draft of the spec out in the next day or so, then davidlenwell is going to help me code it (read: He'll totally be the one doing 99% of the work on it.)
20:20:48 <sbalukoff> ;)
20:20:59 <blogan> lol
20:21:08 <davidlenwell> :)
20:21:19 <sbalukoff> Anyway, spec is here:
20:21:21 <sbalukoff> #link https://review.openstack.org/#/c/126801/
20:21:52 <sbalukoff> johnsom: Can you update us on the base-image creation stuff?
20:22:03 <johnsom> Yes.
20:22:07 <johnsom> #link https://review.openstack.org/#/c/132904
20:22:27 <johnsom> It's been out there in WIP for a few weeks and now is out for review.
20:22:33 <sbalukoff> Nice!
20:22:39 <sbalukoff> Ok, folks, we need eyes on that!
20:22:43 <xgerman> +1
20:22:46 <johnsom> I would like to discuss some of your comments sbalukoff
20:22:58 <sbalukoff> #action y'all should review https://review.openstack.org/#/c/132904
20:23:12 <johnsom> I have built and tested Ubuntu, fedora, and centos VMs.
20:23:18 <sbalukoff> johnsom: Live, or in the gerrit comment system?
20:23:45 <johnsom> There is tox that tests some stuff in the default ubuntu image using libguestfs
20:23:59 <sbalukoff> Ok, cool.
20:24:11 <johnsom> Live would be cool, but we could do so in the comments system if everyone will chime in.
20:24:40 <johnsom> I was happy to see most of your comments were about parts I borrowed from other projects.  grin
20:24:40 <sbalukoff> Let's actually see if we can get through the rest of the agenda and then hit this topic during open discussion. If we don't have time to talk then, we can continue afterward.
20:24:50 <johnsom> Sounds good
20:25:08 <sbalukoff> johnsom: Yeah, I suspected there was copy-pasta going on. Because you actually type with good grammar. ;)
20:25:09 <mwang2> is that possible that we wrap up a document which lists all of the review standards there
20:25:59 <sbalukoff> mwang2: Yes, we can totally do this. We've got a start in the HACKING.rst, but we can formalize other things as well. (like my bias against .md files. ;) )
20:26:27 <johnsom> .md files borrowed from other Openstack projects...  grin
20:26:40 <sbalukoff> Anyway, please folks, have a look at johnsom's review above, eh!
20:26:47 <mwang2> that will be great
20:26:51 <blogan> i should take a look at it today sometime
20:26:58 <xgerman> maybe sbalukoff can write some converter :-)
20:27:38 <sbalukoff> mwang2: Would you like to take an initial stab at writing that review standards doc and/or amending what we've got in HACKING.rst?
20:28:10 <sbalukoff> xgerman: Heh! Well, for the .md files in johnsom's review, the converter would be "cp"
20:28:17 <sbalukoff> Or 'mv'
20:28:30 <blogan> or rm
20:28:34 <sbalukoff> XD
20:28:40 <johnsom> I like rm
20:28:44 <xgerman> +1
20:28:53 <sbalukoff> Yeah, one-line doc files aren't all that useful, in most cases.
20:28:56 * bedis propose a match rm -f
20:29:26 <sbalukoff> Anyway, mwang2: Do you mind if I assign that review standards doc to you? I'd be happy to work with you on it.
20:30:01 <sbalukoff> (Did she disappear?)
20:30:24 <sbalukoff> Ok, let's keep going...
20:30:25 <blogan> action it, she can't decline it then!
20:30:26 <mwang2> ok
20:30:30 <sbalukoff> Haha!
20:30:46 <sbalukoff> #action mwang2 to take initial stab at review standards doc. sbalukoff to work with her on this.
20:30:49 <blogan> mwang2: if there are standards you are unsure of just list thsoe out as well
20:30:58 <mwang2> ok
20:31:08 <sbalukoff> rm_work: Can you give us an update on the TLS security stuff you've been working on?
20:31:35 <rm_work> sbalukoff: most of the initial stuff has been checked in, fixing up the Barbican impl right now
20:31:47 <sbalukoff> Great!
20:31:49 <rm_work> but still need more eyes on the main TLS architecture spec
20:31:55 <sbalukoff> Cool. Link?
20:31:58 <rm_work> specifically, eyes that have security experience
20:32:10 <rm_work> err
20:32:15 <rm_work> weeeeelll it might have merged
20:32:22 <sbalukoff> Yeah, I totally merged it.
20:32:26 <sbalukoff> I'm pretty sure.
20:32:29 <rm_work> yep :P
20:32:31 <rm_work> https://review.openstack.org/#/c/130659/
20:32:38 <rm_work> well, we can always patch it
20:32:41 <sbalukoff> What kind of feedback are you looking for?
20:32:46 <sbalukoff> Yes we can.
20:32:48 <rm_work> Just making sure I didn't miss anything
20:32:52 <rm_work> we're talking about security here
20:33:13 <xgerman> bash had holes for years... so
20:33:14 <rm_work> and this is detailing the workflow for TLS end-to-end for amphorae lifecycle and customer TLS data
20:33:15 <sbalukoff> Well, you almost certainly missed something. Otherwise it wouldn't be security, eh. ;) But I get your point.
20:33:22 <blogan> im pretty sure we'll have everything secure on the first go round
20:33:33 <rm_work> yeah, definitely. 100% unbreakable
20:33:46 <blogan> we should announce that on twitter
20:33:52 <davidlenwell> famous last words
20:33:57 <sbalukoff> Haha
20:34:04 <xgerman> that will get us some free pen tests
20:34:09 <blogan> exactly
20:34:12 <sbalukoff> Ok, so anyone with security chops people on their team should point them at that spec.
20:34:32 <davidlenwell> sbalukoff: get dustin and deva to look at it
20:34:45 <sbalukoff> #action Octavia team members with access to security people should have them look at:  https://review.openstack.org/#/c/130659/
20:34:53 <sbalukoff> davidlenwell: I will.
20:35:28 <sbalukoff> Ok! amiller and / or TrevorV: update on the compute driver interface?
20:35:42 <TrevorV> I've got a few reviews up and waiting for some vision on them
20:35:49 <sbalukoff> Great!
20:35:53 <sbalukoff> Please hit us with the links.
20:35:53 <blogan> it'd be almost done if would catch everything on the first pass
20:35:58 <TrevorV> I got some great feedback from sbalukoff and blogan just yesterday and am currently making changes to one of them
20:35:58 <blogan> if i
20:36:09 <TrevorV> I'm actually about to push a change
20:36:11 <blogan> "great feedback" eh
20:36:12 <TrevorV> Let me link them really quick
20:36:16 <sbalukoff> Haha!
20:36:27 <TrevorV> #link https://review.openstack.org/#/c/130352
20:36:34 <TrevorV> #link https://review.openstack.org/#/c/130640
20:36:42 <TrevorV> #link https://review.openstack.org/#/c/133108
20:36:52 <ajmiller> As far as I am aware, my part of the spec is done.  TrevorV and I have had discussions about what should be defined where, and we think we have that worked out.
20:36:53 <TrevorV> Conveniently they are dependency chained together
20:37:02 <TrevorV> +1 ajmiller
20:37:16 <sbalukoff> Excellent, eh!
20:37:25 <sbalukoff> #action eyes on the above review links
20:37:42 <sbalukoff> Let's see...
20:37:46 <blogan> does anyone think that OCtavia will need to get amphorae by name?
20:38:03 <blogan> if you do, then go comment on the review
20:38:06 <sbalukoff> *crickets*
20:38:13 <a2hill> it is a convenient way for a user to query for it
20:38:21 <a2hill> uuid is hard to remember
20:38:27 <sbalukoff> a2hill: But... will a user ever actually being querying for it?
20:38:28 <TrevorV> a2hill they user isn't ever going to know about an "amphora" though
20:38:35 <TrevorV> the**
20:38:42 <sbalukoff> hostnames are going to be auto-generated too, eh.
20:38:54 <johnsom> Right, I *hope* the user has no concept of amphora
20:38:58 <sbalukoff> Yep.
20:39:06 <sbalukoff> Only the operator can see behind the curtain.
20:39:12 <sbalukoff> (Or at least, that's how it should be.)
20:39:14 <xgerman> well, there is always the operator side of it
20:39:19 <a2hill> i suppose not, that was cleared up
20:39:36 <a2hill> bait car!
20:39:50 <TrevorV> xgerman the operator wouldn't have need of a name either, since everything should be known by the operator, right?
20:39:51 <sbalukoff> xgerman: blogan's point was that we'll always know the UUID whenever we know the name.
20:40:03 <sbalukoff> TrevorV: That was my thought too.
20:40:13 <TrevorV> I hope the operator would have full insight ha ha
20:40:23 <xgerman> you would hope...
20:40:24 <sbalukoff> Anyway, if you think we'll need to look up by name, please read through and comment on the review!
20:40:32 <sbalukoff> Ok!
20:40:38 <sbalukoff> So, controller update!
20:40:46 <johnsom> We don't want to name our amphora because we don't want to get too attached to them....  grin
20:40:51 <sbalukoff> johnsom: Are you working on this already (blueprint is assigned to you)
20:40:56 <johnsom> Yes
20:41:04 <sbalukoff> Ok, cool, can you give us an update?
20:41:04 <blogan> queue rm_work's "they're cattle"
20:41:19 <rm_work> technically dougwig coined that
20:41:26 <xgerman> lol
20:41:27 <johnsom> I have started working on it, but stopped to address the burning need with the base-image.  I am back on it now
20:41:29 <sbalukoff> amphorae are so cattle.
20:41:37 <blogan> rm_work: technically there were many sessions on it at the summit
20:41:39 <johnsom> Hope to have some WIP stuff posted soon
20:41:45 <sbalukoff> johnsom: Excellent!
20:41:46 <rm_work> ah
20:41:54 <a2hill> Yea, a few were actually titled that
20:42:08 <blogan> johnsom: is there a spec out or is that what you're working on?
20:42:14 <rm_work> johnsom: you are working on "the controller"?
20:42:35 <johnsom> I am working on "the controller spec"
20:42:40 <rm_work> we were doing a lot of controller-related whiteboarding here yesterday, and it's looking like whatever we are calling "the controller" is really just a collection of agents
20:42:40 <blogan> excellent
20:42:58 <johnsom> Yes, which aligns with my thinking too
20:43:12 <rm_work> this is the #1 thing we'll need to whiteboard I think
20:43:18 <xgerman> agreed
20:43:20 <johnsom> Agreed
20:43:21 <blogan> #1a
20:43:24 <rm_work> I wouldn't expect that spec to be finalized before the meetup
20:43:31 <blogan> #1b is networking
20:43:37 <rm_work> well, I think most of the other stuff on the list falls out of the controller discussion
20:43:38 <sbalukoff> Heh!
20:43:40 <johnsom> Hahaha, funny man.  I expect a lot of discussion
20:43:45 <xgerman> yeah, if you guys have whiteboards I am wondering if you cna take pictures and forward
20:44:07 <rm_work> the HP offices have LOTS of whiteboards, right?
20:44:13 <sbalukoff> Ok, so: johnsom, it would be great if you could commit a WIP review as soon as you're able, with the understanding it'll probably take several weeks and at least one good whiteboarding session at the hack-a-thon to finalize it.
20:44:19 <rm_work> We will need approximale 1000 sqft of whiteboard
20:44:23 <rm_work> *approximately
20:44:28 <xgerman> we have ways to erase whiteboards
20:44:33 <johnsom> Yes, that is the plan
20:44:44 <blogan> we will also need some boxing gloves
20:44:48 <sbalukoff> Sweet.
20:44:53 <rm_work> xgerman: erase whiteboards? blasphemy
20:45:07 <sbalukoff> Haha
20:45:09 <sbalukoff> Ok!
20:45:11 <sbalukoff> moving on...
20:45:14 <sbalukoff> #topic Other reviews Needing Attention ( https://review.openstack.org/#/q/stackforge/octavia+status:open,n,z )
20:45:31 <sbalukoff> Does anyone else here want to point out a review that's not yet been mentioned that needs eyes?
20:45:34 <rm_work> the Barbican impl is up now
20:45:37 <blogan> spare amphora lifecycle management
20:45:40 <blogan> #link https://review.openstack.org/#/c/130424/
20:45:47 <blogan> don't think that actually got a call out to reveiw
20:45:50 <rm_work> #link https://review.openstack.org/#/c/132580/
20:46:00 <rm_work> just fixed the merge conflict, should be good now
20:46:04 <sbalukoff> Nice!
20:46:30 <sbalukoff> It's great to see all the progress on this, y'all!
20:46:43 <sbalukoff> Feel like we've got good momentum going, so let's keep at it, eh!
20:47:05 <sbalukoff> Any other reviews needing attention?
20:47:59 <sbalukoff> #topic Open Discussion
20:48:20 <sbalukoff> johnsom: Ok, let's talk about the base-image review
20:49:04 <johnsom> Cool.  So, your comment about dropping the RedHat tribe... Fedora and CentOS where in the spec and we get most of that free from upstream.
20:49:22 <sbalukoff> Ok, that's fine. Do we have a way to test the code via CI?
20:49:23 <johnsom> I would like to keep them as options, but make it clear they are experimental.
20:49:50 <johnsom> Yeah, we could enable the tox to also build and look at those if we feel the need
20:49:56 <sbalukoff> I'm OK with that, I suppose, though I'd be happier if they weren't experimental (and testable via CI).
20:50:02 <sbalukoff> Right.
20:50:23 <xgerman> well, I would assume rohara would have enough interest in those OS
20:50:33 <sbalukoff> I honestly don't expect many people to use an amphora image other than the one  that is under primary support.
20:50:40 <sbalukoff> Unless they happen to work for RedHat or something. XD
20:50:42 <johnsom> I can add them to the tox if you would like.  It will just make it take three times as long
20:51:01 <johnsom> Or we can do that later...
20:51:08 <xgerman> I am for later
20:51:15 <sbalukoff> Let's worry about it later.
20:51:24 <johnsom> Excellent answer
20:51:25 <johnsom> grin
20:51:58 * rm_work kicks the rock down the road a bit
20:51:59 <johnsom> Next up, the init scripts.  I put them in to have something that supports reboots, etc.
20:52:30 <johnsom> I expected that when the code lands that manages all of those haproxy instances would update/remove
20:52:32 <sbalukoff> Right, let's not do them for now. The scripts davidlenwell and I will be writing will control the haproxy instances, including after reboot.
20:52:56 <sbalukoff> Let's not even put the init scripts in there right now. They're not going to be useful at all. :/
20:53:04 <davidlenwell> agreed
20:53:09 <johnsom> Ok, so, remove them from the commit or disable?
20:53:21 <sbalukoff> Remove them.
20:53:34 <davidlenwell> +1
20:53:57 <johnsom> Ok.  The upstart I wrote has respawn working for haproxy.  You might want to borrow that for your scripts, etc.
20:54:18 <sbalukoff> Thanks for the heads up!
20:54:56 <sbalukoff> Anything else you'd like to discuss about this review live?
20:55:02 <johnsom> README.md these came from another project.  Nuke 'em, or do you really want me to convert those?  I pulled them forward because they seemed to still apply
20:55:26 <sbalukoff> So, if we're going to have document files at all, I want them to be .rst.
20:55:30 <johnsom> Same thing with the nonlocal_bind, that came from the upstream tripleo haproxy configs.
20:55:36 <sbalukoff> And if the documentation in there is still useful, let's convert them.
20:55:49 <sbalukoff> But they are only 1 line (of poorly written English)
20:55:56 <sbalukoff> So I'm not sure they're actually useful.
20:55:59 <xgerman> did we ever vote on rst vs. md
20:56:02 <xgerman> ?
20:56:06 <johnsom> Agreed, they do not have good grammar
20:56:25 <blogan> that was your grammar don't lie
20:56:34 <sbalukoff> xgerman: I'd rather just use one standard, and everything else with more complication is using .rst in this project.
20:56:39 <sbalukoff> So, let's just keep going with .rst
20:56:44 <johnsom> Haha, go look at that sahara project files.... grin
20:56:48 <sbalukoff> I don't see a compelling reason to support .md
20:56:48 <blogan> lol
20:57:05 <xgerman> well, I don't liek converting for the sake of converting
20:57:30 <johnsom> Yeah, it seems like every project has a mix in OpenStack land
20:57:31 <sbalukoff> Sure, but we're talking about 3 1-line files which will probably be removed anyway.
20:57:42 <sbalukoff> Let's not do that. XD
20:58:14 <blogan> we need to make an Openstack Document Format Working Group
20:58:22 <xgerman> +1
20:58:39 <sbalukoff> blogan: I'm willing to bet there already is one, probably in the docs project, but I'll bet they get ignored a lot.
20:58:50 <xgerman> we can state a strong preference but I don't want to force people borrowing stuff to convert every change the donating project does
20:58:59 <sbalukoff> (Especially if in some projects "the code is the documentation" is the prevailing attitude.)
20:59:13 <sbalukoff> xgerman: I'm OK with that.
20:59:25 <sbalukoff> But realize I'm probably going to complain whenever I see a .md file.
20:59:30 <sbalukoff> :)
20:59:36 <sbalukoff> Ok! 20 seconds left!
20:59:55 <sbalukoff> #endmeeting