20:00:29 <sbalukoff> #startmeeting Octavia
20:00:32 <openstack> Meeting started Wed Dec  3 20:00:29 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:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:33 <xgerman> o/
20:00:35 <sbalukoff> #topic Roll Call
20:00:35 <TrevorV_> o/
20:00:35 <openstack> The meeting name has been set to 'octavia'
20:00:36 <rm_work> o/
20:00:39 <rohara> o/
20:00:40 <johnsom> o/
20:00:40 <blogan> hi
20:00:41 <xgerman> o/
20:00:45 <ajmiller> o/
20:00:48 <sbalukoff> Howdy folks!
20:00:48 <blogan> \o/
20:00:53 <rm_work> Well hello there!
20:01:19 <jwarendt> Hi
20:01:23 <sbalukoff> This is our agenda for today: https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Agenda
20:01:39 <sbalukoff> #topic Quick "Octavia" trademark update
20:02:02 <sbalukoff> #link: http://tsdr.uspto.gov/#caseNumber=86319369&caseType=SERIAL_NO&searchType=statusSearch
20:02:28 <xgerman> so we now can oppose :-)
20:02:30 <jamiem> o/
20:02:31 <sbalukoff> So that came in yesterday. Apparently it's now published on the USPTO's publications that they intend to grant the trademark.
20:02:49 <blogan> awesome
20:02:53 <xgerman> +1
20:03:01 <rm_work> Octavia is one of the stylist's names in The Hunger Games :P
20:03:06 <sbalukoff> And anyone who objects has 11 weeks to register their objection (and explain why granting the trademark would damage them.
20:03:07 <rm_work> noticed that this weekendf
20:03:17 <blogan> im objecting
20:03:22 <xgerman> me, too
20:03:24 <sbalukoff> After 11 weeks, if there aren't objections (or sufficiently justified objections), the trademark gets granted.
20:03:39 <rm_work> cool, so, by Kilo right? :)
20:03:45 <sbalukoff> Basically, yes.
20:04:08 <sbalukoff> Again, assuming nobody goes through the legal paperwork / filing fees to seriously object.
20:04:35 <sbalukoff> So, anyway, I just wanted to keep you updated on the latest developments there.
20:04:39 <sbalukoff> #topic Octavia hack-a-thon in December
20:04:53 <xgerman> this will be epic
20:04:55 <sbalukoff> #link https://etherpad.openstack.org/p/octavia-kilo-meetup
20:05:02 <sbalukoff> Yes, I hope so!
20:05:09 <sbalukoff> I hope it's a really productive week for all of us, eh!
20:05:10 <rm_work> such whiteboarding
20:05:11 <rm_work> so collaboration
20:05:11 <rm_work> wow
20:05:15 <sbalukoff> Haha
20:05:30 <sbalukoff> As a reminder, please RSVP if you intend on coming so that HP can accommodate all of us.
20:05:50 <TrevorV_> I'll go if HP pays for my room/board/travel :P
20:05:55 <sbalukoff> Also, as a reminder, if there are additional specific topics you'd like to see a whiteboarding / design session on, please list them at the end of that document.
20:06:04 <rohara> RSVP is just putting name on the etherpad?
20:06:08 <barclaac> Correct
20:06:09 <xgerman> yep
20:06:09 <sbalukoff> rohara: Yes.
20:06:11 <rohara> ack
20:06:59 <blogan> i know we can mix neutron lbaas and octavia subjects, but the agenda has a discussion point being about lbaas object sharing
20:07:06 <sbalukoff> So that's about 2 weeks away. I'm thinking there's time in the mean time to get some of the discussions underway on the mailing list or what have you so we can hit the ground running at the hack-a-thon
20:07:08 <blogan> isn't that neutron lbaas?
20:07:16 <blogan> or are we looking to do something similar in octavia as well?
20:07:23 <sbalukoff> blogan: It is, but it does affect Octavia of course.
20:08:01 <sbalukoff> As long as Octavia is using Neutron LBaaS as its user API front-end (ie. indefinitely, per the current plan), discussions of how that interface works do affect us.
20:08:19 <sbalukoff> Not to mention the fact that both groups share about 90% of the same people. :)
20:08:30 <blogan> well that is somethign we will discuss there as well
20:08:55 <sbalukoff> So, I think it's a good idea to actually have a mailing list discussion about status information, since that directly impacts the object model sharing, which directly impacts how the API works for the user.
20:09:08 <sbalukoff> I can get that started if y'all like.
20:09:13 <blogan> actually
20:09:20 <sbalukoff> Unless y'all think it would be a bad idea to get that going now.
20:09:23 <xgerman> I think it doesn't matter to the user where status is tored
20:09:33 <xgerman> stored
20:09:33 <blogan> we can discuss on this bp
20:09:35 <blogan> https://review.openstack.org/#/c/138205/
20:09:47 <blogan> nothing about sharing there, but its the repoposed lbaas v2 spec for kilo
20:10:08 <sbalukoff> blogan: Ok, sounds good.
20:10:13 <xgerman> +1
20:10:29 <jorgem> sbalukoff: can you send the agenda link again? sorry just joined. I just want to add some items
20:10:36 <sbalukoff> xgerman: It's not about where or how status is stored, it's about how it's represented to the user.
20:10:41 <blogan> and i did make some changes, but if we wanted to do sharing like sam suggested, we would need to make that decision sooner rather than later
20:10:49 <sbalukoff> jorgem: https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Agenda
20:11:04 <sbalukoff> blogan: Sounds good.
20:11:08 <xgerman> sam explicitly talked about storing...
20:11:31 <sbalukoff> #action everyone participate in LBaaSv2 object model discussion here: https://review.openstack.org/#/c/138205/
20:11:46 <sbalukoff> xgerman: I don't think he understood what I was getting at either.
20:12:03 <sbalukoff> (And that may be because I wasn't clear in what I was saying.)
20:12:25 <xgerman> +1
20:12:30 <sbalukoff> Anyway, are there any other discussions we should "prime" prior to the hack-a-thon?
20:12:59 <sbalukoff> Mostly, I want to make sure the face-to-face time we have is used as effectively as possible.
20:13:33 <sbalukoff> And it can be useful to test the waters a bit, as it were, before having a face-to-face discussion.
20:14:03 <blogan> the controller being split up into smaller stories would be a good one
20:14:13 <sbalukoff> I agree!
20:14:16 <blogan> but that is dependent on a larger conversation that will be best had at the hackathon
20:14:26 <sbalukoff> I'd love to see something about the discussions y'all apparently have been having at rackspace
20:14:34 <blogan> but we can start the controller monolithic story up in the ML
20:14:46 <blogan> discussions on how to overthrow you?
20:14:51 <sbalukoff> blogan: Do you have time to get that going?
20:15:01 <johnsom> The initial direction for the controller is up for WIP review.....
20:15:03 <sbalukoff> (both of those? )
20:15:06 <sbalukoff> ;)
20:15:16 <TrevorV_> johnsom, link here please?
20:15:21 <sbalukoff> Ok, so let's have the discussion in gerrit then?
20:15:21 <blogan> yeah we will try to get somethign out by the end of the week on teh ML
20:15:31 <sbalukoff> blogan: Thanks
20:15:46 <blogan> well gerrit and resort to ML if it requires a huge writeup
20:15:48 <johnsom> #link https://review.openstack.org/136540
20:15:56 <sbalukoff> #action Rackspace team to get something out on the mailing list about whiteboard discussions they've been having / monolithic controller discussion
20:16:10 <johnsom> Posted back on the 22nd
20:16:38 <sballe> hey
20:16:40 <sbalukoff> johnsom: I'll take a look today or tomorrow. Thanks for posting that!
20:16:52 <TrevorV_> yeah thanks johnsom
20:16:54 <sbalukoff> Ok...  moving on.
20:17:04 <sbalukoff> #topic Progress reports
20:17:14 <rm_work> yeah looks kinda similar to what we were talking about here, though our discussions have been more about HOW the communications happen
20:17:17 <rm_work> more than "what are the communication lines"
20:17:46 <sbalukoff> operator-api:  Update from blogan / TrevorV?
20:17:57 <TrevorV_> I've added the controller spec to the prioritized reviews page for johnsom
20:18:12 <sbalukoff> Nice!
20:18:14 <blogan> well i can respond to your comment
20:18:15 <blogan> right now
20:18:23 <blogan> in taht decimal versions don't make sense
20:18:23 <sbalukoff> Uh-oh.
20:18:29 <sbalukoff> Why is that?
20:18:32 <johnsom> It was already on there....
20:18:49 <johnsom> The line above your new one...  Grin
20:18:56 <blogan> i know, thats something we'll need to fix
20:18:57 <sbalukoff> Other APIs using versioning in OpenStack are using decimals.
20:18:57 <TrevorV_> Lulz
20:19:03 <TrevorV_> I'm observant, can you tell?
20:19:15 <blogan> but they never use the minor version, at least as far as i can tell
20:19:38 <sbalukoff> xgerman: What are your thoughts on this?
20:19:52 <sballe> I think we should do the decimal versions.
20:19:58 <xgerman> +1
20:20:01 <TrevorV_> Oh good, you guys are talking about some stuff I was going to bring up ha ha
20:20:05 <sbalukoff> sballe: Why?
20:20:17 <sballe> It makes the versioning consistent across the various services.
20:20:30 <sbalukoff> I don't want to rat-hole on this too far... but if it's something we can resolve quickly, let's do so.
20:20:34 <sballe> I am looking ofr a specific example
20:20:34 <xgerman> we had some discussion where we said we will only increase majore version in the API
20:20:35 <blogan> neutron doesnt have a decimal
20:20:41 <sbalukoff> If we can't resolve this quickly, lets do it in comments on the gerrit review.
20:20:50 <xgerman> neutron has LBaaS v1 in Beutron V2
20:21:02 <sbalukoff> blogan: I thought v2.0 would?
20:21:44 <rm_work> I thought other services were moving away from decimals, but maybe not now, since nova stopped work on v3 and went to v2.1
20:21:45 <rm_work> >_>\
20:21:59 <blogan> ok this will be a rathole
20:21:59 <sbalukoff> Heh!
20:22:01 <blogan> lol
20:22:03 <blogan> lets do gerrit
20:22:04 <xgerman> yeah, abandoning decimals seems premature
20:22:12 <sbalukoff> Ok, let's do it in gerrit.
20:22:20 <rm_work> OH
20:22:21 <sballe> xgerman +1
20:22:25 <rm_work> i remembered why i didn't like decimals
20:22:29 <blogan> plus i have to restart my brain to remember the good reasons i had
20:22:38 <xgerman> rm_work do you like math in general?
20:22:53 * TrevorV_ likes math
20:23:04 <rm_work> because anything inside a major version should be backwards compatible, and we can SHOW the decimal versions, but it should never be part of a URL
20:23:04 <rm_work> xgerman: i hate math in general :P
20:23:11 <sbalukoff> #action Interested parties should have discussion over whether to have decimal version numbers for the api on the gerrit review for the same.
20:23:22 <rm_work> so our URL should always be whatever.com/lbaas/v2/loadbalancer/124325456
20:23:32 <sbalukoff> rm_work: Take it to gerrit, please
20:23:37 <rm_work> but our version could come back in the header as v2.1.34
20:23:37 <sbalukoff> Ok!
20:23:39 <TrevorV_> sbalukoff, real quick, should that be on the documentation review or the actual operator API review?
20:23:40 <rm_work> lol fine
20:23:53 <rm_work> sbalukoff: spoilsport >_<
20:24:08 <sbalukoff> TrevorV_: Aah, good question. I think the discussion is already happening on the Operator API review
20:24:17 <blogan> yes do it on that review
20:24:22 <TrevorV_> Alright
20:24:36 <blogan> i should have responded with the reasons we came up with in IRC, but i am a jack ass
20:24:49 <sbalukoff> This one: https://review.openstack.org/#/c/121233/
20:24:49 * TrevorV_ does not dispute
20:24:53 <sbalukoff> Haha!
20:25:02 <TrevorV_> #link https://review.openstack.org/#/c/121233/
20:25:20 <sbalukoff> Ok, progress report on the amphora-api:
20:25:52 <sbalukoff> I need some more eyes on the review: https://review.openstack.org/#/c/126801/
20:26:01 <sbalukoff> Also, I need rm_work to respond to my response to him. ;)
20:26:11 <rm_work> ack
20:26:43 <sbalukoff> It's been a hectic week, and I have not had heard back from davidlenwell about code progress there yet (he's remote, and text is our primary means of communication)
20:26:43 <sbalukoff> So... not much progress there.
20:26:45 <sballe> could somebody remind me where the etherpad with all the reviews is?
20:27:00 <TrevorV_> #link https://review.openstack.org/#/c/126801/
20:27:13 <sbalukoff> sballe: It's not been updated in a while
20:27:25 <sbalukoff> I typically work off this: https://review.openstack.org/#/q/stackforge/octavia+status:open,n,z
20:27:25 <TrevorV_> sbalukoff, I update it often
20:27:32 <TrevorV_> Just not sure on priority for reviews mostly
20:27:38 <blogan> i work off that too sbalukoff
20:27:40 <sbalukoff> Oh? Ok.
20:27:40 <johnsom> #link https://etherpad.openstack.org/p/octavia-pending-reviews
20:28:07 <sbalukoff> johnsom: Can you give us an update on the amphora base image creation scripts?
20:28:20 <johnsom> Yes, we need reviews!
20:28:50 <sbalukoff> That's probably going to be a theme here.
20:28:51 <johnsom> I'm not a fan of adding versions to sub-components like the build script.
20:29:07 <TrevorV_> sbalukoff, trending eh?
20:29:10 <sbalukoff> #action We need people to do reviews. No seriously, we do.
20:29:12 <johnsom> I also added a comment about the haproxy.conf template place holder in the notes.
20:29:19 <blogan> people still recovering from thanksgiving
20:29:37 <johnsom> Other than that.  Nothing more to report.  Just needs reviews and +2s
20:29:40 <sbalukoff> blogan: Agreed.
20:29:50 <sbalukoff> johnsom: Sounds good. Thanks!
20:30:29 <rm_work> yeah, recovering from Thanksgiving and Yosemite
20:30:30 <sbalukoff> Ok, update on compute driver interface.  amiller and TrevorV?
20:30:30 <rm_work> stupid Yosemite...
20:30:49 <TrevorV_> Oh crap
20:30:54 <blogan> let me guess : reviews
20:31:05 <sbalukoff> blogan +1
20:31:09 <ajmiller> as far as I am aware, by review is done and merged.
20:31:10 <TrevorV_> Yeah, in this case though I also have some questions to have answered
20:31:16 <TrevorV_> ajmiller, is correct
20:31:29 <xgerman> he always is :-)
20:31:33 <ajmiller> I wish
20:31:38 <sbalukoff> TrevorV_: Are they brief, or should we answer them elsewhere?
20:31:52 <TrevorV_> sbalukoff, I responded in the review with my concerns for the management_network
20:31:56 <TrevorV_> I feel they aren't brief ha ha
20:32:05 <sbalukoff> Yeah, that's definitely not a brief discussion.
20:32:11 <TrevorV_> (They may turn out to be, but the unknown is best to assume the worst)
20:32:13 <blogan> oh yeah i need more explanation on that one sbalukoff
20:32:21 <xgerman> I am wondering if we can sidestep it for the sake of having that merged
20:32:25 <sbalukoff> Ok, I think in order to have that discussion, we need a better understanding of topologies.
20:32:28 <blogan> ive been assuming its only the network used for controller and amphorae communication
20:32:33 <sbalukoff> Which may not happen before the hack-a-thon
20:32:53 <TrevorV_> blogan, sbalukoff, xgerman we can talk more during open discussion after the main topics are covered
20:33:01 <sbalukoff> I would like to see the spec merged with the idea that it can always be modified based on later discussion.
20:33:02 <xgerman> k, sound sgood
20:33:04 <blogan> fine by me
20:33:06 <sbalukoff> Nothing we do here is immutable, eh!
20:33:21 <TrevorV_> +1 sbalukoff I have no problems with that thought process either
20:33:21 <blogan> sbalukoff: i hope everyone understands thats the case with every spec
20:33:35 <sbalukoff> blogan: Me too!
20:33:57 <sbalukoff> Again, I'd rather not block the ability to get useful work done in the mean time as we figure out some of the larger issues.
20:34:06 <xgerman> +1
20:34:17 <sbalukoff> And to me that means it should be OK to merge specs that leave some things as "To be determined"
20:34:31 <TrevorV_> Least amount of ambiguity as the focus, eh?
20:34:35 <sballe> sbalukoff: +1
20:34:37 <blogan> the spec not beign merged doesn't prevent anyone from working on the implementation, and the spec being merged doesn't mean it won't change
20:34:39 <sbalukoff> TrevorV_: Yes
20:34:49 <sbalukoff> blogan: +1
20:35:04 <blogan> so either way it shouldnt block
20:35:19 <sbalukoff> blogan: Nevertheless, I sense that there is a mental block there-- people are less likely to work earnestly on implementation when the spec isn't' merged yet.
20:35:34 <blogan> oh i know, its the checklist mentality
20:35:36 <sbalukoff> blogan: I agree, I'm just sharing my observation.
20:35:48 <TrevorV_> sbalukoff, I was dependent on a spec, an impl, and then another spec... didn't stop me ha ha ha
20:36:11 <sbalukoff> Ok, the last status update I have is on the controller-- and we've already talked a little bit about that, and I think we all know this is up for a major discussion
20:36:17 <sbalukoff> both prior to and at the hack-a-thon.
20:36:23 <blogan> indeed
20:36:36 <TrevorV_> agreed
20:36:36 <sballe> sbalukoff: I have time between now and the face 2 face to work on a spec. I like to volunteer to work on https://blueprints.launchpad.net/octavia/+spec/amphorae-scheduler spec.
20:36:41 <sbalukoff> And again, I look forward to seeing something of a summary of the whiteboard discussions y'all at Rackspace have been having about this. :)
20:36:51 <sbalukoff> sballe: Go for it!
20:37:02 <blogan> you sound like you really want details
20:37:04 <sballe> I couldn;t assign it to myslef
20:37:08 <sbalukoff> Ok, are there any other progress reports I'm forgetting about?
20:37:20 <blogan> network driver spec
20:37:21 <blogan> https://review.openstack.org/#/c/135495/
20:37:27 <xgerman> sballe I think I can assign
20:37:31 <sbalukoff> sballe: Aah, ok.
20:37:34 <blogan> this is one that will definitely change as we get further along
20:37:47 <sbalukoff> #action sbalukoff to assign https://blueprints.launchpad.net/octavia/+spec/amphorae-scheduler to sballe
20:38:00 <blogan> but i think it is generic enough now to suit our needs
20:38:02 <sbalukoff> blogan: Agreed.
20:38:12 <sbalukoff> So.... need reviews, right?
20:38:20 <TrevorV_> The more info we can hash out before the hackathon the better though, so eyes on that review would be great
20:38:26 <blogan> no just 2 +2s and a +A
20:38:33 <sbalukoff> TrevorV_: +1
20:38:45 <sballe> blogan: understood. I want to make sure we use the right technologies for the affinity/anit-affnity so I am talking to our nova guys on the best way forward,
20:38:51 <TrevorV_> I also have the review for the Operator API documentation that's still really lean.  Any help there would be great
20:39:08 <sballe> Please I wrote a lot of the slurm scheduler so I feel I should be at home here
20:39:08 <sbalukoff> blogan: Ok, I'll have a look.
20:39:11 <TrevorV_> #link https://review.openstack.org/#/c/136499/
20:39:21 <xgerman> sballe it's yours
20:39:30 <sballe> xgerman: thx
20:39:38 <blogan> sballe: okay, that definitely affinity and anti-affinity definitely need attention
20:39:57 <sbalukoff> TrevorV_: I will happily dole out more berating comments on that if you'd like. ;)
20:40:07 <TrevorV_> sbalukoff, that'll be welcome for the most part :D
20:40:08 <sbalukoff> Seriously, though, it's a good start. :D
20:40:38 <TrevorV_> I feel like I could have more description about stuff, and if anyone does want me to do a glossary or something, please let me know, because I may not have a full definition in mind when making it
20:40:40 <sbalukoff> And yes, to the rest of y'all:  Please do review TrevorV_'s spec!
20:40:42 <TrevorV_> So I'll have questions and such there too
20:41:02 <blogan> meeting TL;DR - all review everything!
20:41:14 * TrevorV_ working on reviewing all the things!
20:41:17 <sbalukoff> TrevorV_: We should discuss this afterward, but I do want to know if you're following a specific template in that. I followed a template I pulled out of my ass for the amphora API spec.
20:41:28 <sbalukoff> blogan: Indeed!
20:41:37 <sbalukoff> #action review all the things!
20:41:49 <sbalukoff> Ok!
20:41:50 <TrevorV_> sbalukoff, simple answer, I followed glance's API docs.  Not intimately followed, but I used it as a starting point
20:41:58 <sbalukoff> Ok.
20:42:01 <blogan> we really need to look at JSONHome and JsonSchema for doc generation, per the apiwg
20:42:12 <sbalukoff> I would like to see a little more detail than what you've got so far. ;)
20:42:14 <TrevorV_> blogan, I might be able to spend some cycles on that
20:42:23 <TrevorV_> sbalukoff, Agreed
20:42:27 <blogan> TrevorV_: go for it pelase
20:42:47 <sbalukoff> blogan: +1
20:42:47 <sbalukoff> Ok!
20:43:01 <sbalukoff> jorgem: Did you have something you wanted added to the agenda, because the next thing on the list is open discussion
20:43:09 <jorgem> Sure
20:43:26 <jorgem> Just wanted to make sure we keep in mind versioning in Octavia
20:43:28 <sbalukoff> #topic jorgem's agend item(s)
20:43:35 <sbalukoff> #undo
20:43:36 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x3db0e10>
20:43:39 <jorgem> Not sure how it will fit in to Neutron as well as octavia
20:43:41 <TrevorV_> sbalukoff, action me for checking into JsonSchema/JSONHome
20:43:44 <sbalukoff> #topic jorgem's agenda item(s)
20:44:02 <sballe> lol
20:44:09 <sbalukoff> #action TrevorV_ to look into JSONSchema / JSONHome
20:44:12 <xgerman> versioning = good
20:44:15 <jorgem> It was brought up today and I'm not sure if it warrants a discussion
20:44:27 <jorgem> API versioning is what I'm referring to to be explicit
20:44:44 <blogan> we need to also look into what nova and neutron are donig with microversionig
20:44:47 <blogan> ng
20:44:51 <jorgem> But I'd like the ability to deprecate and run multiple API versions at the same time in order to transition customers
20:44:53 <xgerman> blogan +1
20:44:56 <sbalukoff> jorgem: So the plan was to have this discussion on the operator api gerrit review, where it's already started
20:45:04 <jorgem> sweet
20:45:05 <sballe> and I am assuming the API group will come out with a best practice
20:45:19 <xgerman> and we have the same operator requirement at HP
20:45:23 <sballe> we should touch base with jay
20:45:28 <sbalukoff> sballe: Sure, but let's not hold our breath there.
20:45:34 <jorgem> Other things to worry about that are slightly related are migrations (up AND down)
20:45:49 <blogan> which alembic does
20:45:59 <jorgem> It is my understanding that most Openstack projects only migrate UP and not down
20:45:59 <xgerman> well, I would be happy if UP worked flawlessly :-)
20:46:07 <sbalukoff> Haha
20:46:17 <blogan> well the migrations do have the ability to mgirate down
20:46:19 <sballe> xgerman: +1 yeah no kidding!
20:46:20 <TrevorV_> xgerman, so far alembic seems to work flawlessly (knocks on wood)
20:46:29 <jorgem> just want to make sure we keep those things in the back of our minds when having design discussions
20:46:38 <sbalukoff> jorgem: It's my impression that a "down" migration only happens when there's a serious problem with a new version that isn't discovered until an upgrade is attempted.
20:46:40 <jorgem> no need to go into details now
20:46:41 <jorgem> :)
20:46:47 <sbalukoff> But yes, our migrations should be able to go both ways.
20:46:47 <jorgem> correct
20:47:00 * TrevorV_ chuckles at "go both ways"
20:47:10 <sballe> when we say migration are we talking about update and rollback?
20:47:14 <jorgem> yes
20:47:34 <sbalukoff> jorgem: Do you want to update our HACKING.rst or constitution with those design principles. (The versioning one is already there, but we aren't explicit about DB migrations working.)
20:47:34 <sbalukoff> ?
20:47:38 <sbalukoff> That was a question.
20:47:40 <blogan> in alembic you define upgrade() and downgrade() methods
20:47:52 <jorgem> sbalukoff: sure
20:47:55 <sballe> yeah if Octavia can do this it will be the only service in OpenStack taht can :-( But of course we are all workign towards OpenStack services being able to do this
20:48:01 <sbalukoff> blogan: I think his point is that sometimes nobody thinks about downgrade()
20:48:18 <xgerman> yep, and what do you dow ith data in the new tables?
20:48:25 <xgerman> will bite you at the next upgrade
20:48:28 <xgerman> ...
20:48:30 <sbalukoff> Everytime your downgrade() doesn't work, god kills a kitten.
20:48:44 <jorgem> for example FK contraints usually cause issues
20:48:46 <sballe> sbalukoff: HP does. The issue is that the tools we use such as Heat to deploy aren't mature enought to do a rollback.
20:48:49 <blogan> i have yet to see a migration that downgrade wasn't complete, however it is possible that it just couldn't be run due to other restrictions
20:48:59 <jorgem> migrations are with code as well though
20:49:15 <jorgem> not just DB albeit the DB is the one most people take into consideration
20:49:31 <jorgem> Requirement is seamleass upgrades and downgrades
20:49:32 <xgerman> jorgem +1000
20:49:33 <blogan> i think thats when the microversioning comes into play
20:49:44 <sbalukoff> Oh boy.
20:50:07 <jorgem> sballe: We almost have that completed with our CLB product
20:50:14 <jorgem> sbalukoff: *sorry
20:50:25 <sbalukoff> blogan: Weren't you against microversioning APIs?
20:50:26 <sbalukoff> Anyway...
20:50:27 <jorgem> anyways, I'll update the HACKING.rst file
20:50:41 <jorgem> sbalukoff: link?
20:50:42 <sballe> Who will go and investigate microversioning and come back next week and explain it to the rest of us?
20:51:10 <sbalukoff> #action jorgem to update Octavia constitution.rst or hacking.rst with principles around seamless upgrades / downgrades
20:51:14 <blogan> sbalukoff: against it in the url
20:51:19 <xgerman> or we invite jay as a guest speaker?
20:51:21 <sbalukoff> jorgem: It's in the root of the octavia repository
20:51:43 <jorgem> k thx
20:51:47 <blogan> we definitely need to version, just not show minor/micro versions in the url
20:51:49 <sbalukoff> jorgem: what you're describing is probably best in the constitution.rst file.
20:52:00 <jorgem> k
20:52:01 <sballe> jorgem: I do agree with this requirement and it will be nice when we have it
20:52:04 <sbalukoff> blogan: Ok
20:52:19 <sbalukoff> Ok!
20:52:20 <sbalukoff> jorgem: Anything else right now?
20:52:23 <jorgem> Just want to make sure we don't perform upgrades like it's 1999!
20:52:28 <sbalukoff> Haha
20:52:35 <sbalukoff> #topic Open Discussion
20:52:42 <jorgem> but I do want to party like it :)
20:52:48 <sbalukoff> +1
20:53:04 <sbalukoff> Ok, folks, we've got 7 minutes left. What else do y'all want to discuss?
20:53:52 <sbalukoff> TrevorV_: Wasn't there something you wanted to yell at me about?
20:54:00 <TrevorV_> no yelling
20:54:08 <TrevorV_> Just the management_network thing is getting to me
20:54:11 <sbalukoff> Aaw!
20:54:15 <blogan> just passive aggressive insults
20:54:22 * TrevorV_ isn't like blogan
20:54:30 <dougwig> oh nuts, timezone
20:54:35 <sbalukoff> Ok. So that's likely to go beyond the 6 minutes we have left-- maybe we can do this in #openstack-lbaas afterward?
20:54:38 <blogan> wtg dougwig
20:54:42 <sbalukoff> dougwig: D'oh!
20:54:46 <dougwig> sorry
20:54:47 <TrevorV_> sbalukoff, I suggested that already :P  Sounds good, talk at you there
20:54:57 <TrevorV_> (or with, if you prefer ha ha)
20:55:12 <sbalukoff> Heh!
20:55:29 <sbalukoff> Ok, folks...  if there's nothing else right now, let's end this a few minutes early.
20:55:39 <TrevorV_> Alrighty, take it easy all!
20:55:43 <TrevorV_> o/
20:55:47 <sbalukoff> Thanks y'all!
20:55:52 <sballe> bye
20:55:58 <sbalukoff> #endmeeting