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