----- Original Message ----- | From: "Lior Vernia" <[email protected]> | To: "Giuseppe Vallarelli" <[email protected]> | Cc: [email protected] | Sent: Monday, August 5, 2013 10:12:58 AM | Subject: Re: Network traffic shaping. | | Hey Giuseppe and everyone else,
Hello Lior, | | Sorry for being late to the party. I've read all the e-mails and have | been rolling the idea around in my head for a couple of days. Here are | my two main thoughts, more UX-oriented, let me know what you think. | | 1. I would prefer not to be able to create a host network QoS entity, | which doesn't really have any significance as an independent entity. | However, I would like to be able to copy the configuration from one host | to another for the same network, right? So how about we add a | "Copy/Clone from" UI field that lets you choose a host from which to | copy the QoS configuration for that network? | | This would appear next to the manual configuration, so users would still | be able to input other custom values if they prefer. Once we do this, we | also won't need to enable to define it on a per-network basis, where it | doesn't really make sense, but we could do with just defining it for | <host,network> pairs (i.e. say in the edit network dialog when attaching | a network to a host NIC). I like your idea and I think it's a good simplification overall. | To further clarify, copying/cloning would be INSTEAD OF creating a | Network QoS through some subtab, naming it, and then picking it in a | list box. There would be no way to create a named host network QoS | configuration. I thought it was the right approach simply because it's what have been implemented already in: http://www.ovirt.org/Features/Network_QoS (I'll refer to it as Network_QoS from now on) I didn't want to have 2 different ways to create what I would call simply QoS (the infamous 6 values) that can be applied a host network, vnic and so on. That's where the idea of associating a predefined Qos comes from. | 2. I would prefer to not have to fill six fields to define QoS. Even if | there are default values to these fields, it makes it look complicated. I'm completely with you on this - libvirt only requires the average attribute, burst and peak are optional, but again for uniformity of behaviour with Network_QoS I opted to have all 6 user defined. Perhaps the uniform behaviour is misplaced in this case, I thought that it might be confusing for the user to provide 6 values in Network_Qos and only one, average, for QoS but host network side. I discussed to have only one compulsory value in a different thread discussion "network and vnic qos" but Doron gave me a rationale (SLA related) for having all six values defined. | I think these six values could be replaced by just one typical value for | the network's traffic. The six-field configuration would still be | accessible somehow, but I don't want it to be necessary. +1 | | Regarding the empty values discussion, I'm not saying to leave the | values empty. I get why we want to fill them. But fill them ourselves in | some reasonable way that users won't be aware of unless they go into | advanced settings. | | An alternative might be to allow two values, one for inbound traffic and | another for outbound traffic. However, I think this would only be | necessary if a user wants to actually manage both inbound and outbound | traffic in detail, which sounds to me like the uncommon use case. In | general people would just want to avoid host traffic, either inbound or | outbound, being taken over by one network. That's a good idea. My only concern is how does it fit with QoS in the engine as a whole ? It's almost like we have different definitions of QoS, which might be fine but maybe we want to find a different naming convention. | And again, distinguishing | between inbound and outbound would still be accessible through some | advanced settings. | | Lior. Thanks for the contribute, hope my feedback will help. Giuseppe | | On 08/07/13 13:45, Giuseppe Vallarelli wrote: | > Hi everybody, I'm working to implement traffic shaping at the network level | > [1]. | > This feature is composed by two distinct parts: definition of traffic | > shaping | > for a logical network entity and optional redefinition of traffic shaping | > when | > the user is doing a Setup Host Networks task. Initial focus will be on | > first | > part. There are some points of contact with Network Qos [2] that's why I | > proposed | > to reuse some code backend side. | > | > Cheers, Giuseppe | > | > [1] http://www.ovirt.org/Features/Network_traffic_shaping | > [2] http://www.ovirt.org/Features/Network_QoS | > _______________________________________________ | > Arch mailing list | > [email protected] | > http://lists.ovirt.org/mailman/listinfo/arch | > | _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
