To try and improve 3.4 planning over the wiki approach in 3.3, I've placed the items i collected on users list last time into a google doc[1] now, the main thing each item needs is a requirements owner, devel owner and a testing owner (well, devel owner is really needed to make it happen, but all are important). then we need an oVirt BZ for each, and for some a feature page. I also added columns indicating if the item will require an API design review and a GUI design review. this list is just the start of course for items from it to get ownership. i expect more items will be added as well, as long as they have owners, etc. the doc is public read-only, please request read-write access to be able to edit it. feel free to ask questions, etc. Thanks, Itamar [1] http://bit.ly/17qBn6F
On Tue, Oct 29, 2013 at 07:46:57PM +0200, Itamar Heim wrote:
To try and improve 3.4 planning over the wiki approach in 3.3, I've placed the items i collected on users list last time into a google doc[1]
now, the main thing each item needs is a requirements owner, devel owner and a testing owner (well, devel owner is really needed to make it happen, but all are important).
then we need an oVirt BZ for each, and for some a feature page.
I also added columns indicating if the item will require an API design review and a GUI design review.
this list is just the start of course for items from it to get ownership. i expect more items will be added as well, as long as they have owners, etc.
the doc is public read-only, please request read-write access to be able to edit it.
feel free to ask questions, etc.
I'd love to add vdsm-reg phase-out to the list. It's a code-only change, but it requires tracking. Bug 994451 - [vdsm-reg] retire vdsm-reg Another one on my wishlist is per-network custom properties and hooks. Having something like that would enable users do all kind of funky network configurations that are currently unsupported by oVirt. Dan.
On 10/31/2013 11:36 AM, Dan Kenigsberg wrote:
On Tue, Oct 29, 2013 at 07:46:57PM +0200, Itamar Heim wrote:
To try and improve 3.4 planning over the wiki approach in 3.3, I've placed the items i collected on users list last time into a google doc[1]
now, the main thing each item needs is a requirements owner, devel owner and a testing owner (well, devel owner is really needed to make it happen, but all are important).
then we need an oVirt BZ for each, and for some a feature page.
I also added columns indicating if the item will require an API design review and a GUI design review.
this list is just the start of course for items from it to get ownership. i expect more items will be added as well, as long as they have owners, etc.
the doc is public read-only, please request read-write access to be able to edit it.
feel free to ask questions, etc.
I'd love to add vdsm-reg phase-out to the list. It's a code-only change, but it requires tracking.
Bug 994451 - [vdsm-reg] retire vdsm-reg
I think its clear its deprecated, but need to remain until we move to "4.0" when a lot of other things to be deprecated are ready.
Another one on my wishlist is per-network custom properties and hooks. Having something like that would enable users do all kind of funky network configurations that are currently unsupported by oVirt.
well, please add to the google doc...
Dan.
On Thu, Oct 31, 2013 at 12:10:20PM +0200, Itamar Heim wrote:
On 10/31/2013 11:36 AM, Dan Kenigsberg wrote:
On Tue, Oct 29, 2013 at 07:46:57PM +0200, Itamar Heim wrote:
To try and improve 3.4 planning over the wiki approach in 3.3, I've placed the items i collected on users list last time into a google doc[1]
now, the main thing each item needs is a requirements owner, devel owner and a testing owner (well, devel owner is really needed to make it happen, but all are important).
then we need an oVirt BZ for each, and for some a feature page.
I also added columns indicating if the item will require an API design review and a GUI design review.
this list is just the start of course for items from it to get ownership. i expect more items will be added as well, as long as they have owners, etc.
the doc is public read-only, please request read-write access to be able to edit it.
feel free to ask questions, etc.
I'd love to add vdsm-reg phase-out to the list. It's a code-only change, but it requires tracking.
Bug 994451 - [vdsm-reg] retire vdsm-reg
I think its clear its deprecated, but need to remain until we move to "4.0" when a lot of other things to be deprecated are ready.
It's still in use today, when a node registers itself to ovirt-engine-3.3. We should replace it with a much simpler http call, and keep vdsm-reg optional for the (very) few users who would like to register an ovirt-node-3.4 to an engine <= 3.1.
Another one on my wishlist is per-network custom properties and hooks. Having something like that would enable users do all kind of funky network configurations that are currently unsupported by oVirt.
well, please add to the google doc...
Would you grant me (actually danken at gmail) write access? Or better move the list the wiki... Editing tables in wiki syntax is no fun, but maintaining a private acl on this google doc sounds like hell to me.
Am Donnerstag, den 31.10.2013, 10:40 +0000 schrieb Dan Kenigsberg:
On Thu, Oct 31, 2013 at 12:10:20PM +0200, Itamar Heim wrote:
On 10/31/2013 11:36 AM, Dan Kenigsberg wrote:
On Tue, Oct 29, 2013 at 07:46:57PM +0200, Itamar Heim wrote:
To try and improve 3.4 planning over the wiki approach in 3.3, I've placed the items i collected on users list last time into a google doc[1]
now, the main thing each item needs is a requirements owner, devel owner and a testing owner (well, devel owner is really needed to make it happen, but all are important).
then we need an oVirt BZ for each, and for some a feature page.
I also added columns indicating if the item will require an API design review and a GUI design review.
this list is just the start of course for items from it to get ownership. i expect more items will be added as well, as long as they have owners, etc.
the doc is public read-only, please request read-write access to be able to edit it.
feel free to ask questions, etc.
I'd love to add vdsm-reg phase-out to the list. It's a code-only change, but it requires tracking.
Bug 994451 - [vdsm-reg] retire vdsm-reg
I think its clear its deprecated, but need to remain until we move to "4.0" when a lot of other things to be deprecated are ready.
It's still in use today, when a node registers itself to ovirt-engine-3.3. We should replace it with a much simpler http call, and keep vdsm-reg optional for the (very) few users who would like to register an ovirt-node-3.4 to an engine <= 3.1.
There is already going some light discussion going on about this simple http call here: https://bugzilla.redhat.com/show_bug.cgi?id=875088 - fabian
Another one on my wishlist is per-network custom properties and hooks. Having something like that would enable users do all kind of funky network configurations that are currently unsupported by oVirt.
well, please add to the google doc...
Would you grant me (actually danken at gmail) write access? Or better move the list the wiki... Editing tables in wiki syntax is no fun, but maintaining a private acl on this google doc sounds like hell to me. _______________________________________________ Arch mailing list Arch@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch
On Thu, Oct 31, 2013 at 11:42:49AM +0100, Fabian Deutsch wrote:
Am Donnerstag, den 31.10.2013, 10:40 +0000 schrieb Dan Kenigsberg:
On Thu, Oct 31, 2013 at 12:10:20PM +0200, Itamar Heim wrote:
On 10/31/2013 11:36 AM, Dan Kenigsberg wrote:
On Tue, Oct 29, 2013 at 07:46:57PM +0200, Itamar Heim wrote:
To try and improve 3.4 planning over the wiki approach in 3.3, I've placed the items i collected on users list last time into a google doc[1]
now, the main thing each item needs is a requirements owner, devel owner and a testing owner (well, devel owner is really needed to make it happen, but all are important).
then we need an oVirt BZ for each, and for some a feature page.
I also added columns indicating if the item will require an API design review and a GUI design review.
this list is just the start of course for items from it to get ownership. i expect more items will be added as well, as long as they have owners, etc.
the doc is public read-only, please request read-write access to be able to edit it.
feel free to ask questions, etc.
I'd love to add vdsm-reg phase-out to the list. It's a code-only change, but it requires tracking.
Bug 994451 - [vdsm-reg] retire vdsm-reg
I think its clear its deprecated, but need to remain until we move to "4.0" when a lot of other things to be deprecated are ready.
It's still in use today, when a node registers itself to ovirt-engine-3.3. We should replace it with a much simpler http call, and keep vdsm-reg optional for the (very) few users who would like to register an ovirt-node-3.4 to an engine <= 3.1.
There is already going some light discussion going on about this simple http call here: https://bugzilla.redhat.com/show_bug.cgi?id=875088
Good! I am asking Bug 875088 - ovirt-node-registration - a generic node registration to be declated as a 3.4 feature.
On 10/31/2013 12:40 PM, Dan Kenigsberg wrote:
On Thu, Oct 31, 2013 at 12:10:20PM +0200, Itamar Heim wrote:
On 10/31/2013 11:36 AM, Dan Kenigsberg wrote:
On Tue, Oct 29, 2013 at 07:46:57PM +0200, Itamar Heim wrote:
To try and improve 3.4 planning over the wiki approach in 3.3, I've placed the items i collected on users list last time into a google doc[1]
now, the main thing each item needs is a requirements owner, devel owner and a testing owner (well, devel owner is really needed to make it happen, but all are important).
then we need an oVirt BZ for each, and for some a feature page.
I also added columns indicating if the item will require an API design review and a GUI design review.
this list is just the start of course for items from it to get ownership. i expect more items will be added as well, as long as they have owners, etc.
the doc is public read-only, please request read-write access to be able to edit it.
feel free to ask questions, etc.
I'd love to add vdsm-reg phase-out to the list. It's a code-only change, but it requires tracking.
Bug 994451 - [vdsm-reg] retire vdsm-reg
I think its clear its deprecated, but need to remain until we move to "4.0" when a lot of other things to be deprecated are ready.
It's still in use today, when a node registers itself to ovirt-engine-3.3. We should replace it with a much simpler http call, and keep vdsm-reg optional for the (very) few users who would like to register an ovirt-node-3.4 to an engine <= 3.1.
Another one on my wishlist is per-network custom properties and hooks. Having something like that would enable users do all kind of funky network configurations that are currently unsupported by oVirt.
well, please add to the google doc...
Would you grant me (actually danken at gmail) write access? Or better move the list the wiki... Editing tables in wiki syntax is no fun, but maintaining a private acl on this google doc sounds like hell to me.
just ask via the google doc... lets see how it works, its for sure much easier to work with a real spreadsheet...
Hi, Just to be clear: if you requested a feature last month, this is a great chance to help make it happen. To do so: * Ask for write access to the document below and add yourself as the "requirements owner" * Create a Feature page for the feature in the wiki, describing the user-facing experience you expect. Inputs, outputs, behaviour - all high level and user facing, nothing to do with implementation * Create a bug in Bugzilla (if there is not one already) to link both in the feature page and the summary doc below Another way to help is: * Add yourself as "test owner" for a feature - you are committing to putting the feature through its paces in a nightly build, when the coding is done. None of the features in the list are promised for 3.4 - it's a short development cycle, and I will be encouraging us to get to feature freeze as soon as reasonably possible - and the only way to guarantee a feature for inclusion is to sign up as the code owner, and agree to develop the feature yourself, but features with a good Feature page are *much* more likely to be implemented than those without. Thanks! Dave. On 10/29/2013 06:46 PM, Itamar Heim wrote:
now, the main thing each item needs is a requirements owner, devel owner and a testing owner (well, devel owner is really needed to make it happen, but all are important).
then we need an oVirt BZ for each, and for some a feature page.
<snip>
the doc is public read-only, please request read-write access to be able to edit it.
<snip>
[1] http://bit.ly/17qBn6F-- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
Hi, There are 2 features I can maybe add to existing projects of mine (check_rhev3 and Monitoring UI-Plugin), but it would be good to know what users require to decide if this can be done via an external (ui)plugin or if this needs to be integrated into oVirt itself. * gluster: Monitoring (UI plugin) What's expected here - monitoring glusterfs volumes (including performance data) and displaying the results in your favored monitoring solution and oVirt? * other: Zabbix monitoring Monitoring the oVirt environment should work with my check_rhev3 plugin by adding it as an external check to Zabbix. I'll test this and if it's working I'll provide a short guide on how to do it. Displaying data/triggers in oVirt isn't possible yet with my Monitoring UI-plugin, but on the feature list (help is welcome)... Before I add myself to the list - can you give me more information on the role/tasks of a testing owner? Are there more steps required then testing a feature, getting in contact with the devel owner to fix issues and update the oVirt BZ (and join the IRC weekly meetings)? Regards, René On Tue, 2013-10-29 at 19:46 +0200, Itamar Heim wrote:
To try and improve 3.4 planning over the wiki approach in 3.3, I've placed the items i collected on users list last time into a google doc[1]
now, the main thing each item needs is a requirements owner, devel owner and a testing owner (well, devel owner is really needed to make it happen, but all are important).
then we need an oVirt BZ for each, and for some a feature page.
I also added columns indicating if the item will require an API design review and a GUI design review.
this list is just the start of course for items from it to get ownership. i expect more items will be added as well, as long as they have owners, etc.
the doc is public read-only, please request read-write access to be able to edit it.
feel free to ask questions, etc.
Thanks, Itamar
[1] http://bit.ly/17qBn6F _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
* other: Zabbix monitoring Monitoring the oVirt environment should work with my check_rhev3 plugin by adding it as an external check to Zabbix. I'll test this and if it's working I'll provide a short guide on how to do it. Displaying data/triggers in oVirt isn't possible yet with my Monitoring UI-plugin, but on the feature list (help is welcome)...
I'm very interested in this Zabbix plugin/check, was thinking about implementing something myself.
On Wed, 2013-11-13 at 15:46 +0100, Sander Grendelman wrote:
* other: Zabbix monitoring Monitoring the oVirt environment should work with my check_rhev3 plugin by adding it as an external check to Zabbix. I'll test this and if it's working I'll provide a short guide on how to do it. Displaying data/triggers in oVirt isn't possible yet with my Monitoring UI-plugin, but on the feature list (help is welcome)...
I'm very interested in this Zabbix plugin/check, was thinking about implementing something myself.
The plugin is a Nagios monitoring plugin, but as mentioned above you should be able to use it with Zabbix when defining it as an external check. Download and documentation can be found here: https://github.com/ovido/check_rhev3 Feedback is more then welcome ;) Regards, René
Hi René, On 11/13/2013 04:16 PM, René Koch (ovido) wrote: [snip]
The plugin is a Nagios monitoring plugin, but as mentioned above you should be able to use it with Zabbix when defining it as an external check.
Download and documentation can be found here: https://github.com/ovido/check_rhev3
Any idea if your plugin also works with Icinga? Regards, Patrick
On 11/13/2013 09:27 AM, René Koch (ovido) wrote:
Hi,
There are 2 features I can maybe add to existing projects of mine (check_rhev3 and Monitoring UI-Plugin), but it would be good to know what users require to decide if this can be done via an external (ui)plugin or if this needs to be integrated into oVirt itself.
* gluster: Monitoring (UI plugin) What's expected here - monitoring glusterfs volumes (including performance data) and displaying the results in your favored monitoring solution and oVirt?
vijay/dpati/sahina - thoughts on this one?
* other: Zabbix monitoring Monitoring the oVirt environment should work with my check_rhev3 plugin by adding it as an external check to Zabbix. I'll test this and if it's working I'll provide a short guide on how to do it. Displaying data/triggers in oVirt isn't possible yet with my Monitoring UI-plugin, but on the feature list (help is welcome)...
Before I add myself to the list - can you give me more information on the role/tasks of a testing owner? Are there more steps required then testing a feature, getting in contact with the devel owner to fix issues and update the oVirt BZ (and join the IRC weekly meetings)?
communicate with the other two owner on scope of what to test, then when feature is ready - test it, open bugs, and communicate if too broken to be considered in the version, etc.
Regards, René
On Tue, 2013-10-29 at 19:46 +0200, Itamar Heim wrote:
To try and improve 3.4 planning over the wiki approach in 3.3, I've placed the items i collected on users list last time into a google doc[1]
now, the main thing each item needs is a requirements owner, devel owner and a testing owner (well, devel owner is really needed to make it happen, but all are important).
then we need an oVirt BZ for each, and for some a feature page.
I also added columns indicating if the item will require an API design review and a GUI design review.
this list is just the start of course for items from it to get ownership. i expect more items will be added as well, as long as they have owners, etc.
the doc is public read-only, please request read-write access to be able to edit it.
feel free to ask questions, etc.
Thanks, Itamar
[1] http://bit.ly/17qBn6F _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 11/13/2013 08:20 PM, Itamar Heim wrote:
On 11/13/2013 09:27 AM, René Koch (ovido) wrote:
Hi,
There are 2 features I can maybe add to existing projects of mine (check_rhev3 and Monitoring UI-Plugin), but it would be good to know what users require to decide if this can be done via an external (ui)plugin or if this needs to be integrated into oVirt itself.
* gluster: Monitoring (UI plugin) What's expected here - monitoring glusterfs volumes (including performance data) and displaying the results in your favored monitoring solution and oVirt?
vijay/dpati/sahina - thoughts on this one? At a high level,
Monitoring of volume Storage metrics - capacity, network, CPU, disk utilization Detecting split-brain/self-heal activity Vijay/Dusmant - please add.
* other: Zabbix monitoring Monitoring the oVirt environment should work with my check_rhev3 plugin by adding it as an external check to Zabbix. I'll test this and if it's working I'll provide a short guide on how to do it. Displaying data/triggers in oVirt isn't possible yet with my Monitoring UI-plugin, but on the feature list (help is welcome)...
Before I add myself to the list - can you give me more information on the role/tasks of a testing owner? Are there more steps required then testing a feature, getting in contact with the devel owner to fix issues and update the oVirt BZ (and join the IRC weekly meetings)?
communicate with the other two owner on scope of what to test, then when feature is ready - test it, open bugs, and communicate if too broken to be considered in the version, etc.
Regards, René
On Tue, 2013-10-29 at 19:46 +0200, Itamar Heim wrote:
To try and improve 3.4 planning over the wiki approach in 3.3, I've placed the items i collected on users list last time into a google doc[1]
now, the main thing each item needs is a requirements owner, devel owner and a testing owner (well, devel owner is really needed to make it happen, but all are important).
then we need an oVirt BZ for each, and for some a feature page.
I also added columns indicating if the item will require an API design review and a GUI design review.
this list is just the start of course for items from it to get ownership. i expect more items will be added as well, as long as they have owners, etc.
the doc is public read-only, please request read-write access to be able to edit it.
feel free to ask questions, etc.
Thanks, Itamar
[1] http://bit.ly/17qBn6F _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 11/13/2013 10:20 AM, Sahina Bose wrote:
On 11/13/2013 08:20 PM, Itamar Heim wrote:
On 11/13/2013 09:27 AM, René Koch (ovido) wrote:
Hi,
There are 2 features I can maybe add to existing projects of mine (check_rhev3 and Monitoring UI-Plugin), but it would be good to know what users require to decide if this can be done via an external (ui)plugin or if this needs to be integrated into oVirt itself.
* gluster: Monitoring (UI plugin) What's expected here - monitoring glusterfs volumes (including performance data) and displaying the results in your favored monitoring solution and oVirt?
vijay/dpati/sahina - thoughts on this one? At a high level,
Monitoring of volume Storage metrics - capacity, network, CPU, disk utilization Detecting split-brain/self-heal activity
would help specyfing which REST API calls are involved.
Vijay/Dusmant - please add.
* other: Zabbix monitoring Monitoring the oVirt environment should work with my check_rhev3 plugin by adding it as an external check to Zabbix. I'll test this and if it's working I'll provide a short guide on how to do it. Displaying data/triggers in oVirt isn't possible yet with my Monitoring UI-plugin, but on the feature list (help is welcome)...
Before I add myself to the list - can you give me more information on the role/tasks of a testing owner? Are there more steps required then testing a feature, getting in contact with the devel owner to fix issues and update the oVirt BZ (and join the IRC weekly meetings)?
communicate with the other two owner on scope of what to test, then when feature is ready - test it, open bugs, and communicate if too broken to be considered in the version, etc.
Regards, René
On Tue, 2013-10-29 at 19:46 +0200, Itamar Heim wrote:
To try and improve 3.4 planning over the wiki approach in 3.3, I've placed the items i collected on users list last time into a google doc[1]
now, the main thing each item needs is a requirements owner, devel owner and a testing owner (well, devel owner is really needed to make it happen, but all are important).
then we need an oVirt BZ for each, and for some a feature page.
I also added columns indicating if the item will require an API design review and a GUI design review.
this list is just the start of course for items from it to get ownership. i expect more items will be added as well, as long as they have owners, etc.
the doc is public read-only, please request read-write access to be able to edit it.
feel free to ask questions, etc.
Thanks, Itamar
[1] http://bit.ly/17qBn6F _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 11/13/2013 08:53 PM, Itamar Heim wrote:
On 11/13/2013 10:20 AM, Sahina Bose wrote:
On 11/13/2013 08:20 PM, Itamar Heim wrote:
On 11/13/2013 09:27 AM, René Koch (ovido) wrote:
Hi,
There are 2 features I can maybe add to existing projects of mine (check_rhev3 and Monitoring UI-Plugin), but it would be good to know what users require to decide if this can be done via an external (ui)plugin or if this needs to be integrated into oVirt itself.
* gluster: Monitoring (UI plugin) What's expected here - monitoring glusterfs volumes (including performance data) and displaying the results in your favored monitoring solution and oVirt?
vijay/dpati/sahina - thoughts on this one? At a high level,
Monitoring of volume Storage metrics - capacity, network, CPU, disk utilization Detecting split-brain/self-heal activity
would help specyfing which REST API calls are involved.
Hmm.. would monitoring work on top of engine via REST API calls? I was thinking more in line of monitoring the nodes directly - maybe a push mechanism from nodes.
Vijay/Dusmant - please add.
* other: Zabbix monitoring Monitoring the oVirt environment should work with my check_rhev3 plugin by adding it as an external check to Zabbix. I'll test this and if it's working I'll provide a short guide on how to do it. Displaying data/triggers in oVirt isn't possible yet with my Monitoring UI-plugin, but on the feature list (help is welcome)...
Before I add myself to the list - can you give me more information on the role/tasks of a testing owner? Are there more steps required then testing a feature, getting in contact with the devel owner to fix issues and update the oVirt BZ (and join the IRC weekly meetings)?
communicate with the other two owner on scope of what to test, then when feature is ready - test it, open bugs, and communicate if too broken to be considered in the version, etc.
Regards, René
On Tue, 2013-10-29 at 19:46 +0200, Itamar Heim wrote:
To try and improve 3.4 planning over the wiki approach in 3.3, I've placed the items i collected on users list last time into a google doc[1]
now, the main thing each item needs is a requirements owner, devel owner and a testing owner (well, devel owner is really needed to make it happen, but all are important).
then we need an oVirt BZ for each, and for some a feature page.
I also added columns indicating if the item will require an API design review and a GUI design review.
this list is just the start of course for items from it to get ownership. i expect more items will be added as well, as long as they have owners, etc.
the doc is public read-only, please request read-write access to be able to edit it.
feel free to ask questions, etc.
Thanks, Itamar
[1] http://bit.ly/17qBn6F _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Wed, 2013-11-13 at 21:05 +0530, Sahina Bose wrote:
On 11/13/2013 08:53 PM, Itamar Heim wrote:
On 11/13/2013 10:20 AM, Sahina Bose wrote:
On 11/13/2013 08:20 PM, Itamar Heim wrote:
On 11/13/2013 09:27 AM, René Koch (ovido) wrote:
Hi,
There are 2 features I can maybe add to existing projects of mine (check_rhev3 and Monitoring UI-Plugin), but it would be good to know what users require to decide if this can be done via an external (ui)plugin or if this needs to be integrated into oVirt itself.
* gluster: Monitoring (UI plugin) What's expected here - monitoring glusterfs volumes (including performance data) and displaying the results in your favored monitoring solution and oVirt?
vijay/dpati/sahina - thoughts on this one? At a high level,
Monitoring of volume Storage metrics - capacity, network, CPU, disk utilization Detecting split-brain/self-heal activity
would help specyfing which REST API calls are involved.
Hmm.. would monitoring work on top of engine via REST API calls? I was thinking more in line of monitoring the nodes directly - maybe a push mechanism from nodes.
The advantage of monitoring via REST-API is that you don't need an agent/script installed on the host/node. Especially for oVirt node I think this is a huge advantage (haven't looked into 3rd party plugin support yet). The downside of it is that if REST-API isn't available (e.g. due to engine maintenance jobs) you can't monitor your environment... Especially for Nagios both options are valid - gathering data from REST-API or directly from the host. Other monitoring solutions may require an agent (or maybe snmp) on the host if data aren't available via REST-API...
Vijay/Dusmant - please add.
* other: Zabbix monitoring Monitoring the oVirt environment should work with my check_rhev3 plugin by adding it as an external check to Zabbix. I'll test this and if it's working I'll provide a short guide on how to do it. Displaying data/triggers in oVirt isn't possible yet with my Monitoring UI-plugin, but on the feature list (help is welcome)...
Before I add myself to the list - can you give me more information on the role/tasks of a testing owner? Are there more steps required then testing a feature, getting in contact with the devel owner to fix issues and update the oVirt BZ (and join the IRC weekly meetings)?
communicate with the other two owner on scope of what to test, then when feature is ready - test it, open bugs, and communicate if too broken to be considered in the version, etc.
Regards, René
On Tue, 2013-10-29 at 19:46 +0200, Itamar Heim wrote:
To try and improve 3.4 planning over the wiki approach in 3.3, I've placed the items i collected on users list last time into a google doc[1]
now, the main thing each item needs is a requirements owner, devel owner and a testing owner (well, devel owner is really needed to make it happen, but all are important).
then we need an oVirt BZ for each, and for some a feature page.
I also added columns indicating if the item will require an API design review and a GUI design review.
this list is just the start of course for items from it to get ownership. i expect more items will be added as well, as long as they have owners, etc.
the doc is public read-only, please request read-write access to be able to edit it.
feel free to ask questions, etc.
Thanks, Itamar
[1] http://bit.ly/17qBn6F _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
participants (8)
-
Dan Kenigsberg -
Dave Neary -
Fabian Deutsch -
Itamar Heim -
Patrick Lists -
René Koch (ovido) -
Sahina Bose -
Sander Grendelman