Re: [ovirt-devel] [ACTION REQUIRED] vdsm_master_install-rpm-sanity-el6_created bugged and vdsm spec file broken
On Mon, Nov 10, 2014 at 08:24:40AM -0500, Ondřej Svoboda wrote: > Hi, > > I am in favor of tagging e.g. the commit introducing the hook in question [1] > with v4.16.99. > (Similarly, in the message to ovirt-users [2] I suggested that anyone > interested in the hook tag their master branch with "v4.17-fake".) > I think that the tag v4.17 is very similar to the eventual tag v4.17.0 and > might be confusing or sounding like a "hack"; but they are different tags > nonetheless so I am not opposed to this solution either. > > Introducing the tag would make installing the hook painless to both groups > (those on v4.16.7; and those on master, i.e., post-v4.16.0). > > [1] hooks: Add a hook to configure IPv6 networking through custom properties > e42c9f3e9a2a4f759a66f11b3572d21c2b28d7c6 > [2] IPv6 configuration through custom network properties and vdsm-hook-ipv6 I've ended up tagging master with v4.17.0. > > - Original Message - > From: "Sandro Bonazzola" > To: devel@ovirt.org, "infra" > Sent: Thursday, November 6, 2014 8:25:09 AM > Subject: [ovirt-devel] [ACTION REQUIRED] > vdsm_master_install-rpm-sanity-el6_created bugged and vdsm spec file broken > > Looking at: > http://jenkins.ovirt.org/job/vdsm_master_install-rpm-sanity-el6_created/570/console > > The job is trying to install the src.rpm and fails: > > 16:45:09 Cannot add package /tmp/vdsm-4.16.0-501.gitf981b80.el6.src.rpm to > transaction. Not a compatible architecture: src > 16:45:11 Cannot add package /tmp/vdsm-4.16.0-501.gitf981b80.fc20.src.rpm to > transaction. Not a compatible architecture: src > > After that, some rpms fails the install: > Package: vdsm-hook-ipv6-4.16.0-501.gitf981b80.el6.noarch > (/vdsm-hook-ipv6-4.16.0-501.gitf981b80.el6.noarch) > 16:45:34Requires: vdsm >= 4.16.7 > > Master must bump version to 4.16.99 or 4.17 or something like that in order > to be installable. > > Last thing: > Cents 6.6 now deliver glusterfs 3.6.0.28 and vdsm is explicitly requiring > 3.5.2. > Anything preventing to move to >= 3.5.2 instead of = 3.5.2? > > -- > 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] [ovirt-users] Ubuntu/Debian support?
Il 17/11/2014 14:22, Sven Kieske ha scritto: > > > On 17/11/14 08:41, Itamar Heim wrote: >> >> 1) Is this still an issue? > Yes of course, or is it implemented yet? > >> 2) Can we afford to dilute the focus we have as it is hard enough to >>stabilize the currently supported distro's? is it worth the >>potential impact? > In general: Software which supports multiple operating systems/distros > tends to be more stable, because some bugs just get found on specific > platforms. > the general ovirt technology is available "everywhere" (TM): java & python >> 3) Would it have maintainers catering to it so it won't be left behind >>/ delay development? > this is a question for devel@ovirt.org (CC'ed ;) ) >> 4) Why bother with host support, ovirt-node can be used? > My impression is, that most users don't use ovirt-node, because > this project has not enough dev power and lacks certain stuff >> 5) Why bother with engine support, a virtual appliance or a docker >>image could be used? > docker is inherently insecure (a famous red hatter said: it's like > download random code from the internet and run it as root), so docker > is no option today, imho. >> 6) if we do it, should we focus on Ubuntu or Debian distro first? > well, the general rule of thumb is: if it runs on debian it runs on > ubuntu. I see way more debian than ubuntu servers, but for modern > deployments this changes. my personal opinion is, that ubuntu sucks > as a server os. >> 7) if we do it, should we focus on host or engine first? > atm you are focusing host, there are some bugs open for that > and it's planned for 3.6. (that's what I read at least) > > General note: > > Imho ovirt would greatly benefit from more supported distros. > Not just debian and ubuntu, but you have to start somewhere. > you can attract many devs, which just don't use el/fedora. > > furthermore, the basic technology runs on any linux distribution: > java and python > > so these are "just" integration issues (path to configfiles, > different init systems, packaging not in rpm, but deb, etc.) > > This is still a huge effort, but I guess canonical and various > debian developers would maybe join the effort to make ovirt > work on their platform. I would really like to see them joining the effort! :-) > > my 2 cent > -- 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
[ovirt-devel] ATTN frontend maintainers
Hi, I just merged [1], which causes *ListModels to be managed by GIN. What does this mean for you? Well if you are creating a new ListModel you should also have them managed by GIN as the CommonModel no longer manages them. If you have any problems with this let me know I will walk you through the process. There should be plenty of examples to work with in the code now. Even though we ran all available tests on this patch and they all passed there is the possibility some things broke. In particular I am worried about some permissions for areas that are somewhat obscure that I might have missed. Also the new data domain import functionality. If anything is not working correctly please contact me so I can get it resolved for you. Thanks, Alexander [1] http://gerrit.ovirt.org/#/c/34193/ ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] Ubuntu/Debian support?
On 17/11/14 08:41, Itamar Heim wrote: > > 1) Is this still an issue? Yes of course, or is it implemented yet? > 2) Can we afford to dilute the focus we have as it is hard enough to >stabilize the currently supported distro's? is it worth the >potential impact? In general: Software which supports multiple operating systems/distros tends to be more stable, because some bugs just get found on specific platforms. the general ovirt technology is available "everywhere" (TM): java & python > 3) Would it have maintainers catering to it so it won't be left behind >/ delay development? this is a question for devel@ovirt.org (CC'ed ;) ) > 4) Why bother with host support, ovirt-node can be used? My impression is, that most users don't use ovirt-node, because this project has not enough dev power and lacks certain stuff > 5) Why bother with engine support, a virtual appliance or a docker >image could be used? docker is inherently insecure (a famous red hatter said: it's like download random code from the internet and run it as root), so docker is no option today, imho. > 6) if we do it, should we focus on Ubuntu or Debian distro first? well, the general rule of thumb is: if it runs on debian it runs on ubuntu. I see way more debian than ubuntu servers, but for modern deployments this changes. my personal opinion is, that ubuntu sucks as a server os. > 7) if we do it, should we focus on host or engine first? atm you are focusing host, there are some bugs open for that and it's planned for 3.6. (that's what I read at least) General note: Imho ovirt would greatly benefit from more supported distros. Not just debian and ubuntu, but you have to start somewhere. you can attract many devs, which just don't use el/fedora. furthermore, the basic technology runs on any linux distribution: java and python so these are "just" integration issues (path to configfiles, different init systems, packaging not in rpm, but deb, etc.) This is still a huge effort, but I guess canonical and various debian developers would maybe join the effort to make ovirt work on their platform. my 2 cent -- 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
Re: [ovirt-devel] [db] add config key with same value to multiple versions
- Original Message -
> From: "Eli Mesika"
> To: "engine-de...@ovirt.org"
> Sent: Monday, November 17, 2014 12:42:29 PM
> Subject: Re: [ovirt-devel] [db] add config key with same value to multiple
> versions
>
>
>
> - Original Message -
> > From: "Eli Mesika"
> > To: "engine-de...@ovirt.org"
> > Sent: Monday, November 17, 2014 12:40:53 PM
> > Subject: [ovirt-devel] [db] add config key with same value to multiple
> > versions
> >
> > Hi
> >
> > Please note that I have added a common function to ease handling of
> > configuration settings:
> >
> > signature : fn_db_add_config_value_for_versions_up_to(v_option_name, v_val
> > ,
> > v_version )
> >
> > so, for example, if you want to add a new feature F1 flag, which is true
> > only
> > for 3.6, to _config.sql instead of :
> >
> > select fn_db_add_config_value('F1','false','3.0');
> > select fn_db_add_config_value('F1','false','3.1');
> > select fn_db_add_config_value('F1','false','3.2');
> > select fn_db_add_config_value('F1','false','3.3');
> > select fn_db_add_config_value('F1','false', '3.4');
> > select fn_db_add_config_value('F1','true', '3.5');
> sorry, this one is
> select fn_db_add_config_value('F1','false', '3.5');
>
> >
> > All you have to do is :
> >
> > fn_db_add_config_value_for_versions_up_to('F1','true', '3.5');
fn_db_add_config_value_for_versions_up_to('F1','false', '3.5');
> >
> > This is true also for other values, for example if you have a key K1 that
> > has
> > values 'a' for {3.0, 3.1} and 'b' for {3.2, 3.3, 3.4, 3.5)
> >
> > instead of
> >
> > select fn_db_add_config_value('K1','a','3.0');
> > select fn_db_add_config_value('K1','a','3.1');
> > select fn_db_add_config_value('K1','b','3.2');
> > select fn_db_add_config_value('K1','b','3.3');
> > select fn_db_add_config_value('K1','b', '3.4');
> > select fn_db_add_config_value('K1','b', '3.5');
> >
> > simply write :
> >
> > fn_db_add_config_value_for_versions_up_to('K1','a', '3.1');
> > fn_db_add_config_value_for_versions_up_to('K1','b', '3.5');
> >
> >
> >
> > 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] [db] add config key with same value to multiple versions
- Original Message -
> From: "Eli Mesika"
> To: "engine-de...@ovirt.org"
> Sent: Monday, November 17, 2014 12:40:53 PM
> Subject: [ovirt-devel] [db] add config key with same value to multiple
> versions
>
> Hi
>
> Please note that I have added a common function to ease handling of
> configuration settings:
>
> signature : fn_db_add_config_value_for_versions_up_to(v_option_name, v_val ,
> v_version )
>
> so, for example, if you want to add a new feature F1 flag, which is true only
> for 3.6, to _config.sql instead of :
>
> select fn_db_add_config_value('F1','false','3.0');
> select fn_db_add_config_value('F1','false','3.1');
> select fn_db_add_config_value('F1','false','3.2');
> select fn_db_add_config_value('F1','false','3.3');
> select fn_db_add_config_value('F1','false', '3.4');
> select fn_db_add_config_value('F1','true', '3.5');
sorry, this one is
select fn_db_add_config_value('F1','false', '3.5');
>
> All you have to do is :
>
> fn_db_add_config_value_for_versions_up_to('F1','true', '3.5');
>
> This is true also for other values, for example if you have a key K1 that has
> values 'a' for {3.0, 3.1} and 'b' for {3.2, 3.3, 3.4, 3.5)
>
> instead of
>
> select fn_db_add_config_value('K1','a','3.0');
> select fn_db_add_config_value('K1','a','3.1');
> select fn_db_add_config_value('K1','b','3.2');
> select fn_db_add_config_value('K1','b','3.3');
> select fn_db_add_config_value('K1','b', '3.4');
> select fn_db_add_config_value('K1','b', '3.5');
>
> simply write :
>
> fn_db_add_config_value_for_versions_up_to('K1','a', '3.1');
> fn_db_add_config_value_for_versions_up_to('K1','b', '3.5');
>
>
>
> 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
[ovirt-devel] [db] add config key with same value to multiple versions
Hi
Please note that I have added a common function to ease handling of
configuration settings:
signature : fn_db_add_config_value_for_versions_up_to(v_option_name, v_val ,
v_version )
so, for example, if you want to add a new feature F1 flag, which is true only
for 3.6, to _config.sql instead of :
select fn_db_add_config_value('F1','false','3.0');
select fn_db_add_config_value('F1','false','3.1');
select fn_db_add_config_value('F1','false','3.2');
select fn_db_add_config_value('F1','false','3.3');
select fn_db_add_config_value('F1','false', '3.4');
select fn_db_add_config_value('F1','true', '3.5');
All you have to do is :
fn_db_add_config_value_for_versions_up_to('F1','true', '3.5');
This is true also for other values, for example if you have a key K1 that has
values 'a' for {3.0, 3.1} and 'b' for {3.2, 3.3, 3.4, 3.5)
instead of
select fn_db_add_config_value('K1','a','3.0');
select fn_db_add_config_value('K1','a','3.1');
select fn_db_add_config_value('K1','b','3.2');
select fn_db_add_config_value('K1','b','3.3');
select fn_db_add_config_value('K1','b', '3.4');
select fn_db_add_config_value('K1','b', '3.5');
simply write :
fn_db_add_config_value_for_versions_up_to('K1','a', '3.1');
fn_db_add_config_value_for_versions_up_to('K1','b', '3.5');
Thanks
Eli Mesika
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [VDSM] [JSONRPC] early, coarse grained benchmarks
- Original Message - > From: "Francesco Romani" > To: "engine-de...@ovirt.org" > Cc: "Nir Soffer" > Sent: Monday, November 17, 2014 11:47:40 AM > Subject: Re: [ovirt-devel] [VDSM] [JSONRPC] early, coarse grained benchmarks > > - Original Message - > > From: "Nir Soffer" > > To: "Francesco Romani" > > Cc: "engine-de...@ovirt.org" > > Sent: Thursday, November 13, 2014 9:35:30 PM > > Subject: Re: [ovirt-devel] [VDSM] [JSONRPC] early, coarse grained > > benchmarks > [...] > > Note that stopping yappi may segfault, as yappi is using unsafe iteration > > on Python internal link list without locking. > > Not nice. But I guess that could be good enough if used only on controlled, > development environments > > > If we add such option, it should work only from local connection. > > How can we enforce that? Just check the peer address? This should work. Nir ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [VDSM] [JSONRPC] early, coarse grained benchmarks
- Original Message - > From: "Nir Soffer" > To: "Francesco Romani" > Cc: "engine-de...@ovirt.org" > Sent: Thursday, November 13, 2014 9:35:30 PM > Subject: Re: [ovirt-devel] [VDSM] [JSONRPC] early, coarse grained benchmarks [...] > > I'm profiling four major flows at the moment, and improving tools along the > > way. > > > > Here's my series, still being worked on and not yet ready for review (still > > draft for this reason) > > > > http://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:profile_runtime,n,z > > > > Here we have > > 1. one patch to start/stop profiling at runtime using vdsClient > > Note that stopping yappi may segfault, as yappi is using unsafe iteration > on Python internal link list without locking. Not nice. But I guess that could be good enough if used only on controlled, development environments > If we add such option, it should work only from local connection. How can we enforce that? Just check the peer address? > > http://gerrit.ovirt.org/#/c/35024/ > > http://gerrit.ovirt.org/#/c/34989/ > > http://gerrit.ovirt.org/#/c/35139 (DRAFT) > > http://gerrit.ovirt.org/#/c/35140 (DRAFT) > > > > Let's see the effect of these in the #3 flows. > > Scenario: > > RHEL 6.5 on minidell running VDSM master + patches, with 150 VMs each one 1 > > What is the cpu usage and load during the test? In previous tests you had > nice > graph with this data. To have them back is very easy, I'll do if that can help understand the behaviour of VDSM and the performance. > This is not a good test - you just overload vdsm. Instead, run this verb in a > more typical rate (like engine does) and limit the test by the running time, > not by the number of calls. > > Running like this will show that the patched version needs less cpu and > complete more > calls during the test duration (e.g. 5 mintues). Yes, this sounds more typical and probably useful. > > patched VDSM: > > What is "patched"? which patches are applied? These: > > http://gerrit.ovirt.org/#/c/35024/ > > http://gerrit.ovirt.org/#/c/34989/ > > http://gerrit.ovirt.org/#/c/35139 (DRAFT) > > http://gerrit.ovirt.org/#/c/35140 (DRAFT) > This look strange: > > vanila vdsm: 75750 19.8710.000 75.8190.001 > vm.py:2271(Vm._getRunningVmStats) > patched vdsm: 234244 183.7840.001 570.9980.002 > vm.py:2274(Vm._getRunningVmStats) > > The second profile is doing about 3 times more Vm._getRunningVmStats calls, > which takes 10 times more cpu time(?!). > > We don't have any info on the load - maybe vdsm is overloaded in both runs, > which > can explain why it does 1/3 of the work vs the patched version, but the > patched > version is probably overloaded as well, which can explain the much higher > cpu time. > > I suggest to check the cpu usage, and do *not* make profiles where vdsm uses > more > then 100% cpu. > > Lets profile much lower load to understand where time is taken. Agreed, another reason to try the scenario you suggested > > Open points: > > * profile remaining flows again and report like this (in progress for > > getAllVmStats) > > * add wiki page > > * find out why there is a so high minimum price for list verb > > * profile JSONRPC (needs patches to vdsClient) > > Comparing jsonrpc would be very interesting - but we don't have a jsonrpc > client yet, so you better use the engine for this intead of vdsclient. Will try both with new jsonrpc client you started and with engine, started with client because full-stack profiling and/or engine profiling is already in progress by others (Yuri/Piotr). 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
