Tuesday, 2014-11-25

*** david-lyle is now known as david-lyle_afk00:17
*** banix has quit IRC00:24
*** david-lyle_afk has quit IRC00:45
*** ChuckC has quit IRC01:12
*** ChuckC has joined #openstack-meeting-401:18
*** mwang2_ has quit IRC01:19
*** ChuckC has quit IRC01:22
*** ChuckC has joined #openstack-meeting-401:23
*** ivar-laz_ has joined #openstack-meeting-401:27
*** ivar-lazzaro has quit IRC01:31
*** ivar-laz_ has quit IRC01:39
*** ivar-lazzaro has joined #openstack-meeting-401:39
*** SridharRamaswam1 has quit IRC02:08
*** banix has joined #openstack-meeting-402:19
*** banix has quit IRC02:24
*** banix has joined #openstack-meeting-402:42
*** s3wong has quit IRC02:46
*** banix has quit IRC02:55
*** yamahata has joined #openstack-meeting-402:57
*** sbalukoff has quit IRC03:03
*** shwetaap has joined #openstack-meeting-403:20
*** ivar-lazzaro has quit IRC03:30
*** nikhil_k|vacay has joined #openstack-meeting-405:02
*** kobis has joined #openstack-meeting-406:24
*** shwetaap has quit IRC06:51
*** shwetaap has joined #openstack-meeting-406:51
*** yamahata has quit IRC09:11
*** sbalukoff has joined #openstack-meeting-410:03
*** naohirot has quit IRC10:29
*** naohirot has joined #openstack-meeting-411:00
*** shwetaap has quit IRC11:16
*** naohirot has quit IRC13:29
*** yamahata has joined #openstack-meeting-413:58
*** evgenyf has joined #openstack-meeting-414:04
*** evgenyf has quit IRC14:06
*** evgenyf has joined #openstack-meeting-414:06
*** vishwana_ has joined #openstack-meeting-414:10
*** vishwana_ has quit IRC14:11
*** dboik has joined #openstack-meeting-414:34
*** banix has joined #openstack-meeting-414:35
*** vishwana_ has joined #openstack-meeting-414:46
*** vishwana_ has quit IRC14:47
*** banix has quit IRC14:58
*** yamahata has quit IRC15:08
*** nikhil_k|vacay is now known as nikhil_k15:15
*** yamahata has joined #openstack-meeting-415:16
*** banix has joined #openstack-meeting-415:22
*** shwetaap has joined #openstack-meeting-415:27
*** nikhil_k is now known as nikhil_k|vacay15:29
*** jamiem has joined #openstack-meeting-415:31
*** banix has quit IRC15:35
*** vjay-netscaler has joined #openstack-meeting-415:35
*** vjay-ns has joined #openstack-meeting-415:36
vjay-nsHi All, Is there an LBaaS meeting today?15:41
*** ajmiller has joined #openstack-meeting-415:51
dougwigyep, starting in 3 minutes.15:56
vjay-netscalerok!15:57
*** xgerman_ has joined #openstack-meeting-415:57
dougwigwe're going to discuss this later in the meeting, so if anyone hasn't had a chance to peek at it yet:  https://review.openstack.org/#/c/13683515:58
sbalukoffThanks for the link, eh!15:59
dougwig#startmeeting neutron lbaas16:00
openstackMeeting started Tue Nov 25 16:00:10 2014 UTC and is due to finish in 60 minutes.  The chair is dougwig. Information about MeetBot at http://wiki.debian.org/MeetBot.16:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:00
*** openstack changes topic to " (Meeting topic: neutron lbaas)"16:00
openstackThe meeting name has been set to 'neutron_lbaas'16:00
dougwig#topic Roll call and Agenda16:00
sbalukoffHowdy, folks!16:00
*** openstack changes topic to "Roll call and Agenda (Meeting topic: neutron lbaas)"16:00
dougwighiya16:00
ajmillero/16:00
dougwig#link https://wiki.openstack.org/wiki/Network/LBaaS#Meeting_25.11.201416:00
blogan\o/16:00
dougwig#topic Announcements16:01
*** openstack changes topic to "Announcements (Meeting topic: neutron lbaas)"16:01
xgerman_\o/ - nobody vacations like blogan16:01
dougwiglol16:01
blogani'm a masochist16:01
dougwigour fourth v2 review merged!  thanks oleg and mestery!16:01
dougwignext review that needs attention: #link https://review.openstack.org/#/c/123487/16:01
xgerman_go see the sights -- the alamo is nice thgis time of year!16:01
dougwigany other announcements, besides that blogan doesn't know how to vacation?16:02
sballeo/16:02
dougwig#topic Subteam charter16:02
bloganthat review needs to be fixed for jenkins and address some comments, ill try to do that today16:02
*** openstack changes topic to "Subteam charter (Meeting topic: neutron lbaas)"16:02
xgerman_also we are looking to gte in touch with mlavalle -- we ant to run the tempest tests16:02
dougwigmestery introduced this wiki yesterday: https://wiki.openstack.org/wiki/NeutronSubteamCharters16:02
dougwigi put in a quick blurb for us, but if anyone disagrees, holler.16:03
dougwig#link https://wiki.openstack.org/wiki/NeutronSubteamCharters16:03
blogani disagree with the rainbows16:03
xgerman_I on the other hand like them16:03
xgerman_but I also want unicorns, lots of them16:04
sbalukoffThe rainbows are important.16:04
dougwiggerrit fight.  go!16:04
sbalukoffxgerman +116:04
blogani do have a question that is somewhat related16:04
dougwigshoot16:04
rm_workyo16:04
bloganif we want all reviews merged into the feature branch, it is not in our best interest to add more reviews to be merged to that feature branch16:05
xgerman_+116:05
bloganwhich means it is not in our best interest to add new features or change things until after the split16:05
dougwigin my mind, we keep going with the feature branch as if the split isn't going to happen.  when the split occurs, a few reviews might need to be moved.16:05
bloganso what if getting things merged into the feature branch becomes a blocker to getting the split done?16:06
bloganmark has hinted this could be the case16:06
dougwigthe spec linked above calls out that case, and as not a blocker.16:06
dougwig(doesn't mean that it's anywhere near consensus, but that topic hasn't come up yet.)16:07
bloganconsensus is like rainbows and unicorns16:07
dougwigi don't like serializing stuff around imminent changes in openstack, since there are *always* imminent changes in openstack, and they can't all be relied upon.  we'd literally be in paralysis all the time.16:07
sballe+116:07
dougwigthat's just my opinion, though.16:08
sballemine too16:08
blogani know, i agree that there really shouldn't be a dependency on pending reviews into the feature branch16:08
xgerman_I agree with getting v2 finished but I would elahy new work16:08
xgerman_delay16:08
bloganthere's also the prospect of redoing some of the v2 api16:08
bloganor changing some of it around16:08
xgerman_I heard of that but we should continue our course16:09
dougwigdo we want to push for a feature branch in the split repo, to account for some kilo churn?16:09
vjay-netscalerI didnt understand the conversation in full. what is the idea here, we get the split with code in main branch and then merge feature branch to split repo?16:09
bloganyeah but id rather avoid kilo having one version of the v2 api only to change it for L16:09
dougwigwe also need to repropose our v2 specs for kilo16:09
sballeblogan: What would the re-work on v2 be?16:10
xgerman_sballe +116:10
blogansballe: we've discussed in last meeting i think, removing the need for the DEFERRED status is one16:10
bloganwell its a big one16:11
*** TrevorV has joined #openstack-meeting-416:11
* TrevorV sorry I'm late :(16:11
bloganthen also having only one true root object, load balancer is a proposal16:11
sballeblogan: ok I'll look at the meeting logs and will sync-up with you16:11
dougwigblogan: we kind of got ourselves into that level of analysis paralysis when we first started getting consensus on v2.  it's not an api any of us love, but it did get consensus.  are we sure that if we go through that mill again that the result will be different/better?16:11
dougwigDEFERRED was added on the fly late; i'm not sure removing it is all that noticeable.  the other stuff is bigger.16:11
xgerman_yeah, I am very worried that we open a can of worms16:11
bloganit was agreed on at the midcycle16:11
xgerman_but that was before task flow16:12
bloganwell i guess the biggest change possibly is what Sam proposed on the ML16:12
xgerman_yeah, and we are not in favor of it16:12
dougwiglet's put this stuff as alternatives (or the main proposal) in the specs for kilo and go for consensus in gerrit?16:13
sballeI saw what Sam proposed but thought we were going to do that down the road if it still made sense. I do not feel we are down the road yet. We talked version 1.0 and we are not at v 0,5 of Octavaia yet16:13
blogandougwig +116:14
dougwigi'm just worried about being duke nukem forever, openstack edition.16:14
blogansballe: sam is talking about neutron lbaas v2 api16:14
sbalukoffdougwig: +116:14
sballeblogan: I understand but I am still not in favor of touching that now16:14
dougwigblogan: can you repurpose your v2 spec for kilo, and we'll continue there?16:14
dougwigrepropose16:14
blogansure16:15
sbalukoffNeutron LBaaS v2 API does affect Octavia, though not initially.16:15
bloganaction me16:15
dougwig#action blogan Re-propose lbaas v2 spec for Kilo16:15
bloganrepurpose works as well16:15
dougwigok, now that we're all warmed up...16:15
sbalukoffAgain, we need to get v0.5 first16:15
dougwig#topic Advanced services split mechanics16:15
*** openstack changes topic to "Advanced services split mechanics (Meeting topic: neutron lbaas)"16:15
dougwig#link https://review.openstack.org/#/c/136835/16:15
dougwigany comments or discussion on that spec that we can do in slightly higher bandwidth irc meeting?16:16
bloganpretty sure the next meeting will have that16:16
sbalukoffI'm just catching up on it. Will probably have more to say in gerrit. :)16:16
rm_worksame16:16
sballesame here16:16
dougwigcurrent hot points are: client?  governance?  extensions?  core vs service plugins?  dependencies and upgrades16:16
dougwighere, or gerrit, or the services meeting in 45 minutes...  feedback anywhere is good.16:17
sbalukoffEeexcellent.16:17
xgerman_yeah, need to cathc up with the comments16:18
dougwigthis topic seems to go dead silent in IRC.  :)16:18
dougwigok, moving on.16:18
dougwig#topic Open discussion16:18
*** openstack changes topic to "Open discussion (Meeting topic: neutron lbaas)"16:18
dougwigany topics to discuss here?16:19
xgerman_so this is for the RAX guys -- we would like to get in touch with Miguel to learn more about the tempest tests16:19
bloganmind if i talk about Sam's proposal here a bit?16:19
dougwigthis is my first meeting stateside at the new time.  loving it.  :)16:20
bloganafter german's16:20
dougwigblogan: go for it16:20
bloganjorgem sits right next to miguel, though miguel is not always at his desk16:20
bloganTrevorV: is miguel there?16:20
TrevorVNope, not right now16:20
xgerman_ok, we also send him an e-mail :-)16:21
TrevorVI mean he could be in the office today but he's not physically at the desk right now16:21
bloganhe might be on vacation this week16:21
xgerman_ok, that makes sense16:21
bloganand he's smart unlike me16:21
TrevorV(like blogan should be)16:21
sbalukoffHaha16:21
dougwiglol16:21
dougwig#topic v2 objects as logical models16:21
*** openstack changes topic to "v2 objects as logical models (Meeting topic: neutron lbaas)"16:21
dougwigtake it away, blogan16:21
bloganother than what i mentioned on the ML, and the fact that it would change v2 midstream, are there any cons to his proposal?16:22
dougwigthat last is a pretty big con.  city sized.16:22
bloganyes but if it is the best most amazing proposal ever, it'd be worth it16:23
sbalukoffI would like to see a fleshed-out version of reporting status as well as a state machine description.16:23
sballesbalukoff: +116:24
sbalukoffOnce you start sharing objects across entities (ie. not within scope of parent objects), status gets crazy.16:24
xgerman_yep, I still fail to understand what sharing gets us -- you can *always* copy objects16:24
dougwigif we prep an alternate, i'd like to see other folks working on it, so we're going in parallel and not stalling out.16:24
blogansbalukoff: it does, but the entities will not have statuses directly, they will be statuses only relevant to the parent16:24
sbalukoffI'm OK with sharing objects within the scope of parent objects.16:24
sbalukoffblogan: Aah-- so there's effectively the built-in scope.16:25
ptoohillso the only way to view status is on the parent in this proposal?16:25
sbalukoffOk, that actually makes more sense to me.16:25
bloganxgerman_: sharing gets a more intuitive UX for people, they don't have to recreate pools 100 times, and they don't have to update 100 pools16:25
sbalukoffptoohill: Correct.16:25
xgerman_well, for the people with a 100 pools -- so that solves a problem for a minority of my users16:25
bloganxgerman_: true16:26
sbalukoffblogan: It does mean that if I have a pool shared across a bazillion listeners, updating one member initiates a ton of back-end work, any of which could fail.16:26
ptoohillSo i wouldnt be able to query my members and see their statues, i would have to then query the parent and sort/find through its list of statuses for the members im interested in16:26
dougwigsam's proposal fits in especially well with taskflow.16:26
ptoohillNot a big deal i suppose16:26
blogansbalukoff: that is true if the backend does not support sharing, but the user will end up manually causing a ton of back-end work anyway if sharing is nto enabled, though it will be easier for the system to handle in that case16:27
rm_workptoohill: you mean like backend nodes?16:27
ptoohillor any object really16:27
ptoohillwas just using that as example16:27
dougwigsbalukoff: unless the logical objects are treated as templates, and not real-time config.  (create uses logical structure, edits affect LB tree only.)16:27
rm_workptoohill: I would hope the same doesn't apply to statuses that come from health monitors16:27
rm_workblogan: ?16:27
bloganptoohill: if neutorn extensions supported parent child nesting, that would make that easier and I'd like this a lot more16:27
sbalukoffdougwig: I don't follow. How is that any different?16:28
ptoohilltrue16:28
ptoohillwerent they talking about reworking that?16:28
dougwigsbalukoff: because then edits to a shared pool would only affect new LB's.16:28
ptoohillbut thats a ways off even if it was true16:28
bloganptoohill: they're focused on refactoring the API, i think extensiosn will be later16:28
ptoohillah16:28
bloganthough i need to spend time on seeing if i can hack it to work with the current exntesion loader16:28
sbalukoffdougwig:  Aah, I see. That's not very intuitive for the user, though.16:28
sbalukoffdougwig: If the user *wants* to affect all load balancers, they're back in the boat of updating everything themselves again..16:29
dougwigdepends on how it's presented.  it's certainly more in line with the proposal of logical objects being divorced from their provisioned config and status.16:29
sbalukoffdougwig: It seems messy to me.16:29
xgerman_+116:29
sbalukoffHonestly, I'd rather initiate all that back-end work.16:29
bloganthat does remove half the reason to have shared objects in that updating one entity can update many16:29
sbalukoffblogan: That's my perception of its benefit, too.16:30
xgerman_and my fear of support calls.16:30
blogandont fear the reaper16:30
sbalukoffOh, pshaw. Providing customer support is so 2014.16:30
rm_work<_<16:31
dougwigwhat company would be silly enough to bet on fanatical support?16:31
dougwigoh.16:31
sbalukoffHaha16:31
dougwig:)16:31
blogansome insane company16:31
*** igordcard has joined #openstack-meeting-416:31
xgerman_well, I am not sure how Sam's proposal will make development easier + we can solve his use cases by copying stuff16:32
sbalukoffOk, so... again, I want to see the idea fleshed out more, as well as some discussion of handling various scenarios (what I mean by state machine, I guess).16:32
dougwigdoes someone want to chase this down and ferret out if it's good enough to overturn the boat?  blogan, before you answer, you are supposed to be on vacation.16:32
sbalukoffAnd I would like to see logical objects nested under parent objects as blogan says.16:32
bloganim pretty sure sbalukoff already asked for this on the ML16:32
sbalukoffOtherwise, I don't have a problem with this in theory.16:32
xgerman_sbalukoff +116:32
dougwigso ,we wait for an ML response and table this for a week or two?16:33
xgerman_nesting objects is goog16:33
sballesbalukoff: +116:33
sbalukoffdougwig: Yep.16:33
blogansounds good to me, hopefully sam responds with such16:33
sbalukoffdougwig: With all the advanced services stuff in the works, I wonder how much traction we'd have overturning the boat.16:33
bloganevgenyf: you around?16:33
sbalukoffThough it seems Radware / Samuel would be on board.16:33
dougwigok.  i'd say we should go ahead with the v2 spec, and add this later if it bears fruit.16:33
evgenyfblogan: yes16:34
sballedougwig: +116:34
sbalukoffdougwig: +116:34
bloganevgenyf: could you relay to sam, if he doesn't know yet, that we'd like more fleshed out examples16:34
evgenyfSure16:34
bloganthanks!16:35
dougwig#topic Open discussion16:35
*** openstack changes topic to "Open discussion (Meeting topic: neutron lbaas)"16:35
dougwiganything else this morning?16:35
bloganevgenyf: unless you can provide the examples16:35
sbalukoffHave a happy turkey day, for those who celebrate it?16:35
blogani thought this week was happy rioting day16:36
bloganor week16:36
dougwigsettle down.16:36
sbalukoffIt's turning into riot week.16:36
sbalukoffHaha16:36
dougwigon that note, let's get out of here.  thanks, everyone.16:36
bloganlol16:36
sballebye16:36
rm_worksee you all next week :)16:36
xgerman_thanks -- see you in 2416:36
bloganbye16:36
sbalukoffThanks! Seeya!16:36
dougwig#endmeeting16:36
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"16:36
openstackMeeting ended Tue Nov 25 16:36:56 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:36
openstackMinutes:        http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neutron_lbaas.2014-11-25-16.00.html16:37
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neutron_lbaas.2014-11-25-16.00.txt16:37
openstackLog:            http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neutron_lbaas.2014-11-25-16.00.log.html16:37
dougwigi wonder if you can undo an endmeetin16:37
dougwig#undo16:37
*** TrevorV has left #openstack-meeting-416:37
dougwigappears not.  :)16:37
rm_worknup16:37
bloganit wouldn't accept your command16:37
dougwig#endmeeting16:37
dougwigjust in case16:37
*** shwetaap has quit IRC16:39
*** banix has joined #openstack-meeting-416:40
*** shwetaap has joined #openstack-meeting-416:43
*** hareeshp has joined #openstack-meeting-416:51
*** vjay-netscaler has quit IRC16:58
*** mhanif has joined #openstack-meeting-416:59
dougwigo/16:59
*** vishwana_ has joined #openstack-meeting-416:59
blogan\o/16:59
ptoohillo/17:00
SumitNaiksatamhi there!17:00
hareeshpHello17:00
vishwana_hello17:00
mhanifhello17:00
*** s3wong has joined #openstack-meeting-417:00
xgerman_o/17:01
*** kobis has quit IRC17:01
sbalukoffGreetings, y'all!17:01
s3wonghello17:01
SumitNaiksatambanix: hareeshp dougwig blogan: hi17:01
bloganhola17:01
banixhi17:01
dougwighiya17:01
SumitNaiksatamxgerman_: sballe: hi17:01
*** SridarK has joined #openstack-meeting-417:02
SumitNaiksatamsbalukoff: hi17:02
s3wonggood turnout for Thanksgiving week...17:02
sbalukoffIs... someone planning on actually starting the meeting?  Or have an agenda?17:02
*** bobmel has joined #openstack-meeting-417:02
mhanifYes, agenda pleas!17:02
s3wongreview the spec from dougwig, I suppose? :-)17:03
*** SumitNaiksatam has quit IRC17:03
xgerman_+117:03
hareeshp+117:03
sbalukoffHAHA!17:03
sbalukoffdougwig! You're in charge again!17:03
*** _sunil has joined #openstack-meeting-417:03
SridarKHi17:03
dougwigsumit usually chairs, appears he lost network.17:04
banixi think sumit got disconnected17:04
bloganSumitNaiksatam leads these, and i know he is here17:04
*** SumitNaiksatam has joined #openstack-meeting-417:04
sbalukoffOh, ok.17:04
bloganoh wait17:04
blogannvm17:04
dougwigthere he is.17:04
bloganthere he is17:04
sbalukoffThere he is!17:04
s3wongSumitNaiksatam is back17:04
bloganjinx17:04
sbalukoffYou owe me a coke?17:04
bloganyou all owe me17:04
sbalukoffjinx!17:04
blogannot an exact jinx17:04
bloganyou lose17:04
bloganyou owe me for false jinxing17:04
sbalukoffGood enough for government work.17:04
sballeo/17:04
SumitNaiksatamhi there17:05
blogangood thing this isn't in the meeting logs17:05
SumitNaiksatamsome issue with my connection i wasnt able to see any responses from any one17:05
s3wongSumitNaiksatam: do you want to have a meeting?17:05
SumitNaiksatamlets get started17:05
SumitNaiksatam#startmeeting Networking Advanced Services17:05
dougwigmaybe add a second chair, in case you drop again17:05
openstackMeeting started Tue Nov 25 17:05:34 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.17:05
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:05
*** openstack changes topic to " (Meeting topic: Networking Advanced Services)"17:05
openstackThe meeting name has been set to 'networking_advanced_services'17:05
*** vishwan__ has joined #openstack-meeting-417:05
SumitNaiksatam#chair blogan dougwig s3wong sbalukoff sballe17:06
openstackCurrent chairs: SumitNaiksatam blogan dougwig s3wong sballe sbalukoff17:06
*** SridharRamaswamy has joined #openstack-meeting-417:06
SumitNaiksatamwelcome to the party!17:06
SumitNaiksatam#info https://wiki.openstack.org/wiki/Meetings/AdvancedServices#Agenda17:06
_sunilhello! I am here representing Embrane! First timer here...:)17:06
SumitNaiksatam_sunil: hi there sunil!17:06
SumitNaiksatam#topic Neutron subteams' charter17:07
*** openstack changes topic to "Neutron subteams' charter (Meeting topic: Networking Advanced Services)"17:07
s3wong_sunil: marcodb too busy? :-)17:07
SumitNaiksatamnot sure if we are subteam or a full fledged team17:07
sbalukoffWe're the A-Team.17:07
xgerman_+117:07
SridarKsbalukoff: +117:07
sballe+117:07
*** vishwana_ has quit IRC17:07
SumitNaiksatamsbalukoff: yay that! :-)17:07
_sunilyeah...:)17:07
vishwan__+117:07
SumitNaiksatambut at least prior to the split i think we need to have a charter17:08
SumitNaiksatami put the most obvious things there17:08
SumitNaiksatamso feel free to edit update as seems relevant (perhaps send an email to the team if in doubt)17:08
SumitNaiksatamanything to discuss on that front?17:08
dougwigi noted a distinct lack of unicorns.17:08
sballelol17:09
* dougwig makes a note in Sumit's permanent file.17:09
SumitNaiksatamdougwig: all the unicorns and rainbows are taken17:09
SumitNaiksatamdougwig: i figured we would do real work :-P17:09
*** nlahouti has joined #openstack-meeting-417:09
mhanifI thought Adv. services had sub-teams in it?  Will LBaaS, VPNaaS be part of it or separate sub-teams?17:09
*** igordcard has quit IRC17:10
SumitNaiksatammhanif: we would treat those as subteam as well17:10
sbalukoffThose are included in the purview of advanced services.17:10
SumitNaiksatamsorry, should have posted:17:10
SumitNaiksatam#link https://wiki.openstack.org/wiki/NeutronSubteamCharters#Advanced_Services_Team17:10
SumitNaiksatamunless mestery informs us otherwise17:10
SumitNaiksatammhanif: this should be clear from the stated adv services charter17:11
mhanifSumitNaisatam: Yes, it is.  Thanks!17:11
SumitNaiksatamany other thoughts on this?17:11
mhanifI have suggested a brand new sub-team Edge-VPN17:12
*** evgenyf has quit IRC17:12
SumitNaiksatammhanif: sure17:12
SumitNaiksatammhanif: perhaps check with mestery as well if there is enough to go around for this17:13
mhanifAll, please let me your comments or if you have anything to add, please feel free,17:13
SumitNaiksatammhanif: also would that not be a part of the VPNaaS team?17:13
sbalukoffWill do.17:13
mhanifNo, since VPNaaS deals with end-2-end VPNs and we are talking about VON's from edge of the data center17:14
*** yamahata has quit IRC17:14
SumitNaiksatammhanif: okay, perhaps best to discuss with the folks currently involved with VPNaaS as well, if there is a way to join efforts17:14
mhanifVPNaaS talks about IPSec and L2TP VPNs while edge VPN deals with MPLS VPNs17:14
SumitNaiksatamjust a suggestion, since, from a process perspective, i think Neutron is discouraging too many subteams17:15
SumitNaiksatammhanif: i agree with the technical differences17:15
SumitNaiksatamok moving on17:15
mhanifSure, open for any discussion there is17:15
SumitNaiksatammhanif: thanks for chiming in17:15
SumitNaiksatam#topic Project spin out logistics17:15
*** openstack changes topic to "Project spin out logistics (Meeting topic: Networking Advanced Services)"17:15
SumitNaiksatammuch anticipated! :-)17:15
SumitNaiksatamdougwig: thanks for taking the initiative to post this spec17:16
dougwig#link https://review.openstack.org/#/c/13683517:16
SumitNaiksatamthanks ^^^17:16
sbalukoffLots of comments to catch up on there.17:16
SumitNaiksatami believe there have been a good number of comments and responses already17:16
dougwigcurrent hot points are: client?  governance?  extensions?  core vs service plugins?  dependencies and upgrades17:16
SumitNaiksatamsbalukoff: looking forward to yours ;-)17:17
SumitNaiksatamdougwig: that pretty much covers most of the spec ;-)17:17
SumitNaiksatamwe agree to that we need the split!17:17
blogani think the governance parts are beyond this spec's scope17:18
SumitNaiksatami think we can spend good time here to discuss17:18
dougwigi hadn't intended to have a governance debate in that spec.  i need technical feedback quickly.17:18
dougwigok17:18
xgerman_yeah, governance is hard to put in a spec17:18
s3wongdougwig, blogan: agreed --- difficult for a technical spec to determine governance17:18
SumitNaiksatamblogan: dougwig: xgerman_: well, everything in openstack is a gerrit spec17:18
sbalukoffHeh!17:19
dougwigthe current governance plan:17:19
sbalukoffWe need somewhere to start on the governance question.17:19
dougwig#link http://lists.openstack.org/pipermail/openstack-dev/2014-November/050961.html17:19
sbalukoffYay!17:19
*** dboik has quit IRC17:19
bloganSumitNaiksatam: and maybe there should be a governance spec, but this is just teh technical details on how to do the code split17:19
SumitNaiksatamall governance issues are also being tracked and debated in gerrit specs, not saying good or bad17:19
*** ivar-lazzaro has joined #openstack-meeting-417:19
xgerman_well, you cna infer my opinion :-)17:19
hareeshpSumitNaiksatam: +117:19
SumitNaiksatamblogan: i agree, the counter point is that these are tied at the hip17:20
SridarKdougwig: i think one of the reasons for a spec was to capture all aspects of discussion in a focussed manner17:20
dougwigwell, we practically had crickets on the ML thread.  and then we pounce on a semi-related gerrit spec.  if y'all want gerrit, make a spec for it.  :)17:20
sbalukoffWell... "focused" ;)17:20
SumitNaiksatamof course, personally i definitely favor the pragmatic approach of making progress wherever we can17:20
dougwigSridarK: i respect that, but i'm not sure we can swallow that large a rodent in one go.17:20
xgerman_+117:20
bloganmmm rodents17:21
xgerman_yeah, also we are not really self governed so we are discussing things we can't change17:21
SridarKdougwig: i agree that this can "rathole" but ...17:21
s3wongSridarK: the downside would be that we would be suck into an endless loop of debate on governance issue but never do the actual work since the spec wasn't approved17:21
xgerman_s3wong +117:21
dougwigs3wong: +10017:21
sbalukoffs3wong: +117:21
dougwigmaybe we take a few minutes now and just discuss governance, instead of discussing discussing governance.17:21
sbalukoffHaha17:22
sbalukoffdougwig: Why you gotta be like that, man? ;)17:22
sbalukoffSeriously though, +117:22
SumitNaiksatamyeah no one likes ratholes!17:22
dougwiganyone seen office space, with the whiteboard titled "Planning to Plan" in the background?  :)17:22
bloganyes17:22
SumitNaiksatamdougwig: lol17:22
s3wongdougwig: what? we don't want to discuss about the merit of discussing governance? :-)17:23
bloganmike judge was a software engineer17:23
s3wongwe should discuss the plan to discuss about governance then...17:23
*** hareeshp has quit IRC17:23
SumitNaiksatamon the technical issues, i didn’t see why the extension definition could not be part of the initial split17:24
dougwigso i'll throw in my $0.02, which is that it's unlikely we'll see "consensus" on the governance topic, and what Mark proposed can be a workable step forward, so let's take it.17:24
xgerman_I like to see more self governance17:24
ivar-lazzaroSumitNaiksatam: +117:24
SumitNaiksatamdougwig: like you said (or may be someone else), sometimes you need let every vent ;-)17:24
SumitNaiksatam*everyone17:25
dougwigi'm trying to trigger the venting.  :)17:25
s3wongdougwig: so now the proposal is (a) API/DB models in "services-tron", (b) different core team with overlap, and (c) spec still driven by neutron-drivers17:25
bloganand extensions remain in neutron tree until kilo-317:26
SumitNaiksatams3wong: the API part is fuzzy17:26
dougwig(a) API/DB/extensions/plugins/tests in MEGAtron, then yes.17:26
dougwigwell, control of API.  i care not who is listening on port 443.17:26
SumitNaiksatamdougwig: +1000 for megatron if we get it! ;-)17:26
s3wongSumitNaiksatam: I think the API part is the one we will have to clearly state in the spec (which dougwig did)17:26
SumitNaiksatamdougwig: yes, API endpoint is not as important17:26
SumitNaiksatamthe place for the API definition is17:26
s3wongdougwig: +1 --- everything service related (except service_base.py stuff)17:27
SumitNaiksatamblogan: i think kilo-3 is too late17:27
dougwigSumitNaiksatam: the issue to me is one of whether to have a breaking change across repos.  will leaving the extensions in neutron for and extra month or two slow us down on something?17:27
dougwigSumitNaiksatam: well, that was the manager in me making a hedge, in case the refactor takes longer than expected.  if don't in kilo-1, then the extensions will move much sooner.17:27
SumitNaiksatamdougwig: even if this is in the main repo, it will be stacked as several patches17:27
ivar-lazzarodougwig: yes. I think that's harder to keep the extensions there17:28
bloganwell i can see a reason why the extensions should stay in neutron in the beginning, and that is because neutron's extension loader will need to have an idea as to wehre to load extensions from an external path17:28
banixSumitNaiksatam: yes, kilo-3 is practically late for almost everything substantial17:28
dougwigivar-lazzaro: we're talking about a month or two.17:28
bloganif the extensiosn are split out17:28
SumitNaiksatamdougwig: so there will always be a window no matter which way we go17:28
*** hareeshp has joined #openstack-meeting-417:28
SumitNaiksatamdougwig: and a month can easily stretch out to much longer17:28
dougwigno, there's zero window if we wait.   how is there a window in that case?17:28
bloganneutron will have to add logic in their extension loaded to load extensions from an external path no?17:28
dougwigit already has that.17:29
SumitNaiksatamblogan: that logic already exists17:29
ivar-lazzarodougwig: I see but we need a good reason to do so. By moving the extension we can work together so that the REST refactor on Neutron's side goes smoothly17:29
bloganwell nvm17:29
dougwigour path just has to go into the conf file as a default.17:29
bloganignore me17:29
dougwigivar-lazzaro: i'm not sure that parallelism makes anything faster.  the refactor is mechanical work to fit the new framework.  by separating, we make that harder, not easier.17:29
ivar-lazzarodougwig: If we wait instead, we are not guaranteed to catch all the possible issues with the refactor17:30
SumitNaiksatamdougwig: the path part can also be easily sorted (even before it goes into the config file)17:30
SridarKivar-lazzaro: +1 my concern here too17:30
s3wongblogan: even Neutron can load extension from different path / package, the hairy part that we try to avoid is the API refactoring gating this17:30
SumitNaiksatamdougwig: i dont necessarily agree with that last statement17:30
dougwigi'm not concerned with the loading path.  just the refactor overlap.17:30
xgerman_s3wong+117:30
blogans3wong: yeah ive been corrected and punished17:30
xgerman_I am worried if we have gating things the spin off won't happen17:31
ivar-lazzaroblogan: Neutron can already do that17:31
s3wongblogan: I figure I should pour it on you while I have an opportunity to do so :-)17:31
xgerman_so rather sign up for more work then to gate the spinoff17:31
ivar-lazzarodougwig: Is refactor overlap bad? Do we really want to hit all the issues once the refactor is completed already?17:31
dougwigthe impression that i've gotten from folks outside this conversation is that if we put extensions on the MUST list, we will gate the split on the refactor.  i don't want that, and i can see at least one technical reason justifying that.17:32
sbalukoffs3wong: I take every opportunity, too.17:32
bloganwell if the neutron core thinks that keeping extensions in neutron for the refactor will make it easier, i don't see how they will give that up17:32
SumitNaiksatamxgerman_: +1, hence one of the views is that the split should happen with the extensions, and once the refactor happens in neutron, the same can be done in the services’ repo17:32
banixblogan: Neutron can already do that! (Just kidding!)17:32
bobmelWhat details about the API refactor do we have? Seems to be a number of unknowns there...17:32
bloganbanix: lol17:32
s3wongdougwig: so I figure you have been in contact with markmcclain --- do you get a sense that he wants to postpone spinning off the extensions until API refactoring is done?17:32
ivar-lazzarodougwig: I don't see why this should happen. Sounds like a threat :)17:33
dougwigconsensus can be a threat.  :)17:33
SumitNaiksatamdougwig: blogan: in that sense its not a technical discussion then, its a function of what you are hearing outside this converation?17:33
banixSumitNaiksatam, all, what concerns me is that other principals, that is non “advanced services” crowd don’t seem to be here17:33
blogani don't think viewing these things as threat is a constructive path to working well with neutron cores17:34
SumitNaiksatambanix: good point17:34
dougwigthere are a million reasons to delay, and i am trying to thread a very tiny needle that doesn't gate us on anyone else.  personally, i want to be really cautious on where we put our stakes in the ground.17:34
SumitNaiksatambanix: how can we ensure everyone attends?17:34
dougwighave the conversation in the neutron meeting would be my first suggestion.17:34
SumitNaiksatamto be fair, its difficult to keep up with so many meetings17:34
xgerman_dougwig +1 increased velocity is the main reason for splitting17:34
s3wong"threat" is strong word, we are showing our goodwill on our willingness to work neutron core/drivers17:35
s3wong* work with17:35
SumitNaiksatamwe seem to have a vested interest in this, hence we are making the time17:35
dougwigi took "threat" as a light-hearted joke up above.17:35
sbalukoffxgerman_: Increased velocity through self-governance?17:35
*** SridharRamaswamy has quit IRC17:35
SumitNaiksatambut yes, the point has been raised before that we should not be discussing in a vacuum17:35
ivar-lazzarodougwig: it totally was actually17:35
SumitNaiksatamhence we try to figure out during the last meeting whether we needed this meeting17:36
s3wongdougwig: I agree, let's put that on the next Neutron meeting agenda17:36
ivar-lazzarodougwig: my point was that I don't see the reason to wait for the split in order to have the APIs from day one17:36
SumitNaiksatamand the general consensus seemed to be that we did17:36
ivar-lazzarodougwig: split/refactor17:36
SumitNaiksatamperhaps this meeting is not as effective to get the buy in from people outside the adv services’ team17:36
dougwigi think we might be in vi/emacs land on the extensions point.  i don't seem much point in pulling over something that will just get broken.17:36
SumitNaiksatamso we should probably push that discussion to the main neutron meeting?17:36
s3wongSumitNaiksatam: +117:36
sbalukoffSumitNaiksatam: I thought this meeting was mostly about trying to drive consensus among the adv.. services team. :)17:37
banixSumitNaiksatam: yeah i really don’t know…. just raising the concern from past experience. yes may be neutron call may be the place to discuss17:37
sbalukoffIf we have a game plan, then we go to the Neutron meeting?17:37
dougwigwhen i roll a new version of the spec with some language around extensions alternatives, and we can chat about it in that meeting, sure.17:37
s3wongsbalukoff: and we just have a consensus to punt the decision to the Neutron meeting :-)17:37
xgerman_yeah, what's the game plan?17:37
dougwigman, that was bad grammar.17:37
dougwigon my part.17:37
xgerman_dougwig -- again we split things out. They brake - we fix it...17:38
bloganwell we still have disagreement here on the extensions17:38
blogannot a consensus17:38
sbalukoffblogan: Exactly.17:38
s3wongblogan: we have a consensus to talk about it during the Neutron meeting :-)17:38
*** SumitNaiksatam has quit IRC17:38
bloganlol17:38
sbalukoffWhat's the point in taking this to the Neutron meeting prematurely, when we don't even know what we want?17:38
s3wongand SumitNaiksatam is so angry that he quitted17:38
xgerman_sbalukoff +117:38
dougwigs3wong: ha.17:38
blogansbalukoff: one reason is to get more details17:39
*** SumitNaiksatam has joined #openstack-meeting-417:39
sbalukoffWoot! I'm totally taking credit for that ragequit.17:39
dougwigsbalukoff: because we've crossed the threshold of new debate and are cycling. it's either get more voices, or just let someone pick a direction.17:39
s3wongguys, I think we all would LOVE to get the extension split off also as step 1 if the Neutron cores are OK with it. Right?17:39
sbalukoffdougwig: Are you saying we need a fearless dicta.... er... leader?17:40
xgerman_s3wong +117:40
bobmels3wong: yes17:40
banixsbalukoff: Neutron core may have other ideas that will influence our plan…. waiting for a complete plan and then taking it to them will not work17:40
sbalukoff;)17:40
SumitNaiksatamsorry guys, my client acted up again17:40
xgerman_sbalukoff -10017:40
ivar-lazzaros3wong: I think it makes a lot of sense17:40
dougwigs3wong: no, i'd rather wait for the rest refactor, but it still be in kilo.17:40
bloganso I'm all for whatever gets the split done ASAP.  sounds to be like the extension debate would hinder that process17:40
_sunilso, lets propose that nd let them nack it...:)17:40
SumitNaiksatami typed in a bunch of stuff and went into /dev/null17:40
hareeshps3wong: +117:40
dougwigSumitNaiksatam: automatic rage filter.17:40
xgerman_lol17:40
ivar-lazzarodougwig: ahah17:40
SumitNaiksatamdougwig: ;-)17:40
s3wong:-)17:40
sbalukoffHeh!17:41
bloganis everyone afraid that if the extensions stayed in neutron tree then neutron will never give them up?17:41
SumitNaiksatamblogan: i dont think afraid is the right characterization17:41
sbalukoffbanix: I'm not saying make a plan and then present it to Neutron core to take it or leave it. They'll leave it, of course. What I'm saying is, we don't seem very unified here, so how are they supposed to work with that?17:41
xgerman_my fear is that they won't get merged17:42
s3wongblogan: I think the fear is that by suggesting extensions in advanced service repo, we can't do split until API refactor is done17:42
ivar-lazzaroblogan: personally, I'm concerned that we may not see issues in the refactor that we would see by having the extensions in the new repo from day one17:42
blogans3wong: but we can do the split without extensions17:42
SumitNaiksatamivar-lazzaro: +117:42
s3wongI think it is silly to think that Neutron cores would mandate the extensions to stay in Neutron repo once all DB/API/plugin/....etc are all split17:42
dougwigivar-lazzaro: issues seen on day one are irrelevant, though.17:42
banixsbalukoff: all I am suggesting that we should bring in those people from right now; if the meeting is not the right place we have to think of other ways to reach them.17:43
s3wongblogan: hence I am all for that IF the Neutron core team thinks that "it is best to wait for API refactoring"17:43
ivar-lazzarodougwig: That's not true, if we feel we need some capabilities from Neutron that it has missing now, then we can make the proposal at refactoring time17:43
SumitNaiksatamdougwig: but day one has to happen sooner, otherwise day one gets pushed to the new cycle17:43
ivar-lazzarodougwig: instead of finding it out later17:44
xgerman_s3wong you are on that core them use your jedi minbdtricks17:44
dougwigissues with extensions found on day 1 are quite literally code that won't exist in another few weeks.17:44
s3wongxgerman_: I am NOT on the core team --- nachi_uno and SumitNaiksatam are :-)17:44
xgerman_I always get confused17:44
SumitNaiksatambanix: yes i was responding earlier to your comment when i got dc'ed17:44
blogans3wong: me too, i just want it done and I don't see why neutron would benefit from having the extensions in neutron for a long time after the split, so I trust that they will move the extensions over in a reasonable time17:45
SumitNaiksatambanix: i think we need to have the larger neutron to be a part of this discussion17:45
bloganbut i am optimistic17:45
dougwigSumitNaiksatam: actually, i think that insisting on extensions from day one is what's going to push the split date.17:45
ivar-lazzarodougwig: yes, and if those issues persist even after the refactor you lost a cycle :)17:45
dougwigivar-lazzaro: neutron has other external extensions already.  this is not new ground.17:45
xgerman_+117:45
s3wongdougwig: if you really think so --- then there is no point insisting on having extensions from day one. The delay is the #1 thing we want to avoid17:46
SumitNaiksatamdougwig: i havent seen a good argument why extensions should not be a part of split from day one (techincally thats the right thing to do)17:46
sbalukoffAgreed.17:46
xgerman_+117:46
SumitNaiksatamdougwig: what i am hearing is that folks ouside this discussion would not agree to it17:47
ivar-lazzaros3wong: I actually don't see why it should hurt to make the proposal, we don't even know if this will really hold the split back17:47
xgerman_so we ask for it and if they make us wait we take it off the table17:47
ivar-lazzaroSumitNaiksatam: +117:47
s3wongivar-lazzaro: yes, so we want a consensus from the team:17:47
_sunilSumitNaiksatam: +117:47
s3wongthen (a) bring this issue to Neutron meeting17:47
dougwigi believe i brought up the fact that breaking refactor changes can happen inside one repo if they stay temporarily.  i consider that a good reason.17:47
s3wongand (b) if the Neutron core team thinks it is OK. We as a team would be happy to split extension also from day one17:48
dougwigs3wong: ok, let's do it.17:48
sbalukoffYay!17:48
SumitNaiksatamdougwig: it seems like the benefit of splitting out weighs the small window of downtime for that breaking17:48
_sunilwhat;s the worse that could happen?...:)17:48
bloganif splitting extensions out on day 1 does not delay the process I am all for it as well17:48
s3wongand (c) otherwise (if Neutron core team thinks it is best to delay until refactoring), we as a team agree to split WITHOUT extension from day one17:49
xgerman_ok, who decides if it delays?17:49
SridarKdougwig: and lets find out sooner what else is broken than wait to K -317:49
bloganSumitNaiksatam: could you enumerate the benefits?17:49
xgerman_ask that perosn17:49
ivar-lazzaroxgerman_: I think that's a community decision :)17:49
sbalukoffxgerman: Being told "wait for the refactor" is a delay.17:49
SumitNaiksatamblogan: i think ivar pointed out earlier - but splitting on day one gets us (technically) closer to where we eventually want to be17:50
sbalukoffYep.17:50
SumitNaiksatamblogan: so if there are issue they are weeded out early in the cycle as opposed to later (or never)17:50
SridarKSumitNaiksatam: +117:50
xgerman_I am just trying to be pragmatic -- and ivar-lazzaro obviously the community hathered here doesn't make the call17:50
ivar-lazzaroThere's a lot of stuff we can do by having the extensions in from day one (approving new APIs without being a burden on Neutron's core)17:51
xgerman_(assuming we have responsive cores)17:51
SumitNaiksatamivar-lazzaro: true that is the other big point here17:51
bloganwell those features are going to have to be approved by the drivers team anyway17:51
ivar-lazzaroThis will gain us enough time to justify the extra effort of fixing the refactor17:51
s3wongxgerman_: agreed, hence we bring it up in Neutron meeting. For those who are passionate about splitting extension from day one, please attend the next Neutron meeting to voice your opinions17:51
SridarKivar-lazzaro: now that is another unchartered territory. :-)17:51
SumitNaiksatamokay time check - 9 mins :-)17:52
SumitNaiksatamis pcm here?17:52
xgerman_also Neutron meeting is oin the middle of thenight for me17:52
bobmelSumitNaiksatam: PTO17:52
bloganso then another question, if neutron cores are determined to keep extensions in neutron for now and it will delay the split, do yall still want to hold out for the extensions?17:52
SumitNaiksatamxgerman_: :-)17:52
SridarKSumitNaiksatam: pcm pto17:52
s3wongxgerman_: but you don't have an opinion :-)17:52
xgerman_I feel like being banned from the polling place17:53
s3wongblogan: I think (hope) the consensus is that if we can't get Neutron cores to OK; then we split without extension on day one17:53
SumitNaiksatamblogan: i believe the opinion being expressed here is to put the extensions split on the table17:53
xgerman_+117:53
blogans3wong: me too17:53
mhanif+117:54
SumitNaiksatamblogan: and udnerstand why it cannot be done, if so17:54
s3wongblogan: I think it only makes sense --- I mean, dougwig already compromised :-)17:54
SumitNaiksatamit it cannot be done on day one, we try to understand what would be the alternate (and it be clearly mentioned in the spec in terms of timelines)17:54
bloganSumitNaiksatam: playing devil's advocate here, what if they don't give any "good" reason but still want to keep the extensions in? what is our recourse?17:55
SumitNaiksatam*if17:55
xgerman_mutany17:55
SumitNaiksatamblogan: :-)17:55
*** shwetaap1 has joined #openstack-meeting-417:55
SumitNaiksatami thought we were having a debate on a “technical” spec, silly me! ;-)17:55
ivar-lazzaroblogan: That's kind of a awkward scenario :D17:55
SumitNaiksatamokay time check again - 5 mins17:56
s3wongSumitNaiksatam: so I am good with that. We need to get the reasons from the opposing Neutron cores; and state that in spec; but if the Neutron community / cores/drivers think we should wait for API refactoring, we should NOT gate the split to wait for extension17:56
ivar-lazzaroI'm pretty sure there's a lot of good will between the 2 teams about the split, so the discussion will be held technically17:56
SumitNaiksatams3wong: i would suggest that we make a call based on the discussion in the spec17:56
SumitNaiksatamshall we transition to the “open discussion”17:57
bloganivar-lazzaro: very awkard indeed, but i just dont want us going down a path of creating a lot of friction with the neutron cores over this17:57
SumitNaiksatamand continue this discussion, in case nothing else is on anyone’s mind?17:57
SumitNaiksatamblogan: +10017:57
s3wongblogan: +117:57
SumitNaiksatami am not sure i have the chair any more, someone want to change the topic to “Open Discussion”?17:58
blogan#topic Open Discussion17:58
*** openstack changes topic to "Open Discussion (Meeting topic: Networking Advanced Services)"17:58
SumitNaiksatamblogan: thanks17:58
blogannp17:58
SumitNaiksatamanyone has any update on the flavors discussion (dougwig?)17:58
*** shwetaap has quit IRC17:59
s3wongSumitNaiksatam: too ambitious to do flavor in 2 minutes :-)17:59
bloganis dougwig re-proposing it?17:59
xgerman_yeah, we like flavors17:59
SumitNaiksatams3wong: yeah silly me again!17:59
*** mhanif has left #openstack-meeting-417:59
s3wongblogan: dougwig mentioned he is re-proposing in Kilo17:59
SumitNaiksatamblogan: i believe yes18:00
s3wong(during the last meeting)18:00
bloganok i thought so18:00
xgerman_yep, that's what he said18:00
*** dboik has joined #openstack-meeting-418:00
bloganhe gets to drag that boulder around now18:00
SumitNaiksatamokay we are at the hour18:00
xgerman_yep, some #chair close the meeting18:00
blogan#endmeeting18:00
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"18:00
openstackMeeting ended Tue Nov 25 18:00:54 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:00
openstackMinutes:        http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-11-25-17.05.html18:00
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-11-25-17.05.txt18:00
openstackLog:            http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-11-25-17.05.log.html18:01
bloganbye everyone18:01
*** nlahouti has left #openstack-meeting-418:01
bloganback to vacation18:01
blogan!18:01
s3wongbye18:01
ivar-lazzaroadieuu18:01
SumitNaiksatamthanks all for the spirited discussion ;-)18:01
_sunilbye18:01
SumitNaiksatamwe are all passionate about this!18:01
SumitNaiksatambye18:01
*** _sunil has quit IRC18:01
s3wongmestery just commented that the spec should NOT be about governance18:01
*** _sunil has joined #openstack-meeting-418:02
banixbye18:02
s3wong(good way to close the meeting :-) )18:02
xgerman_bye18:02
*** _sunil has left #openstack-meeting-418:02
hareeshpbye!18:02
SridarKbye18:02
*** xgerman_ has left #openstack-meeting-418:02
*** ivar-laz_ has joined #openstack-meeting-418:03
*** hareeshp has quit IRC18:05
*** ivar-lazzaro has quit IRC18:06
*** SridarK has quit IRC18:11
*** ivar-laz_ has quit IRC18:12
*** ivar-lazzaro has joined #openstack-meeting-418:12
*** SridharRamaswamy has joined #openstack-meeting-418:14
*** vjay-ns has quit IRC18:20
*** SridharRamaswam1 has joined #openstack-meeting-418:32
*** vishwana_ has joined #openstack-meeting-418:32
*** shwetaap1 has quit IRC18:32
*** SridharRamaswamy has quit IRC18:32
*** vishwan__ has quit IRC18:33
*** jamiem has quit IRC18:36
*** vishwan__ has joined #openstack-meeting-418:49
*** vishwana_ has quit IRC18:52
*** ivar-lazzaro has quit IRC18:58
*** dboik_ has joined #openstack-meeting-418:58
*** ivar-lazzaro has joined #openstack-meeting-418:59
*** dboik_ has quit IRC18:59
*** dboik_ has joined #openstack-meeting-418:59
*** ivar-lazzaro has quit IRC19:00
*** ivar-lazzaro has joined #openstack-meeting-419:00
*** vishwana_ has joined #openstack-meeting-419:01
*** dboik has quit IRC19:01
*** vishwan__ has quit IRC19:04
*** ivar-laz_ has joined #openstack-meeting-419:04
*** SridharRamaswam1 has quit IRC19:06
*** ivar-lazzaro has quit IRC19:08
*** SridharRamaswamy has joined #openstack-meeting-419:09
*** vishwana_ has quit IRC19:20
*** ivar-laz_ has quit IRC19:31
*** ivar-lazzaro has joined #openstack-meeting-419:32
*** sbalukoff has quit IRC19:34
*** ChuckC has quit IRC19:40
*** vishwana_ has joined #openstack-meeting-419:43
*** vishwana_ has quit IRC19:47
*** vishwana_ has joined #openstack-meeting-419:56
*** vishwan__ has joined #openstack-meeting-419:59
*** SridharRamaswamy has quit IRC19:59
*** vishwana_ has quit IRC20:00
*** ChuckC has joined #openstack-meeting-420:01
*** dboik has joined #openstack-meeting-420:02
*** dboik_ has quit IRC20:02
*** vishwan__ has quit IRC20:09
*** vishwana_ has joined #openstack-meeting-420:10
*** vishwana_ has quit IRC20:15
*** ChuckC_ has joined #openstack-meeting-420:28
*** dboik_ has joined #openstack-meeting-420:31
*** ChuckC has quit IRC20:32
*** dboik_ has quit IRC20:32
*** dboik_ has joined #openstack-meeting-420:32
*** dboik has quit IRC20:35
*** igordcard has joined #openstack-meeting-420:40
*** banix has quit IRC20:54
*** dboik_ has quit IRC20:55
*** dboik has joined #openstack-meeting-420:56
*** nikhil_k|vacay is now known as nikhil_k21:01
*** vishwana_ has joined #openstack-meeting-421:07
*** vishwan__ has joined #openstack-meeting-421:11
*** vishwana_ has quit IRC21:14
*** sbalukoff has joined #openstack-meeting-421:31
*** nikhil_k is now known as nikhil_k|vacay21:56
*** SridharRamaswamy has joined #openstack-meeting-422:00
*** SridharRamaswam1 has joined #openstack-meeting-422:09
*** SridharRamaswamy has quit IRC22:09
*** dboik_ has joined #openstack-meeting-422:18
*** dboik has quit IRC22:22
*** dboik_ has quit IRC22:22
*** SridharRamaswam1 has quit IRC22:41
*** vishwan__ has quit IRC22:54
*** SridharRamaswamy has joined #openstack-meeting-423:01
*** banix has joined #openstack-meeting-423:02
*** neatherweb has joined #openstack-meeting-423:08
*** s3wong has quit IRC23:08
*** dboik has joined #openstack-meeting-423:41
*** dboik_ has joined #openstack-meeting-423:42
*** dboik has quit IRC23:46
*** igordcard has quit IRC23:46

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!