[Engine-devel] clean testable code
Talking with my teammates I've noticed that there is some confusion related to what testing means and in general how tests can improve the quality of the codebase by favouring the development of components that are of higher quality - unluckily it doesn't favour hair regrowing. Tests are also cool because when done right they represent an executable form of documentation. Some intro material: 1 How to Write Clean, Testable Code by Miško Hevery (A Googler) http://www.youtube.com/watch?v=XcT4yYu_TTs 2 How to write testable code by Miško Hevery (hands on ;-)) http://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf Examples are provided in Java but the same principles apply to Python as well. 3 TDD by James Shore (a practice created by Kent Beck) http://www.jamesshore.com/Agile-Book/test_driven_development.html A broad article explaining TDD and related concepts. 4 Difference between state based testing and interaction based testing http://martinfowler.com/articles/mocksArentStubs.html Not so intro - but easier to understand after consuming previous material: 5 Mock Roles, not Objects by Freeman and Pryce http://jmock.org/oopsla2004.pdf They both wrote a very interesting book: Growing Object Oriented Software: Guided by Tests http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627/ref=cm_cr_pr_product_top I didn't read it yet. Points from 3 to 5 mostly describe a different kind of working practice, which is very opinionated but nevertheless with some interesting ideas. I consider points 1-2 fundamentals. Enjoy, Giuseppe I will share new materials if there's some interest on it. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Proposal for new commit msg design for engine commits
- Original Message - | From: Eyal Edri ee...@redhat.com | To: Fabian Deutsch fabi...@redhat.com | Cc: engine-devel engine-devel@ovirt.org, infra in...@ovirt.org | Sent: Thursday, July 11, 2013 10:57:31 AM | Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits | | | | - Original Message - | From: Fabian Deutsch fabi...@redhat.com | To: Eyal Edri ee...@redhat.com | Cc: Alon Bar-Lev alo...@redhat.com, engine-devel | engine-devel@ovirt.org, infra in...@ovirt.org | Sent: Thursday, July 11, 2013 11:41:24 AM | Subject: Re: [Engine-devel] Proposal for new commit msg design for engine | commits | | Am Mittwoch, den 10.07.2013, 15:27 -0400 schrieb Eyal Edri: | | - Original Message - |From: Fabian Deutsch fabi...@redhat.com |To: Alon Bar-Lev alo...@redhat.com |Cc: engine-devel engine-devel@ovirt.org, infra in...@ovirt.org |Sent: Tuesday, July 9, 2013 3:54:06 PM |Subject: Re: [Engine-devel] Proposal for new commit msg design for |engine |commits | |Am Dienstag, den 09.07.2013, 08:49 -0400 schrieb Alon Bar-Lev: | | | - Original Message - | From: Yair Zaslavsky yzasl...@redhat.com | To: Alon Bar-Lev alo...@redhat.com | Cc: Eyal Edri ee...@redhat.com, engine-devel | engine-devel@ovirt.org, infra in...@ovirt.org | Sent: Tuesday, July 9, 2013 3:42:24 PM | Subject: Re: [Engine-devel] Proposal for new commit msg design for | engine commits | | | | - Original Message - | From: Alon Bar-Lev alo...@redhat.com | To: Eyal Edri ee...@redhat.com | Cc: engine-devel engine-devel@ovirt.org, infra | in...@ovirt.org | Sent: Tuesday, July 9, 2013 3:33:57 PM | Subject: Re: [Engine-devel] Proposal for new commit msg design | for | engine | commits | | | | - Original Message - |From: Eyal Edri ee...@redhat.com |To: engine-devel engine-devel@ovirt.org |Cc: infra in...@ovirt.org |Sent: Tuesday, July 9, 2013 12:38:51 PM |Subject: Proposal for new commit msg design for engine commits | |Hi, | |You all probably know and familiar with 'ovirt-engine' git hook | for |commit |msg template [1]. |this helps understand the general area of the patch in the | project but it |lacks additional info that might |be valuable for scaling automatic tests in Jenkins CI. | |Let me explain: | |Infra team is working hard on expanding oVirt CI infrastructure | and |adding |more tests in jenkins (per commit/patch). |Adding important meta-data per patch can significatly improve | the ability |to |run specific tests for each patch/commit, |and not waste valuable resources on Jenkins jobs that are not | relevant to |the |code in the patch. | |So the idea is to add/expand current metadata per patch, in the | form of: |(either) | 1. expanding current header template to include more data like | 'network' | , | 'setup', 'tools', 'virt' | | Please do not expand header, it is too short anyway. | | 2. adding a new label with relevant tags for the patch, called | e.g | 'METADATA: network, rest, virt' | | Having: | | CI-Tests: xxx | CI-Tests: yyy | CI-Tests: zzz | | Is much better. | | I'm not sure we should have CI-Test - as we might use this for | something else | besides CI. | Region_of_Interest as Dan suggests sounds better IMHO. | | I don't care how this is to be called. | However, I do not think that commit message is the place for | instructing CI to do anything. | Commit message stays for good, it should contain information that is | required a year from now. | It has nothing to do with tests and such. | |I agree with Alon here that the Ci informations don't belong in the |commit msg. |My opinion is that a testcase should know what it covers. This |information from the testcase can then be used by any party to determin |if the testcase should be run on a specific commit (which yields |informations about the changed paths, files, owner, author, etc ... |which might be valuable). | | i think you're missing the point here. | can you explain how do you propose a test case will know what it | covers? | | let's take an example: | let's say a new commit comes from ovirt-engine: | http://gerrit.ovirt.org/#/c/16668/ | commit msg: core: Use images instead of volumes at CDA message. | | now you have 1000 test cases (could be system or functional test). | (let's assume that your infra can't support running 1000 tests per
Re: [Engine-devel] Proposal for new commit msg design for engine commits
Hi Eyal, I really appreciate your concern and desire to streamline our CI infrastructure, but I'm afraid there might be some issues worth of discussing. If I've understood correctly a developer should add some kind of tags to idenfity the impact of the patch and so the subsets of tests (impact areas) that are going to be executed. I think it might be hard in some cases to properly identify the correct 'areas' and even error prone. I think that it really depends on how much engine software components are independent from each other and developer's codebase knowledge. I think it might be useful to have a dependency graph of components let's say at package level to define which tests should be executed, perhaps this is something that can be automate. We might discover that for transitivity a component depends on the whole engine. My 2 Czech Crowns Cheers, Giuseppe - Original Message - | From: Eyal Edri ee...@redhat.com | To: engine-devel engine-devel@ovirt.org | Cc: infra in...@ovirt.org | Sent: Tuesday, July 9, 2013 11:38:51 AM | Subject: [Engine-devel] Proposal for new commit msg design for engine commits | | Hi, | | You all probably know and familiar with 'ovirt-engine' git hook for commit | msg template [1]. | this helps understand the general area of the patch in the project but it | lacks additional info that might | be valuable for scaling automatic tests in Jenkins CI. | | Let me explain: | | Infra team is working hard on expanding oVirt CI infrastructure and adding | more tests in jenkins (per commit/patch). | Adding important meta-data per patch can significatly improve the ability to | run specific tests for each patch/commit, | and not waste valuable resources on Jenkins jobs that are not relevant to the | code in the patch. | | So the idea is to add/expand current metadata per patch, in the form of: | (either) | 1. expanding current header template to include more data like 'network' , | 'setup', 'tools', 'virt' | 2. adding a new label with relevant tags for the patch, called e.g | 'METADATA: network, rest, virt' | | Jenkins jobs will then be able to parse that data and trigger only relevant | jobs for it. | this can also allow us to add more jobs per patch, an option that is very | problematic today considering the amount of | patches coming in to engine. | | Once agreed on a format, we'll be able to add a git hook to verify the | validity of the commit msg. (similar to bug-url). | | if we're not 100% sure that the tags will cover all corner cases and we feel | like we need to run the code on all jobs, | we can a nightly job to run all the remaining jobs (but at least it won't run | on every patch/commit). | | [1] core | restapi | tools | history | engine | userportal | webadmin: | | | thoughts? | | Eyal Edri. | ___ | Engine-devel mailing list | Engine-devel@ovirt.org | http://lists.ovirt.org/mailman/listinfo/engine-devel | ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] VNic QoS measure units and attributes.
- Original Message - | From: Ofri Masad oma...@redhat.com | To: Giuseppe Vallarelli gvall...@redhat.com | Cc: Livnat Peer lp...@redhat.com, engine-devel@ovirt.org | Sent: Tuesday, June 25, 2013 8:19:30 AM | Subject: Re: [Engine-devel] VNic QoS measure units and attributes. | | Hi Giuseppe, | | Thanks for the review. I am aware of the need to add conversion of units in | the engine. | As for the mandatory fields - we decided to make all 6 fields mandatory to | the engine users (we know libvirt does not enforce this). | Leaving some fields empty may cause some ambiguity since libvirt is filling | the remaining fields by it self. | for example: if libvirt implementation will change in future releases, the | user may get different peak and burst values without even knowing about it. I see, in this case your choice makes perfect sense, Thanks for sharing. Giuseppe | | thank again | Ofri | | - Original Message - | From: Giuseppe Vallarelli gvall...@redhat.com | To: Livnat Peer lp...@redhat.com | Cc: engine-devel@ovirt.org | Sent: Monday, June 24, 2013 9:22:59 PM | Subject: Re: [Engine-devel] VNic QoS measure units and attributes. | | - Original Message - | | From: Livnat Peer lp...@redhat.com | | To: Giuseppe Vallarelli gvall...@redhat.com | | Cc: engine-devel@ovirt.org | | Sent: Monday, June 24, 2013 6:31:43 PM | | Subject: Re: [Engine-devel] VNic QoS measure units and attributes. | | | | On 06/24/2013 03:07 PM, Giuseppe Vallarelli wrote: | | Hi Ofri, I've been reading your design page for this feature [1] and | | and | | I've found out | | that there's a possible unit of measure mismatch regarding: Average, | | Burst | | and Peak, clearly | | makes sense to use Mbps on the gui but I wonder if you're aware that | | the | | vdsm api expects | | respectivly: kB/sec, kB and kB/sec (for average, burst and peak), so a | | conversion is needed. | | As a side note the only compulsory attribute needed to define QoS for | | incoming and outgoing | | traffic is average, burst and peak are optional (see [2]), this is not | | clear by looking | | at the mockups and description. | | | | Cheers, Giuseppe | | | | | | Hi Giuseppe, | | Do you know why VDSM API exposes KB/Sec? don't you think that Mbps is | | more intuitive? | | Hi Livnat, I made this choice because libvirt uses those unit of measure | and I considered vdsm to be almost at the same (low) level. This part of | the API has been already implemented/documented and discussed in a | previous thread [1]. I agree that Mbps is much more intuitive for the | end user. We can decide where we should make the conversion, if at the | engine level or in vdsm. I'm fine with both choices. | | Cheers Giuseppe. | | | [1] Add traffic shaping parameters for a network interface. | | | | | | | Livnat | | | | [1] http://www.ovirt.org/Features/Network_QoS | | [2] http://libvirt.org/formatdomain.html#elementQoS | | | | | | ___ | | Engine-devel mailing list | | Engine-devel@ovirt.org | | http://lists.ovirt.org/mailman/listinfo/engine-devel | | | | | ___ | Engine-devel mailing list | Engine-devel@ovirt.org | http://lists.ovirt.org/mailman/listinfo/engine-devel | | ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] VNic QoS measure units and attributes.
Hi Ofri, I've been reading your design page for this feature [1] and and I've found out that there's a possible unit of measure mismatch regarding: Average, Burst and Peak, clearly makes sense to use Mbps on the gui but I wonder if you're aware that the vdsm api expects respectivly: kB/sec, kB and kB/sec (for average, burst and peak), so a conversion is needed. As a side note the only compulsory attribute needed to define QoS for incoming and outgoing traffic is average, burst and peak are optional (see [2]), this is not clear by looking at the mockups and description. Cheers, Giuseppe [1] http://www.ovirt.org/Features/Network_QoS [2] http://libvirt.org/formatdomain.html#elementQoS ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] VNic QoS measure units and attributes.
- Original Message - | From: Livnat Peer lp...@redhat.com | To: Giuseppe Vallarelli gvall...@redhat.com | Cc: engine-devel@ovirt.org | Sent: Monday, June 24, 2013 6:31:43 PM | Subject: Re: [Engine-devel] VNic QoS measure units and attributes. | | On 06/24/2013 03:07 PM, Giuseppe Vallarelli wrote: | Hi Ofri, I've been reading your design page for this feature [1] and and | I've found out | that there's a possible unit of measure mismatch regarding: Average, Burst | and Peak, clearly | makes sense to use Mbps on the gui but I wonder if you're aware that the | vdsm api expects | respectivly: kB/sec, kB and kB/sec (for average, burst and peak), so a | conversion is needed. | As a side note the only compulsory attribute needed to define QoS for | incoming and outgoing | traffic is average, burst and peak are optional (see [2]), this is not | clear by looking | at the mockups and description. | | Cheers, Giuseppe | | | Hi Giuseppe, | Do you know why VDSM API exposes KB/Sec? don't you think that Mbps is | more intuitive? Hi Livnat, I made this choice because libvirt uses those unit of measure and I considered vdsm to be almost at the same (low) level. This part of the API has been already implemented/documented and discussed in a previous thread [1]. I agree that Mbps is much more intuitive for the end user. We can decide where we should make the conversion, if at the engine level or in vdsm. I'm fine with both choices. Cheers Giuseppe. [1] Add traffic shaping parameters for a network interface. | | | Livnat | | [1] http://www.ovirt.org/Features/Network_QoS | [2] http://libvirt.org/formatdomain.html#elementQoS | | | ___ | Engine-devel mailing list | Engine-devel@ovirt.org | http://lists.ovirt.org/mailman/listinfo/engine-devel | | ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Add traffic shaping parameters for a network interface.
- Original Message -
| From: Doron Fediuck dfedi...@redhat.com
| To: Giuseppe Vallarelli gvall...@redhat.com
| Cc: Livnat Peer lp...@redhat.com, engine-devel@ovirt.org, Dan
Kenigsberg dan...@redhat.com
| Sent: Wednesday, June 12, 2013 9:05:35 AM
| Subject: Re: [Engine-devel] Add traffic shaping parameters for a network
interface.
|
|
|
| - Original Message -
| From: Giuseppe Vallarelli gvall...@redhat.com
| To: Livnat Peer lp...@redhat.com
| Cc: Doron Fediuck dfedi...@redhat.com, engine-devel@ovirt.org, Dan
| Kenigsberg dan...@redhat.com
| Sent: Tuesday, June 11, 2013 5:34:16 PM
| Subject: Re: [Engine-devel] Add traffic shaping parameters for a network
| interface.
|
| - Original Message -
| | From: Giuseppe Vallarelli gvall...@redhat.com
| | To: Livnat Peer lp...@redhat.com
| | Cc: Doron Fediuck dfedi...@redhat.com, engine-devel@ovirt.org, Dan
| | Kenigsberg dan...@redhat.com
| | Sent: Tuesday, June 11, 2013 3:07:32 PM
| | Subject: Re: [Engine-devel] Add traffic shaping parameters for a network
| | interface.
| |
| | Related to QoS parameters reporting to the engine. Looks like they're
| | already
| | available, I tried to use vdsClient with list verb and I've got the
| | devices
| | list where a 'specParams' is defined (it's empty because I didn't try it
| | with
| | my last patch).
| |
| | devices = [... {'nicModel': 'pv', 'macAddr': '00:1a:4a:22:3f:04',
| | 'network':
| | 'ovirtmgmt', 'alias': 'net0', 'specParams': {},
| | 'deviceId': '76173ffc-603a-496f-8ffc-31dc4d41cef6', 'address': {'slot':
| | '0x03', 'bus': '0x00', 'domain': '0x',
| | 'type': 'pci', 'function': '0x0'}, 'device': 'bridge', 'type':
| | 'interface'}
| | ...]
| |
| | Perhaps I'm missing something, any ideas/hints ?
| | Thanks Giuseppe
|
| A few pastes:
| creating the vm: http://paste.fedoraproject.org/17953/37096041/
| dumping vm xml: http://paste.fedoraproject.org/17951/37096009/
|
| I've tried this out thanks to Toni, losing sanity with vdsClient..
|
| Giuseppe
|
|
| Thanks Giuseppe.
| Is this also reported by vdsm in getVmStats?
|
Unfortunately is not reported using getVmStats, I'm looking into it.
Giuseppe
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Add traffic shaping parameters for a network interface.
- Original Message -
| From: Giuseppe Vallarelli gvall...@redhat.com
| To: Doron Fediuck dfedi...@redhat.com
| Cc: engine-devel@ovirt.org
| Sent: Wednesday, June 12, 2013 9:28:19 AM
| Subject: Re: [Engine-devel] Add traffic shaping parameters for a network
interface.
|
|
|
| - Original Message -
| | From: Doron Fediuck dfedi...@redhat.com
| | To: Giuseppe Vallarelli gvall...@redhat.com
| | Cc: Livnat Peer lp...@redhat.com, engine-devel@ovirt.org, Dan
| | Kenigsberg dan...@redhat.com
| | Sent: Wednesday, June 12, 2013 9:05:35 AM
| | Subject: Re: [Engine-devel] Add traffic shaping parameters for a network
| | interface.
| |
| |
| |
| | - Original Message -
| | From: Giuseppe Vallarelli gvall...@redhat.com
| | To: Livnat Peer lp...@redhat.com
| | Cc: Doron Fediuck dfedi...@redhat.com, engine-devel@ovirt.org, Dan
| | Kenigsberg dan...@redhat.com
| | Sent: Tuesday, June 11, 2013 5:34:16 PM
| | Subject: Re: [Engine-devel] Add traffic shaping parameters for a network
| | interface.
| |
| | - Original Message -
| | | From: Giuseppe Vallarelli gvall...@redhat.com
| | | To: Livnat Peer lp...@redhat.com
| | | Cc: Doron Fediuck dfedi...@redhat.com, engine-devel@ovirt.org, Dan
| | | Kenigsberg dan...@redhat.com
| | | Sent: Tuesday, June 11, 2013 3:07:32 PM
| | | Subject: Re: [Engine-devel] Add traffic shaping parameters for a
| | | network
| | | interface.
| | |
| | | Related to QoS parameters reporting to the engine. Looks like they're
| | | already
| | | available, I tried to use vdsClient with list verb and I've got the
| | | devices
| | | list where a 'specParams' is defined (it's empty because I didn't try
| | | it
| | | with
| | | my last patch).
| | |
| | | devices = [... {'nicModel': 'pv', 'macAddr': '00:1a:4a:22:3f:04',
| | | 'network':
| | | 'ovirtmgmt', 'alias': 'net0', 'specParams': {},
| | | 'deviceId': '76173ffc-603a-496f-8ffc-31dc4d41cef6', 'address': {'slot':
| | | '0x03', 'bus': '0x00', 'domain': '0x',
| | | 'type': 'pci', 'function': '0x0'}, 'device': 'bridge', 'type':
| | | 'interface'}
| | | ...]
| | |
| | | Perhaps I'm missing something, any ideas/hints ?
| | | Thanks Giuseppe
| |
| | A few pastes:
| | creating the vm: http://paste.fedoraproject.org/17953/37096041/
| | dumping vm xml: http://paste.fedoraproject.org/17951/37096009/
| |
| | I've tried this out thanks to Toni, losing sanity with vdsClient..
| |
| | Giuseppe
| |
| |
| | Thanks Giuseppe.
| | Is this also reported by vdsm in getVmStats?
| |
|
| Unfortunately is not reported using getVmStats, I'm looking into it.
| Giuseppe
New paste: http://paste.fedoraproject.org/18161/71033933/
Giuseppe
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Add traffic shaping parameters for a network interface.
Related to QoS parameters reporting to the engine. Looks like they're already
available, I tried to use vdsClient with list verb and I've got the devices
list where a 'specParams' is defined (it's empty because I didn't try it with
my last patch).
devices = [... {'nicModel': 'pv', 'macAddr': '00:1a:4a:22:3f:04', 'network':
'ovirtmgmt', 'alias': 'net0', 'specParams': {},
'deviceId': '76173ffc-603a-496f-8ffc-31dc4d41cef6', 'address': {'slot': '0x03',
'bus': '0x00', 'domain': '0x',
'type': 'pci', 'function': '0x0'}, 'device': 'bridge', 'type': 'interface'} ...]
Perhaps I'm missing something, any ideas/hints ?
Thanks Giuseppe
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Add traffic shaping parameters for a network interface.
Hi Guys, I've recently submitted a patch to support traffic shaping for a
network interface (http://gerrit.ovirt.org/#/c/15445/).
This work is needed in order to support
http://www.ovirt.org/Features/Network_QoS .
Given:
'specParams': {'inbound': {'average': '1000', 'peak': '5000', 'burst': '1024'},
'outbound': {'average': '128', 'burst': '256'}}}
Generated xml is the following one:
bandwidth
inbound average=1000 burst=1024 peak=5000/
outbound average=128 burst=256/
/bandwidth
As you can see I tried to keep the data structure as flat as possible having
the bandwidth element not carrying any useful information.
Feedback is highly appreciated.
Cheers, Giuseppe.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Add traffic shaping parameters for a network interface.
- Original Message -
| From: Dan Kenigsberg dan...@redhat.com
| To: Giuseppe Vallarelli gvall...@redhat.com
| Cc: engine-devel@ovirt.org
| Sent: Monday, June 10, 2013 4:22:54 PM
| Subject: Re: [Engine-devel] Add traffic shaping parameters for a network
interface.
|
| On Mon, Jun 10, 2013 at 08:56:21AM -0400, Giuseppe Vallarelli wrote:
| Hi Guys, I've recently submitted a patch to support traffic shaping for a
| network interface (http://gerrit.ovirt.org/#/c/15445/).
| This work is needed in order to support
| http://www.ovirt.org/Features/Network_QoS .
| Given:
|
| 'specParams': {'inbound': {'average': '1000', 'peak': '5000', 'burst':
| '1024'},
| 'outbound': {'average': '128', 'burst': '256'}}}
|
| Generated xml is the following one:
|
|
|
|
|
|
| As you can see I tried to keep the data structure as flat as possible
| having the bandwidth element not carrying any useful information.
| Feedback is highly appreciated.
|
|
| The issue has not been mentioned on the wiki page, but may need a means
| to report the currently-configured QoS of each vNIC from Vdsm to Engine.
| For example, when a VM is de-hibernated, we may want to tell whether its
| QoS needs to be set according to a recently-tweaked policy.
|
| I suggest that we use the getVmList verb of Vdsm, which is intended to
| report static properties of one Vm (or all of them).
|
| On the other hand, Engine would want to blindly set new values whenever
| in doubt. In such a case, I think that reporting of QoS can be avoided.
|
| Dan.
|
I'm not sure I've understood completely the issue in discussion, doesn't the
engine knows already
which are the QoS profile applied to each vNIC ? The last 'tweaked' profile is
the one that should
be applied after de-hibernation. This means that on the engine side we should
keep track of profile
change, if a change happens de-hibernating a vm triggers a QoS profile update
on the host of the
latest profile. I'm not aware of the implementation details so I might be wrong.
Giuseppe.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Add traffic shaping parameters for a network interface.
- Original Message -
| From: Doron Fediuck dfedi...@redhat.com
| To: Giuseppe Vallarelli gvall...@redhat.com
| Cc: Dan Kenigsberg dan...@redhat.com, engine-devel@ovirt.org
| Sent: Monday, June 10, 2013 6:46:29 PM
| Subject: Re: [Engine-devel] Add traffic shaping parameters for a network
interface.
|
|
|
| - Original Message -
| From: Giuseppe Vallarelli gvall...@redhat.com
| To: Dan Kenigsberg dan...@redhat.com
| Cc: engine-devel@ovirt.org
| Sent: Monday, June 10, 2013 6:04:27 PM
| Subject: Re: [Engine-devel] Add traffic shaping parameters for a network
| interface.
|
| - Original Message -
| | From: Dan Kenigsberg dan...@redhat.com
| | To: Giuseppe Vallarelli gvall...@redhat.com
| | Cc: engine-devel@ovirt.org
| | Sent: Monday, June 10, 2013 4:22:54 PM
| | Subject: Re: [Engine-devel] Add traffic shaping parameters for a network
| | interface.
| |
| | On Mon, Jun 10, 2013 at 08:56:21AM -0400, Giuseppe Vallarelli wrote:
| | Hi Guys, I've recently submitted a patch to support traffic shaping for
| | a
| | network interface (http://gerrit.ovirt.org/#/c/15445/).
| | This work is needed in order to support
| | http://www.ovirt.org/Features/Network_QoS .
| | Given:
| |
| | 'specParams': {'inbound': {'average': '1000', 'peak': '5000', 'burst':
| | '1024'},
| | 'outbound': {'average': '128', 'burst': '256'}}}
| |
| | Generated xml is the following one:
| |
| |
| |
| |
| |
| |
| | As you can see I tried to keep the data structure as flat as possible
| | having the bandwidth element not carrying any useful information.
| | Feedback is highly appreciated.
| |
| |
| | The issue has not been mentioned on the wiki page, but may need a means
| | to report the currently-configured QoS of each vNIC from Vdsm to Engine.
| | For example, when a VM is de-hibernated, we may want to tell whether its
| | QoS needs to be set according to a recently-tweaked policy.
| |
| | I suggest that we use the getVmList verb of Vdsm, which is intended to
| | report static properties of one Vm (or all of them).
| |
| | On the other hand, Engine would want to blindly set new values whenever
| | in doubt. In such a case, I think that reporting of QoS can be avoided.
| |
| | Dan.
| |
|
| I'm not sure I've understood completely the issue in discussion, doesn't
| the
| engine knows already
| which are the QoS profile applied to each vNIC ? The last 'tweaked' profile
| is the one that should
| be applied after de-hibernation. This means that on the engine side we
| should
| keep track of profile
| change, if a change happens de-hibernating a vm triggers a QoS profile
| update
| on the host of the
| latest profile. I'm not aware of the implementation details so I might be
| wrong.
|
| Giuseppe.
|
| The idea is to handle scenarios where something went wrong;
| For example, VDSM crash while starting a new VM, engine crash, etc.
| So the engine should be able to ask for current QoS for reporting,
| and (re-)apply it if out of sync.
|
Hi Doron, thanks for the feedback, makes sense to me.
Giuseppe
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
