Re: [ovirt-devel] Firewalld migration.
Ok, so I guess I misread. VDSM should have that responsibility and engine should not be evolved. I like the suggestion from other in the thread on managing the admin custom rules via Ansible and the inventory playbook we have already created. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Wed, Mar 29, 2017 at 9:53 AM, Dan Kenigsberg <dan...@redhat.com> wrote: > On Mon, Mar 27, 2017 at 2:38 PM, Yaniv Dary <yd...@redhat.com> wrote: > > Hi, > > I like option number 3 the most from reading the comments. > > We are not a configuration management system, so custom rules should not > be > > a main consideration. > > VDSM should probably enable the firewalld rules it needs to work and > engine > > should not care about firewall at all. > > A user wanting to add more rules then this should probably use the ones > > planned in: > > https://github.com/cockpit-project/system-api-roles > > > I, too, like the idea of shedding off the attempt to configure custom > iptables rules. Moving to firewalld makes it much easier to manage > such customization out of oVirt. (Anybody who's ever edited iptables > chains by hand would know what I mean) > > Please note that what you describe is Leon's alternative (2.). Where > Vdsm, as oVirt host agent, has complete responsibility on configuring > the services needed by oVirt. There is no Engine/Vdsm interaction in > alternative (2.). Option (3.) requires Engine to provide a list of > services to the host. > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Firewalld migration.
Hi, I like option number 3 the most from reading the comments. We are not a configuration management system, so custom rules should not be a main consideration. VDSM should probably enable the firewalld rules it needs to work and engine should not care about firewall at all. A user wanting to add more rules then this should probably use the ones planned in: https://github.com/cockpit-project/system-api-roles Thanks, Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Mon, Mar 27, 2017 at 2:10 PM, Martin Sivak <msi...@redhat.com> wrote: > > Right, so why not create an Ansible playbook which the users can change > > (extend?), based on http://docs.ansible.com/ > ansible/firewalld_module.html ? > > I think I like the playbook proposal the best. > > Lets assume the engine provides a firewall.yaml playbook somewhere in /etc: > > - The default playbook would contain our default firewalld > configuration (we should also provide it in /usr/share/doc to give the > user a reference) > - The engine or host deploy script can provide ansible variables so > the playbook can even be a parametrized one (port numbers) > - The user can add rules he needs > - The user can REPLACE the content with iptables rules if he wishes > so (we can even say it is unsupported, but possible) > > As an extension: > > - We can provide ovirt-engine-firewalld ansible role with the default > config so we can properly update files using RPM. The user defined (or > default) playbook would just call this role and would stay intact > during package upgrades. > > This is outside of database, allows customization and adapts to > whatever firewall backend we might need. > > -- > Martin Sivak > SLA / oVirt > > On Mon, Mar 27, 2017 at 12:46 PM, Yaniv Kaul <yk...@redhat.com> wrote: > > > > > > On Mon, Mar 27, 2017 at 1:20 PM, Martin Perina <mper...@redhat.com> > wrote: > >> > >> > >> > >> On Mon, Mar 27, 2017 at 12:00 PM, Yaniv Kaul <yk...@redhat.com> wrote: > >>> > >>> > >>> > >>> On Mon, Mar 27, 2017 at 11:55 AM, Martin Perina <mper...@redhat.com> > >>> wrote: > >>>> > >>>> Hi, > >>>> > >>>> so personally I don't like the current way how we store firewall > >>>> configuration within engine (saving complete iptables commands as > string). I > >>>> think should change the way how we store firewall configuration: > >>>> > >>>> 1. On engine side I'd just store which services/ports (or port ranges) > >>>> need to be enabled on host. By default only those services/ports that > engine > >>>> needs, but we can maintain also custom services defined by users > >>> > >>> > >>> Agreed. I hope that's enough on one hand, on the other hand, users can > >>> probably easily extend it via Ansible to the hosts and execution of a > more > >>> customized firewalld configuration there - we probably should not own > it. > >> > >> > >> Right, we should take care only about services/ports which we need. So > we > >> probably could drop the ability for users to define their own custom > >> services/ports within engine for firewalld and force them to use > Ansible or > >> other tools to handle their own configuration. > > > > > > Right, so why not create an Ansible playbook which the users can change > > (extend?), based on http://docs.ansible.com/ > ansible/firewalld_module.html ? > > ... > >> > >> > >>> > >>>> > >>>> > >>>> 2. Write plugin to ovirt-host-deploy which will translate those > >>>> services/ports into actual firewall configuration on the host (it > should > >>>> detected what firewall is currently enabled and adapt) > > > > > > ... and then ovirt-host-deploy will be in charge of executing that > > playbook? Seems fairly straightforward. > > Y. > > > >>> > >>> Agreed. > >>> > >>>> > >>>> > >>>> 3. For newly installed host I'd just use firewalld > >>> > >>> > >>> Agreed. > >>> > >>>> > >>>> > >>>> 4. Also for 4.2 clusters I'd switch from iptables to firewalld when > you > >>>> execute Reinstall (we should document this a
Re: [ovirt-devel] Fwd: Question for oVirt
This is not relevant anymore. We are exploring an option to use NM for network configuration in the future. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Tue, Mar 21, 2017 at 4:40 AM, jeff hsueh <jeffhs...@qnap.com> wrote: > Hi Devel, > > Could you help to give me some detail information about this feature? > Thanks. > > Jeff > > -- Forwarded message -- > From: Mike Burns <mbu...@redhat.com> > Date: 2017-03-20 20:44 GMT+08:00 > Subject: Re: Question for oVirt > To: jeff hsueh <jeffhs...@qnap.com> > > > This is very old (last update 2012). I haven't worked on oVirt in a long > time either. You should redirect this and other questions to > > devel@ovirt.org. > > Thanks > > On Mon, Mar 20, 2017 at 4:56 AM, jeff hsueh <jeffhs...@qnap.com> wrote: > >> Hi Mike, >> >> I am studying "NetworkManager Support" of oVirt project. >> Link: http://www.ovirt.org/develop/release-management/featur >> es/network/networkmanager-support/ >> >> I could not understand what does this feature want to achieve. >> Could I get more information and status about this feature from you? >> Because the information about this feature in oVirt web site is too brief. >> >> Thanks. >> >> Jeff >> >> >> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> >> 不含病毒。www.avast.com >> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> >> <#m_-7074419660434254156_m_-8795404721952800494_m_4727600564310439803_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> > > > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Ceph hyperconvergence
Yes, open a RFE for now. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Sun, Mar 19, 2017 at 4:16 PM, Logan Kuhn <supp...@jac-properties.com> wrote: > What can I do to help make this happen? I am not a programmer, just a > sysadmin using ceph/cinder/ovirt 4 > > Should I put in an RFE? > > > On Sun, Mar 19, 2017 at 9:12 AM, Yaniv Dary <yd...@redhat.com> wrote: > >> We need a native way to use Ceph prior to this type of HCI. >> This is currently not there yet. We are thinking of paths that will allow >> this in the future, but nothing concrete. >> >> Yaniv Dary >> Technical Product Manager >> Red Hat Israel Ltd. >> 34 Jerusalem Road >> Building A, 4th floor >> Ra'anana, Israel 4350109 >> >> Tel : +972 (9) 7692306 <+972%209-769-2306> >> 8272306 >> Email: yd...@redhat.com >> IRC : ydary >> >> >> On Mon, Mar 13, 2017 at 6:01 PM, Logan Kuhn <logankuhn...@gmail.com> >> wrote: >> >>> Hi >>> >>> It was suggested that I ask this list. Are there any plans to add >>> hyperconverge with Ceph, similar to the way it has been implemented with >>> Gluster? I know that I can add Cinder as an external provider as an >>> interface to Ceph, but it's more clunky than a hyperconverged solution. >>> >>> Regards, >>> Logan Kuhn >>> >>> ___ >>> Devel mailing list >>> Devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >>> >> >> > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Ceph hyperconvergence
We need a native way to use Ceph prior to this type of HCI. This is currently not there yet. We are thinking of paths that will allow this in the future, but nothing concrete. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Mon, Mar 13, 2017 at 6:01 PM, Logan Kuhn <logankuhn...@gmail.com> wrote: > Hi > > It was suggested that I ask this list. Are there any plans to add > hyperconverge with Ceph, similar to the way it has been implemented with > Gluster? I know that I can add Cinder as an external provider as an > interface to Ceph, but it's more clunky than a hyperconverged solution. > > Regards, > Logan Kuhn > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [monitoring][collectd] the collectd virt plugin is now on par with Vdsm needs
We need good answers from them to why they do not support this use case. Maybe a github issue on the use case would get more attention. They should allow us to choose how to present and collect the data. Can you open one? Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 <+972%209-769-2306> 8272306 Email: yd...@redhat.com IRC : ydary On Tue, Feb 28, 2017 at 1:07 PM, Francesco Romani <from...@redhat.com> wrote: > > On 02/27/2017 01:32 PM, Yaniv Dary wrote: > > This is about accumulative values, I'm also asking about stats like > > CPU usage of the VM\Host that is not reported in absolute value. > > Can you bump the thread? > > Done, let's see. > > > Speaking about options: during the reviews of my pull requests we also > discussed the (semi?)recommended way to report more values without > adding new collectd types, which is something the collectd upstream > really tries to avoid. > > So we could report the current values *and* the absolutes, making > everyone happy; but I'm afraid this will require a new plugin, like the > one I had in the working (https://github.com/fromanirh/collectd-ovirt) > > TL;DR: in the worst case, we have one safe fallback option. > > -- > Francesco Romani > Red Hat Engineering Virtualization R & D > IRC: fromani > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [monitoring][collectd] the collectd virt plugin is now on par with Vdsm needs
This is about accumulative values, I'm also asking about stats like CPU usage of the VM\Host that is not reported in absolute value. Can you bump the thread? Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Mon, Feb 27, 2017 at 10:11 AM, Francesco Romani <from...@redhat.com> wrote: > > On 02/26/2017 03:13 PM, Yaniv Dary wrote: > > > 2. collectd *intentionally* report metrics as rates, not as absolute >> values as Vdsm does. This may be one issue in presence of restarts/data >> loss in the link between collectd and the metrics store. >> >> >> How does this work? >> If we want to show memory usage over time for example, we need to have >> the usage, not the rate. >> How would this be reported? >> >> >> I was imprecise, my fault. >> >> Let me retry: >> collectd intentionally report quite a lot of metrics we care about as >> rates, not as absolute values. >> Memory is actually ok fine. >> >> a0/virt/disk_octets-hdc -> rate >> a0/virt/disk_octets-vda >> a0/virt/disk_ops-hdc -> rate >> a0/virt/disk_ops-vda >> a0/virt/disk_time-hdc -> rate >> a0/virt/disk_time-vda >> a0/virt/if_dropped-vnet0 -> rate >> a0/virt/if_errors-vnet0 -> rate >> a0/virt/if_octets-vnet0 -> rate >> a0/virt/if_packets-vnet0 -> rate >> a0/virt/memory-actual_balloon -> absolute >> a0/virt/memory-rss -> absolute >> a0/virt/memory-total -> absolute >> a0/virt/ps_cputime -> rate >> a0/virt/total_requests-flush-hdc -> rate >> a0/virt/total_requests-flush-vda >> a0/virt/total_time_in_ms-flush-hdc -> rate >> a0/virt/total_time_in_ms-flush-vda >> a0/virt/virt_cpu_total -> rate >> a0/virt/virt_vcpu-0 -> rate >> a0/virt/virt_vcpu-1 >> >> collectd "just" reports the changes since the last sampling. I'm not sure >> which is the best way to handle that; I've sent a mail to collectd list >> some time ago, no answer so far. >> > > Can you CC on that thread? > I don't know how ES would work with rates at all. > I want to be able to show CPU usage over time and I need to know if its > 80% or 10%. > > > Thanks to the awkward gmail interface I can't reply to myself and CC other > people, but I can share the link: > > https://mailman.verplant.org/pipermail/collectd/2017-January/006965.html > > -- > Francesco Romani > Red Hat Engineering Virtualization R & D > IRC: fromani > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [monitoring][collectd] the collectd virt plugin is now on par with Vdsm needs
Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Wed, Feb 22, 2017 at 5:57 PM, Francesco Romani <from...@redhat.com> wrote: > On 02/21/2017 11:55 PM, Yaniv Dary wrote: > > > > Yaniv Dary > Technical Product Manager > Red Hat Israel Ltd. > 34 Jerusalem Road > Building A, 4th floor > Ra'anana, Israel 4350109 > > Tel : +972 (9) 7692306 <+972%209-769-2306> > 8272306 > Email: yd...@redhat.com > IRC : ydary > > On Feb 21, 2017 13:06, "Francesco Romani" <from...@redhat.com> wrote: > > Hello everyone, > > > in the last weeks I've been submitting PRs to collectd upstream, to > bring the virt plugin up to date with Vdsm and oVirt needs. > > Previously, the collectd virt plugin reported only a subset of metrics > oVirt uses. > > In current collectd master, the collectd virt plugin provides all the > data Vdsm (thus Engine) needs. This means that it is now > > possible for Vdsm or Engine to query collectd, not Vdsm/libvirt, and > have the same data. > > > There are only two caveats: > > 1. it is yet to be seen which version of collectd will ship all those > enhancements > > 2. collectd *intentionally* report metrics as rates, not as absolute > values as Vdsm does. This may be one issue in presence of restarts/data > loss in the link between collectd and the metrics store. > > > How does this work? > If we want to show memory usage over time for example, we need to have the > usage, not the rate. > How would this be reported? > > > I was imprecise, my fault. > > Let me retry: > collectd intentionally report quite a lot of metrics we care about as > rates, not as absolute values. > Memory is actually ok fine. > > a0/virt/disk_octets-hdc -> rate > a0/virt/disk_octets-vda > a0/virt/disk_ops-hdc -> rate > a0/virt/disk_ops-vda > a0/virt/disk_time-hdc -> rate > a0/virt/disk_time-vda > a0/virt/if_dropped-vnet0 -> rate > a0/virt/if_errors-vnet0 -> rate > a0/virt/if_octets-vnet0 -> rate > a0/virt/if_packets-vnet0 -> rate > a0/virt/memory-actual_balloon -> absolute > a0/virt/memory-rss -> absolute > a0/virt/memory-total -> absolute > a0/virt/ps_cputime -> rate > a0/virt/total_requests-flush-hdc -> rate > a0/virt/total_requests-flush-vda > a0/virt/total_time_in_ms-flush-hdc -> rate > a0/virt/total_time_in_ms-flush-vda > a0/virt/virt_cpu_total -> rate > a0/virt/virt_vcpu-0 -> rate > a0/virt/virt_vcpu-1 > > collectd "just" reports the changes since the last sampling. I'm not sure > which is the best way to handle that; I've sent a mail to collectd list > some time ago, no answer so far. > Can you CC on that thread? I don't know how ES would work with rates at all. I want to be able to show CPU usage over time and I need to know if its 80% or 10%. > > > > > -- > Francesco Romani > Red Hat Engineering Virtualization R & D > IRC: fromani > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [REQUEST FOR COMMENTS] oVirt features tracking and documentation
If we want users to touch features we need someone at some point to open a BZ on it. It doesn't have to be the contributor. GitHub pull requests or any other code related tracking is good only to the developer level, not docs\user\QE. Thanks, Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Wed, Feb 22, 2017 at 5:26 PM, Martin Sivak <msi...@redhat.com> wrote: > How are we going to track possible contributions from the community? > Those won't have any bugzilla associated in general. And we want them > and we want to lower the hurdle for other people to contribute. > Especially for the side projects we have (the engine is quite a beast, > but we have smaller or new projects where it is not that hard to > contribute). > > Projects using GitHub track everything using pull requests. Those > generally serve as the umbrella for all the associated changes and > issues. We do not have anything like that. Bugzilla maps to issues and > Gerrit changes map to the code part of pull requests. We do not have > the documentation and design in the sources either so we can't check > for those to be provided together with the patch. > > -- > Martin Sivakl > oVirt / SLA > > On Wed, Feb 22, 2017 at 3:43 PM, Yaniv Dary <yd...@redhat.com> wrote: > > As long as a RFE is created at some point for tracking the testing and > docs > > I don't mind letting them in. > > If no RFE is created it will get lost and no one will probably use the > > feature, which will be a waste of time for the developer working on that. > > Feature page can probably be a good option to automate a required url, > since > > this is also a good option to provide details on the work being done. > > > > Yaniv Dary > > Technical Product Manager > > Red Hat Israel Ltd. > > 34 Jerusalem Road > > Building A, 4th floor > > Ra'anana, Israel 4350109 > > > > Tel : +972 (9) 7692306 > > 8272306 > > Email: yd...@redhat.com > > IRC : ydary > > > > > > On Tue, Feb 21, 2017 at 1:01 PM, Sandro Bonazzola <sbona...@redhat.com> > > wrote: > >> > >> > >> > >> On Tue, Feb 21, 2017 at 11:56 AM, Michal Skrivanek > >> <michal.skriva...@redhat.com> wrote: > >>> > >>> > >>> On 21 Feb 2017, at 09:36, Eyal Edri <ee...@redhat.com> wrote: > >>> > >>> > >>> > >>> On Tue, Feb 21, 2017 at 10:34 AM, Sandro Bonazzola < > sbona...@redhat.com> > >>> wrote: > >>>> > >>>> > >>>> > >>>> On Tue, Feb 21, 2017 at 9:31 AM, Eyal Edri <ee...@redhat.com> wrote: > >>>>> > >>>>> > >>>>> > >>>>> On Tue, Feb 21, 2017 at 10:20 AM, Sandro Bonazzola > >>>>> <sbona...@redhat.com> wrote: > >>>>>> > >>>>>> Hi, > >>>>>> I'm facing a new challenge today, I see new features getting pushed > to > >>>>>> oVirt gerrit intentionally out of bugzilla. > >>>>>> The specific case is not really relevant, but just for reference: > >>>>>> https://gerrit.ovirt.org/#/c/65761/ . > >>>>>> Looks like we'll see features getting merged without any RFE opened > in > >>>>>> bugzilla for them. > >>> > >>> > >>> this is a common case for master, many patches do not have Bug-Url > >>> including features initially > >>> > >>>>>> With current workflow, auto-generating release notes from bugzilla > >>>>>> doc-texts. this means they won't ever be documented. > >>> > >>> > >>> true. Typically they don’t have to be as for user consumable features > >>> there is typically many patches, and eventually the final part of > feature do > >>> have proper tracking, RFE and so on. > >>> > >>>>>> > >>>>>> I'd like to open this public discussion getting comments about how > >>>>>> things will be handled. > >>>>> > >>>>> > >>>>> We can start enforcing bug-url in master branch as well, maybe under > >>>>> certain conditions. > >>> > >>> > >>> I do not see the current practice as problematic > >>> > >>>> > >>>> The
Re: [ovirt-devel] [monitoring][collectd] the collectd virt plugin is now on par with Vdsm needs
Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Feb 21, 2017 13:06, "Francesco Romani" <from...@redhat.com> wrote: Hello everyone, in the last weeks I've been submitting PRs to collectd upstream, to bring the virt plugin up to date with Vdsm and oVirt needs. Previously, the collectd virt plugin reported only a subset of metrics oVirt uses. In current collectd master, the collectd virt plugin provides all the data Vdsm (thus Engine) needs. This means that it is now possible for Vdsm or Engine to query collectd, not Vdsm/libvirt, and have the same data. There are only two caveats: 1. it is yet to be seen which version of collectd will ship all those enhancements 2. collectd *intentionally* report metrics as rates, not as absolute values as Vdsm does. This may be one issue in presence of restarts/data loss in the link between collectd and the metrics store. How does this work? If we want to show memory usage over time for example, we need to have the usage, not the rate. How would this be reported? Please keep reading for more details: How to get the code? This somehow tricky until we get one official release. If one is familiar with the RPM build process, it is easy to build one custom packages from a snapshot from collectd master (https://github.com/collectd/collectd) and a recent 5.7.1 RPM (like https://koji.fedoraproject.org/koji/buildinfo?buildID=835669) How to configure it? -- Most thing work out of the box. One currently in progress Vdsm patch ships the recommended configuration https://gerrit.ovirt.org/#/c/71176/6/static/etc/collectd.d/virt.conf The meaning of the configuration option is documented in man 5 collectd.conf How it looks like? -- Let me post one "screenshot" :) $ collectdctl listval | grep a0 a0/virt/disk_octets-hdc a0/virt/disk_octets-vda a0/virt/disk_ops-hdc a0/virt/disk_ops-vda a0/virt/disk_time-hdc a0/virt/disk_time-vda a0/virt/if_dropped-vnet0 a0/virt/if_errors-vnet0 a0/virt/if_octets-vnet0 a0/virt/if_packets-vnet0 a0/virt/memory-actual_balloon a0/virt/memory-rss a0/virt/memory-total a0/virt/ps_cputime a0/virt/total_requests-flush-hdc a0/virt/total_requests-flush-vda a0/virt/total_time_in_ms-flush-hdc a0/virt/total_time_in_ms-flush-vda a0/virt/virt_cpu_total a0/virt/virt_vcpu-0 a0/virt/virt_vcpu-1 How to consume the data? - Among the ways to query collectd, the two most popular (and most fitting for oVirt use case) ways are perhaps the network protocol (https://collectd.org/wiki/index.php/Binary_protocol) and the plain text protocol (https://collectd.org/wiki/index.php/Plain_text_protocol). The first could be used by Engine to get the data directly, or to consolidate the metrics in one database (e.g to run any kind of query, for historical series...). The latter will be used by Vdsm to keep reporting the metrics (again https://gerrit.ovirt.org/#/c/71176/6) Please note that the performance of the plain text protocol are known to be lower than the binary protocol What about the unresponsive hosts? --- We know from experience that hosts may become unresponsive, and this can disrupt monitoring. however, we do want to keep monitoring the responsive hosts, avoiding that one rogue hosts makes us lose all the monitoring data. To cope with this need, the virt plugin gained support for "partition tag". With this, we can group VMs together using one arbitrary tag. This is completely transparent to collectd, and also completely optional. oVirt can use this tag to group VMs per-storage-domain, or however it sees fit, trying to minimize the disruption should one host become unresponsive. Read the full docs here: https://github.com/collectd/collectd/commit/999efc28d8e2e96bc15f535254d412 a79755ca4f What about the collectd-ovirt plugin? Some time ago I implemented one out-of-tree collectd plugin leveraging the libvirt bulk stats: https://github.com/fromanirh/collectd-ovirt This plugin is meant to be a modern, drop-in replacement for the existing virt plugin. The development of that out of tree plugin is now halted, because we have everything we need in the upstream collectd plugin. Future work -- We believe we have reached feature parity, so we are looking for bugixes/performance tuning in the near term future. I'll be happy to provide more patches/PRs about that. Thanks and bests, -- Francesco Romani Red Hat Engineering Virtualization R & D IRC: fromani ___ Devel mailing list Devel@ovirt.org http:
Re: [ovirt-devel] BZ#1375139 VM lost its disk after snapshot preview/commit
We will be fixing this in the 4.1 GA which is out soon, due to the complexity. If you want, you can try out the RC. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Sun, Jan 22, 2017 at 2:15 PM, Daniel Erez <de...@redhat.com> wrote: > > > On Wed, Jan 18, 2017 at 10:59 AM, Yaniv Dary <yd...@redhat.com> wrote: > >> Did we instruct to test these flow to reduce this risk? >> What are the relevant cases? >> > > The main scenario we've addressed is removing any newer snapshots after > restoring an older one > (of course only in case that we don't use any disk from the newer > snapshots). > This is done to simplify the behavior and avoid confusing scenarios that > we don't support > (i.e. prevent previewing VM configuration of a newer snapshot after > restoring an older snapshot). > > >> >> Yaniv Dary >> Technical Product Manager >> Red Hat Israel Ltd. >> 34 Jerusalem Road >> Building A, 4th floor >> Ra'anana, Israel 4350109 >> >> Tel : +972 (9) 7692306 <+972%209-769-2306> >> 8272306 >> Email: yd...@redhat.com >> IRC : ydary >> >> >> On Wed, Jan 18, 2017 at 1:34 AM, Tal Nisan <tni...@redhat.com> wrote: >> >>> It's indeed an edge case and the fix suggested while in theory better >>> than the condition before it still is quite risky. >>> Take into consideration that the old mechanism while flawed in this >>> particular case worked flawlessly for a few versions now so we've decided >>> that replacing the existing mechanism for zstream as well is not a good >>> idea. >>> >>> >>> On Sun, Jan 15, 2017 at 4:55 PM, Yaniv Dary <yd...@redhat.com> wrote: >>> >>>> Can we consider a backport? >>>> How complex is the fix? >>>> >>>> Yaniv Dary >>>> Technical Product Manager >>>> Red Hat Israel Ltd. >>>> 34 Jerusalem Road >>>> Building A, 4th floor >>>> Ra'anana, Israel 4350109 >>>> >>>> Tel : +972 (9) 7692306 <+972%209-769-2306> >>>> 8272306 >>>> Email: yd...@redhat.com >>>> IRC : ydary >>>> >>>> >>>> On Mon, Jan 9, 2017 at 4:43 PM, Pavel Gashev <p...@acronis.com> wrote: >>>> >>>>> Yaniv, >>>>> >>>>> >>>>> >>>>> Yes, I’ve encountered it in 4.0.5.5. That’s why I started looking for >>>>> existing bugs. >>>>> >>>>> >>>>> >>>>> Thank you so much >>>>> >>>>> >>>>> >>>>> *From: *Yaniv Dary <yd...@redhat.com> >>>>> *Date: *Monday 9 January 2017 at 17:35 >>>>> *To: *Pavel Gashev <p...@acronis.com> >>>>> *Cc: *Vinzenz Feenstra <vfeen...@redhat.com>, "devel@ovirt.org" < >>>>> devel@ovirt.org> >>>>> >>>>> *Subject: *Re: [ovirt-devel] BZ#1375139 VM lost its disk after >>>>> snapshot preview/commit >>>>> >>>>> >>>>> >>>>> The flow seem to be a edge case. >>>>> >>>>> We can reconsider, have you encountered this issue? >>>>> >>>>> >>>>> Yaniv Dary >>>>> >>>>> Technical Product Manager >>>>> >>>>> Red Hat Israel Ltd. >>>>> >>>>> 34 Jerusalem Road >>>>> >>>>> Building A, 4th floor >>>>> >>>>> Ra'anana, Israel 4350109 >>>>> >>>>> >>>>> >>>>> Tel : +972 (9) 7692306 <+972%209-769-2306> >>>>> >>>>> 8272306 >>>>> >>>>> Email: yd...@redhat.com >>>>> >>>>> IRC : ydary >>>>> >>>>> >>>>> >>>>> On Mon, Jan 9, 2017 at 4:25 PM, Pavel Gashev <p...@acronis.com> wrote: >>>>> >>>>> It’s weird, isn’t it? That solution is not accepted, but the issue >>>>> still does exist in 4.0. >>>>> >>>>> There are two bugs (BZ#1379131 and BZ#1375139), but both are switched >>>>> to 4.1. >>>>> >>>>> Does it make sense to create another one? >>>>> >>>>> >>>>> >>>>> Note that the bugs have urgent priority. Users can corrupt their VMs >>>>> via the User Portal. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From: *Vinzenz Feenstra <vfeen...@redhat.com> >>>>> *Date: *Monday 9 January 2017 at 14:25 >>>>> *To: *Pavel Gashev <p...@acronis.com> >>>>> *Cc: *"devel@ovirt.org" <devel@ovirt.org> >>>>> *Subject: *Re: [ovirt-devel] BZ#1375139 VM lost its disk after >>>>> snapshot preview/commit >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Jan 9, 2017, at 12:23 PM, Pavel Gashev <p...@acronis.com> wrote: >>>>> >>>>> >>>>> >>>>> Hello, >>>>> >>>>> >>>>> >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1375139 >>>>> >>>>> >>>>> >>>>> Could somebody confirm, that the issue is not going to be fixed in 4.0? >>>>> >>>>> >>>>> >>>>> It has not been merged to 4.0 branch, so I don’t assume so, the >>>>> backport for 4.0 has been abandoned >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Thanks >>>>> >>>>> >>>>> >>>>> ___ >>>>> Devel mailing list >>>>> Devel@ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>> >>>>> >>>>> >>>>> >>>>> ___ >>>>> Devel mailing list >>>>> Devel@ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>> >>>>> >>>>> >>>> >>>> >>> >> > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] BZ#1375139 VM lost its disk after snapshot preview/commit
Did we instruct to test these flow to reduce this risk? What are the relevant cases? Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Wed, Jan 18, 2017 at 1:34 AM, Tal Nisan <tni...@redhat.com> wrote: > It's indeed an edge case and the fix suggested while in theory better than > the condition before it still is quite risky. > Take into consideration that the old mechanism while flawed in this > particular case worked flawlessly for a few versions now so we've decided > that replacing the existing mechanism for zstream as well is not a good > idea. > > > On Sun, Jan 15, 2017 at 4:55 PM, Yaniv Dary <yd...@redhat.com> wrote: > >> Can we consider a backport? >> How complex is the fix? >> >> Yaniv Dary >> Technical Product Manager >> Red Hat Israel Ltd. >> 34 Jerusalem Road >> Building A, 4th floor >> Ra'anana, Israel 4350109 >> >> Tel : +972 (9) 7692306 <+972%209-769-2306> >> 8272306 >> Email: yd...@redhat.com >> IRC : ydary >> >> >> On Mon, Jan 9, 2017 at 4:43 PM, Pavel Gashev <p...@acronis.com> wrote: >> >>> Yaniv, >>> >>> >>> >>> Yes, I’ve encountered it in 4.0.5.5. That’s why I started looking for >>> existing bugs. >>> >>> >>> >>> Thank you so much >>> >>> >>> >>> *From: *Yaniv Dary <yd...@redhat.com> >>> *Date: *Monday 9 January 2017 at 17:35 >>> *To: *Pavel Gashev <p...@acronis.com> >>> *Cc: *Vinzenz Feenstra <vfeen...@redhat.com>, "devel@ovirt.org" < >>> devel@ovirt.org> >>> >>> *Subject: *Re: [ovirt-devel] BZ#1375139 VM lost its disk after snapshot >>> preview/commit >>> >>> >>> >>> The flow seem to be a edge case. >>> >>> We can reconsider, have you encountered this issue? >>> >>> >>> Yaniv Dary >>> >>> Technical Product Manager >>> >>> Red Hat Israel Ltd. >>> >>> 34 Jerusalem Road >>> >>> Building A, 4th floor >>> >>> Ra'anana, Israel 4350109 >>> >>> >>> >>> Tel : +972 (9) 7692306 <+972%209-769-2306> >>> >>> 8272306 >>> >>> Email: yd...@redhat.com >>> >>> IRC : ydary >>> >>> >>> >>> On Mon, Jan 9, 2017 at 4:25 PM, Pavel Gashev <p...@acronis.com> wrote: >>> >>> It’s weird, isn’t it? That solution is not accepted, but the issue still >>> does exist in 4.0. >>> >>> There are two bugs (BZ#1379131 and BZ#1375139), but both are switched to >>> 4.1. >>> >>> Does it make sense to create another one? >>> >>> >>> >>> Note that the bugs have urgent priority. Users can corrupt their VMs via >>> the User Portal. >>> >>> >>> >>> >>> >>> *From: *Vinzenz Feenstra <vfeen...@redhat.com> >>> *Date: *Monday 9 January 2017 at 14:25 >>> *To: *Pavel Gashev <p...@acronis.com> >>> *Cc: *"devel@ovirt.org" <devel@ovirt.org> >>> *Subject: *Re: [ovirt-devel] BZ#1375139 VM lost its disk after snapshot >>> preview/commit >>> >>> >>> >>> >>> >>> On Jan 9, 2017, at 12:23 PM, Pavel Gashev <p...@acronis.com> wrote: >>> >>> >>> >>> Hello, >>> >>> >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1375139 >>> >>> >>> >>> Could somebody confirm, that the issue is not going to be fixed in 4.0? >>> >>> >>> >>> It has not been merged to 4.0 branch, so I don’t assume so, the backport >>> for 4.0 has been abandoned >>> >>> >>> >>> >>> >>> Thanks >>> >>> >>> >>> ___ >>> Devel mailing list >>> Devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >>> >>> >>> >>> >>> ___ >>> Devel mailing list >>> Devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >>> >>> >>> >> >> > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] BZ#1375139 VM lost its disk after snapshot preview/commit
Can we consider a backport? How complex is the fix? Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Mon, Jan 9, 2017 at 4:43 PM, Pavel Gashev <p...@acronis.com> wrote: > Yaniv, > > > > Yes, I’ve encountered it in 4.0.5.5. That’s why I started looking for > existing bugs. > > > > Thank you so much > > > > *From: *Yaniv Dary <yd...@redhat.com> > *Date: *Monday 9 January 2017 at 17:35 > *To: *Pavel Gashev <p...@acronis.com> > *Cc: *Vinzenz Feenstra <vfeen...@redhat.com>, "devel@ovirt.org" < > devel@ovirt.org> > > *Subject: *Re: [ovirt-devel] BZ#1375139 VM lost its disk after snapshot > preview/commit > > > > The flow seem to be a edge case. > > We can reconsider, have you encountered this issue? > > > Yaniv Dary > > Technical Product Manager > > Red Hat Israel Ltd. > > 34 Jerusalem Road > > Building A, 4th floor > > Ra'anana, Israel 4350109 > > > > Tel : +972 (9) 7692306 <+972%209-769-2306> > > 8272306 > > Email: yd...@redhat.com > > IRC : ydary > > > > On Mon, Jan 9, 2017 at 4:25 PM, Pavel Gashev <p...@acronis.com> wrote: > > It’s weird, isn’t it? That solution is not accepted, but the issue still > does exist in 4.0. > > There are two bugs (BZ#1379131 and BZ#1375139), but both are switched to > 4.1. > > Does it make sense to create another one? > > > > Note that the bugs have urgent priority. Users can corrupt their VMs via > the User Portal. > > > > > > *From: *Vinzenz Feenstra <vfeen...@redhat.com> > *Date: *Monday 9 January 2017 at 14:25 > *To: *Pavel Gashev <p...@acronis.com> > *Cc: *"devel@ovirt.org" <devel@ovirt.org> > *Subject: *Re: [ovirt-devel] BZ#1375139 VM lost its disk after snapshot > preview/commit > > > > > > On Jan 9, 2017, at 12:23 PM, Pavel Gashev <p...@acronis.com> wrote: > > > > Hello, > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1375139 > > > > Could somebody confirm, that the issue is not going to be fixed in 4.0? > > > > It has not been merged to 4.0 branch, so I don’t assume so, the backport > for 4.0 has been abandoned > > > > > > Thanks > > > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > > > > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] BZ#1375139 VM lost its disk after snapshot preview/commit
The flow seem to be a edge case. We can reconsider, have you encountered this issue? Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Mon, Jan 9, 2017 at 4:25 PM, Pavel Gashev <p...@acronis.com> wrote: > It’s weird, isn’t it? That solution is not accepted, but the issue still > does exist in 4.0. > > There are two bugs (BZ#1379131 and BZ#1375139), but both are switched to > 4.1. > > Does it make sense to create another one? > > > > Note that the bugs have urgent priority. Users can corrupt their VMs via > the User Portal. > > > > > > *From: *Vinzenz Feenstra <vfeen...@redhat.com> > *Date: *Monday 9 January 2017 at 14:25 > *To: *Pavel Gashev <p...@acronis.com> > *Cc: *"devel@ovirt.org" <devel@ovirt.org> > *Subject: *Re: [ovirt-devel] BZ#1375139 VM lost its disk after snapshot > preview/commit > > > > > > On Jan 9, 2017, at 12:23 PM, Pavel Gashev <p...@acronis.com> wrote: > > > > Hello, > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1375139 > > > > Could somebody confirm, that the issue is not going to be fixed in 4.0? > > > > It has not been merged to 4.0 branch, so I don’t assume so, the backport > for 4.0 has been abandoned > > > > > > Thanks > > > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > > > > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Manageiq ova upload is failing
You can only upload the OVA disk and attach it to a VM with 4.1.
Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306
8272306
Email: yd...@redhat.com
IRC : ydary
On Wed, Jan 4, 2017 at 10:53 AM, Tomas Jelinek <tjeli...@redhat.com> wrote:
>
> On Wed, Jan 4, 2017 at 9:39 AM, Piotr Kliczewski <
> piotr.kliczew...@gmail.com> wrote:
>
>> On Wed, Jan 4, 2017 at 6:51 AM, Michal Skrivanek <mskri...@redhat.com>
>> wrote:
>> >> On 03 Jan 2017, at 23:59, Piotr Kliczewski <piotr.kliczew...@gmail.com>
>> wrote:
>> >>
>> >> All,
>> >>
>> >> I want to upload manageiq ova from [1] when I attempted to do it I see:
>> >>
>> >> on the engine side:
>> >>
>> >> 2017-01-03 23:43:59,318+01 ERROR
>> >> [org.ovirt.engine.core.bll.GetVmFromOvaQuery] (default task-1)
>> >
>> > You're falling for the confusing trap we created:)
>> > OVA in oVirt is for vmware ova conversion, not for importing ovirt
>> > native-like images. For that you need to use the old and cumbersome
>> > flow of export/import via export domain
>>
>> I looked for it initially and noticed that ovirt-image-uploader is not
>> there in 4.1.
>>
>> Is there any other way to do it?
>>
>
> you should be able to go to webadmin to disks tab and upload it from there.
>
>
>>
>> >
>> >> [33a1d8b5-8cec-4b00-9a35-ee9f1d9635b2] Exception:
>> >> org.ovirt.engine.core.common.errors.EngineException: EngineException:
>> >> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException:
>> >> VDSGenericException: VDSErrorException: Failed to GetOvaInfoVDS, error
>> >> = Error parsing ovf information: no memory size, code = -32603 (Failed
>> >> with error unexpected and code 16)
>> >>at org.ovirt.engine.core.bll.VdsHandler.handleVdsResult(VdsHand
>> ler.java:118)
>> >> [bll.jar:]
>> >>at org.ovirt.engine.core.bll.VDSBrokerFrontendImpl.runVdsComman
>> d(VDSBrokerFrontendImpl.java:33)
>> >> [bll.jar:]
>> >>at org.ovirt.engine.core.bll.QueriesCommandBase.runVdsCommand(Q
>> ueriesCommandBase.java:242)
>> >> [bll.jar:]
>> >>at org.ovirt.engine.core.bll.GetVmFromOvaQuery.getVmInfoFromOva
>> File(GetVmFromOvaQuery.java:24)
>> >> [bll.jar:]
>> >>at org.ovirt.engine.core.bll.GetVmFromOvaQuery.executeQueryComm
>> and(GetVmFromOvaQuery.java:20)
>> >> [bll.jar:]
>> >>at org.ovirt.engine.core.bll.QueriesCommandBase.executeCommand(
>> QueriesCommandBase.java:110)
>> >> [bll.jar:]
>> >>at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandB
>> ase.java:33)
>> >> [dal.jar:]
>> >>at org.ovirt.engine.core.bll.executor.DefaultBackendQueryExecut
>> or.execute(DefaultBackendQueryExecutor.java:14)
>> >> [bll.jar:]
>> >>at org.ovirt.engine.core.bll.Backend.runQueryImpl(Backend.java:
>> 579)
>> >> [bll.jar:]
>> >>at org.ovirt.engine.core.bll.Backend.runQuery(Backend.java:547)
>> >> [bll.jar:]
>> >>
>> >> on the vdsm side:
>> >>
>> >> 2017-01-03 23:43:58,437 ERROR (jsonrpc/0) [jsonrpc.JsonRpcServer]
>> >> Internal server error (__init__:552)
>> >> Traceback (most recent call last):
>> >> File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line
>> >> 547, in _handle_request
>> >>res = method(**params)
>> >> File "/usr/lib/python2.7/site-packages/vdsm/rpc/Bridge.py", line
>> >> 198, in _dynamicMethod
>> >>result = fn(*methodArgs)
>> >> File "/usr/share/vdsm/API.py", line 1493, in getExternalVmFromOva
>> >>return v2v.get_ova_info(ova_path)
>> >> File "/usr/lib/python2.7/site-packages/vdsm/v2v.py", line 226, in
>> get_ova_info
>> >>_add_general_ovf_info(vm, root, ns, ova_path)
>> >> File "/usr/lib/python2.7/site-packages/vdsm/v2v.py", line 1225, in
>> >> _add_general_ovf_info
>> >>raise V2VError('Error parsing ovf information: no memory size')
>> >> V2VError: Error parsing ovf information: no memory size
>> >>
>> >> Is our code not parsing correctly or manageiq guys publish not correct
>> file?
>> >>
>> >> I am using:
>> >> ovirt-engine
>> >> Version : 4.1.0
>> >> Release : 0.3.beta2.20161221085908.el7.centos
>> >> vdsm
>> >> Version : 4.18.999
>> >> Release : 1218.gitd36143e.el7.centos
>> >>
>> >> Thanks,
>> >> Piotr
>> >>
>> >>
>> >> [1] http://manageiq.org/download/
>> >> ___
>> >> Devel mailing list
>> >> Devel@ovirt.org
>> >> http://lists.ovirt.org/mailman/listinfo/devel
>> >>
>> >>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [RFE] treat local NFS storage as localfs
Also NFS had locking issues on loopback. Not really possible to do this with NFS. What is the issue with using a Gluster local replicate 1 for this? Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Wed, Dec 21, 2016 at 8:03 PM, Michal Skrivanek <mskri...@redhat.com> wrote: > > On 21 Dec 2016, at 16:26, Martin Sivak <msi...@redhat.com> wrote: > > > > Hi, > > > >> Hope this get's in. This seems less overhead than a complete > >> hyperconverged gluster setup. > > > > But NFS still is a single point of failure. Hyperconverged is supposed > > to address that. > > > >>> In order to improve performance, disk I/O bound VMs can be pinned to > >>> a host with local storage. However there still is a performance > >>> drawback of NFS layers. Treating a local NFS storage as a local storage > >>> improves performance for VMs pinned to host. > > > > So VMs on one host will get better IO performance and the others will > > still use NFS as they do now. > > > > It is an interesting idea, I am just not sure if having poor-man's > > hyperconverged setup with all the drawbacks of NFS is worth it. > > Imagine for example what happens when that storage provider host needs > > to be fenced or put into maintenance. The whole cluster would go down > > (all VMs would lose storage connection, not just the VMs from the > > affected host). > > > > I will let someone from the storage team to respond to this, but I do > > not think that trading performance (each host has its own local > > storage) and resilience (well, at least one failing host does not > > affect the others) for migrations is a good deal. > > If disk performance is critical then there is an option to use direct > access on local host using either PCI passthrough of a local storage > controller or SCSI passthrough of LUNs. > > > > > -- > > Martin Sivak > > SLA / oVirt > > > >> On Wed, Dec 21, 2016 at 2:18 PM, Sven Kieske <s.kie...@mittwald.de> > wrote: > >>> On 21/12/16 11:44, Pavel Gashev wrote: > >>> Hello, > >>> > >>> I'd like to introduce a RFE that allows to use a local storage in multi > >>> server environments https://bugzilla.redhat.com/ > show_bug.cgi?id=1406412 > >>> > >>> Most servers have a local storage. Some servers have very reliable > >>> storages with hardware RAID controllers and battery units. > >>> > >>> Example user cases: > >>> https://www.mail-archive.com/users@ovirt.org/msg36719.html > >>> https://www.mail-archive.com/users@ovirt.org/msg36772.html > >>> > >>> The best way to use local storage in multi server "shared" datacenters > >>> is exporting it over NFS. Using NFS allows to move disks and VMs among > >>> servers. > >>> > >>> In order to improve performance, disk I/O bound VMs can be pinned to > >>> a host with local storage. However there still is a performance > >>> drawback of NFS layers. Treating a local NFS storage as a local storage > >>> improves performance for VMs pinned to host. > >>> > >>> Currently setting up of NFS exports is out of scope of oVirt. However > >>> this would be a way to get rid of "Local/Shared" storage types of > >>> datacenter. So that all storages are shared, but local storages are > >>> used as local. > >>> > >>> Any questions/comments are welcome. > >>> > >>> Specifically I'd like to request for comment on potential data > >>> integrity issues during online VM or disk migration between NFS and > >>> localfs. > >>> > >> > >> Just let me say that I really like this as an end user. > >> > >> Hope this get's in. This seems less overhead than a complete > >> hyperconverged gluster setup. > >> > >> > >> -- > >> Mit freundlichen Grüßen / Regards > >> > >> Sven Kieske > >> > >> Systemadministrator > >> Mittwald CM Service GmbH & Co. KG > >> Königsberger Straße 6 > >> 32339 Espelkamp > >> T: +495772 293100 > >> F: +495772 29 > >> https://www.mittwald.de > >> Geschäftsführer: Robert Meyer > >> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad > Oeynhausen > >> Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad > Oeynhausen > >> > >> > >> ___ > >> Devel mailing list > >> Devel@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/devel > > ___ > > Devel mailing list > > Devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > > > > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Heads-up: moving Libvirt xml creation to the engine
Does this mean we will be able to move the hooks to the engine side at some point? That would be much better than needing it on VDSM. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Wed, Nov 23, 2016 at 6:12 PM, Arik Hadas <aha...@redhat.com> wrote: > > > - Original Message - > > Hi, > > > > Arik there is also custom metadata section for MOM and QoS in the > > libvirt domain XML and those values are now created as XML and later > > manipulated using libvirt API. VDSM will still need to know at least > > some basic stuff about the XML to be able to process it correctly (the > > metadata descriptor and the structure for example). > > Besides the parsing of the devices that we would love to get rid of, I > believe the parsing of Libvirt XML done by VDSM would remain as is. > > > > > Will the engine assume anything about the XML post-migration (for > > example to speed-up restarts for highly available VMs)? Because the > > hooks can change it significantly. Start hooks will be used anyway, > > but migration hook changes might not be reflected during the restart. > > > > Not sure that I fully understand. > You have a VM with configuration conf1 running on host1. While being > migrated to host2 the configuration is changed to conf2. > Do you suggest that the next time the VM restarts it would be created > based on conf2? > > Changes in the devices would be reflected on the next run (assuming the > engine got the updated devices) - as today. > Other than the devices, no configuration that is used on VM creation > (static data) is read back by the engine so if it is changed it won't be > reflected. > And at the moment we have no plan to change the content of the data that > is passed between the engine and VDSM, only its representation. > > Btw, I'm taking back my statement about migration: > "5. Not to re-generate the XML on each rerun attempt of VM run/migration." > VM migration flow is irrelevant since the engine doesn't pass the VM > configuration. It will remain as-is. > > > > > Martin > > > > > > > > On Wed, Nov 23, 2016 at 1:59 PM, Arik Hadas <aha...@redhat.com> wrote: > > > Hi All, > > > > > > We are working on something that is expected to have a big impact, > hence > > > this heads-up. > > > First, we want you to be aware of this change and provide your > feedback to > > > make it as good as possible. > > > Second, until the proposed mechanism is fully merged there will be a > chase > > > to cover all features unless new features are also implemented with the > > > new mechanism. So please, if you are working on something that > > > adds/changes something in the Libvirt's domain xml, do it with this new > > > mechanism as well (first version would be merged soon). > > > > > > * Goal > > > Creating Libvirt XML in the engine rather than in VDSM. > > > ** Today's flow > > > Engine: VM business entity -> VM properties map > > > VDSM: VM properties map -> Libvirt XML > > > ** Desired flow > > > Engine: VM business entity -> Libvirt XML > > > > > > * Potential Benefits > > > 1. Reduce the number of conversions from 2 to 1, reducing chances for > > > mistakes in the process. > > > 2. Reduce the amount of code in VDSM. > > > 3. Make VM related changes easier - today many of these changes need > to be > > > reviewed in 2 projects, this will eliminate the one that tends to take > > > longer. > > > 4. Prevent shortcuts in the form of VDSM-only changes that should be > better > > > reflected in the engine. > > > 5. Not to re-generate the XML on each rerun attempt of VM > run/migration. > > > 6. Future - not to re-generate the XML on each attempt to auto-start > HA VM > > > when using vm-leases (need to make sure we're using the up-to-date VM > > > configuration though). > > > 7. We already found improvements and cleanups that could be made while > > > touching this area (e.g., remove the boot order from devices in the > > > database). > > > > > > * Challenges > > > 1. Not to move host-specific information to the engine. For example, > path > > > to storage domain or sockets of channels. > > >The solution is to use place-holders that will be replaced by VDSM. > > > 2. Backward comp
Re: [ovirt-devel] [ANN] Changes to oVirt Bugzilla Process.
These changes are now in place, please report any issues you may encounter. Thanks, Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Mon, Oct 31, 2016 at 10:22 AM, Yaniv Dary <yd...@redhat.com> wrote: > Hi, > In order to make the process lighter and reduce bureaucracy we will be > making the following changes this Sunday (06/11/16): > > - *Acks will no longer be needed on bugs, only on RFEs* - This means the > rules engine will not add them and you are not required to get them for > bugs. RFEs will still get acks by rules engine and are required for every > feature. > > - *Flags be set automatically according to milestone - *This means you > will no longer need to add flags. The rules engine will do this for you > according to milestone. You will still be able to add flags to mark a bug > to be tested on two branches. > > - *The version flag will not differentiate between major version and z > stream - *This change will only apply to 4.1+ flags. For example > ovirt-4.1.0 and ovirt-4.1.z will be merged to ovirt-4.1 flag. > > Thanks, > > Yaniv Dary > Technical Product Manager > Red Hat Israel Ltd. > 34 Jerusalem Road > Building A, 4th floor > Ra'anana, Israel 4350109 > > Tel : +972 (9) 7692306 > 8272306 > Email: yd...@redhat.com > IRC : ydary > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Password for database in ovirt-system-tests/basic_suite_3.6
You can also ssh to the engine machine and then su to postgres user and connect in this way without password. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Thu, Oct 6, 2016 at 12:00 PM, Dominik Holler <dhol...@redhat.com> wrote: > On Thu, Oct 06, 2016 at 10:54:53AM +0200, Ondra Machacek wrote: > > On 10/06/2016 10:33 AM, Dominik Holler wrote: > > > Hi, > > > I want to have a look at the database in > > > ovirt-system-tests/basic_suite_3.6, but unfortunately I do not know > the > > > password for the database. I tried already various ones by: > > > [root@lago_basic_suite_3_6_engine ~]# psql -U engine -p 5432 -h > 127.0.0.1 > > > > > > Can anyone give me a hint how to get the password for the database? > > > > It's in file /etc/ovirt-engine/engine.conf.d/10-setup-database.conf > > > > $ grep PASSWORD /etc/ovirt-engine/engine.conf.d/10-setup-database.conf > > ENGINE_DB_PASSWORD="" > > > > Thanks, I just want to confirm this work. > > > > > > > Thanks, > > > Dominik > > > ___ > > > Devel mailing list > > > Devel@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/devel > > > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] [ANN] Changes to oVirt Bugzilla Process.
Hi, In order to make the process lighter and reduce bureaucracy we will be making the following changes this Sunday (06/11/16): - *Acks will no longer be needed on bugs, only on RFEs* - This means the rules engine will not add them and you are not required to get them for bugs. RFEs will still get acks by rules engine and are required for every feature. - *Flags be set automatically according to milestone - *This means you will no longer need to add flags. The rules engine will do this for you according to milestone. You will still be able to add flags to mark a bug to be tested on two branches. - *The version flag will not differentiate between major version and z stream - *This change will only apply to 4.1+ flags. For example ovirt-4.1.0 and ovirt-4.1.z will be merged to ovirt-4.1 flag. Thanks, Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] virt moving to trello
While I don't have a issue with this for development time. It is require that ever RFE you work on is tracked in Bugzilla and status is updated for program convergence monitoring (POST and MODIFIED). This is also needed for early engagement on docs and doc text. Please confirm this will be maintained. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Mon, Sep 26, 2016 at 5:47 PM, Roy Golan <rgo...@redhat.com> wrote: > > > On 23 September 2016 at 16:21, Michal Skrivanek < > michal.skriva...@redhat.com> wrote: > >> Hi all, >> we’ve decided to open up our oVirt “virt” team and improve visibility of >> what we are working on right now. Bugzilla is utterly insufficient and it >> is tricky to see high level, long term items and how they evolve. >> So from now on you can check that out on trello[1] >> There’s not much yet, but the content will improve as we gradually >> transition feature design and tracking over there. >> >> Note we are not abandoning bugzilla, we still use it for bug-level >> tracking, for smaller and targeted things. Just those bigger awesome >> upcoming items are going to be on trello board from now on. >> >> Thanks, >> michal >> >> > +1 I think it's important and useful to publish what the team is doing or > planning to do. I hope that other teams will follow. > Have you got plans to expose the link under ovirt.org? > > [1] https://trello.com/b/pWlunZVR/ovirt-virt >> ___ >> Devel mailing list >> Devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel > > > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ACTION REQUIRED] OpenVSwitch configuration changes
Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Wed, Sep 14, 2016 at 5:03 PM, Tony James <t...@anthonyjames.org> wrote: > On September 14, 2016 at 8:57:14 AM, Yaniv Dary (yd...@redhat.com) wrote: > > It is not run if you don't choose to deploy external provider on the host > > add dialog. > > It won't do that if you don't choose it. > > True, thanks for clarifying. Why do we provide the option if using it > is not supported? Will this be removed in a future release? > > Basically the process of configuring the Neutron provider is: > > 1. Add the provider to RHV-M/ovirt-engine > 2. Add a host without selecting the Neutron provider > We should hide it and I think there is a bug on this. Meni? > 3. Manually install and configure the Neutron Open vSwitch agent on the > host > Yes > > Am I correct that this is the supported approach? > > > > > Yaniv Dary > > Technical Product Manager > > Red Hat Israel Ltd. > > 34 Jerusalem Road > > Building A, 4th floor > > Ra'anana, Israel 4350109 > > > > Tel : +972 (9) 7692306 > > 8272306 > > Email: yd...@redhat.com > > IRC : ydary > > > > > > On Wed, Sep 14, 2016 at 4:44 PM, Tony James wrote: > > > > > On September 14, 2016 at 8:40:09 AM, Yaniv Dary (yd...@redhat.com) > wrote: > > > > Yaniv Dary > > > > Technical Product Manager > > > > Red Hat Israel Ltd. > > > > 34 Jerusalem Road > > > > Building A, 4th floor > > > > Ra'anana, Israel 4350109 > > > > > > > > Tel : +972 (9) 7692306 > > > > 8272306 > > > > Email: yd...@redhat.com > > > > IRC : ydary > > > > > > > > > > > > On Wed, Sep 14, 2016 at 4:36 PM, Tony James wrote: > > > > > > > > > On September 14, 2016 at 3:13:41 AM, Yaniv Dary (yd...@redhat.com) > > > wrote: > > > > > > We will not be support installation for OSP. This is not part of > the > > > > > > supported feature we added in 4.0. > > > > > > > > > > In the process of deploying a node/hypervisor ovirt_host_deploy > tries > > > > > to run the openstack-config command to write the bridge_mappings > entry > > > > > to the Open vSwitch agent INI file. This fails without the patch > due > > > > > to the path change. Are you saying that this is not supported? If > > > > > that is the case what is the supported process for leveraging an > OSP 8 > > > > > Neutron provider with RHV 4/oVirt 4? OSP 8 support is explicitly > > > > > called out in the RHV 4 release announcement. > > > > > > > > > > > > > We expect the Neutron agent to be configured either in provision time > > > prior > > > > to add host or manual configuration. > > > > We can't supply a installer for OSP. Please fill free to open a RFE > to > > > > support this via director. > > > > > > I understand installing OSP is outside the scope of support and that > > > the Neutron Open vSwitch agent configuration needs to be performed > > > manually but adding a node/host via RHV-M/ovirt-engine fails because > > > part of the ovirt_host_deploy process is to touch the agent INI file. > > > Are you saying the Neutron external provider should not be selected on > > > the add host screen? > > > > > > > > > > > > > > > > > > > > > > We will not be testing this or making fixes. We can accept > patches > > > and > > > > > help > > > > > > with review, but it will be a upstream driven effort and needs > to be > > > > > > backwords compatible. > > > > > > > > > > > > Yaniv Dary > > > > > > Technical Product Manager > > > > > > Red Hat Israel Ltd. > > > > > > 34 Jerusalem Road > > > > > > Building A, 4th floor > > > > > > Ra'anana, Israel 4350109 > > > > > > > > > > > > Tel : +972 (9) 7692306 > > > > > > 8272306 > > > > > > Email: yd...@redhat.com > > > > > > IRC : ydary > > > > > > > > > > > > > > >
Re: [ovirt-devel] [ACTION REQUIRED] OpenVSwitch configuration changes
It is not run if you don't choose to deploy external provider on the host add dialog. It won't do that if you don't choose it. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Wed, Sep 14, 2016 at 4:44 PM, Tony James <t...@anthonyjames.org> wrote: > On September 14, 2016 at 8:40:09 AM, Yaniv Dary (yd...@redhat.com) wrote: > > Yaniv Dary > > Technical Product Manager > > Red Hat Israel Ltd. > > 34 Jerusalem Road > > Building A, 4th floor > > Ra'anana, Israel 4350109 > > > > Tel : +972 (9) 7692306 > > 8272306 > > Email: yd...@redhat.com > > IRC : ydary > > > > > > On Wed, Sep 14, 2016 at 4:36 PM, Tony James wrote: > > > > > On September 14, 2016 at 3:13:41 AM, Yaniv Dary (yd...@redhat.com) > wrote: > > > > We will not be support installation for OSP. This is not part of the > > > > supported feature we added in 4.0. > > > > > > In the process of deploying a node/hypervisor ovirt_host_deploy tries > > > to run the openstack-config command to write the bridge_mappings entry > > > to the Open vSwitch agent INI file. This fails without the patch due > > > to the path change. Are you saying that this is not supported? If > > > that is the case what is the supported process for leveraging an OSP 8 > > > Neutron provider with RHV 4/oVirt 4? OSP 8 support is explicitly > > > called out in the RHV 4 release announcement. > > > > > > > We expect the Neutron agent to be configured either in provision time > prior > > to add host or manual configuration. > > We can't supply a installer for OSP. Please fill free to open a RFE to > > support this via director. > > I understand installing OSP is outside the scope of support and that > the Neutron Open vSwitch agent configuration needs to be performed > manually but adding a node/host via RHV-M/ovirt-engine fails because > part of the ovirt_host_deploy process is to touch the agent INI file. > Are you saying the Neutron external provider should not be selected on > the add host screen? > > > > > > > > > > > > We will not be testing this or making fixes. We can accept patches > and > > > help > > > > with review, but it will be a upstream driven effort and needs to be > > > > backwords compatible. > > > > > > > > Yaniv Dary > > > > Technical Product Manager > > > > Red Hat Israel Ltd. > > > > 34 Jerusalem Road > > > > Building A, 4th floor > > > > Ra'anana, Israel 4350109 > > > > > > > > Tel : +972 (9) 7692306 > > > > 8272306 > > > > Email: yd...@redhat.com > > > > IRC : ydary > > > > > > > > > > > > On Wed, Sep 14, 2016 at 11:11 AM, Nelly Credi wrote: > > > > > > > > > > > > > > > > > > > On Wed, Sep 14, 2016 at 11:09 AM, Sandro Bonazzola > > > > > wrote: > > > > > > > > > >> Hi, we received a patch to ovirt-host-deploy > > > > >> https://gerrit.ovirt.org/63707 related to a change in OpenVSwitch > > > > >> configuration between > > > > >> Red Hat OpenStack Platform 7 or older and Red Hat OpenStack > Platform > > > 8 or > > > > >> newer. > > > > >> > > > > >> - We need to ensure to catch these changes in our testing > > > > >> - We need to ensure oVirt host deploy still works with Red Hat > > > OpenStack > > > > >> Platform 8 or newer. > > > > >> > > > > >> Dan, can you or someone in network team please review the patch? > > > > >> Thanks again Tony for the patch. > > > > >> > > > > >> > > > > >> -- > > > > >> Sandro Bonazzola > > > > >> Better technology. Faster innovation. Powered by community > > > collaboration. > > > > >> See how it works at redhat.com > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > > > -- > > > > > Thanks, > > > > > Nelly > > > > > > > > > > > > > > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ACTION REQUIRED] OpenVSwitch configuration changes
Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Wed, Sep 14, 2016 at 4:36 PM, Tony James <t...@anthonyjames.org> wrote: > On September 14, 2016 at 3:13:41 AM, Yaniv Dary (yd...@redhat.com) wrote: > > We will not be support installation for OSP. This is not part of the > > supported feature we added in 4.0. > > In the process of deploying a node/hypervisor ovirt_host_deploy tries > to run the openstack-config command to write the bridge_mappings entry > to the Open vSwitch agent INI file. This fails without the patch due > to the path change. Are you saying that this is not supported? If > that is the case what is the supported process for leveraging an OSP 8 > Neutron provider with RHV 4/oVirt 4? OSP 8 support is explicitly > called out in the RHV 4 release announcement. > We expect the Neutron agent to be configured either in provision time prior to add host or manual configuration. We can't supply a installer for OSP. Please fill free to open a RFE to support this via director. > > > We will not be testing this or making fixes. We can accept patches and > help > > with review, but it will be a upstream driven effort and needs to be > > backwords compatible. > > > > Yaniv Dary > > Technical Product Manager > > Red Hat Israel Ltd. > > 34 Jerusalem Road > > Building A, 4th floor > > Ra'anana, Israel 4350109 > > > > Tel : +972 (9) 7692306 > > 8272306 > > Email: yd...@redhat.com > > IRC : ydary > > > > > > On Wed, Sep 14, 2016 at 11:11 AM, Nelly Credi wrote: > > > > > > > > > > > On Wed, Sep 14, 2016 at 11:09 AM, Sandro Bonazzola > > > wrote: > > > > > >> Hi, we received a patch to ovirt-host-deploy > > >> https://gerrit.ovirt.org/63707 related to a change in OpenVSwitch > > >> configuration between > > >> Red Hat OpenStack Platform 7 or older and Red Hat OpenStack Platform > 8 or > > >> newer. > > >> > > >> - We need to ensure to catch these changes in our testing > > >> - We need to ensure oVirt host deploy still works with Red Hat > OpenStack > > >> Platform 8 or newer. > > >> > > >> Dan, can you or someone in network team please review the patch? > > >> Thanks again Tony for the patch. > > >> > > >> > > >> -- > > >> Sandro Bonazzola > > >> Better technology. Faster innovation. Powered by community > collaboration. > > >> See how it works at redhat.com > > >> > > >> > > > > > > > > > > > > -- > > > Thanks, > > > Nelly > > > > > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ACTION REQUIRED] OpenVSwitch configuration changes
We will not be support installation for OSP. This is not part of the supported feature we added in 4.0. We will not be testing this or making fixes. We can accept patches and help with review, but it will be a upstream driven effort and needs to be backwords compatible. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Wed, Sep 14, 2016 at 11:11 AM, Nelly Credi <ncr...@redhat.com> wrote: > > > On Wed, Sep 14, 2016 at 11:09 AM, Sandro Bonazzola <sbona...@redhat.com> > wrote: > >> Hi, we received a patch to ovirt-host-deploy >> https://gerrit.ovirt.org/63707 related to a change in OpenVSwitch >> configuration between >> Red Hat OpenStack Platform 7 or older and Red Hat OpenStack Platform 8 or >> newer. >> >> - We need to ensure to catch these changes in our testing >> - We need to ensure oVirt host deploy still works with Red Hat OpenStack >> Platform 8 or newer. >> >> Dan, can you or someone in network team please review the patch? >> Thanks again Tony for the patch. >> >> >> -- >> Sandro Bonazzola >> Better technology. Faster innovation. Powered by community collaboration. >> See how it works at redhat.com >> <https://www.redhat.com/it/about/events/red-hat-open-source-day-2016> >> > > > > -- > Thanks, > Nelly > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] ovirt-image-upload fails with NFS error when using a local disk
Once you upload a disk, you can use it for a VM, create a template from it
or export it to export domain.
Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306
8272306
Email: yd...@redhat.com
IRC : ydary
On Thu, Aug 25, 2016 at 11:48 AM, Lynn Dixon <ldi...@redhat.com> wrote:
> I see the option to upload a machines disk file into the Data storage
> domain under "disks" but I don't see an option to upload anything into the
> export or ISO domains.
> I am trying to upload a cloudforms OVA template image so I can use it as a
> template.
>
> Has the ability to upload ISO's and images into the export domain been
> completed yet?
>
> *Lynn Dixon* | Red Hat Certified Architect #100-006-188
> *Sr. Cloud Consultant* | Cloud Management Practice
> Google Voice: 423-618-1414
> Cell/Text: 423-774-3188
> Click here to view my Certification Portfolio <http://red.ht/1XMX2Mi>
>
>
>
> On Thu, Aug 25, 2016 at 11:56 AM, Yaniv Dary <yd...@redhat.com> wrote:
>
>> You should go to disk and use upload from top bar.
>> Make sure you trust the engine CA in you browser and restart it prior to
>> upload:
>> https://${engine's_URL}/ovirt-engine/services/pki-resource?r
>> esource=ca-certificate=X509-PEM-CA
>>
>>
>> Yaniv Dary
>> Technical Product Manager
>> Red Hat Israel Ltd.
>> 34 Jerusalem Road
>> Building A, 4th floor
>> Ra'anana, Israel 4350109
>>
>> Tel : +972 (9) 7692306
>> 8272306
>> Email: yd...@redhat.com
>> IRC : ydary
>>
>>
>> On Thu, Aug 25, 2016 at 10:55 AM, Lynn Dixon <ldi...@redhat.com> wrote:
>>
>>> Yaniv,
>>> I just upgraded my lab to oVirt 4.0.2.7 last night. I cannot find the
>>> image, or ISO uploader in the GUI anywhere.
>>>
>>> Im assuming its in Storage -> EXPORT domain --> and then on the bottom
>>> pane somewhere.
>>>
>>> Is there something I need to install to enable the GUI uploader?
>>>
>>>
>>>
>>> *Lynn Dixon* | Red Hat Certified Architect #100-006-188
>>> *Sr. Cloud Consultant* | Cloud Management Practice
>>> Google Voice: 423-618-1414
>>> Cell/Text: 423-774-3188
>>> Click here to view my Certification Portfolio <http://red.ht/1XMX2Mi>
>>>
>>>
>>>
>>> On Thu, Aug 25, 2016 at 11:46 AM, Yaniv Dary <yd...@redhat.com> wrote:
>>>
>>>> Why not use the disk image uploader via the GUI to upload the OVA
>>>> directly to a SD?
>>>>
>>>> Yaniv Dary
>>>> Technical Product Manager
>>>> Red Hat Israel Ltd.
>>>> 34 Jerusalem Road
>>>> Building A, 4th floor
>>>> Ra'anana, Israel 4350109
>>>>
>>>> Tel : +972 (9) 7692306
>>>> 8272306
>>>> Email: yd...@redhat.com
>>>> IRC : ydary
>>>>
>>>>
>>>> On Tue, Aug 16, 2016 at 1:48 PM, Lynn Dixon <ldi...@redhat.com> wrote:
>>>>
>>>>> Hey all,
>>>>> I am using oVirt 4.0 and trying to upload an OVA into my export domain
>>>>> using the ovirt-image-uploader tool.
>>>>>
>>>>> My Export domain is a local disk on the host, and is NOT using NFS.
>>>>> However, it seems the ovirt-image-uploader tool assumes my domain is NFS
>>>>> and it will give the following error:
>>>>>
>>>>> ERROR: mount.nfs: Failed to resolve server None: Name or service not
>>>>> known
>>>>>
>>>>> Is there a way to import OVA's in to the Export domain when its using
>>>>> a local disk?
>>>>>
>>>>>
>>>>>
>>>>> *Lynn Dixon* | Red Hat Certified Architect #100-006-188
>>>>> *Sr. Cloud Consultant* | Cloud Management Practice
>>>>> Google Voice: 423-618-1414
>>>>> Cell/Text: 423-774-3188
>>>>> Click here to view my Certification Portfolio <http://red.ht/1XMX2Mi>
>>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> Devel mailing list
>>>>> Devel@ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>>
>>>>
>>>>
>>>
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] ovirt-image-upload fails with NFS error when using a local disk
You should go to disk and use upload from top bar.
Make sure you trust the engine CA in you browser and restart it prior to
upload:
https://
${engine's_URL}/ovirt-engine/services/pki-resource?resource=ca-certificate=X509-PEM-CA
Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306
8272306
Email: yd...@redhat.com
IRC : ydary
On Thu, Aug 25, 2016 at 10:55 AM, Lynn Dixon <ldi...@redhat.com> wrote:
> Yaniv,
> I just upgraded my lab to oVirt 4.0.2.7 last night. I cannot find the
> image, or ISO uploader in the GUI anywhere.
>
> Im assuming its in Storage -> EXPORT domain --> and then on the bottom
> pane somewhere.
>
> Is there something I need to install to enable the GUI uploader?
>
>
>
> *Lynn Dixon* | Red Hat Certified Architect #100-006-188
> *Sr. Cloud Consultant* | Cloud Management Practice
> Google Voice: 423-618-1414
> Cell/Text: 423-774-3188
> Click here to view my Certification Portfolio <http://red.ht/1XMX2Mi>
>
>
>
> On Thu, Aug 25, 2016 at 11:46 AM, Yaniv Dary <yd...@redhat.com> wrote:
>
>> Why not use the disk image uploader via the GUI to upload the OVA
>> directly to a SD?
>>
>> Yaniv Dary
>> Technical Product Manager
>> Red Hat Israel Ltd.
>> 34 Jerusalem Road
>> Building A, 4th floor
>> Ra'anana, Israel 4350109
>>
>> Tel : +972 (9) 7692306
>> 8272306
>> Email: yd...@redhat.com
>> IRC : ydary
>>
>>
>> On Tue, Aug 16, 2016 at 1:48 PM, Lynn Dixon <ldi...@redhat.com> wrote:
>>
>>> Hey all,
>>> I am using oVirt 4.0 and trying to upload an OVA into my export domain
>>> using the ovirt-image-uploader tool.
>>>
>>> My Export domain is a local disk on the host, and is NOT using NFS.
>>> However, it seems the ovirt-image-uploader tool assumes my domain is NFS
>>> and it will give the following error:
>>>
>>> ERROR: mount.nfs: Failed to resolve server None: Name or service not
>>> known
>>>
>>> Is there a way to import OVA's in to the Export domain when its using a
>>> local disk?
>>>
>>>
>>>
>>> *Lynn Dixon* | Red Hat Certified Architect #100-006-188
>>> *Sr. Cloud Consultant* | Cloud Management Practice
>>> Google Voice: 423-618-1414
>>> Cell/Text: 423-774-3188
>>> Click here to view my Certification Portfolio <http://red.ht/1XMX2Mi>
>>>
>>>
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] ovirt-image-upload fails with NFS error when using a local disk
Why not use the disk image uploader via the GUI to upload the OVA directly to a SD? Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Tue, Aug 16, 2016 at 1:48 PM, Lynn Dixon <ldi...@redhat.com> wrote: > Hey all, > I am using oVirt 4.0 and trying to upload an OVA into my export domain > using the ovirt-image-uploader tool. > > My Export domain is a local disk on the host, and is NOT using NFS. > However, it seems the ovirt-image-uploader tool assumes my domain is NFS > and it will give the following error: > > ERROR: mount.nfs: Failed to resolve server None: Name or service not known > > Is there a way to import OVA's in to the Export domain when its using a > local disk? > > > > *Lynn Dixon* | Red Hat Certified Architect #100-006-188 > *Sr. Cloud Consultant* | Cloud Management Practice > Google Voice: 423-618-1414 > Cell/Text: 423-774-3188 > Click here to view my Certification Portfolio <http://red.ht/1XMX2Mi> > > > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Wiki page gone horribly wrong.
Hi, Can you help with correcting: http://www.ovirt.org/develop/developer-guide/vdsm/hooks/ The new version is not working well. This is the old one: http://old.ovirt.org/VDSM-Hooks Thanks, Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] oVirt metrics
We are aiming to add IOPS per VM per Disk in oVirt 4.1. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Wed, Jul 13, 2016 at 2:44 PM, Dominique Taffin <dominique.taf...@1und1.de > wrote: > Hello! > > very nice implementation - and very good blog entry. > > IMHO a very important metric should be made available: IOPS. > > IOPS are a very important factor when using shared storage among a > cluster. It is a key indicator for identifying issues and performance > bottlenecks and also having a base for scaling proper storage devices. > Beeing able to display IOPS per VM would be a great benefit for large > scale enterprises. > > best, > Dominique > > > On Wed, 2016-07-13 at 13:36 +0300, Yaniv Bronheim wrote: > > Hi, > > > > In oVirt-4.0 we introduced integration with metrics collectors, In > > [1] you will find a guide for utilizing your environment to retrieve > > visualized reports about hosts and vms statistics. > > > > I encourage to try that out and send us requests for additional > > valuable metrics that you think vdsm should publish. > > This area is still work in progress and we plan to support more > > technologies and different architectures for metrics collections as > > describes in the post. This will follow by additional links in the > > post ([1]) that describe how to do so.. stay tuned. > > > > [1] https://bronhaim.wordpress.com/2016/06/26/ovirt-metrics > > > > -- > > Yaniv Bronhaim. > > ___ > > Users mailing list > > us...@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > ___ > Users mailing list > us...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Ending support for 3.x engines on master
What is the cost of keeping them? Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg <dan...@redhat.com> wrote: > On Sun, Jun 19, 2016 at 02:13:40PM +0300, Nir Soffer wrote: > > Hi all, > > > > We should not support now Engine 3.5 with ovirt 4.0, but vdsm still > > accept 3.5 engines - I guess we forgot to disable it in 4.0. > > Correct. There was a moment in time where we considered supporting 3.5 > as well. > > > > > In 4.1, I don't think we should support any 3.x Engine - otherwise we > > will have to waste time maintaining old apis and infrastructure, instead > > of adding new features that matter to our users. > > Do you have a list of old APIs you'd like to throw away? We've killed a > few in 4.0, and > $ git grep REQUIRED_FOR > is not huge. > > > > > I suggest we disable now support for 3.x engines. > > > > Please see Eli patch: > > https://gerrit.ovirt.org/59308 > > > > Thoughts? > > +1, but let's see if ydary/mgoldboi think we should keep 3.6. > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Interacting with VDSM storage without oVirt Engine
Have you considered submitting a design document to the oVirt website. We will be happy to help in making this happen. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Tue, May 31, 2016 at 8:54 PM, Hayley Swimelar <hay...@linbit.com> wrote: > > > On 05/31/2016 10:40 AM, Nir Soffer wrote: > >> On Tue, May 31, 2016 at 7:25 PM, Hayley Swimelar <hay...@linbit.com> >> wrote: >> >>> >>> >>> On 05/31/2016 08:25 AM, Yaniv Dary wrote: >>> >>>> >>>> Can you explain the use case? What are you trying to use VDSM for? >>>> The API you want to use is internal and can break without notice. >>>> >>> >>> >>> Hi Yaniv, >>> >>> I'm working to to integrate DRBD storage into VDSM. >>> >>> It will be a new type of storage domain, so I can't use the GUI since the >>> engine component won't be aware of it as far as I can tell. >>> >>> The current plan is to have another developer on our end make changes to >>> the >>> Engine once the VDSM side is working. >>> >> >> Hi Hayley, >> >> Sounds cool, can you describe in more details the use case, and how do >> you think this >> can work? >> >> > Hi Nir, > > The use case is to make replicated block level storage available in oVirt. > > VDSM should be able to communicate with DRBD via DRBD Manage, which is a > new administrative layer for the latest release. > > Cheers, >> Nir >> > > -- > Hayley Swimelar > LINBIT | Keeping the Digital World Running > DRBD — Corosync — Pacemaker > +1-503-573-1262 x212 > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ACTION REQUESTED] i18n default English text is now stored in properties files
Is this change being done for 4.0? I would think this is a risky change that better fits 4.1. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Tue, May 24, 2016 at 6:20 PM, Scott Dickerson <sdick...@redhat.com> wrote: > > > On Tue, May 24, 2016 at 9:28 AM, Martin Sivak <msi...@redhat.com> wrote: > >> > Are you talking about some files in specific, and if so which ones? >> >> # find . -name AppErrors.properties | grep -v generated | grep -v target >> >> >> ./backend/manager/modules/dal/src/main/resources/bundles/AppErrors.properties >> >> ./frontend/webadmin/modules/frontend/src/main/resources/org/ovirt/engine/ui/frontend/AppErrors.properties >> >> ./frontend/webadmin/modules/userportal-gwtp/src/main/resources/org/ovirt/engine/ui/frontend/AppErrors.properties >> >> ./frontend/webadmin/modules/webadmin/src/main/resources/org/ovirt/engine/ui/frontend/AppErrors.properties >> > > That properties file does appear 3 times on the frontend side. It is > quite annoying, and there is a reason for it. I ran a process to move > English text to properties files out of annotations, creating the > properties files as necessary. In this case, AppErrors.properties existed > in both "userportal-gwtp" and "webadmin", but didn't originally exist in > the frontend module. Due to the way GWT i18n and GWT compiling work, > default values from annotations on the interface would augment the > properties values that GWT finds first on the classpath. Since > AppErrors.properties in "webadmin" is closer to the compiler then > AppError.properties in "frontend", webadmin will be used. This allows us > to have a full set of AppErrors messages per GWT project, unique to get GWT > project. It still confuses me a bit. There are better ways to do this. > > ConsoleErrors and VdsmErrors do the same thing. Those 3 message bundles > are on the list to do something about in the next round of work. We'll > probably create a common (App|Console|Vdsm)Errors interface, move messages > that are the same between the user portal and the admin portal to the > common ancestor and only define app specific keys in their respective > projects. > > >> >> Now, I know the files are not 100% equivalent, but we were adding the >> same messages to all of them in all the features I was working on. >> This leads me to believe that most of the people treat them as the >> same and we should only have one source for them. >> >> > Yes, our goal is to only have 1 source for them. It is unfortunate that > you have to add the text in multiple places currently. We'll get better > (soon). > > >> >> Martin >> >> On Tue, May 24, 2016 at 3:17 PM, Scott Dickerson <sdick...@redhat.com> >> wrote: >> > response inline >> > >> > On Tue, May 24, 2016 at 5:29 AM, Martin Sivak <msi...@redhat.com> >> wrote: >> >> >> >> Hi, >> >> >> >> We still have three almost identical files. Can we somehow keep just >> >> one and generate the other two? I was actually playing a bit with a >> >> change in the opposite direction - keeping just the EngineMessages >> >> enum with added default english translations and generating all other >> >> files from it. >> > >> > >> > Are you talking about some files in specific, and if so which ones? >> > >> >> >> >> Do you think it would make sense? It would not require a test then as >> >> the consistency would be checked during compilation phase directly. >> > >> > >> > Sure, generating some code from a key/message file could be useful. The >> > difficulty comes in when we have Messages or Constants interface that >> > inherit from a common ancestor. That construct is used a few times to >> share >> > messages between both the user portal and the admin portal. >> > >> > The primary reasons this change was done was to simplify translation >> and to >> > better manage workflow between language files in gerrit and documents in >> > Zanata. With this change, there is now a 1 to 1 mapping of properties >> files >> > to zanata documents. Well, for the front end i18n code at least. The >> > current translations for 4.0 can be seen here: >> > >> >https://translate.zanata.org/iteration/view/ovirt/master/documents >> > >
Re: [ovirt-devel] Vdsm api package
Do we have a RFE on this? Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Tue, Mar 29, 2016 at 9:33 PM, Sandro Bonazzola <sbona...@redhat.com> wrote: > > Il 29/Mar/2016 20:12, "Nir Soffer" <nsof...@redhat.com> ha scritto: > > > > On Tue, Mar 29, 2016 at 9:09 PM, Sandro Bonazzola <sbona...@redhat.com> > wrote: > > > > > > Il 29/Mar/2016 20:02, "Nir Soffer" <nsof...@redhat.com> ha scritto: > > >> > > >> Hi all, > > >> > > >> In the Vdsm call, we discussed a way to expose vdsm errors to its > clients > > >> (e.g, engine, hosted engine agent/setup). > > >> > > >> The idea is to have a vdsmapi package, holding: > > >> - errors.py - all public errors > > >> - events.py - all events sent by vdsm > > >> - client.py - library for communicating with vdsm > > >> - schema.py - the client will use this to autogenerate online help and > > >> validate messages > > >> - schema.yaml - we probably need several files (gluster, events, etc.) > > >> > > >> This will allow other projects talking with vdsm to do: > > >> > > >> from vdsmapi import client, errors > > >> ... > > >> try: > > >> client.list(vmId="xxxyyy") > > >> except errors.NoSuchVM: > > >> ... > > >> > > >> (this is a fake example, the real api may be different) > > >> > > >> Engine can build-require vdsmapi, and generate java module with the > > >> public errors from > > >> vdsmapi/errors.py module, instead of keeping this hardcoded in engine, > > >> and updating > > >> it every time vdsm adds new public error. > > >> > > >> Vdsm will use this package when building response to clients. > > >> > > >> Edi was concerned about sharing the errors module, so maybe we need a > > >> package: > > >> > > >> vdsmapi/ > > >> errors/ > > >> network.py > > >> virt.py > > >> storage.py > > >> gluster.py > > >> > > >> We can still expose all the errors via errors/__init__.py, so clients > > >> do not have to care about > > >> the area of the application the error come from. > > >> > > >> Thoughts? > > > > > > For which version is this proposal targeted? 4.1? > > > > This is not targeted to any version yet, but I would be happy if we can > do this > > for next release. > > I don't see it fitting 4.0 scope but I agree it would be nice to have in > 4.1. > > > > > Nir > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] feature request: shared templates and iso images
It should already work for ISO domain for connection with multiple DCs in same system. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Sun, Mar 13, 2016 at 12:01 PM, Yaniv Dary <yd...@redhat.com> wrote: > Can you open a RFE? > > Yaniv Dary > Technical Product Manager > Red Hat Israel Ltd. > 34 Jerusalem Road > Building A, 4th floor > Ra'anana, Israel 4350109 > > Tel : +972 (9) 7692306 > 8272306 > Email: yd...@redhat.com > IRC : ydary > > > On Fri, Mar 11, 2016 at 9:09 AM, Dobó László <laszlo.d...@ezit.hu> wrote: > >> Hi, >> >> It would be great if the template and iso domains can be attached to >> multiple datacenter at the same time. >> >> enax >> >> >> ___ >> Devel mailing list >> Devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] feature request: shared templates and iso images
Can you open a RFE? Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Fri, Mar 11, 2016 at 9:09 AM, Dobó László <laszlo.d...@ezit.hu> wrote: > Hi, > > It would be great if the template and iso domains can be attached to > multiple datacenter at the same time. > > enax > > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Cockpit-oVirt plugin
Can we have some screenshot or even a short video? That would be wonderful! Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Wed, Feb 24, 2016 at 1:19 PM, Marek Libra <mli...@redhat.com> wrote: > The rpm is not yet ready. As soon as some WIP is done, I'll focus on that. > > - Original Message - > > From: "Fabian Deutsch" <fdeut...@redhat.com> > > To: "Marek Libra" <mli...@redhat.com> > > Cc: "devel" <devel@ovirt.org> > > Sent: Tuesday, February 23, 2016 4:46:51 PM > > Subject: Re: [ovirt-devel] Cockpit-oVirt plugin > > > > On Tue, Feb 23, 2016 at 1:23 PM, Marek Libra <mli...@redhat.com> wrote: > > > I'm pleased to announce initial version of new oVirt plugin for > Cockpit, > > > which is recently a proposed feature for oVirt 4.0. > > > > > > The oVirt Wiki Feature can be found at [3]. > > > > > > Sources and README file can be found on the github [1]. > > > Up-to-date issue list is at [2] (includes planed enhancements) > > > > > > Please refer the README file for install instructions, so far tested on > > > Centos 7 (minimal). > > > > > > The plugin will be distributed as an rpm in the future and is meant as > an > > > optional add-on to oVirt. > > > > > > Main focus is on > > > - troubleshooting when accessibility/functionality of webadmin is > limited > > > - easy-to-use tool for VM-centric host monitoring/administration > > > - potential integration point with oVirt on UI level > > > - easy to use, so for small setups the preferred choice with an option > to > > > "upgrade" to full oVirt later > > > > > > The plugin or its parts can be used as standalone same as embedded into > > > other UIs, like drill-down from webadmin or ManageIQ for more details > or > > > fine-tuning. > > > > > > The plugin has dependency on VDSM. > > > Please note, since there was a VDSM patch needed, recent master is > required > > > (see README in the source). > > > > > > Dependency on oVirt's engine is optional - when accessible then > additional > > > plugin functionality is available. > > > Please note, the plugin is in early development phase showing basic > > > concept. > > > > Hey Marek, > > > > this work looks pretty promising! > > > > Do you already have rpm build which we could include in our nightly > > oVirt Node Next builds? > > > > Greetnigs > > fabian > > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Hello and A Question about oVirt
I don't think we have a option like this. Michal? Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Mon, Feb 1, 2016 at 5:16 AM, zhukaijie <kjzh...@is.ac.cn> wrote: > Hello, now I have defined a custom property named 'A' in oVirt Engine. > Administrator is responsible for entering the value (and arbitrary string ) > of 'A' before starting the VM. After an users trys to start the VM in > oVirt, VDSM will add the value of 'A' in the qemu:arg of libvirt domain > xml, so that the value of 'A' will be added into the QEMU Cmd as a param. > However, just like the password of VNC or SPICE, I want to hide the value > of 'A' in '*' format in both Libvirt domain xml and QEMU Cmd, So could you > please tell me how to achieve it? Thank you very much and happy 2016. > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Changing the name of VDSM in oVirt 4.0.
Hi, I wanted to bring this up to get feedback on this proposed change. VDSM doesn't align to other project under the oVirt umbrella like ovirt-engine, ovirt-node, ovirt-guest-agent etc.. I suggest for ease of use and tracking we change the versioning to align to the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know which version was in which release and also change the package naming to something like ovirt-host-manager\ovirt-host-agent. What do you think on this? What do you think the name should be? Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.
Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Tue, Jan 26, 2016 at 5:47 PM, Martin Perina <mper...@redhat.com> wrote: > > > - Original Message - > > From: "Martin Betak" <mbe...@redhat.com> > > To: "Yaniv Dary" <yd...@redhat.com> > > Cc: "devel" <devel@ovirt.org> > > Sent: Tuesday, January 26, 2016 4:41:29 PM > > Subject: Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0. > > > > +1 > > > > Honestly I think that any name is better and more descriptive than > "VDSM" :) > > "host-agent" seems appropriate to me. > I think the 'ovirt-' initial is needed to mark this is part of the upstream project. > +1 > > > But more important is to align engine and VDSM version. Wwe build them > together for one release, so they should have the same release version, > for example in oVirt 4.0 we should have > > ovirt-engine 4.0.0 > ovirt-host-agent 4.0.0 > > > Martin Perina > > > > > Best regards, > > > > Martin B. > > > > - Original Message - > > > From: "Yaniv Dary" <yd...@redhat.com> > > > To: "devel" <devel@ovirt.org> > > > Sent: Tuesday, January 26, 2016 4:29:46 PM > > > Subject: [ovirt-devel] Changing the name of VDSM in oVirt 4.0. > > > > > > Hi, > > > I wanted to bring this up to get feedback on this proposed change. VDSM > > > doesn't align to other project under the oVirt umbrella like > ovirt-engine, > > > ovirt-node, ovirt-guest-agent etc.. > > > > > > I suggest for ease of use and tracking we change the versioning to > align to > > > the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know which > version > > > was > > > in which release and also change the package naming to something like > > > ovirt-host-manager\ovirt-host-agent. > > > > > > What do you think on this? What do you think the name should be? > > > Yaniv Dary > > > Technical Product Manager > > > Red Hat Israel Ltd. > > > 34 Jerusalem Road > > > Building A, 4th floor > > > Ra'anana, Israel 4350109 > > > > > > Tel : +972 (9) 7692306 > > > 8272306 > > > Email: yd...@redhat.com IRC : ydary > > > > > > ___ > > > Devel mailing list > > > Devel@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/devel > > ___ > > Devel mailing list > > Devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] [ANN] Team in Whiteboard is not more, long live oVirt Team custom field.
Hi All, For a long time now we have been using the whiteboard free-text field to set the team that owns each ticket in Bugzilla. This causes several issues: - The usage was not documented. - We had issue reporting on that field. - People can make mistakes setting it (mis-spelling the team for example). Today Bugzilla team has completed setting oVirt Team field for all open bugs (NEW-> VERIFIED). From today we will be moving to using it. The documentation for this field is updated in Bugzilla, so if you are not sure on what team to set the ticket, click on the field itself and you will have a detailed help page. Please update all queries to use it! It should be easy to do so by changing the field you search on from 'Whiteboard' to 'oVirt Team'. Next Tuesday (26/01/16) I will request removal of all whiteboard team values. Please make sure to fix you queries beforehand. Thanks! Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] No more "vds group" in master code , instead please use "cluster"
This is amazing. Great work! Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Jan 13, 2016 01:00, "Eli Mesika" <emes...@redhat.com> wrote: > Hi > > I have merged today this patch[1] to master. > > The code from historical reasons uses both "vds group" and "cluster" for a > cluster entity. > This makes the code not-clear, non-readable and hard for beginners (to > find for example SPs that handle clusters , or all code related to a > cluster operation) > This also makes our logging and error messages using sometimes "vds group" > and sometimes "cluster" to relate to the same entity. > Worse than that, new code written sometimes introduce a mix of both terms. > > Patch[1] renames "vds group" to cluster all over the code. > This renaming covers all engine code including > Class names > Variables > Comments > Logging > Error messages > Database tables,views, columns and SPs including all kinds of keys and > constrains > > Please do not use from now on the term "vds group" (all its variants > (VdsGroup, vdsGroup, vds_group etc.) > Instead , cluster and all its variants should be used > > If you have some written code that is not merged yet, you will probably > have a little work on rebase on top this patch, as far as I know those > should be trivial patches and if you have any question, please ask. > > Possible affects on other products are minor and were communicated to the > relevant product people. > > [1] https://gerrit.ovirt.org/#/c/51109/ > > Thanks > Eli Mesika > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [ANN] oVirt Bugzilla Now Supports Votes.
You can see it on the bug and filter\display it in queries. Each user can cast up to 100 votes for every product. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Wed, Dec 23, 2015 at 2:53 PM, Michal Skrivanek <mskri...@redhat.com> wrote: > > > On 22 Dec 2015, at 12:53, Yaniv Dary <yd...@redhat.com> wrote: > > I'm not sure I understand the question. > Votes can affect severity and priority. It a aspect to check when setting > these. > > > Where can we see results? > Is it one/specific number of votes per account? > > > Yaniv Dary > Technical Product Manager > Red Hat Israel Ltd. > 34 Jerusalem Road > Building A, 4th floor > Ra'anana, Israel 4350109 > > Tel : +972 (9) 7692306 > 8272306 > Email: yd...@redhat.com > IRC : ydary > > > On Tue, Dec 22, 2015 at 1:39 PM, Amit Aviram <aavi...@redhat.com> wrote: > >> Does voting includes only the severity option? or anything else? >> >> On Tue, Dec 22, 2015 at 12:29 PM, Yaniv Dary <yd...@redhat.com> wrote: >> >>> Hi all, >>> I'm happy to announce that voting has been enabled for all the oVirt >>> projects. >>> Let us know what RFEs and bugs you hold dear and help us in prioritizing >>> what to fix first and what will have most impact. >>> >>> To vote please login, enter any oVirt bug and press on vote button (see >>> attached image). >>> >>> >>> Thanks! >>> >>> Yaniv Dary >>> Technical Product Manager >>> Red Hat Israel Ltd. >>> 34 Jerusalem Road >>> Building A, 4th floor >>> Ra'anana, Israel 4350109 >>> >>> Tel : +972 (9) 7692306 >>> 8272306 >>> Email: yd...@redhat.com >>> IRC : ydary >>> >>> >>> ___ >>> Devel mailing list >>> Devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >>> >> >> > ___ > Users mailing list > us...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] [ANN] oVirt Bugzilla Now Supports Votes.
Hi all, I'm happy to announce that voting has been enabled for all the oVirt projects. Let us know what RFEs and bugs you hold dear and help us in prioritizing what to fix first and what will have most impact. To vote please login, enter any oVirt bug and press on vote button (see attached image). Thanks! Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ANN] oVirt Bugzilla Now Supports Votes.
I'm not sure I understand the question. Votes can affect severity and priority. It a aspect to check when setting these. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Tue, Dec 22, 2015 at 1:39 PM, Amit Aviram <aavi...@redhat.com> wrote: > Does voting includes only the severity option? or anything else? > > On Tue, Dec 22, 2015 at 12:29 PM, Yaniv Dary <yd...@redhat.com> wrote: > >> Hi all, >> I'm happy to announce that voting has been enabled for all the oVirt >> projects. >> Let us know what RFEs and bugs you hold dear and help us in prioritizing >> what to fix first and what will have most impact. >> >> To vote please login, enter any oVirt bug and press on vote button (see >> attached image). >> >> >> Thanks! >> >> Yaniv Dary >> Technical Product Manager >> Red Hat Israel Ltd. >> 34 Jerusalem Road >> Building A, 4th floor >> Ra'anana, Israel 4350109 >> >> Tel : +972 (9) 7692306 >> 8272306 >> Email: yd...@redhat.com >> IRC : ydary >> >> >> ___ >> Devel mailing list >> Devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [ANN] [QE] Bugzilla updates for oVirt Product
I have just finished moving all the bugs from the old tracker to the new one for all 3.6.0 and above RFEs and bugs. You are requested to use the new classification from this point on. 3.5.z bug should be moved by their assignee to the correct target once you make sure, you can fill the target\version\milestone in the new tracker. Please fix your queries to include the classification. Reports based on whiteboard will continue to work. You may also use the milestone\flags to query. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Wed, Sep 9, 2015 at 11:59 AM, Sandro Bonazzola <sbona...@redhat.com> wrote: > The oVirt team is pleased to announce that today oVirt moved to its own > classification within our Bugzilla system as previously anticipated [1]. > No longer limited as a set of sub-projects, each building block > (sub-project) of oVirt will be a Bugzilla product. > This will allow tracking of package versions and target releases based on > their own versioning schema. > Each maintainer, for example, will have administrative rights on his or > her Bugzilla sub-project and will be able to change flags, > versions, targets, and components. > > As part of the improvements of the Bugzilla tracking system, a flag system > has been added to the oVirt product in order to ease its management [2]. > The changes will go into affect in stages, please review the wiki for more > details. > > We invite you to review the new tracking system and get involved with > oVirt QA [3] to make oVirt better than ever! > > [1] http://community.redhat.com/blog/2015/06/moving-focus-to-the-upstream/ > [2] http://www.ovirt.org/Bugzilla_rework > [3] http://www.ovirt.org/OVirt_Quality_Assurance > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > > ___ > Users mailing list > us...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ANN] [QE] Bugzilla updates for oVirt Product
Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Wed, Sep 9, 2015 at 12:11 PM, Sandro Bonazzola <sbona...@redhat.com> wrote: > > > On Wed, Sep 9, 2015 at 11:09 AM, David Caro <dc...@redhat.com> wrote: > >> >> What projects are considered for that? > > > You can see the planning here: > https://docs.google.com/spreadsheets/d/1SOJNw1WQHEhE2rVP26qNtu30aKLQIV8JEzPp8KqCbwU/edit?usp=sharing > > > >> What should be done to add a new one? >> >> > Adding Yaniv > For the first stage we will not be adding any additional sub-projects. After the full migration on the existing sub-project we can consider adding additional ones. > > > >> (for example, the repoman or similar are also there?) >> >> On 09/09, Sandro Bonazzola wrote: >> > The oVirt team is pleased to announce that today oVirt moved to its own >> > classification within our Bugzilla system as previously anticipated [1]. >> > No longer limited as a set of sub-projects, each building block >> > (sub-project) of oVirt will be a Bugzilla product. >> > This will allow tracking of package versions and target releases based >> on >> > their own versioning schema. >> > Each maintainer, for example, will have administrative rights on his or >> her >> > Bugzilla sub-project and will be able to change flags, >> > versions, targets, and components. >> > >> > As part of the improvements of the Bugzilla tracking system, a flag >> system >> > has been added to the oVirt product in order to ease its management [2]. >> > The changes will go into affect in stages, please review the wiki for >> more >> > details. >> > >> > We invite you to review the new tracking system and get involved with >> oVirt >> > QA [3] to make oVirt better than ever! >> > >> > [1] >> http://community.redhat.com/blog/2015/06/moving-focus-to-the-upstream/ >> > [2] http://www.ovirt.org/Bugzilla_rework >> > [3] http://www.ovirt.org/OVirt_Quality_Assurance >> > >> > -- >> > Sandro Bonazzola >> > Better technology. Faster innovation. Powered by community >> collaboration. >> > See how it works at redhat.com >> >> > ___ >> > Infra mailing list >> > in...@ovirt.org >> > http://lists.ovirt.org/mailman/listinfo/infra >> >> >> -- >> David Caro >> >> Red Hat S.L. >> Continuous Integration Engineer - EMEA ENG Virtualization R >> >> Tel.: +420 532 294 605 >> Email: dc...@redhat.com >> Web: www.redhat.com >> RHT Global #: 82-62605 >> > > > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Branch Zanata oVirt project for 3.6
Adding Yuko. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Thu, Sep 3, 2015 at 9:28 AM, Sandro Bonazzola <sbona...@redhat.com> wrote: > Hi, > I've just seen this morning that Zanata oVirt project is still missing 3.6 > branch, > can you please create it? > Thanks, > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Merge patch qemuimg: add support for convert progress
We are currently removing SPM and as part of that adding infra to track progress. After this we will begin adding progress bar for all storage related actions. On 06/27/2015 02:32 AM, Christopher Pereira wrote: qemu-img operations can take very long and there is currently no way to see their progress. It would be nice to include this patch to display the progress of a qemu-img operation (uploaded in November): https://gerrit.ovirt.org/#/c/33910/ Canceling the qemu-img task from Engine is also something that should be addressed at some point. 'copyImage' tasks are displayed via vdsClient. Is there any particular reason why a Cancel button was never added to the Engine's Task list? ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel -- Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [VDSM] Live snapshot with ceph disks
On 06/21/2015 11:07 AM, Nir Soffer wrote: - Original Message - From: Daniel Erez de...@redhat.com To: Nir Soffer nsof...@redhat.com Cc: devel devel@ovirt.org, Eric Blake ebl...@redhat.com, Francesco Romani from...@redhat.com, Adam Litke ali...@redhat.com, Federico Simoncelli fsimo...@redhat.com, Yaniv Dary yd...@redhat.com Sent: Sunday, June 21, 2015 10:05:41 AM Subject: Re: [VDSM] Live snapshot with ceph disks - Original Message - From: Nir Soffer nsof...@redhat.com To: devel devel@ovirt.org Cc: Eric Blake ebl...@redhat.com, Daniel Erez de...@redhat.com, Francesco Romani from...@redhat.com, Adam Litke ali...@redhat.com, Federico Simoncelli fsimo...@redhat.com, Yaniv Dary yd...@redhat.com Sent: Friday, June 19, 2015 11:40:23 PM Subject: [VDSM] Live snapshot with ceph disks Hi all, For 3.6, we will not support live vm snapshot, but this is a must for the next release. It is trivial to create a disk snapshot in ceph (using cinder apis). The snapshot is transparent to libvirt, qmeu and the guest os. However, we want to create a consistent snapshot, so you can revert to the disk snapshot and get a consistent file system state. We also want to create a complete vm snapshot, including all disks and vm memory. Libvirt and qemu provides that when given a new disk for the active layer, but when using ceph disk, we don't change the active layer - we continue to use the same disk. Since 1.2.5, libvirt provides virDomainFSFreeze and virDomainFSThaw: https://libvirt.org/hvsupport.html So here is possible flows (ignoring engine side stuff like locking vms and disks) Disk snapshot - 1. Engine invoke VM.freezeFileSystems 2. Vdsm invokes libvirt.virDomainFSFreeze 3. Engine creates snapshot via cinder 4. Engine invokes VM.thawFileSystems 5. Vdsm invokes livbirt.virDomainFSThaw Vm snapshot --- 1. Engine invoke VM.freezeFileSystems 2. Vdsm invokes libvirt.virDomainFSFreeze 3. Engine creates snapshot via cinder 4. Engine invokes VM.snapshot 5. Vdsm creates snapshot, skipping ceph disks 6. Engine invokes VM.thawFileSystems 7. Vdsm invokes livbirt.virDomainFSThaw API changes --- New verbs: - VM.freezeFileSystems - basically invokes virDomainFSFreeze - VM.thawFileSystems - basically invokes virDomainFSThaw What do you think? OpenStack uses two different approaches for live snapshot: 1. When taking a snapshot of an instance, a new image (of the entire instance) is created on Glance in qcow2 format - orchestrated by Nova and libvirt (Snapshot xml). This does not sound like compatible solution like snaphost using vdsm images. 2. When taking a snapshot of a single volume while the VM is running (i.e. the volume is attached to an instance), the snapshot is taken using Cinder with the relevant driver. The following message is displayed in Horizon: This volume is currently attached to an instance. In some cases, creating a snapshot from an attached volume can result in a corrupted snapshot. (see attached screenshot) Since the current integration is directly with Cinder and VM snapshot is handled by oVirt engine, we should go with a variant of option 2... We support consistent snapshots with vdsm images, and should support consistent snapshots with ceph as well. If it's too late to integrate the new verbs into 3.6, maybe we could just settle with a similar warning when creating a live snapshot? Or block the feature for now to avoid possible data inconsistency? I think we plan live snapshot for next release, not 3.6, so we can add any api we need. I think our goal should be similar live snapshot as we have with other storage types. Do we agree on this goal? Ack on that, we should remember we can have a VM with both Cinder and engine managed disks. Nir -- Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Libvirt secrets management - take 2
On 06/12/2015 02:40 PM, Nir Soffer wrote: - Original Message - From: Oved Ourfali oourf...@redhat.com To: Nir Soffer nsof...@redhat.com Cc: Eric Blake ebl...@redhat.com, devel devel@ovirt.org, Michal Skrivanek mskri...@redhat.com Sent: Friday, June 12, 2015 2:35:30 PM Subject: Re: [ovirt-devel] Libvirt secrets management - take 2 On Jun 12, 2015 14:21, Nir Soffer nsof...@redhat.com wrote: Hi all, Recently support for Ceph network disk landed in master. It its possible now to start a vm using Ceph network disk or hot-plug/unplug such disk using Cephx authentication. However, to make it work, you must add the relevant Ceph secret to libvirt manually, in the same way it is done in OpenStack deployment. Our goal is to manage secrets automatically and use ephemeral (safer) secrets. The next patches in the Ceph topic [1], implement secret management in the same way we manage storage domains or server connections: The concept is - all hosts can use all secrets, so you can migrate a vm using Ceph disk to any host in the cluster. 1. When host becomes up, we register the secrets associated with all the current active domains with libvirt 2. When activating a domain, we register the secrets associated with the new domain with libvirt 3. When deactivating a domain, we unregister the secrets associated with the domain from libvirt 4. When moving host to maintenance, we clear all secrets 5. When vdsm shutdown or starts, clear all secrets to ensure that we don't keep stale or unneeded secrets on a host This system seems to work, but Federico pointed few issues and suggested a new (simpler?) approach. In future libvirt version, libvirt will support the concept of transient secrets so you can start a transient vm using secret without registering the secret with libvirt before starting the vm. The secret will be specified in the vm XML (for starting a vm) or disk XML (for hot-plug). This will make our secret management system and APIs useless. Can you open a RFE tracking the libvirt RFE on secrets? When is this planned to be added to libvirt? I have no idea iiuc, once added, you will no longer need to register the secrets with libvirt, right? Right Managing state on multiple hosts is hard; we will probably have to deal with nasty edge cases (e.g. lost messages, network errors), which may lead to host with missing secret, which cannot run some vms. We probably do this right for storage domains (after 8 years?), and we should not assume that we are smarter and secret management will work in the first try. The new approach is to *not* manage state or multiple hosts. Instead, send the required secrets only to the host that starting a vm or hot-plugging a disk that need a libvirt secret: 1. When starting a vm, add the required secrets to the vm description. On the host, vdsm will register these secrets with libvirt before starting the vm. 2. When migrating a vm, add the required secrets to the vm description. On the host, vdsm will send these secrets to the destination host, and on the destination host, vdsm will register the secrets with libvirt before starting the vm. Will these secrets be part of the domain xml? If so, no need for special treatment in case of VM migration. 3. When hot-plugging a disk, send the secret if needed in the disk description. On the host, vdsm will register the secrets with libvirt. 4. When vdsm shutdown or starts, clear all secrets to ensure that we don't keep stale or unneeded secrets on a host 5. We never unregister secrets, since they are ephemeral anyway. 6. Alternatively, we can implement secrets reference counting so when a vm stops or disk is hot-unplugged we decrease the reference count on the secrets associated with this vm/disk, and if no other vms need the secret, we can unregister the secret from libvirt. Doesn't seem necessary to me. The new approach is simpler, if we avoid the fancy secret reference counting. I believe we can get it merged in couple of weeks with help from the virt team. Please share your thoughts on these alternative solutions. Keep in mind also hosted engine. Sounds to me like the new approach will be a better fit for it, as he won't need to deal with storage domain secrets, but just pass it in the VM description... Although I'm not a hosted engine expert, so not sure it makes a difference, but it sounds simpler in that aspect as well. Good point, the first option require hosted engine installer to register the required secrets when installing the engine vm, and maybe also when adding a new host. Nir ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel -- Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary
Re: [ovirt-devel] 3.6.1 target release
Feature Freeze is no GA. 3.6.1 will happen only after 3.6.0 GA. Please use milestones to target things out (Beta\RC). On 06/10/2015 11:16 AM, Eyal Edri wrote: adding yaniv brian, between them i think one has permissions. +1 on pushing stuff to 3.6.1 that won't make it. e. - Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: devel@ovirt.org, infra in...@ovirt.org Sent: Wednesday, June 10, 2015 11:10:51 AM Subject: [ovirt-devel] 3.6.1 target release Hi, who's maintaing bugzilla's config? I'd appreciate 3.6.1 target release to be able to push out the small things supposed to land immediately after feature freeze Thanks, michal ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel -- Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] searching by tags
Eli, could this be related to the search you committed a few weeks ago? Yaniv On 03/11/2015 09:53 PM, Einav Cohen wrote: Hi, AFAIR, we used to support a hierarchical search by tag. i.e. if I had a parent tag Europe, and it had child-tags Italy and UK, a search such as: VMs: tag=Europe would have returned VMs that are tagged with Europe as well as VMs tagged with any child-tags of Europe (i.e. VMs that are tagged with UK or Italy); however, this doesn't seem to be the case anymore [see http://i.imgur.com/85rZbZj.png]. [I am running master from ~3 weeks ago] Any idea why? Thanks. Regards, Einav ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel -- Yaniv Dary Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - From: Francesco Romani from...@redhat.com To: David Caro dcaro...@redhat.com Cc: in...@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 11:48:00 AM Subject: Re: [ovirt-devel] Creating a new gerrit flag - Original Message - From: David Caro dcaro...@redhat.com To: devel@ovirt.org, in...@ovirt.org Sent: Tuesday, December 9, 2014 10:43:04 AM Subject: [ovirt-devel] Creating a new gerrit flag Hi! e have been having an issue with gerrit patches being merged before jenkins ran any tests on them, to avoid it from happening again I propose creating a new gerrit flag (Tests) with the following specifics: +1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow overriding the process. That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to override the value, she just has to set that flag herself. What do you think? Looks good, but there is a scenario which worries me a bit. It happened in the past times that an otherwise good and working patch failed the tests because, for example, pep8 or pyflakes became stricter about the code formatting. Can the maintainer override such a -1 from failed tests in that case? (probably yes, but worth asking) If a test fails on this, it will fail on all patches that will follow as well, so I don't think it's a bad requirement that you need to fix the underlying issues for patches to be merged. Without running tests you don't have any good wya to make sure a patch is 'good'. Thanks, -- Francesco Romani RedHat Engineering Virtualization R D Phone: 8261328 IRC: fromani ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - From: Oved Ourfali ov...@redhat.com To: David Caro dcaro...@redhat.com Cc: in...@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 11:52:11 AM Subject: Re: [ovirt-devel] Creating a new gerrit flag What happens when rebasing? We can't afford waiting for tests to run on each rebase... as we might end up rebasing forever. why can't you rerun tests after rebase to run tests if the patch is critical and pending? - Original Message - From: David Caro dcaro...@redhat.com To: devel@ovirt.org, in...@ovirt.org Sent: Tuesday, December 9, 2014 11:43:04 AM Subject: [ovirt-devel] Creating a new gerrit flag Hi! e have been having an issue with gerrit patches being merged before jenkins ran any tests on them, to avoid it from happening again I propose creating a new gerrit flag (Tests) with the following specifics: +1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow overriding the process. That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to override the value, she just has to set that flag herself. What do you think? -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization RD Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - From: Yaniv Dary yd...@redhat.com To: Oved Ourfali ov...@redhat.com Cc: devel@ovirt.org, in...@ovirt.org Sent: Tuesday, December 9, 2014 12:10:36 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag - Original Message - From: Oved Ourfali ov...@redhat.com To: David Caro dcaro...@redhat.com Cc: in...@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 11:52:11 AM Subject: Re: [ovirt-devel] Creating a new gerrit flag What happens when rebasing? We can't afford waiting for tests to run on each rebase... as we might end up rebasing forever. why can't you rerun tests after rebase to run tests if the patch is critical and pending? I meant manually. - Original Message - From: David Caro dcaro...@redhat.com To: devel@ovirt.org, in...@ovirt.org Sent: Tuesday, December 9, 2014 11:43:04 AM Subject: [ovirt-devel] Creating a new gerrit flag Hi! e have been having an issue with gerrit patches being merged before jenkins ran any tests on them, to avoid it from happening again I propose creating a new gerrit flag (Tests) with the following specifics: +1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow overriding the process. That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to override the value, she just has to set that flag herself. What do you think? -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization RD Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - From: David Caro dcaro...@redhat.com To: Oved Ourfali ov...@redhat.com Cc: in...@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 12:12:19 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 12/09, Oved Ourfali wrote: What happens when rebasing? We can't afford waiting for tests to run on each rebase... as we might end up rebasing forever. For now we will have to, all the code that is going to be merged must be tested as it is going to be merged, that means running the tests in the last rebase too. In the future there are plans on using a gating system like zuul, so zuul will be the one monitoring the tests and merging when passes, so you will just add the flag, and that will trigger the gate, that runs the tests and merged the patch. It's unlikely that you'll have to wait forever, but there's nothing avoiding you doing that (right now even). I'd like to put emphasis again on differentiating between tests that are fast, that should run on each patch and tests that are slow, that should run on each merge. That will improve the feedback times. +1 Tests are more critical than fast merges, the consequences of merging untest patches is worse. - Original Message - From: David Caro dcaro...@redhat.com To: devel@ovirt.org, in...@ovirt.org Sent: Tuesday, December 9, 2014 11:43:04 AM Subject: [ovirt-devel] Creating a new gerrit flag Hi! e have been having an issue with gerrit patches being merged before jenkins ran any tests on them, to avoid it from happening again I propose creating a new gerrit flag (Tests) with the following specifics: +1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow overriding the process. That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to override the value, she just has to set that flag herself. What do you think? -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization RD Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization RD Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - From: Oved Ourfali ov...@redhat.com To: David Caro dcaro...@redhat.com Cc: in...@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 2:27:14 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag top posting: How about the following flow: 1. You push a patch to gerrit. 2. You need +1 on Testing in order to merge it. 3. You have +1/-1 on the Tests if finished successfully/failed 4. You find out you need to rebase. 5. The rebase copies the result of the Tests of the previous patch-set... if it was +1, it remains +1 and you can merge (assuming you have +2 on CR). If it was -1 then you need to wait for the CI to finish, and it might set it to +1. Does that make sense? Yes, but only if you used rebase button and automatic rebase worked. In case of merge conflict you will need to wait after rebase for tests. - Original Message - From: Oved Ourfali ov...@redhat.com To: David Caro dcaro...@redhat.com Cc: devel@ovirt.org, in...@ovirt.org Sent: Tuesday, December 9, 2014 1:13:57 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag - Original Message - From: David Caro dcaro...@redhat.com To: Oved Ourfali ov...@redhat.com Cc: in...@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 12:12:19 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 12/09, Oved Ourfali wrote: What happens when rebasing? We can't afford waiting for tests to run on each rebase... as we might end up rebasing forever. For now we will have to, all the code that is going to be merged must be tested as it is going to be merged, that means running the tests in the last rebase too. In the future there are plans on using a gating system like zuul, so zuul will be the one monitoring the tests and merging when passes, so you will just add the flag, and that will trigger the gate, that runs the tests and merged the patch. It's unlikely that you'll have to wait forever, but there's nothing avoiding you doing that (right now even). I'd like to put emphasis again on differentiating between tests that are fast, that should run on each patch and tests that are slow, that should run on each merge. That will improve the feedback times. So let's apply that in the future. For now the amount of merges done is enormous, and it will be impossible to get things merged on a reasonable time. Again, I'm not against testing, but it should be done the right way... - Original Message - From: David Caro dcaro...@redhat.com To: devel@ovirt.org, in...@ovirt.org Sent: Tuesday, December 9, 2014 11:43:04 AM Subject: [ovirt-devel] Creating a new gerrit flag Hi! e have been having an issue with gerrit patches being merged before jenkins ran any tests on them, to avoid it from happening again I propose creating a new gerrit flag (Tests) with the following specifics: +1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow overriding the process. That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to override the value, she just has to set that flag herself. What do you think? -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization RD Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization RD Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Important change in UI plugins REST API integration
Does this affect any 3rd parties that implemented UI plugins? Will they need to change anything or is this change more a behaviour change only? Yaniv - Original Message - From: Vojtech Szocs vsz...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: devel@ovirt.org Sent: Tuesday, December 2, 2014 7:12:21 PM Subject: Re: [ovirt-devel] Important change in UI plugins RESTAPI integration - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Sven Kieske s.kie...@mittwald.de Cc: devel@ovirt.org Sent: Tuesday, December 2, 2014 9:43:18 AM Subject: Re: [ovirt-devel] Important change in UI plugins REST API integration - Original Message - From: Sven Kieske s.kie...@mittwald.de To: devel@ovirt.org Sent: Tuesday, December 2, 2014 10:41:00 AM Subject: Re: [ovirt-devel] Important change in UI plugins REST API integration On 01/12/14 20:26, Vojtech Szocs wrote: In other words, usability of REST session ID is now strictly scoped to GUI user being authenticated. If the user logs in, (always) new REST session ID will be passed to all UI plugins. If the user logs out, REST session ID will not work anymore. What if I use just REST for logging in and doing something without any GUI interaction at all? This announcement was about UI plugins in WebAdmin. If you use Engine REST API without any GUI interaction involved, you aren't affected in any way. this reads a little like: you always need an open web gui to be able to use REST, which does not make sense at all. Sorry if my email confused you. It should read like: if you're an author of oVirt UI plugin for WebAdmin, please beware that REST API session ID (automatically acquired by UI plugin infra on behalf of all UI plugins) will not work after GUI logout. If you provide your own credentials nothing changed. The change is only effecting RESTAPI usage within the user interface using the credentials obtained interactively from the user within login page. So I guess I'm misreading this? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] DWH cannot gain hourly history data from db because of the bloody time problem.
Are all your servers sync to the same ntp and in UTM time? Can you attach logs? Yaniv - Original Message - From: 张亚琪 zhangyingyun...@gmail.com To: Devel@ovirt.org Sent: Friday, November 14, 2014 11:22:38 AM Subject: [ovirt-devel] DWH cannot gain hourly history data from db because of the bloody time problem. hi everybody, Recently, I have tested oVirt Reports. And I encountered a problem about some reports that cannot show data. And then I setup the DWH development environment. I found maybe this reason for missing data is the AggregationToHourly3.5. When data from datacenter_samples_history were inserted to datacenter_hourly_history, u will find nothing happened. Because the select sql before inserting data reads： SELECT history_id, history_datetime, datacenter_id, datacenter_status, minutes_in_status, datacenter_configuration_version FROM datacenter_samples_history WHERE history_datetime = '+context.lastHourAggr+ ' AND history_datetime '+TalendDate.addDate(context.lastHourAggr, 1,HH)+' ORDER BY history_datetime, datacenter_id, datacenter_status And then I queried the table of datacenter_samples_history history_configuration (has the field of lastHourAggr) in the db of ovirt_engine_history. The results are as follows: ovirt_engine_history=# select * from history_configuration; var_name | var_value | var_datetime ---+---+ MinimalETLVersion | 3.5.0 | default_language | en_US | firstSync | false | 2014-10-13 19:42:00+08 lastDayAggr | | 2014-11-14 00:00:00+08 lastHourAggr | | 2014- 11-15 06:00:00+08 HourlyAggFailed | false | (6 rows) ovirt_engine_history=# select history_datetime from datacenter_samples_history; history_datetime 2014- 11-13 03:07:00.23+08 2014-11-13 03:08:00.238+08 2014-11-13 03:09:00.229+08 2014-11-13 03:10:00.221+08 2014-11-13 03:11:00.229+08 2014-11-13 03:12:00.221+08 2014-11-13 03:13:00.237+08 2014-11-13 03:14:00.22+08 2014-11-13 03:15:00.221+08 2014-11-13 03:16:00.238+08 2014-11-13 03:17:00.238+08 Obviously， history_datetime lastHourAggr , the data will never be inserted to the datacenter_hourly_history. And the place where I bold is the root cause of the error. Then , I try to update the lastHourAggr in the table of history_configuration. Reports works successfully. However, the lastHourAggr will change to 2014-11-15 afterwards. But u know Today is 2014-11-14 ! I have no idea about why the value of lastHourAggr is 2014-11-15. Would u help me solve this problem. Thanks a lot ! ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Packages for oVirt 3.5.0 RC3
We will release packages for DWH reports later today. Yaniv - Original Message - From: Sandro Bonazzola sbona...@redhat.com To: David Caro dcaro...@redhat.com, devel@ovirt.org Sent: Tuesday, September 23, 2014 10:31:27 AM Subject: [ovirt-devel] Packages for oVirt 3.5.0 RC3 # From developers: # Log Collector http://jenkins.ovirt.org/job/manual-build-tarball/412/ # ISO Uploader http://jenkins.ovirt.org/job/manual-build-tarball/411/ # Image Uploader http://jenkins.ovirt.org/job/manual-build-tarball/410/ # Hosted Engine http://jenkins.ovirt.org/job/ovirt-hosted-engine-ha_any_create-rpms_manual/2/ http://jenkins.ovirt.org/job/ovirt-hosted-engine-setup_any_create-rpms_manual/6/ # VDSM # F20 http://koji.fedoraproject.org/koji/taskinfo?taskID=7648992 # F19 http://koji.fedoraproject.org/koji/taskinfo?taskID=7649080 # rhel6 http://koji.fedoraproject.org/koji/taskinfo?taskID=7649142 #rhel7 http://koji.fedoraproject.org/koji/taskinfo?taskID=7649251 #rhel7 ppc64 http://koji.fedoraproject.org/koji/taskinfo?taskID=7649263 # Delivered by Fedora / EPEL: # - ioprocess # - mom # Remaining packages will be taken from Jenkins 3.5 Publisher once pending patches for the engine will be merged and engine built. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Propose Shirly Radco as DWH Reports Maintainer.
Hi, Shirly Radco has contributed many features, bug fixes and documentation enhancements for DWH Reports and has taken a major role in the project progress and management in the last 9 months. I would like to propose Shirly as a DWH Reports projects Maintainer. I would like to thank Shirly for her great contribution and hope she will keep up the good work! --- Yaniv Dary BI Software Engineer Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : Yaniv D ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [Engine-devel] Polling vs Pushing engine events
You can use the DWH API to check these things. The status is sampled and stored for most entities every 1 minute by default (and can be set to less than that). Yaniv - Original Message - From: Sven Kieske s.kie...@mittwald.de To: us...@ovirt.org, engine-devel@ovirt.org Sent: Tuesday, December 17, 2013 10:08:11 AM Subject: [Engine-devel] Polling vs Pushing engine events Hi, we got the following problem: we create / start / stop hole vms /data centers / storage etc (basically: everything ovirt can handle via REST-API) But if you want to know e.g. the status of a vm (or anything) you need to constantly poll the API. This is not what we desire to do, as it does not scale very well (e.g. polling 100 vms). Is there a standardized way of pushing information from the engine? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ 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] fedora openid authentication for gerrit is broken
- Original Message - From: Itamar Heim ih...@redhat.com To: Dan Kenigsberg dan...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Vered Volansky ve...@redhat.com, in...@ovirt.org Sent: Wednesday, March 6, 2013 12:48:57 PM Subject: Re: [Engine-devel] fedora openid authentication for gerrit is broken On 03/06/2013 12:34 PM, Itamar Heim wrote: On 03/06/2013 11:38 AM, Dan Kenigsberg wrote: On Wed, Mar 06, 2013 at 09:55:45AM +0100, Alexander Rydekull wrote: Itamar, I think Vered summarize it quite perfectly in a parallell thread: http://lists.ovirt.org/pipermail/infra/2013-March/002314.html He was also kind enough to open a ticket on the issue. Could you look into it? I wonder if our friendly gerrit.ovirt.org dba could add the new url https://danken.id.fedoraproject.org/ for every user with the old one, so that people lacking the new one can keep on working? (/me not included, I have both urls) Dan. it's not that simple, still investigating... ___ Infra mailing list in...@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ok, new url is working. for general knowledge, its aside of the use of the new identity url and in the form of: https://admin.fedoraproject.org/accounts/user/view/iheim previous format was: https://admin.fedoraproject.org/accounts/openid/id/iheim (there could be something more correct, but this works...) please check and update if you still see issues. Getting 'Provider is not supported, or was incorrectly entered.'. Yaniv thanks, Itamar ___ 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] DB Schema Reports
- Original Message - From: Eli Mesika emes...@redhat.com To: Libor Spevak lspe...@redhat.com Cc: engine-devel@ovirt.org, rhev-de...@redhat.com, in...@ovirt.org Sent: Friday, February 22, 2013 1:05:01 PM Subject: Re: [Engine-devel] DB Schema Reports - Original Message - From: Libor Spevak lspe...@redhat.com To: engine-devel@ovirt.org, rhev-de...@redhat.com, in...@ovirt.org Sent: Friday, February 22, 2013 10:02:55 AM Subject: DB Schema Reports Hi, let me announce new database schema reports based on the SchemaSpy Java library available. Thanks to infra group for support, especially to David Caro, who set up Mr. Jenkins's jobs. Great job ! +1 oVirt-Engine: http://resources.ovirt.org/dbreports/latest/engine/public/index.html oVirt-DWH: http://resources.ovirt.org/dbreports/latest/dwh/public/index.html Wiki: http://www.ovirt.org/DB_model Regards, Libor ___ Infra mailing list in...@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ 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
