| *** banix has joined #openstack-meeting-3 | 00:03 | |
| *** jackib has joined #openstack-meeting-3 | 00:03 | |
| *** sarob has quit IRC | 00:04 | |
| *** zehicle_at_dell has joined #openstack-meeting-3 | 00:09 | |
| *** jackib has quit IRC | 00:09 | |
| *** banix has quit IRC | 00:11 | |
| *** seizadi has joined #openstack-meeting-3 | 00:18 | |
| *** markmcclain1 has quit IRC | 00:20 | |
| *** lenrow has quit IRC | 00:20 | |
| *** yamamoto has joined #openstack-meeting-3 | 00:24 | |
| *** garyduan has joined #openstack-meeting-3 | 00:29 | |
| *** yamamoto has quit IRC | 00:29 | |
| *** jackib has joined #openstack-meeting-3 | 00:29 | |
| *** seizadi has quit IRC | 00:30 | |
| *** sarob has joined #openstack-meeting-3 | 00:33 | |
| *** cjellick_ has joined #openstack-meeting-3 | 00:33 | |
| *** cjellick has quit IRC | 00:37 | |
| *** garyduan has quit IRC | 00:37 | |
| *** cjellick_ has quit IRC | 00:38 | |
| *** sarob has quit IRC | 00:43 | |
| *** sarob has joined #openstack-meeting-3 | 00:47 | |
| *** nati_ueno has quit IRC | 00:50 | |
| *** nati_ueno has joined #openstack-meeting-3 | 00:50 | |
| *** yamamoto has joined #openstack-meeting-3 | 00:51 | |
| *** mfer has quit IRC | 00:54 | |
| *** mfer has joined #openstack-meeting-3 | 00:55 | |
| *** Sukhdev has quit IRC | 00:59 | |
| *** mfer has quit IRC | 01:00 | |
| *** banix has joined #openstack-meeting-3 | 01:06 | |
| *** TravT has quit IRC | 01:06 | |
| *** zehicle_at_dell has quit IRC | 01:10 | |
| *** yamamoto has quit IRC | 01:12 | |
| *** jackib has quit IRC | 01:19 | |
| *** sarob has quit IRC | 01:36 | |
| *** sarob has joined #openstack-meeting-3 | 01:37 | |
| *** seizadi has joined #openstack-meeting-3 | 01:39 | |
| *** nati_ueno has quit IRC | 01:39 | |
| *** sarob has quit IRC | 01:42 | |
| *** seizadi has quit IRC | 01:53 | |
| *** sarob has joined #openstack-meeting-3 | 01:55 | |
| *** prad_ has quit IRC | 01:58 | |
| *** eghobo has quit IRC | 02:38 | |
| *** sankarshan_away is now known as sankarshan | 02:45 | |
| *** carl_baldwin has joined #openstack-meeting-3 | 02:46 | |
| *** banix has quit IRC | 02:51 | |
| *** kenhui has joined #openstack-meeting-3 | 02:53 | |
| *** banix has joined #openstack-meeting-3 | 03:15 | |
| *** nati_ueno has joined #openstack-meeting-3 | 03:19 | |
| *** ivar-lazzaro has quit IRC | 03:21 | |
| *** kenhui has quit IRC | 03:29 | |
| *** garyduan has joined #openstack-meeting-3 | 03:35 | |
| *** garyduan has quit IRC | 03:40 | |
| *** kenhui has joined #openstack-meeting-3 | 03:43 | |
| *** yamamoto has joined #openstack-meeting-3 | 03:54 | |
| *** eghobo has joined #openstack-meeting-3 | 03:55 | |
| *** kenhui has quit IRC | 03:57 | |
| *** kenhui has joined #openstack-meeting-3 | 03:59 | |
| *** amitpp has joined #openstack-meeting-3 | 03:59 | |
| *** kenhui has quit IRC | 04:06 | |
| *** seizadi has joined #openstack-meeting-3 | 04:10 | |
| *** zehicle_at_dell has joined #openstack-meeting-3 | 04:10 | |
| *** eghobo has quit IRC | 04:16 | |
| *** banix has quit IRC | 04:17 | |
| *** zehicle_at_dell has quit IRC | 04:20 | |
| *** zehicle_at_dell has joined #openstack-meeting-3 | 04:21 | |
| *** carl_baldwin has quit IRC | 04:26 | |
| *** sarob has quit IRC | 04:28 | |
| *** sarob has joined #openstack-meeting-3 | 04:28 | |
| *** sarob has quit IRC | 04:32 | |
| *** eghobo has joined #openstack-meeting-3 | 04:46 | |
| *** SumitNaiksatam has joined #openstack-meeting-3 | 04:49 | |
| *** sarob_ has joined #openstack-meeting-3 | 04:58 | |
| *** sarob_ has quit IRC | 05:02 | |
| *** coolsvap|afk is now known as coolsvap | 05:22 | |
| *** ivar-lazzaro has joined #openstack-meeting-3 | 05:25 | |
| *** ivar-lazzaro has quit IRC | 05:30 | |
| *** yamamoto has quit IRC | 05:32 | |
| *** nelsnelson has quit IRC | 05:32 | |
| *** eghobo has quit IRC | 05:38 | |
| *** eghobo has joined #openstack-meeting-3 | 05:38 | |
| *** zehicle_at_dell has quit IRC | 05:48 | |
| *** sarob has joined #openstack-meeting-3 | 05:58 | |
| *** sarob has quit IRC | 06:02 | |
| *** seizadi has quit IRC | 06:03 | |
| *** eguz has joined #openstack-meeting-3 | 06:06 | |
| *** eghobo has quit IRC | 06:10 | |
| *** ivar-lazzaro has joined #openstack-meeting-3 | 06:13 | |
| *** ivar-lazzaro has quit IRC | 06:18 | |
| *** yamamoto has joined #openstack-meeting-3 | 06:19 | |
| *** enykeev has joined #openstack-meeting-3 | 06:23 | |
| *** jcoufal has joined #openstack-meeting-3 | 06:54 | |
| *** mrunge has joined #openstack-meeting-3 | 07:10 | |
| *** eguz has quit IRC | 07:15 | |
| *** devvesa has joined #openstack-meeting-3 | 07:26 | |
| *** devvesa has left #openstack-meeting-3 | 07:26 | |
| *** zz_johnthetubagu is now known as johnthetubaguy | 07:59 | |
| *** sarob has joined #openstack-meeting-3 | 08:00 | |
| *** MaxV has joined #openstack-meeting-3 | 08:02 | |
| *** sarob has quit IRC | 08:04 | |
| *** nacim has joined #openstack-meeting-3 | 08:05 | |
| *** safchain has joined #openstack-meeting-3 | 08:24 | |
| *** ttrifonov_zZzz is now known as ttrifonov | 08:32 | |
| *** lsmola has joined #openstack-meeting-3 | 08:49 | |
| *** nati_ueno has quit IRC | 08:49 | |
| *** ttrifonov is now known as ttrifonov_zZzz | 08:51 | |
| *** lsmola has quit IRC | 08:52 | |
| *** yamamoto has quit IRC | 08:55 | |
| *** igordcard has joined #openstack-meeting-3 | 08:58 | |
| *** ttrifonov_zZzz is now known as ttrifonov | 08:59 | |
| *** ttrifonov is now known as ttrifonov_zZzz | 09:00 | |
| *** sarob has joined #openstack-meeting-3 | 09:00 | |
| *** ttrifonov_zZzz is now known as ttrifonov | 09:01 | |
| *** sarob has quit IRC | 09:05 | |
| *** ttrifonov is now known as ttrifonov_zZzz | 09:07 | |
| *** MaxV has quit IRC | 09:16 | |
| *** MaxV has joined #openstack-meeting-3 | 09:18 | |
| *** nati_ueno has joined #openstack-meeting-3 | 10:00 | |
| *** sarob has joined #openstack-meeting-3 | 10:02 | |
| *** nati_ueno has quit IRC | 10:05 | |
| *** sarob has quit IRC | 10:06 | |
| *** yamahata has quit IRC | 10:09 | |
| *** coolsvap is now known as coolsvap|afk | 10:28 | |
| *** MaxV_ has joined #openstack-meeting-3 | 10:37 | |
| *** MaxV has quit IRC | 10:37 | |
| *** sarob has joined #openstack-meeting-3 | 11:03 | |
| *** sarob has quit IRC | 11:08 | |
| *** ttrifonov_zZzz is now known as ttrifonov | 11:09 | |
| *** salv-orlando has quit IRC | 11:20 | |
| *** julim has joined #openstack-meeting-3 | 11:21 | |
| *** banix has joined #openstack-meeting-3 | 11:22 | |
| *** johnthetubaguy is now known as zz_johnthetubagu | 11:37 | |
| *** banix has quit IRC | 11:47 | |
| *** ttrifonov is now known as ttrifonov_zZzz | 11:58 | |
| *** sankarshan is now known as sankarshan_away | 12:02 | |
| *** sarob has joined #openstack-meeting-3 | 12:05 | |
| *** sarob has quit IRC | 12:09 | |
| *** amitpp has quit IRC | 12:16 | |
| *** zz_johnthetubagu is now known as johnthetubaguy | 12:18 | |
| *** erecio has joined #openstack-meeting-3 | 12:21 | |
| *** alexpilotti has joined #openstack-meeting-3 | 12:30 | |
| *** jackib has joined #openstack-meeting-3 | 12:39 | |
| *** nacim has quit IRC | 12:44 | |
| *** nacim has joined #openstack-meeting-3 | 12:44 | |
| *** MaxV_ has quit IRC | 12:45 | |
| *** MaxV has joined #openstack-meeting-3 | 12:47 | |
| *** erecio has quit IRC | 12:54 | |
| *** erecio has joined #openstack-meeting-3 | 12:55 | |
| *** sarob has joined #openstack-meeting-3 | 13:06 | |
| *** jackib has quit IRC | 13:10 | |
| *** sarob has quit IRC | 13:10 | |
| *** thomasem has joined #openstack-meeting-3 | 13:14 | |
| *** lblanchard has joined #openstack-meeting-3 | 13:15 | |
| *** nati_ueno has joined #openstack-meeting-3 | 13:15 | |
| *** mfer has joined #openstack-meeting-3 | 13:19 | |
| *** nacim has quit IRC | 13:37 | |
| *** banix has joined #openstack-meeting-3 | 13:40 | |
| *** jackib has joined #openstack-meeting-3 | 13:47 | |
| *** peristeri has joined #openstack-meeting-3 | 13:48 | |
| *** prad_ has joined #openstack-meeting-3 | 13:52 | |
| *** seizadi has joined #openstack-meeting-3 | 13:54 | |
| *** enykeev has quit IRC | 14:11 | |
| *** jaypipes is now known as leakypipes | 14:15 | |
| *** nati_ueno has quit IRC | 14:17 | |
| *** kenhui has joined #openstack-meeting-3 | 14:18 | |
| *** MaxV has quit IRC | 14:24 | |
| *** otherwiseguy has joined #openstack-meeting-3 | 14:25 | |
| *** MaxV has joined #openstack-meeting-3 | 14:26 | |
| *** seizadi has quit IRC | 14:26 | |
| *** seizadi has joined #openstack-meeting-3 | 14:27 | |
| *** nelsnelson has joined #openstack-meeting-3 | 14:32 | |
| *** seizadi has quit IRC | 14:35 | |
| *** thomasem has quit IRC | 14:38 | |
| *** dansmith is now known as superdan | 14:43 | |
| *** shakamunyi has joined #openstack-meeting-3 | 14:53 | |
| *** otherwiseguy has quit IRC | 14:58 | |
| *** mrunge has quit IRC | 14:59 | |
| *** carl_baldwin has joined #openstack-meeting-3 | 15:02 | |
| *** sarob has joined #openstack-meeting-3 | 15:03 | |
| *** salv-orlando has joined #openstack-meeting-3 | 15:03 | |
| *** jackib has quit IRC | 15:05 | |
| *** nacim has joined #openstack-meeting-3 | 15:05 | |
| *** thomasem has joined #openstack-meeting-3 | 15:09 | |
| *** cjellick has joined #openstack-meeting-3 | 15:16 | |
| *** cjellick has quit IRC | 15:16 | |
| *** cjellick has joined #openstack-meeting-3 | 15:16 | |
| *** otherwiseguy has joined #openstack-meeting-3 | 15:24 | |
| *** thomasem_ has joined #openstack-meeting-3 | 15:28 | |
| *** thomasem_ has quit IRC | 15:28 | |
| *** thomasem_ has joined #openstack-meeting-3 | 15:28 | |
| *** david-lyle has joined #openstack-meeting-3 | 15:29 | |
| *** thomasem has quit IRC | 15:30 | |
| *** nacim has quit IRC | 15:35 | |
| *** igordcard has quit IRC | 15:39 | |
| *** erw has quit IRC | 15:49 | |
| *** erw has joined #openstack-meeting-3 | 15:50 | |
| *** amitpp has joined #openstack-meeting-3 | 15:51 | |
| *** armax has joined #openstack-meeting-3 | 15:51 | |
| *** yamamoto has joined #openstack-meeting-3 | 15:51 | |
| *** pballand has joined #openstack-meeting-3 | 15:59 | |
| *** eghobo has joined #openstack-meeting-3 | 16:04 | |
| *** erecio has quit IRC | 16:04 | |
| *** eghobo has quit IRC | 16:04 | |
| *** eghobo has joined #openstack-meeting-3 | 16:05 | |
| *** johnthetubaguy is now known as zz_johnthetubagu | 16:05 | |
| *** devlaps has joined #openstack-meeting-3 | 16:11 | |
| *** jcoufal has quit IRC | 16:12 | |
| *** shakamunyi has quit IRC | 16:28 | |
| *** MaxV has quit IRC | 16:31 | |
| *** markmcclain has joined #openstack-meeting-3 | 16:36 | |
| *** otherwiseguy has quit IRC | 16:36 | |
| *** markmcclain1 has joined #openstack-meeting-3 | 16:37 | |
| *** markmcclain1 has quit IRC | 16:38 | |
| *** markmcclain1 has joined #openstack-meeting-3 | 16:39 | |
| *** markmcclain has quit IRC | 16:40 | |
| *** markmcclain1 has quit IRC | 16:46 | |
| *** safchain has quit IRC | 16:51 | |
| *** sarob has quit IRC | 16:52 | |
| *** zehicle_at_dell has joined #openstack-meeting-3 | 16:54 | |
| *** yamamoto_ has joined #openstack-meeting-3 | 16:55 | |
| *** ivar-lazzaro has joined #openstack-meeting-3 | 16:56 | |
| *** yamamoto_ has quit IRC | 16:57 | |
| *** ivar-lazzaro has quit IRC | 17:01 | |
| *** ivar-lazzaro has joined #openstack-meeting-3 | 17:04 | |
| *** markmcclain has joined #openstack-meeting-3 | 17:05 | |
| *** TravT has joined #openstack-meeting-3 | 17:05 | |
| *** zehicle_at_dell has quit IRC | 17:05 | |
| *** garyduan has joined #openstack-meeting-3 | 17:06 | |
| *** ijw has joined #openstack-meeting-3 | 17:12 | |
| *** thomasem has joined #openstack-meeting-3 | 17:13 | |
| *** MaxV has joined #openstack-meeting-3 | 17:15 | |
| *** yisun has joined #openstack-meeting-3 | 17:16 | |
| *** thomasem_ has quit IRC | 17:17 | |
| *** seizadi has joined #openstack-meeting-3 | 17:21 | |
| *** s3wong has joined #openstack-meeting-3 | 17:25 | |
| s3wong | #endmeeting | 17:26 |
|---|---|---|
| *** sarob has joined #openstack-meeting-3 | 17:27 | |
| mestery | Everyone here for the flavor meeting? | 17:29 |
| enikanorov | yep | 17:29 |
| mestery | enikanorov: Howdy! | 17:29 |
| enikanorov | hi Kyle! | 17:29 |
| banix | mestery: hi | 17:29 |
| markmcclain | hi | 17:29 |
| garyduan | Hi | 17:29 |
| SumitNaiksatam | hi | 17:30 |
| *** seizadi has quit IRC | 17:30 | |
| *** seizadi has joined #openstack-meeting-3 | 17:30 | |
| SumitNaiksatam | i will let people know on -neutron that we are having the meeting here | 17:30 |
| mestery | Looks like we have mostly a quorm, I'll get started then! | 17:30 |
| *** LouisF has joined #openstack-meeting-3 | 17:30 | |
| s3wong | hello | 17:30 |
| mestery | Going to put this meeting under the Adv Svcs banner show the logs show up there. | 17:30 |
| *** seizadi has quit IRC | 17:30 | |
| mestery | #startmeeting Networking Advanced Services | 17:30 |
| openstack | Meeting started Fri Jun 27 17:30:35 2014 UTC and is due to finish in 60 minutes. The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:30 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:30 |
| *** openstack changes topic to " (Meeting topic: Networking Advanced Services)" | 17:30 | |
| openstack | The meeting name has been set to 'networking_advanced_services' | 17:30 |
| mestery | #topic Flavor Framework Conclusions | 17:30 |
| *** openstack changes topic to "Flavor Framework Conclusions (Meeting topic: Networking Advanced Services)" | 17:30 | |
| mestery | Hopefully by now most people ahve read both proposals from enikanorov and markmcclain. | 17:31 |
| *** seizadi has joined #openstack-meeting-3 | 17:31 | |
| SumitNaiksatam | mestery: yes | 17:31 |
| mestery | What I'd like to see here is we come to an agreement on these which moves us forward for Juno. | 17:31 |
| SumitNaiksatam | markmcclain: thanks for posting yours | 17:31 |
| mestery | markmcclain: Yes, thanks for posting that! | 17:31 |
| dougwig | hi | 17:31 |
| *** andyshi_ has joined #openstack-meeting-3 | 17:31 | |
| SumitNaiksatam | mestery: +1 | 17:31 |
| markmcclain | sorry it took so long.. connectivity in west montana wasn't so good :) | 17:31 |
| mestery | I think banix and enikanorov made some good attempts at summarizing hte key differences between the proposals in comments on markmcclain's spec. | 17:32 |
| mestery | I think first of all, we're all in agreement we want flavors in Juno, right? :) | 17:32 |
| *** yamamoto has quit IRC | 17:32 | |
| SumitNaiksatam | mestery: yes! :-) | 17:32 |
| enikanorov | yes | 17:32 |
| garyduan | yes | 17:32 |
| SumitNaiksatam | mestery: +2, A | 17:33 |
| *** pgpus has joined #openstack-meeting-3 | 17:33 | |
| banix | yes | 17:33 |
| markmcclain | yes | 17:33 |
| mestery | I also think we need to move forward quickly on this, given where we're at and the time left, so something simple which can grwo in future releases makes sense. | 17:33 |
| mestery | After saying all that, where should we start on coming to a conclusion here? :) | 17:33 |
| markmcclain | yes time is critical here | 17:34 |
| *** sbalukoff has joined #openstack-meeting-3 | 17:34 | |
| enikanorov | the approaches are quite different, to me it doesn't seem that one is simpler then the other | 17:34 |
| *** xgerman has joined #openstack-meeting-3 | 17:34 | |
| enikanorov | so basically it's about doing something that could be easily extended later | 17:34 |
| SumitNaiksatam | should we first looks for things which are obvious and we certainly want to do as a first iteration? | 17:34 |
| SumitNaiksatam | *look | 17:35 |
| markmcclain | SumitNaiksatam: yes that was make approach when I stepped back last week to look at the problem anew | 17:35 |
| mestery | enikanorov: Agreed, something simple for now which allows for expansion in the future. | 17:35 |
| *** overlayer has joined #openstack-meeting-3 | 17:35 | |
| SumitNaiksatam | markmcclain: great! | 17:35 |
| markmcclain | s/make/my/ | 17:35 |
| *** vinay_yadhav has joined #openstack-meeting-3 | 17:36 | |
| SumitNaiksatam | so we have been all talking about differences, what are the common things between the two proposals? | 17:36 |
| SumitNaiksatam | is the user facing API consistent across the two | 17:36 |
| enikanorov | SumitNaiksatam: yes | 17:36 |
| enikanorov | it's flavor_id on the service instance | 17:36 |
| enikanorov | but that's integration part, I'd say | 17:36 |
| *** mandeep has joined #openstack-meeting-3 | 17:36 | |
| SumitNaiksatam | enikanorov markmcclain: so what the user sees as a part of the flavor definition is the same across both the proposals? | 17:37 |
| *** pcm_ has joined #openstack-meeting-3 | 17:37 | |
| enikanorov | SumitNaiksatam: that's no so similar | 17:37 |
| SumitNaiksatam | (i have read the proposals, but just want to make sure that we are all on teh same page here) | 17:37 |
| markmcclain | yeah we agree on attaching flavor_id to the logical service and also once it's bound dispatching calls directly to driver | 17:37 |
| enikanorov | in markmcclain's proposal user sees description, in my proposal user sees tags as more formal contract | 17:37 |
| SumitNaiksatam | markmcclain enikanorov: can we potentially add tags later as a second iteration enhancement? | 17:38 |
| markmcclain | enikanorov is correct, my proposal also exposes the set of API extensions available for a flavor (ie TLS, L7) | 17:38 |
| markmcclain | SumitNaiksatam: yes | 17:38 |
| enikanorov | extension list is questionable, imo | 17:38 |
| mestery | SumitNaiksatam: +1 | 17:38 |
| SumitNaiksatam | markmcclain: ok cool | 17:38 |
| enikanorov | why do coarse grained when we later move to fine grained? | 17:38 |
| sbalukoff | I think it's less questionable than tags. :P | 17:38 |
| enikanorov | the problem is that most drivers going to implement all extensions | 17:39 |
| enikanorov | if two drivers implement SSL, but different cyphers | 17:39 |
| enikanorov | ... | 17:39 |
| enikanorov | that's where tags help | 17:39 |
| dougwig | or the description. | 17:39 |
| enikanorov | that just one example of many | 17:39 |
| SumitNaiksatam | enikanorov: i think the claim is that coarse grain is currently simpler to achieve in Juno, but does not leave out the eventual path towards fine grained | 17:39 |
| mestery | SumitNaiksatam: +1 | 17:40 |
| xgerman | +1 | 17:40 |
| SumitNaiksatam | markmcclain: is that an accurate assessment? | 17:40 |
| enikanorov | considering implementation - it's not | 17:40 |
| markmcclain | We can always formalize the contract over time | 17:40 |
| *** jackib has joined #openstack-meeting-3 | 17:40 | |
| enikanorov | also, each author sees implementation of his proposal to be simpler :) | 17:40 |
| SumitNaiksatam | enikanorov: :-) | 17:40 |
| garyduan | I also agree tag will be difficult to control | 17:40 |
| *** natarajk has joined #openstack-meeting-3 | 17:41 | |
| enikanorov | the next thing is driver profiles | 17:41 |
| mestery | enikanorov: human nature :) | 17:41 |
| enikanorov | where metadata seem to be the same tags as in my proposal | 17:41 |
| garyduan | but I'd like to understand more how metadata works | 17:41 |
| garyduan | enikanorov: +1 | 17:41 |
| banix | enikanorov: would it be conceptually possible to think of profiles as a set of tags? | 17:41 |
| markmcclain | so metadata is a dict of driver specific parameters passed at driver init time | 17:41 |
| *** andyshi_ has quit IRC | 17:42 | |
| enikanorov | banix: yes, i think it's close | 17:42 |
| mestery | banix: That's kind of what I was thinking as well | 17:42 |
| enikanorov | so the problem for operator then that he needs to know driver specific details | 17:42 |
| markmcclain | the metadata is really designed to toggle behavior in a driver to match the profile's description/sla | 17:42 |
| banix | so can we agree on using the spec as teh vehicle for carrying the info, tags or metadata? | 17:42 |
| mandeep | banix: That is what I was thinking as well | 17:42 |
| sbalukoff | markmcclain: the idea being that drivers won't necessarily share the same specific parameters | 17:42 |
| dougwig | it could be just a set of tags, or it could configure the driver slightly different for each flavor (simple example, you tell driver A to use backend hosts 1-2 for flavor X and hosts 3-10 for flavor Y). | 17:42 |
| *** TravT has quit IRC | 17:42 | |
| sbalukoff | even if they are implementing the same "feature" | 17:42 |
| markmcclain | enikanorov: operators already know that info because most go through selection process when purchasing equipment | 17:43 |
| markmcclain | sbalukoff: +1 | 17:43 |
| enikanorov | markmcclain: right, but metadata should really be bound to implementation, e.g. code | 17:43 |
| markmcclain | dougwig: yes | 17:43 |
| garyduan | markmcclain: metadata is created by admin,right? | 17:43 |
| enikanorov | it's not purely ask-API-create-flavor | 17:43 |
| enikanorov | so it really requires introspection into how it's done on the inside | 17:44 |
| markmcclain | enikanorov: no it is configuration options or it could even be a pointer of where to read in config file | 17:44 |
| enikanorov | you can't just pass anything | 17:44 |
| markmcclain | garyduan: yes | 17:44 |
| enikanorov | yep, the pointer of where to read is better | 17:44 |
| sbalukoff | enikanorov: Why can't you just pass anything? | 17:45 |
| markmcclain | enikanorov: the operator does not have to read the code, just understand the init options a vendor might offer | 17:45 |
| enikanorov | but then it's just the same as to use tag from a flavor to do the same | 17:45 |
| garyduan | markmcclain: does driver need to expose anything? | 17:45 |
| mestery | markmcclain: This is similar to what they'd need to put in a config file when using the driver, right? | 17:45 |
| enikanorov | sbalukoff: because it makes no sense for the driver | 17:45 |
| markmcclain | ie pass ha=true at initialization time to ensure the backends creates pairs | 17:45 |
| enikanorov | markmcclain: ok, that's a tag. and it's on a profile | 17:45 |
| pgpus | whynot have two ways of specifiying service parameters tagOr metadata and point to a location where you can find key,vals or whateber minimum per service | 17:46 |
| markmcclain | garyduan: no drivers should not need to be aware of flavors at this time | 17:46 |
| sbalukoff | enikanorov: It does if the driver knows how to interpret the metadata passed to it. :P | 17:46 |
| enikanorov | so why not to put it on Flavor so user see it, formally? | 17:46 |
| markmcclain | mestery: yes | 17:46 |
| markmcclain | pgpus: two ways = confusion | 17:46 |
| ijw | I think the issue will be with tags that you have no formal description of what the tag means. Clearly it means a function is supported, but how do you document what that means in practice? | 17:46 |
| xgerman | ijw +1 | 17:46 |
| mestery | markmcclain: that makes sense to me. | 17:46 |
| SumitNaiksatam | ijw: but that problem is not solved | 17:46 |
| SumitNaiksatam | ijw: we now have the operator figure that out | 17:46 |
| sbalukoff | ijw: +1 | 17:47 |
| ijw | It's not the operator that cares: it's the tenant. | 17:47 |
| ijw | Extensions are self-documenting but per enikanorov's point they can't possibly catch nuances. | 17:47 |
| enikanorov | tags are self-descriptive via their names | 17:47 |
| markmcclain | enikanorov: it's not put on flavor because that exposes specific details of the implementation backend and may not be the same for multilple vendors | 17:47 |
| s3wong | ijw: but operators are the one exposing metadata here, right? | 17:47 |
| ijw | s3wong: yes, but wouldn't you like those tags to be cross-operator? | 17:47 |
| garyduan | I'd agree operator should define the tag or metadata | 17:47 |
| sbalukoff | s3wong: I don't think tenants get to see the metadata | 17:48 |
| enikanorov | markmcclain: yes, that's why specific details are kept in driver's config | 17:48 |
| markmcclain | ijw: standardizing the set of tags and letting everyone implement will take time | 17:48 |
| sbalukoff | s3wong: So that's not actually exposed to the tenant. | 17:48 |
| enikanorov | while on flavors only generic stuff like 'HA: True' is set | 17:48 |
| ijw | I mean, surely the point here is 'I want a service X supporting Y' and whoever I ask it of I get a service that suits my purposes. | 17:48 |
| garyduan | if he/she says the driver support L7, the drivers supports L7 | 17:48 |
| ijw | markmcclain: yup - I'm not really solving your problem, I'm trying to define it | 17:48 |
| s3wong | ijw: if tags are exposed by drivers, then driver-tags would be cross-operator | 17:48 |
| SumitNaiksatam | ok, can i summarize from a user facing API perspective, that the main difference between the two proposals is that in markmcclain’s proposal the meta-information is not exposed to the user, the operator configures that | 17:48 |
| SumitNaiksatam | where as in enikanorov’s proposal | 17:48 |
| SumitNaiksatam | it gets exposed as tags within the flavor | 17:48 |
| ijw | s3wong: only if drivers agree what those tags mean, and that's the definition issue I'm referring ot. | 17:48 |
| markmcclain | SumitNaiksatam: correct | 17:49 |
| enikanorov | tags are implementation-agnostic definitions of the service | 17:49 |
| SumitNaiksatam | and the user can choose the flavors based on the tags | 17:49 |
| s3wong | sbalukoff: right, but operator would need to set metadata as part of what features drivers can expose, thus a manual process | 17:49 |
| enikanorov | so no impl details sneak into flavor | 17:49 |
| SumitNaiksatam | markmcclain: ok | 17:49 |
| SumitNaiksatam | enikanorov markmcclain: hence my earlier suggestion, can we add tags as a second iteration enhancement | 17:49 |
| s3wong | ijw: that has always been the question on enikanorov 's proposal - that we as community would have to define some common tags per service type | 17:49 |
| SumitNaiksatam | enikanorov markmcclain: that way we can have the best of both proposals | 17:50 |
| sbalukoff | s3wong: Defining what products an operator wants to offer is going to be a manual process in any case. ;) | 17:50 |
| banix | SumitNaiksatam: right. so the difference is granulaity of what tenant sees; markmcclain shows well defined limitted number of extensions enikanorov shows fine grained properties | 17:50 |
| ijw | s3wong: and if they're common tags, are they not attributes of the implementation? | 17:50 |
| SumitNaiksatam | enikanorov markmcclain: we can start with somethin “simpler” | 17:50 |
| markmcclain | SumitNaiksatam: right tags can be added later once we have standard set | 17:50 |
| mestery | markmcclain SumitNaiksatam: +1 | 17:50 |
| *** pballand has quit IRC | 17:50 | |
| SumitNaiksatam | enikanorov: does that seem reasonable? | 17:50 |
| mestery | I think we need something simple for Juno at this stage. | 17:50 |
| s3wong | ijw: yes, they would be | 17:50 |
| enikanorov | i have a couple more questions | 17:51 |
| enikanorov | one is do we really need driver entry poins in driver profile? | 17:51 |
| *** otherwiseguy has joined #openstack-meeting-3 | 17:51 | |
| enikanorov | i think current provider framework can be used for this purpose | 17:51 |
| garyduan | enikanorov: same question here | 17:51 |
| pgpus | every service needs to be managed by driver so why not just expose managment parameter and leave alone vwndor variations and just provide basic defalt services we have like FW,LB, VPN etc | 17:51 |
| s3wong | sbalukoff: that's a fair point :-) | 17:51 |
| SumitNaiksatam | enikanorov: one sec | 17:51 |
| banix | enikanorov: let’s see if we can get an agreement on the API as SumitNaiksatam was suggesting | 17:51 |
| SumitNaiksatam | lets all first have agreement on the tenant facing API | 17:52 |
| SumitNaiksatam | banix: yeah | 17:52 |
| SumitNaiksatam | we will get to the admin side of the API in a but | 17:52 |
| SumitNaiksatam | bit | 17:52 |
| mandeep | SumitNaiksatam: +1 | 17:52 |
| SumitNaiksatam | enikanorov markmcclain mestery: what say? | 17:52 |
| enikanorov | well, not having tags on the flavor actually creates another question i was going to ask | 17:52 |
| mestery | SumitNaiksatam: I think we're close on this front, so yes. | 17:52 |
| markmcclain | I think from user perspective yes | 17:52 |
| SumitNaiksatam | mestery markmcclain: cool | 17:53 |
| SumitNaiksatam | enikanorov: whats your question | 17:53 |
| enikanorov | do we really need to associate flavor with driver profile | 17:53 |
| enikanorov | but it seems that if no tags - we have to do that | 17:54 |
| enikanorov | but scheduling would not make much sense then | 17:54 |
| markmcclain | enikanorov: right there has to be some kind of association layer | 17:54 |
| banix | enikanorov: yes. need the association. will still have a list of possible choices | 17:54 |
| enikanorov | because from flavor perspective there's no hint to use when choosing from associated profiles | 17:54 |
| markmcclain | which enables an operator to make a flavor to several possible backend implementation options | 17:54 |
| s3wong | enikanorov: it is a list of driver profile though, not really one to one mapping, so some sort of scheduling still needed, right? | 17:54 |
| enikanorov | but what would be the criteria other than random choice? | 17:55 |
| pgpus | Take the case of nova flavor did we really tie it to the drivers there? | 17:55 |
| markmcclain | enikanorov: german has pointed out that I had left weight off as an initial metric of the list | 17:55 |
| SumitNaiksatam | enikanorov: perhaps in the first iteration this will be limited without the hints/tags | 17:55 |
| * markmcclain pushed update with that | 17:55 | |
| SumitNaiksatam | markmcclain: do you agree ^^^? | 17:55 |
| enikanorov | yep, i've seen update with weight, but... | 17:55 |
| enikanorov | what does it solve? | 17:55 |
| enikanorov | are you going to get max weight each time? | 17:55 |
| markmcclain | s3wong: yes there is a selection call to bind flavor to a driver | 17:55 |
| ijw | Right, so to be clear, the question is: a tenant has requirements that are met by several available service implementations: what should happen. Is that right? | 17:56 |
| enikanorov | weight is actually a hardcoded kind of tag | 17:56 |
| *** pballand has joined #openstack-meeting-3 | 17:56 | |
| markmcclain | enikanorov: enables operator control to say set a preference that backend A should be preferred over backend B | 17:56 |
| enikanorov | *implementation A over B | 17:56 |
| sbalukoff | enikanorov: Not the same kind of tag that's in your proposal | 17:56 |
| enikanorov | sbalukoff: the same, indeed | 17:56 |
| markmcclain | pgpus: nova can still bind because of extra data for flavor | 17:57 |
| enikanorov | markmcclain: but how impl B is ever chosen? | 17:57 |
| enikanorov | it it's weight is lower | 17:57 |
| markmcclain | enikanorov: depends on selection algorithm | 17:57 |
| markmcclain | I've also intentionally kept it simple too | 17:57 |
| markmcclain | because I think that making a really good one is a great future BP :) | 17:58 |
| enikanorov | well, that's important, because simplest is random choice | 17:58 |
| garyduan | for example, round-robin in first release | 17:58 |
| s3wong | enikanorov: where there is no more resources for backend A? | 17:58 |
| ijw | No, actually simplest is offering the tenant the choice. | 17:58 |
| enikanorov | weighting scheduler need to consider capacity or something | 17:58 |
| enikanorov | s3wong: exactly | 17:58 |
| sbalukoff | Or weighted round robin | 17:58 |
| sbalukoff | Or weighted random choice. | 17:58 |
| SumitNaiksatam | enikanorov: i think its okay to have limitations in the first release | 17:58 |
| SumitNaiksatam | as long as we know what they are, and we have path towards evolution | 17:58 |
| mandeep | ijw: The tenant should have no view of resources, only logical entities after they have been scheduled | 17:59 |
| SumitNaiksatam | in this case the path is to to incoroporate tags | 17:59 |
| mestery | Folks: Scheduling needs to be dirt simple for Juno or this won't land, that's the reality at this point. | 17:59 |
| xgerman | mandeep +1 | 17:59 |
| pgpus | can you sggest what extra data for flvor is equivalent for neutron to tie it to neutron plugins? is it metadata/ | 17:59 |
| garyduan | if driver A has no resource, it can be feedback to plugin and select the next one | 17:59 |
| mestery | I don't want to rathole on scheduling here either. | 17:59 |
| enikanorov | i mean that's just a workarounds for the fact that 'naked flavor' is not a scheduling hint | 17:59 |
| sbalukoff | mestery: Good point. | 17:59 |
| mandeep | mestery: +1 | 17:59 |
| markmcclain | mestery: +1 scheduling is for Paris :) | 17:59 |
| mestery | markmcclain: :P | 17:59 |
| SumitNaiksatam | ok lets get an agreement here | 17:59 |
| SumitNaiksatam | hang folks | 18:00 |
| SumitNaiksatam | * hang on | 18:00 |
| SumitNaiksatam | i think its okay to have limitations in the first release | 18:00 |
| mestery | SumitNaiksatam: Whew, had me worried there ;) | 18:00 |
| enikanorov | as for something simple - I remember avishay's patch where he enabled driver to choose it's configuration based on provider name | 18:00 |
| SumitNaiksatam | as long as we know what they are, and we have path towards evolution | 18:00 |
| enikanorov | that's actually very close to what is called driver profile | 18:00 |
| mestery | SumitNaiksatam: +1 | 18:00 |
| SumitNaiksatam | in this case the path is to to incoroporate tags | 18:00 |
| SumitNaiksatam | as a future iteration | 18:00 |
| SumitNaiksatam | enikanorov markmcclain: can we agree? | 18:00 |
| SumitNaiksatam | this is in the context of the user/tenant facing API | 18:01 |
| markmcclain | SumitNaiksatam: +1 | 18:01 |
| SumitNaiksatam | markmcclain: great, enikanorov? | 18:01 |
| enikanorov | yep, as simple first step we may just introduce flavors layer on top of providers | 18:01 |
| pgpus | you service profile's path and that service prpofile will have tags? | 18:01 |
| SumitNaiksatam | enikanorov: i know this is not ideal | 18:01 |
| SumitNaiksatam | enikanorov markmcclain: nice | 18:01 |
| enikanorov | may be with just 1:1 and no scheduling and such | 18:01 |
| SumitNaiksatam | enikanorov: nice | 18:01 |
| enikanorov | markmcclain: how does it sounds? | 18:01 |
| enikanorov | then we could flush out what we really want from driver profiles | 18:02 |
| markmcclain | enikanorov: operators need more than 1:1 | 18:02 |
| enikanorov | markmcclain: sure | 18:02 |
| sbalukoff | markmcclain: +1 | 18:02 |
| enikanorov | but at least we'll get user-facing api more or less stable | 18:02 |
| enikanorov | and then extend this with other more advanced features | 18:03 |
| *** yamamoto has joined #openstack-meeting-3 | 18:03 | |
| *** lenrow has joined #openstack-meeting-3 | 18:03 | |
| enikanorov | in terms of implementation that seems to be the simplest. plus migration is also simple, as well as operators workflow | 18:03 |
| markmcclain | so service profiles are must | 18:04 |
| enikanorov | that's solvable with providers | 18:04 |
| markmcclain | because the mutli-vendor requirement why we started the who flavor discussion in the first place | 18:04 |
| *** otherwiseguy has quit IRC | 18:04 | |
| garyduan | I have questions about profile, but I want to wait until we get there :-) | 18:05 |
| enikanorov | markmcclain: so i agree, i'm just saying someone already impemented the idea very close to driver profiles | 18:05 |
| enikanorov | that coudl be reused and merged with flavors | 18:05 |
| pgpus | OK lets take a sample service profile for existing FW,LB,VPN as see if this makes sense | 18:05 |
| dougwig | enikanorov: sounds like you're agreeing about profiles, just not where to put them? | 18:05 |
| enikanorov | markmcclain: so we both get rid of provider attribute on the service instance, plus not too much changing the existing flow | 18:06 |
| *** dlenrow has joined #openstack-meeting-3 | 18:06 | |
| enikanorov | dougwig: i'm not opposed to profiles, just honestly it is possible right now with very small changes in the code | 18:06 |
| pgpus | What should a fw profile conatin like neutron firewall-list | 18:07 |
| pgpus | neutron firewall-policy-list | 18:07 |
| pgpus | neutron firewall-rule-list | 18:07 |
| enikanorov | that's however has another issues listed in markmcclain's proposal in the beginning, but with flavor layer it is solvable | 18:07 |
| *** jorgem has joined #openstack-meeting-3 | 18:07 | |
| garyduan | pgpus: firewall itself is the service instance | 18:07 |
| banix | sounds like we have reached an agreement. right? | 18:08 |
| pgpus | will flavor and proivder type be able to express these in profiles in terms of some unit of measure to say like weight vwe discussed for user to undertsand which profile they pickup? | 18:08 |
| *** yamamoto has quit IRC | 18:08 | |
| mestery | banix: Seems like it. | 18:08 |
| markmcclain | I think so | 18:08 |
| markmcclain | the one contention seems to be profiles | 18:09 |
| markmcclain | which are a evolved form of providers | 18:09 |
| enikanorov | markmcclain: I'm for using current workflow with keeping it in conf | 18:09 |
| enikanorov | at least for now | 18:09 |
| enikanorov | with flavors we are able to solve issues of providers | 18:10 |
| sbalukoff | I think there a benefits to keeping providers in the DB and not in conf. | 18:10 |
| sbalukoff | Er... not in conf files. | 18:10 |
| garyduan | enikanorov: are you saying 1:1 mapping between profile and driver? | 18:10 |
| enikanorov | profile:driver is N:1 | 18:10 |
| enikanorov | driver may have multiple profiles | 18:10 |
| pgpus | we will have to re-invent like ml2 an mlProfile | 18:10 |
| garyduan | that my question, | 18:11 |
| garyduan | Mark's spec says, metadata can be used by driver to behave differently | 18:11 |
| mandeep | enikanorov: it is more likely n:m - same profile may be provided by multiple drivers as well | 18:11 |
| SumitNaiksatam | mandeep: +1 | 18:11 |
| markmcclain | enikanorov: my only concern about keeping current provider conf is there's no operator control | 18:11 |
| sbalukoff | mandeep: Not if metadata is driver-specific | 18:12 |
| enikanorov | mandeep: that's more complex. not sure that would be easy with storing profiles in config | 18:12 |
| SumitNaiksatam | sbalukoff: that is just a special case | 18:12 |
| enikanorov | markmcclain: the control of what? | 18:12 |
| mandeep | SumitNaiksatam: exactly | 18:12 |
| s3wong | mandeep: oh really? if so, how is metadata passed - because that needs to be driver specific? | 18:12 |
| SumitNaiksatam | sbalukoff: mandeep’s suggestion for n:m includes that | 18:12 |
| markmcclain | which provider is selected | 18:12 |
| SumitNaiksatam | sbalukoff: n or m is 1! | 18:12 |
| enikanorov | markmcclain: how's it different from your proposal besides the fact that it is configured in conf, not by API? | 18:12 |
| markmcclain | the original reason we started with flavors months ago was the operator need for multi-vendor/multi-driver for same SLA | 18:13 |
| SumitNaiksatam | folks, sorry for interrupting | 18:13 |
| SumitNaiksatam | have we moved on from the user/tenant facing API discussion? | 18:13 |
| *** otherwiseguy has joined #openstack-meeting-3 | 18:13 | |
| sbalukoff | SumitNaiksatam: No, what I mean is, if the metadata in the profile is only meant to be interpreted by one driver, then that profile can only apply to one driver. Are y'all suggesting the metadata might be not driver-specific? | 18:13 |
| markmcclain | SumitNaiksatam: yes | 18:13 |
| SumitNaiksatam | sorry for repeating this over and over again | 18:13 |
| enikanorov | markmcclain: as we discussed, flavors associated with providers, which ae actually a driver profile | 18:13 |
| markmcclain | so I think we have agreement on user API | 18:13 |
| SumitNaiksatam | markmcclain: ok cool | 18:13 |
| s3wong | sbalukoff: that was my question above as well... to me it seems n:1 | 18:14 |
| SumitNaiksatam | mestery: can we summarize the agreement? | 18:14 |
| mandeep | s3wong: I expect that common profiles (say providing cookie rewriting), will be implemented by multiple backends. That is whjat allows you to reschedule a tenant to a new backend transparently | 18:14 |
| enikanorov | SumitNaiksatam: yep, i think so as well | 18:14 |
| banix | SumitNaiksatam: i think the only remaining question is driver in profile or not issue | 18:14 |
| SumitNaiksatam | enikanorov markmcclain: perhaps you can summarize | 18:14 |
| mestery | SumitNaiksatam: Yes, lets have enikanorov markmcclain summarize :) | 18:14 |
| markmcclain | so there's agreement that the user will select a flavor | 18:14 |
| enikanorov | that's for sure :) | 18:15 |
| SumitNaiksatam | :-) | 18:15 |
| *** cjellick has quit IRC | 18:15 | |
| markmcclain | flavor definition will include list of API extensions | 18:15 |
| markmcclain | the API extensions will be used to activate logic in teh server for configuring the logical model | 18:15 |
| *** cjellick has joined #openstack-meeting-3 | 18:15 | |
| enikanorov | not sure we need that... | 18:15 |
| SumitNaiksatam | markmcclain: the list of API extensions is in a user friendly form? | 18:15 |
| enikanorov | if API extension is not used for scheduling, then why have it? | 18:16 |
| markmcclain | SumitNaiksatam: about as friendly as our current /extensions endpoint :) | 18:16 |
| markmcclain | enikanorov: not all flavors will implement every API extension | 18:16 |
| SumitNaiksatam | markmcclain: ok may be i misunderstood that part, but i can go back to the spec | 18:16 |
| enikanorov | markmcclain: right, admin will need to write this in the description | 18:17 |
| garyduan | markmcclain: extension list seems informational to me | 18:17 |
| markmcclain | enikanorov, garyduan: it is | 18:17 |
| enikanorov | that's the same as with API aspects | 18:17 |
| markmcclain | mainly because the extensions should be defined in our API spec | 18:17 |
| garyduan | markmcclain: OK | 18:17 |
| enikanorov | markmcclain: also, the problem i see with this is the usage | 18:18 |
| markmcclain | ie the user knows that if TLS is enable these extra child resources are available for a service | 18:18 |
| markmcclain | enikanorov: what is the usage issue? | 18:18 |
| enikanorov | markmcclain: so say instance ID1 doesn't suport L7. user calls L7 on instance with ID1, API layer need to goo to DB and find out which extensions are enabled | 18:18 |
| enikanorov | to decide whether to forward rest call | 18:18 |
| enikanorov | or to reply with 404 or 400 | 18:19 |
| enikanorov | if that's what you're proposing, then it's not easy to do. but if we're not doing this, then we don't need extension list as a separate attribute | 18:19 |
| markmcclain | enikanorov: yep for service extensions that will be required | 18:19 |
| *** cjellick has quit IRC | 18:19 | |
| markmcclain | not every backend may implement an extension | 18:20 |
| enikanorov | yep, just raise unimplemented | 18:20 |
| markmcclain | also if we don't do this how do vendor differentiate? | 18:20 |
| markmcclain | enikanorov: except that as an operator | 18:20 |
| dougwig | how is a user going to call L7 on something that doesn't support it unless the operator has misconfigured their flavors/profiles? | 18:20 |
| enikanorov | they differentiate. on user-facing side, flavor descriptions are different | 18:20 |
| enikanorov | dougwig: well, user just calls... it should get reasonable error | 18:21 |
| enikanorov | 'not implemented' seems reasonable to me | 18:21 |
| markmcclain | enikanorov: an operator may want to make a driver that offers more features to a flavor that offers no features | 18:22 |
| markmcclain | s/no/few/ | 18:22 |
| enikanorov | i'm saying that extension list as an attribute is not extendible, if we want to declare API aspects in the future | 18:22 |
| sbalukoff | enikanorov: That's true... but I guess I'm still not following why markmcclain's proposal wouldn't be able to do that? What is the usage problem here? | 18:22 |
| markmcclain | enikanorov: it is extensible | 18:22 |
| mandeep | markmcclain: As a generic neutron question, we have the same issue of exposing APIs exposed by a driver to the tenant (say for ML2), so should we be exposing API extensions from drivers in a generic way, not in a service flavor specific way? | 18:22 |
| sbalukoff | "That's true" was meant to apply to the 'not implemented' error comment you said above. | 18:23 |
| enikanorov | i guess that's not about APIs exposed by drivers | 18:23 |
| enikanorov | it's about core service API that driver may not support | 18:23 |
| markmcclain | the operator ensures the deployed backends have support and then add extension to the list if they choose | 18:23 |
| enikanorov | anyway, flavor-based discpatching seems the complexity we would like to avoid | 18:24 |
| markmcclain | enikanorov: if we keep the core service API small then everyone should be able to support it | 18:24 |
| markmcclain | enikanorov: flavor based dispatching is not that difficult of a problem | 18:24 |
| *** kenhui has quit IRC | 18:24 | |
| enikanorov | i'd say it's not a step-1 task | 18:24 |
| markmcclain | mainly because the mechanics of dispatching usually involve retrieving teh flavor info | 18:25 |
| pgpus | can we describe falvor info for one service say fw to understand heer? | 18:25 |
| enikanorov | firewall has no extensions, i guess | 18:26 |
| enikanorov | garyduan: is that so? | 18:26 |
| markmcclain | pgpus: mind if I talk lbaas example case? | 18:26 |
| pgpus | OK lets take LB | 18:26 |
| garyduan | no ext. | 18:26 |
| enikanorov | so is vpn, i guess | 18:26 |
| sbalukoff | Well, there's also the problem of an extension "mostly" being supported: For example, if a particular implementation can support most of L7 in LBaaS, but there are one of two things it doesn't support within the L7 functionality, can it report that a given configuration is not implemented? | 18:26 |
| markmcclain | sbalukoff: right | 18:27 |
| enikanorov | sbalukoff: that may make sense for particular not supported attr. like unsupported cypher of certificate or something | 18:27 |
| pgpus | pool, member, protocol say http supported but not https does it make sense? | 18:28 |
| mestery | Folks, where are we at here? We're at an hour, and I'd like to ensure we wrap this up at some point. :) | 18:28 |
| sbalukoff | enikanorov: Yes | 18:28 |
| enikanorov | pgpus: there's not way with extension list to say 'i don't support https protocol' | 18:28 |
| pgpus | OK so flavor can be L7LBsimplehttp types | 18:28 |
| sbalukoff | mestery: Sorry for throwing a monkey-wrench into the clockwork. :P | 18:29 |
| enikanorov | pgpus: that goes down to a vervose description | 18:29 |
| mestery | We can't sit here all day discussing this, I'm sure most of us have backlogs that are huge at this point. :) | 18:29 |
| enikanorov | that's my point, extension list is not helping much, not to say dispatching based on it is not necessary | 18:29 |
| mestery | So moving forward, is there anything else that isn't agreed on? I lost track to be honest. :) | 18:29 |
| pgpus | OK I am trying to understand flavor in terms of am I drinking a Darjeeling tea or a colombian cofee | 18:29 |
| markmcclain | how to map flavor to driver is the point of contention | 18:29 |
| enikanorov | mestery: that's still about user api | 18:30 |
| SumitNaiksatam | the last i remember, markmcclain was summarizing what we agreed on | 18:30 |
| LouisF | can we get a merged proposal with examples to review? | 18:30 |
| markmcclain | but I really don't think it is that far off | 18:30 |
| s3wong | mestery: I think we are still on APIs - since we have disagreement on extensions | 18:30 |
| enikanorov | markmcclain: let's do it the way you proposed | 18:30 |
| enikanorov | at least for now | 18:30 |
| enikanorov | it's hidden from user anyway | 18:30 |
| markmcclain | enikanorov: right and then we can add advance capabilities as follow up work | 18:30 |
| mestery | markmcclain: +1 | 18:31 |
| mestery | enikanorov: +1 | 18:31 |
| sbalukoff | +1 | 18:31 |
| markmcclain | this will also break the dependency bottleneck the adv services are experiencing | 18:31 |
| mestery | markmcclain: HUGE +1 | 18:31 |
| sbalukoff | Yes! | 18:31 |
| garyduan | one more question | 18:31 |
| sbalukoff | Damn. | 18:31 |
| sbalukoff | ;) | 18:31 |
| garyduan | meta data in profile | 18:31 |
| banix | so the optimism of the other day was well founded :) | 18:31 |
| sbalukoff | It's drier specific! | 18:31 |
| sbalukoff | driver | 18:31 |
| garyduan | how is it used to make driver work differently? | 18:31 |
| markmcclain | garyduan: it's a vendor choice | 18:32 |
| markmcclain | a vendor could create a driver that require no additional metadata | 18:32 |
| markmcclain | so the operator would leave the field blank | 18:32 |
| sbalukoff | That is, vendor defines what metadata should look like and what the driver will understand, operator decides which metadata to put in there to enable which features. | 18:32 |
| * markmcclain envisions there will be vendors who do exactly that | 18:32 | |
| garyduan | vendor defines what meta data should look like ? | 18:33 |
| garyduan | where? | 18:33 |
| sbalukoff | And thus, vendors can differentiate, and operators control their product offerings. | 18:33 |
| markmcclain | garyduan: in their docs on how to deploy their solution | 18:33 |
| banix | mestery: i think converging to one spec as LouisF suggested would be great | 18:33 |
| garyduan | Ok. It's an external process. | 18:33 |
| markmcclain | garyduan: yes | 18:33 |
| sbalukoff | Yes! | 18:33 |
| garyduan | I agree | 18:33 |
| SumitNaiksatam | banix: i agree, one spec would be good | 18:34 |
| garyduan | then, multiple driver instances? | 18:34 |
| mandeep | banix: +1 | 18:34 |
| s3wong | garyduan: yeah, we talked about that a bit earlier too (as I had with sbalukoff) - that metadata is a manual process for operators | 18:34 |
| garyduan | Do we do dynamic loading? | 18:34 |
| mestery | markmcclain enikanorov: We need to move to one spec and continue the discussion there. | 18:34 |
| garyduan | of vendor driver? | 18:34 |
| mestery | At this point, I'm going to end this meeting (or pass chair to someone else). | 18:35 |
| markmcclain | garyduan: yes dynamic loading via entrypoint | 18:35 |
| mestery | enikanorov markmcclain: ^^^ Sound ok? | 18:35 |
| markmcclain | mestery: I've got a hard stop too | 18:35 |
| mestery | OK, lets move to one spec and continue the conversation there. | 18:35 |
| sbalukoff | Thanks, y'all! | 18:35 |
| mestery | I think at this point we're at "implementation detaiuls" anyways, and we coudl all stay here the rset of the day talking it feels like. :) | 18:35 |
| SumitNaiksatam | enikanorov markmcclain: thanks for indulging in this discussion | 18:35 |
| mestery | Thanks for joining folks! | 18:35 |
| s3wong | SumitNaiksatam: so we can skip talking about flavor during next week's adv service meeting? :-) | 18:35 |
| mestery | sbalukoff: +1 | 18:35 |
| enikanorov | markmcclain: salv-orlando would not be happy to do dynamic loading. at least he was no-no about that | 18:35 |
| SumitNaiksatam | s3wong: :-) | 18:36 |
| *** seizadi has quit IRC | 18:36 | |
| mestery | #endmeeting | 18:36 |
| *** openstack changes topic to "Services’ integration (Meeting topic: networking_policy)" | 18:36 | |
| openstack | Meeting ended Fri Jun 27 18:36:12 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:36 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-06-27-17.30.html | 18:36 |
| markmcclain | enikanorov: I'll follow up with salv-orlando | 18:36 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-06-27-17.30.txt | 18:36 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-06-27-17.30.log.html | 18:36 |
| *** mandeep has left #openstack-meeting-3 | 18:36 | |
| garyduan | dynamic loading of multiple instances of a vendor driver, .... | 18:36 |
| s3wong | garyduan: I quite honestly didn't see that from markmcclain 's spec, so you may want to comment on it on the spec | 18:37 |
| enikanorov | s3wong: i have commented on that | 18:37 |
| garyduan | s3wong: it is implied, | 18:37 |
| pgpus | are we co-relating between Service profile in conf to a generic or specific driver to load? | 18:38 |
| enikanorov | if driver profiles with entrypoint are pushed via API | 18:38 |
| markmcclain | s3wong: the entrypoint loading will mean different threads would instantiate different ones | 18:38 |
| enikanorov | then neutron need to load drivers dynamically | 18:38 |
| banix | s3wong: yes that is i,plied | 18:38 |
| *** pcm_ has left #openstack-meeting-3 | 18:38 | |
| garyduan | the driver has to take care many synchronization issues | 18:38 |
| enikanorov | that's one of the reasons to postpone this existing workflow | 18:39 |
| enikanorov | that's not only driver synchronization, it's also a security hole | 18:39 |
| markmcclain | garyduan: yes and many drivers do not functional well in the typical deployment of multiple neutron api servers and rpc worker processes | 18:39 |
| enikanorov | (potential, of course) | 18:39 |
| s3wong | enikanorov: yes, dynamic loading of driver seems like it needs to be a new feature for Neutron | 18:39 |
| pgpus | will we consider them simlar to type drivers of ml2? so service drivers are also mudular? | 18:40 |
| sbalukoff | Please add these comments to the spec, eh. | 18:40 |
| markmcclain | s3wong: we already support dynamic load | 18:40 |
| markmcclain | and have for sometime via entrypoints | 18:40 |
| enikanorov | markmcclain: where we do? | 18:40 |
| markmcclain | pgpus: yep | 18:40 |
| pgpus | ok | 18:40 |
| enikanorov | what is loaded dynamically? | 18:40 |
| garyduan | I posted a comment in #2 patch, do we really need dynamic loading or multiple instance? | 18:41 |
| markmcclain | mech drivers are loaded dynamically | 18:41 |
| markmcclain | garyduan: yes | 18:41 |
| markmcclain | I wanted to harmonize how drivers work to follow ml2 pattern of entrypoints | 18:41 |
| garyduan | If the driver exposes multiple entry points, basically, like different drivers | 18:42 |
| enikanorov | mechdrivers are loaded at startup | 18:42 |
| LouisF | markmcclain: so the driver entry points are specified in the config file? | 18:42 |
| garyduan | then, the plugin doesn't have to load multiple instances dynamically | 18:42 |
| markmcclain | enikanorov: they are still loaded dynamically :) | 18:42 |
| *** banix has quit IRC | 18:42 | |
| garyduan | I guess dynamically means loaded when user request the service | 18:43 |
| markmcclain | LouisF: I'm proposing that they are stored in the service profile in the database | 18:43 |
| garyduan | loaded = load it | 18:43 |
| s3wong | markmcclain: OK - that's the dynamic loading you talked about :-) | 18:43 |
| markmcclain | to make deployment consistency guaranteed | 18:43 |
| sbalukoff | Which is very important for large deployments. | 18:43 |
| enikanorov | markmcclain: yep, but know what i mean, we don't load attacker's code which attacker has pointed to via API :) | 18:43 |
| LouisF | markmcclain: i was refering to the ml2 mech drivers | 18:43 |
| enikanorov | *you | 18:44 |
| markmcclain | otherwise rolling configuration upgrades leave large deployments in inconsistent state | 18:44 |
| garyduan | if we load them at startup, we can use provider name, not entry points. Provider name is not shown to the tenant anyway. | 18:44 |
| sbalukoff | enikanorov: Given the operator is the one defining the profiles, are you worried about an attacker getting a hold of the operator's credentials/ | 18:44 |
| sbalukoff | ? | 18:44 |
| sbalukoff | If so, that operator has bigger problems. | 18:44 |
| *** Sukhdev has joined #openstack-meeting-3 | 18:45 | |
| *** banix has joined #openstack-meeting-3 | 18:45 | |
| markmcclain | ok.. I've got to run feel to free to leave additional questions on the review | 18:46 |
| markmcclain | thanks to everyone for discussing | 18:46 |
| garyduan | markmcclain: thanks | 18:46 |
| s3wong | markmcclain: thanks! | 18:46 |
| sbalukoff | Yes, thanks! | 18:46 |
| banix | bye all | 18:47 |
| enikanorov | sbalukoff: that's kinda lame excuse for the software with security issues :) | 18:48 |
| sbalukoff | enikanorov: I don't see this as any worse issue than someone having access to the host to add malicious code that gets loaded at boot. :P | 18:49 |
| *** lenrow has quit IRC | 18:50 | |
| enikanorov | remember that is an API, not an access to the host | 18:50 |
| sbalukoff | Right, and SSH is a network service, too. :P | 18:51 |
| pgpus | Are we expecting some updates to | 18:52 |
| pgpus | * Flavors API extension52 | 18:52 |
| pgpus | * Flavors persistence layer (DB plugin)53 | 18:52 |
| pgpus | * Common code for service plugins and drivers to support capabilities54 | 18:52 |
| pgpus | and scheduling.55 | 18:52 |
| sbalukoff | If there's a way to exploit the API that doesn't involve privileged access then that's a bug and should be dealt with as a bug. | 18:52 |
| pgpus | * DB migration | 18:52 |
| *** yamamoto has joined #openstack-meeting-3 | 18:52 | |
| *** erecio has joined #openstack-meeting-3 | 18:52 | |
| pgpus | I mean for security as you discuss here? | 18:52 |
| pgpus | OK what about key's provided by keystone before you can access API's does that not secure suffucientlY the Service APIs' | 18:54 |
| *** vinay_yadhav has quit IRC | 18:54 | |
| sbalukoff | pgpus: Are you asking? | 18:55 |
| pgpus | Yes to understand security issues you are pointing? | 18:55 |
| sbalukoff | Oh! So I think enikanorov is uncomfortable with the idea of dynamically loaded code. I'm pointing out that the admin / operator is the only one who can control which code gets loaded dynamically, and that this is actually not much different than the admin / operator determining which code gets loaded at start up time. | 18:56 |
| *** yamamoto has quit IRC | 18:56 | |
| sbalukoff | From mark's spec: | 18:57 |
| sbalukoff | The policy.json will be updated to allow all users to query the flavor146 | 18:57 |
| sbalukoff | listing and requst details about a specific flavor entry. All other REST147 | 18:57 |
| sbalukoff | points for create/update/delete operations will admin only. Additionally, the148 | 18:57 |
| sbalukoff | CRUD operations for Driver Profiles will be restricted to administrators.149 | 18:57 |
| sbalukoff | The policy.json will be updated to allow all users to query the flavor146 | 18:57 |
| sbalukoff | listing and requst details about a specific flavor entry. All other REST147 | 18:57 |
| sbalukoff | points for create/update/delete operations will admin only. Additionally, the148 | 18:57 |
| sbalukoff | CRUD operations for Driver Profiles will be restricted to administrators.149 | 18:57 |
| sbalukoff | The policy.json will be updated to allow all users to query the flavor146 | 18:57 |
| sbalukoff | listing and requst details about a specific flavor entry. All other REST147 | 18:57 |
| sbalukoff | points for create/update/delete operations will admin only. Additionally, the148 | 18:57 |
| *** sarob has quit IRC | 18:57 | |
| sbalukoff | CRUD operations for Driver Profiles will be restricted to administrators.149 | 18:57 |
| sbalukoff | The policy.json will be updated to allow all users to query the flavor146 | 18:57 |
| sbalukoff | listing and requst details about a specific flavor entry. All other REST147 | 18:57 |
| sbalukoff | points for create/update/delete operations will admin only. Additionally, the148 | 18:57 |
| sbalukoff | CRUD operations for Driver Profiles will be restricted to administrators. | 18:57 |
| sbalukoff | Dang it... sorry! | 18:57 |
| sbalukoff | Anyway, all CRUD operations in the API are controlled by an admin account. | 18:57 |
| sbalukoff | So, I don't see an issue. | 18:57 |
| sbalukoff | Though it should probably be noted in the spec that dynamic loading of code via the profiles is implied. | 18:58 |
| sbalukoff | (All CRUD operations having to do with profiles, I mean.) | 18:58 |
| *** LouisF has quit IRC | 18:58 | |
| *** mfer has quit IRC | 18:59 | |
| pgpus | OK so policy.json once managed by admin should reolve most of security issues | 18:59 |
| sbalukoff | That is my opinion. | 18:59 |
| pgpus | Good that helps | 18:59 |
| sbalukoff | Others should feel free to disagree with me and point out how I'm wrong. :) | 18:59 |
| *** amitpp has quit IRC | 18:59 | |
| *** seizadi has joined #openstack-meeting-3 | 19:00 | |
| pgpus | Mark's point was all deriver loading at init time can slow down service in a bulk operations, so load just in time is good, but still its secure as you pointed out | 19:01 |
| sbalukoff | Ok, I've gotta run off for a bit. Catch y'all later! | 19:02 |
| pgpus | I will leave now and will follow up on Flavor update as soon as that is put in BP and docs for design - thx | 19:02 |
| *** yamamoto has joined #openstack-meeting-3 | 19:03 | |
| *** ijw has quit IRC | 19:03 | |
| *** xgerman has quit IRC | 19:03 | |
| *** yisun has quit IRC | 19:04 | |
| *** seizadi has quit IRC | 19:04 | |
| *** yamamoto has quit IRC | 19:08 | |
| *** sarob has joined #openstack-meeting-3 | 19:09 | |
| *** zehicle_at_dell has joined #openstack-meeting-3 | 19:13 | |
| *** pballand has quit IRC | 19:16 | |
| *** terryw has joined #openstack-meeting-3 | 19:18 | |
| *** otherwiseguy has quit IRC | 19:18 | |
| *** dlenrow has quit IRC | 19:19 | |
| *** s3wong has quit IRC | 19:22 | |
| *** nati_ueno has joined #openstack-meeting-3 | 19:23 | |
| *** sarob has quit IRC | 19:24 | |
| *** kenhui has joined #openstack-meeting-3 | 19:24 | |
| *** sarob has joined #openstack-meeting-3 | 19:24 | |
| *** leakypipes has quit IRC | 19:25 | |
| *** jorgem has left #openstack-meeting-3 | 19:25 | |
| *** xgerman has joined #openstack-meeting-3 | 19:25 | |
| *** sarob has quit IRC | 19:29 | |
| *** zehicle_at_dell has quit IRC | 19:30 | |
| *** cjellick has joined #openstack-meeting-3 | 19:34 | |
| *** cjellick has quit IRC | 19:35 | |
| *** cjellick has joined #openstack-meeting-3 | 19:35 | |
| *** jackib has quit IRC | 19:38 | |
| *** HenryG_ has joined #openstack-meeting-3 | 19:40 | |
| *** yamahata_ has joined #openstack-meeting-3 | 19:42 | |
| *** amotoki_ has joined #openstack-meeting-3 | 19:43 | |
| *** amotoki has quit IRC | 19:43 | |
| *** yamahata__ has quit IRC | 19:43 | |
| *** HenryG has quit IRC | 19:43 | |
| *** zz_johnthetubagu has quit IRC | 19:43 | |
| *** mordred has quit IRC | 19:43 | |
| *** mordred has joined #openstack-meeting-3 | 19:43 | |
| *** erw has quit IRC | 19:44 | |
| *** natarajk has left #openstack-meeting-3 | 19:45 | |
| *** erw has joined #openstack-meeting-3 | 19:46 | |
| *** zz_johnthetubagu has joined #openstack-meeting-3 | 19:47 | |
| *** zz_johnthetubagu is now known as johnthetubaguy | 19:47 | |
| *** mfer has joined #openstack-meeting-3 | 19:51 | |
| *** prad_ has quit IRC | 20:02 | |
| *** david-lyle has quit IRC | 20:03 | |
| *** yamamoto has joined #openstack-meeting-3 | 20:03 | |
| *** david-ly_ has joined #openstack-meeting-3 | 20:04 | |
| *** terryw has quit IRC | 20:05 | |
| *** prad has joined #openstack-meeting-3 | 20:05 | |
| *** yamamoto has quit IRC | 20:08 | |
| *** jackib has joined #openstack-meeting-3 | 20:08 | |
| *** erecio has quit IRC | 20:09 | |
| *** salv-orlando has quit IRC | 20:15 | |
| *** shakamunyi has joined #openstack-meeting-3 | 20:15 | |
| *** HenryG_ has quit IRC | 20:21 | |
| *** HenryG_ has joined #openstack-meeting-3 | 20:21 | |
| *** yamahata_ has quit IRC | 20:21 | |
| *** yamahata_ has joined #openstack-meeting-3 | 20:21 | |
| *** erw has quit IRC | 20:21 | |
| *** erw has joined #openstack-meeting-3 | 20:21 | |
| *** prad has quit IRC | 20:21 | |
| *** prad has joined #openstack-meeting-3 | 20:21 | |
| *** shakamunyi has quit IRC | 20:22 | |
| *** shakamunyi has joined #openstack-meeting-3 | 20:22 | |
| *** salv-orlando has joined #openstack-meeting-3 | 20:23 | |
| *** otherwiseguy has joined #openstack-meeting-3 | 20:28 | |
| *** nati_ueno has quit IRC | 20:28 | |
| *** peristeri has quit IRC | 20:35 | |
| *** kenhui has quit IRC | 20:37 | |
| *** nati_ueno has joined #openstack-meeting-3 | 20:39 | |
| *** pballand has joined #openstack-meeting-3 | 20:41 | |
| *** Sukhdev has quit IRC | 20:45 | |
| *** nati_ueno has quit IRC | 20:50 | |
| *** nati_ueno has joined #openstack-meeting-3 | 20:50 | |
| *** coolsvapl has joined #openstack-meeting-3 | 20:51 | |
| *** lblanchard has quit IRC | 20:51 | |
| *** johnthetubaguy has quit IRC | 20:52 | |
| *** coolsvap|afk has quit IRC | 20:52 | |
| *** zehicle has quit IRC | 20:52 | |
| *** johnthetubaguy has joined #openstack-meeting-3 | 20:57 | |
| *** jackib has quit IRC | 20:58 | |
| *** zehicle has joined #openstack-meeting-3 | 20:58 | |
| *** johnthetubaguy has quit IRC | 20:58 | |
| *** banix has quit IRC | 21:01 | |
| *** tylerdurden has joined #openstack-meeting-3 | 21:02 | |
| *** johnthetubaguy has joined #openstack-meeting-3 | 21:02 | |
| *** thomasem has quit IRC | 21:02 | |
| *** yamamoto has joined #openstack-meeting-3 | 21:03 | |
| *** shakamunyi has quit IRC | 21:05 | |
| *** shakamunyi has joined #openstack-meeting-3 | 21:11 | |
| *** mfer has quit IRC | 21:11 | |
| *** yamamoto has quit IRC | 21:11 | |
| *** tylerdurden has quit IRC | 21:12 | |
| *** Adri2000 has quit IRC | 21:13 | |
| *** alexpilotti has quit IRC | 21:13 | |
| *** alexpilotti has joined #openstack-meeting-3 | 21:14 | |
| *** david-ly_ has quit IRC | 21:14 | |
| *** Adri2000 has joined #openstack-meeting-3 | 21:14 | |
| *** notmyname has quit IRC | 21:14 | |
| *** Adri2000 is now known as Guest34731 | 21:15 | |
| *** notmyname has joined #openstack-meeting-3 | 21:17 | |
| *** gduan has joined #openstack-meeting-3 | 21:23 | |
| *** zigo_ has joined #openstack-meeting-3 | 21:24 | |
| *** david-lyle has joined #openstack-meeting-3 | 21:27 | |
| *** pballand has quit IRC | 21:29 | |
| *** Guest34731 has quit IRC | 21:31 | |
| *** erw has quit IRC | 21:31 | |
| *** garyduan has quit IRC | 21:31 | |
| *** markmcclain has quit IRC | 21:31 | |
| *** edleafe has quit IRC | 21:31 | |
| *** wendar has quit IRC | 21:31 | |
| *** dolphm has quit IRC | 21:31 | |
| *** russellb has quit IRC | 21:31 | |
| *** vishy has quit IRC | 21:31 | |
| *** zigo has quit IRC | 21:31 | |
| *** briancurtin has quit IRC | 21:31 | |
| *** ttx has quit IRC | 21:31 | |
| *** abramley has quit IRC | 21:31 | |
| *** abramley has joined #openstack-meeting-3 | 21:32 | |
| *** pballand has joined #openstack-meeting-3 | 21:36 | |
| *** sarob has joined #openstack-meeting-3 | 21:43 | |
| *** nelsnelson has quit IRC | 21:53 | |
| *** yamamoto has joined #openstack-meeting-3 | 22:03 | |
| *** yamamoto has quit IRC | 22:08 | |
| *** jackib has joined #openstack-meeting-3 | 22:25 | |
| *** alexpilotti has quit IRC | 22:26 | |
| *** armax has quit IRC | 22:38 | |
| *** prad has quit IRC | 22:43 | |
| *** zehicle_at_dell has joined #openstack-meeting-3 | 22:44 | |
| *** otherwiseguy has quit IRC | 22:51 | |
| *** rhagarty has quit IRC | 22:54 | |
| *** jackib has quit IRC | 22:55 | |
| *** shakamunyi has quit IRC | 22:56 | |
| *** shakamunyi has joined #openstack-meeting-3 | 22:56 | |
| *** zehicle_at_dell has quit IRC | 22:58 | |
| *** devlaps has quit IRC | 22:59 | |
| *** sarob has quit IRC | 23:00 | |
| *** rhagarty has joined #openstack-meeting-3 | 23:01 | |
| *** sarob has joined #openstack-meeting-3 | 23:01 | |
| *** yamamoto has joined #openstack-meeting-3 | 23:03 | |
| *** ivar-lazzaro has quit IRC | 23:04 | |
| *** sarob has quit IRC | 23:05 | |
| *** david-lyle has quit IRC | 23:05 | |
| *** zehicle_at_dell has joined #openstack-meeting-3 | 23:07 | |
| *** david-lyle has joined #openstack-meeting-3 | 23:07 | |
| *** yamamoto has quit IRC | 23:08 | |
| *** nati_ueno has quit IRC | 23:09 | |
| *** nati_ueno has joined #openstack-meeting-3 | 23:10 | |
| *** david-lyle has quit IRC | 23:11 | |
| *** ivar-lazzaro has joined #openstack-meeting-3 | 23:18 | |
| *** sarob has joined #openstack-meeting-3 | 23:24 | |
| *** armax has joined #openstack-meeting-3 | 23:27 | |
| *** xgerman has quit IRC | 23:32 | |
| *** sarob has quit IRC | 23:38 | |
| *** sarob has joined #openstack-meeting-3 | 23:39 | |
| *** sarob has quit IRC | 23:43 | |
| *** shakamunyi has quit IRC | 23:47 | |
| *** seizadi has joined #openstack-meeting-3 | 23:52 | |
| *** MaxV has quit IRC | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!