Wednesday, 2014-04-16

*** sarob has quit IRC00:01
*** ChanServ changes topic to "OpenStack Meetings ||"00:02
*** SumitNaiksatam has quit IRC00:23
*** eguz has quit IRC00:45
*** dstanek has quit IRC01:29
*** dstanek has joined #openstack-meeting-301:32
*** david-lyle has joined #openstack-meeting-301:36
*** cjellick has quit IRC01:50
*** david-lyle has quit IRC02:03
*** alexpilotti has quit IRC02:13
*** coolsvap|afk is now known as coolsvap02:35
*** sarob has joined #openstack-meeting-303:01
*** sarob has quit IRC03:06
*** lcheng has joined #openstack-meeting-303:21
*** beyounn has quit IRC03:23
*** Sukhdev has joined #openstack-meeting-303:30
*** SumitNaiksatam has joined #openstack-meeting-303:33
*** lcheng has quit IRC03:44
*** lcheng has joined #openstack-meeting-303:51
*** sarob has joined #openstack-meeting-304:02
*** lcheng has quit IRC04:05
*** sarob has quit IRC04:07
*** lcheng has joined #openstack-meeting-304:10
*** saju_m has joined #openstack-meeting-304:27
*** saju_m has quit IRC04:27
*** coolsvap is now known as coolsvap|afk04:35
*** dstanek has quit IRC04:39
*** dstanek has joined #openstack-meeting-304:40
*** wchrisj has quit IRC04:43
*** coolsvap|afk is now known as coolsvap04:52
*** dstanek has quit IRC04:55
*** Sukhdev has quit IRC04:57
*** sunrenjie6 has joined #openstack-meeting-304:57
*** lcheng has quit IRC04:57
*** lcheng has joined #openstack-meeting-305:02
*** sarob has joined #openstack-meeting-305:03
*** sarob has quit IRC05:08
*** HenryG_ has joined #openstack-meeting-305:54
*** jcoufal has joined #openstack-meeting-305:55
*** lblanchard has joined #openstack-meeting-305:55
*** HenryG has quit IRC05:57
*** lcheng has quit IRC05:57
*** sdague has quit IRC05:58
*** lcheng has joined #openstack-meeting-305:59
*** sarob has joined #openstack-meeting-306:04
*** sdague has joined #openstack-meeting-306:05
*** sarob has quit IRC06:08
*** lblanchard has quit IRC06:11
*** safchain has joined #openstack-meeting-306:15
*** lcheng has quit IRC06:17
*** dstanek has joined #openstack-meeting-306:22
*** lcheng has joined #openstack-meeting-306:23
*** lpetrut has joined #openstack-meeting-306:24
*** dstanek has quit IRC06:27
*** jcoufal has quit IRC06:38
*** lcheng has quit IRC06:39
*** MaxV_ has joined #openstack-meeting-307:00
*** jcoufal has joined #openstack-meeting-307:02
*** sarob has joined #openstack-meeting-307:05
*** sarob has quit IRC07:10
*** MaxV_ has quit IRC07:12
*** beyounn has joined #openstack-meeting-307:13
*** ttrifonov_zZzz is now known as ttrifonov07:15
*** MaxV_ has joined #openstack-meeting-307:16
*** MaxV_ has quit IRC07:23
*** ryanpetrello has quit IRC07:40
*** nacim has joined #openstack-meeting-307:43
*** ryanpetrello has joined #openstack-meeting-307:44
*** MaxV_ has joined #openstack-meeting-307:59
*** jtomasek has joined #openstack-meeting-307:59
*** sarob has joined #openstack-meeting-308:06
*** MaxV_ has quit IRC08:08
*** ryanpetrello has quit IRC08:09
*** sarob has quit IRC08:11
*** ryanpetrello has joined #openstack-meeting-308:11
*** beyounn has quit IRC08:22
*** dstanek has joined #openstack-meeting-308:24
*** dstanek has quit IRC08:28
*** lpetrut has quit IRC08:30
*** MaxV_ has joined #openstack-meeting-308:35
*** lpetrut has joined #openstack-meeting-308:38
*** lpetrut has quit IRC08:43
*** eghobo has joined #openstack-meeting-308:51
*** sarob has joined #openstack-meeting-309:07
*** sarob has quit IRC09:12
*** overlayer has joined #openstack-meeting-309:13
*** alexpilotti has joined #openstack-meeting-309:16
*** persia has quit IRC09:25
*** persia has joined #openstack-meeting-309:28
*** persia is now known as Guest9004309:29
*** Guest90043 has quit IRC09:29
*** Guest90043 has joined #openstack-meeting-309:29
*** Guest90043 is now known as persia09:29
*** dstanek has joined #openstack-meeting-309:45
*** dstanek has quit IRC10:00
*** sarob has joined #openstack-meeting-310:08
*** sarob has quit IRC10:13
*** eghobo has quit IRC10:21
*** mestery_ has joined #openstack-meeting-310:33
*** mestery has quit IRC10:36
*** sunrenjie6 has quit IRC10:37
*** overlayer has quit IRC10:46
*** sarob has joined #openstack-meeting-311:09
*** sarob has quit IRC11:15
*** coolsvap is now known as coolsvap|afk11:15
*** dstanek has joined #openstack-meeting-311:33
*** sarob has joined #openstack-meeting-312:10
*** sarob has quit IRC12:15
*** alexpilotti has quit IRC12:15
*** overlayer has joined #openstack-meeting-312:39
*** HenryG_ has quit IRC12:44
*** mfer has joined #openstack-meeting-312:58
*** HenryG has joined #openstack-meeting-313:08
*** sarob has joined #openstack-meeting-313:11
*** alexpilotti has joined #openstack-meeting-313:14
*** sarob has quit IRC13:16
*** dstanek_afk has joined #openstack-meeting-313:21
*** mestery_ is now known as mestery13:22
*** dstanek has quit IRC13:23
*** amotoki has quit IRC13:32
*** peristeri has joined #openstack-meeting-313:34
*** wchrisj has joined #openstack-meeting-313:34
*** dstanek_afk is now known as dstanek13:35
*** dtroyer has left #openstack-meeting-313:39
*** xuhanp has joined #openstack-meeting-313:51
*** wchrisj has left #openstack-meeting-313:53
*** sarob has joined #openstack-meeting-314:12
*** dstanek has quit IRC14:14
*** sarob has quit IRC14:17
*** overlayer has quit IRC14:29
*** dstanek has joined #openstack-meeting-314:30
*** mwagner_lap has quit IRC14:47
*** coolsvap|afk is now known as coolsvap14:51
*** sarob has joined #openstack-meeting-315:13
*** jamie_h has joined #openstack-meeting-315:13
*** sarob has quit IRC15:18
*** samchoi has joined #openstack-meeting-315:18
*** dstanek has quit IRC15:22
*** dstanek has joined #openstack-meeting-315:23
*** cjellick has joined #openstack-meeting-315:28
mfer#startmeeting openstack-sdk-php15:30
openstackMeeting started Wed Apr 16 15:30:05 2014 UTC and is due to finish in 60 minutes.  The chair is mfer. Information about MeetBot at
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:30
*** openstack changes topic to " (Meeting topic: openstack-sdk-php)"15:30
openstackThe meeting name has been set to 'openstack_sdk_php'15:30
mferHello everyone. If you couple please state your name along with any association15:30
mferMatt Farina, HP15:30
samchoiSam Choi, HP15:30
jamie_hJamie Hannaford, Rackspace15:30
ycombinatorShaunak Kashyap, Rackspace15:30
glencGlen Campbell, Rackspace15:31
*** amotoki has joined #openstack-meeting-315:32
mfer#topic Agenda15:32
*** openstack changes topic to "Agenda (Meeting topic: openstack-sdk-php)"15:32
mferI updated the agenda on the Wiki. It's simliar to the last one.15:33
*** sjmc7 has joined #openstack-meeting-315:33
mferThe first item was an intro if anyone new came. As it's the regular attenders I don't think we need to introduce the PHP SDK and can skip that item15:33
mferSo, let's move tot he second item15:34
mfer#topic State of the codebase15:34
*** openstack changes topic to "State of the codebase (Meeting topic: openstack-sdk-php)"15:34
mferSince we spoke last Wednesday I did a bunch of due diligence. I spoke with others in the community about process, community, history, and looked through other projects for examples15:35
mferSo, it's taken a little time to do this legwork. Thanks for being patient with me. I wanted to get some good well rounded guidance.15:35
mferIn the community sense I didn't want to make any decisions without doing the legwork and taking time to contact others with more experience15:36
mferthat includes going outside HP. Please don't think that I only spoke with others at HP. I wanted a wider perspective than that15:36
mferI want the PHP SDK to be something that helps OpenStack and those that use it.15:37
mferAll that being said...15:37
mferMy stance is to keep the current codebase and continue on the path of re-factoring to better support OpenStack. We have a roadmap that will get us there.15:38
jamie_hsamchoi What do you think, Sam?15:38
*** Sukhdev has joined #openstack-meeting-315:39
mferI'd shared that if there was a better technological solution (measurable?) or a way to get there for OpenStack far faster we should talk about it. In the past few weeks since this came up a case has not been made for that.15:39
mferquestions or other discussion on this point?15:40
mferi'm happy to add context as needed.15:40
jamie_hmfer Did you read the e-mail I sent Sam? How do you respond to the three very strong points made there15:42
samchoiMy take on all of this is that I believe that using the current codebase would be the fastest route to make a pure OpenStack SDK available. I also understand there may be dissenting opinions on design/architecture. To be quite honest, I am not so concerned with debating design/architecture and believe a compromise may be to allow other contributors to get involed and make significant changes when necessary.15:43
glencWell, I disagree that it would get us broader support for OpenStack faster. If, for example, we used php-opencloud as a base, we'd have support for Nova, Swift, and Trove already, plus Heat in progress and some others. The current code base only supports Swift. Both cases would require refactoring. Plus, it already supports Guzzle. We need to understand that this decision involves stepping back and re-doing work that already exists.15:44
mferjamie_h I did see the email. I used is as a starting point for some of my research. I wanted to be able to clearly understand each point. My goal is to think long term best for the community, those that use the SDK, and the project itself.15:44
glencHaving said that, this decision has already cost us some number of man-months. No matter what the decision, if we had made a decision earlier, we would be further along.15:44
mferglenc if you don't mind i'd like to address jamie_h before i circle back to your comment. i want you do know that i'm not forgetting it but i want touch there first.15:45
jamie_hmfer I don't understand your counter-argument to our main point about community process. All code needs to be approved through Gerrit - that's a very foundational point about contributing to OpenStack. I don't see how consulting people on a few non-OpenStack projects gets around or addresses this issue...15:46
mferjamie_h the first point you brought up was the community angle. For our code we'd long used a process similar to what we do in Gerrit. So, when the codebase was put into Stackforge it was a transition not a change of pace.15:46
mferif you look at a majority of projects to come into the community they start with an existing codebase that's imported. the infra process to create a new project as a mechanism to pull in an existing codebase when it's setup. it's automated15:47
jamie_hmfer sure, but none of the code was submitted through Gerrit. What you did before that is moot15:47
mferall code that's come in since that import has gone through gerrit. this is typical.15:47
jamie_hmfer but we're not talking about generic projects, we're integrating into a very established larger project with rules15:48
mferyou can look at other example projects like barbacon, from Rackspace, and can see this in practice15:48
jamie_hmfer new code has, but the vast majority of existing code has not been reviewed15:48
jamie_hI've yet to hear a good reason to break OpenStack rules/protocol15:48
jamie_hapart from "it'll be faster"15:49
mferfrom doing my due diligence here, the way this is handled is within the rules/protocols.15:49
mferthis is how other projects have gone in. Even project started by those at Rackspace15:49
jamie_hthe python SDK doesn't15:49
mferthis is not stepping outside the process or what happens in practice15:49
jamie_hit is, because we're inheriting a codebase that's not gone through any review process15:50
mferthe python SDK is an outlier from the norm.15:50
*** mwagner_lap has joined #openstack-meeting-315:51
jamie_hI disagree. It's taking a very sensible and democratic approach15:51
mferSo, for the first point... we're holding to the process and what has typically happened.15:51
jamie_hNo, we're really not. Allowing unreviewed code is a clear breach of standard protocol15:51
mferjamie_h may I test your point quickly. So, when barbacon was brought in should all of the code been removed and the project started from scratch. it was an existing codebase that was importent.15:52
mferplease note, we've invited you and others to review the current codebase and file any issues found that are not already filed15:53
jamie_hI'm not familiar with how older projects did things, I'm focusing on how we do it according to present rules15:54
*** cjellick has quit IRC15:55
mfercan you point me to these present rules in writing? as of now I've heard your opinion on how we should do things. but, i've gone to others in the community with a lot of insight into the rules and the way the community operates now and historically.15:55
*** cjellick has joined #openstack-meeting-315:56
mferwhat i've learned is that this approach is appropriate15:56
jamie_hmfer who exactly did you consult in the community? Have they had much exposure to OpenStack workflow?15:58
jamie_hMy point is that a typical PHP project, for example, might have a different workflow than OpenStack15:58
mferi'm not going to share names because I didn't ask them first. I will say I spoke to folks on the TC and who are PTLs15:59
samchoijamie_h: can you elaborate on that?15:59
mferjamie_h and others who have experience in the community outside that15:59
*** banix has joined #openstack-meeting-316:00
samchoijamie_h: you're referring to PHP projects outside of OpenStack, correct?16:01
*** persia has quit IRC16:02
*** persia has joined #openstack-meeting-316:02
*** persia has quit IRC16:02
*** persia has joined #openstack-meeting-316:02
mfergiven the time and that the conversation on this point seems to have stopped i'll move on to the second point of community16:02
*** eghobo has joined #openstack-meeting-316:03
jamie_hI don't think we've reached consensus yet16:03
mferjamie_h at what point will we reach concensus?16:03
jamie_hI don't agree with any of the counter-points made here, but I agree that we need to move forward16:04
mferwe have 27 minutes left in this meeting, there are two other areas, and the question from glenc16:04
ycombinatorwhat jamie_h said16:04
jamie_hThis is my opinion:16:04
ycombinatorI think we need to move on16:04
samchoilet's try to address the other topics quickly and come back to this?16:04
jamie_hI'm content to use the current codebase on the sole condition that everyone's open to the idea of aggressive refactoring16:05
samchoijamie_h: that was my thought actually...I felt it to be a good compromise16:05
ycombinatoryeah, I'm not seeing another way forward16:05
mferjamie_h that's what we've been doing. the roadmap assumes that.16:06
jamie_hI don't want to be in a position were we're implicitly agreeing on the current code. So if we agree to allow people to refactor parts, it's a decent compromise16:06
mferyou'll notice it has guzzle4 support already16:06
jamie_hSure, but I didn't know whether people might cling to certain existing concepts or areas of code16:06
jamie_hBy being in the codebase they'll already have quasi-approval16:06
mferthere are definitely patterns to keep in the current code and to expand on. but, there are other things that need to change.16:06
mferfor example, we are working to make PSR-2 happen, we use http messages from FIG and guzzle as a default (a suggestion from jamie_h), and more16:07
jamie_hOkay, I'm satisfied here. Shaunak and Glen, do you have anything else to add?16:07
ycombinatorno, lets move on16:08
mferI'm happy to address the point from Glen still if needed16:08
glencno need to address -16:08
glencwas just making the point that IMHO this is *not* the fastest way to get working code, but willing to defer that and use a slower path to get us moving16:08
ycombinatoryeah, I think the time we are losing in figuring out fastest path > choosing A path and moving on16:09
ycombinatorso lets move on :)16:09
mferglenc note, we have a much larger codebase that implements many other services. we have months and months and months of work on that. not contributing all of that back at the onset was intentional so we could refactor things. for example, to handle multiple API versions. something that I've only seen done well in the openstack client projects16:10
mfershall we move on to the near term roadmap?16:10
jamie_hThat's untrue, we actually have a considerably bigger codebase with more public support. But this is not really important after what we've just agreed on16:10
jamie_hYeah, let's move on16:11
ycombinatoryeah, lets not rehash this; mfer: please move on to the near term roadmap16:11
glencNot willing to argue the point; would rather move on16:11
mfer#topic Near term roadmap16:12
*** openstack changes topic to "Near term roadmap (Meeting topic: openstack-sdk-php)"16:12
*** ttrifonov is now known as ttrifonov_zZzz16:12
mferas per my action from the last meeting, I linked the blueprints to the roadmap16:12
mferThe guzzle 4 work and phpdoc change has already been completed16:13
mfernext up, and not on here but happening, is the shift to PSR-2 that samchoi is working on16:13
jamie_hsamchoi how are you getting on with PSR-2?16:13
samchoigood, I'm reviewing diff logs from an automated tool16:13
samchoiI'm primarily checking to see if certain coding conventions are NOT addressed by the tool16:14
*** sarob has joined #openstack-meeting-316:14
samchoibut all good thus far16:14
jamie_hif you use PhpStorm, you can do it with that too. It has a neat reformatting tool16:15
jamie_hyou can do it across a project directory16:15
mferthe next item to tackle once that is done is to add multiple api version support. i'd hoped to have that done but went after Guzzle first after you suggested it.16:17
jamie_hmfer I think that's related to the service layer. I want to get stuck into that next week. I've nearly finalized my experimentation with json-schema, so it's at a point were we can think incorporating it16:18
mferi've been talking with others who've worked on doing this support in other clients on the lessons they've learned16:19
*** sarob has quit IRC16:19
jamie_h - but this might not be anything like what we could end up using16:19
mferi had something in mind that would work within json schema while taking their feedback into account. i'm curious to see what you've got brewing and why16:19
mferjamie_h i'll go poke around at that this afternoon16:19
jamie_hmfer okay. It's effectively a validator and parser for consuming schemas - but as I've said, it might not look anything like what we end up using. Just a strawman16:20
mferwhile i look forward to chatting with you about it we have 9 minutes left. you mind if we take that off meeting?16:21
mferonce those areas are done we can move into extensions and service discovery while mroe services are being added and documented16:22
mferthere is an upcoming bottleneck of work and they we can do more in parallel16:22
mferis there any questions on the roadmap?16:23
*** xuhanp has quit IRC16:23
jamie_hI don't have any16:23
samchoiroadmap is clear, but I'd like further clarification later on what we plan to do now (the "bottlenecks") before getting to a point where we're able to add new services in parallel16:24
samchoibut we can chat later16:24
mfer#topic Bugs / Reviews16:24
*** openstack changes topic to "Bugs / Reviews (Meeting topic: openstack-sdk-php)"16:24
mferthere are two closely related bugs and nothing currently in review16:24
mferthe two bugs are on Sams plate to done once the PSR-2 work is complete.16:25
mferif there is no discussion on this we can move to open discussion.16:25
mferthe bug has to do with a default for a region name. we can't assume a default for broader openstack16:26
mfer#topic open discussion16:26
*** openstack changes topic to "open discussion (Meeting topic: openstack-sdk-php)"16:26
mferwe've got about 4 minutes until the next meeting IIRC16:26
*** tjones has joined #openstack-meeting-316:27
jamie_hI have nothing else to add, I think we covered the most important things during the codebase discussion16:27
*** MaxV_ has quit IRC16:28
ycombinatoryeah, I'm good too16:28
glencFYI I'm out next week16:29
glencI'm sure you can carry on without me LOL16:29
*** browne has joined #openstack-meeting-316:29
tjonesyou guys done?  i've got to start up the next meeting.  sorry to kick you out16:30
*** jogo has joined #openstack-meeting-316:30
samchoithink we're good16:30
glencNot sure what happened to mfer16:30
*** openstack changes topic to "OpenStack Meetings ||"16:30
openstackMeeting ended Wed Apr 16 16:30:57 2014 UTC.  Information about MeetBot at . (v 0.1.4)16:30
jamie_hokay, thanks everyone. Speak next week16:30
openstackMinutes (text):
tjones#startmeeting NovaBugScrub16:31
openstackMeeting started Wed Apr 16 16:31:13 2014 UTC and is due to finish in 60 minutes.  The chair is tjones. Information about MeetBot at
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:31
*** openstack changes topic to " (Meeting topic: NovaBugScrub)"16:31
openstackThe meeting name has been set to 'novabugscrub'16:31
tjoneshi - anyone around?16:31
dansmithI'm peripherally around16:31
tjoneslurker ;-)16:31
* jogo lurks16:31
dansmithyes, lurking creepily in the shadows16:31
tjonesand another one :-D16:32
tjonesgonna be a short meeting today - i've been tagging things every day when i get a minute16:32
tjonesjust 4 this am16:32
tjonesso lets quickly get through them16:32
dansmithtjones: the pci one, talk to yjiang516:33
tjonesthis one is the spice console - so "console"?16:33
tjonesdansmith: ok will do on that one16:33
tjonesi am not sure this is true16:35
dansmithI don't know,16:36
dansmithbut that guy has fixed some things recently,16:36
dansmithso I'm sure he'll engage, and he set himself as the assignee16:36
tjonesok but should the quota be decremented if this is no valid host?16:36
dansmithI don't know16:36
dansmithI would think that post-delete it would be decremented16:37
tjonesok i'll leave it with compute.16:37
tjonesso that is it.16:37
tjonesi have not done anything with my action item on figuring out how to track stale and "unofficial" tagged bugs in this meeting.  that is what we thought we should focus on next16:38
tjonesso i'll try to get to that next week.16:38
tjonesany other items?16:38
dansmithtjones: one more week or you're fired!16:38
dansmithjust kidding firing you from this job would be crazy stupid :)16:38
tjonesbut it's so much fun ;-)16:38
*** sjmc7 has left #openstack-meeting-316:39
dansmithbecause you're a masochist :)16:39
tjonespeople are clambering for this job16:39
dansmithpfft, yeah right :)16:39
tjonesso if there is nothing else we can fiinish early :-D16:39
tjonesmy favorite kind of meeting16:39
*** openstack changes topic to "OpenStack Meetings ||"16:40
openstackMeeting ended Wed Apr 16 16:40:22 2014 UTC.  Information about MeetBot at . (v 0.1.4)16:40
openstackMinutes (text):
*** jogo has left #openstack-meeting-316:42
*** jcoufal has quit IRC16:43
*** browne has left #openstack-meeting-316:46
*** tjones has left #openstack-meeting-316:55
*** wendar has quit IRC16:59
*** wendar has joined #openstack-meeting-317:01
*** nacim has quit IRC17:03
*** rkukura has joined #openstack-meeting-317:06
*** safchain has quit IRC17:10
*** eghobo has quit IRC17:11
*** eghobo has joined #openstack-meeting-317:11
*** beyounn has joined #openstack-meeting-317:13
*** shivharis has joined #openstack-meeting-317:17
*** david-lyle has joined #openstack-meeting-317:20
*** Sukhdev has quit IRC17:21
*** amotoki has quit IRC17:23
*** hemanthravi has joined #openstack-meeting-317:27
*** overlayer_ has joined #openstack-meeting-317:30
*** prasadv_ has joined #openstack-meeting-317:30
*** s3wong has joined #openstack-meeting-317:30
cgoncalveshowdy advanced services team members!17:31
SumitNaiksatamcgoncalves: hi!17:31
*** sweston has joined #openstack-meeting-317:31
overlayer_cgoncalves, hello17:31
SumitNaiksatamany other Neutrons out here?17:31
s3wongHas the meeting started?17:31
prasadv_hi there17:32
cgoncalvesSumitNaiksatam, overlayer_: hi17:32
SumitNaiksatams3wong: hi, not yet, just waiting for critical mass to aggregate17:32
SumitNaiksatamprasadv_: hi17:32
*** Kanzhe has joined #openstack-meeting-317:32
SumitNaiksatamenikanorov_ kevinbenton : hi17:32
s3wongOh, in that case. Hello17:32
*** samchoi has quit IRC17:32
SumitNaiksatamkevinbenton: you trailblazer! ;-)17:32
swestonI'm here, btw the wiki has the wrong link ;-)17:33
SumitNaiksatamrkukura Kanzhe sweston: hi17:33
SumitNaiksatamsweston: wiki?17:33
SumitNaiksatamsweston: got it, the two hashes17:34
SumitNaiksatamsweston: feel free to fix it17:34
SumitNaiksatambanix: hi, lets get started17:34
swestonyup yup, or just one yup17:34
SumitNaiksatam#startmeeting Networking Advanced Services17:34
openstackMeeting started Wed Apr 16 17:34:30 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:34
banixSumitNaiksatam: hi17:34
*** openstack changes topic to " (Meeting topic: Networking Advanced Services)"17:34
openstackThe meeting name has been set to 'networking_advanced_services'17:34
SumitNaiksatam#info the new blueprint review process is in effect for neutron17:35
*** david-lyle has quit IRC17:35
SumitNaiksatamso if your bleuprint is not already in approved state, you will need to go through this process for approval17:35
SumitNaiksatami know this is already stale news to some ;-)17:36
SumitNaiksatamso our standing item for this meeting:17:36
SumitNaiksatam#topic Flavors Framework17:36
*** openstack changes topic to "Flavors Framework (Meeting topic: Networking Advanced Services)"17:36
enikanorov_yeah, so far no major updates17:37
SumitNaiksatamenikanorov_ also sent out an email a couple of days back on this: #link
enikanorov_i'd love to try to apply the idea to some service17:37
enikanorov_but i'm really blocked with that17:37
SumitNaiksatamenikanorov_: you could have tried on FWaaS, but it does not have STF17:38
enikanorov_what i'm interested in is the STF being integrated in fwaas or vpnaas17:38
SumitNaiksatamenikanorov_: otherwise FWaaS is good candidate since it has some vendor drivers as well17:38
enikanorov_SumitNaiksatam: i may try to rebase on that patch...17:38
SumitNaiksatamokay back to the email which enikanorov_ sent, essentially it proposes keeping the existing service provider framework for the backend17:39
SumitNaiksatamenikanorov_: ok sure17:39
enikanorov_on STF: yes, but not expose it to API17:39
SumitNaiksatamenikanorov_: yes17:39
SumitNaiksatamso any thoughts from the folks here on the provider part?17:40
SumitNaiksatamin case you got a chance to read through what enikanorov_ is proposing17:40
enikanorov_i'm also concerned about the flavor format17:40
SumitNaiksatamenikanorov_: sure, had some discussions on that17:41
enikanorov_right now it is a list of k,v pairs17:41
enikanorov_which is not exactly tags17:41
enikanorov_but i think that may simplify builind UI around that17:41
SumitNaiksatamenikanorov_: i think k,v is good17:41
enikanorov_raw tags might be confusing17:41
SumitNaiksatamenikanorov_: but there are at least three sets of these k,v17:42
hemanthravienikanorov_: tags would be known k?17:42
SumitNaiksatamenikanorov_: those that are common to the neutron services’ framework17:42
enikanorov_SumitNaiksatam: why three sets?17:42
*** s3wong has quit IRC17:42
*** Swami has joined #openstack-meeting-317:42
SumitNaiksatamenikanorov_: (2) those that are common to a service type17:42
enikanorov_hemanthravi: not necessarily17:42
enikanorov_i think the part of the solution is vendor drivers exporting those pairs to the plugin17:43
SumitNaiksatamenikanorov_: and (3) those that differentiate between different service instances of the same service type17:43
enikanorov_ah, i see17:43
enikanorov_yes, seems so17:43
SumitNaiksatamenikanorov_: i would think that the vendor specific would fall into the third category17:43
*** jsoares has joined #openstack-meeting-317:44
SumitNaiksatamenikanorov_: your earlier point about raw tags, i believe, is in the context of the lack of this classification17:44
*** s3wong has joined #openstack-meeting-317:44
SumitNaiksatamenikanorov_: for keys, defined in sets 1 and 2, there would be more semantics attached (they would be well defined) hence people would know how to use them17:44
*** sarob has joined #openstack-meeting-317:45
SumitNaiksatamthat said, finding a common set for (1) and (2) can be a challenging exercise :-)17:45
enikanorov_well, it seems to be a problem of setting the defaults17:45
SumitNaiksatamenikanorov_: sure17:46
enikanorov_i mean that flavors themselves are created by cloud operator17:46
enikanorov_so user mostly unaffected17:46
enikanorov_and then we can add types of tags as we go17:46
enikanorov_i mean add hardcoded types17:46
enikanorov_which fall into (1)17:46
SumitNaiksatamenikanorov_: ok17:46
enikanorov_*(1) and (2)17:47
SumitNaiksatamother folks have thoughts on the tags (or k,v as we are referring to them here)?17:47
SumitNaiksatamthey will essentially define the flavor17:47
SumitNaiksatam*flavor choice17:47
SumitNaiksatamenikanorov_: so as a next step you said you wanted to take a crack at implementing this on fwaas?17:48
enikanorov_so... i'll had to push this design on gerrit then :)17:48
enikanorov_yes, I can try, on top of STF for fwaas17:49
Kanzheenikanorov_: SumitNaiksatam Is there a first set of k,v pairs for 1 and 2?17:49
SumitNaiksatamenikanorov_: ok great17:49
hemanthravithe k,v are also defined by the cloud operator when creating the flavors17:49
SumitNaiksatamhemanthravi: yes, the point is that there has to be a base set for which there is common understanding across the project17:50
enikanorov_one important part of the whole solution is the scheduling part17:50
enikanorov_i hope everyone gets it right17:50
SumitNaiksatamKanzhe: perhaps once enikanorov_ put this bp in gerrit we can comment on what the base set would include17:50
SumitNaiksatamenikanorov_: please go ahead17:50
enikanorov_so on scheduling: it's a two step process17:51
s3wongenikanorov_: is the scheduling part done by individual services?17:51
enikanorov_first step matches flavor to a capabilities of the vendor driver17:51
enikanorov_s3wong: yes17:51
enikanorov_second step is internal, driver does that. it maps flavor to the capabilities of appliances that it manages17:51
enikanorov_it can happen that driver doesn't manage appliances, then step #2 is skipped17:52
SumitNaiksatamenikanorov_: i believe first step is done in the service plugin?17:52
enikanorov_SumitNaiksatam: yes.17:52
enikanorov_the result of step #1 is ProviderResourceMapping entry created for the resource17:52
SumitNaiksatamenikanorov_: ok17:52
enikanorov_the result of step #2 is ApplianceResourceMappign entry17:53
s3wongenikanorov_: so vendors have to expose a set of capabilities? Or is it more like ML2 where each driver would come back and tell if it has all the capabilities?17:53
SumitNaiksatamenikanorov_: can that entry be updated if the resource has to be moved somewhere else?17:53
enikanorov_s3wong: yes17:53
*** overlayer_ has quit IRC17:53
enikanorov_SumitNaiksatam: you mean user requests another capabilities?17:53
enikanorov_s3wong: first option.17:54
enikanorov_SumitNaiksatam: in that case resource can be rescheduled17:54
SumitNaiksatamenikanorov_: no user interaction involved, just that the operator might want to move things around/optimize17:54
*** markmcclain has joined #openstack-meeting-317:54
*** amrith is now known as notamrcn17:54
enikanorov_yes, it can be updated, both entries17:55
SumitNaiksatamenikanorov_: ok good17:55
SumitNaiksatamKanzhe: did you have any particular keys/tags in mind?17:55
SumitNaiksatamwe had defined a bunch of them when the initial discussion on STF was going on, and I had put it on the wiki17:55
enikanorov_yeah, that would be good if you guys could help me to gather initial set of tags17:55
SumitNaiksatamhaving trouble finding it now, would have to look into the history17:56
*** markmcclain1 has joined #openstack-meeting-317:56
SumitNaiksatamokay, any more questions for enikanorov_ today?17:56
*** d0ugal has quit IRC17:56
KanzheSumitNaiksatam: serviceContext may need a pair to derive insertion type. I will wait for enikanorov_ to put the initial draft.17:56
SumitNaiksatamKanzhe: ok17:57
SumitNaiksatamenikanorov_: thanks, we will look forward to your bp in gerrit17:57
SumitNaiksatam#topic Port Chaining Proposal17:57
*** openstack changes topic to "Port Chaining Proposal (Meeting topic: Networking Advanced Services)"17:57
SumitNaiksatamcgoncalves: there?17:58
cgoncalvesSumitNaiksatam: sure17:58
SumitNaiksatamso there were a couple of excahnges on this over the mailer as well17:58
cgoncalvesso monday we added an initial proposal for the API and data models17:58
SumitNaiksatamcgoncalves: nice job capturing the details in teh document17:58
cgoncalveswe also brainstormed other data models but that's the one up for discussion now17:59
cgoncalvesSumitNaiksatam: thanks17:59
*** markmcclain has quit IRC17:59
*** notamrcn is now known as amrith17:59
cgoncalvesdoes anyone have questions regarding the proposal?17:59
SumitNaiksatamin general my thinking is that, this is more along the lines of expressing intent for traffic steering17:59
SumitNaiksatambetween ports that is17:59
*** eguz has joined #openstack-meeting-318:00
SumitNaiksatamthis probably could be a south side abstraction that the broader service chaining framework can use18:00
cgoncalvesSumitNaiksatam: it is but as I said on an email yesterday in reply to Kanzhe it can also be extended to traffic steering other than ports by extending the scope of the service function endpoint (SFE)18:00
cgoncalvesSumitNaiksatam: yup18:01
SumitNaiksatamthat said, the validation of a “port chain” is kind of a tricky issue18:01
SumitNaiksatami mean the validation for whether the traffic can indeed be steered betweek the given set of ports18:02
Kanzhecgoncalves: Is SFE meant for services that don't have neutron ports?18:02
cgoncalvesfor an initial implementation we should focus only on steering traffic between ports, so L118:02
SumitNaiksatamalso, to express this port chaining, you would already need the ports to exist, right?18:02
*** sarob has quit IRC18:03
jsoaresSumitNaiksatam: the proposal is in fact expressing intent for traffic steering but I guess it is a bit more than that since it gives and e2e perpesctive (path along several ports)18:03
*** sarob has joined #openstack-meeting-318:03
jsoaresSumitNaiksatam: which makes it closer to a SFC abstraction18:03
cgoncalvesSumitNaiksatam: yes, you would beed the ports to already exist18:04
SumitNaiksatamjsoares: sure, but i am not sure that the port level abstraction is the best way to capture the e2e path18:04
*** eghobo has quit IRC18:04
cgoncalvesKanzhe: my opinion is that for an initial implementation we should only focus on neutron ports18:04
SumitNaiksatamcgoncalves: so that might be a bit of a problem with existing services in neutron18:05
SumitNaiksatamjsoares: agreed, but services in neutron are not only services in VMs18:05
cgoncalvesKanzhe: but it could later be extended to have a 'type' attribute where it could be extend to L2 or L3 steering rather than only L1 steering (ports)18:05
s3wongcgoncalves: interesting. endpoints are identified by ports, chain is associated with flow, then a flow has a list of classifiers. The list of endpoints is ordered?18:06
jsoaresSumitNaiksatam: yes, but that is also why a SFC is not directly associated to neutron ports, but is associated to SF Endpoints. a SF Endpoint could be associated to something else rather than a neutron port18:06
*** sarob has quit IRC18:07
cgoncalvess3wong: the list of endpoints was previously an ordered list, but it's not required as we discussed internally, so that requirement has been dropped18:07
Kanzhecgoncalves: I think the current Neutron ports are all L3 ports, with mac and IP.18:08
s3wongcgoncalves: then how is the order of traffic flow through the chain be configured?18:08
SumitNaiksatamjsoares: ok, in which case its probably similar to the existing proposal around service chains18:08
SumitNaiksatamjsoares: my understanding, where this proposal complements the existing discussion, is to be able to signal intent for the traffic sterring between a set of neutron ports18:09
jsoaress3wong: the endpoints don't actually have to be ordered because the traffic steering would be done at each pair of ports (i.e. the same forwarding rule would be applied to all hops in the chain)18:09
cgoncalvesKanzhe: that said, you're saying we could not steer traffic based on ports but just mac and IP?18:10
SumitNaiksatamjsoares cgoncalves: i am with s3wong  here, i would have expected this to be an ordered list18:10
banixthe order seem to be implicit18:10
SumitNaiksatambanix: based on the flow?18:11
banixyes if i understand it correctly18:11
jsoaresSumitNaiksatam s3wong: maybe we can further clarify this aspect in the proposal. We believe it can be an order list but it does not need to be.18:11
SumitNaiksatamjsoares: sure18:11
cgoncalvess3wong, SumitNaiksatam: ok, so yesterday we came up with this new list of endpoints structure. instead of being a list of endpoints it should be a list of list of {K,V}+PassiveEndpoints18:11
s3wongjsoares: sure18:12
Kanzhecgoncalves: that was my question: is neutron port the right abstraction for traffic steering. Maybe it is, then it needs to be extended. Maybe not.18:12
cgoncalvesan example of a passive endpoint is the one in use case #4 (MON_01)18:12
s3wongcgoncalves: passive endpoint?18:12
cgoncalvess3wong: network taps :)18:13
jsoaresKanzhe: I think I see your point. E.g. if you have a function that does not have an IP in its interface, the neutron port would say it that it?18:13
*** Swami has quit IRC18:14
cgoncalvesKanzhe: I'm not 100% sure, but in principle it should be doable? :)18:14
jsoaress3wong: the notion of "passive" or "active" relates if the enpoint is in fact part of the main course of the chain or not. A passive function can be a function that has a promiscuous interface and is just looking into packets and does nothing (e.g. DPI)18:15
cgoncalves^ what jsoares said18:15
SumitNaiksatamok perhaps, jsoares and cgoncalves are planning some more updates to their document18:15
jsoaress3wong: Use case #4 has cgoncalves pointed out18:15
Kanzhejsoares: kind of. If a service is a L1 device. Currently, the device is invisible to Neutron since create_port can't be called for such device's interface.18:16
SumitNaiksatamin general i am thinking of this as neutron port-chain abstraction18:16
s3wongjsoares: OK. Thanks18:16
SumitNaiksatamand can be leveraged (at times) by the broader service chaining framework18:16
SumitNaiksatamin interest of time lets move to the next topic18:17
SumitNaiksatamcgoncalves jsoares: thanks!18:17
jsoaresKanzhe: Ah, yes, agree!18:17
SumitNaiksatam#topic Service context with Service Interfaces18:17
*** openstack changes topic to "Service context with Service Interfaces (Meeting topic: Networking Advanced Services)"18:17
SumitNaiksatamso Kanzhe had some more thoughts on our definition of the service_context based on the review comments in the patch: #link
Kanzhejsoares: cgoncalves I am facing the same issue for service insertion. Neutron port belongs to a Neutron network. It doesn't make much sense to use Neutron port for L1 interface.18:18
SumitNaiksatamhere’s kanzhe’s document: #link #link
SumitNaiksatamKanzhe: you want to summarize?18:18
prasadv_Kanzhe: can elaborate on not using neutron port for L1?18:19
KanzheSince L1 device doesn't belong to any network. It probably makes more sense to define another abstraction for such purpose.18:20
cgoncalvesKanzhe: we can move this discussion to the mailing list or schedule some time in #openstack-neutron18:20
s3wongKanzhe: L1 is transparent insertion, bump-in-the-wire?18:21
Kanzheprasadv_: L1 is a invisible to L2 or L3 entities.18:21
prasadv_s3wong: L1 is bridged insertion18:21
Kanzhes3wong: yes.18:21
prasadv_Kanzhe: it is bridged insertion right?18:22
*** jsoares_ has joined #openstack-meeting-318:22
hemanthravikanzhe: the ip/mac are redundant but a neutron port would be functional for L118:23
KanzheThanks, SumitNaiksatam. In the writeup shared by Sumit, I added a new object, serviceInterface. It captures L3, L2, and L1 interfaces. It could also be used for traffic steering.18:23
Kanzheprasadv_: yes.18:23
*** sarob has joined #openstack-meeting-318:23
prasadv_shouldnt we separate interfaces from insertion?18:24
SumitNaiksatamprasadv_: i believe the thinking is that the service interfaces are required for service insertion18:24
Kanzheprasadv_: why?18:24
prasadv_what I mean is a service has ports associated with a service18:24
Kanzhehemanthravi: how?18:25
SumitNaiksatamprasadv_: hence specify what those interface types are, and accordingly the service can be inserted18:25
SumitNaiksatamprasadv_: the interfaces plug into the ports18:25
hemanthravikanzhe: the L1 service doesn't use these18:25
prasadv_and then how the service is inserted determines how traffic flows between the ports of the service18:25
prasadv_and also the type of service18:25
*** coolsvap is now known as coolsvap|afk18:26
prasadv_L3 routes between the ports right?18:26
prasadv_L1 bridges the traffic between the ports18:26
SumitNaiksatamKanzhe: i think the point where we are tripping over is, will an L1 interface have a correspoding “neutron” port manifestation?18:26
Kanzheprasadv_: service insertion is different from traffic flow, which is traffic steering.18:26
s3wongprasadv_: are you advocating just using ports?18:27
prasadv_Kanzhe: but the type of service being inserted determines the flow doesnt it?18:28
*** dstanek has quit IRC18:28
SumitNaiksatamokay i think we need to spend a little more time on Kanzhe’s document, and perhaps some more higher bandhwidth discussions18:28
s3wong[2 minutes]18:28
*** shivharis has quit IRC18:28
prasadv_s3wong: Not sure. Need to think18:28
SumitNaiksatams3wong: yes! :-)18:29
KanzheSumitNaiksatam: Yes, we can either extend the Neutron port to support L1, L2 interfaces, or a separate object. I haven't wrapped my head around on which one makes more sense.18:29
SumitNaiksatamKanzhe: ok18:29
SumitNaiksatamKanzhe: thanks18:29
SumitNaiksatam#topic Open Discussion18:29
*** openstack changes topic to "Open Discussion (Meeting topic: Networking Advanced Services)"18:29
cgoncalvesKanzhe: yup, that would be then the main issue here to sort out18:29
SumitNaiksatamso we havent yet reached out to the Neutron PTL regarding us getting a standing item on the neutron IRC18:29
SumitNaiksatambut i believe enikanorov_, nachi, and i are on the same page on this18:30
jsoares_Kanzhe, SumitNaiksatam: that was in fact something that we also thought about, neutron port to also reflect L1 aspects18:30
cgoncalves1 hour is proving to be short to discuss all topics. should we arrange another meeting for chaining?18:30
SumitNaiksatamcgoncalves: we have had several in the past :-)18:30
cgoncalvesI mean, as it is still an early topic of discussion18:30
s3wongwe could just always eat into FWaaS's time :-)18:30
cgoncalvesSumitNaiksatam: off adv-services meetings?18:30
Kanzheprasadv_: No. I disagree. Insertion type is independent of what flows is steered to the service interface.18:30
SumitNaiksatamcgoncalves: service chaining has a long history of discussion :-)18:31
cgoncalvesSumitNaiksatam: and yet we are still discussing it hehe :)18:31
SumitNaiksatamso i think in terms of priority, getting the flavors work done by enikanorov_ is clearly a prirority from an advanced services common requirements perspective18:32
SumitNaiksatami also think the service insertion part need to be sorted out18:32
KanzheSumitNaiksatam: and service insertion. :-)18:32
SumitNaiksatamKanzhe: yeah, right on cue! :-)18:32
cgoncalvesSumitNaiksatam: agreed18:32
SumitNaiksatami believe there are aspects related to certificate management that swami had brought up earlier18:32
s3wongSumitNaiksatam: some sort of Neutron representation of "service" is also needed for GBP18:33
SumitNaiksatams3wong: very much agree18:33
SumitNaiksatams3wong: in fact that is a precursor to the service insertion18:33
prasadv_Kanzhe: I agree what traafic flows from outside is independent of service insertion18:33
SumitNaiksatamso good, lets collect the list of items that we need to prioritize and present to the broader neutron community/core team18:34
banixSumitNaiksatam: and a timeframe maybe?18:34
SumitNaiksatamwe have also proposed a design summit session for this18:34
SumitNaiksatambanix: absolutely18:34
SumitNaiksatami am not sure if we will get a slot18:34
SumitNaiksatambut please, reach out to me or on the mailer as to what items are in your critical path from an advanced services common requirements perspective18:35
SumitNaiksatamand we can accordingly prioritize and get reviewer attention for thise18:35
SumitNaiksatamnote that we first have to get the blueprints reviewed now!18:35
SumitNaiksatamalright, anything more today?18:35
*** pcm__ has joined #openstack-meeting-318:36
SumitNaiksatamdont want to make a habit of going over the time every week!18:36
SumitNaiksatamokay thanks everyone for joining, lets keep plugging at this18:36
*** openstack changes topic to "OpenStack Meetings ||"18:36
openstackMeeting ended Wed Apr 16 18:36:59 2014 UTC.  Information about MeetBot at . (v 0.1.4)18:37
openstackMinutes (text):
SumitNaiksatambye all!18:37
*** jamie_h has quit IRC18:37
*** s3wong has quit IRC18:37
*** s3wong has joined #openstack-meeting-318:38
*** hemanthravi has quit IRC18:38
*** s3wong has left #openstack-meeting-318:38
*** dstanek has joined #openstack-meeting-318:42
*** sweston has quit IRC18:43
*** rand738 has quit IRC18:49
*** pcm__ has left #openstack-meeting-318:50
*** rand738 has joined #openstack-meeting-318:51
*** jsoares_ has quit IRC18:51
*** jsoares has quit IRC18:51
*** russellb has quit IRC18:53
*** Kanzhe has quit IRC18:54
*** prasadv_ has quit IRC18:54
*** russellb has joined #openstack-meeting-318:55
*** rkukura has left #openstack-meeting-319:04
*** dstanek has quit IRC19:21
*** yamahata_ has quit IRC19:21
*** dstanek has joined #openstack-meeting-319:22
*** sweston has joined #openstack-meeting-319:43
*** sarob has quit IRC19:48
*** jpomero has joined #openstack-meeting-319:50
*** dstanek has quit IRC19:53
*** alexpilotti has quit IRC20:05
*** Sukhdev has joined #openstack-meeting-320:08
*** sarob has joined #openstack-meeting-320:10
*** sarob has quit IRC20:15
*** david-lyle has joined #openstack-meeting-320:16
*** jomara has quit IRC20:19
*** dstanek has joined #openstack-meeting-320:19
*** sarob has joined #openstack-meeting-320:20
*** jomara has joined #openstack-meeting-320:20
*** _sweston_ has joined #openstack-meeting-320:21
*** sweston has quit IRC20:21
*** jomara has quit IRC20:44
*** jomara has joined #openstack-meeting-320:45
*** eguz has quit IRC20:49
*** eghobo has joined #openstack-meeting-320:50
*** MaxV_ has joined #openstack-meeting-320:51
*** mfer has quit IRC21:07
*** _sweston_ has quit IRC21:08
*** sweston has joined #openstack-meeting-321:10
*** sarob has quit IRC21:11
*** sarob has joined #openstack-meeting-321:11
*** sarob has quit IRC21:15
*** sarob has joined #openstack-meeting-321:24
*** jcoufal has joined #openstack-meeting-321:24
*** sarob_ has joined #openstack-meeting-321:27
*** dstanek has quit IRC21:27
*** sarob_ has quit IRC21:28
*** sarob_ has joined #openstack-meeting-321:29
*** sarob has quit IRC21:29
*** eguz has joined #openstack-meeting-321:29
*** sarob has joined #openstack-meeting-321:31
*** sarob has quit IRC21:32
*** sarob_ has quit IRC21:33
*** eghobo has quit IRC21:34
*** _sweston_ has joined #openstack-meeting-321:35
*** sweston has quit IRC21:35
*** mwagner_lap has quit IRC21:38
*** peristeri has quit IRC21:43
*** dstanek has joined #openstack-meeting-321:54
*** dstanek has quit IRC21:59
*** Sukhdev has quit IRC22:08
*** sarob has joined #openstack-meeting-322:13
*** banix has quit IRC22:23
*** MaxV_ has quit IRC22:27
*** MaxV_ has joined #openstack-meeting-322:27
*** jtomasek has quit IRC22:30
*** MaxV_ has quit IRC22:32
*** sarob has quit IRC22:34
*** sarob has joined #openstack-meeting-322:35
*** jcoufal has quit IRC22:36
*** sarob has quit IRC22:39
*** sarob has joined #openstack-meeting-323:01
*** sarob has quit IRC23:01
*** david-lyle has quit IRC23:01
*** sarob has joined #openstack-meeting-323:01
*** jpomero has quit IRC23:18
*** lblanchard has joined #openstack-meeting-323:52
*** lblanchard has quit IRC23:59

Generated by 2.14.0 by Marius Gedminas - find it at!