14:07:21 #startmeeting neutron_qos 14:07:22 Meeting started Wed Apr 15 14:07:21 2015 UTC and is due to finish in 60 minutes. The chair is ajo. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:07:24 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:07:26 The meeting name has been set to 'neutron_qos' 14:08:14 ok, from my last emails you will see I got very confused with timeslots / timezones and meetings 14:09:21 we will be overlapping with the TWG every two weeks, may be it's good enough and we just need to pick the right room 14:09:54 it will be good to update the link as well - https://wiki.openstack.org/wiki/Meetings#Neutron_QoS_meeting 14:09:57 we could also move the meeting 30m later, and not overlap partially... let's talk about it on list 14:10:42 #action ajo update the meeting room in https://wiki.openstack.org/wiki/Meetings#Neutron_QoS_meeting 14:11:12 ganeshna, vikram , did you have time to read the old specs on QoS? 14:11:24 ok i can do 14:11:49 am fairly new, submitted my first patch just today 14:11:57 :D 14:12:00 welcome ganeshna :) 14:12:04 i went through it once.. 14:12:04 thanks :) 14:12:16 #link https://etherpad.openstack.org/p/neutron-qos-agenda 14:12:27 I'm trying to put up an agend for the next week 14:12:33 agenda 14:12:50 the original spec by sc68cal is here: http://review.openstack.org/#/c/88599/6 14:13:26 basically, the idea, at that stage was to create "QoS" objects, which could be associated with ports or networks 14:13:40 with a policy dictionary, describing the settings. 14:14:13 IMO this is limited 14:14:21 and I would like to propose something a bit more elaborated, 14:14:37 having QoS objects, with 1:N QoSPolicies 14:14:59 or QoSRules may be it's a more appropriate name if looking into the future. 14:15:25 the idea is that you could, this way, put several polices together into a QoS configuration 14:16:05 ajo : +1 14:16:14 also, in the future, 14:16:25 +1 14:16:38 we could extend QoSPolicies to match on protocol fields, and this way we would be providing traffic classification 14:16:58 not sure if QoSPolicy with 1:N QoSRules is more correct 14:16:58 ajo: I also feel the scope is limited and only the translation of IP TOS field is being done 14:17:21 vikram, the original spec also talks about bandwidth limiting 14:17:41 types could be added, and policy definitions could be extended 14:17:58 ok 14:17:58 but for example you couldn't put both together easily 14:18:47 also I'd like to understand how the flavor famework is supposed to work 14:18:57 framework :) 14:19:13 I've read the specs but I don't understand the use cases yet. 14:19:59 ajo : I think the use case is to hide the implementation of services to the tenant 14:20:30 ping salv-orlando: ^ 14:20:57 we still have open questions, 14:20:59 for example, 14:21:19 who's able to create QoS policies, I guess a good start is "admin only" 14:21:48 ajo : a gold FWaas service can be implemented by firewall A, but the cloud admin can decide later to implement it wit firewall B, the cloud change the implementation but it is trnasparent to the tenant which still uses a Qos Flavor for its firewall service 14:22:21 hi irenab :) 14:22:28 ajo : at least it's the way I see it :) 14:23:47 ajo : It's the same for Qos, a gold QOS might evolve in the time, but it must be transparent for the end user 14:23:57 aha 14:24:49 ok, so, considering that, it's still transparent, as long as we implement QoS, then tenants could reference flavors instead of QoS policies directly, right? 14:25:31 matrohon: so I guess, we may work at implementing QoS first, and then doing integration with flavors? 14:25:38 ajo : that's might understanding yes... 14:26:02 matrohon: thanks, I will ask dougwig to read our conversation and confirm we're getting it right 14:26:27 ajo: I feel policy control should be tied with the flavor.. Otherwise how to apply QoS for some specific traffic? 14:26:27 other gaps we have: 14:26:50 ajo : It might be more reasonable, Qos is hard enough to not burden the debate with flavors discussions :) 14:27:25 +1 I agree with matrohon here, if we could integrate with flavors later, may be it's a good start to keep it simple 14:27:44 if a bad implementation would prevent a later flavor integration, then we should look at it from the start. 14:27:58 vikram, do you mean nova flavors? 14:28:03 +1 for matrohon.. Let's keep it simple for now. 14:28:19 I believe nova and neutron flavors are different things 14:28:32 ajo: I meant QoS flavors 14:29:27 at current stage, the proposal is that we have specific API calls to tie QoS definitions to ports, or to networks 14:29:35 where network = all ports created in network 14:30:14 there are more complicated interpretation as for example "limiting the whole amount of bandwidth a network can use as a whole" but those cases I guess are not resolved in generall :) 14:30:39 that opens another question (from the gaps)... 14:31:09 1) If we want to stick a tenant to a QoS profile how do we do it? 14:32:27 for example, one tenant contracted "Bronze", and we want all his traffic to stay in a certain QoS 14:32:41 vikram, matrohon ^ 14:33:05 ajo : In the current proposal, Qos profile is assigned to a tenant, am I wrong? 14:33:39 matrohon, that's only because every object in neutron belongs to a tenant 14:33:44 it could be the admin 14:34:07 at the point we would be able to allow tenants creating QoS profiles, we may need some sort of ACLs in place, 14:34:27 like limiting bandwidth min/max on limiting, or types of DSCP / IPv6 marks... 14:34:31 ajo: I feel this should be done at the ML2 layer. As for example, if we use OVS for example then appropriate flow rules should be downloaded. 14:34:37 otherwise a tenant could override admin settings 14:34:57 vikram, yes, that's the dataplane implementation, we can do that there, but I mean 14:35:17 ajo : It doesn't impact the visibility of the Qos object by the tenant? I understood that Qos object creation was admin only! 14:35:18 in the current definition, we don't have a way to make sure every net / port a tenant creates, is associated with a certain QoS 14:35:36 ajo: hi 14:35:36 we have to go via API and tie the port/net to the QoS profile 14:35:50 hi irenab :) 14:36:18 I guess that depends on how we configure them I could be getting it wrong 14:36:48 ajo : you mean the policy.json? 14:36:57 yes, I was looking at there now 14:37:09 matrohon, one example are the external networks, 14:37:31 are they marked as shared to be seen by tenants, or are those seen because policy.json allows it? 14:38:21 no, they are shared: False 14:38:27 I just checked 14:39:01 "get_network": "rule:admin_or_owner or rule:shared or rule:external or rule:context_is_advsvc", 14:39:13 rule:external 14:39:36 Another open question 14:40:05 2) How do we configure which QoS profiles are available to specific tenants... 14:40:18 ajo : ok, so tenant can see it but cannot create it 14:40:53 ajo: for your second question, is it required for initial impementation? 14:40:59 matrohon, I believe we need also some sort of ACL in place to let tenants pick some QoS's and not others 14:41:04 ajo : that the purpose of RBAC 14:41:05 irenab: probably not 14:41:15 matrohon: +1 14:41:32 irenab: as long as we can improve it in the future, we can do it on next cycles 14:41:36 ajo : we have exactly the same issue with network : they are shared or tenant only 14:41:39 matrohon, irenab RBAC? 14:41:49 RBAC is supposed to solve the issue 14:42:02 * matrohon looking for the spec 14:42:18 https://review.openstack.org/#/c/132661/ 14:42:21 ajo: my understanding that making some entity available to specific tenants is self contained system (RBAC) 14:42:31 ok, if we will have a generic way to solve this, it would be perfect 14:43:14 while need to look into details of this spec, it seems this should be probably generalized for other objects 14:43:16 #topic ACLs for QoS 14:43:21 ajo: +1 14:43:32 irenab, yes +1 14:43:34 it totally makes sense 14:43:57 we shouldn't be reinventing wheels 14:45:16 yet, irenab, if we wanted to make an specific association of a tenant objects to a QoS by default, 14:45:35 may be we would need another db model to do it... 14:45:41 may be something to be left for next cycles too 14:45:49 ajo: agree 14:46:06 irenab, I guess you missed my first dissertation: I have notes here: https://etherpad.openstack.org/p/neutron-qos-agenda 14:46:28 I was proposing to break down the proposed QoS model in two objects, as we discussed +/- 14:46:46 but this does not look different from something like ‘This router can be used by this list of Tenant’ 14:47:27 irenab, well, I'm more talking about "this QoS will be applied to this tenant ports wether he wants or not" 14:47:40 like enforcing because the tenant contracted one level of service or another with the cloud, 14:47:49 or because the application type he's serving is in one category or another 14:48:27 but for the visibility, and available QoS's yet, it's like the router example , and great if we will be able to solve it via RBAC 14:48:29 ajo: this sounds reasonable requirement. I think we just need to see if want to support this as part of the initial implementation 14:48:34 matrohon, where you able to find the spec? 14:48:48 ajo : https://review.openstack.org/#/c/132661/ 14:48:57 the RBAC spec : ^ 14:49:11 #link https://review.openstack.org/#/c/132661/ 14:49:58 yes, we should help them extend roled based access control not only for networks, but in general 14:50:13 ajo : +1 14:50:29 ajo: +1 14:50:47 ajo : Fot the moment I'm not sure the tenant needs to be specified 14:50:59 #action ajo talk to kevinbenton about RBAC spec https://review.openstack.org/#/c/132661/ , for extending it into a more generic access control 14:51:23 the Qos object can be created by the cloud admin, and consummed by the tenant for it's network/port 14:51:39 ajo: lets also add this concern on spec patch review 14:51:57 irenab, I will 14:52:09 matrohon: maybe need some ‘shared’ field to enable it 14:52:48 irenab, we could do it regardless of the shared flag 14:52:57 if we configure policy.json properly 14:53:19 irenab, this is what we have for networks: "get_network": "rule:admin_or_owner or rule:shared or rule:external or rule:context_is_advsvc", 14:53:25 ajo: right, but maybe this should be configurable per qos policy 14:53:29 when it's shared, anybody can access to it 14:53:43 irenab, true 14:53:57 may be one use case can be all QoS's belong to admin, 14:54:06 and he's in charge of setting the QoS on specific ports or networks 14:54:09 irenab : yep, and for thos Qos obj with shared field, then the tenant can dynamically attach its ports to the Qos 14:54:12 without the specific tenant intervention 14:54:21 ajo: right 14:54:35 may be it's good enough as a start 14:54:45 ajo : ok 14:54:51 +1 14:55:09 may be we could define a list of use cases and see which ones are we covering , and which ones aren't we, for a first iteration 14:55:33 ajo : It seems fair to hink about the Qos usage for the Cloud admin first 14:55:43 ajo: sounds like a plan 14:55:43 ok we are near to the top of the hour. 14:55:46 yes 14:55:51 matrohon, irenab ++ 14:55:52 ajo: good idea. this will ensure we don't miss later. 14:56:27 #action ajo include a set of use cases in the QoS spec to explain what we plan to cover, and what we don't plan to cover for a first iteration. 14:56:30 ajo: we may use etherad to put use cases there, later transform it to the spec 14:56:57 #topic QoS use cases 14:56:59 #link https://etherpad.openstack.org/p/neutron-qos-use-case 14:57:06 #link https://etherpad.openstack.org/p/neutron-qos-use-cases 14:57:08 sorry :) 14:57:19 not sure if we have some sort of un-do's 14:57:29 :-) 14:57:58 feel free to fill in use cases we can think of 14:58:28 ok, shall we close this meeting? :) 14:58:50 1min left :) 14:59:39 ajo: do we have meeting next week? 14:59:49 irenab, vikram , matrohon , ganeshna 14:59:52 thanks for joining 14:59:53 timing? 14:59:57 irenab, yes, 15:00:02 #endmeeting