| *** markmcclain1 has joined #openstack-meeting-3 | 00:09 | |
| *** markmcclain1 has quit IRC | 00:09 | |
| *** markmcclain1 has joined #openstack-meeting-3 | 00:09 | |
| *** markmcclain has quit IRC | 00:12 | |
| *** Sukhdev has quit IRC | 00:20 | |
| *** markmcclain1 has quit IRC | 00:23 | |
| *** banix has joined #openstack-meeting-3 | 00:24 | |
| *** Hao has joined #openstack-meeting-3 | 00:25 | |
| *** Hao has quit IRC | 00:29 | |
| *** dansmith has quit IRC | 00:48 | |
| *** dansmith has joined #openstack-meeting-3 | 00:49 | |
| *** banix has quit IRC | 00:49 | |
| *** wchrisj has quit IRC | 00:50 | |
| *** SumitNaiksatam has quit IRC | 00:53 | |
| *** yamahata has quit IRC | 00:54 | |
| *** SumitNaiksatam has joined #openstack-meeting-3 | 00:57 | |
| *** wchrisj has joined #openstack-meeting-3 | 01:09 | |
| *** SumitNaiksatam has quit IRC | 01:15 | |
| *** wchrisj has quit IRC | 01:20 | |
| *** banix has joined #openstack-meeting-3 | 01:22 | |
| *** eghobo has quit IRC | 01:28 | |
| *** Hao has joined #openstack-meeting-3 | 02:07 | |
| *** mwagner_lap has quit IRC | 02:10 | |
| *** Hao has quit IRC | 02:11 | |
| *** yamahata has joined #openstack-meeting-3 | 02:22 | |
| *** julim has quit IRC | 02:26 | |
| *** coolsvap has joined #openstack-meeting-3 | 02:33 | |
| *** banix has quit IRC | 02:39 | |
| *** Hao has joined #openstack-meeting-3 | 02:50 | |
| *** Hao has quit IRC | 02:52 | |
| *** banix has joined #openstack-meeting-3 | 03:00 | |
| *** coolsvap has quit IRC | 03:12 | |
| *** cjellick has quit IRC | 03:13 | |
| *** david-lyle has joined #openstack-meeting-3 | 03:18 | |
| *** eghobo has joined #openstack-meeting-3 | 03:19 | |
| *** cody-somerville has joined #openstack-meeting-3 | 03:19 | |
| *** coolsvap1 has joined #openstack-meeting-3 | 03:27 | |
| *** coolsvap1 has quit IRC | 03:27 | |
| *** coolsvap has joined #openstack-meeting-3 | 03:28 | |
| *** yamahata has quit IRC | 03:35 | |
| *** banix has quit IRC | 03:37 | |
| *** lcheng has quit IRC | 04:27 | |
| *** SumitNaiksatam has joined #openstack-meeting-3 | 04:30 | |
| *** wchrisj has joined #openstack-meeting-3 | 04:37 | |
| *** mwagner_lap has joined #openstack-meeting-3 | 04:39 | |
| *** cody-somerville has quit IRC | 04:44 | |
| *** wchrisj has quit IRC | 04:52 | |
| *** HenryG has quit IRC | 04:59 | |
| *** mrunge has joined #openstack-meeting-3 | 05:26 | |
| *** yamahata has joined #openstack-meeting-3 | 06:17 | |
| *** yamahata__ has joined #openstack-meeting-3 | 06:18 | |
| *** yamahata has quit IRC | 06:20 | |
| *** eghobo has quit IRC | 06:22 | |
| *** jamielennox is now known as jamielennox|away | 06:35 | |
| *** ttrifonov_zZzz is now known as ttrifonov | 06:55 | |
| *** jtomasek has joined #openstack-meeting-3 | 07:02 | |
| *** yamahata__ has quit IRC | 07:03 | |
| *** jcoufal has joined #openstack-meeting-3 | 07:08 | |
| *** mrunge has quit IRC | 07:19 | |
| *** mrunge has joined #openstack-meeting-3 | 07:23 | |
| *** coolsvap is now known as coolsvap_away | 07:30 | |
| *** coolsvap_away is now known as coolsvap | 07:41 | |
| *** safchain has joined #openstack-meeting-3 | 08:04 | |
| *** nacim has joined #openstack-meeting-3 | 08:06 | |
| *** d0ugal has quit IRC | 08:18 | |
| *** gdebreczeni has quit IRC | 08:20 | |
| *** d0ugal has joined #openstack-meeting-3 | 08:21 | |
| *** d0ugal has quit IRC | 08:21 | |
| *** d0ugal has joined #openstack-meeting-3 | 08:21 | |
| *** ttrifonov has quit IRC | 08:22 | |
| *** ttrifonov_zZzz has joined #openstack-meeting-3 | 08:31 | |
| *** lpetrut has joined #openstack-meeting-3 | 08:35 | |
| *** ttrifonov_zZzz is now known as ttrifonov | 08:47 | |
| *** yamahata has joined #openstack-meeting-3 | 08:47 | |
| *** lpetrut has quit IRC | 08:50 | |
| *** coolsvap is now known as coolsvap|afk | 08:52 | |
| *** coolsvap|afk is now known as coolsvap | 09:05 | |
| *** overlayer has joined #openstack-meeting-3 | 09:09 | |
| *** lpetrut has joined #openstack-meeting-3 | 09:12 | |
| *** david-lyle has quit IRC | 09:20 | |
| *** lpetrut has quit IRC | 09:31 | |
| *** samchoi has joined #openstack-meeting-3 | 10:25 | |
| *** samchoi_ has joined #openstack-meeting-3 | 10:26 | |
| *** samchoi has quit IRC | 10:26 | |
| *** alexpilotti has joined #openstack-meeting-3 | 10:29 | |
| *** coolsvap is now known as coolsvap|afk | 10:38 | |
| *** HenryG has joined #openstack-meeting-3 | 11:07 | |
| *** julim has joined #openstack-meeting-3 | 11:28 | |
| *** jamielennox|away is now known as jamielennox | 11:30 | |
| *** jamielennox is now known as jamielennox|away | 11:33 | |
| *** coolsvap|afk is now known as coolsvap | 11:57 | |
| *** samchoi_ has quit IRC | 12:00 | |
| *** d0ugal_ has joined #openstack-meeting-3 | 12:04 | |
| *** d0ugal has quit IRC | 12:07 | |
| *** lblanchard has joined #openstack-meeting-3 | 12:12 | |
| *** d0ugal_ is now known as d0ugal | 12:23 | |
| *** lenrow has joined #openstack-meeting-3 | 12:28 | |
| *** lenrow_ has quit IRC | 12:31 | |
| *** nacim has quit IRC | 12:37 | |
| *** wchrisj has joined #openstack-meeting-3 | 12:44 | |
| *** mrunge has quit IRC | 12:44 | |
| *** cody-somerville has joined #openstack-meeting-3 | 12:45 | |
| *** cody-somerville has quit IRC | 12:52 | |
| *** MaxV has joined #openstack-meeting-3 | 12:56 | |
| *** nacim has joined #openstack-meeting-3 | 12:57 | |
| *** mwagner_lap has quit IRC | 13:06 | |
| *** tedchang has joined #openstack-meeting-3 | 13:15 | |
| *** coolsvap is now known as coolsvap|afk | 13:18 | |
| *** coolsvap|afk is now known as coolsvap | 13:20 | |
| *** coolsvap is now known as coolsvap|afk | 13:22 | |
| *** Hao has joined #openstack-meeting-3 | 13:22 | |
| *** gdebreczeni has joined #openstack-meeting-3 | 13:40 | |
| *** julim is now known as julim_WFH | 13:43 | |
| *** gdebreczeni_ has joined #openstack-meeting-3 | 13:44 | |
| *** gdebreczeni has quit IRC | 13:44 | |
| *** xuhanp has joined #openstack-meeting-3 | 13:49 | |
| *** yamahata has quit IRC | 13:53 | |
| *** jcoufal has quit IRC | 13:59 | |
| *** jcoufal has joined #openstack-meeting-3 | 14:00 | |
| *** pballand has joined #openstack-meeting-3 | 14:17 | |
| *** pballand has quit IRC | 14:24 | |
| *** saju_m has joined #openstack-meeting-3 | 14:26 | |
| *** mwagner_lap has joined #openstack-meeting-3 | 14:27 | |
| *** yamahata has joined #openstack-meeting-3 | 14:37 | |
| *** TravT has quit IRC | 14:46 | |
| *** coolsvap|afk is now known as coolsvap | 14:48 | |
| *** david-lyle has joined #openstack-meeting-3 | 14:55 | |
| *** saju_m has quit IRC | 14:58 | |
| *** mfer has joined #openstack-meeting-3 | 15:03 | |
| *** banix has joined #openstack-meeting-3 | 15:05 | |
| *** tedchang has quit IRC | 15:10 | |
| *** gdebreczeni_ has quit IRC | 15:17 | |
| *** alexpilotti has quit IRC | 15:20 | |
| *** alexpilotti has joined #openstack-meeting-3 | 15:20 | |
| *** jamie_h has joined #openstack-meeting-3 | 15:21 | |
| *** nacim has quit IRC | 15:23 | |
| *** lenrow has quit IRC | 15:24 | |
| *** samchoi has joined #openstack-meeting-3 | 15:24 | |
| *** MaxV has quit IRC | 15:25 | |
| *** ycombinator has joined #openstack-meeting-3 | 15:26 | |
| *** MaxV has joined #openstack-meeting-3 | 15:28 | |
| *** dolphm has quit IRC | 15:29 | |
| *** dolphm has joined #openstack-meeting-3 | 15:30 | |
| *** overlayer has quit IRC | 15:30 | |
| mfer | #startmeeting openstack-sdk-php | 15:30 |
|---|---|---|
| openstack | Meeting started Wed Apr 9 15:30:23 2014 UTC and is due to finish in 60 minutes. The chair is mfer. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:30 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:30 |
| *** openstack changes topic to " (Meeting topic: openstack-sdk-php)" | 15:30 | |
| openstack | The meeting name has been set to 'openstack_sdk_php' | 15:30 |
| jamie_h | hey folks | 15:30 |
| mfer | Hi folks | 15:30 |
| samchoi | hello all | 15:30 |
| ycombinator | hi everyone | 15:30 |
| mfer | For the first item, can everyone state your name along with an affiliation if there is one. | 15:31 |
| mfer | Matt Farina, HP | 15:31 |
| samchoi | Sam Choi, HP | 15:31 |
| glenc | Glen Campbell, Rackspace | 15:31 |
| ycombinator | Shaunak Kashyap, Rackspace | 15:31 |
| jamie_h | Jamie Hannaford, Rackspace | 15:31 |
| *** nacim has joined #openstack-meeting-3 | 15:32 | |
| *** wchrisj has left #openstack-meeting-3 | 15:32 | |
| mfer | #topic Agenda Items | 15:32 |
| *** openstack changes topic to "Agenda Items (Meeting topic: openstack-sdk-php)" | 15:32 | |
| mfer | #link https://wiki.openstack.org/wiki/Meetings/OpenStack-SDK-PHP | 15:32 |
| mfer | I wasn't sure who else would come. The first two items an introduction to what this project is and what's in an SDK. | 15:33 |
| glenc | Do we have a definition of "SDK" (beyond just PHP)? | 15:34 |
| mfer | glenc yes. https://wiki.openstack.org/wiki/SDK-Development | 15:34 |
| ycombinator | glenc: item #2 on the agenda links to https://wiki.openstack.org/wiki/SDK-Development | 15:34 |
| glenc | Yeah, found it | 15:34 |
| mfer | The first item was meant to be an introduction to the PHP SDK and what it's for. | 15:35 |
| mfer | #topic What is the OpenStack SDK for PHP? | 15:35 |
| *** openstack changes topic to "What is the OpenStack SDK for PHP? (Meeting topic: openstack-sdk-php)" | 15:35 | |
| mfer | #link https://wiki.openstack.org/wiki/OpenStack-SDK-PHP | 15:35 |
| jamie_h | I generally agree with the definition on https://wiki.openstack.org/wiki/SDK-Development, except that "system" is slightly unclear. I'd replace with "any remote OpenStack system" | 15:36 |
| mfer | The goal of the PHP SDK is to have a language binding, documentation, and examples for PHP application developers to talk to OpenStack endpoints. they don't need to know how OpenStack works. | 15:36 |
| jamie_h | and also tests, which guarantee API behaviour and allow users to understand how to interact with it | 15:37 |
| mfer | I put this item on here for anyone not familiar with the concept | 15:37 |
| *** ttrifonov is now known as ttrifonov_zZzz | 15:37 | |
| mfer | since we've already talked about this, do we need to talk more about the point of a PHP SDK or can we move on to SDKs in general? | 15:37 |
| ycombinator | mfer: looking at the short term roadmap items on https://wiki.openstack.org/wiki/OpenStack-SDK-PHP, should we say something about the specific services we'll aim to implement in the short term? | 15:37 |
| mfer | ycombinator that's agenda item 3. we'll get there | 15:38 |
| jamie_h | mfer My definition was for general SDKs | 15:38 |
| jamie_h | but I'm happy to move on | 15:38 |
| ycombinator | right, thanks | 15:38 |
| ycombinator | in that case, move on | 15:38 |
| samchoi | agreed | 15:38 |
| mfer | #topic What's in an SDK? | 15:38 |
| *** openstack changes topic to "What's in an SDK? (Meeting topic: openstack-sdk-php)" | 15:38 | |
| mfer | #link https://wiki.openstack.org/wiki/SDK-Development | 15:39 |
| mfer | The section on "What's in an SDK?" was originally written by Jesse at Rackspace | 15:39 |
| jamie_h | source code which provides a convenient API for interacting with OpenStack services; tests which guarantee behaviour; feature specs; documentation which explains in simple terms how to interact with the SDK; code samples | 15:40 |
| mfer | The system is meat to talk about an OpenStack installation somewhere. The SDK interacts with it but is not part of it. | 15:40 |
| jamie_h | Does anybody disagree with any of my points? | 15:41 |
| mfer | this is a general description for all SDKs. Changing this shouldn't happen without engaging some of the other teams. | 15:41 |
| mfer | what do you mean by tests which guarantee behavior? | 15:41 |
| mfer | jamie_h ^^ | 15:42 |
| jamie_h | the purpose of a test is to guarantee that a class behaves in a certain way. It also serves as a working code sample for users | 15:42 |
| mfer | i'm curious how you relate that to openstack api endpoints. | 15:43 |
| jamie_h | i'm relating it to source code | 15:43 |
| jamie_h | perhaps it should be changed to: "tests which guarantee the behaviour of elements in the SDK" | 15:44 |
| mfer | you used the phrase "which guarantee behaviour". How do you see that as differing from other types of tests? | 15:44 |
| jamie_h | because the scope is different. a unit test or spec test will guarantee internal threads of behaviour. acceptance tests verifies the API of the SDK. integration tests verifies our SDK successfully maps to remote endpoints | 15:45 |
| jamie_h | i kept it general because we don't need to go into too much detail for this top-level definition of what a SDK is | 15:46 |
| ycombinator | jamie_h: are you proposing adding tests to this list: https://wiki.openstack.org/wiki/SDK-Development#Goals_for_each_SDK? | 15:46 |
| jamie_h | ycombinator i can do that as an action item if that's okay with everyone? | 15:47 |
| ycombinator | well - as mfer said, that page is shared | 15:47 |
| ycombinator | so we should probably make sure its okay with other SDK owners as well | 15:47 |
| jamie_h | i want to make sure what i'm writing aligns with everyone else's opinions | 15:47 |
| mfer | jamie_h this is for the SDK Development in general. it touches the python sdk, Go sdk, .NET sdk, and others. | 15:48 |
| mfer | as ycombinator noted, any changes in scope to that should go through them as well | 15:48 |
| ycombinator | mfer jamie_h: in the interest of time, should we take an action item to check with other SDK owners about adding tests? | 15:49 |
| *** markmcclain has joined #openstack-meeting-3 | 15:49 | |
| jamie_h | mfer ycombinator sure, i can do that | 15:49 |
| samchoi | agree with ycombinator | 15:49 |
| mfer | who wants to own that? | 15:50 |
| mfer | ah | 15:50 |
| *** Zhou_Yu has joined #openstack-meeting-3 | 15:50 | |
| mfer | #action jamie_h Connect with SDK owners about testing. | 15:50 |
| * ycombinator is excited about using meeting bot's features | 15:50 | |
| *** cjellick has joined #openstack-meeting-3 | 15:50 | |
| mfer | are there any other elements of the SDK Development page we should discuss? | 15:51 |
| ycombinator | okay, I'm good with the SDK definition otherwise | 15:51 |
| jamie_h | me too | 15:51 |
| mfer | #topic Near term roadmap | 15:52 |
| *** openstack changes topic to "Near term roadmap (Meeting topic: openstack-sdk-php)" | 15:52 | |
| mfer | #link https://wiki.openstack.org/wiki/OpenStack-SDK-PHP#Short_Term_Roadmap | 15:52 |
| *** eghobo has joined #openstack-meeting-3 | 15:52 | |
| mfer | ycombinator you asked earlier about specific services. There are currently blueprints for compute and networking. | 15:54 |
| ycombinator | mfer: cool, is that something we ought to make explicit in the roadmap | 15:54 |
| ycombinator | just so users know what's coming | 15:54 |
| mfer | I intentionally kept it at a high level. If someone wants to contribute another service that would be great. | 15:55 |
| jamie_h | I've submitted a bunch of blueprints that deal with core features for the SDK. | 15:55 |
| mfer | I would also put image and block storage on the list to round out elements around compute | 15:55 |
| mfer | jamie_h I saw that. | 15:56 |
| ycombinator | so, to be clear: identity (implicit), compute, networking, image and block storage | 15:56 |
| ycombinator | ... are all part of the short term deliverables | 15:56 |
| ycombinator | ? | 15:56 |
| jamie_h | these are high-level features, right? Would core components (like Guzzle, json-schema) get included in this list? | 15:57 |
| mfer | ycombinator I would say the short term deliverables are to round out the architecture changes and then to add services. the short term is to change the architecture. adding servcies is both short and mid term | 15:57 |
| jamie_h | +1 | 15:57 |
| ycombinator | okay, cool; then short term roadmap looks good to me as-is | 15:58 |
| *** Zhou_Yu has quit IRC | 15:58 | |
| jamie_h | most of these short-term architectural changes are in separate blueprints | 15:58 |
| glenc | is there a blueprint for the "support multiple service API versions" | 15:58 |
| *** Zhou_Yu has joined #openstack-meeting-3 | 15:58 | |
| glenc | ? | 15:58 |
| ycombinator | glenc: https://blueprints.launchpad.net/openstack-sdk-php/+spec/multiple-api-versions | 15:58 |
| mfer | so, the second short term item is to move to HTTP Messages from FIG, Guzzle as the default transport layer, and make it pluggable. That is up for review at https://review.openstack.org/#/c/86137/ | 15:58 |
| glenc | we should probably link to those when possible | 15:59 |
| *** Sukhdev has joined #openstack-meeting-3 | 15:59 | |
| mfer | glenc I was going to work on the support for multiple api versions first but Jamie had a great suggestion to deal with Guzzle so I did that first | 15:59 |
| jamie_h | mfer I started a blueprint which invited discussion about what we mean by pluggable. I think we should move that discussion to the Wiki | 15:59 |
| jamie_h | https://blueprints.launchpad.net/openstack-sdk-php/+spec/transport-client-flexibility | 16:00 |
| ycombinator | mfer I'd like to take an action item to link short term roadmap to blueprints | 16:00 |
| mfer | i see you added that. for reference take a look at https://review.openstack.org/#/c/86137/1/src/OpenStack/Transport/ClientInterface.php | 16:00 |
| mfer | ycombinator I'll do that | 16:00 |
| ycombinator | thanks | 16:01 |
| mfer | #action mfer link the short term roadmap to blueprints. | 16:01 |
| glenc | heh I just did the first one :) | 16:01 |
| jamie_h | mfer I think the interface looks promising. By pluggable, do you mean the ability for the entire client to be swappable? (So a user can define their own) | 16:02 |
| mfer | yes | 16:02 |
| jamie_h | If so, is there a real use-case for that? | 16:02 |
| mfer | but Guzzle is the fall back/default | 16:02 |
| jamie_h | Connection adapters offer as much flexibility | 16:02 |
| mfer | They are flexible. and the Guzzle implementation lets you inject a Guzzle client you've altered as needed | 16:03 |
| mfer | but, there are cases where you'd want to do something entirely different. we've run into two use cases for that. | 16:04 |
| jamie_h | okay, so we could add the ability where a service (like SwiftClient) could redefine its HTTP client? | 16:04 |
| jamie_h | setHttpClient(HttpClientInterface $client) | 16:05 |
| jamie_h | and the service effectively wraps it | 16:05 |
| glenc | yes, a dependency injection to override | 16:05 |
| mfer | soft of. it's dependency injection rather than extending. so, the clients/managers for servcies are loosly coupled to the http client | 16:06 |
| jamie_h | okay, i think that's a great idea | 16:06 |
| mfer | but, Guzzle is the fall back default | 16:06 |
| mfer | in the interest of time, is there something else on the roadmap to talk about? | 16:07 |
| mfer | i'm happy to talk about transport layer elements. we can carry those into #openstack-sdks too | 16:07 |
| glenc | is there any proposal for how to handle vendor extensions yet? | 16:07 |
| jamie_h | i've added a blueprint for it | 16:07 |
| mfer | yes. it's been discussed in the past | 16:07 |
| mfer | both in the low level and for the service discovery parts. | 16:08 |
| glenc | ok, sorry | 16:08 |
| jamie_h | details are vague at the moment because it's not a top level priority right now, as i understand it | 16:08 |
| mfer | i've even discussed those with some of the other SDK groups. | 16:08 |
| mfer | when I update the short term plan I'll add lots of details to the blueprints | 16:08 |
| *** pballand has joined #openstack-meeting-3 | 16:09 | |
| mfer | something else worth noting from an implementation standpoint is the user facing docs. we'd wanted that to be an all in one getting going guide | 16:10 |
| mfer | the idea is that application developers don't know openstack and should learn what they need there. | 16:10 |
| mfer | we'd talked about doing it consistently with rst/sphinx | 16:10 |
| mfer | That might even have been Jessies idea | 16:11 |
| jamie_h | i agree that having a good "getting started" guide is essential | 16:11 |
| glenc | yes, we've discussed with anne gentle as well | 16:11 |
| glenc | specifically about making the technology as easy as possible for devleopers to contribute | 16:11 |
| glenc | s/devleopers/developers/ | 16:11 |
| mfer | i'm actually not sure RST is the easiest method for developers. Far more developers are familiar with markdown than RST. | 16:12 |
| mfer | but, RST/Sphinx is what openstack uses and it's increasing in use. | 16:12 |
| mfer | it's also richer to describe these types of things | 16:12 |
| ycombinator | I'm happy to take a stab at the user-facing docs using rst/sphinx | 16:12 |
| ycombinator | I see the bp for it | 16:12 |
| mfer | ycombinator in the order of things i put it a little later because any code might change due to architecture stuff. but, if you want to start it sooner that would be great | 16:13 |
| mfer | there is already a doc directory with a bunch of material to be reworked into the new format or thrown out | 16:13 |
| ycombinator | yeah, totally, makes sense to let the code "settle" a bit | 16:13 |
| ycombinator | but I'll start playing with sphinx/rst | 16:13 |
| mfer | other projects like the python-openstackclient already have a setup in a subdirectory. might be worth looking at those setups as well | 16:14 |
| ycombinator | will do | 16:14 |
| mfer | if you have questions feel free to ask. I've worked with these before. | 16:15 |
| glenc | fwiw, most other OpenStack docs are in a separate repo from the code | 16:15 |
| glenc | not sure I like that model personally | 16:15 |
| *** lsmola has quit IRC | 16:15 | |
| glenc | I'd rather see docs committed alongside code | 16:15 |
| *** tedchang has joined #openstack-meeting-3 | 16:15 | |
| glenc | we can always move to that in the future if that's what OpenStack wants | 16:16 |
| ycombinator | okay, sounds good to me | 16:16 |
| mfer | glenc the scope and setup is interesting. for many projects there is end user docs for a service as a separate repo. then there's different internal docs. for example see https://github.com/openstack/nova/tree/master/doc and https://github.com/openstack/api-site | 16:16 |
| *** tjones has joined #openstack-meeting-3 | 16:16 | |
| glenc | yup | 16:17 |
| mfer | we'd discussed that we want the docs to be internal and easy to use/follow. so you can generate a site or you can just read it and use it as part of the sdk | 16:17 |
| ycombinator | +1 to getting the docs as part of the SDK codebase | 16:17 |
| mfer | the goal is end user application developers. give them one package that just gives them what they need to know | 16:17 |
| ycombinator | yup | 16:17 |
| ycombinator | okay, so I think we are all in agreement here: subdir in same repo as code | 16:18 |
| mfer | i think so | 16:18 |
| samchoi | yes, that certainly seems sensible | 16:18 |
| glenc | +1 | 16:18 |
| jamie_h | +1 | 16:18 |
| mfer | I'm glad everyone is in agreement. that's the direction we'd been taking here and on other SDKs. | 16:19 |
| mfer | if there's not other discussion on the near term goals, shall we move onto the bugs/reviews? | 16:19 |
| ycombinator | mfer: possibly | 16:19 |
| mfer | ycombinator is there something else? | 16:19 |
| ycombinator | is now a good time to talk repo initial state (i.e. as part of short term goals), or do you want to save that for open discussion? | 16:19 |
| mfer | i was thinking open discussion | 16:20 |
| ycombinator | okay, cool; lets keep moving | 16:20 |
| mfer | #topic Bugs / Reviews | 16:20 |
| *** openstack changes topic to "Bugs / Reviews (Meeting topic: openstack-sdk-php)" | 16:20 | |
| mfer | #link https://review.openstack.org/#/q/status:open+project:stackforge/openstack-sdk-php,n,z | 16:20 |
| mfer | #link https://bugs.launchpad.net/openstack-sdk-php | 16:21 |
| mfer | The one item out for review actually fixes bug #1277535 | 16:21 |
| mfer | the other two bugs are linked and something I'm working this week. | 16:21 |
| mfer | did anyone want to discuss them? | 16:21 |
| mfer | silence. i'll take that as no discussion. | 16:23 |
| jamie_h | i haven't spent much time on these patches because the repo issue was under discussion | 16:24 |
| jamie_h | i have nothing to add | 16:24 |
| ycombinator | to be honest, I feel like reviews are closely related to the initial repo state discussion so... | 16:24 |
| mfer | #topic Open Discussion | 16:24 |
| *** openstack changes topic to "Open Discussion (Meeting topic: openstack-sdk-php)" | 16:24 | |
| mfer | It seems the repo state discussion is the one on your minds | 16:25 |
| mfer | Here is where I'm at... | 16:25 |
| ycombinator | yeah, its pretty fundamental to any actual changes | 16:25 |
| *** xuhanp has quit IRC | 16:26 | |
| *** pballand has quit IRC | 16:26 | |
| mfer | We have an SDK that we contributed to stackforge and altered to be OpenStack rather than HP Cloud. We have a larder codebase than we released because we went all in on OpenStack rather than continuing to drive our own. We wanted to make the needed changes for OpenStack before we added service.... | 16:26 |
| mfer | For example, there are things like multiple api version support that needed to happen. | 16:27 |
| mfer | I'm sorry if there was confusion. I'd stated some months ago that we were planning to start with this codebase and alter it as needed. | 16:28 |
| samchoi | larger codebase that was *not released, meaning our internal PHP SDK right? | 16:28 |
| samchoi | to avoid confusion | 16:29 |
| mfer | This is the SDK we're going all in on for PHP. Our HP one is only in major bugfix mode. | 16:29 |
| ycombinator | mfer: likewise | 16:29 |
| ycombinator | from a general contributor perspective, wouldn't it be easier to start from an empty repo, though? | 16:29 |
| mfer | samchoi yes. the lager codebase is the internal one you've done a great job with. | 16:29 |
| jamie_h | yes. no legacy decisions, cleaner code, and it allows members to be included from the very beginning | 16:30 |
| mfer | i'm curious to know why? many folks prefer to join into an architecture that's already there so add to it or work on needed tasks. | 16:30 |
| tjones | you guys almost done? we have another meeting starting now. sorry to push you out | 16:30 |
| *** melwitt has joined #openstack-meeting-3 | 16:31 | |
| ycombinator | lets continue in openstack-sdks? | 16:31 |
| tjones | thanks | 16:31 |
| jamie_h | yeah okay | 16:31 |
| samchoi | that's fine | 16:31 |
| mfer | tjones thanks | 16:31 |
| mfer | #endmeeting | 16:31 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 16:31 | |
| openstack | Meeting ended Wed Apr 9 16:31:25 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:31 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_sdk_php/2014/openstack_sdk_php.2014-04-09-15.30.html | 16:31 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_sdk_php/2014/openstack_sdk_php.2014-04-09-15.30.txt | 16:31 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/openstack_sdk_php/2014/openstack_sdk_php.2014-04-09-15.30.log.html | 16:31 |
| tjones | #startmeeting NovaBugScrub | 16:31 |
| openstack | Meeting started Wed Apr 9 16:31:36 2014 UTC and is due to finish in 60 minutes. The chair is tjones. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:31 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:31 |
| *** openstack changes topic to " (Meeting topic: NovaBugScrub)" | 16:31 | |
| openstack | The meeting name has been set to 'novabugscrub' | 16:31 |
| tjones | hi folks - who's here today? | 16:31 |
| melwitt | o/ | 16:32 |
| tjones | hey melwitt | 16:32 |
| tjones | lets go ahead and hopefully others will join. we have a short queue to tag today and then i'd like to talk about how we should change this meeting now that we are done with icehouse (pretty much) | 16:33 |
| tjones | so first tagging | 16:33 |
| melwitt | okay | 16:33 |
| tjones | #topic tagging | 16:33 |
| *** openstack changes topic to "tagging (Meeting topic: NovaBugScrub)" | 16:33 | |
| tjones | #link https://bugs.launchpad.net/nova/+bugs?field.tag=-*&field.status%3Alist=NEW | 16:33 |
| tjones | #link https://bugs.launchpad.net/nova/+bug/1303802 | 16:33 |
| tjones | libvirt? | 16:34 |
| tjones | or?? | 16:34 |
| melwitt | it's a virt thing so I'd guess libvirt | 16:34 |
| tjones | lol | 16:35 |
| tjones | #link https://bugs.launchpad.net/nova/+bug/1301626 | 16:35 |
| *** garyk has joined #openstack-meeting-3 | 16:35 | |
| tjones | no idea | 16:35 |
| *** pballand has joined #openstack-meeting-3 | 16:35 | |
| *** yamahata has quit IRC | 16:36 | |
| tjones | clues? | 16:36 |
| garyk | hi | 16:36 |
| tjones | hi garyk | 16:36 |
| tjones | we are tagging bugs - currently on https://bugs.launchpad.net/nova/+bug/1301626 | 16:37 |
| tjones | db?? just cause it's something you'd put in the db? | 16:37 |
| garyk | i would say api | 16:37 |
| melwitt | me too | 16:38 |
| tjones | great. this one i think api too #link https://bugs.launchpad.net/nova/+bug/1301824 | 16:38 |
| garyk | agreed | 16:39 |
| tjones | #link https://bugs.launchpad.net/nova/+bug/1304183 | 16:39 |
| tjones | not sure | 16:39 |
| tjones | guessing compute | 16:39 |
| garyk | yup. | 16:40 |
| melwitt | yes | 16:40 |
| tjones | #link https://bugs.launchpad.net/nova/+bug/1304790 | 16:40 |
| tjones | last one | 16:40 |
| tjones | no clue | 16:40 |
| melwitt | api I think | 16:41 |
| tjones | SOOO much info in that bug | 16:41 |
| melwitt | haha yeah | 16:41 |
| garyk | that is api = i think | 16:41 |
| tjones | ok done with this | 16:41 |
| tjones | #topic open discussion | 16:41 |
| *** openstack changes topic to "open discussion (Meeting topic: NovaBugScrub)" | 16:41 | |
| *** Zhou_Yu has quit IRC | 16:41 | |
| tjones | so obvioulsy this meeting is for tagging but what else should we be looking at in this phase of the project? i have some ideas about closing old bugs, and removing owners that are not working on bugs so others can do it. what do you guys think? | 16:42 |
| garyk | are there any bugs that need to be addressed for icehouse rc? | 16:42 |
| tjones | looking | 16:42 |
| tjones | #topic icehouse rc bugs | 16:43 |
| *** openstack changes topic to "icehouse rc bugs (Meeting topic: NovaBugScrub)" | 16:43 | |
| tjones | #link https://bugs.launchpad.net/bugs/1290537 | 16:43 |
| garyk | if so it may be useful to chase down poeple assignedto them | 16:43 |
| tjones | this is the last one for rc 2 | 16:43 |
| tjones | lots of action on it | 16:44 |
| garyk | ok, tx | 16:44 |
| tjones | im thinking icehouse is done from our point of view now. any bug that comes up russellb will be hounding them :-) | 16:45 |
| tjones | anything else for icehouse? | 16:45 |
| garyk | tjones: i think that you should get added to the security group (that is, if there are bugs like this then you will be in the loop from the start) | 16:45 |
| tjones | garyk: good idea. i'll ask ttx | 16:45 |
| garyk | i think that russellb can add you | 16:45 |
| tjones | ok | 16:45 |
| tjones | so back to open discussion? | 16:45 |
| garyk | if not certainly ttx | 16:45 |
| tjones | #topic open discussion | 16:46 |
| *** openstack changes topic to "open discussion (Meeting topic: NovaBugScrub)" | 16:46 | |
| tjones | i have a hard stop at 10 - but did want to get your views on this | 16:46 |
| garyk | i need to run. i'll catch you gys later | 16:47 |
| tjones | this = what else we should focus on for this meeting | 16:47 |
| tjones | c ya garyk | 16:47 |
| *** yamahata has joined #openstack-meeting-3 | 16:48 | |
| *** overlayer has joined #openstack-meeting-3 | 16:48 | |
| melwitt | I also think it's important to find the old bugs that have someone assigned to unassign but I think it could be done with a search or tool for finding bugs > some age that have someone assigned but no patch proposed yet | 16:48 |
| tjones | yes i currently have a script that dumps bugs and their ages and then i import into excel to look at it. i haven't done anything but look at it so far | 16:49 |
| melwitt | usually In Progress tells if something has been proposed but some people wrongly set it to In Progress manually and it doesn't necessarily mean there's been movement on it | 16:50 |
| garyk | tjones: it may be a good idea to send to the mail list a heads up that we will remove assignees from bugs. give them a day or 2 to respond | 16:50 |
| *** overlayer has quit IRC | 16:50 | |
| tjones | yeah it would be nice to have better integration tools between launchpad and gerrit | 16:50 |
| *** pballand has quit IRC | 16:51 | |
| tjones | gerrit also doens't always update the bug with the review which makes it tricky | 16:51 |
| tjones | there are also bugs which are tagged but not with an "offical" tag - so they are more likley to be ignored | 16:52 |
| melwitt | yeah, if the developer doesn't flag it with the right syntax (or whatever) it won't | 16:52 |
| melwitt | I've seen that too, the "unofficial" tags | 16:52 |
| tjones | ok so 3 things - tagging, stale bugs, and badly tagged bugs | 16:53 |
| tjones | russellb: wants to disallow unoffical bugs but not sure if you can do that just for nova | 16:53 |
| tjones | s/bugs/tags | 16:53 |
| tjones | #action tjones figure out how to track stale and badly tagged bugs in this meeting | 16:54 |
| tjones | anything else melwitt, garyk? | 16:54 |
| melwitt | I don't have anything else | 16:55 |
| tjones | ok me either | 16:55 |
| *** MaxV has quit IRC | 16:55 | |
| tjones | thanks for joining. "see" you next week | 16:55 |
| tjones | #endmeeting | 16:55 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 16:55 | |
| openstack | Meeting ended Wed Apr 9 16:55:23 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:55 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/novabugscrub/2014/novabugscrub.2014-04-09-16.31.html | 16:55 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/novabugscrub/2014/novabugscrub.2014-04-09-16.31.txt | 16:55 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/novabugscrub/2014/novabugscrub.2014-04-09-16.31.log.html | 16:55 |
| *** Hao has quit IRC | 16:56 | |
| *** melwitt has left #openstack-meeting-3 | 16:56 | |
| *** tjones has left #openstack-meeting-3 | 16:58 | |
| *** nacim has quit IRC | 16:59 | |
| *** rkukura has joined #openstack-meeting-3 | 17:04 | |
| *** SumitNaiksatam has quit IRC | 17:06 | |
| *** garyduan has joined #openstack-meeting-3 | 17:09 | |
| *** coolsvap is now known as coolsvap|afk | 17:18 | |
| *** krotscheck has quit IRC | 17:19 | |
| *** SumitNaiksatam has joined #openstack-meeting-3 | 17:21 | |
| *** Swami has joined #openstack-meeting-3 | 17:22 | |
| *** krotscheck has joined #openstack-meeting-3 | 17:22 | |
| *** mandeep has joined #openstack-meeting-3 | 17:25 | |
| mandeep | SumitNaiksatam: Hi | 17:26 |
| SumitNaiksatam | mandeep: hi | 17:26 |
| rkukura | hi | 17:26 |
| *** pcm has joined #openstack-meeting-3 | 17:28 | |
| *** markmcclain has quit IRC | 17:29 | |
| garyduan | Hi | 17:29 |
| *** overlayer has joined #openstack-meeting-3 | 17:30 | |
| banix | hello | 17:30 |
| *** s3wong has joined #openstack-meeting-3 | 17:30 | |
| SumitNaiksatam | rkukura garyduan banix: Hi | 17:30 |
| cgoncalves | hi | 17:30 |
| SumitNaiksatam | cgoncalves: hi | 17:30 |
| s3wong | Hello | 17:30 |
| banix | hi SumitNaiksatam and the rest of the gang :) | 17:30 |
| overlayer | cgoncalves, boas hello | 17:30 |
| enikanorov | hi | 17:31 |
| SumitNaiksatam | s3wong enikanorov: hi | 17:31 |
| cgoncalves | overlayer: greetings | 17:31 |
| SumitNaiksatam | ok i think we have critical mass lets get started | 17:31 |
| *** kanzhe has joined #openstack-meeting-3 | 17:31 | |
| mandeep | banix: cgoncalves: garyduan: s3wong: hi | 17:31 |
| SumitNaiksatam | #startmeeting Networking Advanced Services | 17:31 |
| openstack | Meeting started Wed Apr 9 17:31:28 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:31 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:31 |
| *** openstack changes topic to " (Meeting topic: Networking Advanced Services)" | 17:31 | |
| openstack | The meeting name has been set to 'networking_advanced_services' | 17:31 |
| SumitNaiksatam | #topic Flavors Framework | 17:31 |
| *** openstack changes topic to "Flavors Framework (Meeting topic: Networking Advanced Services)" | 17:31 | |
| SumitNaiksatam | #link: https://review.openstack.org/#/c/83055/ | 17:31 |
| SumitNaiksatam | also #link https://wiki.openstack.org/wiki/Neutron/FlavorFramework | 17:32 |
| SumitNaiksatam | enikanorov: i think there was some activity on the PoC patch | 17:32 |
| Swami | hi | 17:32 |
| SumitNaiksatam | Swami: hi, thanks for joining | 17:32 |
| enikanorov | SumitNaiksatam: yes, but i think people reviewed it as regular one | 17:32 |
| enikanorov | while i think it make sense to focus on shceduling part of it | 17:32 |
| *** eguz has joined #openstack-meeting-3 | 17:32 | |
| SumitNaiksatam | enikanorov: i know, more on syntax than semantics :-) | 17:32 |
| SumitNaiksatam | enikanorov: yeah the scheduling part was not very clear to me | 17:33 |
| SumitNaiksatam | enikanorov: for the benefit of everyone here, can you quickly walk through the workflow | 17:33 |
| enikanorov | so the idea of scheduling is that it is falling into two parts | 17:33 |
| SumitNaiksatam | enikanorov: if it can be done briefly | 17:33 |
| enikanorov | 1. choose the provider that generally supports all requested capabilities | 17:34 |
| enikanorov | 2. if provider manages some backends - try to chose particular backend | 17:34 |
| *** wchrisj has joined #openstack-meeting-3 | 17:34 | |
| enikanorov | #2 is totally driver-dependent operation, it can be omitted, e.g. scheduling on the driver side can be just empty | 17:34 |
| enikanorov | so, for lbaas #2 could be agent scheduling | 17:34 |
| *** OSM has joined #openstack-meeting-3 | 17:34 | |
| enikanorov | so #1 will chose haproxy provider | 17:35 |
| SumitNaiksatam | enikanorov: the “provider” definition here is per the service type framework? | 17:35 |
| enikanorov | #2 will chose particular lbaas agent | 17:35 |
| enikanorov | SumitNaiksatam: yes | 17:35 |
| *** OSM is now known as songole | 17:35 | |
| enikanorov | provider/driver | 17:35 |
| garyduan | enikanorov: for #2, do you mean to choose different verdor's AGENT driver? | 17:36 |
| enikanorov | if some driver manages hw/sw appliances, then #2 could be scheduling on them | 17:36 |
| enikanorov | garyduan: no, scheduling is done on the plugin-driver side | 17:36 |
| enikanorov | e.g. it chooses plugin-driver first | 17:36 |
| *** eghobo has quit IRC | 17:36 | |
| *** safchain has quit IRC | 17:36 | |
| garyduan | enikanorov: I see. so #2 is to talk to the device | 17:36 |
| enikanorov | not exactly, i'd say | 17:37 |
| enikanorov | driver evaluates available backends and choses matching backend | 17:37 |
| SumitNaiksatam | enikanorov: moreover, the vendor name could be a “tag” value as well? | 17:37 |
| enikanorov | it's not necessary to ommunicate with backends | 17:37 |
| garyduan | enikanorov: understand now | 17:37 |
| enikanorov | SumitNaiksatam: yes, i believe that was one of the unit tests showing such example | 17:37 |
| Swami | enikanorov: What do you mean by backend here. | 17:37 |
| SumitNaiksatam | enikanorov: to provide a hint to the scheduler | 17:37 |
| SumitNaiksatam | enikanorov: ok | 17:38 |
| enikanorov | Swami: backend is an entity actually implementing the service | 17:38 |
| Swami | enikanorov: thanks | 17:38 |
| enikanorov | that's it from my side... | 17:40 |
| garyduan | enikanorov: probably, provider should do the validation to make sure the flavor can be scheduled to the backend | 17:40 |
| enikanorov | garyduan: that's the step #2 | 17:40 |
| enikanorov | it can internally match flavor with capabilities of managed backends | 17:40 |
| enikanorov | and if no backend is found, then scheduler may try to use another provider/driver | 17:41 |
| songole | Is the plugin doing this match? | 17:41 |
| garyduan | enikanorov: yes. that's what I am thinking now | 17:41 |
| enikanorov | songole: basically, yes | 17:43 |
| SumitNaiksatam | enikanorov: the “schedule” method is not defined in any base class in the current patch | 17:43 |
| enikanorov | SumitNaiksatam: it's defined in class SchedulingProvidersPlugin | 17:43 |
| enikanorov | it's in the test_flavors.py | 17:43 |
| banix | can you post the link to the BP if handy | 17:43 |
| SumitNaiksatam | banix: #link https://wiki.openstack.org/wiki/Neutron/FlavorFramework | 17:44 |
| enikanorov | banix: https://blueprints.launchpad.net/neutron/+spec/neutron-flavor-framework | 17:44 |
| banix | thanks | 17:44 |
| songole | enikanorov: thanks. what is the flavor framework doing in the process? | 17:44 |
| enikanorov | yep, and the description is on the wiki | 17:44 |
| enikanorov | songole: what do you mean? | 17:44 |
| enikanorov | SumitNaiksatam: most of the meaningful code is in test_flavors, i intentionally didn't separate it to different files | 17:45 |
| garyduan | enikanorov: does the capability have anything to do with extensions? | 17:45 |
| *** wchrisj has quit IRC | 17:45 | |
| SumitNaiksatam | enikanorov: ok | 17:45 |
| enikanorov | garyduan: flavors are API extension itself | 17:46 |
| SumitNaiksatam | enikanorov: so on the flavors API side | 17:46 |
| songole | API lands on the plugin first. Is there an interface between plugin & flavor? | 17:46 |
| *** cjellick_ has joined #openstack-meeting-3 | 17:47 | |
| *** overlayer has quit IRC | 17:47 | |
| enikanorov | songole: the plugin for the flavors API is FlavorManager, it's a class instance similar to plugins | 17:47 |
| SumitNaiksatam | enikanorov: the API lets you programatically create flavors | 17:47 |
| enikanorov | i think it makes sense to implement it like provider framework | 17:47 |
| enikanorov | SumitNaiksatam: yes | 17:48 |
| *** mwagner_lap has quit IRC | 17:48 | |
| *** cjellic__ has joined #openstack-meeting-3 | 17:48 | |
| SumitNaiksatam | enikanorov: what about the “service types" | 17:48 |
| banix | this may have been mentioned earlier but the provider knows how to schedule the backend? that is the idea behind having a two step approach here? | 17:48 |
| enikanorov | right now patch assumes serviec types are constant | 17:48 |
| enikanorov | LOADBALANCER, FIREWALL, etc | 17:48 |
| *** cjellick_ has quit IRC | 17:49 | |
| songole | enikanorov: ok | 17:49 |
| SumitNaiksatam | enikanorov: ok, that is fine for individual services | 17:49 |
| *** cjellick has quit IRC | 17:50 | |
| SumitNaiksatam | enikanorov: there was a feeling that one should be able to dyncamically create and publish chains as well | 17:50 |
| enikanorov | for combinations/types - i don't know yet. i think there should be API to define such types first | 17:50 |
| Swami | will there be any validation to check if those chains are valid chains before deploying the service. | 17:50 |
| s3wong | enikanorov: in that case, you would need more dynamic flavor - not constants service_type | 17:51 |
| enikanorov | banix: provider/driver may need or need not scheduling at all, that's why it's delegated to the driver | 17:51 |
| enikanorov | s3wong: right, instead of a string, that will be a foreign key to service-types | 17:51 |
| enikanorov | but right now i'm not sure how flexible such construct can be | 17:51 |
| enikanorov | i mean that a chain should have a driver, i don't think it can be arbitratry, can it? | 17:52 |
| s3wong | enikanorov: yes, still undefined today | 17:52 |
| SumitNaiksatam | enikanorov: i think we had this discussion earlier, the feeling is that there could potentially be a generic driver which might be able to handle such cases | 17:52 |
| s3wong | enikanorov: there are two camps on that. We want to have fixed template for chains, or some of us also want to have dynamically defined chains | 17:52 |
| enikanorov | SumitNaiksatam: i don't think it will be a major change even if service types will be dynamic | 17:53 |
| SumitNaiksatam | enikanorov: at this point, if possible, it might be good to not close that possiblity | 17:53 |
| SumitNaiksatam | enikanorov: ok good | 17:53 |
| SumitNaiksatam | any more questions for enikanorov | 17:53 |
| SumitNaiksatam | enikanorov: what is the plan forward | 17:54 |
| *** overlayer_ has joined #openstack-meeting-3 | 17:54 | |
| banix | enikanorov: s3wong does it make sense to have one or more driver of srvice type "chain" that may be able to instantiate certain chains? | 17:54 |
| SumitNaiksatam | enikanorov: when does this come out of WIP? | 17:54 |
| enikanorov | well... I filed a design track for that | 17:54 |
| SumitNaiksatam | banix: i believe that is the current plan | 17:54 |
| enikanorov | on the summit, i mean | 17:54 |
| SumitNaiksatam | enikanorov: so this will be WIP until/after the summit? | 17:54 |
| enikanorov | so i hope to gather more attention of the core team | 17:54 |
| s3wong | banix: yes, I believe that is what SumitNaiksatam said above. Having a driver to render the chain definition | 17:54 |
| banix | enikanorov: shall we work on getting a more detailed design before then? | 17:55 |
| *** cjellick has joined #openstack-meeting-3 | 17:55 | |
| enikanorov | SumitNaiksatam: considering the state of lbaas (where I was planning to apply it at first) i'm not sure i'm able to proceed with some non-wip code | 17:55 |
| SumitNaiksatam | garyduan: would you be interested in trying this on FWaaS? | 17:56 |
| enikanorov | banix: to me the design is quite straightforward, if you see some issues - feel free to email me or reach out to IRC, i'll update the wiki and the code | 17:56 |
| banix | enikanorov: can you ellaborate what you mean by state of lbaas; | 17:56 |
| banix | sorry for being ignorant on that front | 17:56 |
| enikanorov | banix: np. we're thinking of some API redesign, and basically flavor framework is not a top priority there | 17:57 |
| *** cjellick has quit IRC | 17:57 | |
| banix | enikanorov: i see. thx. | 17:57 |
| *** cjellick has joined #openstack-meeting-3 | 17:57 | |
| enikanorov | btu i may try to apply the patch to some other adv service | 17:57 |
| *** cjellic__ has quit IRC | 17:57 | |
| SumitNaiksatam | enikanorov: are you offering to apply the patch to some other adv service or are you suggesting that some one else can apply? | 17:58 |
| enikanorov | btw, sorry for interrupting | 17:58 |
| enikanorov | my patch assumes that service already employs provider framework | 17:58 |
| enikanorov | and that is something that we had not agreement with some core team members | 17:59 |
| enikanorov | so... | 17:59 |
| SumitNaiksatam | enikanorov: ok, that is a bit of catch 22 | 17:59 |
| *** Sukhdev has quit IRC | 17:59 | |
| banix | Is it possible to invent a simple service just for experimentation? or the calue is in picking an existing service and see how it can use this framework? | 17:59 |
| banix | value | 17:59 |
| SumitNaiksatam | enikanorov: since the STF is not approved for FWaaS or VPNaaS | 17:59 |
| enikanorov | banix: it's implemented in my patch :_) | 17:59 |
| banix | enikanorov: right | 17:59 |
| pcm | STF not hard to add though... | 18:00 |
| enikanorov | SumitNaiksatam: so the value that i see in STF is dispatching mechanism, but STF is blamed for bad user experieence | 18:00 |
| SumitNaiksatam | pcm: that is correct, the patches are already there | 18:00 |
| SumitNaiksatam | pcm: yeah, per enikanorov ^^^ the STF future itself is uncertain | 18:00 |
| Swami | pcm: Why was the STF patch not approved. | 18:01 |
| SumitNaiksatam | Swami: see enikanorov’s comment ^^^ | 18:01 |
| pcm | Swami: I think the discussion of flavors put a hold on it. | 18:01 |
| SumitNaiksatam | ok all, we have other topics | 18:01 |
| songole | SumitNaiksatam: Apologies for my ignorance. What is STF? | 18:01 |
| enikanorov | service type framework | 18:01 |
| Swami | SumitNaiksatam,pcm: thanks | 18:01 |
| songole | oh. thanks | 18:01 |
| enikanorov | or provider framework | 18:01 |
| SumitNaiksatam | lets think about what’s a good way to make progress, and if you have suggestions, please send to the mailer, we can revisit next week as to where we are | 18:02 |
| SumitNaiksatam | songole: STF - service type framewrok | 18:02 |
| SumitNaiksatam | moving on | 18:02 |
| SumitNaiksatam | cgoncalves: wanted some time last week, and we could not accommodate that | 18:02 |
| SumitNaiksatam | #topic Port chaining proposal | 18:02 |
| *** openstack changes topic to "Port chaining proposal (Meeting topic: Networking Advanced Services)" | 18:02 | |
| cgoncalves | SumitNaiksatam: thanks | 18:02 |
| SumitNaiksatam | #link https://docs.google.com/document/d/1Bk1e8-diE1VnzlbM8l479Mjx2vKliqdqC_3l5S56ITU/edit?pli=1# | 18:03 |
| SumitNaiksatam | cgoncalves: i believe you sent an email to the mailer? | 18:03 |
| cgoncalves | so, I don't know if any of you read that doc | 18:03 |
| SumitNaiksatam | cgoncalves: i had a quick run through it | 18:03 |
| cgoncalves | SumitNaiksatam: I did send an email to -dev ml some time ago | 18:03 |
| SumitNaiksatam | hope others had a chance to look | 18:03 |
| SumitNaiksatam | btw, enikanorov: thanks for the earlier update! :-) | 18:03 |
| enikanorov | np! | 18:04 |
| SumitNaiksatam | cgoncalves: does anyone have thoughts on cgoncalves’s proposal? | 18:04 |
| SumitNaiksatam | cgoncalves: perhaps people need a little more time to read through | 18:05 |
| SumitNaiksatam | cgoncalves: you want to quickly summarize? | 18:05 |
| banix | cgoncalves: are you following the work being done on services in VMs? are these related? | 18:05 |
| cgoncalves | in a nutshell: if I'm not mistaken, every Neutron network service is attached to a Neutron port. the currently work regarding network service chain only adresses those Neutron network services | 18:05 |
| banix | cgoncalves: ignore my question and carry on pls | 18:06 |
| cgoncalves | what I'm proposing is not restrict to those supported services but anything that is reached via a Neutron port | 18:06 |
| SumitNaiksatam | cgoncalves: that is somewhat true (regarding each service attaching to a port) | 18:06 |
| s3wong | SumitNaiksatam: cgoncalves: what are we really adding with port-based chaining over service-context based one? | 18:06 |
| *** lpetrut has joined #openstack-meeting-3 | 18:06 | |
| SumitNaiksatam | banix: service VM discussion coming up, hang in there :-) | 18:07 |
| banix | SumitNaiksatam: sure. thanks. | 18:07 |
| SumitNaiksatam | s3wong: it is supposed to be a more flexible approach | 18:07 |
| cgoncalves | s3wong: in the service-context based one you can only attach Neutron services (vpn, lb, fw) to the chain. I'm proposing augumenting it to something more broad and hence a port-based approach | 18:07 |
| SumitNaiksatam | s3wong: as banix hinted, this might have more relevance when services are in a VM | 18:08 |
| cgoncalves | s3wong: so that you can mix in a chain VMs and Neutron services | 18:08 |
| SumitNaiksatam | cgoncalves: so my take on this is that this could be potential approach to chaining | 18:08 |
| cgoncalves | the group policy BP could also benefit from this approach rather than also be limited to the service-based approach | 18:09 |
| s3wong | SumitNaiksatam: cgoncalves: yes, I can see more relevancy in case a service has multiple ports | 18:09 |
| SumitNaiksatam | cgoncalves: however it requires the user to actually understand everything about how a service is realized | 18:09 |
| SumitNaiksatam | cgoncalves: we were trying to hide that to some extent by making services available as *aaS | 18:09 |
| s3wong | cgoncalves: for GBP, I don't know if tenants would even "see" a port to a service | 18:10 |
| cgoncalves | SumitNaiksatam: yes, but as argued in the proposal Neutron can't keep up with all network services providing them as *aaS | 18:10 |
| s3wong | cgoncalves: OK - you are thinking if the tenants themselves are bringing in their own services | 18:11 |
| SumitNaiksatam | cgoncalves: that is true, but in that case that service is not a service, its just a VM as far as Neutron/OpenStack is concerned | 18:11 |
| SumitNaiksatam | s3wong: yeah, mean to say the same thing | 18:11 |
| cgoncalves | s3wong: yes. you can see use case #2 for instance (the DPI one) | 18:11 |
| s3wong | SumitNaiksatam: but you can't chain that service then, right? | 18:11 |
| cgoncalves | SumitNaiksatam: that's right. | 18:11 |
| banix | Network Service as a Sevice? NSaaS | 18:11 |
| SumitNaiksatam | banix: :-) | 18:11 |
| s3wong | banix: ha ha :-) | 18:12 |
| SumitNaiksatam | recursive defintion like GNU | 18:12 |
| banix | :) | 18:12 |
| cgoncalves | SumitNaiksatam: the whole propose is to be agnostic to what's running in those ports, either a VM running some kind of service or a Neutron provided network service | 18:12 |
| SumitNaiksatam | cgoncalves: essentially you want a way to be able to specify that traffic be steered between certain ports | 18:12 |
| cgoncalves | btw, IETF folks have been recently working on the definition and such on this matter http://datatracker.ietf.org/wg/sfc/ | 18:13 |
| cgoncalves | SumitNaiksatam: yes. | 18:13 |
| s3wong | cgoncalves: in case of GBP, in case of having service represented by a group, having to specify a "port" seems to be limiting | 18:13 |
| SumitNaiksatam | s3wong: i dont see this being directly consumed at the policy abstraction level | 18:14 |
| SumitNaiksatam | s3wong: however the “renderer” could potentially make use of this | 18:14 |
| kanzhe | cgoncalves: what about define a "GenericServiceaaS" with service context? then undefined services can be inserted or chained with serviceContext. | 18:14 |
| cgoncalves | SumitNaiksatam: given this approach, the work you've been working on Neutron network service chaining could use this work | 18:14 |
| SumitNaiksatam | cgoncalves: yeah, i was trying to say that | 18:15 |
| SumitNaiksatam | kanzhe: i see, that could be another way of doing it | 18:15 |
| cgoncalves | s3wong: that could be hidden from the user, I guess | 18:15 |
| s3wong | SumitNaiksatam: how so? The chain itself is "rendered" by GBP in our thinking so far, right (contract scope chains)? | 18:16 |
| s3wong | or service object | 18:16 |
| cgoncalves | kanzhe: that's another way, yes | 18:16 |
| SumitNaiksatam | s3wong: still not completely sure, there are differing opinions :-) | 18:16 |
| SumitNaiksatam | cgoncalves: ok thanks, good start, lets think about it a little more | 18:16 |
| cgoncalves | kanzhe: but I think in that particular case you would say that VMs could be initiated and configured by Neutron just like other services (fw, lb, vpn) | 18:17 |
| banix | cgoncalves: this all sounds very interesting; will read through more carefully and get back to you. | 18:17 |
| cgoncalves | banix: thanks | 18:17 |
| SumitNaiksatam | cgoncalves: and lets give others a chance to think through this as well | 18:17 |
| cgoncalves | SumitNaiksatam: ok. thank you the time slot to briefly present it here | 18:17 |
| SumitNaiksatam | cgoncalves: very welcome and we will circle back | 18:17 |
| SumitNaiksatam | #tpoic Service VM progress update | 18:17 |
| cgoncalves | we've been working on models and API. next week I think I can present something to you all | 18:18 |
| SumitNaiksatam | #topic Service VM progress update | 18:18 |
| *** openstack changes topic to "Service VM progress update (Meeting topic: Networking Advanced Services)" | 18:18 | |
| SumitNaiksatam | cgoncalves: great thanks | 18:18 |
| s3wong | cgoncalves: great. Looking forward to seeing that | 18:18 |
| SumitNaiksatam | so yamahata cannot make it to this meeting | 18:18 |
| SumitNaiksatam | s3wong: voluteered to provide update from the service VM meeting | 18:18 |
| SumitNaiksatam | s3wong: over to you | 18:18 |
| banix | s3wong: that's nice. thanks. | 18:19 |
| s3wong | SumitNaiksatam: I see yamahata online, but I guess he is really sleeping now :-) | 18:19 |
| kanzhe | cgoncalves: I think this group is working on many enhancement around XaaS to address resource scheduling, insertion, chaining, and other issues. The port-based proposal won't be able to leverage all the improvement. | 18:19 |
| SumitNaiksatam | yamahata: there? | 18:19 |
| s3wong | So yamahata has done pretty much all the work so far | 18:19 |
| SumitNaiksatam | kanzhe: that is good point | 18:19 |
| s3wong | the API and DB model is here: | 18:19 |
| SumitNaiksatam | s3wong: yes please go on | 18:19 |
| s3wong | #link https://review.openstack.org/#/c/72068/ | 18:20 |
| s3wong | The basic architecture consists of a management interface driver and a device manager/driver | 18:20 |
| s3wong | management manager/driver is for management interface on the VM | 18:21 |
| s3wong | device manager/driver is for managing the actual service VM | 18:21 |
| cgoncalves | kanzhe: if you could elaborate more on that thought next week or mailing list I would appreciate :-) | 18:21 |
| s3wong | at this point, the reference implementation we are aiming for is LBaaS haproxy driver on a VM | 18:22 |
| *** jamie_h has quit IRC | 18:22 | |
| s3wong | some preliminary diff can be found here: | 18:22 |
| kanzhe | cgoncalves: sure. | 18:22 |
| s3wong | #link https://review.openstack.org/#/c/72068/ | 18:22 |
| s3wong | that is not working yet, BTW | 18:23 |
| SumitNaiksatam | the API patch is here #link https://review.openstack.org/#/c/56892 | 18:23 |
| s3wong | yamahata is also working with the community on defining a message proxy server | 18:23 |
| s3wong | SumitNaiksatam: sorry, cut and paste error :-) | 18:24 |
| SumitNaiksatam | s3wong: np | 18:24 |
| s3wong | currently the suggestion is to use Marconi | 18:24 |
| SumitNaiksatam | s3wong: perhaps let people dwell on these links a little more | 18:24 |
| SumitNaiksatam | s3wong: ok, sounds logical | 18:24 |
| s3wong | which I have no idea what Marconi really does, so I will refrain from commenting too much :-) | 18:25 |
| s3wong | yamahata would like our comment on the API and DB model, especially | 18:25 |
| SumitNaiksatam | s3wong: i believe they had applied for incubation | 18:25 |
| SumitNaiksatam | s3wong: sure | 18:25 |
| SumitNaiksatam | all, please respond to the review patches in Gerrit | 18:26 |
| *** SridarK has joined #openstack-meeting-3 | 18:26 | |
| SumitNaiksatam | s3wong: thanks | 18:26 |
| SumitNaiksatam | Swami: there? | 18:26 |
| s3wong | SumitNaiksatam: Thanks for letting me proxy yamahata for couple minutes :-) | 18:26 |
| Swami | yes here | 18:26 |
| SumitNaiksatam | s3wong: we will circle back next week, thanks! | 18:26 |
| banix | s3wong: thanks | 18:26 |
| SumitNaiksatam | #topic Service Insertion for distributed service implementation | 18:26 |
| *** openstack changes topic to "Service Insertion for distributed service implementation (Meeting topic: Networking Advanced Services)" | 18:26 | |
| SumitNaiksatam | Swami: you want to quicly brief the team about the issues you were facing? | 18:27 |
| Swami | SumitNaiksatam: Yes | 18:27 |
| SumitNaiksatam | Swami: please go ahead | 18:27 |
| Swami | For the Distributed routed module, some of the services can be distributed and there are certain services that need to be centralized. | 18:28 |
| Swami | Say for example FWaaS and LBaaS can be distributed. | 18:28 |
| Swami | VPNaaS should be a singleton service and should be centralized. | 18:28 |
| banix | Swami: dictributed as in a cluster | 18:29 |
| Swami | Is there any way that we can identify the services and assign it to the right routers. | 18:29 |
| Swami | banix: Distributed across your compute Nodes. For the Distributed Virtual Router, all tenant routers will be distributed and will be available in each and every compute node were the Tenant routed vm resides. | 18:30 |
| *** wchrisj_ has joined #openstack-meeting-3 | 18:30 | |
| s3wong | Swami: distributed LBaaS as in elastic load balancing? | 18:30 |
| banix | swami: got it; thx. | 18:30 |
| SumitNaiksatam | Swami: how useful do you think the “service_context” be in this case? | 18:30 |
| Swami | s3wong: For LBaaS today it is not tied to the router, so it might not be a problem. | 18:31 |
| SumitNaiksatam | BTW, we are the end of the meeting but we can go on longer, since i have the next meeting slot as well on this channel | 18:31 |
| SumitNaiksatam | Swami: go ahead, take your time | 18:31 |
| Swami | SumitNaiksatam: Thanks | 18:31 |
| SumitNaiksatam | SridarK: apologies for the delay on FWaaS but i believe you are equally interested here :-) | 18:31 |
| Swami | So here in this case we are proposing the chain is created and then we apply the chain to a router. | 18:32 |
| SridarK | Yes no worries at all interested too SumitNaiksatam: | 18:32 |
| Swami | How do we distinguish between the services and apply those service chains to the respective routers is my question. | 18:32 |
| Swami | If this has not been addressed, then we should take it into consideration. | 18:33 |
| SumitNaiksatam | Swami: we have discussed before, but we have not addressed it | 18:33 |
| Swami | SumitNaiksatam: Yes I do agree. | 18:33 |
| banix | Swami: agree | 18:33 |
| SumitNaiksatam | Swami: since currently even the single service/centralized insertion is kind of fuzzy :-) | 18:34 |
| banix | SumitNaiksatam: yeah :) | 18:34 |
| Swami | SumitNaiksatam: Yes I agree . | 18:34 |
| *** beyounn has joined #openstack-meeting-3 | 18:34 | |
| SumitNaiksatam | Swami: but this is a good time to bring this up, since we dont want to paint ourselves in a corner | 18:34 |
| SumitNaiksatam | Swami: my earlier question, will sevice_context help in this case? | 18:34 |
| kanzhe | Swami: This is the same issue with NAT service, which DVR proposal has a solution. Are you proposing a more generic way to tackle the problem? | 18:34 |
| Swami | Even with today's model we might be able to include it into our discussion and see where we end up, rather than modifying our stuff later. | 18:34 |
| SumitNaiksatam | Swami: or we need to think through it again? | 18:34 |
| SumitNaiksatam | kanzhe: sorry go ahead | 18:35 |
| SumitNaiksatam | Swami: kanzhe’s question ^^^ | 18:35 |
| Swami | SumitNaiksatam: yes we need to think through it again and probably walk through a use case. | 18:35 |
| garyduan | Hi, sorry, I was in a meeting | 18:35 |
| SumitNaiksatam | garyduan: np, we are still in the previous meeting too :-) | 18:36 |
| Swami | kanzhe: yes DVR is proposing that NAT being done at the Service Node. That's where we are also thinking that the VPNaaS should be running. | 18:36 |
| SumitNaiksatam | Swami: so NAT is still centralized? | 18:36 |
| *** overlayer_ has quit IRC | 18:36 | |
| Swami | SumitNaiksatam: Yes SNAT is centralized, but for any floating ip it is still distributed. | 18:37 |
| SumitNaiksatam | Swami: thanks, sorry for being slow, you had explained this before during the meeting | 18:37 |
| Swami | SumitNaiksatam: What we can do is take the existing services and come up with a Use case on how it will be handled with the centralized and distribtued mode. | 18:38 |
| SumitNaiksatam | Swami kanzhe: so in the distributed case, can we expect the service backend be expected to figure out how the distribution occurs | 18:38 |
| Swami | Then we can discuss how the Framework will help deploy those services. | 18:38 |
| SumitNaiksatam | Swami kanzhe: based on the service_context? | 18:38 |
| Swami | SumitNaiksatam: yes the service_context. | 18:39 |
| Swami | SumitNaiksatam: For next week we can plan on walking through the use-case. | 18:40 |
| kanzhe | SumitNaiksatam: this is a good use case for service insertion. Swami: agree. | 18:40 |
| s3wong | Swami: sounds good | 18:40 |
| SumitNaiksatam | Swami kanzhe: can you guys set something up before the next week’s meeting? | 18:41 |
| SumitNaiksatam | and whoever else is interested | 18:41 |
| Swami | SumitNaiksatam: Yes I will work on that Use case with either You are kanzhe. | 18:41 |
| SumitNaiksatam | Swami: thanks! | 18:41 |
| Swami | SumitNaiksatam: Also one other information. | 18:42 |
| SumitNaiksatam | Swami: and for bringing this up…sorry it took us two weeks to get this | 18:42 |
| SumitNaiksatam | Swami: although you requested that this be discussed three weeks back | 18:42 |
| SumitNaiksatam | for the record! :-) | 18:42 |
| kanzhe | SumitNaiksatam: what is the venue? An IRC meeting before the next week's meeting? | 18:42 |
| SumitNaiksatam | Swami: go ahead | 18:42 |
| Swami | For the Certificate handling for all the services, should this be discussed in this meeting or is there another team for that. | 18:42 |
| SumitNaiksatam | kanzhe: lets decide offline, i think we need a higher bandwidth channel | 18:42 |
| kanzhe | SumitNaiksatam: sounds good. | 18:43 |
| SumitNaiksatam | Swami: ah, you had asked that before as well | 18:43 |
| SumitNaiksatam | Swami: i dont have any objections to discusisng it in this meeting | 18:43 |
| Swami | I also discussed briefly about this with enikanorov. | 18:43 |
| SumitNaiksatam | Swami: we are probably out of time this week, but lets circle back on this for the next week’s meeting | 18:44 |
| SumitNaiksatam | everyone just one more topic | 18:44 |
| Swami | Right now both LBaaS and VPNaaS needs some framework within the Neutron to support Certificates. | 18:44 |
| SumitNaiksatam | Swami: sure | 18:44 |
| SumitNaiksatam | #topic Adv Services logistics | 18:44 |
| *** openstack changes topic to "Adv Services logistics (Meeting topic: Networking Advanced Services)" | 18:44 | |
| SumitNaiksatam | hope everyone is still around | 18:44 |
| SumitNaiksatam | enikanorov: ? | 18:44 |
| Swami | SumitNaiksatam: Thanks we can take this next week, I don't want to block your FWaaS meeting. | 18:44 |
| SumitNaiksatam | so this thought just occured to me | 18:44 |
| s3wong | SumitNaiksatam: this meeting needs to be at least 90 minutes long :-) | 18:45 |
| SumitNaiksatam | based on Swami’s request | 18:45 |
| SumitNaiksatam | s3wong: :-) | 18:45 |
| enikanorov | i'm here still | 18:45 |
| SumitNaiksatam | enikanorov: good | 18:45 |
| SumitNaiksatam | so we have lots of things to discuss here | 18:45 |
| SumitNaiksatam | under the advance services requirements agenda | 18:45 |
| enikanorov | what's 'logistics' is about? | 18:45 |
| SumitNaiksatam | we need a way to channelize this feedback and prioritize it | 18:45 |
| SumitNaiksatam | enikanorov: probably bad choice of words, i meant process for channelizing feedback | 18:46 |
| SumitNaiksatam | #undo | 18:46 |
| openstack | Removing item from minutes: <ircmeeting.items.Topic object at 0x2515590> | 18:46 |
| enikanorov | ok | 18:46 |
| SumitNaiksatam | #topic Advanced Services common requirements process and prioritization | 18:46 |
| *** openstack changes topic to "Advanced Services common requirements process and prioritization (Meeting topic: Networking Advanced Services)" | 18:46 | |
| SumitNaiksatam | i think at this point we are not having enough core participation in this meeting | 18:47 |
| SumitNaiksatam | and hence i am concerned that what we are discussing here does not have enough of a representation on the core team side | 18:47 |
| SumitNaiksatam | does anyone have thoughts on this? | 18:48 |
| SumitNaiksatam | One thing i can think off is having a standing item on this topic “Advanced Services common requirements” in the neutron IRC | 18:48 |
| pcm | +1 | 18:49 |
| SridarK | SumitNaiksatam: +1 i think this is a good way to get more attention | 18:49 |
| SumitNaiksatam | currently there is hardly any time given to advanced services in the neutron IRC | 18:49 |
| banix | SumitNaiksatam: agree with the premise. | 18:49 |
| Swami | SumitNaiksatam: Yes that would work out. | 18:49 |
| Swami | +1 | 18:49 |
| kanzhe | SumitNaiksatam: That would be a good start. | 18:49 |
| SumitNaiksatam | ok | 18:49 |
| SumitNaiksatam | enikanorov: what do you think? | 18:49 |
| s3wong | SumitNaiksatam: sure +1 | 18:49 |
| SumitNaiksatam | we should check with nachi as well | 18:50 |
| SumitNaiksatam | enikanorov: there? | 18:50 |
| enikanorov | i'll support this idea | 18:50 |
| SumitNaiksatam | enikanorov: ok | 18:50 |
| banix | and the API group? | 18:50 |
| SumitNaiksatam | we should not expect to get too much time | 18:50 |
| SumitNaiksatam | but just enough to highlight our high priority items | 18:50 |
| SumitNaiksatam | that way we can get on the radar | 18:51 |
| SumitNaiksatam | ok, enikanorov, lets try to reach out to nachi, and try to work through this | 18:51 |
| SumitNaiksatam | #topic Open Discussion | 18:51 |
| *** openstack changes topic to "Open Discussion (Meeting topic: Networking Advanced Services)" | 18:51 | |
| enikanorov | sure | 18:51 |
| SumitNaiksatam | anythin more for today? | 18:51 |
| SumitNaiksatam | enikanorov: thanks | 18:51 |
| SumitNaiksatam | okay i think its been a fairly long meeting | 18:52 |
| SumitNaiksatam | thanks all for joining and hanging in there | 18:52 |
| banix | bye | 18:52 |
| SumitNaiksatam | bye all! | 18:52 |
| s3wong | bye! | 18:52 |
| SumitNaiksatam | #endmeeting | 18:53 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 18:53 | |
| openstack | Meeting ended Wed Apr 9 18:53:01 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:53 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-04-09-17.31.html | 18:53 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-04-09-17.31.txt | 18:53 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-04-09-17.31.log.html | 18:53 |
| Swami | bye | 18:53 |
| *** songole has left #openstack-meeting-3 | 18:53 | |
| *** jamie_h has joined #openstack-meeting-3 | 18:54 | |
| *** mandeep has left #openstack-meeting-3 | 18:54 | |
| SumitNaiksatam | SridarK garyduan beyounn: there? | 18:54 |
| beyounn | ya | 18:54 |
| SridarK | hi SumitNaiksatam | 18:54 |
| SumitNaiksatam | ok lets get started | 18:55 |
| SumitNaiksatam | #startmeeting Networking FWaaS | 18:55 |
| openstack | Meeting started Wed Apr 9 18:55:08 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. | 18:55 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 18:55 |
| *** openstack changes topic to " (Meeting topic: Networking FWaaS)" | 18:55 | |
| openstack | The meeting name has been set to 'networking_fwaas' | 18:55 |
| garyduan | Yes | 18:55 |
| SumitNaiksatam | SridarK beyounn garyduan: thanks for joining | 18:55 |
| SumitNaiksatam | I am not sure that Rajesh will join | 18:55 |
| SumitNaiksatam | #topic Service Insertion and Firewall | 18:55 |
| *** openstack changes topic to "Service Insertion and Firewall (Meeting topic: Networking FWaaS)" | 18:55 | |
| SridarK | dont see him online | 18:55 |
| SumitNaiksatam | #link https://review.openstack.org/#/c/62599 | 18:56 |
| SumitNaiksatam | Rajesh as updated the patch | 18:56 |
| SumitNaiksatam | *has | 18:56 |
| SumitNaiksatam | and we are trying to chase the reviewers | 18:57 |
| SumitNaiksatam | thanks SridarK for working on the CLI | 18:57 |
| SumitNaiksatam | any further thoughts on that? | 18:57 |
| SridarK | SumitNaiksatam: i will also pick up his changes to run a complete end to end test | 18:57 |
| SumitNaiksatam | SridarK: nice | 18:57 |
| SumitNaiksatam | i think the DB migration changes are probably not right in his patch | 18:58 |
| SumitNaiksatam | i mean the changes to the HEAD | 18:58 |
| SumitNaiksatam | need to check | 18:58 |
| SumitNaiksatam | #topic Firewall Zones | 18:58 |
| *** openstack changes topic to "Firewall Zones (Meeting topic: Networking FWaaS)" | 18:58 | |
| SridarK | Jenkins would have complained then correct ? | 18:58 |
| SumitNaiksatam | SridarK: not sure | 18:59 |
| SumitNaiksatam | I mean i am not sure that we are supposed to modify that file | 18:59 |
| SridarK | it seems happy now anyways wil discuss later | 18:59 |
| SumitNaiksatam | it will work but i am not sure that its the right convention | 18:59 |
| SumitNaiksatam | #undo | 18:59 |
| openstack | Removing item from minutes: <ircmeeting.items.Topic object at 0x2671a10> | 18:59 |
| SumitNaiksatam | : #topic Firewall Zones | 18:59 |
| SridarK | SumitNaiksatam: starting to pull things together as a doc | 19:00 |
| SumitNaiksatam | SridarK: ok good | 19:00 |
| SumitNaiksatam | SridarK: do you by any chance have a link? | 19:00 |
| SridarK | did have some questions and need to run thru more usecases | 19:00 |
| garyduan | For zone, I just brought an idea if it can be covered by service chaining | 19:00 |
| SridarK | no not yet still very prelim | 19:00 |
| SridarK | garyduan: yes we should discuss that | 19:01 |
| SumitNaiksatam | SridarK: ok | 19:01 |
| SumitNaiksatam | garyduan: okay, is this documented? | 19:01 |
| SridarK | The notion of a zone could be a collection of some basic neutron resources indicating src or dest of the traffic of interest. This could beyond just looking at router or ports perhaps networks, subnets too ? | 19:01 |
| garyduan | no, just in the email | 19:01 |
| SumitNaiksatam | garyduan: ah ok, the one you had sent a few days back? | 19:01 |
| SridarK | so working of that looks a lot like what we are doing for service insertion at least in term of what we are specifying | 19:02 |
| garyduan | SumitNaiksatam: yes | 19:02 |
| SumitNaiksatam | garyduan: got it | 19:02 |
| SumitNaiksatam | SridarK garyduan: in general if we can “infer” zones from other existing constructs we should do that | 19:03 |
| SridarK | SumitNaiksatam: garyduan it does seem like we can do that | 19:03 |
| SumitNaiksatam | that said, service_context itself is not yet merged/approved | 19:03 |
| SumitNaiksatam | so one could also make a case for zones | 19:03 |
| SridarK | that said just want to make sure that there is no ambiguity and no corner cases | 19:03 |
| SumitNaiksatam | to infer the service_context :-) | 19:04 |
| garyduan | Let's say we still want to define zone | 19:04 |
| garyduan | SridarK listed two options we discussed before | 19:04 |
| garyduan | setting the zone on policy or on rules | 19:05 |
| SumitNaiksatam | what is the predominant usage in firewalls? | 19:06 |
| SridarK | garyduan: one concern on the second case was being able to reuse the policy for other zone pairs | 19:06 |
| SumitNaiksatam | SridarK: ah, good point | 19:06 |
| SumitNaiksatam | SridarK: but that would apply to the policy as well? | 19:06 |
| SridarK | SumitNaiksatam: from the cisco usage it would be outside the rules and more as a policy being applied across a zone pair | 19:06 |
| SumitNaiksatam | SridarK: ok | 19:07 |
| SumitNaiksatam | garyduan beyounn: what do you guys think? | 19:07 |
| SridarK | SumitNaiksatam: (1) is not really embedded in the policy but more as FW attribute | 19:07 |
| SumitNaiksatam | SridarK: ok | 19:07 |
| garyduan | The concern is we might need a lot of firewall, simply for different zones | 19:08 |
| SumitNaiksatam | garyduan: ok | 19:08 |
| SridarK | garyduan: ok because we have a single policy | 19:09 |
| *** MaxV has joined #openstack-meeting-3 | 19:09 | |
| garyduan | SridarK: yes | 19:09 |
| garyduan | SridarK: or if zone is an attribute of FW | 19:09 |
| garyduan | SridarK: do we allow a list of src/dst zones or just one pair | 19:10 |
| garyduan | SridarK: to be associated with one firewall instance? | 19:10 |
| SridarK | garyduan: rather that was the case in how we view it with a single policy - what i meant was the zone pair assoc is done outside the policy | 19:10 |
| SridarK | garyduan: the thought now is to think in terms of a single pair | 19:11 |
| *** jtomasek has quit IRC | 19:11 | |
| SridarK | because the zone is itself a list of n/w entities | 19:12 |
| garyduan | SridarK: so we might still need multiple firewalls on one router | 19:12 |
| SridarK | garyduan: but i agree on ur point of having multiple fw is not easy | 19:12 |
| SridarK | if we supported multiple policies then on each policy we could apply diff zone pairs | 19:13 |
| *** rand738 has quit IRC | 19:13 | |
| SridarK | SumitNaiksatam: but i think we dont want to think in terms of having multiple policies on a FW ? | 19:14 |
| garyduan | or define zone at rule level | 19:14 |
| garyduan | I mean associate zone with rules | 19:14 |
| SumitNaiksatam | SridarK: we avoided doing that because composition is not easy | 19:14 |
| SridarK | garyduan: yes so we can have co mingling of zones | 19:14 |
| SridarK | SumitNaiksatam: yes | 19:14 |
| garyduan | SridarK: yes | 19:15 |
| SridarK | garyduan: SumitNaiksatam: i think in that case this is a strong case for supporting it in the rules if we cannot have multiple policies | 19:15 |
| SumitNaiksatam | SridarK: ok | 19:16 |
| SumitNaiksatam | i wanted to take a step back though, and think through this | 19:16 |
| SridarK | Ofcourse vendor backends can normalize to their implementations | 19:16 |
| SumitNaiksatam | in the sense that, what abstractions should be exposed in any *aaS in Neutron | 19:16 |
| SumitNaiksatam | does a zone need to be a fundamental fwaas abstraction? | 19:17 |
| SumitNaiksatam | or is is a detail that needs to be hidden from the “cloud” user | 19:17 |
| *** rand738 has joined #openstack-meeting-3 | 19:18 | |
| SridarK | SumitNaiksatam: Hmm! cant think beyond a network guy :-) | 19:18 |
| SridarK | but u raise an important point in terms of the abstraction | 19:18 |
| SridarK | from a user perspective | 19:18 |
| SumitNaiksatam | SridarK: i think that applies to all of us :-) | 19:19 |
| SumitNaiksatam | i bring this up, because there was a discussion on more than one occassion, raising the question whether every aspect of every service needs to be represented as an abstraction in neutron/openstack | 19:19 |
| SridarK | i see something like "deploy a FW btwn the engineering folks and the marketing folks" | 19:19 |
| SumitNaiksatam | SridarK: true | 19:19 |
| SridarK | engineering - could be a collection of some n/w entities | 19:20 |
| SridarK | same for mktg and that we think of as a zone | 19:20 |
| *** krotscheck has quit IRC | 19:20 | |
| SumitNaiksatam | SridarK: correct | 19:20 |
| SridarK | agree on ur thought on the abstraction and i am sure this will be raised | 19:20 |
| SumitNaiksatam | SridarK: hence my hesitation | 19:21 |
| SumitNaiksatam | SridarK: as long as we are able to respond and justify, we can go ahead with this | 19:21 |
| garyduan | Someone asked in HK summit that can zone be defined by subnet | 19:21 |
| garyduan | instead of ports | 19:21 |
| SumitNaiksatam | SridarK: right now i dont have a strong enough justification | 19:21 |
| SumitNaiksatam | garyduan: ok | 19:21 |
| SridarK | SumitNaiksatam: also earlier we were thinking of zone as a resource but perhaps how we think of Service context more an attribute | 19:22 |
| garyduan | that becomes very similar to service chain | 19:22 |
| SridarK | garyduan: yes subnets, networks | 19:22 |
| SumitNaiksatam | so i come back to asking, are there “cloud” use cases that we cannot satisfy without the explicit definition of zones? | 19:22 |
| SridarK | garyduan: and this also led me to ur line of thought with relation to service context | 19:22 |
| garyduan | I think we need zone concept, either in terms of zone object or service context | 19:23 |
| SridarK | SumitNaiksatam: i think we can justify along the lines of the engr mktg type usecases ofcourse with more analysis with something more realistic | 19:23 |
| garyduan | or web server subnet and database subnet | 19:24 |
| SridarK | garyduan: adding that from and to | 19:24 |
| garyduan | subnet => networks | 19:24 |
| SumitNaiksatam | garyduan: ok | 19:25 |
| SridarK | SumitNaiksatam: i will work thru more with some usecases | 19:25 |
| garyduan | web and db networks served in one l3 router can have different policies | 19:26 |
| SumitNaiksatam | SridarK: okay, great | 19:26 |
| SumitNaiksatam | garyduan: correct | 19:26 |
| garyduan | right now this is can be sort of achieved by IP addresses | 19:26 |
| SumitNaiksatam | garyduan beyounn: are you guys still comfortable with the current defintion of service_context? | 19:27 |
| garyduan | SumitNaiksatam: beyounn just left | 19:27 |
| SumitNaiksatam | or for that matter it’s need | 19:27 |
| SumitNaiksatam | garyduan: ok, what about you? | 19:27 |
| garyduan | SumitNaiksatam: I think it is OK | 19:27 |
| garyduan | SumitNaiksatam: but we need more clarification on validation logic | 19:28 |
| SumitNaiksatam | garyduan: ok let me ask in a different way, what is your understanding on service_context? | 19:28 |
| SumitNaiksatam | i am asking since different people are interpreting in different ways | 19:28 |
| garyduan | A place to insert the service | 19:29 |
| SumitNaiksatam | so insert to you means, attaching to the network, or being able to steer traffic to it? | 19:29 |
| garyduan | but the context only defines the place, but only implies what the service is | 19:29 |
| garyduan | SumitNaiksatam: either way | 19:30 |
| SumitNaiksatam | garyduan: hmmm…thats where it gets a little ambiguous | 19:31 |
| garyduan | SumitNaiksatam: I think it's up to driver to decide | 19:31 |
| SumitNaiksatam | okay i am not sure if there is another meeting on this channel now | 19:31 |
| SumitNaiksatam | i think we can go on until we are bumped out (since we started a little late) | 19:31 |
| SridarK | SumitNaiksatam: i thought steering was out of the scope | 19:32 |
| SumitNaiksatam | SridarK: yeah i was about to ask you | 19:32 |
| SumitNaiksatam | SridarK: so what is your understanding? | 19:32 |
| SumitNaiksatam | of service_context | 19:32 |
| SridarK | SumitNaiksatam: to me it seems defining the insert point similar to what garyduan mentioned | 19:32 |
| SridarK | SumitNaiksatam: but steering seemed was not out of the scope of this first activity | 19:33 |
| SridarK | and will be covered with how the data path stiching happens | 19:33 |
| SridarK | we may then need to think in terms of if any encaps are needed etc esp in the chaining case | 19:33 |
| SumitNaiksatam | SridarK: true, but i think others have an opinion that service_context provides the context to steering | 19:34 |
| SridarK | SumitNaiksatam: clearly a closely related activity except we were keeping that for step 2 in the discussion | 19:35 |
| SridarK | at least from the original BP scope | 19:35 |
| SumitNaiksatam | SridarK: true, not so much from this patch or BP perspective | 19:35 |
| SumitNaiksatam | garyduan: do you agree with what SridarK mentioned? | 19:35 |
| garyduan | SumitNaiksatam: yes | 19:35 |
| SumitNaiksatam | garyduan: ok | 19:36 |
| SumitNaiksatam | garyduan: are you travelling or are you local? | 19:36 |
| garyduan | SumitNaiksatam: local, I am back :-) | 19:36 |
| SumitNaiksatam | garyduan: ok | 19:37 |
| SumitNaiksatam | lets plan the F2F to discuss more details on the zones, and perhaps touch on service_context | 19:38 |
| SumitNaiksatam | we will circle back in the IRC next week as well | 19:38 |
| SridarK | SumitNaiksatam: i will have some travel next week - will sync with u guys on email | 19:38 |
| SridarK | SumitNaiksatam: to set a time | 19:38 |
| SumitNaiksatam | SridarK: sure | 19:39 |
| SumitNaiksatam | #topic open discussion | 19:39 |
| *** openstack changes topic to "open discussion (Meeting topic: Networking FWaaS)" | 19:39 | |
| SumitNaiksatam | anything more to discuss? | 19:39 |
| garyduan | not from me | 19:40 |
| SridarK | nothing from me | 19:40 |
| SumitNaiksatam | ok thanks for joining! | 19:40 |
| SumitNaiksatam | until next time, bye! | 19:40 |
| SridarK | thanks for the good discussion | 19:40 |
| SridarK | bye | 19:40 |
| SumitNaiksatam | #endmeeting | 19:40 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 19:40 | |
| openstack | Meeting ended Wed Apr 9 19:40:43 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 19:40 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/networking_fwaas/2014/networking_fwaas.2014-04-09-18.55.html | 19:40 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/networking_fwaas/2014/networking_fwaas.2014-04-09-18.55.txt | 19:40 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/networking_fwaas/2014/networking_fwaas.2014-04-09-18.55.log.html | 19:40 |
| *** pcm has left #openstack-meeting-3 | 19:40 | |
| *** SridarK has quit IRC | 19:42 | |
| *** krotscheck has joined #openstack-meeting-3 | 19:43 | |
| *** rkukura has left #openstack-meeting-3 | 19:48 | |
| *** d0ugal has quit IRC | 19:54 | |
| *** kanzhe has quit IRC | 19:58 | |
| *** david_lyle_ has joined #openstack-meeting-3 | 20:01 | |
| *** dklyle has joined #openstack-meeting-3 | 20:03 | |
| *** david-lyle has quit IRC | 20:04 | |
| *** beyounn has quit IRC | 20:06 | |
| *** david_lyle_ has quit IRC | 20:06 | |
| *** eguz has quit IRC | 20:07 | |
| *** eghobo has joined #openstack-meeting-3 | 20:07 | |
| *** tedchang has quit IRC | 20:08 | |
| *** d0ugal has joined #openstack-meeting-3 | 20:09 | |
| *** d0ugal has quit IRC | 20:09 | |
| *** d0ugal has joined #openstack-meeting-3 | 20:09 | |
| *** mwagner_lap has joined #openstack-meeting-3 | 20:10 | |
| *** jcoufal has quit IRC | 20:13 | |
| *** openstackstatus has quit IRC | 20:15 | |
| *** openstackstatus has joined #openstack-meeting-3 | 20:16 | |
| *** markmcclain has joined #openstack-meeting-3 | 20:21 | |
| *** jcoufal has joined #openstack-meeting-3 | 20:32 | |
| *** beyounn has joined #openstack-meeting-3 | 20:38 | |
| *** jamielennox|away is now known as jamielennox | 20:43 | |
| *** jamielennox has left #openstack-meeting-3 | 20:44 | |
| *** dklyle is now known as david-lyle | 21:03 | |
| *** enykeev has quit IRC | 21:10 | |
| *** xazel has joined #openstack-meeting-3 | 21:10 | |
| *** eghobo has quit IRC | 21:12 | |
| *** openstackstatus has quit IRC | 21:14 | |
| *** jcoufal has quit IRC | 21:16 | |
| *** openstackstatus has joined #openstack-meeting-3 | 21:22 | |
| *** SumitNaiksatam has quit IRC | 21:23 | |
| *** lblanchard has quit IRC | 21:24 | |
| *** mfer has quit IRC | 21:31 | |
| *** MaxV has quit IRC | 21:31 | |
| *** markmcclain has quit IRC | 21:39 | |
| *** markmcclain has joined #openstack-meeting-3 | 21:41 | |
| *** david-lyle has quit IRC | 22:02 | |
| *** markmcclain has quit IRC | 22:02 | |
| *** SumitNaiksatam has joined #openstack-meeting-3 | 22:07 | |
| *** kevinbenton has quit IRC | 22:14 | |
| *** jamie_h has quit IRC | 22:15 | |
| *** SumitNaiksatam has quit IRC | 22:22 | |
| *** lpetrut has quit IRC | 22:23 | |
| *** wchrisj_ has quit IRC | 22:28 | |
| *** openstack has joined #openstack-meeting-3 | 22:33 | |
| *** ChanServ sets mode: +o openstack | 22:34 | |
| *** MaxV has joined #openstack-meeting-3 | 22:36 | |
| *** alexpilotti has quit IRC | 22:40 | |
| *** Sukhdev has joined #openstack-meeting-3 | 22:59 | |
| *** MaxV has quit IRC | 23:04 | |
| *** banix has quit IRC | 23:07 | |
| *** wchrisj has joined #openstack-meeting-3 | 23:28 | |
| *** s3wong has quit IRC | 23:41 | |
| *** wchrisj has quit IRC | 23:47 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!