On 08/08/13 13:48, Giuseppe Vallarelli wrote: > ----- 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.
Yeah, I saw that discussion and I see Doron's point. I just wanna clarify that all 6 values would still be set as per those comments - but this assignment would be transparent to the users, unless they access the "advanced settings" (still not sure how that should be accessed). > > | 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. > I'm all for a different naming convention anyway, as we do not really provide network QoS at the moment - networks are DC-wide entities and we can't guarantee anything about what happens when packets leave the host. I actually think "Host Traffic Shaping" is pretty good, I would maybe call it "Host Traffic Control" because control is a simpler word to fathom than shaping. > > | 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
