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 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. _______________________________________________ Arch mailing list Arch(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/arch

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.

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(a)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.

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(a)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(a)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(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/users >>>> >>> >> >