Wednesday, 2014-04-30

*** yamahata has joined #openstack-meeting-300:06
*** cjellick has quit IRC00:15
*** cjellick has joined #openstack-meeting-300:16
*** banix has quit IRC00:16
*** lblanchard has joined #openstack-meeting-300:17
*** SumitNaiksatam has quit IRC00:18
*** otherwiseguy has joined #openstack-meeting-300:40
*** MaxV_ has joined #openstack-meeting-300:42
*** MaxV_ has quit IRC00:48
*** Adri2000 has quit IRC00:53
*** Adri2000 has joined #openstack-meeting-300:55
*** TravT has quit IRC00:57
*** eguz has quit IRC01:22
*** david-lyle has joined #openstack-meeting-301:32
*** mfer has joined #openstack-meeting-301:33
*** lblanchard has quit IRC01:35
*** banix has joined #openstack-meeting-301:41
*** SumitNaiksatam has joined #openstack-meeting-301:42
*** shivharis has quit IRC01:45
*** banix has quit IRC01:54
*** david-lyle has quit IRC01:57
*** mfer has quit IRC01:59
*** beyounn has joined #openstack-meeting-302:12
*** banix has joined #openstack-meeting-302:18
*** emagana has quit IRC02:19
*** emagana has joined #openstack-meeting-302:21
*** emagana has quit IRC02:25
*** coolsvap|afk is now known as coolsvap02:30
*** devlaps has quit IRC02:35
*** MaxV_ has joined #openstack-meeting-302:35
*** MaxV_ has quit IRC02:39
*** sankarshan is now known as sankarshan_away02:45
*** chuckC has joined #openstack-meeting-302:59
*** alexpilotti has quit IRC03:01
*** alexpilotti has joined #openstack-meeting-303:03
*** alexpilotti has quit IRC03:04
*** dtroyer has left #openstack-meeting-303:38
*** coolsvap is now known as coolsvap|afk03:42
*** eghobo has joined #openstack-meeting-303:49
*** mfer has joined #openstack-meeting-303:51
*** coolsvap|afk is now known as coolsvap03:54
*** mfer has quit IRC03:56
*** shakamunyi has quit IRC04:05
*** eghobo has quit IRC04:32
*** Tufin has joined #openstack-meeting-304:42
*** banix has quit IRC04:48
*** sankarshan_away is now known as sankarshan04:50
*** alexpilotti has joined #openstack-meeting-304:51
*** eghobo has joined #openstack-meeting-304:55
*** alexpilotti has quit IRC04:56
*** jtomasek has joined #openstack-meeting-305:18
*** jtomasek has quit IRC05:26
*** jtomasek has joined #openstack-meeting-305:27
*** MaxV_ has joined #openstack-meeting-305:37
*** MaxV_ has quit IRC05:42
*** jcoufal has joined #openstack-meeting-306:24
*** beyounn has quit IRC06:26
*** MaxV_ has joined #openstack-meeting-306:36
*** jcoufal has quit IRC06:37
*** jcoufal has joined #openstack-meeting-306:37
*** Tufin has quit IRC06:37
*** mrunge has joined #openstack-meeting-306:38
*** alexpilotti has joined #openstack-meeting-306:39
*** mrunge has quit IRC06:40
*** mrunge has joined #openstack-meeting-306:40
*** alexpilotti has quit IRC06:45
*** MaxV_ has quit IRC06:48
*** mrunge has quit IRC06:56
*** otherwiseguy has quit IRC07:03
*** mrunge has joined #openstack-meeting-307:07
*** ttrifonov_zZzz is now known as ttrifonov07:18
*** eghobo has quit IRC07:30
*** Tufin has joined #openstack-meeting-307:35
*** nacim has joined #openstack-meeting-307:37
*** coolsvap is now known as coolsvap|afk07:44
*** coolsvap|afk is now known as coolsvap07:51
*** safchain has joined #openstack-meeting-307:54
*** zigo_ is now known as zigo07:55
*** Tufin has quit IRC08:12
*** Tufin_ has joined #openstack-meeting-308:14
*** Tufin_ is now known as Tufin08:17
*** jamie_h has joined #openstack-meeting-308:23
*** otherwiseguy has joined #openstack-meeting-308:23
*** otherwiseguy has quit IRC08:27
*** mrunge has quit IRC08:30
*** sankarshan is now known as sankarshan_away08:30
*** mrunge has joined #openstack-meeting-308:34
*** sankarshan_away is now known as sankarshan08:42
*** coolsvap is now known as coolsvap|afk08:54
*** MaxV_ has joined #openstack-meeting-309:40
*** coolsvap|afk is now known as coolsvap09:55
*** Tufin has quit IRC09:55
*** sankarshan is now known as sankarshan_away10:04
*** alexpilotti has joined #openstack-meeting-310:11
*** otherwiseguy has joined #openstack-meeting-310:11
*** otherwiseguy has quit IRC10:15
*** coolsvap is now known as coolsvap|afk10:33
*** MaxV_ has quit IRC10:37
*** yamahata has quit IRC10:56
*** MaxV_ has joined #openstack-meeting-311:04
*** otherwiseguy has joined #openstack-meeting-311:06
*** jamie_h has quit IRC11:07
*** jamie_h has joined #openstack-meeting-311:08
*** otherwiseguy has quit IRC11:10
*** mwagner_lap has quit IRC11:39
*** coolsvap|afk is now known as coolsvap12:20
*** lblanchard has joined #openstack-meeting-312:21
*** mwagner_lap has joined #openstack-meeting-312:27
*** coolsvap is now known as coolsvap|afk12:34
*** julim has joined #openstack-meeting-312:49
*** mfer has joined #openstack-meeting-312:51
*** MaxV_ has quit IRC13:00
*** peristeri has joined #openstack-meeting-313:11
*** sankarshan_away is now known as sankarshan13:14
*** MaxV_ has joined #openstack-meeting-313:15
*** mwagner_lap has quit IRC13:20
*** jtomasek has quit IRC13:29
*** safchain has quit IRC13:35
*** enykeev has quit IRC13:36
*** safchain has joined #openstack-meeting-313:36
*** jtomasek has joined #openstack-meeting-314:05
*** yamahata has joined #openstack-meeting-314:06
*** mwagner_lap has joined #openstack-meeting-314:20
*** wchrisj has joined #openstack-meeting-314:21
*** wchrisj has left #openstack-meeting-314:21
*** david-lyle has joined #openstack-meeting-314:29
*** otherwiseguy has joined #openstack-meeting-314:36
*** cjellick has quit IRC14:36
*** otherwis_ has joined #openstack-meeting-314:38
*** cjellick has joined #openstack-meeting-314:40
*** devlaps has joined #openstack-meeting-314:41
*** cjellick_ has joined #openstack-meeting-314:41
*** otherwiseguy has quit IRC14:41
*** cjellick has quit IRC14:45
*** cjellick_ has quit IRC14:45
*** cjellick has joined #openstack-meeting-314:46
*** otherwis_ is now known as otherwiseguy14:50
*** banix has joined #openstack-meeting-314:59
*** emagana has joined #openstack-meeting-315:05
*** emagana has quit IRC15:06
*** emagana has joined #openstack-meeting-315:08
*** rudrarugge has joined #openstack-meeting-315:12
*** samchoi has joined #openstack-meeting-315:18
*** emagana has quit IRC15:21
*** rudrarugge has quit IRC15:30
mfer#startmeeting openstack-sdk-php15:31
openstackMeeting started Wed Apr 30 15:31:04 2014 UTC and is due to finish in 60 minutes.  The chair is mfer. Information about MeetBot at http://wiki.debian.org/MeetBot.15:31
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:31
*** openstack changes topic to " (Meeting topic: openstack-sdk-php)"15:31
openstackThe meeting name has been set to 'openstack_sdk_php'15:31
mferCan everyone please state your name and any applicable association.15:31
mferMatt Farina, HP15:31
samchoiSam Choi, HP15:31
jamie_hJamie Hannaford, Rackspace15:31
jamie_hShaunak and Glen are at a meeting, so won't be attending today15:31
mfer#topic Agenda15:32
*** openstack changes topic to "Agenda (Meeting topic: openstack-sdk-php)"15:32
mfer#link https://wiki.openstack.org/wiki/Meetings/OpenStack-SDK-PHP15:32
mfer1. Intro to the PHP SDK if there is anyone new? (mfer)15:32
mfer2. Near term roadmap (mfer)15:32
mfer3. Service definitions (jamie_h)15:32
mfer4. Blueprints / Bugs / Reviews (mfer)15:32
mfer5. Copyrights? (jamie_h)15:32
mfer6. Open Discussion (mfer)15:32
mferSince there is no one new here we can jump to #215:33
mfer#topic Near term roadmap15:33
*** openstack changes topic to "Near term roadmap (Meeting topic: openstack-sdk-php)"15:33
mfer#link https://wiki.openstack.org/wiki/OpenStack-SDK-PHP#Short_Term_Roadmap15:33
mferI left this on here because we've had a bit of discussion on it. is there anything else we should talk about?15:33
jamie_hToday I've been working on 2 (Guzzle transport layer)15:34
jamie_hShaunak will be commencing progress on Friday with his doc stuff15:34
jamie_hHe put together this spec: https://wiki.openstack.org/wiki/OpenStack-SDK-PHP/UserFacingDocumentation15:34
jamie_hOther than that, I have nothing else15:35
mferjamie_h #2 was marked as complete so that's something we might want to talk about.15:35
mferI'm glad to see Shaunak working on that stuff. I'll poke around at what he put together15:35
jamie_hIt's adding no new functionality - just refactoring existing stuff and adding missing tests15:35
jamie_hadding FIG messages etc.15:36
samchoijamie_h: is there a bug/blueprint with additional details?15:36
mferjamie_h FIG message for a response was already included.15:37
mferjamie_h i think the question is why and how does it fit in the scope of what15:37
jamie_honly a ResponseInterface was there - there was no MessageInterface or RequestInterface15:37
mferonly the featuers that need to be present are the ones that will be used. the use case and how it fits into scope is the larger question15:38
jamie_hit's work on the transport layer that enables us to move on with the more complex service stuff15:38
jamie_hright now there are inefficiencies which need to be cleaned up15:38
jamie_hWhen we agreed to take on the codebase, we agreed to the idea of refactoring15:38
jamie_hI'm not going to steam on with adding stuff to a wobbly foundation15:39
mferthis isn't about refactoring. anything that goes in should have a purpose in the broader scope. can you please add a blueprint describing what, why, and how it fits in.15:39
jamie_hOf course - I'll sketch one today15:40
mferwe're building a binding in an SDK and not an application. This is meant for end users to have a simple and useful way to map to services. i just want to make sure we don't go down a road of feature creep or into something larger and more unwieldy than needed.15:40
jamie_hI agree. But we also have an obligation to provide users with code that is well-written and not riddled with technical debt15:41
mferjamie_h i'd prefer if you didn't call this a wobbly foundation or otherwise poke it with a negative tone. there are some things you have looked down upon which were intentional decsions based on good engineering principles with end users in mind. I do agree that debt should be removed.15:43
mferif you have a question about why something is please ask and try to understand why something is a certain way15:44
mferi look forward to the blueprint15:44
mferis there anything else on the roadmap?15:44
jamie_hjust to clarify:15:44
samchoiFor work done on the transport layer/Guzzle, I think we should also keep in mind that how we make use of Guzzle can make it more difficult for contributors to understand the codebas since Guzzle itself takes some time to get used to.15:44
jamie_hdoes every patch in OpenStack require a blueprint first?15:44
mferjamie_h no15:45
mferjamie_h not every patch requires a blueprint or bug. but, any new featuers or bugs should have something associated15:45
mferso, something like removing the credits file is just fine15:45
jamie_hhow about refactoring which doesn't introduce new features?15:46
*** rand738 has quit IRC15:46
samchoimfer: so there aren't many cases where a patch wouldn't have an associated bp/bug then?15:46
jamie_hdoes that require an official blueprint?15:46
*** rand738 has joined #openstack-meeting-315:46
jamie_hsamchoi: I agree - we need to minimize the complexity underneath, and separate it out so it's not intimidating or cryptic for new users - that was what I was working on today15:47
jamie_hthings like renaming "GuzzleClient" class to "GuzzleAdapter"15:47
mferjamie_h possibly not. but, the refactor should be discussed and intents be clear. many of the decisions were made for good technical reasons. to switch to a different architecture the technical changes and reasoning needs to be clear and understood15:48
jamie_hI completely agree - I'm not trying to move to a different architecture, just strengthen and simplify the one we have :)15:48
mferjamie_h those are fine. strengthen just needs to be clearly communicated15:49
jamie_hOkay. I just think we need to be open to the idea of changing parts of the codebase. Asking for formal blueprints and debating every minutiae of detail raises barriers IMHO15:49
mferand not on a personal pref merit. i've seen some of that on some projects recently and i'd like to avoid those things.15:50
mferdoing things in openstack has extra barriers. that's part of the system of folks from very different walks of life working together and the large companies being incolved.15:50
mferlets try to minimize those and work efficiently in them15:51
jamie_hI agree - what's the best way to communicate prospective refactorings?15:51
jamie_hsurely that's what Gerrit is for?15:51
mfercommit messages. when questions come up clearly articulate reasoning. things like that15:52
mferprovide logic and reasoned cases15:52
jamie_hOkay - what's the best way to do that? Gerrit doesn't have a great commenting system - shall we use the Wiki?15:52
jamie_hI'm wary about having to write a wiki article for every patch I write. It'll take days to merge simple refactorings then15:53
mferThe latest release of Gerrit has the ability to just do comments in addition to reviews. comments inline are a great way. someone can ask a question about a section of code in context and a discussion can happen there15:53
mferis there a reason this won't work?15:54
jamie_hLet's go with that for now15:54
jamie_hI'm happy to move on15:54
mferanything else with the roadmap or shall we talk service definitions?15:54
jamie_hI have nothing to add for roadmap15:55
samchoiI'm good15:55
mfer#topic Service definitions15:55
*** openstack changes topic to "Service definitions (Meeting topic: openstack-sdk-php)"15:55
*** eghobo has joined #openstack-meeting-315:55
mferjamie_h since this is your item can you kick us off15:55
jamie_hI sent out several e-mails and wrote up some Wiki articles detailing my idea15:55
jamie_hdid everyone get a chance to read it?15:55
mferjamie_h i did15:56
jamie_hit was fairly long, so no worries if not :)15:56
jamie_hso it's just an idea - I'm not firmly advocating it. I think it could offer us and our users a lot of advantages15:56
samchoiI was out earlier this week, I haven't gotten through all emails unfortunately15:57
*** ttrifonov is now known as ttrifonov_zZzz15:57
*** overlayer_kiwi has joined #openstack-meeting-315:57
jamie_hmfer do you have any questions? If not, shall we postpone this topic until next week so Sam has a chance to read everything?15:57
mferjamie_h I understand the case you're making. I took this a few steps further. I looked at other places that are using this. did you know Google is taking json schema and generating Go code from it? i also dug into the debugging experience even if something like Guzzle isn't used.15:58
mferso, i'm up to speed15:58
jamie_hreally? I didn't know they were generating go code - that's awesome15:58
jamie_hI love their Discovery API15:59
jamie_hmfer do you have any concerns about using a definitions DSL like the one I described? Or any reason why userland code would be better?15:59
mferi can come up with other ways to do the same thing w/o json schemas.16:00
mferbetter here is going to be a little subjectice on the developer experience side16:00
jamie_hby "other ways" do you mean userland code? Or a DSL?16:02
mfermy largest curiosity is that I discussed this with some folks in and out of HP who work on SDKs. the majority reaction I got was to use userland code. i was a little surprised16:02
mferi'd like to explore their thinking more.16:02
jamie_hokay, sure. Let's try and compile a list of strong reasons for/against so we can evaluate further16:02
mferpersonally, i don't have a preference one way or another. i'm fine either way. i'd like like to understand this first and why some folks had push back the way they did16:02
jamie_hI agree. The openstack-dev mailing list is a great way to find this out too16:03
mfersome of these folks will be at the summit. i'd like to spend some time face to face with them and talk it through.16:03
jamie_hI did a search for json-schema and the reaction was nearly always positive16:03
jamie_hokay - sounds like a plan16:03
mferi'm saving the emails and wiki pages you had to use in the conversations. to share examples and talk it through16:03
mferi have a feeling that those who didn't take on json schema didn't say anything at all16:04
mferand, i wonder if there is some stuff that's misunderstood16:04
jamie_hdo you want to postpone this schema stuff until after the summit?16:05
*** nacim has quit IRC16:05
mferjamie_h i think you did a good job of articulating your point. i was also able to easily find any missing information i wanted when i researched16:05
mferyeah, i was thinking we postpone that until after the summit. i'll collect a bunch of feedback and share16:05
samchoibtw, OS summit is next week and mfer is out all week right?16:06
mferthe OS summit is the week after next16:06
jamie_hso, can we halt work on all service stuff until after the summit - since schemas are linked to that16:06
jamie_hI don't want to get started on something, realize we've committed to a solution, and that forms the basis for not including schemas16:07
mferif something becomes clear during the summit i'll be sure to start emails then16:07
mferthanks.16:07
*** cjellick has quit IRC16:07
jamie_hso until the summit finished, how will this affect the roadmap?16:07
mferi was really interested in the schema work. then i spoke with some others and they had reservations. i'd like to just make sure everything is vetted16:07
jamie_hokay that's fair16:07
mferi'm not sure how it affects the roadmap16:08
mferthere are some other things we can work on in the meantime16:09
jamie_hsure okay16:09
jamie_hI'm happy to move on to next topic16:09
mfersamchoi are you ready to move on?16:09
samchoisure, I'll gather more information on my own and from emails16:10
samchoino further comments at this time16:10
mfer#topic Blueprints / Bugs / Reviews16:10
*** openstack changes topic to "Blueprints / Bugs / Reviews (Meeting topic: openstack-sdk-php)"16:10
mferLets start with the credits file one16:10
mfer#link https://review.openstack.org/#/c/91305/16:10
mferI don't see an issue with this one. It seems fairly straight forward.16:11
*** cjellick has joined #openstack-meeting-316:11
jamie_hsamchoi did you have reservations for this one?16:12
samchoino, looks fine16:12
*** cjellick has quit IRC16:12
mferthen i just merged it now :)16:13
*** cjellick has joined #openstack-meeting-316:13
mfererr, reviewed it for Jenkins to do it's thing16:13
jamie_hcool!16:13
mferthen there is the test separation one16:13
mfer#link https://review.openstack.org/#/c/90407/16:13
jamie_hcan we talk about https://review.openstack.org/#/c/90378/7 first?16:14
jamie_hsince it's a dependency16:14
mferok16:14
jamie_hthanks mfer for your feedback on this one. I ended up adding back in a lot of the original tests16:14
jamie_hthere's only minor refactoring, removing duplication etc.16:14
mferi've not had a chance to look through the latest patch set16:14
*** emagana has joined #openstack-meeting-316:15
mferi'd like to get to that later today16:15
jamie_hokay16:15
mfereach day i'm carving out some time to do some reviews and that time hasn't come up since the last time you pushed a change16:16
mferi'll review this one before i get to the test structure changes one16:16
jamie_hthanks16:16
mferjamie_h with this change would it be safe to run against devstack too?16:18
*** TravT has joined #openstack-meeting-316:18
jamie_hmfer yep, that's what I was running against16:18
mfergreat. i'll do that. thanks16:18
mferI was going to start the process to convert bootstrap away from a singleton (https://blueprints.launchpad.net/openstack-sdk-php/+spec/remove-openstack-singleton)16:19
jamie_hsamchoi do you need today to review this one too? I know you approved of the other one (separating out tests)16:19
jamie_hmfer okay, sounds good16:20
samchoito review 90378? I'll look through the latest patch today. I haven't looked at others' comments, but I didn't see any blockers or serious issues.16:21
jamie_hmfer can we talk about whether to have a global context (like Bootstrap) or individual service builders - perhaps in IRC later?16:21
jamie_hI haven't had much time to get to grips with bootstrap yet16:21
mferjamie_h sure.16:21
mferthe idea is the developer experience of developers integrating this into their setup. to make it easy for the long tail of developers16:22
jamie_hyeah, like a single access point16:22
mferwe're not targeting the top 10% of devs. they likely wouldn't need an SDK. i want to make sure we help the long tail be successful16:22
mferi'll start with a spec16:22
jamie_hI like the idea of making it as easy as possible to create a service16:23
jamie_hare there any other patches that need discussion?16:24
mferyeah, i do too. it's two slightly different audiences. someone who is going to add to/extend the binding and someone who is going to use it.16:24
mferthose are the only 3 open reviews right now16:24
mfersamchoi did you have anything that needed discussing?16:24
samchoinope16:24
mfershall we move on to copyrights?16:25
jamie_hsure16:25
mfer#topic Copyrights?16:25
*** openstack changes topic to "Copyrights? (Meeting topic: openstack-sdk-php)"16:25
mferjamie_h this is another one you added. can you fill in the context16:26
mferi think i know what you mean but i don't want to assume16:26
jamie_hSo I submitted a patch a week or so ago that rewrote all the copyright headers to use OpenStack Foundation as the copyright holder. Currently the files reference HP16:26
jamie_hmore time was required for investigation to see the legal ramifications of changing to OpenStack Foundation16:27
mferUnfortunately, I've not had the time for that yet.16:27
mfer#link https://wiki.openstack.org/wiki/LegalIssuesFAQ#Copyright_Headers16:27
jamie_hthat's fine - shall we add this to next week's agenda?16:28
jamie_hbasically, an overwhelming reason to keep HP as the copyright holder on this project16:28
jamie_hinstead of switching everything to OpenStack Foundation16:28
mferI was going to save this for the open discussions but i will likely not be here next week. i'm on vacation.16:28
mfercan we punt it to the week after the summit?16:28
mferthere's actually a "duplicative licensing situation" going on here16:29
*** tjones has joined #openstack-meeting-316:29
samchoimfer: Is this something we can send off to HP legal to research for us?16:29
mferand I'm not sure of the legal stance within HP and within the community. i need to make checks on both sides16:29
jamie_hsure, let's talk about it after the simmit16:29
mfersamchoi I need to check with HPs lawyers16:29
mfernote, it's not uncommon for companies to be in the headers like this.16:30
mferyou'll see it in lots of projects16:30
mferi'm just always very caucious around these legalities16:30
samchoiwe should wrap up... I think we'll be kicked out shortly16:31
mferok, there is another meeting starting. see y'all in #openstack-sdks16:31
mfer#endmeeting16:31
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"16:31
openstackMeeting ended Wed Apr 30 16:31:56 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:31
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack_sdk_php/2014/openstack_sdk_php.2014-04-30-15.31.html16:31
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack_sdk_php/2014/openstack_sdk_php.2014-04-30-15.31.txt16:32
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack_sdk_php/2014/openstack_sdk_php.2014-04-30-15.31.log.html16:32
mfersorry for going over a minute16:32
tjones#startmeeting NovaBugScrub16:32
openstackMeeting started Wed Apr 30 16:32:07 2014 UTC and is due to finish in 60 minutes.  The chair is tjones. Information about MeetBot at http://wiki.debian.org/MeetBot.16:32
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:32
*** openstack changes topic to " (Meeting topic: NovaBugScrub)"16:32
openstackThe meeting name has been set to 'novabugscrub'16:32
jaypipeso/ how can I help16:32
tjonesno prom mfer16:32
tjoneshi jaypipes.  we r just going to tag untagged today.  got a bunch of them16:32
tjones#link https://bugs.launchpad.net/nova/+bugs?field.tag=-*&field.status%3Alist=NEW16:32
*** beagles has joined #openstack-meeting-316:33
tjonesi usually try to get to it before this meeting and only have the ones i don't know to review but i have not had time16:33
jaypipestjones: ok, sounds good. are there specific tags I should be using?16:33
tjonesyes - they are on …. *finding it*16:33
jaypipestjones: just the ones on the right there?16:33
tjonesthe official tags are on #link https://wiki.openstack.org/wiki/Nova/BugTriage16:34
jaypipesthx!16:34
tjoneswe go through the list of untagged and tag them so the owners can further triage16:34
tjones#link https://bugs.launchpad.net/nova/+bug/131366116:35
jaypipescool. well, I will try and help as much as I can. thx for that link :)16:35
tjonesthis looks like networking16:35
tjoneschime in if you disagree otherwise i will just keep going16:35
tjones#link https://bugs.launchpad.net/nova/+bug/131421716:36
tjonesthat is api16:36
tjones#link https://bugs.launchpad.net/nova/+bug/131421716:36
tjonesnetworking16:36
jaypipestjones: do you mind if I tag a couple of these with "low-hanging-fruit"?16:36
tjones#link https://bugs.launchpad.net/nova/+bug/130153216:37
jaypipesin particular, I think 1314217 is a low-hanging fruit16:37
tjoneshmmm…..  compute or api?16:37
*** otherwiseguy has quit IRC16:37
tjonesaded low-hanging-fruit to that16:37
*** otherwiseguy has joined #openstack-meeting-316:38
tjonesim going to start with api on https://bugs.launchpad.net/nova/+bug/1301532 unless someone disagrees16:38
tjones#link https://bugs.launchpad.net/nova/+bug/130153216:39
jaypipestjones: no, it's not really api. I would go with compute.16:39
jaypipestjones: the quota one...16:39
tjonesok done16:39
tjonescompute it is16:39
jaypipestjones: just cuz it's not solvable via an api change...16:39
tjonesmakes sense16:39
jaypipes#link https://bugs.launchpad.net/nova/+bug/131200216:40
jaypipescells16:40
tjonesforgot that was a valid tag16:40
tjones#link https://bugs.launchpad.net/nova/+bug/131287416:40
tjonesvolume16:41
tjones#link https://bugs.launchpad.net/nova/+bug/131370716:41
tjoneslibvirt16:41
tjones#link https://bugs.launchpad.net/nova/+bug/131412916:42
tjonesno idea16:42
tjonesits a build thing16:43
tjonesim just going to leave it - looks like ihar is taking care of all of them16:44
jaypipestjones: a build thing?16:44
tjonesthis one https://bugs.launchpad.net/nova/+bug/131412916:44
tjones9:4216:44
jaypipestjones: not sure it's a build thing, but it certasinly doesn't fit with any existing tags :)16:44
tjonesyeah lets leave it.16:44
tjones#link https://bugs.launchpad.net/nova/+bug/131449016:44
jaypipestjones: well, hold up... maybe "oslo" tag it, since it's jsonutils in oslo.16:45
tjonesoh ok16:45
tjonesthere you go16:45
tjonesnow the nxt one - this one i think we just push back. there is not enough info here16:45
tjonesunless it is ec2 and they know what this means16:46
jaypipestjones: it's a simple refactoring... I marked it low-hnangin-frut16:46
tjonesok16:46
jaypipesor low-hanging-fruit, as it were..16:46
jaypipestyping sucks today...16:46
tjoneslol16:46
tjones#link this one i think we just push back. there is not enough info here16:46
tjonesoops16:46
tjones#undo16:46
openstackRemoving item from minutes: <ircmeeting.items.Link object at 0x390e290>16:46
tjones#link https://bugs.launchpad.net/nova/+bug/131452616:46
jaypipestjones: I can't set bug priorities. you might want to set the above bug priority to low.16:47
tjoneslibvirt16:47
jaypipes131449016:47
tjonesyes16:47
*** overlayer_kiwi has quit IRC16:47
jaypipesyup, libvirt.16:47
tjonesnext one vmware16:47
jaypipesand final one is cells.16:48
tjoneslast one #Link https://bugs.launchpad.net/nova/+bug/131467716:48
jaypipescells16:48
tjonescells16:48
jaypipes:) yup.16:48
tjonesand DONE16:48
jaypipestjones: anything else I can help with?16:48
tjonesnow i take a peek and see if there are critical bugs not moving and there are not16:48
tjonesso we are done16:48
tjonesthanks jaypipes!16:48
jaypipestjones: any time, happy to help. pls do let me know if I can assist you with bug triaging or verification stuffs.16:49
tjonesthanks!16:49
tjones#endmeeting16:49
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"16:49
openstackMeeting ended Wed Apr 30 16:49:23 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:49
openstackMinutes:        http://eavesdrop.openstack.org/meetings/novabugscrub/2014/novabugscrub.2014-04-30-16.32.html16:49
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/novabugscrub/2014/novabugscrub.2014-04-30-16.32.txt16:49
openstackLog:            http://eavesdrop.openstack.org/meetings/novabugscrub/2014/novabugscrub.2014-04-30-16.32.log.html16:49
*** jamielennox is now known as jamielennox|away17:00
*** mrunge has quit IRC17:06
*** SumitNaiksatam has quit IRC17:06
*** garyduan has joined #openstack-meeting-317:12
*** safchain has quit IRC17:14
*** SumitNaiksatam has joined #openstack-meeting-317:19
*** rkukura has joined #openstack-meeting-317:20
*** german_ has joined #openstack-meeting-317:22
*** mandeep has joined #openstack-meeting-317:23
*** reaperhulk has joined #openstack-meeting-317:26
*** wchrisj__ has quit IRC17:29
SumitNaiksatamhello Neutrons!17:30
*** SridarK has joined #openstack-meeting-317:30
SumitNaiksatamSridarK: hi17:30
mesteryo/17:30
cgoncalveshi all17:30
banixHaloooo SumitServices17:30
SridarKHi SumitNaiksatam and all17:30
SumitNaiksatammestery cgoncalves banix: Hi!17:30
*** s3wong has joined #openstack-meeting-317:31
rkukurahi17:31
SumitNaiksatambanix: i will create a bp with that name :-)17:31
SumitNaiksatamrkukura: hi!17:31
banixSumitNaiksatam: :)17:31
s3wonghello17:31
SumitNaiksatambanix: or rather IRC alias17:31
SumitNaiksatams3wong: hi17:31
SumitNaiksatamenikanorov_ nachi: there?17:31
enikanorov_hi17:31
banixSumitNaiksatam: yeah that would be great or Twitter handle!17:31
enikanorov_yep, i'm here17:31
SumitNaiksatamok great, lets get started17:31
*** pcm_ has joined #openstack-meeting-317:32
SumitNaiksatampcm_: hi17:32
SumitNaiksatam#startmeeting Networking Advanced Services17:32
openstackMeeting started Wed Apr 30 17:32:10 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.17:32
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:32
*** openstack changes topic to " (Meeting topic: Networking Advanced Services)"17:32
openstackThe meeting name has been set to 'networking_advanced_services'17:32
SumitNaiksatamMeeting agenda: #link https://wiki.openstack.org/wiki/Meetings/AdvancedServices17:32
SumitNaiksatam#info Wiki page17:32
*** jtomasek has quit IRC17:32
*** Kanzhe has joined #openstack-meeting-317:32
SumitNaiksatam#link https://wiki.openstack.org/wiki/Neutron/AdvancedServices17:32
pcm_SumitNaiksatam: hi17:32
*** nati_ueno has joined #openstack-meeting-317:32
nati_uenoHi!17:32
KanzheSumitNaiksatam: hi17:32
SumitNaiksatamnati_ueno Kanzhe: hi17:33
SumitNaiksatamgoing forward we will gradually start tracking our Juno progress on the wiki17:33
SumitNaiksatammeeting wiki page only for meeting agenda and suggesting topics of discussion17:33
SumitNaiksatam#topic Neutron Advanced Services' Framework17:33
*** openstack changes topic to "Neutron Advanced Services' Framework (Meeting topic: Networking Advanced Services)"17:33
mestery+1 to that SumitNaiksatam17:33
SumitNaiksatammestery: sure17:34
SumitNaiksatam#link https://docs.google.com/document/d/1hshzNDfBrMj7C_3HnVaUlMSuAzea9MI7S3wLKH5eJmc/edit#17:34
SumitNaiksatambassed on the discussions so far, we captured a design plan in the above document17:34
SumitNaiksatami also share it with the PTL (mestery)17:34
SumitNaiksatam*shared17:34
SumitNaiksatamit should not be new to whoever has been participating in the IRC and discussions here17:34
banixSumitNaiksatam: was [2] updated accordingly?17:35
mesterySumitNaiksatam: I liked how the plan was broken up into digestible pieces. :)17:35
SumitNaiksatamwanted to bounce it off everyone before we sent to the mailer and socialized more17:35
*** Swami has joined #openstack-meeting-317:35
SumitNaiksatammestery: thanks17:35
Swamihi17:35
SumitNaiksatambanix: no, 2 has not been updated17:35
SumitNaiksatamSwami: hi17:35
SumitNaiksatambanix: i was hoping to replace the references with actual gerrit bp links as they are posted17:35
SridarKSumitNaiksatam: +1 to mestery: on that the doc has a nice overview leading off to the pieces parts17:36
*** jsoares has joined #openstack-meeting-317:36
banixSumitNaiksatam: makes sense17:36
SumitNaiksatambanix: for now they are high level place holders17:36
SumitNaiksatamSridarK: ok17:36
SumitNaiksatamany more thoughts comments on this?17:36
s3wongSumitNaiksatam: do you want the proposal of ServiceBase definition to go on [2]? If so, you may want to grant me edit right on that document17:36
SumitNaiksatams3wong: sure, we can discuss offline17:36
SumitNaiksatams3wong: i thought it was open, but perhaps not17:37
SumitNaiksatamits been a while :-)17:37
banixnot open17:37
SumitNaiksatamthe detail is obviously in the details as far as that document is concerned17:37
banixwhich is fine17:37
SumitNaiksatamwhich should come through each individual blueprint17:37
SumitNaiksatamand we will discuss here as well17:37
SumitNaiksatambanix: okay, will fix17:38
*** MaxV_ has quit IRC17:38
SumitNaiksatamenikanorov_ nati_ueno: any thoughts on the high level plan?17:38
nati_ueno+117:38
nati_ueno:)17:38
enikanorov_SumitNaiksatam: high level plan looks good. btw, is there a bp on review regarding service base definition?17:38
SumitNaiksatamenikanorov_: not yet, since its evolving, s3wong will put one17:39
SumitNaiksatamenikanorov_: or we might combine it with the service insertion bp that Kanzhe will add17:39
SumitNaiksatamenikanorov_: but one of those17:39
SumitNaiksatamnati_ueno: thanks :-)17:39
emaganahi folks! joinig late17:39
enikanorov_ok. i'd like to focus on neutron-specs since i have to track too much in mailing list and in separate docs17:39
nati_uenoso we will use google doc as draft?17:39
emaganajoining*17:39
SumitNaiksatamenikanorov_: agreed17:40
KanzheSumitNaiksatam: s3wong and I will sync up after the meeting.17:40
nati_ueno+1 for discussing in gerrit17:40
mestery+! for neutron-specs17:40
mestery+1 even17:40
nati_uenomestery: process id? :)17:40
enikanorov_^)17:40
SumitNaiksatamyes we will try to put this into gerrit at the earliest17:40
garyduanHi, I am late17:40
s3wongKanzhe: definitely17:40
SumitNaiksatammestery: do you propose that the high level plan be put in gerrit as well? or should we just keep it in the google docs and socialize over emails?17:41
nati_uenolet's have them in the gerrit too17:41
SumitNaiksatammestery: with the gerrit specs to follow with individual details17:41
nati_uenoneutron-spec html looks really nice spec doc17:41
mesteryI think checking in the high-level plan into gerrit, referencing the other BPs, may not be a bad idea17:41
mesteryAs long as we make it clear it's a high level plan.17:41
mesteryThoughts?17:41
SumitNaiksatamnati_ueno mestery: okay got it17:41
banixwell, the high level plan cannot be really reviewed on its own17:42
SumitNaiksatamwill do that, i think it will help to have the other bps in teh queue too so that those can be referenced17:42
SumitNaiksatambanix: yes i agree17:42
nati_uenobanix: if we make sure we agreed on high level in gerrit, we can just refer it, and We can prevent looping discussion17:43
SumitNaiksatamnati_ueno: ok sure17:43
banixqish we could somehow have he high level plan on evey individual spec to give the reader the context17:43
SumitNaiksatamwe will do it then17:43
SumitNaiksatam#action SumitNaiksatam to add high level advanced services framework bp to gerrit, will not contain details but reference other detailed bps17:43
cgoncalvesbanix: nice sugestion. will add to port-chain as soon as I submit it to neutron-specs17:44
banixc/quish/wish17:44
s3wongbanix: yes, I agree with nati_ueno here. The advanced service high-level idea itself has been circulating for a while, it is great to use gerrit as a channel to gather community feedback17:44
SumitNaiksatammestery: hopefully this will be reviewed in that spirit, and we wont get stuck at the lack of details in the high level bp17:44
*** david-lyle has quit IRC17:45
banixnati_ueno: s3wong ok; people may not review it on its own but for referencing sounds good17:45
nati_uenobanix: ya, let's link it17:45
SumitNaiksatammestery: ^^^ ?17:45
mesterySumitNaiksatam: I will police the BP submission. :)17:45
SumitNaiksatammestery:  ah good! :-)17:46
SumitNaiksatamok moving on (unless there is something else on this)17:46
banixso every related spec can start with referncing the high level design17:46
SumitNaiksatambanix: ok17:46
s3wongbanix: sure17:46
SumitNaiksatam#topic Key/certificate management using Barbican for VPN and LBaaS17:46
*** openstack changes topic to "Key/certificate management using Barbican for VPN and LBaaS (Meeting topic: Networking Advanced Services)"17:46
SumitNaiksatamthis was raised by Swami earlier17:47
SumitNaiksatamand we brought this up with mestery  as well17:47
nati_uenoyes, and we have a thread on this17:47
mesteryYes, thread on the ML.17:47
mesterySeems as if using Barbican here could benefit both VPNaaS and LBaaS.17:47
enikanorov_right17:47
SumitNaiksatamnati_ueno mestery: so at this point this is resolved?17:47
nati_uenoenikanorov_: are you agree with this plan?17:48
enikanorov_but how neutron can rely on barbican?17:48
SumitNaiksatamSwami: does this work for you?17:48
SumitNaiksatamenikanorov_: good question17:48
mesteryThe only issue Barbican is in incubation :)17:48
mesteryHopefully out of Incubation soon.17:48
nati_uenoyes17:48
SumitNaiksatammestery: yes good point17:48
nati_uenoso we need driver archtecture for this management17:48
enikanorov_yep, that will solve the issue17:48
mestery+1 nati_ueno17:48
nati_uenowe will need db impl for some time17:48
mesteryWith the end goal of moving it all to Barbican.17:48
nati_uenoand also barbarian impl17:48
* SumitNaiksatam thinks similar issue to Service VMs being in stackforge17:49
nati_uenoyes17:49
enikanorov_nati_ueno: i think a part of neutron community is against db impl17:49
mestery+1 SumitNaiksatam17:49
mesteryYEs17:49
mesteryDB implementation will have challenges. Is there an alternative?17:49
nati_uenoenikanorov_: yes, so they can choose barbarian impl17:49
german_barbican +117:49
enikanorov_nati_ueno: i think the main point is security concerns17:49
nati_uenoenikanorov_: it depends on how we define system security17:49
enikanorov_that better be avoided rather then offered as a "unsecure option"17:50
nati_uenoenikanorov_: I don't think it is unsecure option17:50
nati_uenoenikanorov_:  If DB ID/PW get stolen, it is same17:50
nati_uenoenikanorov_: But I do agree there are more secure option17:50
nati_uenoenikanorov_: I'm new to barbarian, so I'm still not sure how it is more secure than db impl yet17:51
banixbarbarian :)17:51
enikanorov_:)17:51
nati_uenooops typo17:51
*** david-lyle has joined #openstack-meeting-317:51
* SumitNaiksatam thinks that ^^^ was coming :-)17:51
mestery;)17:51
banixI thought that was the name first time I saw it17:51
nati_uenohe he he17:52
nati_uenoanyway, let's decide the option17:52
SumitNaiksatammestery: so is this the plan of record to use barbician, or are we still evaluating this?17:52
nati_ueno(1) Jump to Barbican (2) have two option17:52
mesteryI think we should plan to move to barbican, if we need a stopgap, that's what we can discuss on the ML still.17:52
SumitNaiksatamSwami: have you evaluated using barbician?17:52
nati_uenoso (1) ?17:53
SumitNaiksatam*barbican17:53
nati_uenooops17:53
mesterynati_ueno: 117:53
mesteryI think17:53
nati_uenoSure, so we don't need driver arch here17:54
nati_uenolet's have a Barbican manager in the neutron17:54
SumitNaiksatamok for now the plan of record is to use barbican, i was hoping Swami would have been able to chime in17:55
german_BTW barbican is two way it can also notify that a cert has changed17:55
*** SridarK has quit IRC17:55
SumitNaiksatamenikanorov_, mestery: perphaps you can notify the LBaaS team as well17:55
german_aka new certs comes barbican kicks off a new LB17:55
SumitNaiksatamgerman_: ok good to know17:55
mesterySumitNaiksatam: Yes, we will do that.17:55
enikanorov_SumitNaiksatam: sure...17:55
SumitNaiksatammestery enikanorov_: thanks17:56
mesteryThat's all for me on keys/certs, thanks SumitNaiksatam!17:56
SumitNaiksatami did not mention VPNaaS since i think we have the entire team here (nati_ueno and pcm_ :-P)17:56
SumitNaiksatammestery: thanks much for joining17:56
nati_uenohe he, so we agreed on how we store cert17:56
SumitNaiksatamnext topic17:56
nati_uenohow we save it on the file system?17:56
pcm_SumitNaiksatam: No idea, but I haven't work w/cert stuff.17:57
nati_uenoplain? or it should be encrypted?17:57
nati_uenoI don't know how we can encrypt & automation yet17:57
banixwho else uses barbican?17:58
SumitNaiksatamnati_ueno: we need a library in neutron?17:58
nati_uenoSumitNaiksatam: library for what?17:58
mesterynati_ueno: These are all good questions, I'm not sure.17:58
SumitNaiksatambanix:  good question, they will face the same issue17:58
SumitNaiksatamnati_ueno: to do the encryption17:58
SumitNaiksatamperhaps this is for oslo?17:59
nati_uenomestery: he he I'm expecting your nice answer17:59
banixSumitNaiksatam: hoping they have already and have a solution/lib17:59
mesterynati_ueno: :P17:59
*** SridarK has joined #openstack-meeting-317:59
nati_uenoSumitNaiksatam: even if we encrypt it, how we manage the key for encription17:59
mesterynati_ueno: More discussion needed here. :)17:59
nati_uenoya, it is more than this meeting timeslot17:59
SumitNaiksatamgerman_: anyone else uses barbican today?17:59
nati_uenoso let's keep discussion in the ML17:59
enikanorov_...after we know some more about barbican :)18:00
mesterynati_ueno: +118:00
german_Rackspace does and some at HP are evaluating18:00
*** hemanthravi has joined #openstack-meeting-318:00
SumitNaiksatamgerman_: ok perhaps we have more questions for you18:00
mesterygerman_: Good to know!18:00
nati_uenogerman_: cool! where is good how-to doc?18:00
SumitNaiksatam#action nati_ueno mestery Swami to take barbican support and local cert/key management discussion to mailer18:01
german_I will check with and get back to you via mailing list18:01
SumitNaiksatam#undo18:01
nati_uenogerman_: Thanks!!18:01
openstackRemoving item from minutes: <ircmeeting.items.Action object at 0x3800dd0>18:01
SumitNaiksatam: #action nati_ueno mestery german_ Swami to take barbican support and local cert/key management discussion to mailer18:01
SumitNaiksatam#topic Flavors Framework18:01
*** openstack changes topic to "Flavors Framework (Meeting topic: Networking Advanced Services)"18:01
SumitNaiksatam#link https://review.openstack.org/#/c/8305518:02
*** Tufin has joined #openstack-meeting-318:02
SumitNaiksatamenikanorov_: noticed that updated based on comments till date18:02
enikanorov_i've pushed pretty much complete description18:02
SumitNaiksatamenikanorov_: thanks18:02
enikanorov_yes18:02
SumitNaiksatamdid anyone get a chance to review the latest revision?18:02
SumitNaiksatami am unfortunately behind on this18:02
german_so am I18:03
nati_uenoThis is the spec https://review.openstack.org/#/c/90070/18:03
enikanorov_so i think we had a consensus on general idea18:03
enikanorov_nati_ueno: oh, thanks18:03
enikanorov_you're right18:03
german_there were some discussions about not using the word flavor18:03
SumitNaiksatamnati_ueno: thanks, sorry i mixed up the links18:03
enikanorov_so i think what still worth discussing is how to specify capabilities in flavor object18:03
enikanorov_and probably how to match them18:03
enikanorov_german_: i think majority is in favor of 'flavor'18:04
enikanorov_because it's similar concept to nova's18:04
SumitNaiksatamenikanorov_: so elaborate on “capabilities"?18:04
german_also I am wondering how the flavor system relates to the nova scheduler (GANT) which is being spun off and can select a machine "flavor"18:04
* nati_ueno put review the spec in today's todo18:04
enikanorov_SumitNaiksatam: it's a list of (name, value) pairs that flavor object is keeping18:04
SumitNaiksatamnati_ueno: thanks18:04
enikanorov_german_: it's same idea18:05
banixenikanorov_: you mean issues like wildcarding the match?18:05
enikanorov_german_: it's described in the spec btw, scheduling part18:05
german_thanks -- neat18:05
enikanorov_banix: i don't think we need to support wildcarding, but it's an interesting option18:05
enikanorov_haven't thought of it18:06
SumitNaiksatamenikanorov_: wouldnt wild card be the default option, so to say?18:06
german_so we are evaluating GANTT for that (https://github.com/openstack/gantt)18:06
enikanorov_SumitNaiksatam: a good question18:07
*** beyounn has joined #openstack-meeting-318:07
SumitNaiksatamgerman_: good to know18:07
enikanorov_i think i need to work more on defaults and migration18:07
pcm_how do the flavors get expressed by the client? dict? wondering how easy to specify for user.18:07
*** nati_ueno has quit IRC18:07
enikanorov_pcm_: falvor_id18:07
*** nati_ueno has joined #openstack-meeting-318:07
enikanorov_pcm_: right now the idea is that flavor specified by admin only18:08
pcm_enikanorov_: so flavors created separately, and then specify by ID18:08
enikanorov_yes18:08
enikanorov_user just lists them and specifies the id18:08
pcm_gotcha18:08
hemanthravidoesn't the user have to specify a key/value to find a matching flavor18:09
enikanorov_there's a small discussion on that in the 1st patchset between me and salvatore18:09
enikanorov_hemanthravi: no, and btw, key-value is apparently a wrong name for capability18:09
pcm_enikanorov_: will look at it.18:09
enikanorov_it's better to say (name, value)18:09
SumitNaiksatamenikanorov_: :-)18:09
banixmatching happens on selecting providers18:09
enikanorov_it's just because names can duplicate18:10
enikanorov_keys imply uniqueness18:10
SumitNaiksatamenikanorov_: ah got it18:10
hemanthravibanix: isn't flavor the mech to select a provider?18:10
pcm_enikanorov_: so flavor would contain "provider" info, so that feature could then select the driver?18:10
*** reaperhulk has left #openstack-meeting-318:11
enikanorov_pcm_: not necessarily18:11
enikanorov_pcm_: but that's possible18:11
pcm_enikanorov_: trying to understand how to support providers18:11
banixhemanthravi: yes but the user does not specify the list of name values18:11
s3wongenikanorov_: of course, even with "value", you can have multiple providers matching the criteria18:11
enikanorov_pcm_: you can create flavor that will point to provider, btw, that was implemented as an example in PoC patch18:11
enikanorov_s3wong: you can. you select some provier that satisfies all capabilities18:12
SumitNaiksatamenikanorov_: based on “vendor” name (per pcm_’s question)?18:12
enikanorov_pcm_: look at UTs: https://review.openstack.org/#/c/83055/18:12
enikanorov_SumitNaiksatam: yes, like that18:12
banix*possible*18:12
pcm_enikanorov_: will do18:13
enikanorov_that's just if some admin want to imitate existing workflow with providers18:13
SumitNaiksatamok, lets get some more eyes and comments on this gerrit bp at the earliest18:13
nati_uenoya, this is really important bp.18:13
SumitNaiksatamthis is in the critical path of other work services’ work18:13
nati_uenomay guys depends on this18:13
garyduanWhat is the plan for current STF patch?18:13
nati_uenoyep18:13
SumitNaiksatamso either we all agree on this and move ahead, or we suggest improvements at the earliest18:14
SumitNaiksatamwe cannot linger in this state for too long18:14
enikanorov_garyduan: id like STF to be integrated with services18:14
SumitNaiksatamenikanorov_ has done his job by posting the review, we all need to respond18:14
enikanorov_garyduan: as you remember, you need to move provider out of API, but preserve it as a dispatching mechanism18:14
hemanthravibanix: got it, flavor-id is the list of name/value pairs to find a provider18:14
garyduanenikanorov_: yes, I understand the flow18:15
enikanorov_garyduan: i think in such variant the patch should be fine with those (like Mark) who -1ed it18:15
SumitNaiksatamenikanorov_: do we have consensus with the other cores on using the STF at the backend?18:15
enikanorov_SumitNaiksatam: not yet i think18:15
garyduanso we wait for for flavor framework18:16
german_no, I need to see how it relates to gantt since we have a complex scheduling environment18:16
german_will put my comments in today18:16
garyduanwait for flavor framework to get in first?18:16
enikanorov_german_: it doesn't18:16
pcm_so STF selects driver based on provider on backend, and flavors gives a way to select provider (based on caps or vendor selection)?18:16
SumitNaiksatamenikanorov_: do you mention STF integration in the bp?18:16
enikanorov_SumitNaiksatam: no18:16
* pcm_ needs to look at the PoC18:16
enikanorov_SumitNaiksatam: integration is needed to actually apply Flavors to fwaas/vpnaas18:17
nati_uenoenikanorov_: yep18:17
enikanorov_but it isn't needed to implement API, DB and common code for plugins part18:17
SumitNaiksatamenikanorov_: actually that should be fine since we can have that discussion independent of the user facing flavors abstraction18:17
SumitNaiksatamenikanorov_: yes18:17
enikanorov_SumitNaiksatam: agree18:17
SumitNaiksatamok, all please comment on the review18:17
SumitNaiksatam#topic Service context with Service Interfaces18:18
*** openstack changes topic to "Service context with Service Interfaces (Meeting topic: Networking Advanced Services)"18:18
SumitNaiksatam#undo18:18
openstackRemoving item from minutes: <ircmeeting.items.Topic object at 0x38ad890>18:18
garyduanenikanorov_, SumitNaiksatam: so if STF is to be the backend, get STF in, hide provider selection is one path to move forward18:18
SumitNaiksatam#topic Service Insertion with Service Interfaces18:18
*** openstack changes topic to "Service Insertion with Service Interfaces (Meeting topic: Networking Advanced Services)"18:18
SumitNaiksatamgaryduan: i agree18:18
enikanorov_garyduan: right18:18
SumitNaiksatam#link https://docs.google.com/document/d/1AlEockwk0Ir267U9uFDc-Q6vYsWiAcAoKtCJM0Jc5UI/edit#18:18
SumitNaiksatamKanzhe: you want to update on the latest round of discussions?18:19
SumitNaiksatamwe will have to keep it quick since we have a couple of other agenda items18:19
KanzheSumitNaiksatam: sure, a quick update.18:19
KanzheThere are some feedback on serviceInsertion proposal.18:19
* nati_ueno may be,, neutron-spec police is comming18:20
KanzheThe main point is to introduce an new object that can be used as service insertion point.18:20
*** nati_ueno has quit IRC18:20
SumitNaiksatamnati_ueno: gerrit spec is coming soon, until then we will bribe the police :-)18:20
KanzheIt could be a neutron port, or extended to L1 port in the future.18:21
*** nati_ueno has joined #openstack-meeting-318:21
KanzheI will update the doc and convert to BP in gerrit later the week.18:21
nati_uenoKanzhe: Thanks!18:21
*** beyounn has quit IRC18:22
Kanzheover. :-)18:22
SridarKKanzhe: the doc in its current form is close to the last round of discussions ?18:22
banixKanzhe: thanks18:22
KanzheNot yet. didn't have time to update with the latest design.18:22
s3wongKanzhe: are we merging serviceBase and serviceInterface into one spec?18:22
KanzheWill do it later today.18:22
KanzheI think so.18:23
banixs3wong: Kanzhe combining makes sense18:23
SridarKKanzhe: ok will wait on that18:23
Kanzhes3wong: +118:23
s3wongbanix Kanzhe: cool18:23
SumitNaiksatamthe only reason they might be different is if they need to first make things backward compatible18:24
SumitNaiksatamwe need to think through18:24
SumitNaiksatamand will need input from enikanorov_ and nati_ueno on this18:24
banixgood point; wasnt thinking about that18:24
nati_uenoSumitNaiksatam: Sure!18:24
SumitNaiksatamwith regards to LBaaS and VPNaaS18:24
s3wongSumitNaiksatam: OK, makes sense18:25
enikanorov_things aer quite complex on lbaas front :)18:25
banixythat conversation should happen before the submission to review. no?18:25
SumitNaiksatamenikanorov_: :-)18:25
SumitNaiksatambanix: yes, that is hte reason we are doing this on gdoc18:25
banixyup18:26
SumitNaiksatamto at least get some critical mass to converge on the basic idea18:26
SumitNaiksatamperhaps we need some explanation in the doc for this18:26
SumitNaiksatami guess Kanzhe will follow up18:26
SumitNaiksatamnext topic18:26
banixyeah; in this particular case we need VPNaaS and LBaaS onboard18:26
KanzheSumitNaiksatam: yes.18:26
SumitNaiksatamKanzhe: thanks18:26
SumitNaiksatamenikanorov_: btw, forgot to mention thanks for the earlier update on flavors18:27
SumitNaiksatam#topic Port Chaining Proposal18:27
*** openstack changes topic to "Port Chaining Proposal (Meeting topic: Networking Advanced Services)"18:27
SumitNaiksatam#link https://docs.google.com/document/d/1Bk1e8-diE1VnzlbM8l479Mjx2vKliqdqC_3l5S56ITU/edit18:27
SumitNaiksatamcgoncalves jsoares: there?18:27
cgoncalves\o/18:27
jsoaresyup18:27
SumitNaiksatamyou will see that this is incorporated into the bigger plan18:27
SumitNaiksatamdoes everyone agree with this as the traffic steering building block?18:28
cgoncalvesso this week we got some feedback from some of you (thanks!)18:28
*** Tufin has quit IRC18:28
cgoncalvesand we've removed the idea of Flow and Endpoint as per SumitNaiksatam suggestion18:28
jsoaresupdates that lead to relevant updates :)18:28
SumitNaiksatamcgoncalves jsoares: thanks18:29
*** rustlebee has left #openstack-meeting-318:29
SumitNaiksatamso if there are no major objections, cgoncalves and jsoares can move this to the gerrit bp process18:30
*** emagana has quit IRC18:30
*** samchoi has quit IRC18:30
*** jamie_h has quit IRC18:31
SumitNaiksatami also think this is an independent peice, so can be worked on in parallel18:31
cgoncalvesSumitNaiksatam: yes, that would be the next move I suppose. if all agree, I will do it this week18:31
nati_uenoIs service chain still needed even if we have GP?18:31
SumitNaiksatamnati_ueno: yes18:31
banixnati_ueno: yes18:31
nati_ueno:)18:32
hemanthraviyes on the service_chain18:32
SwamiYes +118:32
SumitNaiksatamnati_ueno: we tried to explain that a little in the high level document18:32
SumitNaiksatamnati_ueno: the service chain abstraction can make use of the traffic sterring abstraction18:33
nati_uenoso if we have a chain or graph of services in the contract policy rule action, we can do this, right?18:33
SumitNaiksatamnati_ueno: are you referring to group policy?18:33
nati_uenoyes18:33
banixat least as GP is defined now we refer to a service chain as defined in services18:34
SumitNaiksatambanix: yeah18:34
*** otherwiseguy has quit IRC18:34
nati_uenobanix: yeah, but isn't it more simple?18:34
cgoncalvesservice chain will rely on port chain, and GP on service chain. that's the plan if i'm not mistaken18:34
SumitNaiksatamand that service chain in turn might use the traffic steering to actually achieve the chain18:34
SumitNaiksatamcgoncalves: yeah, meant to say that18:34
banixnati_ueno: it is easier to use a chain defined elsewhere :)18:35
SumitNaiksatambanix: agree18:35
s3wongnati_ueno: we don't really define service chain in GP; only that the policy enforced between a group going to another group18:35
SumitNaiksatams3wong: agree18:35
SumitNaiksatamokay we running over time18:35
SumitNaiksatamnati_ueno: we can perhaps take this offline?18:35
banixnati_ueno: we have thought of what I think you are suggesting though.18:35
SumitNaiksatami have one more agenda item18:35
nati_uenohmm I'm worring about resource model getting really complex..18:35
nati_uenodo we have complete horizon wireframe for this?18:36
banixnati_ueno: agree but at least this way there is a seperation …18:36
banixnati_ueno: what is a wireframe?18:36
nati_uenobanix: a wireframe is a design of UI workflow18:37
SumitNaiksatamnati_ueno: we are looking for a volunteer to do horizon work, do you want to volunteer? :-)18:37
banixSumitNaiksatam: sorry you wanted to discuss something else18:37
nati_uenobanix: you can see example in tripleo-ui18:37
nati_uenoSumitNaiksatam: ya, if I can understand models :)18:37
*** Tufin has joined #openstack-meeting-318:37
nati_uenoSumitNaiksatam: so please help me18:37
banixnati_ueno: do you have a pointer? is that part of dashboard already?18:37
SumitNaiksatamnati_ueno: only if you are willing to :-)18:37
nati_uenoSumitNaiksatam: I do!18:37
banixnati_ueno: you got it! :)18:38
SridarK"I do" famous words often said and regretted later :-)18:38
SumitNaiksatamnati_ueno: on a more serious note, ronak who is not here, has volunteered for horizon support18:38
nati_uenobanix: this is ample http://ask-openstackux.rhcloud.com/question/95/tripleo-ui-resource-management/18:38
SumitNaiksatambut we are going off topic here18:38
banixnati_ueno: great. thx.18:38
nati_uenoSridarK: he he he18:38
SumitNaiksatamwe have group policy meeting tomorrow where we can bring this up18:38
nati_uenoSridarK: in that case, Kyle do it18:39
SumitNaiksatamcgoncalves jsoares thanks for the update18:39
SridarKnati_ueno: :-)18:39
cgoncalvesSumitNaiksatam: thank you for bringing this up in the first place ;-)18:39
SumitNaiksatam#topic Atlanta Design Summit session18:39
*** openstack changes topic to "Atlanta Design Summit session (Meeting topic: Networking Advanced Services)"18:39
SumitNaiksatamwe have a 40 min session18:39
SumitNaiksatamits shared between this discussion including flavors and another proposal18:40
SumitNaiksatam#link http://junodesignsummit.sched.org/event/b16e5bab304eb57baef9188a081ed962#.U2EyFa1dX3A18:40
SumitNaiksatami think schedule is subject to change18:40
SumitNaiksatamsince time is short for a long discussion such as this18:40
nati_uenohow about to use the time with reviewing gerrit?18:40
SumitNaiksatamit will help to prepare as much in advance as possible18:40
SumitNaiksatamnati_ueno: yeah sure18:41
banixSumitNaiksatam:  can we have only a subset of topics dicussed today in the design session or you think we need all?18:41
SumitNaiksatambanix: i agree, thats what i meant by lets plan18:41
s3wongSumitNaiksatam: what are you proposing?18:41
SumitNaiksatamlets decide as a team as to what needs the attention of the face-to-face discussion with the rest of the community18:41
SridarKSumitNaiksatam: Can we atleast get a solid buy in on Service Insertion at the bare minimum ?18:42
banixSumitNaiksatam: considerring the limitted time, should we focus on the core issues … yes18:42
SumitNaiksatamSridarK banix: yes18:42
SumitNaiksatams3wong: i am just throwing it up for your suggestions18:42
banixs3wong: we wont have time to cover all these topics18:42
SumitNaiksatamif we start with the flavors topic, that in itseld might consume the whole session18:43
german_yep18:43
SumitNaiksatamso we need to balance18:43
s3wongSumitNaiksatam: obviously with only potentially 15 or so miniutes, we can't do service base definition, service insertion, and service chaining :-)18:43
SumitNaiksatams3wong: :-)18:43
hemanthraviSumitNaiksatam: 1,2,3 from your doc https://docs.google.com/a/oneconvergence.com/document/d/1hshzNDfBrMj7C_3HnVaUlMSuAzea9MI7S3wLKH5eJmc/edit#18:43
SumitNaiksatamhemanthravi: ok18:43
banixservice definition and insertion to begin with18:44
SumitNaiksatamso if we have topics in gerrit review prior to the summit, at least we will have a head start18:44
KanzheSumitNaiksatam: Let's get all the gerrit BPs in place. Maybe the ones with least discussion needs to be discussed.18:44
SumitNaiksatamKanzhe banix: sure18:44
SumitNaiksatamok i wanted to plant the seed and solicit ideas18:45
SumitNaiksatamwe are 15 minutes over!18:45
SumitNaiksatamthanks all for your participation18:45
SumitNaiksatamuntil next week, bye!18:45
german_thanks18:45
SumitNaiksatam#endmeeting18:45
banixSumitNaiksatam: we won’t reach a consensus during the session anyways so we may want to think of gerrit plus some one on ones, etc as well18:45
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"18:45
openstackMeeting ended Wed Apr 30 18:45:30 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:45
openstackMinutes:        http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-04-30-17.32.html18:45
banixbyes18:45
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-04-30-17.32.txt18:45
openstackLog:            http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-04-30-17.32.log.html18:45
*** german_ has left #openstack-meeting-318:45
Swamibye18:45
SridarKbye18:45
SumitNaiksatambanix: absolutely18:45
nati_uenobye!18:45
s3wongbye guys!18:46
SumitNaiksatambanix: it will be very difficult to get consensus in short time18:46
banixSumitNaiksatam: yeah18:46
garyduanno FWaaS meeting today?18:46
SumitNaiksatamgaryduan: yes, starting now18:46
garyduan:-)18:46
*** beagles has left #openstack-meeting-318:47
SumitNaiksatamgaryduan: sorry for holding up :-P18:47
garyduanSumitNaiksatam: not at all18:47
SumitNaiksatam#startmeeting Networking FWaaS18:47
openstackMeeting started Wed Apr 30 18:47:44 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.18:47
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.18:47
*** openstack changes topic to " (Meeting topic: Networking FWaaS)"18:47
openstackThe meeting name has been set to 'networking_fwaas'18:47
*** nati_ueno has quit IRC18:47
SumitNaiksatam#topic STF patch18:48
*** openstack changes topic to "STF patch (Meeting topic: Networking FWaaS)"18:48
SumitNaiksatambtw, SridarK garyduan, still here?18:48
garyduanyes18:48
*** nati_ueno has joined #openstack-meeting-318:48
SridarKSumitNaiksatam: yes here18:48
*** nati_ueno has quit IRC18:49
SumitNaiksatamsorry for the delay18:49
SridarKno worries18:49
SumitNaiksatamgaryduan: thanks for taking the effort on the STF patch18:49
SumitNaiksatamgaryduan: you saw some of the discussions on flavors18:49
SumitNaiksatamgaryduan: i am hoping that STF will stil be used18:50
garyduanSumitNaiksatam: I think it will, right?18:50
SumitNaiksatamgaryduan: enikanorov_ is proposing that18:50
garyduanSumitNaiksatam: eventually need to map to driver18:50
SumitNaiksatamgaryduan: i am not sure everyone is on board though18:50
*** nati_ueno has joined #openstack-meeting-318:51
SridarKi guess only the mapping part will change ?18:51
SumitNaiksatamgaryduan: if we like that idea we should push for it18:51
garyduanSumitNaiksatam: the alternative is everyone write their plugin18:51
SumitNaiksatamSridarK: true, some changes18:51
SumitNaiksatamgaryduan: yeah, that should not be the only option18:51
*** hemanthravi has quit IRC18:51
SridarKgaryduan: SumitNaiksatam perhaps from a vendor perspective we need to start with writing as a svc plugin18:52
SridarKand refactor when this becomes avail ?18:52
SumitNaiksatamSridarK: certainly an option, perhaps will illustrate to the community the need for the framework, once they see common code18:52
enikanorov_SridarK: that would be quite difficult18:52
enikanorov_SridarK: i think you need to target a driver from the beginning18:53
SumitNaiksatambut certainly helps vendors to make progress18:53
SridarKenikanorov_: agree only on timing of release cycles for products18:53
enikanorov_moving from plugin to driver can be difficult18:53
SumitNaiksatamenikanorov_: the concern here is that the vendors have not been able to make progress in the entire icehouse cycle18:53
enikanorov_as you need to deprecate, change deployment practive, etc18:53
SridarKenikanorov_: rather i meant that is the only reason to take that extreme approach18:54
SumitNaiksatamenikanorov_: and there is stil no clear path for them in Juno18:54
SumitNaiksatamenikanorov_: if there is a way to provide enough evidence that they can get a driver out based on a framework, within Juno, we are forcing them to take this extreme approach18:54
enikanorov_SumitNaiksatam: i think that's a management problem. we need to bring those who 'not onboard' to our meetings or to propose alternative approaches18:55
SumitNaiksatamenikanorov_: i agree there is a process issue18:55
enikanorov_otherwise it all can be unproductive. And i personally think that issue is no big deal from impl perspective18:55
SumitNaiksatamwe are having meetings in the community including this one18:55
enikanorov_but rather important from UX perspective18:55
SumitNaiksatamnot sure what more to do to get people to participate18:56
enikanorov_SumitNaiksatam: yeah, but I noticed that bps are getting reviewed by whole oother group of people :)18:56
enikanorov_(then who attend the meetings i mean)18:56
SumitNaiksatamenikanorov_: i believe you are saying that those review bps dont attend these meetings18:57
SumitNaiksatamenikanorov_: i agree18:57
enikanorov_yep18:57
SridarKI do hope we can get this adopted and agreed upon even if we start getting it out in phases18:57
SumitNaiksatamenikanorov_: i think the people who attend the meetings should commet on the reviews and reference the discussion in the meetings18:57
SumitNaiksatam*comment18:57
SumitNaiksatamanyway18:57
*** jsoares has quit IRC18:57
*** david-lyle has quit IRC18:57
SumitNaiksatamwe digressed a bit18:58
SridarKsorry18:58
SumitNaiksatamenikanorov_: so you plan to bring up the STF tie in as separate bp spec?18:58
enikanorov_oh...18:58
SumitNaiksatamSridarK: no, not at all18:58
enikanorov_i can take it, but i'm not sure i'll have enough bandwidth for this18:59
SumitNaiksatamenikanorov_: understandable19:01
SridarKSumitNaiksatam: The notion of keeping STF is good - so with garyduan: 's work for fwaas - vendors have something to work against - i think that will be easier to digest19:01
SumitNaiksatamSridarK: agree19:01
enikanorov_i think basically we need to work with mark macclain to resolve his concerns19:01
SumitNaiksatamgaryduan SridarK: any chance that you will have the bandwidth to refactor STF?19:01
SumitNaiksatamenikanorov_: ok19:01
*** eghobo has quit IRC19:01
*** peristeri has quit IRC19:01
garyduanSumitNaiksatam: no problem19:01
SridarKSumitNaiksatam: i can help some - but i may get oversubscribed - we can talk offline19:01
* SumitNaiksatam thinks this is quite a bit of a heavy protocol to have to individually reach out to people19:01
SumitNaiksatamgaryduan SridarK: good19:01
SumitNaiksatamenikanorov_: lets bring this up with the PTL, what say?19:02
enikanorov_yes sure19:02
SumitNaiksatam#action SumitNaiksatam enikanorov_ to reach out to mestery and mark mcclain to sort out the future of the service provider framework19:03
*** sdague has quit IRC19:03
mesteryhttps://wiki.opendaylight.org/images/HostedFiles/Fedora20_ODL_OpenStack.zip19:03
*** sdague has joined #openstack-meeting-319:03
* SumitNaiksatam happy to see mestery participate in some way in FWaaS :-)19:05
SumitNaiksatamon next topic19:05
mesterySumitNaiksatam: Yes me too!19:05
SumitNaiksatammestery: we wanted to reach out to you regarding the service provider framework19:05
pcm_wondering about STF for VPNaaS as well19:05
SumitNaiksatampcm_: good19:05
SumitNaiksatammestery: wondering if this meeting is a good time, or we should send you an meail19:05
SumitNaiksatamemail19:05
pcm_Nachi had a review (and I had client code), but both nixed in icehouse19:06
mesterySumitNaiksatam: Lets see what we can cover her19:06
SumitNaiksatamthe firewall and the VPN vendors are having a really tough time integrating their drivers19:06
pcm_Guess we should have a common solution for all services (and maybe push up to common code)?19:06
pcm_SumitNaiksatam: yeah, that be me19:06
SumitNaiksatamthey have tried to use the service time framework (which is now evolving to flavors) before, but their patches are on hold now19:06
SwamiSumitNaiksatam: yes you are right, we need to have the Framework sorted out for the services.19:07
SumitNaiksatampcm_ Swami: yes19:07
SumitNaiksatammestery:  so while we are making progress with the flavors discussion19:07
SumitNaiksatammestery: how that ties in to the backed provider is not clear19:07
mesterySumitNaiksatam: OK. Any plans there or ideas?19:07
SumitNaiksatammestery: enikanorov_ has been suggesting that we reuse the existing service type framework for that19:08
mesteryThat makes some sense. :)19:08
SumitNaiksatammestery: others seem to be in agreement19:08
SumitNaiksatamenikanorov_: can you share your thoughts? or what the objections are?19:08
enikanorov_mestery: there's however some specifics. right now STF has a bit of public API19:08
enikanorov_and that bit is not quite suitable for public clouds19:08
enikanorov_so we just remove it in favow of flavor framework19:09
enikanorov_*in favor19:09
enikanorov_but STF is also a dispatching mechanism from rest calls to vendor drivers19:09
enikanorov_that part is really useful19:09
SumitNaiksatamenikanorov_: so your proposal is to refactor that part and keep it19:10
*** TravT|2 has joined #openstack-meeting-319:10
SumitNaiksatami also have not see any alterante proposal19:10
enikanorov_SumitNaiksatam: exactly19:10
SridarKenikanorov_: also if this keeps the plugin - driver i/f reasonably intact except for the provider scheduling aspect - something to start off with19:11
SumitNaiksatammestery: some of the firewall team members participating here and representing vendors are suggesting that they might have to take extreme approach of creating vendor specific service plugins if they dont have a resolution to this19:11
*** TravT has quit IRC19:11
SumitNaiksatammestery: i am guessing this is the same with VPNaaS as well19:12
mesterySumitNaiksatam: Understood. So is hte issue we need to get the framework merged soon?19:12
SridarKenikanorov_: perhaps "reasonably" is a bit of a stretch but atleast something to start with19:12
enikanorov_i think that approach is not good, it will create a lot of contention once API will develop19:12
enikanorov_SridarK: it will keep plugin and driver's interface19:12
SumitNaiksatammestery: i believe the issue is that there is some opposition to keeping that part of the STF19:12
SumitNaiksatamenikanorov_: i am articulating the issue correctly?19:13
mesterySumitNaiksatam enikanorov_: Understood.19:13
enikanorov_SumitNaiksatam: as far as i understand, the concern is about user allowed to chose implementation (vendor)19:13
pcm_same issue with VPNaaS, currently, no way to support mutiple providers.19:13
enikanorov_so it's about implementation typesbeing exposed19:13
SumitNaiksatamenikanorov_: but you are addressing that with the flavors framework19:13
enikanorov_once we hide it behind flavors - we still can leverage dispatching mechanism of STF19:14
SumitNaiksatamenikanorov_: so ideally once that is addressed there should not be an issue with using STF in the backend19:14
enikanorov_still can = still should19:14
enikanorov_SumitNaiksatam: yes19:14
SumitNaiksatammestery: ok it seems like we need your nod on this19:14
garyduanI think it's the most feasible way19:14
enikanorov_SumitNaiksatam: so right now i'm suggesting to merge the patch STF+fwaas, removing 'provider' from public API19:14
SumitNaiksatamenikanorov_: agree19:15
enikanorov_SumitNaiksatam: it's 'noop' from functionality perspective, but a basis for flavors applied to fwaas19:15
SridarKthis seems like a light at the end of the tunnel :-)19:15
mesterySumitNaiksatam: OK, understood. Doing 2 meetings at once now, apologies. :)19:15
SumitNaiksatammestery: no worries, at least you are listening to us :-)19:15
mestery:)19:15
SridarKmestery: u need to clone urself :-)19:15
mesterySridarkK: :P19:15
SumitNaiksatamSridarK: :D19:16
SumitNaiksatamenikanorov_ garyduan: i think we should push forward with the proposal19:16
pcm_So, once flavors is avail, we'll have the selection (UI) component. in the meantime use the same method of selecting (sole) default provider in neutron.conf?19:16
*** Kanzhe has quit IRC19:16
SumitNaiksatampcm_: i would think so19:16
enikanorov_pcm_: yes19:17
pcm_sounds good to me... hsip it :)19:17
SridarKenikanorov_: if this flies then it will be refactoring a STF implementation to flavors19:17
pcm_ship19:17
enikanorov_SridarK: not exactly19:17
enikanorov_SridarK: STF is a bit of different part of mechanism19:17
SridarKenikanorov_:19:18
enikanorov_STF is about dispatchin rest calls to drivers19:18
enikanorov_Flavors is about cheduling service instance to a driver and to a backend19:18
SridarKenikanorov_: agree at least better than svc plugin to flavors19:18
SridarKenikanorov_: that is what i meant19:18
enikanorov_ok19:18
SumitNaiksatamenikanorov_: can we have a short write up of how the STF refactoring should happen in your opinion?19:19
SumitNaiksatamenikanorov_: i know you are swamped19:19
SumitNaiksatamenikanorov_: but we need to be on the same page19:19
enikanorov_SumitNaiksatam: yes, will do19:19
enikanorov_SumitNaiksatam: should i post it to neutron spec?19:19
SumitNaiksatamok good, enikanorov_ thanks19:19
SumitNaiksatamenikanorov_: sure19:19
enikanorov_ok19:19
SumitNaiksatamwe can then decide, who can take that up19:19
SumitNaiksatamgaryduan: perhaps you can follow up on that19:20
Swamienikanorov_: that would be nice19:20
garyduanSumitNaiksatam: ok19:20
SumitNaiksatam#action enikanorov_ to post STF refactor proposal19:20
SridarKenikanorov_: perhaps a few of us can also discuss at some point during the summit19:20
garyduanSumitNaiksatam: I will submit the spec to gerrit19:20
enikanorov_SridarK: sure19:21
SumitNaiksatamSridarK: i would hope we sort this out before the summit19:21
SumitNaiksatamthat would be ideal :-)19:21
SridarKSumitNaiksatam: yes that would be best19:21
pcm_+119:22
SumitNaiksatamenikanorov_: thanks much for that19:22
SumitNaiksatammestery: as well19:22
Swamisumit: can you include me in any offline discussion19:22
SumitNaiksatamSwami: of course19:22
SwamiSumitNaiksatam: thanks19:22
SumitNaiksatamgaryduan are you feeling more comfortable now?19:22
SumitNaiksatamregarding STF patch that is19:23
garyduanSumitNaiksatam: :-)19:23
SumitNaiksatamok moving on19:23
SumitNaiksatam#topic Firewall Zones19:23
*** openstack changes topic to "Firewall Zones (Meeting topic: Networking FWaaS)"19:23
SumitNaiksatamSridarK: can you provide upate?19:24
SumitNaiksatam*udpate19:24
*** Tufin has quit IRC19:24
SridarKsome more questions on how we want to model zones - whether as a neutron resource or we can provide this as a list of existing neutron resources (ports etc)19:25
*** beyounn has joined #openstack-meeting-319:25
*** nati_ueno has quit IRC19:25
SridarKfrom the service context discussion perhaps as a list seems more in line ?19:25
SridarKAlso thinking in terms of zones and service context looking at zones as a subset of where the service is inserted19:26
SumitNaiksatamSridarK: okay19:27
SumitNaiksatamSridarK:  you were working on a document for this19:27
SridarKcapturing some thoughts for perhaps an internal discussion and the push it up19:27
SumitNaiksatami am still a little bit on the fence19:27
SridarKyes19:27
SumitNaiksatamit seems like an uphill battle to convince the rest of the community19:28
SumitNaiksatamwe will do it if it is required19:28
SumitNaiksatambut we need to see what our priorities are19:28
SumitNaiksatamgaryduan: what do you think?19:29
SumitNaiksatamSridarK: sorry, commenting without looking at the doc19:29
garyduanI think port is fine19:29
SumitNaiksatamSridarK: but since you mentioned that there might be an alternative19:29
SridarKSumitNaiksatam: are u saying for zones or more in general on services insertion etc19:29
SumitNaiksatamgaryduan: ok19:29
garyduanfor edge firewall, this concept still applies19:29
SumitNaiksatamSridarK: i meant zones19:29
SridarKSumitNaiksatam: no issues - want to have more discussion on this - so that is good19:30
SumitNaiksatamgaryduan: with the current service insertion suggestion, we might be able to apply the service on a port19:30
SridarKSumitNaiksatam: ok - i think we will put in usecases across vendors and customers to what extent can be shared19:30
garyduanSumitNaiksatam: yes. that's why i was thinking in that direction too19:31
SumitNaiksatamSridarK: ok good, and we can accordingly validate if the current service insertion suggestion help19:31
SumitNaiksatamgaryduan: ok good19:31
SridarKSumitNaiksatam: garyduan: But we will need different FW instances for each zone pair ?19:31
garyduanSumitNaiksatam: but I believe there some use cases that the traditonal zone fits better19:31
beyounnSumitNaiksatam: just to confirm, when we apply server to ports, there also be direction info, right?19:32
beyounns/server/service/19:32
*** mfer has quit IRC19:32
SumitNaiksatambeyounn: good question19:32
*** david-lyle has joined #openstack-meeting-319:32
SumitNaiksatambeyounn: i believe if we have direction notion, then it will satisfy zones requirement?19:33
SridarKSumitNaiksatam: i saw direction in latest doc from Kanjie19:33
beyounnSumitNaiksatam: that is my feeling19:33
SumitNaiksatamSridarK: i am not completely sure about that19:33
SumitNaiksatambeyounn: so we have direction in the firewall rules, right?19:34
SridarKSumitNaiksatam: ok19:34
beyounnSumitNaiksatam: when we want is something like "from zone1 to zone2 match source_address,dest_address,port.. then reject"19:34
beyounns/when/what/19:35
beyounnSumitNaiksatam:but from zone2 to zone1 the rule can be different19:35
SumitNaiksatami doubt that service insertion is going to have a directional notion19:35
SridarKbeyounn: yes19:36
SumitNaiksatami am just trying to look up what is the notion of direction on our firewall rules19:36
SumitNaiksatamoh actually we dont have direction19:37
SumitNaiksatamwe have source and destination19:37
SridarKSumitNaiksatam: we only have src , dst19:37
*** pcm_ has left #openstack-meeting-319:38
beyounnhow about we still stick with Zone and build test case around of it and then compare with service insertion to see if it can fit?19:38
SridarKwe will need to overlay the notion of direction btwn zones19:38
beyounns/test case/use case/19:38
SumitNaiksatambeyounn: sure19:38
SumitNaiksatamSridarK: you are going to do that?19:38
SridarKSumitNaiksatam: yes19:38
SridarKSumitNaiksatam: beyounn garyduan: perhaps we can have some offline discussions too19:39
SumitNaiksatamSridarK: sure19:39
beyounnSridark:sure19:39
beyounnSumitNaiksatam: how was the plan for F2F mgt?19:39
SumitNaiksatam#action SridarK to work on draft of zones proposal, focussing on use case19:39
SumitNaiksatambeyounn: sure, lets take that offline19:39
SridarKperhaps beyounn: & I will run into each other if we are working out side ;-)19:40
beyounnSumitNaiksatam:ok19:40
SumitNaiksatamSridarK: ah thats what you meant by offline :-)19:40
beyounnSridark: Let have a beer :-)19:40
beyounnI have good wine in my home :-)19:40
SridarKSumitNaiksatam: thanks - i think some offline brainstorming will help - some dependency on service insertion will also need to be clarified so we can model accordingly19:41
SridarKSumitNaiksatam: beyounn; ;-)19:41
SumitNaiksatam#topic Service Objects19:41
*** openstack changes topic to "Service Objects (Meeting topic: Networking FWaaS)"19:41
SumitNaiksatambeyounn: we intend to target this for Juno?19:41
beyounnSumitNaiksatam:Still, I will write spec19:42
SumitNaiksatambeyounn:  ok great19:42
SumitNaiksatam#action beyounn to submit gerrit bp spec for Service Objects extension: https://blueprints.launchpad.net/neutron/+spec/fwaas-customized-service19:42
SumitNaiksatam#topic Juno priorities and Atlanta design summit session discussion19:43
*** openstack changes topic to "Juno priorities and Atlanta design summit session discussion (Meeting topic: Networking FWaaS)"19:43
SumitNaiksatam#info design summit session: http://junodesignsummit.sched.org/event/72f3dc6498fa2821fab5f941b9690da919:43
SumitNaiksatamwe have a share 40 minute slot with VPNaaS19:44
SumitNaiksatam*shared19:44
SumitNaiksatamso we will get 20 minutes19:44
SridarKSumitNaiksatam: it will be good if we can drive some commonality with VPN on service insertion19:44
garyduanDo we plan any other things in FWaaS19:45
SumitNaiksatamSridarK: we will discuss service insertion in the advanced services common requirements session19:45
SridarKSumitNaiksatam: yes agreed19:45
SumitNaiksatamgaryduan: everything is up for discussion at this stage19:45
*** mfer has joined #openstack-meeting-319:45
garyduanLike logging, app-id etc.19:45
SumitNaiksatamincluding vendor drivers19:45
SumitNaiksatamgaryduan: do we have the resources to do that?19:46
beyounnand address book19:46
SridarKSumitNaiksatam: we will have a vendor BP19:46
SumitNaiksatamgaryduan: since we were blocked in icehouse, i would like be more focussed in juno to push forward19:47
SumitNaiksatam*like to19:47
garyduanSumitNaiksatam: agreed19:47
SumitNaiksatamwe need to decide absolutely what we want to get through in Juno19:47
SumitNaiksatamplease think accordingly19:47
SumitNaiksatamwe will also be looking for reviewers attention19:48
*** otherwiseguy has joined #openstack-meeting-319:48
SumitNaiksatamso its not just how fast we can churn patches, we also need reviewers to be able to review them19:48
garyduanSumitNaiksatam: that's partly process issue19:48
SumitNaiksatamif we put too many things out there at the same time, it dilutes reviewers attention and nothing gets in19:49
SumitNaiksatamgaryduan: i think process is changing, but its a bit of everything19:49
SumitNaiksatamgaryduan: so we need to be pragmatic19:50
garyduanSumitNaiksatam: I don't think we have time to do those things, but some discuss in F-to-F meeting might be helpful19:50
SumitNaiksatamgaryduan: you yeah absolutely19:50
SumitNaiksatamgaryduan: we need to have a long term road map for sure, i think we have had on19:50
SumitNaiksatami am just asking now about Juno19:50
SumitNaiksatamwhat are our absolute priorities19:51
SumitNaiksatami believe the ones we already have in flight (service insertion and STF) are the ones we have already identified19:51
SridarKSumitNaiksatam: IMO, zones is important19:51
SumitNaiksatamwe need to decide besides those what is critical19:51
garyduanand beyounn's patch too19:52
garyduanto make FWaaS complete19:52
SumitNaiksatamgaryduan: yeah19:52
garyduannot really complete, but cover the basis19:53
SumitNaiksatamso i would think that the realistic thing is here to first focus on the patches that we already have in flight19:53
SumitNaiksatamwe need to file new blueprints for them, and that itself is going to take some more time to converge19:53
SumitNaiksatambesides i believe both SridarK  and garyduan have the vendor drivers planned as well, right?19:53
SridarKSumitNaiksatam: yes19:54
garyduanSumitNaiksatam: yes, in our case, refactor19:54
SumitNaiksatamso thats going to be a handful between 3 or 4 people19:54
*** mwagner_lap has quit IRC19:55
SumitNaiksatamand considering the limited reviewer attention we get19:55
SumitNaiksatami would propose that we focus on these things which are in flight first, and once we the blueprints are re-approved, code patches are resubmitted, we can potentially think of any new features we can try to target for juno19:56
SumitNaiksatamwe can definitely have discussions on features in longer term road map, but that would be proposed priority - first get our existing patches reviewed and merged19:56
garyduanyes19:57
*** mrunge has joined #openstack-meeting-319:57
SridarKSumitNaiksatam: sure and we can continue more offline discussions too19:57
SumitNaiksatamif we can get that far, that will be a huge step forward compared to icehouse :-)19:57
SumitNaiksatamSridarK: absolutely19:57
SumitNaiksatamok lets, starting thinking in terms of the couple of topics that we might want to bring up in the summit discussion19:58
SumitNaiksatamwe also need to create an etherpad19:58
SumitNaiksatamanyone want to do that?19:58
SumitNaiksatamor else i can do it19:58
SridarKSumitNaiksatam: I can do it19:58
SumitNaiksatamSridarK: great19:59
SumitNaiksatam#action SridarK to create design summit etherpad19:59
SumitNaiksatamalrighty, anything more for now?19:59
garyduanno for me20:00
SumitNaiksatamits been a long meeting, but i think we at least made progress on the STF discussion20:00
SridarKwe can figure out more next steps offline then20:00
SumitNaiksatamSridarK: yes20:00
SumitNaiksatamgreat, thanks SridarK garyduan beyounn for joining20:00
SumitNaiksatambye all!20:00
garyduanbye20:00
SumitNaiksatamSwami: as well20:00
SridarKThanks and bye all20:00
*** nati_ueno has joined #openstack-meeting-320:00
SumitNaiksatam#endmeeting20:00
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"20:00
openstackMeeting ended Wed Apr 30 20:00:53 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)20:00
openstackMinutes:        http://eavesdrop.openstack.org/meetings/networking_fwaas/2014/networking_fwaas.2014-04-30-18.47.html20:00
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/networking_fwaas/2014/networking_fwaas.2014-04-30-18.47.txt20:00
openstackLog:            http://eavesdrop.openstack.org/meetings/networking_fwaas/2014/networking_fwaas.2014-04-30-18.47.log.html20:00
*** markmcclain has joined #openstack-meeting-320:03
*** nati_ueno has quit IRC20:04
*** eghobo has joined #openstack-meeting-320:07
*** TravT|2 has quit IRC20:12
*** mandeep has quit IRC20:21
*** SumitNaiksatam has quit IRC20:25
-openstackstatus- NOTICE: the gate is backed up due to broken nodepool images, fix in progress (eta 22:00 utc)20:25
*** ChanServ changes topic to "the gate is backed up due to broken nodepool images, fix in progress (eta 22:00 utc)"20:25
*** nati_ueno has joined #openstack-meeting-320:25
*** TravT has joined #openstack-meeting-320:30
*** lblanchard has quit IRC20:30
*** lblanchard has joined #openstack-meeting-320:32
*** rand738 has quit IRC20:33
*** rkukura has left #openstack-meeting-320:39
*** jcoufal has quit IRC20:42
*** overlayer has joined #openstack-meeting-320:42
*** eghobo has quit IRC20:46
*** jcoufal has joined #openstack-meeting-320:52
*** jcoufal has quit IRC20:53
*** eghobo has joined #openstack-meeting-320:54
*** eghobo has quit IRC20:54
*** eghobo has joined #openstack-meeting-320:54
*** mrunge has quit IRC21:04
*** markmcclain has quit IRC21:12
*** yamahata has quit IRC21:37
*** yamahata has joined #openstack-meeting-321:40
*** banix has quit IRC22:12
*** lblanchard has quit IRC22:13
*** nati_ueno has quit IRC22:15
*** overlayer has quit IRC22:16
*** Tufin has joined #openstack-meeting-322:21
*** Tufin has quit IRC22:25
*** ttrifonov_zZzz is now known as ttrifonov22:26
*** nati_ueno has joined #openstack-meeting-322:28
*** mfer has quit IRC22:29
*** ttrifonov is now known as ttrifonov_zZzz22:39
*** otherwiseguy has quit IRC22:40
*** nati_ueno has quit IRC22:43
*** nati_ueno has joined #openstack-meeting-322:45
*** eguz has joined #openstack-meeting-322:48
*** eghobo has quit IRC22:52
*** david-lyle has quit IRC22:58
*** david-lyle has joined #openstack-meeting-322:58
*** david-lyle has quit IRC22:58
*** jamielennox|away is now known as jamielennox23:01
*** s3wong has left #openstack-meeting-323:05
*** rand738 has joined #openstack-meeting-323:41
*** banix has joined #openstack-meeting-323:45
*** SumitNaiksatam has joined #openstack-meeting-323:45
*** nati_ueno has quit IRC23:48
*** nati_ueno has joined #openstack-meeting-323:48
*** nati_ueno has quit IRC23:54

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