| *** wchrisj has quit IRC | 00:08 | |
| *** MaxV has quit IRC | 00:09 | |
| *** MaxV has joined #openstack-meeting-3 | 00:09 | |
| *** mfer has joined #openstack-meeting-3 | 00:16 | |
| *** mfer has quit IRC | 00:16 | |
| *** cjellick has quit IRC | 00:20 | |
| *** mwagner_lap has joined #openstack-meeting-3 | 00:21 | |
| *** jamielennox has left #openstack-meeting-3 | 00:23 | |
| *** SumitNaiksatam has quit IRC | 00:24 | |
| *** sarob has joined #openstack-meeting-3 | 00:47 | |
| *** yamahata has quit IRC | 00:47 | |
| *** sarob_ has joined #openstack-meeting-3 | 00:48 | |
| *** wchrisj has joined #openstack-meeting-3 | 00:52 | |
| *** sarob has quit IRC | 00:52 | |
| *** devlaps has quit IRC | 00:52 | |
| *** mwagner__ has joined #openstack-meeting-3 | 00:56 | |
| *** dguitarbite has quit IRC | 01:09 | |
| *** eguz_ has quit IRC | 01:15 | |
| *** wchrisj has quit IRC | 01:25 | |
| *** amotoki has joined #openstack-meeting-3 | 01:38 | |
| *** sarob_ has quit IRC | 01:43 | |
| *** wchrisj has joined #openstack-meeting-3 | 02:00 | |
| *** wchrisj has quit IRC | 02:04 | |
| *** yamahata has joined #openstack-meeting-3 | 02:08 | |
| *** jthopkin has joined #openstack-meeting-3 | 02:19 | |
| *** devlaps has joined #openstack-meeting-3 | 02:29 | |
| *** jthopkin has quit IRC | 02:35 | |
| *** MaxV has quit IRC | 02:36 | |
| *** coolsvap has quit IRC | 02:39 | |
| *** eghobo has joined #openstack-meeting-3 | 03:00 | |
| *** MaxV has joined #openstack-meeting-3 | 03:06 | |
| *** dguitarbite has joined #openstack-meeting-3 | 03:08 | |
| *** MaxV has quit IRC | 03:11 | |
| *** SumitNaiksatam has joined #openstack-meeting-3 | 03:22 | |
| *** devlaps has quit IRC | 03:30 | |
| *** banix has joined #openstack-meeting-3 | 03:50 | |
| *** dguitarbite has quit IRC | 03:52 | |
| *** banix has quit IRC | 04:36 | |
| *** dguitarbite has joined #openstack-meeting-3 | 04:57 | |
| *** wchrisj has joined #openstack-meeting-3 | 05:00 | |
| *** wchrisj has quit IRC | 05:37 | |
| *** dguitarbite has quit IRC | 05:40 | |
| *** lpetrut has joined #openstack-meeting-3 | 05:46 | |
| *** saju_m has joined #openstack-meeting-3 | 05:58 | |
| *** jtomasek has joined #openstack-meeting-3 | 06:33 | |
| *** eghobo has quit IRC | 07:26 | |
| *** jtomasek has quit IRC | 07:30 | |
| *** lpetrut has quit IRC | 07:44 | |
| *** MaxV has joined #openstack-meeting-3 | 07:50 | |
| *** MaxV has quit IRC | 08:05 | |
| *** jtomasek has joined #openstack-meeting-3 | 08:08 | |
| *** lpetrut has joined #openstack-meeting-3 | 08:08 | |
| *** lpetrut_ has joined #openstack-meeting-3 | 08:10 | |
| *** lpetrut has quit IRC | 08:12 | |
| *** ttrifonov_zZzz is now known as ttrifonov | 08:13 | |
| *** mrunge has joined #openstack-meeting-3 | 08:19 | |
| *** jcoufal has joined #openstack-meeting-3 | 08:22 | |
| *** nacim has joined #openstack-meeting-3 | 08:50 | |
| *** yamahata has quit IRC | 08:51 | |
| *** jcoufal has quit IRC | 08:54 | |
| *** nacim has quit IRC | 08:54 | |
| *** nacim has joined #openstack-meeting-3 | 08:55 | |
| *** MaxV has joined #openstack-meeting-3 | 08:57 | |
| *** safchain has joined #openstack-meeting-3 | 09:01 | |
| *** markmcclain has joined #openstack-meeting-3 | 09:03 | |
| *** MaxV has quit IRC | 09:04 | |
| *** johnthetubaguy has joined #openstack-meeting-3 | 09:16 | |
| *** jcoufal has joined #openstack-meeting-3 | 09:24 | |
| *** jcoufal has quit IRC | 09:25 | |
| *** amotoki has quit IRC | 09:26 | |
| *** jcoufal has joined #openstack-meeting-3 | 09:26 | |
| *** jrist has joined #openstack-meeting-3 | 09:32 | |
| *** jcoufal has quit IRC | 10:07 | |
| *** johnthetubaguy1 has joined #openstack-meeting-3 | 10:23 | |
| *** johnthetubaguy has quit IRC | 10:26 | |
| *** johnthetubaguy1 is now known as johnthetubaguy | 10:30 | |
| *** jcoufal has joined #openstack-meeting-3 | 11:13 | |
| *** safchain has quit IRC | 11:35 | |
| *** markmcclain has quit IRC | 11:36 | |
| *** rook has joined #openstack-meeting-3 | 11:46 | |
| *** jrist has quit IRC | 11:53 | |
| *** jcoufal has quit IRC | 12:19 | |
| *** MaxV has joined #openstack-meeting-3 | 12:29 | |
| *** jtomasek has quit IRC | 12:37 | |
| *** mrunge has quit IRC | 12:51 | |
| *** jrist has joined #openstack-meeting-3 | 12:58 | |
| *** lblanchard has joined #openstack-meeting-3 | 13:00 | |
| *** julim has joined #openstack-meeting-3 | 13:12 | |
| *** safchain has joined #openstack-meeting-3 | 13:13 | |
| *** jthopkin has joined #openstack-meeting-3 | 13:14 | |
| *** xuhanp has joined #openstack-meeting-3 | 13:15 | |
| *** cjellick has joined #openstack-meeting-3 | 13:16 | |
| *** mfer has joined #openstack-meeting-3 | 13:22 | |
| *** mwagner_lap is now known as mwagner_dontUseM | 13:25 | |
| *** cjellick has quit IRC | 13:27 | |
| *** jrist has quit IRC | 13:27 | |
| *** cjellick has joined #openstack-meeting-3 | 13:28 | |
| *** mwagner__ has quit IRC | 13:30 | |
| *** jrist has joined #openstack-meeting-3 | 13:36 | |
| *** safchain has quit IRC | 13:37 | |
| *** safchain has joined #openstack-meeting-3 | 13:40 | |
| *** peristeri has joined #openstack-meeting-3 | 13:44 | |
| *** alexpilotti has joined #openstack-meeting-3 | 13:47 | |
| *** david-lyle has quit IRC | 13:48 | |
| *** jthopkin has quit IRC | 13:50 | |
| *** wchrisj has joined #openstack-meeting-3 | 13:54 | |
| *** jthopkin has joined #openstack-meeting-3 | 14:05 | |
| *** jrist has quit IRC | 14:05 | |
| *** jthopkin has quit IRC | 14:06 | |
| *** safchain has quit IRC | 14:08 | |
| *** markmcclain has joined #openstack-meeting-3 | 14:10 | |
| *** markmcclain1 has joined #openstack-meeting-3 | 14:12 | |
| *** markmcclain has quit IRC | 14:15 | |
| *** markmcclain1 has quit IRC | 14:40 | |
| *** devlaps has joined #openstack-meeting-3 | 14:51 | |
| *** markmcclain has joined #openstack-meeting-3 | 14:54 | |
| *** cjellick has quit IRC | 14:57 | |
| *** david-lyle has joined #openstack-meeting-3 | 14:58 | |
| *** jrist has joined #openstack-meeting-3 | 14:59 | |
| *** jpomero has joined #openstack-meeting-3 | 15:00 | |
| *** mwagner__ has joined #openstack-meeting-3 | 15:05 | |
| *** jthopkin has joined #openstack-meeting-3 | 15:06 | |
| *** yamahata has joined #openstack-meeting-3 | 15:07 | |
| *** jthopkin has quit IRC | 15:23 | |
| *** banix has joined #openstack-meeting-3 | 15:26 | |
| *** jthopkin has joined #openstack-meeting-3 | 15:28 | |
| *** jcoufal has joined #openstack-meeting-3 | 15:39 | |
| *** jcoufal has quit IRC | 15:39 | |
| *** MaxV has quit IRC | 15:41 | |
| *** MaxV has joined #openstack-meeting-3 | 15:42 | |
| *** jthopkin has quit IRC | 15:45 | |
| *** jthopkin has joined #openstack-meeting-3 | 15:52 | |
| *** coolsvap has joined #openstack-meeting-3 | 15:54 | |
| *** eghobo has joined #openstack-meeting-3 | 16:06 | |
| *** Sukhdev has joined #openstack-meeting-3 | 16:08 | |
| *** eghobo has quit IRC | 16:08 | |
| *** eghobo has joined #openstack-meeting-3 | 16:11 | |
| *** xuhanp has quit IRC | 16:17 | |
| *** tjones has joined #openstack-meeting-3 | 16:23 | |
| *** jrist has quit IRC | 16:25 | |
| *** dansmith has joined #openstack-meeting-3 | 16:26 | |
| tjones | hi anyone here for bug scrub? | 16:30 |
|---|---|---|
| * dansmith lurks | 16:30 | |
| tjones | #startmeeting NovaBugScrub | 16:30 |
| openstack | Meeting started Wed Mar 19 16:30:52 2014 UTC and is due to finish in 60 minutes. The chair is tjones. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:30 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:30 |
| *** openstack changes topic to " (Meeting topic: NovaBugScrub)" | 16:30 | |
| openstack | The meeting name has been set to 'novabugscrub' | 16:30 |
| *** melwitt has joined #openstack-meeting-3 | 16:30 | |
| tjones | hi dansmith | 16:31 |
| tjones | i mean "lurker" | 16:31 |
| * dansmith stays in the shadows | 16:31 | |
| tjones | ok - anyone else here so we can get starting? just 11 to tag today and then we will look at rc1 bugs | 16:31 |
| melwitt | o/ | 16:31 |
| wendar | o/ | 16:31 |
| tjones | great - lets go then | 16:32 |
| tjones | #link https://bugs.launchpad.net/nova/+bugs?field.tag=-*&field.status%3Alist=NEW | 16:32 |
| tjones | #link https://bugs.launchpad.net/nova/+bug/1291311 | 16:32 |
| tjones | compute | 16:32 |
| wendar | compute | 16:33 |
| *** SumitNaiksatam has quit IRC | 16:33 | |
| tjones | i actually went through a bunch of these already - trying to get the obvious ones done | 16:33 |
| tjones | but i missed that one | 16:33 |
| tjones | #link https://bugs.launchpad.net/nova/+bug/1291637 | 16:33 |
| tjones | this sounds like a big deal from 1st glance | 16:34 |
| wendar | affects keystone | 16:34 |
| tjones | added that. | 16:34 |
| wendar | and api | 16:34 |
| tjones | rc1 issue? | 16:35 |
| wendar | I'd nominate it for rc1 | 16:36 |
| wendar | it may depend on how disruptive the fix is | 16:36 |
| tjones | i think so too. (to both points). just raise visibility | 16:36 |
| tjones | #link https://bugs.launchpad.net/nova/+bug/1291726 | 16:36 |
| tjones | api? | 16:37 |
| melwitt | I think so | 16:37 |
| tjones | #link https://bugs.launchpad.net/nova/+bug/1291791 | 16:37 |
| wendar | sounds likely, but really needs more details | 16:38 |
| tjones | wendar: the prev one? | 16:38 |
| tjones | wendar: you mind updating that to ask for more? | 16:38 |
| wendar | aye | 16:38 |
| melwitt | the last one I'd say nova-manage | 16:38 |
| tjones | duh :-) | 16:38 |
| tjones | forgot that was a tag | 16:39 |
| tjones | #link https://bugs.launchpad.net/nova/+bug/1292309 | 16:39 |
| melwitt | hehe | 16:39 |
| tjones | i guess api | 16:39 |
| melwitt | api I think | 16:39 |
| tjones | #link https://bugs.launchpad.net/nova/+bug/1292316 | 16:40 |
| tjones | api | 16:40 |
| tjones | #link https://bugs.launchpad.net/nova/+bug/1292339 | 16:40 |
| tjones | thinking it's compute | 16:41 |
| melwitt | agree | 16:42 |
| tjones | #link https://bugs.launchpad.net/nova/+bug/1292572 | 16:42 |
| wendar | api | 16:43 |
| tjones | #link https://bugs.launchpad.net/nova/+bug/1293794 | 16:43 |
| tjones | compute??? | 16:44 |
| wendar | nods | 16:44 |
| tjones | #link https://bugs.launchpad.net/nova/+bug/1294316 | 16:45 |
| tjones | guessing compute again | 16:45 |
| *** markmcclain has quit IRC | 16:45 | |
| melwitt | it might be volumes | 16:46 |
| tjones | ok | 16:46 |
| tjones | last but not least | 16:46 |
| tjones | #link https://bugs.launchpad.net/nova/+bug/1294481 | 16:46 |
| melwitt | I'm not sure, probably compute is better | 16:47 |
| tjones | should i put them both and let them decide? | 16:47 |
| melwitt | yeah, can do that | 16:47 |
| tjones | ok this last one - i thought the gate would block nova.conf getting out of sync | 16:48 |
| wendar | I guess not :( | 16:49 |
| melwitt | I thought so too (it's happened to me in the past) | 16:49 |
| tjones | it has blocked it for me before - guess i got lucky | 16:49 |
| tjones | so not sure how to tag it | 16:49 |
| wendar | rc candidate? | 16:49 |
| wendar | seems like a simple fix | 16:49 |
| tjones | yes | 16:49 |
| tjones | quite | 16:49 |
| tjones | ok we are done with tagging. ! | 16:50 |
| tjones | #link https://launchpad.net/nova/+milestone/icehouse-rc1 | 16:50 |
| tjones | anything not merged by monday will be moved out to rc-potential unless it's a regression or something terrible (as decided by russellb) | 16:51 |
| tjones | i've been pushing out stuff that was not moving already | 16:51 |
| tjones | :-D | 16:51 |
| *** rkukura has joined #openstack-meeting-3 | 16:52 | |
| tjones | dansmith: you may want to take a look at https://bugs.launchpad.net/bugs/1291637 we just added it to rc1 | 16:52 |
| dansmith | NO! | 16:52 |
| * dansmith looks | 16:52 | |
| dansmith | tjones: I don't think that's unified-objects related by the way | 16:53 |
| dansmith | confusing usage of "object" but I don't think there's any difference with caching NovaObjects in that case | 16:53 |
| *** briancurtin has left #openstack-meeting-3 | 16:53 | |
| tjones | dansmith: i tagged it api though?? | 16:53 |
| dansmith | tjones: that's fine, I thought you were getting me to look because of the object relation | 16:54 |
| tjones | im just telling you since you are lurking. | 16:54 |
| dansmith | oh | 16:54 |
| dansmith | then, okay | 16:54 |
| dansmith | :) | 16:54 |
| tjones | i'll let cyeoh know | 16:54 |
| *** d89 has joined #openstack-meeting-3 | 16:54 | |
| tjones | anything else for bugs? | 16:55 |
| *** SumitNaiksatam has joined #openstack-meeting-3 | 16:55 | |
| tjones | ok then i think we are done today | 16:55 |
| tjones | thanks for your help wendar, melwitt | 16:55 |
| wendar | thanks tjones | 16:56 |
| tjones | #endmeeting | 16:56 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 16:56 | |
| openstack | Meeting ended Wed Mar 19 16:56:28 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:56 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/novabugscrub/2014/novabugscrub.2014-03-19-16.30.html | 16:56 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/novabugscrub/2014/novabugscrub.2014-03-19-16.30.txt | 16:56 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/novabugscrub/2014/novabugscrub.2014-03-19-16.30.log.html | 16:56 |
| *** melwitt has left #openstack-meeting-3 | 16:57 | |
| *** s3wong has joined #openstack-meeting-3 | 16:59 | |
| *** SridarK has joined #openstack-meeting-3 | 17:00 | |
| SumitNaiksatam | Hi folks! | 17:00 |
| s3wong | Hello | 17:00 |
| cgoncalves | hi! | 17:00 |
| SridarK | Hi All | 17:00 |
| banix | Hi | 17:00 |
| banix | just changed the main meeting page to reflect the new meeting time | 17:01 |
| SumitNaiksatam | s3wong cgoncalves SridarK banix enikanorov__: hi | 17:01 |
| enikanorov__ | hi | 17:01 |
| SumitNaiksatam | banix: shoot...thanks | 17:01 |
| rkukura | hi | 17:01 |
| SridarK | Hi SumitNaiksatam: | 17:01 |
| SumitNaiksatam | banix: had only changed on the wiki page | 17:01 |
| cgoncalves | SumitNaiksatam: did you also changed the time in the iCal? | 17:01 |
| banix | SumitNaiksatam: Hi | 17:01 |
| banix | Hi everybody | 17:01 |
| SumitNaiksatam | i think that was probably the reason for enikanorov__'s confusion | 17:01 |
| SumitNaiksatam | cgoncalves: nope, not that either :-( | 17:02 |
| SumitNaiksatam | feel free to update, or i can | 17:02 |
| SumitNaiksatam | ok lets get started | 17:02 |
| banix | SumitNaiksatam: np | 17:02 |
| cgoncalves | SumitNaiksatam: it should be write-protected I guess | 17:02 |
| SumitNaiksatam | i think we almost have a qorum | 17:02 |
| *** tjones has left #openstack-meeting-3 | 17:02 | |
| SumitNaiksatam | #startmeeting Networking Advanced Services | 17:03 |
| openstack | Meeting started Wed Mar 19 17:03:08 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:03 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:03 |
| *** openstack changes topic to " (Meeting topic: Networking Advanced Services)" | 17:03 | |
| openstack | The meeting name has been set to 'networking_advanced_services' | 17:03 |
| SumitNaiksatam | cgoncalves: lets check after the meeting on how to change ical | 17:03 |
| SumitNaiksatam | Meeting agenda: #link https://wiki.openstack.org/wiki/Meetings/AdvancedServices | 17:03 |
| SumitNaiksatam | as we discussed last time there are many topics of interest for this forum | 17:04 |
| *** eguz has joined #openstack-meeting-3 | 17:04 | |
| SumitNaiksatam | please feel free to add the topics of interest to the wiki page ^^^ | 17:04 |
| SumitNaiksatam | and we can accordingly prioritize | 17:04 |
| *** eguz has quit IRC | 17:04 | |
| SumitNaiksatam | i just picked an agenda for today based on the discussions during the week (and past meeting) | 17:04 |
| *** eguz has joined #openstack-meeting-3 | 17:04 | |
| s3wong | SumitNaiksatam: Are the topics priortized on the wiki page now? | 17:04 |
| SumitNaiksatam | but definitely open to suggestions | 17:05 |
| cgoncalves | SumitNaiksatam: I would add the chaining thing I talked with you yesterday but I'll have to leave in 25m | 17:05 |
| SumitNaiksatam | s3wong: the topics of discussion are not necessarily in order of priority | 17:05 |
| s3wong | i.e., meaning that "Group Policy requirements" has the highest priority :-) | 17:05 |
| SumitNaiksatam | s3wong: ha...you wish :-) | 17:05 |
| *** ttrifonov is now known as ttrifonov_zZzz | 17:05 | |
| SumitNaiksatam | cgoncalves: sure, that becomes part of the chaining discussion | 17:05 |
| banix | May be we are on the "next meeting"? | 17:05 |
| SumitNaiksatam | banix: "next meeting" as in today's meeting | 17:06 |
| banix | I mean the entry for the next meeting is for this meeting | 17:06 |
| banix | yes | 17:06 |
| SumitNaiksatam | #topic Service context | 17:06 |
| *** openstack changes topic to "Service context (Meeting topic: Networking Advanced Services)" | 17:06 | |
| SumitNaiksatam | #link https://review.openstack.org/#/c/62599 | 17:06 |
| SumitNaiksatam | so last week we tried to get everyone upto speed with this | 17:06 |
| SumitNaiksatam | the above patch proposes the notion of the service context | 17:07 |
| SumitNaiksatam | wanted to check if you had a chance to think over this | 17:07 |
| *** eghobo has quit IRC | 17:07 | |
| SumitNaiksatam | it seems like this is a small first step to achieve the other things we want to with services | 17:08 |
| SumitNaiksatam | this might not be sufficient though | 17:08 |
| banix | yes, with the current available options for a context being: port, network, subnet, router | 17:08 |
| SumitNaiksatam | (we can come to the not sufficient part in the next agenda topic) | 17:08 |
| SumitNaiksatam | banix: ok | 17:08 |
| s3wong | SumitNaiksatam: not really gone through the code yet, but the current definition of service context seems like a good first step | 17:09 |
| SumitNaiksatam | s3wong: yes sure, i think it might be difficult to glean the intent from the code | 17:09 |
| *** d89 has left #openstack-meeting-3 | 17:09 | |
| SumitNaiksatam | the google doc was trying to capture the intent: #link https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering | 17:09 |
| SumitNaiksatam | ok anyone have different thoughts on this? | 17:10 |
| SumitNaiksatam | if not, can we comment on the above review? | 17:10 |
| SumitNaiksatam | that way we can hopefully have the service_context notion available early in Juno and we can build on it | 17:11 |
| banix | I think the google doc referenced in the link above ^^^ is a good place for different parts of the services framework | 17:11 |
| SumitNaiksatam | banix: ok | 17:11 |
| s3wong | SumitNaiksatam: will review the code - though not happening during this meeting... | 17:11 |
| SumitNaiksatam | s3wong: sure :-) | 17:11 |
| SumitNaiksatam | ok so let's move on to the next topic | 17:12 |
| *** jthopkin has left #openstack-meeting-3 | 17:12 | |
| SumitNaiksatam | #topic Base Service definition | 17:12 |
| *** openstack changes topic to "Base Service definition (Meeting topic: Networking Advanced Services)" | 17:12 | |
| banix | yes will look more closely; my only comments were related to the policy work which we will cover later. | 17:12 |
| SumitNaiksatam | banix: yes sure | 17:12 |
| SumitNaiksatam | #link https://github.com/openstack/neutron/blob/master/neutron/services/service_base.py | 17:13 |
| SumitNaiksatam | some of us met yesterday in person (those who are local in the bay area) | 17:13 |
| SumitNaiksatam | and were brainstorming on discussion from the last IRC meeting | 17:13 |
| s3wong | SumitNaiksatam: what is this service_base thing? seems to depend on service type framework? | 17:14 |
| SumitNaiksatam | s3wong: yeah, getting there - trying to expelling the context | 17:14 |
| SumitNaiksatam | we were reaching the realization that the service_context itself might not be enough to support "user defined" chaining | 17:15 |
| SumitNaiksatam | by "user defined" chaining i mean the point that was raised by s3wong banix and others last time, that one should be able to create a chain from any collection of available services | 17:16 |
| SumitNaiksatam | and not be limited to those defined in as a service-type/flavor | 17:16 |
| SumitNaiksatam | to support this it would require that each service provide information about where it plugs into the topolocy | 17:17 |
| SumitNaiksatam | *topology | 17:17 |
| SumitNaiksatam | using this information, the chain provider can chain these services | 17:17 |
| SumitNaiksatam | however, today's base service definition (link above) does not have any notion of this | 17:18 |
| SumitNaiksatam | ideally, something like "get_service_attachment_ports" kind of an api | 17:18 |
| SumitNaiksatam | thoughts? | 17:18 |
| SridarK | SumitNaiksatam: so just as one would pick a flavor - we also want to be able to pick a chain | 17:19 |
| SumitNaiksatam | SridarK: this is the case where the chain is constructed by the user, not based on chain defined as a flavor | 17:19 |
| enikanorov__ | SumitNaiksatam: that makes sense. it also means that service's driver api should have such method as well. | 17:19 |
| SridarK | ok got it | 17:19 |
| s3wong | SumitNaiksatam: seems like we may need tenants with their own service to have APIs to fill out a service context for their own service? | 17:20 |
| banix | each service or each service driver | 17:20 |
| enikanorov__ | because attachment ports could be different for diff drivers | 17:20 |
| SumitNaiksatam | enikanorov__ banix: i am referring to the logical neutron port as the attachment point | 17:20 |
| SumitNaiksatam | which can be returned by the service plugin (it might perhaps depend on the driver) | 17:21 |
| enikanorov__ | i think it does depends on the driver | 17:21 |
| SumitNaiksatam | the assumption is that the chain provider can map the attachment point (neutron port) to the backend realization | 17:21 |
| s3wong | SumitNaiksatam: do we expect the chain provider to do traffic steering (to the next service in chain, for example) | 17:21 |
| s3wong | or that the service themselves would send traffic to the next element by querying the chain for where the next service is? | 17:22 |
| cgoncalves | SumitNaiksatam: I haven't put enough though on the implementation part, but this neutron network service chain and service context could get deprecated in favor of a generic chaining mechanism where we define chains were not based on neutron network services but on neutron ports, as neutron network services are accessible as neutron ports. this way we could mix network services and machines in chains | 17:22 |
| SumitNaiksatam | enikanorov__: well, i am saying that the API is on the service, to satisfy it, might require driver participation | 17:22 |
| *** MaxV has quit IRC | 17:22 | |
| SumitNaiksatam | s3wong: i would imagine its the former | 17:22 |
| enikanorov__ | ok | 17:23 |
| banix | SumitNaikasatam: makes sense | 17:23 |
| SumitNaiksatam | cgoncalves: in the group yesterday we discussed your proposal for neutron ports | 17:23 |
| SumitNaiksatam | cgoncalves: that is neutron ports to specify a service chain | 17:24 |
| SumitNaiksatam | cgoncalves: however that does not seem to be the right user facing abstraction | 17:24 |
| SumitNaiksatam | cgoncalves: it requires the user to understand how each service is instantiated | 17:24 |
| SumitNaiksatam | cgoncalves: there are other ways to satisfy to your use case | 17:24 |
| SumitNaiksatam | banix: ok | 17:24 |
| SumitNaiksatam | enikanorov__: what are your thoughts on introducing this API in the service base class? | 17:25 |
| enikanorov__ | i'm fine with that, however I need to understand how this maps to flavors | 17:25 |
| enikanorov__ | i can explain | 17:25 |
| SumitNaiksatam | enikanorov__: go ahead | 17:26 |
| enikanorov__ | given that actual service provider (driver) will be a result of scheduling based on flavor | 17:26 |
| cgoncalves | SumitNaiksatam: how would users have to understand how each service is instantiated? services would be instantiated on a neutron port and nothing more. it would then be up to the user to strategically place the service where he wants (e.g., in between two other neutron ports) | 17:26 |
| enikanorov__ | that becomes a requirement that driver publishes it's capability of support for certain chain type | 17:26 |
| cgoncalves | SumitNaiksatam: but that we can discuss off meeting | 17:27 |
| enikanorov__ | so basically service context and then get_attachment_ports should match driver's capabilities | 17:27 |
| enikanorov__ | i hope i get all that right :) | 17:28 |
| banix | cgoncalves: please let us know if there are any pointers to your proposal so we can review (after the meeting in my case) | 17:28 |
| s3wong | enikanorov__: wouldn't that mean that all the chains have to be pre-defined by OpenStack community? because otherwise drivers can't know what the available chain types are? | 17:28 |
| enikanorov__ | s3wong: i believe that was the initial proposal, to have predefined chains. and we've discussed that on previous meeting | 17:29 |
| SumitNaiksatam | enikanorov__ s3wong: i think the chain provider should know of the service constructs, but the service should not have to know of the chain construct | 17:29 |
| cgoncalves | banix: I've started today writing proposal on a google doc. I'll share with you all as soon as it gets some form to discuss | 17:29 |
| SumitNaiksatam | cgoncalves: thanks | 17:30 |
| cgoncalves | folks, I will have to leave now. will catch up with the meeting log later today | 17:30 |
| banix | cgoncalves: thanks | 17:30 |
| s3wong | cgoncalves: have fun | 17:30 |
| cgoncalves | thank you all! | 17:30 |
| SumitNaiksatam | enikanorov__: in the predefined case the chain provider is performing the insertion | 17:30 |
| banix | SumitNaiksatam: +1 wrt having user defined chains | 17:30 |
| enikanorov__ | that seems to be difficult | 17:31 |
| SumitNaiksatam | enikanorov__: so yeah, the above discussion is not as relevant | 17:31 |
| SumitNaiksatam | enikanorov__: ok let me reword that, the chain provider provides the service_context for insertion | 17:31 |
| s3wong | I agree with SumitNaiksatam here - services should not have notion of chains, while chains should know about services | 17:31 |
| banix | yup | 17:32 |
| enikanorov__ | if chain provider does the insertion, will not it require it to support particular drivers of particular services? | 17:32 |
| SumitNaiksatam | enikanorov__: i clarified above ^^^ | 17:32 |
| enikanorov__ | I probably don't understand this completely | 17:32 |
| enikanorov__ | oh, yep, thanks | 17:32 |
| enikanorov__ | that makes sense | 17:32 |
| SumitNaiksatam | enikanorov__: yeah my bad | 17:32 |
| SumitNaiksatam | ok so in the "user defined" chain case, the chain provider is not in the best position to provide the service context | 17:33 |
| SumitNaiksatam | for each service | 17:33 |
| s3wong | SumitNaiksatam: isn't service context always provided by the service? | 17:34 |
| banix | can it drive the required context from a source/destination context? | 17:34 |
| SumitNaiksatam | so the thinking is that it would rely on the service to provide the details of how the insertion happened, and then use that information to do the steering | 17:34 |
| SumitNaiksatam | s3wong: so we are saying the user or the chain provider provides the service_context (except in cases when its a "user defined" chain) | 17:35 |
| SumitNaiksatam | banix: good point, it seems difficult for the chain provider to do this when the nature of services is not know before hand | 17:35 |
| SumitNaiksatam | banix: so in the workflow for the "user defined" chain will probably not even have the source and destination chain context | 17:36 |
| SumitNaiksatam | banix: each service will be created (with service context) individually | 17:36 |
| banix | SumitNaiksatam: ok | 17:36 |
| SumitNaiksatam | banix: like how you would create a stand alone service (with service_context) | 17:36 |
| s3wong | SumitNaiksatam: when a service is instantiated, user/service-itself should clarify the insertion points | 17:36 |
| SumitNaiksatam | s3wong: yeah | 17:37 |
| s3wong | in that case, much of the information needed for service context is filled up at that point | 17:37 |
| SumitNaiksatam | banix: and then the user creates the "user defined" chain merely stating which services he wants to be part of that chain | 17:37 |
| SumitNaiksatam | however, at this point the "user defined" chain provider kicks in, and needs to be able to steer the traffic between the different services | 17:38 |
| SumitNaiksatam | and hence it needs to know from each service, where it has attached in the network | 17:38 |
| SumitNaiksatam | note that the service_context, and the actual attachment/insertion point are slightly different | 17:39 |
| SumitNaiksatam | service_context is a sort of hint to express the intent | 17:39 |
| banix | SumitNaiksatam: Let's see if I understand this | 17:39 |
| SumitNaiksatam | each service implementation/provider/driver has its own way of actually inserting | 17:39 |
| SumitNaiksatam | banix: go ahead | 17:40 |
| banix | I was thinking along the line that for a user defined chain, the chain provider will set the insertion context for the services. Does that make sense? | 17:40 |
| s3wong | banix: how so? how does the chain provider know where to insert the service? | 17:41 |
| SumitNaiksatam | banix: the point s3wong is making is that, when you know what the service is going to be, you can bake that into the implementation | 17:42 |
| banix | It has to be given some context but not contexts for all the individual services | 17:42 |
| SumitNaiksatam | banix: that -> insertion | 17:42 |
| SumitNaiksatam | banix: but when you don't know the composition of the chain, its difficult to do | 17:42 |
| banix | yes unless the chain provider knows certain types of services | 17:43 |
| SumitNaiksatam | banix: exactly, hence the earlier suggestion to have templates/flavors for chains | 17:43 |
| banix | and can support them in a chain: meaning it know how to chain certain types of services. | 17:43 |
| enikanorov__ | btw, is my understanding correct that chain providing actually does the steering? I mean that it operates on already created services that are already somehow plugged into a network, right? | 17:43 |
| s3wong | banix: in that case we are restricting users to bring in a service that is not yet supported by Neutron | 17:44 |
| banix | well, we could be somewhere in between :) | 17:44 |
| SumitNaiksatam | enikanorov__: yes on the first part, different people have different understanding on the latter part | 17:44 |
| s3wong | enikanorov__: that was my question above too - but SumitNaiksatam indicates that service insertion point != chain attachment points | 17:44 |
| SumitNaiksatam | ok folks, i want to give enikanorov__ a chance for the flavors update as well | 17:45 |
| SumitNaiksatam | the chain part is a difficult discussion on IRC | 17:45 |
| enikanorov__ | not much to update. I am actually working on PoC code that will illustrate the proposal | 17:45 |
| banix | yes please go ahead | 17:45 |
| SumitNaiksatam | we can circle back to this topic | 17:46 |
| enikanorov__ | e.g. it will have an extension, db part and a test plugin with drivers where service could be requested by capabilities | 17:46 |
| s3wong | enikanorov__: nice | 17:46 |
| SumitNaiksatam | #topic Flavors update | 17:46 |
| *** openstack changes topic to "Flavors update (Meeting topic: Networking Advanced Services)" | 17:46 | |
| SumitNaiksatam | enikanorov__: nice | 17:46 |
| SumitNaiksatam | enikanorov__: so what approach are you taking for the PoC | 17:46 |
| SumitNaiksatam | as currently documented in the wiki: #link https://wiki.openstack.org/wiki/Neutron/FlavorFramework? | 17:47 |
| enikanorov__ | well, currently i'm thinking about flavor as a set of 'tags' | 17:47 |
| enikanorov__ | probably that is the simplest to implement | 17:47 |
| SumitNaiksatam | enikanorov__: define "tags" | 17:47 |
| SumitNaiksatam | as in labels? | 17:47 |
| enikanorov__ | currently thinking about k:v pairs as tags | 17:48 |
| SumitNaiksatam | enikanorov__: ok | 17:48 |
| enikanorov__ | so a flavor will be something like {'quality': 'good', 'topology': 'ha'} | 17:49 |
| s3wong | enikanorov__: so what happens if more than one driver can satisfy all the tags? | 17:49 |
| enikanorov__ | s3wong: that goes to scheduling algorithm | 17:49 |
| enikanorov__ | and it chooses. it may be random | 17:49 |
| SridarK | enikanorov__: beyond scheduling we can also specify a vendor ? | 17:49 |
| enikanorov__ | SridarK: that is a first requirement to implement existing workflow with providers | 17:50 |
| SumitNaiksatam | SridarK: i think vendor could be one of the "tags" | 17:50 |
| enikanorov__ | so vendor is just a tag | 17:50 |
| enikanorov__ | yep | 17:50 |
| SridarK | ok | 17:50 |
| SumitNaiksatam | enikanorov__: what are the required fields in the flavor definition? | 17:50 |
| enikanorov__ | service_type, name, tags | 17:50 |
| SumitNaiksatam | enikanorov__: tags could be empty, right? | 17:51 |
| enikanorov__ | tags are in a form of string concatenated from pairs k:v, k:v | 17:51 |
| enikanorov__ | hmm | 17:51 |
| enikanorov__ | yes, why not | 17:51 |
| SumitNaiksatam | enikanorov__: no i mean, you need to spec that out clearly | 17:51 |
| *** hemanthravi has joined #openstack-meeting-3 | 17:51 | |
| SumitNaiksatam | enikanorov__: if it cannot be empty, then it means there is a mandatory field in there | 17:52 |
| SumitNaiksatam | enikanorov__: right? | 17:52 |
| enikanorov__ | i mean that i didn't think about it specifically, but right now i cant' think of what prevents us from having empty tags in a flavor | 17:52 |
| SumitNaiksatam | enikanorov__: i am not proposing that, i think it could be empty | 17:52 |
| SumitNaiksatam | enikanorov__: yes | 17:52 |
| SumitNaiksatam | enikanorov__: essentially we are saying that the tags are completely service dependent | 17:52 |
| *** s3wong has quit IRC | 17:53 | |
| *** Kanzhe has joined #openstack-meeting-3 | 17:53 | |
| SumitNaiksatam | enikanorov__: do we need to identify any parameters that are common across services? | 17:53 |
| enikanorov__ | well, since tags are written in a free form | 17:53 |
| SumitNaiksatam | Kanzhe hemanthravi: welcome :-) | 17:53 |
| *** s3wong_ has joined #openstack-meeting-3 | 17:53 | |
| enikanorov__ | it's admin's responsibility to make it consistent | 17:53 |
| enikanorov__ | that's my opinion | 17:53 |
| SumitNaiksatam | enikanorov__: no i mean apart from the tags | 17:53 |
| hemanthravi | sumitnaiksatam: thought the irc was at 11...my mistake | 17:53 |
| Kanzhe | sorry, I went on a wrong meeting. | 17:54 |
| SumitNaiksatam | hemanthravi Kanzhe: np :-) | 17:54 |
| *** RajeshMohan has joined #openstack-meeting-3 | 17:54 | |
| enikanorov__ | apart from tags i see flavor name, and service type | 17:54 |
| s3wong_ | Kanzhe hemanthravi: was wondering where you guys were :-) | 17:54 |
| enikanorov__ | nothing else | 17:54 |
| SridarK | enikanorov__: Is the plan to target J1 or early J2 ? | 17:54 |
| SumitNaiksatam | enikanorov__: where service_type is a predefined constant? | 17:54 |
| enikanorov__ | SumitNaiksatam: yes, service type is predefined | 17:55 |
| hemanthravi | had an older advsvc invite on my cal :) | 17:55 |
| enikanorov__ | SridarK: J1 | 17:55 |
| SridarK | enikanorov__: Thanks that will help | 17:55 |
| SumitNaiksatam | enikanorov__: there was a suggestion to include service_context as part of flavor | 17:55 |
| SumitNaiksatam | enikanorov__: i am not necessarily in favor of that | 17:55 |
| enikanorov__ | hm, that's something i need to understand. service context is not a very user-friendly abstraction IMO | 17:56 |
| SumitNaiksatam | enikanorov__: but wanted to check what is the current thinking | 17:56 |
| SumitNaiksatam | enikanorov__: agree, service_context need not be user facing | 17:56 |
| s3wong_ | SumitNaiksatam: by including service context in flavor, then the service driver effectively limit how the service can be inserted into the chain - not necessarily a bad thing | 17:56 |
| SumitNaiksatam | enikanorov__: it can be derived based on other user friendly tags | 17:56 |
| *** dansmith has left #openstack-meeting-3 | 17:56 | |
| SumitNaiksatam | s3wong_: possibly | 17:57 |
| SumitNaiksatam | enikanorov__ s3wong_: i guess since tags are free form, a particular implementation might decide to expose service_context to the user | 17:57 |
| SumitNaiksatam | not necessary that the user has to populate it | 17:57 |
| Kanzhe | enikanorov__: agree that serviceContext is not user friendly. However, the need for a insertionContext is immediate for every services. | 17:58 |
| banix | Need two minutes before we end the meeting: we may need to change the time or IRC channel | 17:58 |
| s3wong_ | Kanzhe: agreed | 17:58 |
| banix | got a message from tax indicating there is a conflict on meeting-3 | 17:58 |
| enikanorov__ | Kanzhe: i think service context is not directly related to a flavor | 17:58 |
| SumitNaiksatam | banix: ah | 17:58 |
| enikanorov__ | for isntance | 17:58 |
| banix | Nova bug scrub meeting is every Wednesday at 16:30 UTC | 17:58 |
| Kanzhe | We refine the proposal to make it as user friendly as possible, not postpone the effort. | 17:58 |
| s3wong_ | banix: tax? :-) | 17:58 |
| SumitNaiksatam | i did not see any conflicts when we reserved | 17:59 |
| banix | ttx | 17:59 |
| SumitNaiksatam | they may have changed the time | 17:59 |
| hemanthravi | 10 am on meeting-3 is the right time? | 17:59 |
| enikanorov__ | Kanzhe: flavor may declare that service supports routed insertion (with tag 'router': 'yes', for example) | 17:59 |
| banix | how about going to 17:30? | 17:59 |
| s3wong_ | perhaps moving it an hour later? ML2 is the hour earlier, so conflict there for a lot of folks | 17:59 |
| enikanorov__ | and the insertion context is something that is used on background | 17:59 |
| SumitNaiksatam | #topic meeting day/time | 17:59 |
| *** openstack changes topic to "meeting day/time (Meeting topic: Networking Advanced Services)" | 17:59 | |
| SumitNaiksatam | banix: we have the fwaas meeting scheduled at 18.00 UTC | 18:00 |
| SumitNaiksatam | although we are not having it today | 18:00 |
| Kanzhe | enikanorov__: Routed insertion may address most of the use case for LB, but limits other type of services | 18:00 |
| banix | could it be because it was 16:30 we didn't notice the conflict? | 18:00 |
| banix | i see | 18:00 |
| SumitNaiksatam | ok we have reached to the hour | 18:01 |
| *** nacim has quit IRC | 18:01 | |
| SumitNaiksatam | lets discuss meeting day/time between us | 18:01 |
| enikanorov__ | Kanzhe: i meant that user doesn't specify insertion context, it's chain provider that passes context to a service | 18:01 |
| enikanorov__ | if service declared such support via capability | 18:01 |
| SumitNaiksatam | lets continue the discussion, an hour is proving to be too short | 18:01 |
| SumitNaiksatam | we can move over to -neutron | 18:01 |
| *** prasadv has joined #openstack-meeting-3 | 18:01 | |
| SumitNaiksatam | #endmeeting | 18:01 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 18:01 | |
| openstack | Meeting ended Wed Mar 19 18:01:50 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:01 |
| SumitNaiksatam | thanks all | 18:01 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-03-19-17.03.html | 18:01 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-03-19-17.03.txt | 18:01 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-03-19-17.03.log.html | 18:01 |
| *** prasadv has quit IRC | 18:02 | |
| Kanzhe | SumitNaiksatam: are we moving to different channel? | 18:02 |
| SumitNaiksatam | we can continue the discussion in #openstack-neutron if you guys want to | 18:02 |
| SumitNaiksatam | what say folks? | 18:02 |
| *** jthopkin has joined #openstack-meeting-3 | 18:02 | |
| enikanorov__ | yes, let's try | 18:03 |
| hemanthravi | ok | 18:03 |
| SumitNaiksatam | ok i am jumping there | 18:03 |
| *** SridarK has left #openstack-meeting-3 | 18:07 | |
| *** Sukhdev has quit IRC | 18:08 | |
| *** peristeri has quit IRC | 18:08 | |
| *** jtomasek has joined #openstack-meeting-3 | 18:15 | |
| *** Adri2000 has quit IRC | 18:26 | |
| *** s3wong_ is now known as s3wong | 18:27 | |
| *** Kanzhe has quit IRC | 18:43 | |
| *** johnthetubaguy has quit IRC | 18:46 | |
| *** julim has quit IRC | 18:47 | |
| *** Adri2000 has joined #openstack-meeting-3 | 18:48 | |
| *** Adri2000 has quit IRC | 18:48 | |
| *** Adri2000 has joined #openstack-meeting-3 | 18:48 | |
| *** hemanthravi has quit IRC | 18:48 | |
| *** jthopkin has quit IRC | 18:49 | |
| *** s3wong has quit IRC | 19:01 | |
| *** rkukura has left #openstack-meeting-3 | 19:02 | |
| *** hemanthravi has joined #openstack-meeting-3 | 19:02 | |
| *** MaxV has joined #openstack-meeting-3 | 19:10 | |
| *** rook has quit IRC | 19:19 | |
| *** MaxV has quit IRC | 19:20 | |
| *** saju_m has quit IRC | 19:21 | |
| *** MaxV has joined #openstack-meeting-3 | 19:22 | |
| *** saju_m has joined #openstack-meeting-3 | 19:23 | |
| *** sarob has joined #openstack-meeting-3 | 19:35 | |
| *** julim has joined #openstack-meeting-3 | 19:38 | |
| *** MaxV has quit IRC | 19:45 | |
| *** devlaps has quit IRC | 19:53 | |
| *** devlaps has joined #openstack-meeting-3 | 20:07 | |
| *** saju_m has quit IRC | 20:08 | |
| *** eguz has quit IRC | 20:08 | |
| *** eghobo has joined #openstack-meeting-3 | 20:08 | |
| *** saju_m has joined #openstack-meeting-3 | 20:08 | |
| *** MaxV has joined #openstack-meeting-3 | 20:13 | |
| *** MaxV has quit IRC | 20:13 | |
| *** eguz has joined #openstack-meeting-3 | 20:14 | |
| *** jthopkin has joined #openstack-meeting-3 | 20:14 | |
| *** lpetrut_ has quit IRC | 20:17 | |
| *** eghobo has quit IRC | 20:17 | |
| *** MaxV has joined #openstack-meeting-3 | 20:35 | |
| *** MaxV has quit IRC | 20:35 | |
| *** MaxV has joined #openstack-meeting-3 | 20:37 | |
| *** banix has quit IRC | 20:47 | |
| *** coolsvap has quit IRC | 20:51 | |
| *** lblanchard has quit IRC | 21:14 | |
| *** RajeshMohan has quit IRC | 21:17 | |
| *** mwagner__ has quit IRC | 21:17 | |
| *** RajeshMohan has joined #openstack-meeting-3 | 21:18 | |
| *** MaxV has quit IRC | 21:22 | |
| *** MaxV has joined #openstack-meeting-3 | 21:24 | |
| *** MaxV has quit IRC | 21:24 | |
| *** jthopkin has quit IRC | 21:27 | |
| *** saju_m has quit IRC | 21:28 | |
| *** mfer has quit IRC | 21:30 | |
| *** skath has quit IRC | 21:35 | |
| *** jtomasek has quit IRC | 21:45 | |
| *** SumitNaiksatam has quit IRC | 21:46 | |
| *** MaxV has joined #openstack-meeting-3 | 21:47 | |
| *** dhellmann is now known as dhellmann_ | 21:48 | |
| *** dguitarbite_ has joined #openstack-meeting-3 | 21:48 | |
| *** sarob has quit IRC | 21:48 | |
| *** sarob has joined #openstack-meeting-3 | 21:49 | |
| *** MaxV has quit IRC | 21:51 | |
| *** sarob_ has joined #openstack-meeting-3 | 21:53 | |
| *** sarob has quit IRC | 21:53 | |
| *** sarob_ is now known as sarob | 21:53 | |
| *** devlaps has quit IRC | 22:03 | |
| *** devlaps has joined #openstack-meeting-3 | 22:18 | |
| *** david-lyle has quit IRC | 22:19 | |
| *** mwagner__ has joined #openstack-meeting-3 | 22:42 | |
| *** SumitNaiksatam has joined #openstack-meeting-3 | 22:53 | |
| *** sarob has quit IRC | 23:00 | |
| *** sarob has joined #openstack-meeting-3 | 23:00 | |
| *** yamahata has quit IRC | 23:04 | |
| *** sarob has quit IRC | 23:05 | |
| *** sarob has joined #openstack-meeting-3 | 23:05 | |
| *** sarob has quit IRC | 23:31 | |
| *** sarob has joined #openstack-meeting-3 | 23:32 | |
| *** sarob has quit IRC | 23:36 | |
| *** MaxV has joined #openstack-meeting-3 | 23:37 | |
| *** mwagner_dontUseM is now known as mwagner | 23:56 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!