From danken at redhat.com  Thu May  2 06:53:46 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Thu, 2 May 2013 09:53:46 +0300
Subject: Direct Host Address
In-Reply-To: <1437433971.1365545.1361099555481.JavaMail.root@redhat.com>
References: <20130217104402.GG23843@redhat.com>
	<1437433971.1365545.1361099555481.JavaMail.root@redhat.com>
Message-ID: <20130502065346.GA20465@redhat.com>

On Sun, Feb 17, 2013 at 06:12:35AM -0500, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "Muli Salem" <msalem at redhat.com>, arch at ovirt.org
> > Sent: Sunday, February 17, 2013 12:44:02 PM
> > Subject: Re: Direct Host Address
> > 
> > On Thu, Feb 14, 2013 at 03:27:57PM -0500, Alon Bar-Lev wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Muli Salem" <msalem at redhat.com>
> > > > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > Cc: arch at ovirt.org
> > > > Sent: Sunday, February 10, 2013 6:09:30 PM
> > > > Subject: Re: Direct Host Address
> > > > > 
> > > > > "Current behaviour assumes the network interface with the
> > > > > specified
> > > > > address is configured properly in the engine although this may
> > > > > not
> > > > > be the case initially"
> > > > > 
> > > > > I don't understand what does this mean, which interface are you
> > > > > referring to and what does it have to do with being configured
> > > > > in
> > > > > the engine?
> > > > > The next line is also unclear to me:
> > > > > "The direct address allows the engine to connect to the host,
> > > > > without
> > > > > knowing the exact configuration of the network interface that
> > > > > has
> > > > > the address. "
> > > > > 
> > > > 
> > > > Regarding the last two sentences you quoted:
> > > > 
> > > > I am referring to the interface that has the IP that the user
> > > > gives
> > > > us (with regards to current behavior).
> > > > At the moment, we assume that the given IP is for an interface
> > > > that
> > > > can communicate with the engine (when in practice, this may not
> > > > be
> > > > the case).
> > > > So separating the two addresses, allows us to ask the admin for
> > > > an
> > > > alternate IP address that will allow communication without
> > > > needing
> > > > to know the specific configuration (for example, whether this is
> > > > a
> > > > VLAN network or not).
> > > > 
> > > > Perhaps the wording should be changed a bit to clarify.
> > > 
> > > I still don't get it... can you please provide real world use case?
> > > 
> > > When can we access the alternate address and not the management
> > > address?
> > 
> > We have customers who want to install vdsm via native connection, but
> > manage it over a VLAN. If you want to add a fresh host, you cannot
> > use
> > its management address (that sits inside the vlan).
> > 
> 
> So as far as I understand the prerequisite of this feature is to perform host deploy (ovirt-host-deploy) without constructing the management bridge.
> 
> In this mode, during host deployment (ovirt-host-deploy) the engine uses the host name only to be able to construct proper CN field for the certificate of VDSM.
> 
> Then the engine performs provisioning of the host to define the host name's ip address on the optional vlan id that is shared by the entire cluster.
> 
> Maybe there will not be a management bridge at all, which makes me happy!
> 
> This means that:
> 1. No management bridge name is to be provided to ovirt-host-deply (this is to do in the prerequisite of the feature).
> 2. New parameter for the VdsDeploy at engine side of IP address to SSH.
> 3. After VdsDeploy is finished, there is provisioning to define the management address on the host using standard VDSM communication.
> 
> Am I missing anything?

You haven't - but apprently I have. Your point (2) would be useful only
when we can use it to tunnel getVdsCaps and setupNetworks verbs on top
of ssh. Without this ability, we gain hardly anything: the first
Engine-to-vdsm call would have to go to the management interface, using
its proper CN, meaning that we have to have the management interface up
and running and answering xmlrpc before we have a chance to setup a vlan
tag for it. Thus, we decided to scrap this point (2) for now.


From dneary at redhat.com  Mon May  6 22:55:19 2013
From: dneary at redhat.com (Dave Neary)
Date: Tue, 07 May 2013 00:55:19 +0200
Subject: 3.3 release engineering - awesome page!
Message-ID: <518834D7.3030708@redhat.com>

Hi all,

I came across this page today when looking for information on the 3.3
release timeline: http://www.ovirt.org/oVirt_3.3_release-management

This is awesome! I was a little surprised, because I hadn't seen a lot
of discussion on the arch list about the 3.3 release planning, but this
is a great resource to have.

Can I suggest one improvement which could be done this week, please?
There's no way of knowing from this page which features in the MUST,
SHOULD lists are done and just awaiting release, in need of QE and
testing, being actively worked on (and if so, by who?) and which
features are there aspirationally and won't be worked on unless someone
volunteers to pick them up.

This would also give an opportunity to see whether the 2013-05-31 beta
release date is at all realistic now, and whether we need a feature
bump/feature freeze meeting soon which allows us to stay on schedule.

If you're working on a feature that's in this page and it's not
finished, would you mind adding a link to the feature page (if there is
one) and adding your name to the feature, please? And if the feature is
done, please link to the feature page, or some other resource that
allows people to use and test it - and (if possible) the changelog
entry/gerrit where the patch was included.

Thanks!
Dave.

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From masayag at redhat.com  Tue May  7 11:22:19 2013
From: masayag at redhat.com (Moti Asayag)
Date: Tue, 7 May 2013 07:22:19 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <20130101124757.GI7274@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
Message-ID: <1264143158.8051712.1367925739116.JavaMail.root@redhat.com>

I stumbled upon few issues with the current design while implementing it:

There seems to be a requirement to reboot the host after the installation
is completed in order to assure the host is recoverable.

Therefore, the building blocks of the installation process of 3.3 are:
1. host deploy which installs the host expect configuring its management network.
2. SetupNetwork (and CommitNetworkChanges) - for creating the management network 
on the host and persisting the network configuration.
3. Reboot the host - This is a missing piece. (engine has FenceVds command, but it 
requires the power management to be configured prior to the installation and might 
be irrelevant for hosts without PM.)

So, there are couple of issues here:
1. How to reboot the host?
1.1. By exposing new RebootNode verb in VDSM and invoking it from the engine
1.2. By opening ssh dialog to the host in order to execute the reboot

2. When to perform the reboot?
2.1. After host deploy, by utilizing the host deploy to perform the reboot. 
It requires to configure the network by the monitor when the host is detected by the engine,
detached from the installation flow. However it is a step toward the non-persistent network feature
yet to be defined.
2.2. After setupNetwork is done and network was configured and persisted on the host.
There is no special advantage from recoverable aspect, as setupNetwork is constantly
used to persist the network configuration (by the complementary CommitNetworkChanges command).
In case and network configuration fails, VDSM will revert to the last well known configuration 
- so connectivity with engine should be restored. Design wise, it fits to configure the management
 network as part of the installation sequence.
If the network configuration fails in this context, the host status will be set to "InstallFailed" rather than "NonOperational",
as might occur as a result of a failed setupNetwork command.


Your inputs are welcome.

Thanks,
Moti
----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>, "Moti Asayag" <masayag at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Tuesday, January 1, 2013 2:47:57 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> On Thu, Dec 27, 2012 at 07:36:40AM -0500, Simon Grinberg wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > To: "Simon Grinberg" <simon at redhat.com>
> > > Cc: "arch" <arch at ovirt.org>
> > > Sent: Thursday, December 27, 2012 2:14:06 PM
> > > Subject: Re: feature suggestion: initial generation of management network
> > > 
> > > On Tue, Dec 25, 2012 at 09:29:26AM -0500, Simon Grinberg wrote:
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > To: "arch" <arch at ovirt.org>
> > > > > Sent: Tuesday, December 25, 2012 2:27:22 PM
> > > > > Subject: feature suggestion: initial generation of management
> > > > > network
> > > > > 
> > > > > Current condition:
> > > > > ==================
> > > > > The management network, named ovirtmgmt, is created during host
> > > > > bootstrap. It consists of a bridge device, connected to the
> > > > > network
> > > > > device that was used to communicate with Engine (nic, bonding or
> > > > > vlan).
> > > > > It inherits its ip settings from the latter device.
> > > > > 
> > > > > Why Is the Management Network Needed?
> > > > > =====================================
> > > > > Understandably, some may ask why do we need to have a management
> > > > > network - why having a host with IPv4 configured on it is not
> > > > > enough.
> > > > > The answer is twofold:
> > > > > 1. In oVirt, a network is an abstraction of the resources
> > > > > required
> > > > > for
> > > > >    connectivity of a host for a specific usage. This is true for
> > > > >    the
> > > > >    management network just as it is for VM network or a display
> > > > >    network.
> > > > >    The network entity is the key for adding/changing nics and IP
> > > > >    address.
> > > > > 2. In many occasions (such as small setups) the management
> > > > > network is
> > > > >    used as a VM/display network as well.
> > > > > 
> > > > > Problems in current connectivity:
> > > > > ================================
> > > > > According to alonbl of ovirt-host-deploy fame, and with no
> > > > > conflict
> > > > > to
> > > > > my own experience, creating the management network is the most
> > > > > fragile,
> > > > > error-prone step of bootstrap.
> > > > 
> > > > +1,
> > > > I've raise that repeatedly in the past, bootstrap should not create
> > > > the management network but pick up the existing configuration and
> > > > let the engine override later with it's own configuration if it
> > > > differs , I'm glad that we finally get to that.
> > > > 
> > > > > 
> > > > > Currently it always creates a bridged network (even if the DC
> > > > > requires a
> > > > > non-bridged ovirtmgmt), it knows nothing about the defined MTU
> > > > > for
> > > > > ovirtmgmt, it uses ping to guess on top of which device to build
> > > > > (and
> > > > > thus requires Vdsm-to-Engine reverse connectivity), and is the
> > > > > sole
> > > > > remaining user of the addNetwork/vdsm-store-net-conf scripts.
> > > > > 
> > > > > Suggested feature:
> > > > > ==================
> > > > > Bootstrap would avoid creating a management network. Instead,
> > > > > after
> > > > > bootstrapping a host, Engine would send a getVdsCaps probe to the
> > > > > installed host, receiving a complete picture of the network
> > > > > configuration on the host. Among this picture is the device that
> > > > > holds
> > > > > the host's management IP address.
> > > > > 
> > > > > Engine would send setupNetwork command to generate ovirtmgmt with
> > > > > details devised from this picture, and according to the DC
> > > > > definition
> > > > > of
> > > > > ovirtmgmt.  For example, if Vdsm reports:
> > > > > 
> > > > > - vlan bond4.3000 has the host's IP, configured to use dhcp.
> > > > > - bond4 is comprises eth2 and eth3
> > > > > - ovirtmgmt is defined as a VM network with MTU 9000
> > > > > 
> > > > > then Engine sends the likes of:
> > > > >   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
> > > > >                 bonding=bond4: {eth2,eth3}, MTU=9000)
> > > > 
> > > > Just one comment here,
> > > > In order to save time and confusion - if the ovirtmgmt is defined
> > > > with default values meaning the user did not bother to touch it,
> > > > let it pick up the VLAN configuration from the first host added in
> > > > the Data Center.
> > > > 
> > > > Otherwise, you may override the host VLAN and loose connectivity.
> > > > 
> > > > This will also solve the situation many users encounter today.
> > > > 1. The engine in on a host that actually has VLAN defined
> > > > 2. The ovirtmgmt network was not updated in the DC
> > > > 3. A host, with VLAN already defined is added - everything works
> > > > fine
> > > > 4. Any number of hosts are now added, again everything seems to
> > > > work fine.
> > > > 
> > > > But, now try to use setupNetworks, and you'll find out that you
> > > > can't do much on the interface that contains the ovirtmgmt since
> > > > the definition does not match. You can't sync (Since this will
> > > > remove the VLAN and cause connectivity lose) you can't add more
> > > > networks on top since it already has non-VLAN network on top
> > > > according to the DC definition, etc.
> > > > 
> > > > On the other hand you can't update the ovirtmgmt definition on the
> > > > DC since there are clusters in the DC that use the network.
> > > > 
> > > > The only workaround not involving DB hack to change the VLAN on the
> > > > network is to:
> > > > 1. Create new DC
> > > > 2. Do not use the wizard that pops up to create your cluster.
> > > > 3. Modify the ovirtmgmt network to have VLANs
> > > > 4. Now create a cluster and add your hosts.
> > > > 
> > > > If you insist on using the default DC and cluster then before
> > > > adding the first host, create an additional DC and move the
> > > > Default cluster over there. You may then change the network on the
> > > > Default cluster and then move the Default cluster back
> > > > 
> > > > Both are ugly. And should be solved by the proposal above.
> > > > 
> > > > We do something similar for the Default cluster CPU level, where we
> > > > set the intial level based on the first host added to the cluster.
> > > 
> > > I'm not sure what Engine has for Default cluster CPU level. But I
> > > have
> > > reservation of the hysteresis in your proposal - after a host is
> > > added,
> > > the DC cannot forget ovirtmgmt's vlan.
> > > 
> > > How about letting the admin edit ovirtmgmt's vlan in the DC level,
> > > thus
> > > rendering all hosts out-of-sync. The the admin could manually, or
> > > through a script, or in the future through a distributed operation,
> > > sync
> > > all the hosts to the definition?
> > 
> > Usually if you do that you will loose connectivity to the hosts.
> 
> Yes, changing the management vlan id (or ip address) is never fun, and
> requires out-of-band intervention.
> 
> > I'm not insisting on the automatic adjustment of the ovirtmgmt network to
> > match the hosts' (that is just a nice touch) we can take the allow edit
> > approach.
> > 
> > But allow to change VLAN on the ovirtmgmt network will indeed solve the
> > issue I'm trying to solve while creating another issue of user expecting
> > that we'll be able to re-tag the host from the engine side, which is
> > challenging to do.
> > 
> > On the other hand, if we allow to change the VLAN as long as the change
> > matches the hosts' configuration, it will both solve the issue while not
> > eluding the user to think that we really can solve the chicken and egg
> > issue of re-tag the entire system.
> > 
> > Now with the above ability you do get a flow to do the re-tag.
> > 1. Place all the hosts in maintenance
> > 2. Re-tag the ovirtmgmt on all the hosts
> > 3. Re-tag the hosts on which the engine on
> > 4. Activate the hosts - this should work well now since connectivity exist
> > 5. Change the tag on ovirtmgmt on the engine to match the hosts'
> > 
> > Simple and clear process.
> > 
> > When the workaround of creating another DC was not possible since the
> > system was already long in use and the need was re-tag of the network the
> > above is what I've recommended in the, except that steps 4-5 where done
> > as:
> > 4. Stop the engine
> > 5. Change the tag in the DB
> > 6. Start the engine
> > 7. Activate the hosts
> 
> Sounds reasonable to me - but as far as I am aware this is not tightly
> related to the $Subject, which is the post-boot ovirtmgmt definition.
> 
> I've added a few details to
> http://www.ovirt.org/Features/Normalized_ovirtmgmt_Initialization#Engine
> and I would apreciate a review from someone with intimate Engine
> know-how.
> 
> Dan.
> 


From mkolesni at redhat.com  Tue May  7 11:33:15 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Tue, 7 May 2013 07:33:15 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
Message-ID: <1633347300.8227458.1367926395327.JavaMail.root@redhat.com>

----- Original Message -----
> I stumbled upon few issues with the current design while implementing it:
> 
> There seems to be a requirement to reboot the host after the installation
> is completed in order to assure the host is recoverable.
> 
> Therefore, the building blocks of the installation process of 3.3 are:
> 1. host deploy which installs the host expect configuring its management
> network.
> 2. SetupNetwork (and CommitNetworkChanges) - for creating the management
> network
> on the host and persisting the network configuration.
> 3. Reboot the host - This is a missing piece. (engine has FenceVds command,
> but it
> requires the power management to be configured prior to the installation and
> might
> be irrelevant for hosts without PM.)
> 
> So, there are couple of issues here:
> 1. How to reboot the host?
> 1.1. By exposing new RebootNode verb in VDSM and invoking it from the engine

This sounds like a solid and good API to me.

> 1.2. By opening ssh dialog to the host in order to execute the reboot

How would you do this?

> 
> 2. When to perform the reboot?
> 2.1. After host deploy, by utilizing the host deploy to perform the reboot.
> It requires to configure the network by the monitor when the host is detected
> by the engine,
> detached from the installation flow. However it is a step toward the
> non-persistent network feature
> yet to be defined.

I am not sure this statement has merit, if the feature is yet to be defined, how
can we know if this is a step towards it or not?

Anyway, I'm not sure that this is a good design - should we setup the network
when host returns from non-responsive status?

> 2.2. After setupNetwork is done and network was configured and persisted on
> the host.
> There is no special advantage from recoverable aspect, as setupNetwork is
> constantly
> used to persist the network configuration (by the complementary
> CommitNetworkChanges command).
> In case and network configuration fails, VDSM will revert to the last well
> known configuration
> - so connectivity with engine should be restored. Design wise, it fits to
> configure the management
>  network as part of the installation sequence.
> If the network configuration fails in this context, the host status will be
> set to "InstallFailed" rather than "NonOperational",
> as might occur as a result of a failed setupNetwork command.

This sounds like the good solution to me, design wise. The host is installed
and with that the communication with the management network is configured.
If this communication is not possible, the host failed to install (also meaning
it's not operational). I see no problem with this approach.

> 
> 
> Your inputs are welcome.
> 
> Thanks,
> Moti
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Simon Grinberg" <simon at redhat.com>, "Moti Asayag" <masayag at redhat.com>
> > Cc: "arch" <arch at ovirt.org>
> > Sent: Tuesday, January 1, 2013 2:47:57 PM
> > Subject: Re: feature suggestion: initial generation of management network
> > 
> > On Thu, Dec 27, 2012 at 07:36:40AM -0500, Simon Grinberg wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > To: "Simon Grinberg" <simon at redhat.com>
> > > > Cc: "arch" <arch at ovirt.org>
> > > > Sent: Thursday, December 27, 2012 2:14:06 PM
> > > > Subject: Re: feature suggestion: initial generation of management
> > > > network
> > > > 
> > > > On Tue, Dec 25, 2012 at 09:29:26AM -0500, Simon Grinberg wrote:
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > > To: "arch" <arch at ovirt.org>
> > > > > > Sent: Tuesday, December 25, 2012 2:27:22 PM
> > > > > > Subject: feature suggestion: initial generation of management
> > > > > > network
> > > > > > 
> > > > > > Current condition:
> > > > > > ==================
> > > > > > The management network, named ovirtmgmt, is created during host
> > > > > > bootstrap. It consists of a bridge device, connected to the
> > > > > > network
> > > > > > device that was used to communicate with Engine (nic, bonding or
> > > > > > vlan).
> > > > > > It inherits its ip settings from the latter device.
> > > > > > 
> > > > > > Why Is the Management Network Needed?
> > > > > > =====================================
> > > > > > Understandably, some may ask why do we need to have a management
> > > > > > network - why having a host with IPv4 configured on it is not
> > > > > > enough.
> > > > > > The answer is twofold:
> > > > > > 1. In oVirt, a network is an abstraction of the resources
> > > > > > required
> > > > > > for
> > > > > >    connectivity of a host for a specific usage. This is true for
> > > > > >    the
> > > > > >    management network just as it is for VM network or a display
> > > > > >    network.
> > > > > >    The network entity is the key for adding/changing nics and IP
> > > > > >    address.
> > > > > > 2. In many occasions (such as small setups) the management
> > > > > > network is
> > > > > >    used as a VM/display network as well.
> > > > > > 
> > > > > > Problems in current connectivity:
> > > > > > ================================
> > > > > > According to alonbl of ovirt-host-deploy fame, and with no
> > > > > > conflict
> > > > > > to
> > > > > > my own experience, creating the management network is the most
> > > > > > fragile,
> > > > > > error-prone step of bootstrap.
> > > > > 
> > > > > +1,
> > > > > I've raise that repeatedly in the past, bootstrap should not create
> > > > > the management network but pick up the existing configuration and
> > > > > let the engine override later with it's own configuration if it
> > > > > differs , I'm glad that we finally get to that.
> > > > > 
> > > > > > 
> > > > > > Currently it always creates a bridged network (even if the DC
> > > > > > requires a
> > > > > > non-bridged ovirtmgmt), it knows nothing about the defined MTU
> > > > > > for
> > > > > > ovirtmgmt, it uses ping to guess on top of which device to build
> > > > > > (and
> > > > > > thus requires Vdsm-to-Engine reverse connectivity), and is the
> > > > > > sole
> > > > > > remaining user of the addNetwork/vdsm-store-net-conf scripts.
> > > > > > 
> > > > > > Suggested feature:
> > > > > > ==================
> > > > > > Bootstrap would avoid creating a management network. Instead,
> > > > > > after
> > > > > > bootstrapping a host, Engine would send a getVdsCaps probe to the
> > > > > > installed host, receiving a complete picture of the network
> > > > > > configuration on the host. Among this picture is the device that
> > > > > > holds
> > > > > > the host's management IP address.
> > > > > > 
> > > > > > Engine would send setupNetwork command to generate ovirtmgmt with
> > > > > > details devised from this picture, and according to the DC
> > > > > > definition
> > > > > > of
> > > > > > ovirtmgmt.  For example, if Vdsm reports:
> > > > > > 
> > > > > > - vlan bond4.3000 has the host's IP, configured to use dhcp.
> > > > > > - bond4 is comprises eth2 and eth3
> > > > > > - ovirtmgmt is defined as a VM network with MTU 9000
> > > > > > 
> > > > > > then Engine sends the likes of:
> > > > > >   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
> > > > > >                 bonding=bond4: {eth2,eth3}, MTU=9000)
> > > > > 
> > > > > Just one comment here,
> > > > > In order to save time and confusion - if the ovirtmgmt is defined
> > > > > with default values meaning the user did not bother to touch it,
> > > > > let it pick up the VLAN configuration from the first host added in
> > > > > the Data Center.
> > > > > 
> > > > > Otherwise, you may override the host VLAN and loose connectivity.
> > > > > 
> > > > > This will also solve the situation many users encounter today.
> > > > > 1. The engine in on a host that actually has VLAN defined
> > > > > 2. The ovirtmgmt network was not updated in the DC
> > > > > 3. A host, with VLAN already defined is added - everything works
> > > > > fine
> > > > > 4. Any number of hosts are now added, again everything seems to
> > > > > work fine.
> > > > > 
> > > > > But, now try to use setupNetworks, and you'll find out that you
> > > > > can't do much on the interface that contains the ovirtmgmt since
> > > > > the definition does not match. You can't sync (Since this will
> > > > > remove the VLAN and cause connectivity lose) you can't add more
> > > > > networks on top since it already has non-VLAN network on top
> > > > > according to the DC definition, etc.
> > > > > 
> > > > > On the other hand you can't update the ovirtmgmt definition on the
> > > > > DC since there are clusters in the DC that use the network.
> > > > > 
> > > > > The only workaround not involving DB hack to change the VLAN on the
> > > > > network is to:
> > > > > 1. Create new DC
> > > > > 2. Do not use the wizard that pops up to create your cluster.
> > > > > 3. Modify the ovirtmgmt network to have VLANs
> > > > > 4. Now create a cluster and add your hosts.
> > > > > 
> > > > > If you insist on using the default DC and cluster then before
> > > > > adding the first host, create an additional DC and move the
> > > > > Default cluster over there. You may then change the network on the
> > > > > Default cluster and then move the Default cluster back
> > > > > 
> > > > > Both are ugly. And should be solved by the proposal above.
> > > > > 
> > > > > We do something similar for the Default cluster CPU level, where we
> > > > > set the intial level based on the first host added to the cluster.
> > > > 
> > > > I'm not sure what Engine has for Default cluster CPU level. But I
> > > > have
> > > > reservation of the hysteresis in your proposal - after a host is
> > > > added,
> > > > the DC cannot forget ovirtmgmt's vlan.
> > > > 
> > > > How about letting the admin edit ovirtmgmt's vlan in the DC level,
> > > > thus
> > > > rendering all hosts out-of-sync. The the admin could manually, or
> > > > through a script, or in the future through a distributed operation,
> > > > sync
> > > > all the hosts to the definition?
> > > 
> > > Usually if you do that you will loose connectivity to the hosts.
> > 
> > Yes, changing the management vlan id (or ip address) is never fun, and
> > requires out-of-band intervention.
> > 
> > > I'm not insisting on the automatic adjustment of the ovirtmgmt network to
> > > match the hosts' (that is just a nice touch) we can take the allow edit
> > > approach.
> > > 
> > > But allow to change VLAN on the ovirtmgmt network will indeed solve the
> > > issue I'm trying to solve while creating another issue of user expecting
> > > that we'll be able to re-tag the host from the engine side, which is
> > > challenging to do.
> > > 
> > > On the other hand, if we allow to change the VLAN as long as the change
> > > matches the hosts' configuration, it will both solve the issue while not
> > > eluding the user to think that we really can solve the chicken and egg
> > > issue of re-tag the entire system.
> > > 
> > > Now with the above ability you do get a flow to do the re-tag.
> > > 1. Place all the hosts in maintenance
> > > 2. Re-tag the ovirtmgmt on all the hosts
> > > 3. Re-tag the hosts on which the engine on
> > > 4. Activate the hosts - this should work well now since connectivity
> > > exist
> > > 5. Change the tag on ovirtmgmt on the engine to match the hosts'
> > > 
> > > Simple and clear process.
> > > 
> > > When the workaround of creating another DC was not possible since the
> > > system was already long in use and the need was re-tag of the network the
> > > above is what I've recommended in the, except that steps 4-5 where done
> > > as:
> > > 4. Stop the engine
> > > 5. Change the tag in the DB
> > > 6. Start the engine
> > > 7. Activate the hosts
> > 
> > Sounds reasonable to me - but as far as I am aware this is not tightly
> > related to the $Subject, which is the post-boot ovirtmgmt definition.
> > 
> > I've added a few details to
> > http://www.ovirt.org/Features/Normalized_ovirtmgmt_Initialization#Engine
> > and I would apreciate a review from someone with intimate Engine
> > know-how.
> > 
> > Dan.
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From ofrenkel at redhat.com  Tue May  7 13:11:05 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Tue, 7 May 2013 09:11:05 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
Message-ID: <497587874.11990711.1367932265918.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "arch" <arch at ovirt.org>
> Cc: "Alon Bar-Lev" <abarlev at redhat.com>
> Sent: Tuesday, May 7, 2013 2:22:19 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> I stumbled upon few issues with the current design while implementing it:
> 
> There seems to be a requirement to reboot the host after the installation
> is completed in order to assure the host is recoverable.
> 
> Therefore, the building blocks of the installation process of 3.3 are:
> 1. host deploy which installs the host expect configuring its management
> network.
> 2. SetupNetwork (and CommitNetworkChanges) - for creating the management
> network
> on the host and persisting the network configuration.
> 3. Reboot the host - This is a missing piece. (engine has FenceVds command,
> but it
> requires the power management to be configured prior to the installation and
> might
> be irrelevant for hosts without PM.)
> 
> So, there are couple of issues here:
> 1. How to reboot the host?
> 1.1. By exposing new RebootNode verb in VDSM and invoking it from the engine
> 1.2. By opening ssh dialog to the host in order to execute the reboot
> 

why not send a reboot flag to the CommitNetworkChanges which is sent anyway,
one less call (or connection if you choose ssh) and easier to do.

> 2. When to perform the reboot?
> 2.1. After host deploy, by utilizing the host deploy to perform the reboot.
> It requires to configure the network by the monitor when the host is detected
> by the engine,
> detached from the installation flow. However it is a step toward the
> non-persistent network feature
> yet to be defined.
> 2.2. After setupNetwork is done and network was configured and persisted on
> the host.
> There is no special advantage from recoverable aspect, as setupNetwork is
> constantly
> used to persist the network configuration (by the complementary
> CommitNetworkChanges command).
> In case and network configuration fails, VDSM will revert to the last well
> known configuration
> - so connectivity with engine should be restored. Design wise, it fits to
> configure the management
>  network as part of the installation sequence.
> If the network configuration fails in this context, the host status will be
> set to "InstallFailed" rather than "NonOperational",
> as might occur as a result of a failed setupNetwork command.
> 
> 
> Your inputs are welcome.
> 
> Thanks,
> Moti
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Simon Grinberg" <simon at redhat.com>, "Moti Asayag" <masayag at redhat.com>
> > Cc: "arch" <arch at ovirt.org>
> > Sent: Tuesday, January 1, 2013 2:47:57 PM
> > Subject: Re: feature suggestion: initial generation of management network
> > 
> > On Thu, Dec 27, 2012 at 07:36:40AM -0500, Simon Grinberg wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > To: "Simon Grinberg" <simon at redhat.com>
> > > > Cc: "arch" <arch at ovirt.org>
> > > > Sent: Thursday, December 27, 2012 2:14:06 PM
> > > > Subject: Re: feature suggestion: initial generation of management
> > > > network
> > > > 
> > > > On Tue, Dec 25, 2012 at 09:29:26AM -0500, Simon Grinberg wrote:
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > > To: "arch" <arch at ovirt.org>
> > > > > > Sent: Tuesday, December 25, 2012 2:27:22 PM
> > > > > > Subject: feature suggestion: initial generation of management
> > > > > > network
> > > > > > 
> > > > > > Current condition:
> > > > > > ==================
> > > > > > The management network, named ovirtmgmt, is created during host
> > > > > > bootstrap. It consists of a bridge device, connected to the
> > > > > > network
> > > > > > device that was used to communicate with Engine (nic, bonding or
> > > > > > vlan).
> > > > > > It inherits its ip settings from the latter device.
> > > > > > 
> > > > > > Why Is the Management Network Needed?
> > > > > > =====================================
> > > > > > Understandably, some may ask why do we need to have a management
> > > > > > network - why having a host with IPv4 configured on it is not
> > > > > > enough.
> > > > > > The answer is twofold:
> > > > > > 1. In oVirt, a network is an abstraction of the resources
> > > > > > required
> > > > > > for
> > > > > >    connectivity of a host for a specific usage. This is true for
> > > > > >    the
> > > > > >    management network just as it is for VM network or a display
> > > > > >    network.
> > > > > >    The network entity is the key for adding/changing nics and IP
> > > > > >    address.
> > > > > > 2. In many occasions (such as small setups) the management
> > > > > > network is
> > > > > >    used as a VM/display network as well.
> > > > > > 
> > > > > > Problems in current connectivity:
> > > > > > ================================
> > > > > > According to alonbl of ovirt-host-deploy fame, and with no
> > > > > > conflict
> > > > > > to
> > > > > > my own experience, creating the management network is the most
> > > > > > fragile,
> > > > > > error-prone step of bootstrap.
> > > > > 
> > > > > +1,
> > > > > I've raise that repeatedly in the past, bootstrap should not create
> > > > > the management network but pick up the existing configuration and
> > > > > let the engine override later with it's own configuration if it
> > > > > differs , I'm glad that we finally get to that.
> > > > > 
> > > > > > 
> > > > > > Currently it always creates a bridged network (even if the DC
> > > > > > requires a
> > > > > > non-bridged ovirtmgmt), it knows nothing about the defined MTU
> > > > > > for
> > > > > > ovirtmgmt, it uses ping to guess on top of which device to build
> > > > > > (and
> > > > > > thus requires Vdsm-to-Engine reverse connectivity), and is the
> > > > > > sole
> > > > > > remaining user of the addNetwork/vdsm-store-net-conf scripts.
> > > > > > 
> > > > > > Suggested feature:
> > > > > > ==================
> > > > > > Bootstrap would avoid creating a management network. Instead,
> > > > > > after
> > > > > > bootstrapping a host, Engine would send a getVdsCaps probe to the
> > > > > > installed host, receiving a complete picture of the network
> > > > > > configuration on the host. Among this picture is the device that
> > > > > > holds
> > > > > > the host's management IP address.
> > > > > > 
> > > > > > Engine would send setupNetwork command to generate ovirtmgmt with
> > > > > > details devised from this picture, and according to the DC
> > > > > > definition
> > > > > > of
> > > > > > ovirtmgmt.  For example, if Vdsm reports:
> > > > > > 
> > > > > > - vlan bond4.3000 has the host's IP, configured to use dhcp.
> > > > > > - bond4 is comprises eth2 and eth3
> > > > > > - ovirtmgmt is defined as a VM network with MTU 9000
> > > > > > 
> > > > > > then Engine sends the likes of:
> > > > > >   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
> > > > > >                 bonding=bond4: {eth2,eth3}, MTU=9000)
> > > > > 
> > > > > Just one comment here,
> > > > > In order to save time and confusion - if the ovirtmgmt is defined
> > > > > with default values meaning the user did not bother to touch it,
> > > > > let it pick up the VLAN configuration from the first host added in
> > > > > the Data Center.
> > > > > 
> > > > > Otherwise, you may override the host VLAN and loose connectivity.
> > > > > 
> > > > > This will also solve the situation many users encounter today.
> > > > > 1. The engine in on a host that actually has VLAN defined
> > > > > 2. The ovirtmgmt network was not updated in the DC
> > > > > 3. A host, with VLAN already defined is added - everything works
> > > > > fine
> > > > > 4. Any number of hosts are now added, again everything seems to
> > > > > work fine.
> > > > > 
> > > > > But, now try to use setupNetworks, and you'll find out that you
> > > > > can't do much on the interface that contains the ovirtmgmt since
> > > > > the definition does not match. You can't sync (Since this will
> > > > > remove the VLAN and cause connectivity lose) you can't add more
> > > > > networks on top since it already has non-VLAN network on top
> > > > > according to the DC definition, etc.
> > > > > 
> > > > > On the other hand you can't update the ovirtmgmt definition on the
> > > > > DC since there are clusters in the DC that use the network.
> > > > > 
> > > > > The only workaround not involving DB hack to change the VLAN on the
> > > > > network is to:
> > > > > 1. Create new DC
> > > > > 2. Do not use the wizard that pops up to create your cluster.
> > > > > 3. Modify the ovirtmgmt network to have VLANs
> > > > > 4. Now create a cluster and add your hosts.
> > > > > 
> > > > > If you insist on using the default DC and cluster then before
> > > > > adding the first host, create an additional DC and move the
> > > > > Default cluster over there. You may then change the network on the
> > > > > Default cluster and then move the Default cluster back
> > > > > 
> > > > > Both are ugly. And should be solved by the proposal above.
> > > > > 
> > > > > We do something similar for the Default cluster CPU level, where we
> > > > > set the intial level based on the first host added to the cluster.
> > > > 
> > > > I'm not sure what Engine has for Default cluster CPU level. But I
> > > > have
> > > > reservation of the hysteresis in your proposal - after a host is
> > > > added,
> > > > the DC cannot forget ovirtmgmt's vlan.
> > > > 
> > > > How about letting the admin edit ovirtmgmt's vlan in the DC level,
> > > > thus
> > > > rendering all hosts out-of-sync. The the admin could manually, or
> > > > through a script, or in the future through a distributed operation,
> > > > sync
> > > > all the hosts to the definition?
> > > 
> > > Usually if you do that you will loose connectivity to the hosts.
> > 
> > Yes, changing the management vlan id (or ip address) is never fun, and
> > requires out-of-band intervention.
> > 
> > > I'm not insisting on the automatic adjustment of the ovirtmgmt network to
> > > match the hosts' (that is just a nice touch) we can take the allow edit
> > > approach.
> > > 
> > > But allow to change VLAN on the ovirtmgmt network will indeed solve the
> > > issue I'm trying to solve while creating another issue of user expecting
> > > that we'll be able to re-tag the host from the engine side, which is
> > > challenging to do.
> > > 
> > > On the other hand, if we allow to change the VLAN as long as the change
> > > matches the hosts' configuration, it will both solve the issue while not
> > > eluding the user to think that we really can solve the chicken and egg
> > > issue of re-tag the entire system.
> > > 
> > > Now with the above ability you do get a flow to do the re-tag.
> > > 1. Place all the hosts in maintenance
> > > 2. Re-tag the ovirtmgmt on all the hosts
> > > 3. Re-tag the hosts on which the engine on
> > > 4. Activate the hosts - this should work well now since connectivity
> > > exist
> > > 5. Change the tag on ovirtmgmt on the engine to match the hosts'
> > > 
> > > Simple and clear process.
> > > 
> > > When the workaround of creating another DC was not possible since the
> > > system was already long in use and the need was re-tag of the network the
> > > above is what I've recommended in the, except that steps 4-5 where done
> > > as:
> > > 4. Stop the engine
> > > 5. Change the tag in the DB
> > > 6. Start the engine
> > > 7. Activate the hosts
> > 
> > Sounds reasonable to me - but as far as I am aware this is not tightly
> > related to the $Subject, which is the post-boot ovirtmgmt definition.
> > 
> > I've added a few details to
> > http://www.ovirt.org/Features/Normalized_ovirtmgmt_Initialization#Engine
> > and I would apreciate a review from someone with intimate Engine
> > know-how.
> > 
> > Dan.
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From masayag at redhat.com  Tue May  7 13:31:47 2013
From: masayag at redhat.com (Moti Asayag)
Date: Tue, 7 May 2013 09:31:47 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <497587874.11990711.1367932265918.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<497587874.11990711.1367932265918.JavaMail.root@redhat.com>
Message-ID: <1596048609.8203468.1367933507824.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Omer Frenkel" <ofrenkel at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>
> Cc: "arch" <arch at ovirt.org>, "Alon Bar-Lev" <abarlev at redhat.com>
> Sent: Tuesday, May 7, 2013 4:11:05 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> 
> 
> ----- Original Message -----
> > From: "Moti Asayag" <masayag at redhat.com>
> > To: "arch" <arch at ovirt.org>
> > Cc: "Alon Bar-Lev" <abarlev at redhat.com>
> > Sent: Tuesday, May 7, 2013 2:22:19 PM
> > Subject: Re: feature suggestion: initial generation of management network
> > 
> > I stumbled upon few issues with the current design while implementing it:
> > 
> > There seems to be a requirement to reboot the host after the installation
> > is completed in order to assure the host is recoverable.
> > 
> > Therefore, the building blocks of the installation process of 3.3 are:
> > 1. host deploy which installs the host expect configuring its management
> > network.
> > 2. SetupNetwork (and CommitNetworkChanges) - for creating the management
> > network
> > on the host and persisting the network configuration.
> > 3. Reboot the host - This is a missing piece. (engine has FenceVds command,
> > but it
> > requires the power management to be configured prior to the installation
> > and
> > might
> > be irrelevant for hosts without PM.)
> > 
> > So, there are couple of issues here:
> > 1. How to reboot the host?
> > 1.1. By exposing new RebootNode verb in VDSM and invoking it from the
> > engine
> > 1.2. By opening ssh dialog to the host in order to execute the reboot
> > 
> 
> why not send a reboot flag to the CommitNetworkChanges which is sent anyway,
> one less call (or connection if you choose ssh) and easier to do.
> 

Adding a reboot parameter to the CommitNetworkChanges (setSafeNetworkConfig on vdsm side) 
exceeds its logical scope which is persisting the network changes.

Needless to say if such functionally will be required elsewhere, it couldn't be
properly reused if implemented as part of that command.

Adding Dan to comment on this as well.

> > 2. When to perform the reboot?
> > 2.1. After host deploy, by utilizing the host deploy to perform the reboot.
> > It requires to configure the network by the monitor when the host is
> > detected
> > by the engine,
> > detached from the installation flow. However it is a step toward the
> > non-persistent network feature
> > yet to be defined.
> > 2.2. After setupNetwork is done and network was configured and persisted on
> > the host.
> > There is no special advantage from recoverable aspect, as setupNetwork is
> > constantly
> > used to persist the network configuration (by the complementary
> > CommitNetworkChanges command).
> > In case and network configuration fails, VDSM will revert to the last well
> > known configuration
> > - so connectivity with engine should be restored. Design wise, it fits to
> > configure the management
> >  network as part of the installation sequence.
> > If the network configuration fails in this context, the host status will be
> > set to "InstallFailed" rather than "NonOperational",
> > as might occur as a result of a failed setupNetwork command.
> > 
> > 
> > Your inputs are welcome.
> > 
> > Thanks,
> > Moti
> > ----- Original Message -----
> > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > To: "Simon Grinberg" <simon at redhat.com>, "Moti Asayag"
> > > <masayag at redhat.com>
> > > Cc: "arch" <arch at ovirt.org>
> > > Sent: Tuesday, January 1, 2013 2:47:57 PM
> > > Subject: Re: feature suggestion: initial generation of management network
> > > 
> > > On Thu, Dec 27, 2012 at 07:36:40AM -0500, Simon Grinberg wrote:
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > To: "Simon Grinberg" <simon at redhat.com>
> > > > > Cc: "arch" <arch at ovirt.org>
> > > > > Sent: Thursday, December 27, 2012 2:14:06 PM
> > > > > Subject: Re: feature suggestion: initial generation of management
> > > > > network
> > > > > 
> > > > > On Tue, Dec 25, 2012 at 09:29:26AM -0500, Simon Grinberg wrote:
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > > > To: "arch" <arch at ovirt.org>
> > > > > > > Sent: Tuesday, December 25, 2012 2:27:22 PM
> > > > > > > Subject: feature suggestion: initial generation of management
> > > > > > > network
> > > > > > > 
> > > > > > > Current condition:
> > > > > > > ==================
> > > > > > > The management network, named ovirtmgmt, is created during host
> > > > > > > bootstrap. It consists of a bridge device, connected to the
> > > > > > > network
> > > > > > > device that was used to communicate with Engine (nic, bonding or
> > > > > > > vlan).
> > > > > > > It inherits its ip settings from the latter device.
> > > > > > > 
> > > > > > > Why Is the Management Network Needed?
> > > > > > > =====================================
> > > > > > > Understandably, some may ask why do we need to have a management
> > > > > > > network - why having a host with IPv4 configured on it is not
> > > > > > > enough.
> > > > > > > The answer is twofold:
> > > > > > > 1. In oVirt, a network is an abstraction of the resources
> > > > > > > required
> > > > > > > for
> > > > > > >    connectivity of a host for a specific usage. This is true for
> > > > > > >    the
> > > > > > >    management network just as it is for VM network or a display
> > > > > > >    network.
> > > > > > >    The network entity is the key for adding/changing nics and IP
> > > > > > >    address.
> > > > > > > 2. In many occasions (such as small setups) the management
> > > > > > > network is
> > > > > > >    used as a VM/display network as well.
> > > > > > > 
> > > > > > > Problems in current connectivity:
> > > > > > > ================================
> > > > > > > According to alonbl of ovirt-host-deploy fame, and with no
> > > > > > > conflict
> > > > > > > to
> > > > > > > my own experience, creating the management network is the most
> > > > > > > fragile,
> > > > > > > error-prone step of bootstrap.
> > > > > > 
> > > > > > +1,
> > > > > > I've raise that repeatedly in the past, bootstrap should not create
> > > > > > the management network but pick up the existing configuration and
> > > > > > let the engine override later with it's own configuration if it
> > > > > > differs , I'm glad that we finally get to that.
> > > > > > 
> > > > > > > 
> > > > > > > Currently it always creates a bridged network (even if the DC
> > > > > > > requires a
> > > > > > > non-bridged ovirtmgmt), it knows nothing about the defined MTU
> > > > > > > for
> > > > > > > ovirtmgmt, it uses ping to guess on top of which device to build
> > > > > > > (and
> > > > > > > thus requires Vdsm-to-Engine reverse connectivity), and is the
> > > > > > > sole
> > > > > > > remaining user of the addNetwork/vdsm-store-net-conf scripts.
> > > > > > > 
> > > > > > > Suggested feature:
> > > > > > > ==================
> > > > > > > Bootstrap would avoid creating a management network. Instead,
> > > > > > > after
> > > > > > > bootstrapping a host, Engine would send a getVdsCaps probe to the
> > > > > > > installed host, receiving a complete picture of the network
> > > > > > > configuration on the host. Among this picture is the device that
> > > > > > > holds
> > > > > > > the host's management IP address.
> > > > > > > 
> > > > > > > Engine would send setupNetwork command to generate ovirtmgmt with
> > > > > > > details devised from this picture, and according to the DC
> > > > > > > definition
> > > > > > > of
> > > > > > > ovirtmgmt.  For example, if Vdsm reports:
> > > > > > > 
> > > > > > > - vlan bond4.3000 has the host's IP, configured to use dhcp.
> > > > > > > - bond4 is comprises eth2 and eth3
> > > > > > > - ovirtmgmt is defined as a VM network with MTU 9000
> > > > > > > 
> > > > > > > then Engine sends the likes of:
> > > > > > >   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
> > > > > > >                 bonding=bond4: {eth2,eth3}, MTU=9000)
> > > > > > 
> > > > > > Just one comment here,
> > > > > > In order to save time and confusion - if the ovirtmgmt is defined
> > > > > > with default values meaning the user did not bother to touch it,
> > > > > > let it pick up the VLAN configuration from the first host added in
> > > > > > the Data Center.
> > > > > > 
> > > > > > Otherwise, you may override the host VLAN and loose connectivity.
> > > > > > 
> > > > > > This will also solve the situation many users encounter today.
> > > > > > 1. The engine in on a host that actually has VLAN defined
> > > > > > 2. The ovirtmgmt network was not updated in the DC
> > > > > > 3. A host, with VLAN already defined is added - everything works
> > > > > > fine
> > > > > > 4. Any number of hosts are now added, again everything seems to
> > > > > > work fine.
> > > > > > 
> > > > > > But, now try to use setupNetworks, and you'll find out that you
> > > > > > can't do much on the interface that contains the ovirtmgmt since
> > > > > > the definition does not match. You can't sync (Since this will
> > > > > > remove the VLAN and cause connectivity lose) you can't add more
> > > > > > networks on top since it already has non-VLAN network on top
> > > > > > according to the DC definition, etc.
> > > > > > 
> > > > > > On the other hand you can't update the ovirtmgmt definition on the
> > > > > > DC since there are clusters in the DC that use the network.
> > > > > > 
> > > > > > The only workaround not involving DB hack to change the VLAN on the
> > > > > > network is to:
> > > > > > 1. Create new DC
> > > > > > 2. Do not use the wizard that pops up to create your cluster.
> > > > > > 3. Modify the ovirtmgmt network to have VLANs
> > > > > > 4. Now create a cluster and add your hosts.
> > > > > > 
> > > > > > If you insist on using the default DC and cluster then before
> > > > > > adding the first host, create an additional DC and move the
> > > > > > Default cluster over there. You may then change the network on the
> > > > > > Default cluster and then move the Default cluster back
> > > > > > 
> > > > > > Both are ugly. And should be solved by the proposal above.
> > > > > > 
> > > > > > We do something similar for the Default cluster CPU level, where we
> > > > > > set the intial level based on the first host added to the cluster.
> > > > > 
> > > > > I'm not sure what Engine has for Default cluster CPU level. But I
> > > > > have
> > > > > reservation of the hysteresis in your proposal - after a host is
> > > > > added,
> > > > > the DC cannot forget ovirtmgmt's vlan.
> > > > > 
> > > > > How about letting the admin edit ovirtmgmt's vlan in the DC level,
> > > > > thus
> > > > > rendering all hosts out-of-sync. The the admin could manually, or
> > > > > through a script, or in the future through a distributed operation,
> > > > > sync
> > > > > all the hosts to the definition?
> > > > 
> > > > Usually if you do that you will loose connectivity to the hosts.
> > > 
> > > Yes, changing the management vlan id (or ip address) is never fun, and
> > > requires out-of-band intervention.
> > > 
> > > > I'm not insisting on the automatic adjustment of the ovirtmgmt network
> > > > to
> > > > match the hosts' (that is just a nice touch) we can take the allow edit
> > > > approach.
> > > > 
> > > > But allow to change VLAN on the ovirtmgmt network will indeed solve the
> > > > issue I'm trying to solve while creating another issue of user
> > > > expecting
> > > > that we'll be able to re-tag the host from the engine side, which is
> > > > challenging to do.
> > > > 
> > > > On the other hand, if we allow to change the VLAN as long as the change
> > > > matches the hosts' configuration, it will both solve the issue while
> > > > not
> > > > eluding the user to think that we really can solve the chicken and egg
> > > > issue of re-tag the entire system.
> > > > 
> > > > Now with the above ability you do get a flow to do the re-tag.
> > > > 1. Place all the hosts in maintenance
> > > > 2. Re-tag the ovirtmgmt on all the hosts
> > > > 3. Re-tag the hosts on which the engine on
> > > > 4. Activate the hosts - this should work well now since connectivity
> > > > exist
> > > > 5. Change the tag on ovirtmgmt on the engine to match the hosts'
> > > > 
> > > > Simple and clear process.
> > > > 
> > > > When the workaround of creating another DC was not possible since the
> > > > system was already long in use and the need was re-tag of the network
> > > > the
> > > > above is what I've recommended in the, except that steps 4-5 where done
> > > > as:
> > > > 4. Stop the engine
> > > > 5. Change the tag in the DB
> > > > 6. Start the engine
> > > > 7. Activate the hosts
> > > 
> > > Sounds reasonable to me - but as far as I am aware this is not tightly
> > > related to the $Subject, which is the post-boot ovirtmgmt definition.
> > > 
> > > I've added a few details to
> > > http://www.ovirt.org/Features/Normalized_ovirtmgmt_Initialization#Engine
> > > and I would apreciate a review from someone with intimate Engine
> > > know-how.
> > > 
> > > Dan.
> > > 
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> 


From masayag at redhat.com  Wed May  8 07:39:17 2013
From: masayag at redhat.com (Moti Asayag)
Date: Wed, 8 May 2013 03:39:17 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <1633347300.8227458.1367926395327.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<1633347300.8227458.1367926395327.JavaMail.root@redhat.com>
Message-ID: <803219126.8564890.1367998757682.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>
> Cc: "arch" <arch at ovirt.org>, "Alon Bar-Lev" <abarlev at redhat.com>
> Sent: Tuesday, May 7, 2013 2:33:15 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> ----- Original Message -----
> > I stumbled upon few issues with the current design while implementing it:
> > 
> > There seems to be a requirement to reboot the host after the installation
> > is completed in order to assure the host is recoverable.
> > 
> > Therefore, the building blocks of the installation process of 3.3 are:
> > 1. host deploy which installs the host expect configuring its management
> > network.
> > 2. SetupNetwork (and CommitNetworkChanges) - for creating the management
> > network
> > on the host and persisting the network configuration.
> > 3. Reboot the host - This is a missing piece. (engine has FenceVds command,
> > but it
> > requires the power management to be configured prior to the installation
> > and
> > might
> > be irrelevant for hosts without PM.)
> > 
> > So, there are couple of issues here:
> > 1. How to reboot the host?
> > 1.1. By exposing new RebootNode verb in VDSM and invoking it from the
> > engine
> 
> This sounds like a solid and good API to me.
> 
> > 1.2. By opening ssh dialog to the host in order to execute the reboot
> 
> How would you do this?
> 

Either by reusing the same ssh dialog used by the VdsDeploy or by opening a new one.
But there is a downside for this solution, as the vdsm is already operational and was
used to configure the network, therefore accessing the host directly and a vdsm-detour
will break the engagement method from engine to vdsm. In addition, rebooting a host
might require resource releasing, therefore it is better to have this logic inside of
the VDSM.

> > 
> > 2. When to perform the reboot?
> > 2.1. After host deploy, by utilizing the host deploy to perform the reboot.
> > It requires to configure the network by the monitor when the host is
> > detected
> > by the engine,
> > detached from the installation flow. However it is a step toward the
> > non-persistent network feature
> > yet to be defined.
> 
> I am not sure this statement has merit, if the feature is yet to be defined,
> how
> can we know if this is a step towards it or not?
> 
> Anyway, I'm not sure that this is a good design - should we setup the network
> when host returns from non-responsive status?

I raised this option as a second alternative. I'm in favour of the second one.

> 
> > 2.2. After setupNetwork is done and network was configured and persisted on
> > the host.
> > There is no special advantage from recoverable aspect, as setupNetwork is
> > constantly
> > used to persist the network configuration (by the complementary
> > CommitNetworkChanges command).
> > In case and network configuration fails, VDSM will revert to the last well
> > known configuration
> > - so connectivity with engine should be restored. Design wise, it fits to
> > configure the management
> >  network as part of the installation sequence.
> > If the network configuration fails in this context, the host status will be
> > set to "InstallFailed" rather than "NonOperational",
> > as might occur as a result of a failed setupNetwork command.
> 
> This sounds like the good solution to me, design wise. The host is installed
> and with that the communication with the management network is configured.
> If this communication is not possible, the host failed to install (also
> meaning
> it's not operational). I see no problem with this approach.
> 
> > 
> > 
> > Your inputs are welcome.
> > 
> > Thanks,
> > Moti
> > ----- Original Message -----
> > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > To: "Simon Grinberg" <simon at redhat.com>, "Moti Asayag"
> > > <masayag at redhat.com>
> > > Cc: "arch" <arch at ovirt.org>
> > > Sent: Tuesday, January 1, 2013 2:47:57 PM
> > > Subject: Re: feature suggestion: initial generation of management network
> > > 
> > > On Thu, Dec 27, 2012 at 07:36:40AM -0500, Simon Grinberg wrote:
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > To: "Simon Grinberg" <simon at redhat.com>
> > > > > Cc: "arch" <arch at ovirt.org>
> > > > > Sent: Thursday, December 27, 2012 2:14:06 PM
> > > > > Subject: Re: feature suggestion: initial generation of management
> > > > > network
> > > > > 
> > > > > On Tue, Dec 25, 2012 at 09:29:26AM -0500, Simon Grinberg wrote:
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > > > To: "arch" <arch at ovirt.org>
> > > > > > > Sent: Tuesday, December 25, 2012 2:27:22 PM
> > > > > > > Subject: feature suggestion: initial generation of management
> > > > > > > network
> > > > > > > 
> > > > > > > Current condition:
> > > > > > > ==================
> > > > > > > The management network, named ovirtmgmt, is created during host
> > > > > > > bootstrap. It consists of a bridge device, connected to the
> > > > > > > network
> > > > > > > device that was used to communicate with Engine (nic, bonding or
> > > > > > > vlan).
> > > > > > > It inherits its ip settings from the latter device.
> > > > > > > 
> > > > > > > Why Is the Management Network Needed?
> > > > > > > =====================================
> > > > > > > Understandably, some may ask why do we need to have a management
> > > > > > > network - why having a host with IPv4 configured on it is not
> > > > > > > enough.
> > > > > > > The answer is twofold:
> > > > > > > 1. In oVirt, a network is an abstraction of the resources
> > > > > > > required
> > > > > > > for
> > > > > > >    connectivity of a host for a specific usage. This is true for
> > > > > > >    the
> > > > > > >    management network just as it is for VM network or a display
> > > > > > >    network.
> > > > > > >    The network entity is the key for adding/changing nics and IP
> > > > > > >    address.
> > > > > > > 2. In many occasions (such as small setups) the management
> > > > > > > network is
> > > > > > >    used as a VM/display network as well.
> > > > > > > 
> > > > > > > Problems in current connectivity:
> > > > > > > ================================
> > > > > > > According to alonbl of ovirt-host-deploy fame, and with no
> > > > > > > conflict
> > > > > > > to
> > > > > > > my own experience, creating the management network is the most
> > > > > > > fragile,
> > > > > > > error-prone step of bootstrap.
> > > > > > 
> > > > > > +1,
> > > > > > I've raise that repeatedly in the past, bootstrap should not create
> > > > > > the management network but pick up the existing configuration and
> > > > > > let the engine override later with it's own configuration if it
> > > > > > differs , I'm glad that we finally get to that.
> > > > > > 
> > > > > > > 
> > > > > > > Currently it always creates a bridged network (even if the DC
> > > > > > > requires a
> > > > > > > non-bridged ovirtmgmt), it knows nothing about the defined MTU
> > > > > > > for
> > > > > > > ovirtmgmt, it uses ping to guess on top of which device to build
> > > > > > > (and
> > > > > > > thus requires Vdsm-to-Engine reverse connectivity), and is the
> > > > > > > sole
> > > > > > > remaining user of the addNetwork/vdsm-store-net-conf scripts.
> > > > > > > 
> > > > > > > Suggested feature:
> > > > > > > ==================
> > > > > > > Bootstrap would avoid creating a management network. Instead,
> > > > > > > after
> > > > > > > bootstrapping a host, Engine would send a getVdsCaps probe to the
> > > > > > > installed host, receiving a complete picture of the network
> > > > > > > configuration on the host. Among this picture is the device that
> > > > > > > holds
> > > > > > > the host's management IP address.
> > > > > > > 
> > > > > > > Engine would send setupNetwork command to generate ovirtmgmt with
> > > > > > > details devised from this picture, and according to the DC
> > > > > > > definition
> > > > > > > of
> > > > > > > ovirtmgmt.  For example, if Vdsm reports:
> > > > > > > 
> > > > > > > - vlan bond4.3000 has the host's IP, configured to use dhcp.
> > > > > > > - bond4 is comprises eth2 and eth3
> > > > > > > - ovirtmgmt is defined as a VM network with MTU 9000
> > > > > > > 
> > > > > > > then Engine sends the likes of:
> > > > > > >   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
> > > > > > >                 bonding=bond4: {eth2,eth3}, MTU=9000)
> > > > > > 
> > > > > > Just one comment here,
> > > > > > In order to save time and confusion - if the ovirtmgmt is defined
> > > > > > with default values meaning the user did not bother to touch it,
> > > > > > let it pick up the VLAN configuration from the first host added in
> > > > > > the Data Center.
> > > > > > 
> > > > > > Otherwise, you may override the host VLAN and loose connectivity.
> > > > > > 
> > > > > > This will also solve the situation many users encounter today.
> > > > > > 1. The engine in on a host that actually has VLAN defined
> > > > > > 2. The ovirtmgmt network was not updated in the DC
> > > > > > 3. A host, with VLAN already defined is added - everything works
> > > > > > fine
> > > > > > 4. Any number of hosts are now added, again everything seems to
> > > > > > work fine.
> > > > > > 
> > > > > > But, now try to use setupNetworks, and you'll find out that you
> > > > > > can't do much on the interface that contains the ovirtmgmt since
> > > > > > the definition does not match. You can't sync (Since this will
> > > > > > remove the VLAN and cause connectivity lose) you can't add more
> > > > > > networks on top since it already has non-VLAN network on top
> > > > > > according to the DC definition, etc.
> > > > > > 
> > > > > > On the other hand you can't update the ovirtmgmt definition on the
> > > > > > DC since there are clusters in the DC that use the network.
> > > > > > 
> > > > > > The only workaround not involving DB hack to change the VLAN on the
> > > > > > network is to:
> > > > > > 1. Create new DC
> > > > > > 2. Do not use the wizard that pops up to create your cluster.
> > > > > > 3. Modify the ovirtmgmt network to have VLANs
> > > > > > 4. Now create a cluster and add your hosts.
> > > > > > 
> > > > > > If you insist on using the default DC and cluster then before
> > > > > > adding the first host, create an additional DC and move the
> > > > > > Default cluster over there. You may then change the network on the
> > > > > > Default cluster and then move the Default cluster back
> > > > > > 
> > > > > > Both are ugly. And should be solved by the proposal above.
> > > > > > 
> > > > > > We do something similar for the Default cluster CPU level, where we
> > > > > > set the intial level based on the first host added to the cluster.
> > > > > 
> > > > > I'm not sure what Engine has for Default cluster CPU level. But I
> > > > > have
> > > > > reservation of the hysteresis in your proposal - after a host is
> > > > > added,
> > > > > the DC cannot forget ovirtmgmt's vlan.
> > > > > 
> > > > > How about letting the admin edit ovirtmgmt's vlan in the DC level,
> > > > > thus
> > > > > rendering all hosts out-of-sync. The the admin could manually, or
> > > > > through a script, or in the future through a distributed operation,
> > > > > sync
> > > > > all the hosts to the definition?
> > > > 
> > > > Usually if you do that you will loose connectivity to the hosts.
> > > 
> > > Yes, changing the management vlan id (or ip address) is never fun, and
> > > requires out-of-band intervention.
> > > 
> > > > I'm not insisting on the automatic adjustment of the ovirtmgmt network
> > > > to
> > > > match the hosts' (that is just a nice touch) we can take the allow edit
> > > > approach.
> > > > 
> > > > But allow to change VLAN on the ovirtmgmt network will indeed solve the
> > > > issue I'm trying to solve while creating another issue of user
> > > > expecting
> > > > that we'll be able to re-tag the host from the engine side, which is
> > > > challenging to do.
> > > > 
> > > > On the other hand, if we allow to change the VLAN as long as the change
> > > > matches the hosts' configuration, it will both solve the issue while
> > > > not
> > > > eluding the user to think that we really can solve the chicken and egg
> > > > issue of re-tag the entire system.
> > > > 
> > > > Now with the above ability you do get a flow to do the re-tag.
> > > > 1. Place all the hosts in maintenance
> > > > 2. Re-tag the ovirtmgmt on all the hosts
> > > > 3. Re-tag the hosts on which the engine on
> > > > 4. Activate the hosts - this should work well now since connectivity
> > > > exist
> > > > 5. Change the tag on ovirtmgmt on the engine to match the hosts'
> > > > 
> > > > Simple and clear process.
> > > > 
> > > > When the workaround of creating another DC was not possible since the
> > > > system was already long in use and the need was re-tag of the network
> > > > the
> > > > above is what I've recommended in the, except that steps 4-5 where done
> > > > as:
> > > > 4. Stop the engine
> > > > 5. Change the tag in the DB
> > > > 6. Start the engine
> > > > 7. Activate the hosts
> > > 
> > > Sounds reasonable to me - but as far as I am aware this is not tightly
> > > related to the $Subject, which is the post-boot ovirtmgmt definition.
> > > 
> > > I've added a few details to
> > > http://www.ovirt.org/Features/Normalized_ovirtmgmt_Initialization#Engine
> > > and I would apreciate a review from someone with intimate Engine
> > > know-how.
> > > 
> > > Dan.
> > > 
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> 


From danken at redhat.com  Wed May  8 13:35:49 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Wed, 8 May 2013 16:35:49 +0300
Subject: feature suggestion: initial generation of management network
In-Reply-To: <1596048609.8203468.1367933507824.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<497587874.11990711.1367932265918.JavaMail.root@redhat.com>
	<1596048609.8203468.1367933507824.JavaMail.root@redhat.com>
Message-ID: <20130508133549.GA17279@redhat.com>

On Tue, May 07, 2013 at 09:31:47AM -0400, Moti Asayag wrote:
> 
> 
> ----- Original Message -----
> > From: "Omer Frenkel" <ofrenkel at redhat.com>
> > To: "Moti Asayag" <masayag at redhat.com>
> > Cc: "arch" <arch at ovirt.org>, "Alon Bar-Lev" <abarlev at redhat.com>
> > Sent: Tuesday, May 7, 2013 4:11:05 PM
> > Subject: Re: feature suggestion: initial generation of management network
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Moti Asayag" <masayag at redhat.com>
> > > To: "arch" <arch at ovirt.org>
> > > Cc: "Alon Bar-Lev" <abarlev at redhat.com>
> > > Sent: Tuesday, May 7, 2013 2:22:19 PM
> > > Subject: Re: feature suggestion: initial generation of management network
> > > 
> > > I stumbled upon few issues with the current design while implementing it:
> > > 
> > > There seems to be a requirement to reboot the host after the installation
> > > is completed in order to assure the host is recoverable.
> > > 
> > > Therefore, the building blocks of the installation process of 3.3 are:
> > > 1. host deploy which installs the host expect configuring its management
> > > network.
> > > 2. SetupNetwork (and CommitNetworkChanges) - for creating the management
> > > network
> > > on the host and persisting the network configuration.
> > > 3. Reboot the host - This is a missing piece. (engine has FenceVds command,
> > > but it
> > > requires the power management to be configured prior to the installation
> > > and
> > > might
> > > be irrelevant for hosts without PM.)
> > > 
> > > So, there are couple of issues here:
> > > 1. How to reboot the host?
> > > 1.1. By exposing new RebootNode verb in VDSM and invoking it from the
> > > engine
> > > 1.2. By opening ssh dialog to the host in order to execute the reboot
> > > 
> > 
> > why not send a reboot flag to the CommitNetworkChanges which is sent anyway,
> > one less call (or connection if you choose ssh) and easier to do.
> > 
> 
> Adding a reboot parameter to the CommitNetworkChanges (setSafeNetworkConfig on vdsm side) 
> exceeds its logical scope which is persisting the network changes.
> 
> Needless to say if such functionally will be required elsewhere, it couldn't be
> properly reused if implemented as part of that command.
> 
> Adding Dan to comment on this as well.

Yeah, a "reboot-after-me" flag defies my sense of cleanliness.
If reboot-after-initial-net-config is crucial, we would need to add a
special verb for that (or use the fenceNode verb if available).


However, I am not sure that this reboot is unavoidable.
Originally the reboot had two important goal:
- make sure that the updated kernel is running
- make sure that the network, which we tweak during bootstrap, is
  accessible after boot

Nowadays, the kernels does not change THAT often, for all ovirt can
matter. running an oldish kernel is not the end of the world.

And with Moti's feature implemented, we no longer tweak net config
blindly during boot. We use a well-define setupNetwork API, with a
well-tested rollback mechanism.

The bottom line is, that in my opinion, reboot-after-install can be
skipped these days.

> 
> > > 2. When to perform the reboot?
> > > 2.1. After host deploy, by utilizing the host deploy to perform the reboot.
> > > It requires to configure the network by the monitor when the host is
> > > detected
> > > by the engine,
> > > detached from the installation flow. However it is a step toward the
> > > non-persistent network feature
> > > yet to be defined.
> > > 2.2. After setupNetwork is done and network was configured and persisted on
> > > the host.
> > > There is no special advantage from recoverable aspect, as setupNetwork is
> > > constantly
> > > used to persist the network configuration (by the complementary
> > > CommitNetworkChanges command).
> > > In case and network configuration fails, VDSM will revert to the last well
> > > known configuration
> > > - so connectivity with engine should be restored. Design wise, it fits to
> > > configure the management
> > >  network as part of the installation sequence.
> > > If the network configuration fails in this context, the host status will be
> > > set to "InstallFailed" rather than "NonOperational",
> > > as might occur as a result of a failed setupNetwork command.
> > > 
> > > 
> > > Your inputs are welcome.
> > > 
> > > Thanks,
> > > Moti


From mburns at redhat.com  Wed May  8 15:26:00 2013
From: mburns at redhat.com (Mike Burns)
Date: Wed, 08 May 2013 11:26:00 -0400
Subject: Updates-Testing repo
In-Reply-To: <518A3CB4.8010501@redhat.com>
References: <518A3CB4.8010501@redhat.com>
Message-ID: <518A6E88.6020106@redhat.com>

oVirt Engine RPMS for the 3.2.2 update are uploaded to this repo.

Thanks

Mike

On 05/08/2013 07:53 AM, Mike Burns wrote:
> A new repo is now available on resources.ovirt.org.  It contains
> packages that are targeted to be shipped as updates to the current
> stable oVirt release.
>
> This repo is located at:
>
> http://resources.ovirt.org/releases/updates-testing/
>
> New ovirt-release packages are also available that contain the repo
> (disabled by default).
>
> http://resources.ovirt.org/releases/ovirt-release-fedora-6-1.noarch.rpm
> http://resources.ovirt.org/releases/ovirt-release-el6-6-1.noarch.rpm
>
> Let me know if there are any questions.
>
> Thanks
>
> Mike
> _______________________________________________
> Announce mailing list
> Announce at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/announce



From lpeer at redhat.com  Thu May  9 05:42:28 2013
From: lpeer at redhat.com (Livnat Peer)
Date: Thu, 09 May 2013 08:42:28 +0300
Subject: feature suggestion: initial generation of management network
In-Reply-To: <20130508133549.GA17279@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<497587874.11990711.1367932265918.JavaMail.root@redhat.com>
	<1596048609.8203468.1367933507824.JavaMail.root@redhat.com>
	<20130508133549.GA17279@redhat.com>
Message-ID: <518B3744.8020209@redhat.com>

On 05/08/2013 04:35 PM, Dan Kenigsberg wrote:
> On Tue, May 07, 2013 at 09:31:47AM -0400, Moti Asayag wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Omer Frenkel" <ofrenkel at redhat.com>
>>> To: "Moti Asayag" <masayag at redhat.com>
>>> Cc: "arch" <arch at ovirt.org>, "Alon Bar-Lev" <abarlev at redhat.com>
>>> Sent: Tuesday, May 7, 2013 4:11:05 PM
>>> Subject: Re: feature suggestion: initial generation of management network
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Moti Asayag" <masayag at redhat.com>
>>>> To: "arch" <arch at ovirt.org>
>>>> Cc: "Alon Bar-Lev" <abarlev at redhat.com>
>>>> Sent: Tuesday, May 7, 2013 2:22:19 PM
>>>> Subject: Re: feature suggestion: initial generation of management network
>>>>
>>>> I stumbled upon few issues with the current design while implementing it:
>>>>
>>>> There seems to be a requirement to reboot the host after the installation
>>>> is completed in order to assure the host is recoverable.
>>>>
>>>> Therefore, the building blocks of the installation process of 3.3 are:
>>>> 1. host deploy which installs the host expect configuring its management
>>>> network.
>>>> 2. SetupNetwork (and CommitNetworkChanges) - for creating the management
>>>> network
>>>> on the host and persisting the network configuration.
>>>> 3. Reboot the host - This is a missing piece. (engine has FenceVds command,
>>>> but it
>>>> requires the power management to be configured prior to the installation
>>>> and
>>>> might
>>>> be irrelevant for hosts without PM.)
>>>>
>>>> So, there are couple of issues here:
>>>> 1. How to reboot the host?
>>>> 1.1. By exposing new RebootNode verb in VDSM and invoking it from the
>>>> engine
>>>> 1.2. By opening ssh dialog to the host in order to execute the reboot
>>>>
>>>
>>> why not send a reboot flag to the CommitNetworkChanges which is sent anyway,
>>> one less call (or connection if you choose ssh) and easier to do.
>>>
>>
>> Adding a reboot parameter to the CommitNetworkChanges (setSafeNetworkConfig on vdsm side) 
>> exceeds its logical scope which is persisting the network changes.
>>
>> Needless to say if such functionally will be required elsewhere, it couldn't be
>> properly reused if implemented as part of that command.
>>
>> Adding Dan to comment on this as well.
> 
> Yeah, a "reboot-after-me" flag defies my sense of cleanliness.
> If reboot-after-initial-net-config is crucial, we would need to add a
> special verb for that (or use the fenceNode verb if available).
> 

+1

> 
> However, I am not sure that this reboot is unavoidable.
> Originally the reboot had two important goal:
> - make sure that the updated kernel is running
> - make sure that the network, which we tweak during bootstrap, is
>   accessible after boot
> 
> Nowadays, the kernels does not change THAT often, for all ovirt can
> matter. running an oldish kernel is not the end of the world.
> 
> And with Moti's feature implemented, we no longer tweak net config
> blindly during boot. We use a well-define setupNetwork API, with a
> well-tested rollback mechanism.
> 
> The bottom line is, that in my opinion, reboot-after-install can be
> skipped these days.
> 

Adding Barak to the thread as I think he had some concern about removing
the reboot after install.


>>
>>>> 2. When to perform the reboot?
>>>> 2.1. After host deploy, by utilizing the host deploy to perform the reboot.
>>>> It requires to configure the network by the monitor when the host is
>>>> detected
>>>> by the engine,
>>>> detached from the installation flow. However it is a step toward the
>>>> non-persistent network feature
>>>> yet to be defined.
>>>> 2.2. After setupNetwork is done and network was configured and persisted on
>>>> the host.
>>>> There is no special advantage from recoverable aspect, as setupNetwork is
>>>> constantly
>>>> used to persist the network configuration (by the complementary
>>>> CommitNetworkChanges command).
>>>> In case and network configuration fails, VDSM will revert to the last well
>>>> known configuration
>>>> - so connectivity with engine should be restored. Design wise, it fits to
>>>> configure the management
>>>>  network as part of the installation sequence.
>>>> If the network configuration fails in this context, the host status will be
>>>> set to "InstallFailed" rather than "NonOperational",
>>>> as might occur as a result of a failed setupNetwork command.
>>>>
>>>>
>>>> Your inputs are welcome.
>>>>
>>>> Thanks,
>>>> Moti
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 



From alonbl at redhat.com  Thu May  9 14:42:09 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 9 May 2013 10:42:09 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <1633347300.8227458.1367926395327.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<1633347300.8227458.1367926395327.JavaMail.root@redhat.com>
Message-ID: <868990068.5761536.1368110529578.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>
> Cc: "Alon Bar-Lev" <abarlev at redhat.com>, "arch" <arch at ovirt.org>
> Sent: Tuesday, May 7, 2013 2:33:15 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> ----- Original Message -----
> > I stumbled upon few issues with the current design while implementing it:
> > 
> > There seems to be a requirement to reboot the host after the installation
> > is completed in order to assure the host is recoverable.
> > 
> > Therefore, the building blocks of the installation process of 3.3 are:
> > 1. host deploy which installs the host expect configuring its management
> > network.
> > 2. SetupNetwork (and CommitNetworkChanges) - for creating the management
> > network
> > on the host and persisting the network configuration.
> > 3. Reboot the host - This is a missing piece. (engine has FenceVds command,
> > but it
> > requires the power management to be configured prior to the installation
> > and
> > might
> > be irrelevant for hosts without PM.)
> > 
> > So, there are couple of issues here:
> > 1. How to reboot the host?
> > 1.1. By exposing new RebootNode verb in VDSM and invoking it from the
> > engine
> 
> This sounds like a solid and good API to me.
> 
> > 1.2. By opening ssh dialog to the host in order to execute the reboot
> 
> How would you do this?
> 
> > 
> > 2. When to perform the reboot?
> > 2.1. After host deploy, by utilizing the host deploy to perform the reboot.
> > It requires to configure the network by the monitor when the host is
> > detected
> > by the engine,
> > detached from the installation flow. However it is a step toward the
> > non-persistent network feature
> > yet to be defined.
> 
> I am not sure this statement has merit, if the feature is yet to be defined,
> how
> can we know if this is a step towards it or not?
> 
> Anyway, I'm not sure that this is a good design - should we setup the network
> when host returns from non-responsive status?

Exactly.
Imagine that after a reboot only single interface is configured to allow communication to engine.
Once the engine connects to the host, it re-configure anything it needs on that host.
A completely stateless host.
 
> > 2.2. After setupNetwork is done and network was configured and persisted on
> > the host.
> > There is no special advantage from recoverable aspect, as setupNetwork is
> > constantly
> > used to persist the network configuration (by the complementary
> > CommitNetworkChanges command).
> > In case and network configuration fails, VDSM will revert to the last well
> > known configuration
> > - so connectivity with engine should be restored. Design wise, it fits to
> > configure the management
> >  network as part of the installation sequence.
> > If the network configuration fails in this context, the host status will be
> > set to "InstallFailed" rather than "NonOperational",
> > as might occur as a result of a failed setupNetwork command.
> 
> This sounds like the good solution to me, design wise. The host is installed
> and with that the communication with the management network is configured.
> If this communication is not possible, the host failed to install (also
> meaning
> it's not operational). I see no problem with this approach.
> 
> > 
> > 
> > Your inputs are welcome.
> > 
> > Thanks,
> > Moti
> > ----- Original Message -----
> > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > To: "Simon Grinberg" <simon at redhat.com>, "Moti Asayag"
> > > <masayag at redhat.com>
> > > Cc: "arch" <arch at ovirt.org>
> > > Sent: Tuesday, January 1, 2013 2:47:57 PM
> > > Subject: Re: feature suggestion: initial generation of management network
> > > 
> > > On Thu, Dec 27, 2012 at 07:36:40AM -0500, Simon Grinberg wrote:
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > To: "Simon Grinberg" <simon at redhat.com>
> > > > > Cc: "arch" <arch at ovirt.org>
> > > > > Sent: Thursday, December 27, 2012 2:14:06 PM
> > > > > Subject: Re: feature suggestion: initial generation of management
> > > > > network
> > > > > 
> > > > > On Tue, Dec 25, 2012 at 09:29:26AM -0500, Simon Grinberg wrote:
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > > > To: "arch" <arch at ovirt.org>
> > > > > > > Sent: Tuesday, December 25, 2012 2:27:22 PM
> > > > > > > Subject: feature suggestion: initial generation of management
> > > > > > > network
> > > > > > > 
> > > > > > > Current condition:
> > > > > > > ==================
> > > > > > > The management network, named ovirtmgmt, is created during host
> > > > > > > bootstrap. It consists of a bridge device, connected to the
> > > > > > > network
> > > > > > > device that was used to communicate with Engine (nic, bonding or
> > > > > > > vlan).
> > > > > > > It inherits its ip settings from the latter device.
> > > > > > > 
> > > > > > > Why Is the Management Network Needed?
> > > > > > > =====================================
> > > > > > > Understandably, some may ask why do we need to have a management
> > > > > > > network - why having a host with IPv4 configured on it is not
> > > > > > > enough.
> > > > > > > The answer is twofold:
> > > > > > > 1. In oVirt, a network is an abstraction of the resources
> > > > > > > required
> > > > > > > for
> > > > > > >    connectivity of a host for a specific usage. This is true for
> > > > > > >    the
> > > > > > >    management network just as it is for VM network or a display
> > > > > > >    network.
> > > > > > >    The network entity is the key for adding/changing nics and IP
> > > > > > >    address.
> > > > > > > 2. In many occasions (such as small setups) the management
> > > > > > > network is
> > > > > > >    used as a VM/display network as well.
> > > > > > > 
> > > > > > > Problems in current connectivity:
> > > > > > > ================================
> > > > > > > According to alonbl of ovirt-host-deploy fame, and with no
> > > > > > > conflict
> > > > > > > to
> > > > > > > my own experience, creating the management network is the most
> > > > > > > fragile,
> > > > > > > error-prone step of bootstrap.
> > > > > > 
> > > > > > +1,
> > > > > > I've raise that repeatedly in the past, bootstrap should not create
> > > > > > the management network but pick up the existing configuration and
> > > > > > let the engine override later with it's own configuration if it
> > > > > > differs , I'm glad that we finally get to that.
> > > > > > 
> > > > > > > 
> > > > > > > Currently it always creates a bridged network (even if the DC
> > > > > > > requires a
> > > > > > > non-bridged ovirtmgmt), it knows nothing about the defined MTU
> > > > > > > for
> > > > > > > ovirtmgmt, it uses ping to guess on top of which device to build
> > > > > > > (and
> > > > > > > thus requires Vdsm-to-Engine reverse connectivity), and is the
> > > > > > > sole
> > > > > > > remaining user of the addNetwork/vdsm-store-net-conf scripts.
> > > > > > > 
> > > > > > > Suggested feature:
> > > > > > > ==================
> > > > > > > Bootstrap would avoid creating a management network. Instead,
> > > > > > > after
> > > > > > > bootstrapping a host, Engine would send a getVdsCaps probe to the
> > > > > > > installed host, receiving a complete picture of the network
> > > > > > > configuration on the host. Among this picture is the device that
> > > > > > > holds
> > > > > > > the host's management IP address.
> > > > > > > 
> > > > > > > Engine would send setupNetwork command to generate ovirtmgmt with
> > > > > > > details devised from this picture, and according to the DC
> > > > > > > definition
> > > > > > > of
> > > > > > > ovirtmgmt.  For example, if Vdsm reports:
> > > > > > > 
> > > > > > > - vlan bond4.3000 has the host's IP, configured to use dhcp.
> > > > > > > - bond4 is comprises eth2 and eth3
> > > > > > > - ovirtmgmt is defined as a VM network with MTU 9000
> > > > > > > 
> > > > > > > then Engine sends the likes of:
> > > > > > >   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
> > > > > > >                 bonding=bond4: {eth2,eth3}, MTU=9000)
> > > > > > 
> > > > > > Just one comment here,
> > > > > > In order to save time and confusion - if the ovirtmgmt is defined
> > > > > > with default values meaning the user did not bother to touch it,
> > > > > > let it pick up the VLAN configuration from the first host added in
> > > > > > the Data Center.
> > > > > > 
> > > > > > Otherwise, you may override the host VLAN and loose connectivity.
> > > > > > 
> > > > > > This will also solve the situation many users encounter today.
> > > > > > 1. The engine in on a host that actually has VLAN defined
> > > > > > 2. The ovirtmgmt network was not updated in the DC
> > > > > > 3. A host, with VLAN already defined is added - everything works
> > > > > > fine
> > > > > > 4. Any number of hosts are now added, again everything seems to
> > > > > > work fine.
> > > > > > 
> > > > > > But, now try to use setupNetworks, and you'll find out that you
> > > > > > can't do much on the interface that contains the ovirtmgmt since
> > > > > > the definition does not match. You can't sync (Since this will
> > > > > > remove the VLAN and cause connectivity lose) you can't add more
> > > > > > networks on top since it already has non-VLAN network on top
> > > > > > according to the DC definition, etc.
> > > > > > 
> > > > > > On the other hand you can't update the ovirtmgmt definition on the
> > > > > > DC since there are clusters in the DC that use the network.
> > > > > > 
> > > > > > The only workaround not involving DB hack to change the VLAN on the
> > > > > > network is to:
> > > > > > 1. Create new DC
> > > > > > 2. Do not use the wizard that pops up to create your cluster.
> > > > > > 3. Modify the ovirtmgmt network to have VLANs
> > > > > > 4. Now create a cluster and add your hosts.
> > > > > > 
> > > > > > If you insist on using the default DC and cluster then before
> > > > > > adding the first host, create an additional DC and move the
> > > > > > Default cluster over there. You may then change the network on the
> > > > > > Default cluster and then move the Default cluster back
> > > > > > 
> > > > > > Both are ugly. And should be solved by the proposal above.
> > > > > > 
> > > > > > We do something similar for the Default cluster CPU level, where we
> > > > > > set the intial level based on the first host added to the cluster.
> > > > > 
> > > > > I'm not sure what Engine has for Default cluster CPU level. But I
> > > > > have
> > > > > reservation of the hysteresis in your proposal - after a host is
> > > > > added,
> > > > > the DC cannot forget ovirtmgmt's vlan.
> > > > > 
> > > > > How about letting the admin edit ovirtmgmt's vlan in the DC level,
> > > > > thus
> > > > > rendering all hosts out-of-sync. The the admin could manually, or
> > > > > through a script, or in the future through a distributed operation,
> > > > > sync
> > > > > all the hosts to the definition?
> > > > 
> > > > Usually if you do that you will loose connectivity to the hosts.
> > > 
> > > Yes, changing the management vlan id (or ip address) is never fun, and
> > > requires out-of-band intervention.
> > > 
> > > > I'm not insisting on the automatic adjustment of the ovirtmgmt network
> > > > to
> > > > match the hosts' (that is just a nice touch) we can take the allow edit
> > > > approach.
> > > > 
> > > > But allow to change VLAN on the ovirtmgmt network will indeed solve the
> > > > issue I'm trying to solve while creating another issue of user
> > > > expecting
> > > > that we'll be able to re-tag the host from the engine side, which is
> > > > challenging to do.
> > > > 
> > > > On the other hand, if we allow to change the VLAN as long as the change
> > > > matches the hosts' configuration, it will both solve the issue while
> > > > not
> > > > eluding the user to think that we really can solve the chicken and egg
> > > > issue of re-tag the entire system.
> > > > 
> > > > Now with the above ability you do get a flow to do the re-tag.
> > > > 1. Place all the hosts in maintenance
> > > > 2. Re-tag the ovirtmgmt on all the hosts
> > > > 3. Re-tag the hosts on which the engine on
> > > > 4. Activate the hosts - this should work well now since connectivity
> > > > exist
> > > > 5. Change the tag on ovirtmgmt on the engine to match the hosts'
> > > > 
> > > > Simple and clear process.
> > > > 
> > > > When the workaround of creating another DC was not possible since the
> > > > system was already long in use and the need was re-tag of the network
> > > > the
> > > > above is what I've recommended in the, except that steps 4-5 where done
> > > > as:
> > > > 4. Stop the engine
> > > > 5. Change the tag in the DB
> > > > 6. Start the engine
> > > > 7. Activate the hosts
> > > 
> > > Sounds reasonable to me - but as far as I am aware this is not tightly
> > > related to the $Subject, which is the post-boot ovirtmgmt definition.
> > > 
> > > I've added a few details to
> > > http://www.ovirt.org/Features/Normalized_ovirtmgmt_Initialization#Engine
> > > and I would apreciate a review from someone with intimate Engine
> > > know-how.
> > > 
> > > Dan.
> > > 
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From asegurap at redhat.com  Thu May  9 14:52:38 2013
From: asegurap at redhat.com (Antoni Segura Puimedon)
Date: Thu, 9 May 2013 10:52:38 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <868990068.5761536.1368110529578.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<1633347300.8227458.1367926395327.JavaMail.root@redhat.com>
	<868990068.5761536.1368110529578.JavaMail.root@redhat.com>
Message-ID: <708444892.5769916.1368111158149.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Mike Kolesnik" <mkolesni at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Thursday, May 9, 2013 4:42:09 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> 
> 
> ----- Original Message -----
> > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > To: "Moti Asayag" <masayag at redhat.com>
> > Cc: "Alon Bar-Lev" <abarlev at redhat.com>, "arch" <arch at ovirt.org>
> > Sent: Tuesday, May 7, 2013 2:33:15 PM
> > Subject: Re: feature suggestion: initial generation of management network
> > 
> > ----- Original Message -----
> > > I stumbled upon few issues with the current design while implementing it:
> > > 
> > > There seems to be a requirement to reboot the host after the installation
> > > is completed in order to assure the host is recoverable.
> > > 
> > > Therefore, the building blocks of the installation process of 3.3 are:
> > > 1. host deploy which installs the host expect configuring its management
> > > network.
> > > 2. SetupNetwork (and CommitNetworkChanges) - for creating the management
> > > network
> > > on the host and persisting the network configuration.
> > > 3. Reboot the host - This is a missing piece. (engine has FenceVds
> > > command,
> > > but it
> > > requires the power management to be configured prior to the installation
> > > and
> > > might
> > > be irrelevant for hosts without PM.)
> > > 
> > > So, there are couple of issues here:
> > > 1. How to reboot the host?
> > > 1.1. By exposing new RebootNode verb in VDSM and invoking it from the
> > > engine
> > 
> > This sounds like a solid and good API to me.
> > 
> > > 1.2. By opening ssh dialog to the host in order to execute the reboot
> > 
> > How would you do this?
> > 
> > > 
> > > 2. When to perform the reboot?
> > > 2.1. After host deploy, by utilizing the host deploy to perform the
> > > reboot.
> > > It requires to configure the network by the monitor when the host is
> > > detected
> > > by the engine,
> > > detached from the installation flow. However it is a step toward the
> > > non-persistent network feature
> > > yet to be defined.
> > 
> > I am not sure this statement has merit, if the feature is yet to be
> > defined,
> > how
> > can we know if this is a step towards it or not?
> > 
> > Anyway, I'm not sure that this is a good design - should we setup the
> > network
> > when host returns from non-responsive status?
> 
> Exactly.
> Imagine that after a reboot only single interface is configured to allow
> communication to engine.
> Once the engine connects to the host, it re-configure anything it needs on
> that host.
> A completely stateless host.

Not completely stateless we'd have to keep the configuration for this privileged
interface in case of reboots. Even so, the less state the better, of course.
>  
> > > 2.2. After setupNetwork is done and network was configured and persisted
> > > on
> > > the host.
> > > There is no special advantage from recoverable aspect, as setupNetwork is
> > > constantly
> > > used to persist the network configuration (by the complementary
> > > CommitNetworkChanges command).
> > > In case and network configuration fails, VDSM will revert to the last
> > > well
> > > known configuration
> > > - so connectivity with engine should be restored. Design wise, it fits to
> > > configure the management
> > >  network as part of the installation sequence.
> > > If the network configuration fails in this context, the host status will
> > > be
> > > set to "InstallFailed" rather than "NonOperational",
> > > as might occur as a result of a failed setupNetwork command.
> > 
> > This sounds like the good solution to me, design wise. The host is
> > installed
> > and with that the communication with the management network is configured.
> > If this communication is not possible, the host failed to install (also
> > meaning
> > it's not operational). I see no problem with this approach.
> > 
> > > 
> > > 
> > > Your inputs are welcome.
> > > 
> > > Thanks,
> > > Moti
> > > ----- Original Message -----
> > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > To: "Simon Grinberg" <simon at redhat.com>, "Moti Asayag"
> > > > <masayag at redhat.com>
> > > > Cc: "arch" <arch at ovirt.org>
> > > > Sent: Tuesday, January 1, 2013 2:47:57 PM
> > > > Subject: Re: feature suggestion: initial generation of management
> > > > network
> > > > 
> > > > On Thu, Dec 27, 2012 at 07:36:40AM -0500, Simon Grinberg wrote:
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > > To: "Simon Grinberg" <simon at redhat.com>
> > > > > > Cc: "arch" <arch at ovirt.org>
> > > > > > Sent: Thursday, December 27, 2012 2:14:06 PM
> > > > > > Subject: Re: feature suggestion: initial generation of management
> > > > > > network
> > > > > > 
> > > > > > On Tue, Dec 25, 2012 at 09:29:26AM -0500, Simon Grinberg wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > > > > To: "arch" <arch at ovirt.org>
> > > > > > > > Sent: Tuesday, December 25, 2012 2:27:22 PM
> > > > > > > > Subject: feature suggestion: initial generation of management
> > > > > > > > network
> > > > > > > > 
> > > > > > > > Current condition:
> > > > > > > > ==================
> > > > > > > > The management network, named ovirtmgmt, is created during host
> > > > > > > > bootstrap. It consists of a bridge device, connected to the
> > > > > > > > network
> > > > > > > > device that was used to communicate with Engine (nic, bonding
> > > > > > > > or
> > > > > > > > vlan).
> > > > > > > > It inherits its ip settings from the latter device.
> > > > > > > > 
> > > > > > > > Why Is the Management Network Needed?
> > > > > > > > =====================================
> > > > > > > > Understandably, some may ask why do we need to have a
> > > > > > > > management
> > > > > > > > network - why having a host with IPv4 configured on it is not
> > > > > > > > enough.
> > > > > > > > The answer is twofold:
> > > > > > > > 1. In oVirt, a network is an abstraction of the resources
> > > > > > > > required
> > > > > > > > for
> > > > > > > >    connectivity of a host for a specific usage. This is true
> > > > > > > >    for
> > > > > > > >    the
> > > > > > > >    management network just as it is for VM network or a display
> > > > > > > >    network.
> > > > > > > >    The network entity is the key for adding/changing nics and
> > > > > > > >    IP
> > > > > > > >    address.
> > > > > > > > 2. In many occasions (such as small setups) the management
> > > > > > > > network is
> > > > > > > >    used as a VM/display network as well.
> > > > > > > > 
> > > > > > > > Problems in current connectivity:
> > > > > > > > ================================
> > > > > > > > According to alonbl of ovirt-host-deploy fame, and with no
> > > > > > > > conflict
> > > > > > > > to
> > > > > > > > my own experience, creating the management network is the most
> > > > > > > > fragile,
> > > > > > > > error-prone step of bootstrap.
> > > > > > > 
> > > > > > > +1,
> > > > > > > I've raise that repeatedly in the past, bootstrap should not
> > > > > > > create
> > > > > > > the management network but pick up the existing configuration and
> > > > > > > let the engine override later with it's own configuration if it
> > > > > > > differs , I'm glad that we finally get to that.
> > > > > > > 
> > > > > > > > 
> > > > > > > > Currently it always creates a bridged network (even if the DC
> > > > > > > > requires a
> > > > > > > > non-bridged ovirtmgmt), it knows nothing about the defined MTU
> > > > > > > > for
> > > > > > > > ovirtmgmt, it uses ping to guess on top of which device to
> > > > > > > > build
> > > > > > > > (and
> > > > > > > > thus requires Vdsm-to-Engine reverse connectivity), and is the
> > > > > > > > sole
> > > > > > > > remaining user of the addNetwork/vdsm-store-net-conf scripts.
> > > > > > > > 
> > > > > > > > Suggested feature:
> > > > > > > > ==================
> > > > > > > > Bootstrap would avoid creating a management network. Instead,
> > > > > > > > after
> > > > > > > > bootstrapping a host, Engine would send a getVdsCaps probe to
> > > > > > > > the
> > > > > > > > installed host, receiving a complete picture of the network
> > > > > > > > configuration on the host. Among this picture is the device
> > > > > > > > that
> > > > > > > > holds
> > > > > > > > the host's management IP address.
> > > > > > > > 
> > > > > > > > Engine would send setupNetwork command to generate ovirtmgmt
> > > > > > > > with
> > > > > > > > details devised from this picture, and according to the DC
> > > > > > > > definition
> > > > > > > > of
> > > > > > > > ovirtmgmt.  For example, if Vdsm reports:
> > > > > > > > 
> > > > > > > > - vlan bond4.3000 has the host's IP, configured to use dhcp.
> > > > > > > > - bond4 is comprises eth2 and eth3
> > > > > > > > - ovirtmgmt is defined as a VM network with MTU 9000
> > > > > > > > 
> > > > > > > > then Engine sends the likes of:
> > > > > > > >   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000,
> > > > > > > >   iface=bond4,
> > > > > > > >                 bonding=bond4: {eth2,eth3}, MTU=9000)
> > > > > > > 
> > > > > > > Just one comment here,
> > > > > > > In order to save time and confusion - if the ovirtmgmt is defined
> > > > > > > with default values meaning the user did not bother to touch it,
> > > > > > > let it pick up the VLAN configuration from the first host added
> > > > > > > in
> > > > > > > the Data Center.
> > > > > > > 
> > > > > > > Otherwise, you may override the host VLAN and loose connectivity.
> > > > > > > 
> > > > > > > This will also solve the situation many users encounter today.
> > > > > > > 1. The engine in on a host that actually has VLAN defined
> > > > > > > 2. The ovirtmgmt network was not updated in the DC
> > > > > > > 3. A host, with VLAN already defined is added - everything works
> > > > > > > fine
> > > > > > > 4. Any number of hosts are now added, again everything seems to
> > > > > > > work fine.
> > > > > > > 
> > > > > > > But, now try to use setupNetworks, and you'll find out that you
> > > > > > > can't do much on the interface that contains the ovirtmgmt since
> > > > > > > the definition does not match. You can't sync (Since this will
> > > > > > > remove the VLAN and cause connectivity lose) you can't add more
> > > > > > > networks on top since it already has non-VLAN network on top
> > > > > > > according to the DC definition, etc.
> > > > > > > 
> > > > > > > On the other hand you can't update the ovirtmgmt definition on
> > > > > > > the
> > > > > > > DC since there are clusters in the DC that use the network.
> > > > > > > 
> > > > > > > The only workaround not involving DB hack to change the VLAN on
> > > > > > > the
> > > > > > > network is to:
> > > > > > > 1. Create new DC
> > > > > > > 2. Do not use the wizard that pops up to create your cluster.
> > > > > > > 3. Modify the ovirtmgmt network to have VLANs
> > > > > > > 4. Now create a cluster and add your hosts.
> > > > > > > 
> > > > > > > If you insist on using the default DC and cluster then before
> > > > > > > adding the first host, create an additional DC and move the
> > > > > > > Default cluster over there. You may then change the network on
> > > > > > > the
> > > > > > > Default cluster and then move the Default cluster back
> > > > > > > 
> > > > > > > Both are ugly. And should be solved by the proposal above.
> > > > > > > 
> > > > > > > We do something similar for the Default cluster CPU level, where
> > > > > > > we
> > > > > > > set the intial level based on the first host added to the
> > > > > > > cluster.
> > > > > > 
> > > > > > I'm not sure what Engine has for Default cluster CPU level. But I
> > > > > > have
> > > > > > reservation of the hysteresis in your proposal - after a host is
> > > > > > added,
> > > > > > the DC cannot forget ovirtmgmt's vlan.
> > > > > > 
> > > > > > How about letting the admin edit ovirtmgmt's vlan in the DC level,
> > > > > > thus
> > > > > > rendering all hosts out-of-sync. The the admin could manually, or
> > > > > > through a script, or in the future through a distributed operation,
> > > > > > sync
> > > > > > all the hosts to the definition?
> > > > > 
> > > > > Usually if you do that you will loose connectivity to the hosts.
> > > > 
> > > > Yes, changing the management vlan id (or ip address) is never fun, and
> > > > requires out-of-band intervention.
> > > > 
> > > > > I'm not insisting on the automatic adjustment of the ovirtmgmt
> > > > > network
> > > > > to
> > > > > match the hosts' (that is just a nice touch) we can take the allow
> > > > > edit
> > > > > approach.
> > > > > 
> > > > > But allow to change VLAN on the ovirtmgmt network will indeed solve
> > > > > the
> > > > > issue I'm trying to solve while creating another issue of user
> > > > > expecting
> > > > > that we'll be able to re-tag the host from the engine side, which is
> > > > > challenging to do.
> > > > > 
> > > > > On the other hand, if we allow to change the VLAN as long as the
> > > > > change
> > > > > matches the hosts' configuration, it will both solve the issue while
> > > > > not
> > > > > eluding the user to think that we really can solve the chicken and
> > > > > egg
> > > > > issue of re-tag the entire system.
> > > > > 
> > > > > Now with the above ability you do get a flow to do the re-tag.
> > > > > 1. Place all the hosts in maintenance
> > > > > 2. Re-tag the ovirtmgmt on all the hosts
> > > > > 3. Re-tag the hosts on which the engine on
> > > > > 4. Activate the hosts - this should work well now since connectivity
> > > > > exist
> > > > > 5. Change the tag on ovirtmgmt on the engine to match the hosts'
> > > > > 
> > > > > Simple and clear process.
> > > > > 
> > > > > When the workaround of creating another DC was not possible since the
> > > > > system was already long in use and the need was re-tag of the network
> > > > > the
> > > > > above is what I've recommended in the, except that steps 4-5 where
> > > > > done
> > > > > as:
> > > > > 4. Stop the engine
> > > > > 5. Change the tag in the DB
> > > > > 6. Start the engine
> > > > > 7. Activate the hosts
> > > > 
> > > > Sounds reasonable to me - but as far as I am aware this is not tightly
> > > > related to the $Subject, which is the post-boot ovirtmgmt definition.
> > > > 
> > > > I've added a few details to
> > > > http://www.ovirt.org/Features/Normalized_ovirtmgmt_Initialization#Engine
> > > > and I would apreciate a review from someone with intimate Engine
> > > > know-how.
> > > > 
> > > > Dan.
> > > > 
> > > _______________________________________________
> > > Arch mailing list
> > > Arch at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/arch
> > > 
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From alonbl at redhat.com  Thu May  9 14:55:00 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 9 May 2013 10:55:00 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <20130508133549.GA17279@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<497587874.11990711.1367932265918.JavaMail.root@redhat.com>
	<1596048609.8203468.1367933507824.JavaMail.root@redhat.com>
	<20130508133549.GA17279@redhat.com>
Message-ID: <1556816649.5772576.1368111300185.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Wednesday, May 8, 2013 4:35:49 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> On Tue, May 07, 2013 at 09:31:47AM -0400, Moti Asayag wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Omer Frenkel" <ofrenkel at redhat.com>
> > > To: "Moti Asayag" <masayag at redhat.com>
> > > Cc: "arch" <arch at ovirt.org>, "Alon Bar-Lev" <abarlev at redhat.com>
> > > Sent: Tuesday, May 7, 2013 4:11:05 PM
> > > Subject: Re: feature suggestion: initial generation of management network
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Moti Asayag" <masayag at redhat.com>
> > > > To: "arch" <arch at ovirt.org>
> > > > Cc: "Alon Bar-Lev" <abarlev at redhat.com>
> > > > Sent: Tuesday, May 7, 2013 2:22:19 PM
> > > > Subject: Re: feature suggestion: initial generation of management
> > > > network
> > > > 
> > > > I stumbled upon few issues with the current design while implementing
> > > > it:
> > > > 
> > > > There seems to be a requirement to reboot the host after the
> > > > installation
> > > > is completed in order to assure the host is recoverable.
> > > > 
> > > > Therefore, the building blocks of the installation process of 3.3 are:
> > > > 1. host deploy which installs the host expect configuring its
> > > > management
> > > > network.
> > > > 2. SetupNetwork (and CommitNetworkChanges) - for creating the
> > > > management
> > > > network
> > > > on the host and persisting the network configuration.
> > > > 3. Reboot the host - This is a missing piece. (engine has FenceVds
> > > > command,
> > > > but it
> > > > requires the power management to be configured prior to the
> > > > installation
> > > > and
> > > > might
> > > > be irrelevant for hosts without PM.)
> > > > 
> > > > So, there are couple of issues here:
> > > > 1. How to reboot the host?
> > > > 1.1. By exposing new RebootNode verb in VDSM and invoking it from the
> > > > engine
> > > > 1.2. By opening ssh dialog to the host in order to execute the reboot
> > > > 
> > > 
> > > why not send a reboot flag to the CommitNetworkChanges which is sent
> > > anyway,
> > > one less call (or connection if you choose ssh) and easier to do.
> > > 
> > 
> > Adding a reboot parameter to the CommitNetworkChanges (setSafeNetworkConfig
> > on vdsm side)
> > exceeds its logical scope which is persisting the network changes.
> > 
> > Needless to say if such functionally will be required elsewhere, it
> > couldn't be
> > properly reused if implemented as part of that command.
> > 
> > Adding Dan to comment on this as well.
> 
> Yeah, a "reboot-after-me" flag defies my sense of cleanliness.

Yes.

> If reboot-after-initial-net-config is crucial, we would need to add a
> special verb for that (or use the fenceNode verb if available).
> 
> 
> However, I am not sure that this reboot is unavoidable.
> Originally the reboot had two important goal:
> - make sure that the updated kernel is running
> - make sure that the network, which we tweak during bootstrap, is
>   accessible after boot
> 
> Nowadays, the kernels does not change THAT often, for all ovirt can
> matter. running an oldish kernel is not the end of the world.
> 
> And with Moti's feature implemented, we no longer tweak net config
> blindly during boot. We use a well-define setupNetwork API, with a
> well-tested rollback mechanism.
> 
> The bottom line is, that in my opinion, reboot-after-install can be
> skipped these days.

I agree.

The current design of ovirt-host-deploy fully supports a deployment cycle without requiring a reboot.
We no longer update kernel command-line, nor performing changes without activating them at runtime.
The bridge setup was the one bit that was risky and could not be rolled back cleanly without re-implementation of large chunk of engine logic.

The risk of a deployed system (without bridge) to be unresponsive after reboot is minimum.

1. iptables rules are already active.
2. udev rules are active.
3. vdsm is up.

The major risk is basically if some dependency package was UPDATED during the installation of vdsm, while its service/consumer is already running, then we are running a host with the old software and there is a chance that after reboot with the new software the host will fail.

I think that the decision to reboot host should be delegated to administrator, adding vdsm verb to reboot is usable. This way admin will be able to take a host to maintenance mode and reboot, and we can add checkbox to the add host dialog '[x] reboot', rebooting the host at the end of the sequence. I think the default should be off.

> 
> > 
> > > > 2. When to perform the reboot?
> > > > 2.1. After host deploy, by utilizing the host deploy to perform the
> > > > reboot.
> > > > It requires to configure the network by the monitor when the host is
> > > > detected
> > > > by the engine,
> > > > detached from the installation flow. However it is a step toward the
> > > > non-persistent network feature
> > > > yet to be defined.
> > > > 2.2. After setupNetwork is done and network was configured and
> > > > persisted on
> > > > the host.
> > > > There is no special advantage from recoverable aspect, as setupNetwork
> > > > is
> > > > constantly
> > > > used to persist the network configuration (by the complementary
> > > > CommitNetworkChanges command).
> > > > In case and network configuration fails, VDSM will revert to the last
> > > > well
> > > > known configuration
> > > > - so connectivity with engine should be restored. Design wise, it fits
> > > > to
> > > > configure the management
> > > >  network as part of the installation sequence.
> > > > If the network configuration fails in this context, the host status
> > > > will be
> > > > set to "InstallFailed" rather than "NonOperational",
> > > > as might occur as a result of a failed setupNetwork command.
> > > > 
> > > > 
> > > > Your inputs are welcome.
> > > > 
> > > > Thanks,
> > > > Moti
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From asegurap at redhat.com  Thu May  9 14:57:16 2013
From: asegurap at redhat.com (Antoni Segura Puimedon)
Date: Thu, 9 May 2013 10:57:16 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <1556816649.5772576.1368111300185.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<497587874.11990711.1367932265918.JavaMail.root@redhat.com>
	<1596048609.8203468.1367933507824.JavaMail.root@redhat.com>
	<20130508133549.GA17279@redhat.com>
	<1556816649.5772576.1368111300185.JavaMail.root@redhat.com>
Message-ID: <941280855.5773599.1368111436878.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Thursday, May 9, 2013 4:55:00 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> 
> 
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Moti Asayag" <masayag at redhat.com>
> > Cc: "arch" <arch at ovirt.org>
> > Sent: Wednesday, May 8, 2013 4:35:49 PM
> > Subject: Re: feature suggestion: initial generation of management network
> > 
> > On Tue, May 07, 2013 at 09:31:47AM -0400, Moti Asayag wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Omer Frenkel" <ofrenkel at redhat.com>
> > > > To: "Moti Asayag" <masayag at redhat.com>
> > > > Cc: "arch" <arch at ovirt.org>, "Alon Bar-Lev" <abarlev at redhat.com>
> > > > Sent: Tuesday, May 7, 2013 4:11:05 PM
> > > > Subject: Re: feature suggestion: initial generation of management
> > > > network
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Moti Asayag" <masayag at redhat.com>
> > > > > To: "arch" <arch at ovirt.org>
> > > > > Cc: "Alon Bar-Lev" <abarlev at redhat.com>
> > > > > Sent: Tuesday, May 7, 2013 2:22:19 PM
> > > > > Subject: Re: feature suggestion: initial generation of management
> > > > > network
> > > > > 
> > > > > I stumbled upon few issues with the current design while implementing
> > > > > it:
> > > > > 
> > > > > There seems to be a requirement to reboot the host after the
> > > > > installation
> > > > > is completed in order to assure the host is recoverable.
> > > > > 
> > > > > Therefore, the building blocks of the installation process of 3.3
> > > > > are:
> > > > > 1. host deploy which installs the host expect configuring its
> > > > > management
> > > > > network.
> > > > > 2. SetupNetwork (and CommitNetworkChanges) - for creating the
> > > > > management
> > > > > network
> > > > > on the host and persisting the network configuration.
> > > > > 3. Reboot the host - This is a missing piece. (engine has FenceVds
> > > > > command,
> > > > > but it
> > > > > requires the power management to be configured prior to the
> > > > > installation
> > > > > and
> > > > > might
> > > > > be irrelevant for hosts without PM.)
> > > > > 
> > > > > So, there are couple of issues here:
> > > > > 1. How to reboot the host?
> > > > > 1.1. By exposing new RebootNode verb in VDSM and invoking it from the
> > > > > engine
> > > > > 1.2. By opening ssh dialog to the host in order to execute the reboot
> > > > > 
> > > > 
> > > > why not send a reboot flag to the CommitNetworkChanges which is sent
> > > > anyway,
> > > > one less call (or connection if you choose ssh) and easier to do.
> > > > 
> > > 
> > > Adding a reboot parameter to the CommitNetworkChanges
> > > (setSafeNetworkConfig
> > > on vdsm side)
> > > exceeds its logical scope which is persisting the network changes.
> > > 
> > > Needless to say if such functionally will be required elsewhere, it
> > > couldn't be
> > > properly reused if implemented as part of that command.
> > > 
> > > Adding Dan to comment on this as well.
> > 
> > Yeah, a "reboot-after-me" flag defies my sense of cleanliness.
> 
> Yes.
> 
> > If reboot-after-initial-net-config is crucial, we would need to add a
> > special verb for that (or use the fenceNode verb if available).
> > 
> > 
> > However, I am not sure that this reboot is unavoidable.
> > Originally the reboot had two important goal:
> > - make sure that the updated kernel is running
> > - make sure that the network, which we tweak during bootstrap, is
> >   accessible after boot
> > 
> > Nowadays, the kernels does not change THAT often, for all ovirt can
> > matter. running an oldish kernel is not the end of the world.
> > 
> > And with Moti's feature implemented, we no longer tweak net config
> > blindly during boot. We use a well-define setupNetwork API, with a
> > well-tested rollback mechanism.
> > 
> > The bottom line is, that in my opinion, reboot-after-install can be
> > skipped these days.
> 
> I agree.
> 
> The current design of ovirt-host-deploy fully supports a deployment cycle
> without requiring a reboot.
> We no longer update kernel command-line, nor performing changes without
> activating them at runtime.
> The bridge setup was the one bit that was risky and could not be rolled back
> cleanly without re-implementation of large chunk of engine logic.
> 
> The risk of a deployed system (without bridge) to be unresponsive after
> reboot is minimum.
> 
> 1. iptables rules are already active.
> 2. udev rules are active.
> 3. vdsm is up.
> 
> The major risk is basically if some dependency package was UPDATED during the
> installation of vdsm, while its service/consumer is already running, then we
> are running a host with the old software and there is a chance that after
> reboot with the new software the host will fail.
> 
> I think that the decision to reboot host should be delegated to
> administrator, adding vdsm verb to reboot is usable. This way admin will be
> able to take a host to maintenance mode and reboot, and we can add checkbox
> to the add host dialog '[x] reboot', rebooting the host at the end of the
> sequence. I think the default should be off.

I'm also in agreement with the addition of a reboot verb. It could be a nice
addition regardless of this specific use case.

> 
> > 
> > > 
> > > > > 2. When to perform the reboot?
> > > > > 2.1. After host deploy, by utilizing the host deploy to perform the
> > > > > reboot.
> > > > > It requires to configure the network by the monitor when the host is
> > > > > detected
> > > > > by the engine,
> > > > > detached from the installation flow. However it is a step toward the
> > > > > non-persistent network feature
> > > > > yet to be defined.
> > > > > 2.2. After setupNetwork is done and network was configured and
> > > > > persisted on
> > > > > the host.
> > > > > There is no special advantage from recoverable aspect, as
> > > > > setupNetwork
> > > > > is
> > > > > constantly
> > > > > used to persist the network configuration (by the complementary
> > > > > CommitNetworkChanges command).
> > > > > In case and network configuration fails, VDSM will revert to the last
> > > > > well
> > > > > known configuration
> > > > > - so connectivity with engine should be restored. Design wise, it
> > > > > fits
> > > > > to
> > > > > configure the management
> > > > >  network as part of the installation sequence.
> > > > > If the network configuration fails in this context, the host status
> > > > > will be
> > > > > set to "InstallFailed" rather than "NonOperational",
> > > > > as might occur as a result of a failed setupNetwork command.
> > > > > 
> > > > > 
> > > > > Your inputs are welcome.
> > > > > 
> > > > > Thanks,
> > > > > Moti
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From bazulay at redhat.com  Thu May  9 15:12:38 2013
From: bazulay at redhat.com (Barak Azulay)
Date: Thu, 9 May 2013 11:12:38 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <518B3744.8020209@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<497587874.11990711.1367932265918.JavaMail.root@redhat.com>
	<1596048609.8203468.1367933507824.JavaMail.root@redhat.com>
	<20130508133549.GA17279@redhat.com> <518B3744.8020209@redhat.com>
Message-ID: <1441971488.13645005.1368112358854.JavaMail.root@redhat.com>

After reading the thread, top posting to give my perspective of the what I think would be the best approach:

Some background:
- The reboot at the end of host deployment came after issues in host deployment that were discovered after fencing/reboot (which had nothing to do with the reboot reason).
- Host deployment takes care of of constructing the bridge (when no bonding exist on host).

So Bottom line:
- I think that both handling the network configuration and reboot should be removed from host deployment (I think we all agree on that)
- host deployment should leave the VDSM up and running with everything configured (including the SSL and SSH keys), and listening to all networks.
- About the reboot - I'm not sure we still need reboot (this is a question even without this discussion)
- Anyway about how to reboot:
  - I don't think it should be done through a VDSM command
  - There is an open issue already with enabling a few stages of fencing with no PowerManagement module but based on SSH,
    So a new engine internal command should be introduced like (runSSHCmdOnVds ... and this command can have 2 variants ... one of them is reboot ... (the other is restart VDSM))
  - such command will not require a password as the SSH keys should already be in place

Thoughts/Implications on Host Life cycle:
- The easiest approach will be to leave the host in Installing phase throughout this process (all under installVdsCommand), and eventually move it to reboot 
- If one skips reboot than assuming the cluster has more than one network, he host will imminently move to none-operational ( like today)
- We can take a different approach and add a new status to the Host - PendingNetworkConfig, which could be executed automatically in the future with network-labels, ot today simply popup todo dialog in the UI.


Thanks
Barak Azulay
    
 

----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>, "Barak Azulay" <bazulay at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Thursday, May 9, 2013 8:42:28 AM
> Subject: Re: feature suggestion: initial generation of management network
> 
> On 05/08/2013 04:35 PM, Dan Kenigsberg wrote:
> > On Tue, May 07, 2013 at 09:31:47AM -0400, Moti Asayag wrote:
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Omer Frenkel" <ofrenkel at redhat.com>
> >>> To: "Moti Asayag" <masayag at redhat.com>
> >>> Cc: "arch" <arch at ovirt.org>, "Alon Bar-Lev" <abarlev at redhat.com>
> >>> Sent: Tuesday, May 7, 2013 4:11:05 PM
> >>> Subject: Re: feature suggestion: initial generation of management network
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Moti Asayag" <masayag at redhat.com>
> >>>> To: "arch" <arch at ovirt.org>
> >>>> Cc: "Alon Bar-Lev" <abarlev at redhat.com>
> >>>> Sent: Tuesday, May 7, 2013 2:22:19 PM
> >>>> Subject: Re: feature suggestion: initial generation of management
> >>>> network
> >>>>
> >>>> I stumbled upon few issues with the current design while implementing
> >>>> it:
> >>>>
> >>>> There seems to be a requirement to reboot the host after the
> >>>> installation
> >>>> is completed in order to assure the host is recoverable.
> >>>>
> >>>> Therefore, the building blocks of the installation process of 3.3 are:
> >>>> 1. host deploy which installs the host expect configuring its management
> >>>> network.
> >>>> 2. SetupNetwork (and CommitNetworkChanges) - for creating the management
> >>>> network
> >>>> on the host and persisting the network configuration.
> >>>> 3. Reboot the host - This is a missing piece. (engine has FenceVds
> >>>> command,
> >>>> but it
> >>>> requires the power management to be configured prior to the installation
> >>>> and
> >>>> might
> >>>> be irrelevant for hosts without PM.)
> >>>>
> >>>> So, there are couple of issues here:
> >>>> 1. How to reboot the host?
> >>>> 1.1. By exposing new RebootNode verb in VDSM and invoking it from the
> >>>> engine
> >>>> 1.2. By opening ssh dialog to the host in order to execute the reboot
> >>>>
> >>>
> >>> why not send a reboot flag to the CommitNetworkChanges which is sent
> >>> anyway,
> >>> one less call (or connection if you choose ssh) and easier to do.
> >>>
> >>
> >> Adding a reboot parameter to the CommitNetworkChanges
> >> (setSafeNetworkConfig on vdsm side)
> >> exceeds its logical scope which is persisting the network changes.
> >>
> >> Needless to say if such functionally will be required elsewhere, it
> >> couldn't be
> >> properly reused if implemented as part of that command.
> >>
> >> Adding Dan to comment on this as well.
> > 
> > Yeah, a "reboot-after-me" flag defies my sense of cleanliness.
> > If reboot-after-initial-net-config is crucial, we would need to add a
> > special verb for that (or use the fenceNode verb if available).
> > 
> 
> +1
> 
> > 
> > However, I am not sure that this reboot is unavoidable.
> > Originally the reboot had two important goal:
> > - make sure that the updated kernel is running
> > - make sure that the network, which we tweak during bootstrap, is
> >   accessible after boot
> > 
> > Nowadays, the kernels does not change THAT often, for all ovirt can
> > matter. running an oldish kernel is not the end of the world.
> > 
> > And with Moti's feature implemented, we no longer tweak net config
> > blindly during boot. We use a well-define setupNetwork API, with a
> > well-tested rollback mechanism.
> > 
> > The bottom line is, that in my opinion, reboot-after-install can be
> > skipped these days.
> > 
> 
> Adding Barak to the thread as I think he had some concern about removing
> the reboot after install.
> 
> 
> >>
> >>>> 2. When to perform the reboot?
> >>>> 2.1. After host deploy, by utilizing the host deploy to perform the
> >>>> reboot.
> >>>> It requires to configure the network by the monitor when the host is
> >>>> detected
> >>>> by the engine,
> >>>> detached from the installation flow. However it is a step toward the
> >>>> non-persistent network feature
> >>>> yet to be defined.
> >>>> 2.2. After setupNetwork is done and network was configured and persisted
> >>>> on
> >>>> the host.
> >>>> There is no special advantage from recoverable aspect, as setupNetwork
> >>>> is
> >>>> constantly
> >>>> used to persist the network configuration (by the complementary
> >>>> CommitNetworkChanges command).
> >>>> In case and network configuration fails, VDSM will revert to the last
> >>>> well
> >>>> known configuration
> >>>> - so connectivity with engine should be restored. Design wise, it fits
> >>>> to
> >>>> configure the management
> >>>>  network as part of the installation sequence.
> >>>> If the network configuration fails in this context, the host status will
> >>>> be
> >>>> set to "InstallFailed" rather than "NonOperational",
> >>>> as might occur as a result of a failed setupNetwork command.
> >>>>
> >>>>
> >>>> Your inputs are welcome.
> >>>>
> >>>> Thanks,
> >>>> Moti
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 
> 
> 


From alonbl at redhat.com  Thu May  9 15:36:30 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 9 May 2013 11:36:30 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <1441971488.13645005.1368112358854.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<497587874.11990711.1367932265918.JavaMail.root@redhat.com>
	<1596048609.8203468.1367933507824.JavaMail.root@redhat.com>
	<20130508133549.GA17279@redhat.com> <518B3744.8020209@redhat.com>
	<1441971488.13645005.1368112358854.JavaMail.root@redhat.com>
Message-ID: <2095276319.5812204.1368113790742.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Barak Azulay" <bazulay at redhat.com>
> To: "Livnat Peer" <lpeer at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Thursday, May 9, 2013 6:12:38 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> After reading the thread, top posting to give my perspective of the what I
> think would be the best approach:
> 
> Some background:
> - The reboot at the end of host deployment came after issues in host
> deployment that were discovered after fencing/reboot (which had nothing to
> do with the reboot reason).
> - Host deployment takes care of of constructing the bridge (when no bonding
> exist on host).
> 
> So Bottom line:
> - I think that both handling the network configuration and reboot should be
> removed from host deployment (I think we all agree on that)
> - host deployment should leave the VDSM up and running with everything
> configured (including the SSL and SSH keys), and listening to all networks.
> - About the reboot - I'm not sure we still need reboot (this is a question
> even without this discussion)
> - Anyway about how to reboot:
>   - I don't think it should be done through a VDSM command
>   - There is an open issue already with enabling a few stages of fencing with
>   no PowerManagement module but based on SSH,
>     So a new engine internal command should be introduced like
>     (runSSHCmdOnVds ... and this command can have 2 variants ... one of them
>     is reboot ... (the other is restart VDSM))
>   - such command will not require a password as the SSH keys should already
>   be in place

I disagree.
After management agent (VDSM in our case) is installed, all communications should be done via that agent.
Using multi-protocol layers is not wise in this architecture.
For example, if we switch the direction of engine->vdsm communications we cannot use SSH.

> 
> Thoughts/Implications on Host Life cycle:
> - The easiest approach will be to leave the host in Installing phase
> throughout this process (all under installVdsCommand), and eventually move
> it to reboot
> - If one skips reboot than assuming the cluster has more than one network, he
> host will imminently move to none-operational ( like today)
> - We can take a different approach and add a new status to the Host -
> PendingNetworkConfig, which could be executed automatically in the future
> with network-labels, ot today simply popup todo dialog in the UI.
> 
> 
> Thanks
> Barak Azulay
>     
>  
> 
> ----- Original Message -----
> > From: "Livnat Peer" <lpeer at redhat.com>
> > To: "Dan Kenigsberg" <danken at redhat.com>, "Barak Azulay"
> > <bazulay at redhat.com>
> > Cc: "arch" <arch at ovirt.org>
> > Sent: Thursday, May 9, 2013 8:42:28 AM
> > Subject: Re: feature suggestion: initial generation of management network
> > 
> > On 05/08/2013 04:35 PM, Dan Kenigsberg wrote:
> > > On Tue, May 07, 2013 at 09:31:47AM -0400, Moti Asayag wrote:
> > >>
> > >>
> > >> ----- Original Message -----
> > >>> From: "Omer Frenkel" <ofrenkel at redhat.com>
> > >>> To: "Moti Asayag" <masayag at redhat.com>
> > >>> Cc: "arch" <arch at ovirt.org>, "Alon Bar-Lev" <abarlev at redhat.com>
> > >>> Sent: Tuesday, May 7, 2013 4:11:05 PM
> > >>> Subject: Re: feature suggestion: initial generation of management
> > >>> network
> > >>>
> > >>>
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Moti Asayag" <masayag at redhat.com>
> > >>>> To: "arch" <arch at ovirt.org>
> > >>>> Cc: "Alon Bar-Lev" <abarlev at redhat.com>
> > >>>> Sent: Tuesday, May 7, 2013 2:22:19 PM
> > >>>> Subject: Re: feature suggestion: initial generation of management
> > >>>> network
> > >>>>
> > >>>> I stumbled upon few issues with the current design while implementing
> > >>>> it:
> > >>>>
> > >>>> There seems to be a requirement to reboot the host after the
> > >>>> installation
> > >>>> is completed in order to assure the host is recoverable.
> > >>>>
> > >>>> Therefore, the building blocks of the installation process of 3.3 are:
> > >>>> 1. host deploy which installs the host expect configuring its
> > >>>> management
> > >>>> network.
> > >>>> 2. SetupNetwork (and CommitNetworkChanges) - for creating the
> > >>>> management
> > >>>> network
> > >>>> on the host and persisting the network configuration.
> > >>>> 3. Reboot the host - This is a missing piece. (engine has FenceVds
> > >>>> command,
> > >>>> but it
> > >>>> requires the power management to be configured prior to the
> > >>>> installation
> > >>>> and
> > >>>> might
> > >>>> be irrelevant for hosts without PM.)
> > >>>>
> > >>>> So, there are couple of issues here:
> > >>>> 1. How to reboot the host?
> > >>>> 1.1. By exposing new RebootNode verb in VDSM and invoking it from the
> > >>>> engine
> > >>>> 1.2. By opening ssh dialog to the host in order to execute the reboot
> > >>>>
> > >>>
> > >>> why not send a reboot flag to the CommitNetworkChanges which is sent
> > >>> anyway,
> > >>> one less call (or connection if you choose ssh) and easier to do.
> > >>>
> > >>
> > >> Adding a reboot parameter to the CommitNetworkChanges
> > >> (setSafeNetworkConfig on vdsm side)
> > >> exceeds its logical scope which is persisting the network changes.
> > >>
> > >> Needless to say if such functionally will be required elsewhere, it
> > >> couldn't be
> > >> properly reused if implemented as part of that command.
> > >>
> > >> Adding Dan to comment on this as well.
> > > 
> > > Yeah, a "reboot-after-me" flag defies my sense of cleanliness.
> > > If reboot-after-initial-net-config is crucial, we would need to add a
> > > special verb for that (or use the fenceNode verb if available).
> > > 
> > 
> > +1
> > 
> > > 
> > > However, I am not sure that this reboot is unavoidable.
> > > Originally the reboot had two important goal:
> > > - make sure that the updated kernel is running
> > > - make sure that the network, which we tweak during bootstrap, is
> > >   accessible after boot
> > > 
> > > Nowadays, the kernels does not change THAT often, for all ovirt can
> > > matter. running an oldish kernel is not the end of the world.
> > > 
> > > And with Moti's feature implemented, we no longer tweak net config
> > > blindly during boot. We use a well-define setupNetwork API, with a
> > > well-tested rollback mechanism.
> > > 
> > > The bottom line is, that in my opinion, reboot-after-install can be
> > > skipped these days.
> > > 
> > 
> > Adding Barak to the thread as I think he had some concern about removing
> > the reboot after install.
> > 
> > 
> > >>
> > >>>> 2. When to perform the reboot?
> > >>>> 2.1. After host deploy, by utilizing the host deploy to perform the
> > >>>> reboot.
> > >>>> It requires to configure the network by the monitor when the host is
> > >>>> detected
> > >>>> by the engine,
> > >>>> detached from the installation flow. However it is a step toward the
> > >>>> non-persistent network feature
> > >>>> yet to be defined.
> > >>>> 2.2. After setupNetwork is done and network was configured and
> > >>>> persisted
> > >>>> on
> > >>>> the host.
> > >>>> There is no special advantage from recoverable aspect, as setupNetwork
> > >>>> is
> > >>>> constantly
> > >>>> used to persist the network configuration (by the complementary
> > >>>> CommitNetworkChanges command).
> > >>>> In case and network configuration fails, VDSM will revert to the last
> > >>>> well
> > >>>> known configuration
> > >>>> - so connectivity with engine should be restored. Design wise, it fits
> > >>>> to
> > >>>> configure the management
> > >>>>  network as part of the installation sequence.
> > >>>> If the network configuration fails in this context, the host status
> > >>>> will
> > >>>> be
> > >>>> set to "InstallFailed" rather than "NonOperational",
> > >>>> as might occur as a result of a failed setupNetwork command.
> > >>>>
> > >>>>
> > >>>> Your inputs are welcome.
> > >>>>
> > >>>> Thanks,
> > >>>> Moti
> > > _______________________________________________
> > > Arch mailing list
> > > Arch at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/arch
> > > 
> > 
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> > 
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From dougsland at redhat.com  Thu May  9 19:58:27 2013
From: dougsland at redhat.com (Douglas Schilling Landgraf)
Date: Thu, 09 May 2013 15:58:27 -0400
Subject: feature suggestion: initial generation of management network
In-Reply-To: <1556816649.5772576.1368111300185.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<497587874.11990711.1367932265918.JavaMail.root@redhat.com>
	<1596048609.8203468.1367933507824.JavaMail.root@redhat.com>
	<20130508133549.GA17279@redhat.com>
	<1556816649.5772576.1368111300185.JavaMail.root@redhat.com>
Message-ID: <518BFFE3.8030308@redhat.com>

On 05/09/2013 10:55 AM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Dan Kenigsberg" <danken at redhat.com>
>> To: "Moti Asayag" <masayag at redhat.com>
>> Cc: "arch" <arch at ovirt.org>
>> Sent: Wednesday, May 8, 2013 4:35:49 PM
>> Subject: Re: feature suggestion: initial generation of management network
>>
>> On Tue, May 07, 2013 at 09:31:47AM -0400, Moti Asayag wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Omer Frenkel" <ofrenkel at redhat.com>
>>>> To: "Moti Asayag" <masayag at redhat.com>
>>>> Cc: "arch" <arch at ovirt.org>, "Alon Bar-Lev" <abarlev at redhat.com>
>>>> Sent: Tuesday, May 7, 2013 4:11:05 PM
>>>> Subject: Re: feature suggestion: initial generation of management network
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Moti Asayag" <masayag at redhat.com>
>>>>> To: "arch" <arch at ovirt.org>
>>>>> Cc: "Alon Bar-Lev" <abarlev at redhat.com>
>>>>> Sent: Tuesday, May 7, 2013 2:22:19 PM
>>>>> Subject: Re: feature suggestion: initial generation of management
>>>>> network
>>>>>
>>>>> I stumbled upon few issues with the current design while implementing
>>>>> it:
>>>>>
>>>>> There seems to be a requirement to reboot the host after the
>>>>> installation
>>>>> is completed in order to assure the host is recoverable.
>>>>>
>>>>> Therefore, the building blocks of the installation process of 3.3 are:
>>>>> 1. host deploy which installs the host expect configuring its
>>>>> management
>>>>> network.
>>>>> 2. SetupNetwork (and CommitNetworkChanges) - for creating the
>>>>> management
>>>>> network
>>>>> on the host and persisting the network configuration.
>>>>> 3. Reboot the host - This is a missing piece. (engine has FenceVds
>>>>> command,
>>>>> but it
>>>>> requires the power management to be configured prior to the
>>>>> installation
>>>>> and
>>>>> might
>>>>> be irrelevant for hosts without PM.)
>>>>>
>>>>> So, there are couple of issues here:
>>>>> 1. How to reboot the host?
>>>>> 1.1. By exposing new RebootNode verb in VDSM and invoking it from the
>>>>> engine
>>>>> 1.2. By opening ssh dialog to the host in order to execute the reboot
>>>>>
>>>>
>>>> why not send a reboot flag to the CommitNetworkChanges which is sent
>>>> anyway,
>>>> one less call (or connection if you choose ssh) and easier to do.
>>>>
>>>
>>> Adding a reboot parameter to the CommitNetworkChanges (setSafeNetworkConfig
>>> on vdsm side)
>>> exceeds its logical scope which is persisting the network changes.
>>>
>>> Needless to say if such functionally will be required elsewhere, it
>>> couldn't be
>>> properly reused if implemented as part of that command.
>>>
>>> Adding Dan to comment on this as well.
>>
>> Yeah, a "reboot-after-me" flag defies my sense of cleanliness.
>
> Yes.
>
>> If reboot-after-initial-net-config is crucial, we would need to add a
>> special verb for that (or use the fenceNode verb if available).
>>
>>
>> However, I am not sure that this reboot is unavoidable.
>> Originally the reboot had two important goal:
>> - make sure that the updated kernel is running
>> - make sure that the network, which we tweak during bootstrap, is
>>    accessible after boot
>>
>> Nowadays, the kernels does not change THAT often, for all ovirt can
>> matter. running an oldish kernel is not the end of the world.
>>
>> And with Moti's feature implemented, we no longer tweak net config
>> blindly during boot. We use a well-define setupNetwork API, with a
>> well-tested rollback mechanism.
>>
>> The bottom line is, that in my opinion, reboot-after-install can be
>> skipped these days.
>
> I agree.
>
> The current design of ovirt-host-deploy fully supports a deployment cycle without requiring a reboot.
> We no longer update kernel command-line, nor performing changes without activating them at runtime.
> The bridge setup was the one bit that was risky and could not be rolled back cleanly without re-implementation of large chunk of engine logic.
>
> The risk of a deployed system (without bridge) to be unresponsive after reboot is minimum.
>
> 1. iptables rules are already active.
> 2. udev rules are active.
> 3. vdsm is up.
>
> The major risk is basically if some dependency package was UPDATED during the installation of vdsm, while its service/consumer is already running, then we are running a host with the old software and there is a chance that after reboot with the new software the host will fail.
>
> I think that the decision to reboot host should be delegated to administrator, adding vdsm verb to reboot is usable. This way admin will be able to take a host to maintenance mode and reboot, and we can add checkbox to the add host dialog '[x] reboot', rebooting the host at the end of the sequence. I think the default should be off.
>
+1


-- 
Cheers
Douglas


From bazulay at redhat.com  Thu May  9 19:59:59 2013
From: bazulay at redhat.com (Barak Azulay)
Date: Thu, 9 May 2013 15:59:59 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <2095276319.5812204.1368113790742.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<497587874.11990711.1367932265918.JavaMail.root@redhat.com>
	<1596048609.8203468.1367933507824.JavaMail.root@redhat.com>
	<20130508133549.GA17279@redhat.com> <518B3744.8020209@redhat.com>
	<1441971488.13645005.1368112358854.JavaMail.root@redhat.com>
	<2095276319.5812204.1368113790742.JavaMail.root@redhat.com>
Message-ID: <1367250542.13826069.1368129599726.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Barak Azulay" <bazulay at redhat.com>
> Cc: "Livnat Peer" <lpeer at redhat.com>, "arch" <arch at ovirt.org>
> Sent: Thursday, May 9, 2013 6:36:30 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> 
> 
> ----- Original Message -----
> > From: "Barak Azulay" <bazulay at redhat.com>
> > To: "Livnat Peer" <lpeer at redhat.com>
> > Cc: "arch" <arch at ovirt.org>
> > Sent: Thursday, May 9, 2013 6:12:38 PM
> > Subject: Re: feature suggestion: initial generation of management network
> > 
> > After reading the thread, top posting to give my perspective of the what I
> > think would be the best approach:
> > 
> > Some background:
> > - The reboot at the end of host deployment came after issues in host
> > deployment that were discovered after fencing/reboot (which had nothing to
> > do with the reboot reason).
> > - Host deployment takes care of of constructing the bridge (when no bonding
> > exist on host).
> > 
> > So Bottom line:
> > - I think that both handling the network configuration and reboot should be
> > removed from host deployment (I think we all agree on that)
> > - host deployment should leave the VDSM up and running with everything
> > configured (including the SSL and SSH keys), and listening to all networks.
> > - About the reboot - I'm not sure we still need reboot (this is a question
> > even without this discussion)
> > - Anyway about how to reboot:
> >   - I don't think it should be done through a VDSM command
> >   - There is an open issue already with enabling a few stages of fencing
> >   with
> >   no PowerManagement module but based on SSH,
> >     So a new engine internal command should be introduced like
> >     (runSSHCmdOnVds ... and this command can have 2 variants ... one of
> >     them
> >     is reboot ... (the other is restart VDSM))
> >   - such command will not require a password as the SSH keys should already
> >   be in place
> 
> I disagree.
> After management agent (VDSM in our case) is installed, all communications
> should be done via that agent.

First I must say that the reboot may not be a must  for host deploy, this is a legitimate point to discuss 

However on the other hand a reboot might still be needed for various reasons, If it was that simple we wouldn't have to:
- use Power Management cards
- build safety belts around services we depend on

In addition the fact is that VDSM can turn not responsive due to many unexpected reasons, and we might still need the ability to force a host to reboot (and not through PM).  
On the other hand SSH is very reliable, used anyway by engine for various flows (deploy/upgrade/log collection), and for that reason will be configured anyway. 
 

> Using multi-protocol layers is not wise in this architecture.

We already do, and as it looks like its here to stay - unless we remove the host deployment part from ovirt.

> For example, if we switch the direction of engine->vdsm communications we
> cannot use SSH.

The current plans are to move to a bi directional communication transport on top of AMQP/TCP,
See the work done by Saggi.M

And even if we do - the SSH will still be required.


> 
> > 
> > Thoughts/Implications on Host Life cycle:
> > - The easiest approach will be to leave the host in Installing phase
> > throughout this process (all under installVdsCommand), and eventually move
> > it to reboot
> > - If one skips reboot than assuming the cluster has more than one network,
> > he
> > host will imminently move to none-operational ( like today)
> > - We can take a different approach and add a new status to the Host -
> > PendingNetworkConfig, which could be executed automatically in the future
> > with network-labels, ot today simply popup todo dialog in the UI.
> > 
> > 
> > Thanks
> > Barak Azulay
> >     
> >  
> > 
> > ----- Original Message -----
> > > From: "Livnat Peer" <lpeer at redhat.com>
> > > To: "Dan Kenigsberg" <danken at redhat.com>, "Barak Azulay"
> > > <bazulay at redhat.com>
> > > Cc: "arch" <arch at ovirt.org>
> > > Sent: Thursday, May 9, 2013 8:42:28 AM
> > > Subject: Re: feature suggestion: initial generation of management network
> > > 
> > > On 05/08/2013 04:35 PM, Dan Kenigsberg wrote:
> > > > On Tue, May 07, 2013 at 09:31:47AM -0400, Moti Asayag wrote:
> > > >>
> > > >>
> > > >> ----- Original Message -----
> > > >>> From: "Omer Frenkel" <ofrenkel at redhat.com>
> > > >>> To: "Moti Asayag" <masayag at redhat.com>
> > > >>> Cc: "arch" <arch at ovirt.org>, "Alon Bar-Lev" <abarlev at redhat.com>
> > > >>> Sent: Tuesday, May 7, 2013 4:11:05 PM
> > > >>> Subject: Re: feature suggestion: initial generation of management
> > > >>> network
> > > >>>
> > > >>>
> > > >>>
> > > >>> ----- Original Message -----
> > > >>>> From: "Moti Asayag" <masayag at redhat.com>
> > > >>>> To: "arch" <arch at ovirt.org>
> > > >>>> Cc: "Alon Bar-Lev" <abarlev at redhat.com>
> > > >>>> Sent: Tuesday, May 7, 2013 2:22:19 PM
> > > >>>> Subject: Re: feature suggestion: initial generation of management
> > > >>>> network
> > > >>>>
> > > >>>> I stumbled upon few issues with the current design while
> > > >>>> implementing
> > > >>>> it:
> > > >>>>
> > > >>>> There seems to be a requirement to reboot the host after the
> > > >>>> installation
> > > >>>> is completed in order to assure the host is recoverable.
> > > >>>>
> > > >>>> Therefore, the building blocks of the installation process of 3.3
> > > >>>> are:
> > > >>>> 1. host deploy which installs the host expect configuring its
> > > >>>> management
> > > >>>> network.
> > > >>>> 2. SetupNetwork (and CommitNetworkChanges) - for creating the
> > > >>>> management
> > > >>>> network
> > > >>>> on the host and persisting the network configuration.
> > > >>>> 3. Reboot the host - This is a missing piece. (engine has FenceVds
> > > >>>> command,
> > > >>>> but it
> > > >>>> requires the power management to be configured prior to the
> > > >>>> installation
> > > >>>> and
> > > >>>> might
> > > >>>> be irrelevant for hosts without PM.)
> > > >>>>
> > > >>>> So, there are couple of issues here:
> > > >>>> 1. How to reboot the host?
> > > >>>> 1.1. By exposing new RebootNode verb in VDSM and invoking it from
> > > >>>> the
> > > >>>> engine
> > > >>>> 1.2. By opening ssh dialog to the host in order to execute the
> > > >>>> reboot
> > > >>>>
> > > >>>
> > > >>> why not send a reboot flag to the CommitNetworkChanges which is sent
> > > >>> anyway,
> > > >>> one less call (or connection if you choose ssh) and easier to do.
> > > >>>
> > > >>
> > > >> Adding a reboot parameter to the CommitNetworkChanges
> > > >> (setSafeNetworkConfig on vdsm side)
> > > >> exceeds its logical scope which is persisting the network changes.
> > > >>
> > > >> Needless to say if such functionally will be required elsewhere, it
> > > >> couldn't be
> > > >> properly reused if implemented as part of that command.
> > > >>
> > > >> Adding Dan to comment on this as well.
> > > > 
> > > > Yeah, a "reboot-after-me" flag defies my sense of cleanliness.
> > > > If reboot-after-initial-net-config is crucial, we would need to add a
> > > > special verb for that (or use the fenceNode verb if available).
> > > > 
> > > 
> > > +1
> > > 
> > > > 
> > > > However, I am not sure that this reboot is unavoidable.
> > > > Originally the reboot had two important goal:
> > > > - make sure that the updated kernel is running
> > > > - make sure that the network, which we tweak during bootstrap, is
> > > >   accessible after boot
> > > > 
> > > > Nowadays, the kernels does not change THAT often, for all ovirt can
> > > > matter. running an oldish kernel is not the end of the world.
> > > > 
> > > > And with Moti's feature implemented, we no longer tweak net config
> > > > blindly during boot. We use a well-define setupNetwork API, with a
> > > > well-tested rollback mechanism.
> > > > 
> > > > The bottom line is, that in my opinion, reboot-after-install can be
> > > > skipped these days.
> > > > 
> > > 
> > > Adding Barak to the thread as I think he had some concern about removing
> > > the reboot after install.
> > > 
> > > 
> > > >>
> > > >>>> 2. When to perform the reboot?
> > > >>>> 2.1. After host deploy, by utilizing the host deploy to perform the
> > > >>>> reboot.
> > > >>>> It requires to configure the network by the monitor when the host is
> > > >>>> detected
> > > >>>> by the engine,
> > > >>>> detached from the installation flow. However it is a step toward the
> > > >>>> non-persistent network feature
> > > >>>> yet to be defined.
> > > >>>> 2.2. After setupNetwork is done and network was configured and
> > > >>>> persisted
> > > >>>> on
> > > >>>> the host.
> > > >>>> There is no special advantage from recoverable aspect, as
> > > >>>> setupNetwork
> > > >>>> is
> > > >>>> constantly
> > > >>>> used to persist the network configuration (by the complementary
> > > >>>> CommitNetworkChanges command).
> > > >>>> In case and network configuration fails, VDSM will revert to the
> > > >>>> last
> > > >>>> well
> > > >>>> known configuration
> > > >>>> - so connectivity with engine should be restored. Design wise, it
> > > >>>> fits
> > > >>>> to
> > > >>>> configure the management
> > > >>>>  network as part of the installation sequence.
> > > >>>> If the network configuration fails in this context, the host status
> > > >>>> will
> > > >>>> be
> > > >>>> set to "InstallFailed" rather than "NonOperational",
> > > >>>> as might occur as a result of a failed setupNetwork command.
> > > >>>>
> > > >>>>
> > > >>>> Your inputs are welcome.
> > > >>>>
> > > >>>> Thanks,
> > > >>>> Moti
> > > > _______________________________________________
> > > > Arch mailing list
> > > > Arch at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/arch
> > > > 
> > > 
> > > _______________________________________________
> > > Arch mailing list
> > > Arch at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/arch
> > > 
> > > 
> > > 
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> 


From alonbl at redhat.com  Thu May  9 20:24:26 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 9 May 2013 16:24:26 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <1367250542.13826069.1368129599726.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<497587874.11990711.1367932265918.JavaMail.root@redhat.com>
	<1596048609.8203468.1367933507824.JavaMail.root@redhat.com>
	<20130508133549.GA17279@redhat.com> <518B3744.8020209@redhat.com>
	<1441971488.13645005.1368112358854.JavaMail.root@redhat.com>
	<2095276319.5812204.1368113790742.JavaMail.root@redhat.com>
	<1367250542.13826069.1368129599726.JavaMail.root@redhat.com>
Message-ID: <1932720504.6022857.1368131066950.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Barak Azulay" <bazulay at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Livnat Peer" <lpeer at redhat.com>, "arch" <arch at ovirt.org>
> Sent: Thursday, May 9, 2013 10:59:59 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Barak Azulay" <bazulay at redhat.com>
> > Cc: "Livnat Peer" <lpeer at redhat.com>, "arch" <arch at ovirt.org>
> > Sent: Thursday, May 9, 2013 6:36:30 PM
> > Subject: Re: feature suggestion: initial generation of management network
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Barak Azulay" <bazulay at redhat.com>
> > > To: "Livnat Peer" <lpeer at redhat.com>
> > > Cc: "arch" <arch at ovirt.org>
> > > Sent: Thursday, May 9, 2013 6:12:38 PM
> > > Subject: Re: feature suggestion: initial generation of management network
> > > 
> > > After reading the thread, top posting to give my perspective of the what
> > > I
> > > think would be the best approach:
> > > 
> > > Some background:
> > > - The reboot at the end of host deployment came after issues in host
> > > deployment that were discovered after fencing/reboot (which had nothing
> > > to
> > > do with the reboot reason).
> > > - Host deployment takes care of of constructing the bridge (when no
> > > bonding
> > > exist on host).
> > > 
> > > So Bottom line:
> > > - I think that both handling the network configuration and reboot should
> > > be
> > > removed from host deployment (I think we all agree on that)
> > > - host deployment should leave the VDSM up and running with everything
> > > configured (including the SSL and SSH keys), and listening to all
> > > networks.
> > > - About the reboot - I'm not sure we still need reboot (this is a
> > > question
> > > even without this discussion)
> > > - Anyway about how to reboot:
> > >   - I don't think it should be done through a VDSM command
> > >   - There is an open issue already with enabling a few stages of fencing
> > >   with
> > >   no PowerManagement module but based on SSH,
> > >     So a new engine internal command should be introduced like
> > >     (runSSHCmdOnVds ... and this command can have 2 variants ... one of
> > >     them
> > >     is reboot ... (the other is restart VDSM))
> > >   - such command will not require a password as the SSH keys should
> > >   already
> > >   be in place
> > 
> > I disagree.
> > After management agent (VDSM in our case) is installed, all communications
> > should be done via that agent.
> 
> First I must say that the reboot may not be a must  for host deploy, this is
> a legitimate point to discuss
> 
> However on the other hand a reboot might still be needed for various reasons,
> If it was that simple we wouldn't have to:
> - use Power Management cards
> - build safety belts around services we depend on
> 
> In addition the fact is that VDSM can turn not responsive due to many
> unexpected reasons, and we might still need the ability to force a host to
> reboot (and not through PM).
> On the other hand SSH is very reliable, used anyway by engine for various
> flows (deploy/upgrade/log collection), and for that reason will be
> configured anyway.
>  
> 
> > Using multi-protocol layers is not wise in this architecture.
> 
> We already do, and as it looks like its here to stay - unless we remove the
> host deployment part from ovirt.
> 
> > For example, if we switch the direction of engine->vdsm communications we
> > cannot use SSH.
> 
> The current plans are to move to a bi directional communication transport on
> top of AMQP/TCP,
> See the work done by Saggi.M
> 
> And even if we do - the SSH will still be required.
> 

I think it would be mistake to require SSH or relay on communication direction (initiated by the engine for example).

Also the requirement of 'root' user at host is something that should be avoided.

If you do not trust your own agent, then we need to provide fail-safe mechanism for our own core functionality (such as reboot).

SSH is used now only to provision host, as you wrote:
1. Host-deploy.
2. ovirt-node upgrade.

Log collection is irrelevant, as it is not exactly part of the product, and can be easily replaced with any other method of log collections.

Both of the above are host provisioning, which can be easily automated out-side of ovirt domain.
2. Node upgrade - for sure... it can be done manually or via pxe, we provide this within ovirt-engine just for the sake of friendly.
1. host-deploy, can be done via external provisioning framework, such as foreman.

Introducing application dependency in SSH is new introduction, and should be considered carefully.

Thanks!

> 
> > 
> > > 
> > > Thoughts/Implications on Host Life cycle:
> > > - The easiest approach will be to leave the host in Installing phase
> > > throughout this process (all under installVdsCommand), and eventually
> > > move
> > > it to reboot
> > > - If one skips reboot than assuming the cluster has more than one
> > > network,
> > > he
> > > host will imminently move to none-operational ( like today)
> > > - We can take a different approach and add a new status to the Host -
> > > PendingNetworkConfig, which could be executed automatically in the future
> > > with network-labels, ot today simply popup todo dialog in the UI.
> > > 
> > > 
> > > Thanks
> > > Barak Azulay
> > >     
> > >  
> > > 
> > > ----- Original Message -----
> > > > From: "Livnat Peer" <lpeer at redhat.com>
> > > > To: "Dan Kenigsberg" <danken at redhat.com>, "Barak Azulay"
> > > > <bazulay at redhat.com>
> > > > Cc: "arch" <arch at ovirt.org>
> > > > Sent: Thursday, May 9, 2013 8:42:28 AM
> > > > Subject: Re: feature suggestion: initial generation of management
> > > > network
> > > > 
> > > > On 05/08/2013 04:35 PM, Dan Kenigsberg wrote:
> > > > > On Tue, May 07, 2013 at 09:31:47AM -0400, Moti Asayag wrote:
> > > > >>
> > > > >>
> > > > >> ----- Original Message -----
> > > > >>> From: "Omer Frenkel" <ofrenkel at redhat.com>
> > > > >>> To: "Moti Asayag" <masayag at redhat.com>
> > > > >>> Cc: "arch" <arch at ovirt.org>, "Alon Bar-Lev" <abarlev at redhat.com>
> > > > >>> Sent: Tuesday, May 7, 2013 4:11:05 PM
> > > > >>> Subject: Re: feature suggestion: initial generation of management
> > > > >>> network
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> ----- Original Message -----
> > > > >>>> From: "Moti Asayag" <masayag at redhat.com>
> > > > >>>> To: "arch" <arch at ovirt.org>
> > > > >>>> Cc: "Alon Bar-Lev" <abarlev at redhat.com>
> > > > >>>> Sent: Tuesday, May 7, 2013 2:22:19 PM
> > > > >>>> Subject: Re: feature suggestion: initial generation of management
> > > > >>>> network
> > > > >>>>
> > > > >>>> I stumbled upon few issues with the current design while
> > > > >>>> implementing
> > > > >>>> it:
> > > > >>>>
> > > > >>>> There seems to be a requirement to reboot the host after the
> > > > >>>> installation
> > > > >>>> is completed in order to assure the host is recoverable.
> > > > >>>>
> > > > >>>> Therefore, the building blocks of the installation process of 3.3
> > > > >>>> are:
> > > > >>>> 1. host deploy which installs the host expect configuring its
> > > > >>>> management
> > > > >>>> network.
> > > > >>>> 2. SetupNetwork (and CommitNetworkChanges) - for creating the
> > > > >>>> management
> > > > >>>> network
> > > > >>>> on the host and persisting the network configuration.
> > > > >>>> 3. Reboot the host - This is a missing piece. (engine has FenceVds
> > > > >>>> command,
> > > > >>>> but it
> > > > >>>> requires the power management to be configured prior to the
> > > > >>>> installation
> > > > >>>> and
> > > > >>>> might
> > > > >>>> be irrelevant for hosts without PM.)
> > > > >>>>
> > > > >>>> So, there are couple of issues here:
> > > > >>>> 1. How to reboot the host?
> > > > >>>> 1.1. By exposing new RebootNode verb in VDSM and invoking it from
> > > > >>>> the
> > > > >>>> engine
> > > > >>>> 1.2. By opening ssh dialog to the host in order to execute the
> > > > >>>> reboot
> > > > >>>>
> > > > >>>
> > > > >>> why not send a reboot flag to the CommitNetworkChanges which is
> > > > >>> sent
> > > > >>> anyway,
> > > > >>> one less call (or connection if you choose ssh) and easier to do.
> > > > >>>
> > > > >>
> > > > >> Adding a reboot parameter to the CommitNetworkChanges
> > > > >> (setSafeNetworkConfig on vdsm side)
> > > > >> exceeds its logical scope which is persisting the network changes.
> > > > >>
> > > > >> Needless to say if such functionally will be required elsewhere, it
> > > > >> couldn't be
> > > > >> properly reused if implemented as part of that command.
> > > > >>
> > > > >> Adding Dan to comment on this as well.
> > > > > 
> > > > > Yeah, a "reboot-after-me" flag defies my sense of cleanliness.
> > > > > If reboot-after-initial-net-config is crucial, we would need to add a
> > > > > special verb for that (or use the fenceNode verb if available).
> > > > > 
> > > > 
> > > > +1
> > > > 
> > > > > 
> > > > > However, I am not sure that this reboot is unavoidable.
> > > > > Originally the reboot had two important goal:
> > > > > - make sure that the updated kernel is running
> > > > > - make sure that the network, which we tweak during bootstrap, is
> > > > >   accessible after boot
> > > > > 
> > > > > Nowadays, the kernels does not change THAT often, for all ovirt can
> > > > > matter. running an oldish kernel is not the end of the world.
> > > > > 
> > > > > And with Moti's feature implemented, we no longer tweak net config
> > > > > blindly during boot. We use a well-define setupNetwork API, with a
> > > > > well-tested rollback mechanism.
> > > > > 
> > > > > The bottom line is, that in my opinion, reboot-after-install can be
> > > > > skipped these days.
> > > > > 
> > > > 
> > > > Adding Barak to the thread as I think he had some concern about
> > > > removing
> > > > the reboot after install.
> > > > 
> > > > 
> > > > >>
> > > > >>>> 2. When to perform the reboot?
> > > > >>>> 2.1. After host deploy, by utilizing the host deploy to perform
> > > > >>>> the
> > > > >>>> reboot.
> > > > >>>> It requires to configure the network by the monitor when the host
> > > > >>>> is
> > > > >>>> detected
> > > > >>>> by the engine,
> > > > >>>> detached from the installation flow. However it is a step toward
> > > > >>>> the
> > > > >>>> non-persistent network feature
> > > > >>>> yet to be defined.
> > > > >>>> 2.2. After setupNetwork is done and network was configured and
> > > > >>>> persisted
> > > > >>>> on
> > > > >>>> the host.
> > > > >>>> There is no special advantage from recoverable aspect, as
> > > > >>>> setupNetwork
> > > > >>>> is
> > > > >>>> constantly
> > > > >>>> used to persist the network configuration (by the complementary
> > > > >>>> CommitNetworkChanges command).
> > > > >>>> In case and network configuration fails, VDSM will revert to the
> > > > >>>> last
> > > > >>>> well
> > > > >>>> known configuration
> > > > >>>> - so connectivity with engine should be restored. Design wise, it
> > > > >>>> fits
> > > > >>>> to
> > > > >>>> configure the management
> > > > >>>>  network as part of the installation sequence.
> > > > >>>> If the network configuration fails in this context, the host
> > > > >>>> status
> > > > >>>> will
> > > > >>>> be
> > > > >>>> set to "InstallFailed" rather than "NonOperational",
> > > > >>>> as might occur as a result of a failed setupNetwork command.
> > > > >>>>
> > > > >>>>
> > > > >>>> Your inputs are welcome.
> > > > >>>>
> > > > >>>> Thanks,
> > > > >>>> Moti
> > > > > _______________________________________________
> > > > > Arch mailing list
> > > > > Arch at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/arch
> > > > > 
> > > > 
> > > > _______________________________________________
> > > > Arch mailing list
> > > > Arch at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/arch
> > > > 
> > > > 
> > > > 
> > > _______________________________________________
> > > Arch mailing list
> > > Arch at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/arch
> > > 
> > 
> 


From lpeer at redhat.com  Sun May 12 06:59:07 2013
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 12 May 2013 09:59:07 +0300
Subject: feature suggestion: initial generation of management network
In-Reply-To: <1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
Message-ID: <518F3DBB.6080606@redhat.com>

Thread Summary -

1. We all agree the automatic reboot after host installation is not
needed anymore and can be removed.

2. There is a vast agreement that we need to add a new VDSM verb for reboot.

3. There was a suggestion to add a checkbox when adding a host to reboot
the host after installation, default would be not to reboot. (leaving
the option to reboot to the administrator).


If there is no objection we'll go with the above.

Thanks, Livnat


On 05/07/2013 02:22 PM, Moti Asayag wrote:
> I stumbled upon few issues with the current design while implementing it:
> 
> There seems to be a requirement to reboot the host after the installation
> is completed in order to assure the host is recoverable.
> 
> Therefore, the building blocks of the installation process of 3.3 are:
> 1. host deploy which installs the host expect configuring its management network.
> 2. SetupNetwork (and CommitNetworkChanges) - for creating the management network 
> on the host and persisting the network configuration.
> 3. Reboot the host - This is a missing piece. (engine has FenceVds command, but it 
> requires the power management to be configured prior to the installation and might 
> be irrelevant for hosts without PM.)
> 
> So, there are couple of issues here:
> 1. How to reboot the host?
> 1.1. By exposing new RebootNode verb in VDSM and invoking it from the engine
> 1.2. By opening ssh dialog to the host in order to execute the reboot
> 
> 2. When to perform the reboot?
> 2.1. After host deploy, by utilizing the host deploy to perform the reboot. 
> It requires to configure the network by the monitor when the host is detected by the engine,
> detached from the installation flow. However it is a step toward the non-persistent network feature
> yet to be defined.
> 2.2. After setupNetwork is done and network was configured and persisted on the host.
> There is no special advantage from recoverable aspect, as setupNetwork is constantly
> used to persist the network configuration (by the complementary CommitNetworkChanges command).
> In case and network configuration fails, VDSM will revert to the last well known configuration 
> - so connectivity with engine should be restored. Design wise, it fits to configure the management
>  network as part of the installation sequence.
> If the network configuration fails in this context, the host status will be set to "InstallFailed" rather than "NonOperational",
> as might occur as a result of a failed setupNetwork command.
> 
> 
> Your inputs are welcome.
> 
> Thanks,
> Moti
> ----- Original Message -----
>> From: "Dan Kenigsberg" <danken at redhat.com>
>> To: "Simon Grinberg" <simon at redhat.com>, "Moti Asayag" <masayag at redhat.com>
>> Cc: "arch" <arch at ovirt.org>
>> Sent: Tuesday, January 1, 2013 2:47:57 PM
>> Subject: Re: feature suggestion: initial generation of management network
>>
>> On Thu, Dec 27, 2012 at 07:36:40AM -0500, Simon Grinberg wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Dan Kenigsberg" <danken at redhat.com>
>>>> To: "Simon Grinberg" <simon at redhat.com>
>>>> Cc: "arch" <arch at ovirt.org>
>>>> Sent: Thursday, December 27, 2012 2:14:06 PM
>>>> Subject: Re: feature suggestion: initial generation of management network
>>>>
>>>> On Tue, Dec 25, 2012 at 09:29:26AM -0500, Simon Grinberg wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Dan Kenigsberg" <danken at redhat.com>
>>>>>> To: "arch" <arch at ovirt.org>
>>>>>> Sent: Tuesday, December 25, 2012 2:27:22 PM
>>>>>> Subject: feature suggestion: initial generation of management
>>>>>> network
>>>>>>
>>>>>> Current condition:
>>>>>> ==================
>>>>>> The management network, named ovirtmgmt, is created during host
>>>>>> bootstrap. It consists of a bridge device, connected to the
>>>>>> network
>>>>>> device that was used to communicate with Engine (nic, bonding or
>>>>>> vlan).
>>>>>> It inherits its ip settings from the latter device.
>>>>>>
>>>>>> Why Is the Management Network Needed?
>>>>>> =====================================
>>>>>> Understandably, some may ask why do we need to have a management
>>>>>> network - why having a host with IPv4 configured on it is not
>>>>>> enough.
>>>>>> The answer is twofold:
>>>>>> 1. In oVirt, a network is an abstraction of the resources
>>>>>> required
>>>>>> for
>>>>>>    connectivity of a host for a specific usage. This is true for
>>>>>>    the
>>>>>>    management network just as it is for VM network or a display
>>>>>>    network.
>>>>>>    The network entity is the key for adding/changing nics and IP
>>>>>>    address.
>>>>>> 2. In many occasions (such as small setups) the management
>>>>>> network is
>>>>>>    used as a VM/display network as well.
>>>>>>
>>>>>> Problems in current connectivity:
>>>>>> ================================
>>>>>> According to alonbl of ovirt-host-deploy fame, and with no
>>>>>> conflict
>>>>>> to
>>>>>> my own experience, creating the management network is the most
>>>>>> fragile,
>>>>>> error-prone step of bootstrap.
>>>>>
>>>>> +1,
>>>>> I've raise that repeatedly in the past, bootstrap should not create
>>>>> the management network but pick up the existing configuration and
>>>>> let the engine override later with it's own configuration if it
>>>>> differs , I'm glad that we finally get to that.
>>>>>
>>>>>>
>>>>>> Currently it always creates a bridged network (even if the DC
>>>>>> requires a
>>>>>> non-bridged ovirtmgmt), it knows nothing about the defined MTU
>>>>>> for
>>>>>> ovirtmgmt, it uses ping to guess on top of which device to build
>>>>>> (and
>>>>>> thus requires Vdsm-to-Engine reverse connectivity), and is the
>>>>>> sole
>>>>>> remaining user of the addNetwork/vdsm-store-net-conf scripts.
>>>>>>
>>>>>> Suggested feature:
>>>>>> ==================
>>>>>> Bootstrap would avoid creating a management network. Instead,
>>>>>> after
>>>>>> bootstrapping a host, Engine would send a getVdsCaps probe to the
>>>>>> installed host, receiving a complete picture of the network
>>>>>> configuration on the host. Among this picture is the device that
>>>>>> holds
>>>>>> the host's management IP address.
>>>>>>
>>>>>> Engine would send setupNetwork command to generate ovirtmgmt with
>>>>>> details devised from this picture, and according to the DC
>>>>>> definition
>>>>>> of
>>>>>> ovirtmgmt.  For example, if Vdsm reports:
>>>>>>
>>>>>> - vlan bond4.3000 has the host's IP, configured to use dhcp.
>>>>>> - bond4 is comprises eth2 and eth3
>>>>>> - ovirtmgmt is defined as a VM network with MTU 9000
>>>>>>
>>>>>> then Engine sends the likes of:
>>>>>>   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
>>>>>>                 bonding=bond4: {eth2,eth3}, MTU=9000)
>>>>>
>>>>> Just one comment here,
>>>>> In order to save time and confusion - if the ovirtmgmt is defined
>>>>> with default values meaning the user did not bother to touch it,
>>>>> let it pick up the VLAN configuration from the first host added in
>>>>> the Data Center.
>>>>>
>>>>> Otherwise, you may override the host VLAN and loose connectivity.
>>>>>
>>>>> This will also solve the situation many users encounter today.
>>>>> 1. The engine in on a host that actually has VLAN defined
>>>>> 2. The ovirtmgmt network was not updated in the DC
>>>>> 3. A host, with VLAN already defined is added - everything works
>>>>> fine
>>>>> 4. Any number of hosts are now added, again everything seems to
>>>>> work fine.
>>>>>
>>>>> But, now try to use setupNetworks, and you'll find out that you
>>>>> can't do much on the interface that contains the ovirtmgmt since
>>>>> the definition does not match. You can't sync (Since this will
>>>>> remove the VLAN and cause connectivity lose) you can't add more
>>>>> networks on top since it already has non-VLAN network on top
>>>>> according to the DC definition, etc.
>>>>>
>>>>> On the other hand you can't update the ovirtmgmt definition on the
>>>>> DC since there are clusters in the DC that use the network.
>>>>>
>>>>> The only workaround not involving DB hack to change the VLAN on the
>>>>> network is to:
>>>>> 1. Create new DC
>>>>> 2. Do not use the wizard that pops up to create your cluster.
>>>>> 3. Modify the ovirtmgmt network to have VLANs
>>>>> 4. Now create a cluster and add your hosts.
>>>>>
>>>>> If you insist on using the default DC and cluster then before
>>>>> adding the first host, create an additional DC and move the
>>>>> Default cluster over there. You may then change the network on the
>>>>> Default cluster and then move the Default cluster back
>>>>>
>>>>> Both are ugly. And should be solved by the proposal above.
>>>>>
>>>>> We do something similar for the Default cluster CPU level, where we
>>>>> set the intial level based on the first host added to the cluster.
>>>>
>>>> I'm not sure what Engine has for Default cluster CPU level. But I
>>>> have
>>>> reservation of the hysteresis in your proposal - after a host is
>>>> added,
>>>> the DC cannot forget ovirtmgmt's vlan.
>>>>
>>>> How about letting the admin edit ovirtmgmt's vlan in the DC level,
>>>> thus
>>>> rendering all hosts out-of-sync. The the admin could manually, or
>>>> through a script, or in the future through a distributed operation,
>>>> sync
>>>> all the hosts to the definition?
>>>
>>> Usually if you do that you will loose connectivity to the hosts.
>>
>> Yes, changing the management vlan id (or ip address) is never fun, and
>> requires out-of-band intervention.
>>
>>> I'm not insisting on the automatic adjustment of the ovirtmgmt network to
>>> match the hosts' (that is just a nice touch) we can take the allow edit
>>> approach.
>>>
>>> But allow to change VLAN on the ovirtmgmt network will indeed solve the
>>> issue I'm trying to solve while creating another issue of user expecting
>>> that we'll be able to re-tag the host from the engine side, which is
>>> challenging to do.
>>>
>>> On the other hand, if we allow to change the VLAN as long as the change
>>> matches the hosts' configuration, it will both solve the issue while not
>>> eluding the user to think that we really can solve the chicken and egg
>>> issue of re-tag the entire system.
>>>
>>> Now with the above ability you do get a flow to do the re-tag.
>>> 1. Place all the hosts in maintenance
>>> 2. Re-tag the ovirtmgmt on all the hosts
>>> 3. Re-tag the hosts on which the engine on
>>> 4. Activate the hosts - this should work well now since connectivity exist
>>> 5. Change the tag on ovirtmgmt on the engine to match the hosts'
>>>
>>> Simple and clear process.
>>>
>>> When the workaround of creating another DC was not possible since the
>>> system was already long in use and the need was re-tag of the network the
>>> above is what I've recommended in the, except that steps 4-5 where done
>>> as:
>>> 4. Stop the engine
>>> 5. Change the tag in the DB
>>> 6. Start the engine
>>> 7. Activate the hosts
>>
>> Sounds reasonable to me - but as far as I am aware this is not tightly
>> related to the $Subject, which is the post-boot ovirtmgmt definition.
>>
>> I've added a few details to
>> http://www.ovirt.org/Features/Normalized_ovirtmgmt_Initialization#Engine
>> and I would apreciate a review from someone with intimate Engine
>> know-how.
>>
>> Dan.
>>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 
> 



From bazulay at redhat.com  Sun May 12 08:15:20 2013
From: bazulay at redhat.com (Barak Azulay)
Date: Sun, 12 May 2013 04:15:20 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <518F3DBB.6080606@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<518F3DBB.6080606@redhat.com>
Message-ID: <557908336.127528.1368346520205.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>
> Cc: "arch" <arch at ovirt.org>, "Alon Bar-Lev" <abarlev at redhat.com>, "Barak Azulay" <bazulay at redhat.com>, "Simon
> Grinberg" <sgrinber at redhat.com>
> Sent: Sunday, May 12, 2013 9:59:07 AM
> Subject: Re: feature suggestion: initial generation of management network
> 
> Thread Summary -
> 
> 1. We all agree the automatic reboot after host installation is not
> needed anymore and can be removed.
> 
> 2. There is a vast agreement that we need to add a new VDSM verb for reboot.

I disagree with the above

In addition to the fact that it will not work when VDSM is not responsive (when this action will be needed the most) 


> 
> 3. There was a suggestion to add a checkbox when adding a host to reboot
> the host after installation, default would be not to reboot. (leaving
> the option to reboot to the administrator).
> 
> 
> If there is no objection we'll go with the above.
> 
> Thanks, Livnat
> 
> 
> On 05/07/2013 02:22 PM, Moti Asayag wrote:
> > I stumbled upon few issues with the current design while implementing it:
> > 
> > There seems to be a requirement to reboot the host after the installation
> > is completed in order to assure the host is recoverable.
> > 
> > Therefore, the building blocks of the installation process of 3.3 are:
> > 1. host deploy which installs the host expect configuring its management
> > network.
> > 2. SetupNetwork (and CommitNetworkChanges) - for creating the management
> > network
> > on the host and persisting the network configuration.
> > 3. Reboot the host - This is a missing piece. (engine has FenceVds command,
> > but it
> > requires the power management to be configured prior to the installation
> > and might
> > be irrelevant for hosts without PM.)
> > 
> > So, there are couple of issues here:
> > 1. How to reboot the host?
> > 1.1. By exposing new RebootNode verb in VDSM and invoking it from the
> > engine
> > 1.2. By opening ssh dialog to the host in order to execute the reboot
> > 
> > 2. When to perform the reboot?
> > 2.1. After host deploy, by utilizing the host deploy to perform the reboot.
> > It requires to configure the network by the monitor when the host is
> > detected by the engine,
> > detached from the installation flow. However it is a step toward the
> > non-persistent network feature
> > yet to be defined.
> > 2.2. After setupNetwork is done and network was configured and persisted on
> > the host.
> > There is no special advantage from recoverable aspect, as setupNetwork is
> > constantly
> > used to persist the network configuration (by the complementary
> > CommitNetworkChanges command).
> > In case and network configuration fails, VDSM will revert to the last well
> > known configuration
> > - so connectivity with engine should be restored. Design wise, it fits to
> > configure the management
> >  network as part of the installation sequence.
> > If the network configuration fails in this context, the host status will be
> > set to "InstallFailed" rather than "NonOperational",
> > as might occur as a result of a failed setupNetwork command.
> > 
> > 
> > Your inputs are welcome.
> > 
> > Thanks,
> > Moti
> > ----- Original Message -----
> >> From: "Dan Kenigsberg" <danken at redhat.com>
> >> To: "Simon Grinberg" <simon at redhat.com>, "Moti Asayag"
> >> <masayag at redhat.com>
> >> Cc: "arch" <arch at ovirt.org>
> >> Sent: Tuesday, January 1, 2013 2:47:57 PM
> >> Subject: Re: feature suggestion: initial generation of management network
> >>
> >> On Thu, Dec 27, 2012 at 07:36:40AM -0500, Simon Grinberg wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Dan Kenigsberg" <danken at redhat.com>
> >>>> To: "Simon Grinberg" <simon at redhat.com>
> >>>> Cc: "arch" <arch at ovirt.org>
> >>>> Sent: Thursday, December 27, 2012 2:14:06 PM
> >>>> Subject: Re: feature suggestion: initial generation of management
> >>>> network
> >>>>
> >>>> On Tue, Dec 25, 2012 at 09:29:26AM -0500, Simon Grinberg wrote:
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Dan Kenigsberg" <danken at redhat.com>
> >>>>>> To: "arch" <arch at ovirt.org>
> >>>>>> Sent: Tuesday, December 25, 2012 2:27:22 PM
> >>>>>> Subject: feature suggestion: initial generation of management
> >>>>>> network
> >>>>>>
> >>>>>> Current condition:
> >>>>>> ==================
> >>>>>> The management network, named ovirtmgmt, is created during host
> >>>>>> bootstrap. It consists of a bridge device, connected to the
> >>>>>> network
> >>>>>> device that was used to communicate with Engine (nic, bonding or
> >>>>>> vlan).
> >>>>>> It inherits its ip settings from the latter device.
> >>>>>>
> >>>>>> Why Is the Management Network Needed?
> >>>>>> =====================================
> >>>>>> Understandably, some may ask why do we need to have a management
> >>>>>> network - why having a host with IPv4 configured on it is not
> >>>>>> enough.
> >>>>>> The answer is twofold:
> >>>>>> 1. In oVirt, a network is an abstraction of the resources
> >>>>>> required
> >>>>>> for
> >>>>>>    connectivity of a host for a specific usage. This is true for
> >>>>>>    the
> >>>>>>    management network just as it is for VM network or a display
> >>>>>>    network.
> >>>>>>    The network entity is the key for adding/changing nics and IP
> >>>>>>    address.
> >>>>>> 2. In many occasions (such as small setups) the management
> >>>>>> network is
> >>>>>>    used as a VM/display network as well.
> >>>>>>
> >>>>>> Problems in current connectivity:
> >>>>>> ================================
> >>>>>> According to alonbl of ovirt-host-deploy fame, and with no
> >>>>>> conflict
> >>>>>> to
> >>>>>> my own experience, creating the management network is the most
> >>>>>> fragile,
> >>>>>> error-prone step of bootstrap.
> >>>>>
> >>>>> +1,
> >>>>> I've raise that repeatedly in the past, bootstrap should not create
> >>>>> the management network but pick up the existing configuration and
> >>>>> let the engine override later with it's own configuration if it
> >>>>> differs , I'm glad that we finally get to that.
> >>>>>
> >>>>>>
> >>>>>> Currently it always creates a bridged network (even if the DC
> >>>>>> requires a
> >>>>>> non-bridged ovirtmgmt), it knows nothing about the defined MTU
> >>>>>> for
> >>>>>> ovirtmgmt, it uses ping to guess on top of which device to build
> >>>>>> (and
> >>>>>> thus requires Vdsm-to-Engine reverse connectivity), and is the
> >>>>>> sole
> >>>>>> remaining user of the addNetwork/vdsm-store-net-conf scripts.
> >>>>>>
> >>>>>> Suggested feature:
> >>>>>> ==================
> >>>>>> Bootstrap would avoid creating a management network. Instead,
> >>>>>> after
> >>>>>> bootstrapping a host, Engine would send a getVdsCaps probe to the
> >>>>>> installed host, receiving a complete picture of the network
> >>>>>> configuration on the host. Among this picture is the device that
> >>>>>> holds
> >>>>>> the host's management IP address.
> >>>>>>
> >>>>>> Engine would send setupNetwork command to generate ovirtmgmt with
> >>>>>> details devised from this picture, and according to the DC
> >>>>>> definition
> >>>>>> of
> >>>>>> ovirtmgmt.  For example, if Vdsm reports:
> >>>>>>
> >>>>>> - vlan bond4.3000 has the host's IP, configured to use dhcp.
> >>>>>> - bond4 is comprises eth2 and eth3
> >>>>>> - ovirtmgmt is defined as a VM network with MTU 9000
> >>>>>>
> >>>>>> then Engine sends the likes of:
> >>>>>>   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
> >>>>>>                 bonding=bond4: {eth2,eth3}, MTU=9000)
> >>>>>
> >>>>> Just one comment here,
> >>>>> In order to save time and confusion - if the ovirtmgmt is defined
> >>>>> with default values meaning the user did not bother to touch it,
> >>>>> let it pick up the VLAN configuration from the first host added in
> >>>>> the Data Center.
> >>>>>
> >>>>> Otherwise, you may override the host VLAN and loose connectivity.
> >>>>>
> >>>>> This will also solve the situation many users encounter today.
> >>>>> 1. The engine in on a host that actually has VLAN defined
> >>>>> 2. The ovirtmgmt network was not updated in the DC
> >>>>> 3. A host, with VLAN already defined is added - everything works
> >>>>> fine
> >>>>> 4. Any number of hosts are now added, again everything seems to
> >>>>> work fine.
> >>>>>
> >>>>> But, now try to use setupNetworks, and you'll find out that you
> >>>>> can't do much on the interface that contains the ovirtmgmt since
> >>>>> the definition does not match. You can't sync (Since this will
> >>>>> remove the VLAN and cause connectivity lose) you can't add more
> >>>>> networks on top since it already has non-VLAN network on top
> >>>>> according to the DC definition, etc.
> >>>>>
> >>>>> On the other hand you can't update the ovirtmgmt definition on the
> >>>>> DC since there are clusters in the DC that use the network.
> >>>>>
> >>>>> The only workaround not involving DB hack to change the VLAN on the
> >>>>> network is to:
> >>>>> 1. Create new DC
> >>>>> 2. Do not use the wizard that pops up to create your cluster.
> >>>>> 3. Modify the ovirtmgmt network to have VLANs
> >>>>> 4. Now create a cluster and add your hosts.
> >>>>>
> >>>>> If you insist on using the default DC and cluster then before
> >>>>> adding the first host, create an additional DC and move the
> >>>>> Default cluster over there. You may then change the network on the
> >>>>> Default cluster and then move the Default cluster back
> >>>>>
> >>>>> Both are ugly. And should be solved by the proposal above.
> >>>>>
> >>>>> We do something similar for the Default cluster CPU level, where we
> >>>>> set the intial level based on the first host added to the cluster.
> >>>>
> >>>> I'm not sure what Engine has for Default cluster CPU level. But I
> >>>> have
> >>>> reservation of the hysteresis in your proposal - after a host is
> >>>> added,
> >>>> the DC cannot forget ovirtmgmt's vlan.
> >>>>
> >>>> How about letting the admin edit ovirtmgmt's vlan in the DC level,
> >>>> thus
> >>>> rendering all hosts out-of-sync. The the admin could manually, or
> >>>> through a script, or in the future through a distributed operation,
> >>>> sync
> >>>> all the hosts to the definition?
> >>>
> >>> Usually if you do that you will loose connectivity to the hosts.
> >>
> >> Yes, changing the management vlan id (or ip address) is never fun, and
> >> requires out-of-band intervention.
> >>
> >>> I'm not insisting on the automatic adjustment of the ovirtmgmt network to
> >>> match the hosts' (that is just a nice touch) we can take the allow edit
> >>> approach.
> >>>
> >>> But allow to change VLAN on the ovirtmgmt network will indeed solve the
> >>> issue I'm trying to solve while creating another issue of user expecting
> >>> that we'll be able to re-tag the host from the engine side, which is
> >>> challenging to do.
> >>>
> >>> On the other hand, if we allow to change the VLAN as long as the change
> >>> matches the hosts' configuration, it will both solve the issue while not
> >>> eluding the user to think that we really can solve the chicken and egg
> >>> issue of re-tag the entire system.
> >>>
> >>> Now with the above ability you do get a flow to do the re-tag.
> >>> 1. Place all the hosts in maintenance
> >>> 2. Re-tag the ovirtmgmt on all the hosts
> >>> 3. Re-tag the hosts on which the engine on
> >>> 4. Activate the hosts - this should work well now since connectivity
> >>> exist
> >>> 5. Change the tag on ovirtmgmt on the engine to match the hosts'
> >>>
> >>> Simple and clear process.
> >>>
> >>> When the workaround of creating another DC was not possible since the
> >>> system was already long in use and the need was re-tag of the network the
> >>> above is what I've recommended in the, except that steps 4-5 where done
> >>> as:
> >>> 4. Stop the engine
> >>> 5. Change the tag in the DB
> >>> 6. Start the engine
> >>> 7. Activate the hosts
> >>
> >> Sounds reasonable to me - but as far as I am aware this is not tightly
> >> related to the $Subject, which is the post-boot ovirtmgmt definition.
> >>
> >> I've added a few details to
> >> http://www.ovirt.org/Features/Normalized_ovirtmgmt_Initialization#Engine
> >> and I would apreciate a review from someone with intimate Engine
> >> know-how.
> >>
> >> Dan.
> >>
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> > 
> 
> 


From alonbl at redhat.com  Sun May 12 08:25:45 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 12 May 2013 04:25:45 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <557908336.127528.1368346520205.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<518F3DBB.6080606@redhat.com>
	<557908336.127528.1368346520205.JavaMail.root@redhat.com>
Message-ID: <1435740579.270682.1368347145591.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Barak Azulay" <bazulay at redhat.com>
> To: "Livnat Peer" <lpeer at redhat.com>
> Cc: "Alon Bar-Lev" <abarlev at redhat.com>, "arch" <arch at ovirt.org>, "Simon Grinberg" <sgrinber at redhat.com>
> Sent: Sunday, May 12, 2013 11:15:20 AM
> Subject: Re: feature suggestion: initial generation of management network
> 
> 
> 
> ----- Original Message -----
> > From: "Livnat Peer" <lpeer at redhat.com>
> > To: "Moti Asayag" <masayag at redhat.com>
> > Cc: "arch" <arch at ovirt.org>, "Alon Bar-Lev" <abarlev at redhat.com>, "Barak
> > Azulay" <bazulay at redhat.com>, "Simon
> > Grinberg" <sgrinber at redhat.com>
> > Sent: Sunday, May 12, 2013 9:59:07 AM
> > Subject: Re: feature suggestion: initial generation of management network
> > 
> > Thread Summary -
> > 
> > 1. We all agree the automatic reboot after host installation is not
> > needed anymore and can be removed.
> > 
> > 2. There is a vast agreement that we need to add a new VDSM verb for
> > reboot.
> 
> I disagree with the above
> 
> In addition to the fact that it will not work when VDSM is not responsive
> (when this action will be needed the most)

If vdsm is unresponsive because of a fault in vdsm we can add a fail safe mechanism for critical commands within vdsm.
And we can always fallback to the standard fencing in such cases.

Can you please describe the scenario of which host-deploy succeeds and vdsm is unresponsive?

Current sequence:
1. host-deploy + reboot - all via single ssh session.

New sequence:
1. host-deploy - via ssh.
2. network setup - via vdsm.
3. optional reboot - via vdsm.

In the new sequence, vdsm must be responsive to accomplish (2), and if (2) succeeds vdsm, again, must be responsive.

Thanks!

> 
> 
> > 
> > 3. There was a suggestion to add a checkbox when adding a host to reboot
> > the host after installation, default would be not to reboot. (leaving
> > the option to reboot to the administrator).
> > 
> > 
> > If there is no objection we'll go with the above.
> > 
> > Thanks, Livnat
> > 
> > 
> > On 05/07/2013 02:22 PM, Moti Asayag wrote:
> > > I stumbled upon few issues with the current design while implementing it:
> > > 
> > > There seems to be a requirement to reboot the host after the installation
> > > is completed in order to assure the host is recoverable.
> > > 
> > > Therefore, the building blocks of the installation process of 3.3 are:
> > > 1. host deploy which installs the host expect configuring its management
> > > network.
> > > 2. SetupNetwork (and CommitNetworkChanges) - for creating the management
> > > network
> > > on the host and persisting the network configuration.
> > > 3. Reboot the host - This is a missing piece. (engine has FenceVds
> > > command,
> > > but it
> > > requires the power management to be configured prior to the installation
> > > and might
> > > be irrelevant for hosts without PM.)
> > > 
> > > So, there are couple of issues here:
> > > 1. How to reboot the host?
> > > 1.1. By exposing new RebootNode verb in VDSM and invoking it from the
> > > engine
> > > 1.2. By opening ssh dialog to the host in order to execute the reboot
> > > 
> > > 2. When to perform the reboot?
> > > 2.1. After host deploy, by utilizing the host deploy to perform the
> > > reboot.
> > > It requires to configure the network by the monitor when the host is
> > > detected by the engine,
> > > detached from the installation flow. However it is a step toward the
> > > non-persistent network feature
> > > yet to be defined.
> > > 2.2. After setupNetwork is done and network was configured and persisted
> > > on
> > > the host.
> > > There is no special advantage from recoverable aspect, as setupNetwork is
> > > constantly
> > > used to persist the network configuration (by the complementary
> > > CommitNetworkChanges command).
> > > In case and network configuration fails, VDSM will revert to the last
> > > well
> > > known configuration
> > > - so connectivity with engine should be restored. Design wise, it fits to
> > > configure the management
> > >  network as part of the installation sequence.
> > > If the network configuration fails in this context, the host status will
> > > be
> > > set to "InstallFailed" rather than "NonOperational",
> > > as might occur as a result of a failed setupNetwork command.
> > > 
> > > 
> > > Your inputs are welcome.
> > > 
> > > Thanks,
> > > Moti
> > > ----- Original Message -----
> > >> From: "Dan Kenigsberg" <danken at redhat.com>
> > >> To: "Simon Grinberg" <simon at redhat.com>, "Moti Asayag"
> > >> <masayag at redhat.com>
> > >> Cc: "arch" <arch at ovirt.org>
> > >> Sent: Tuesday, January 1, 2013 2:47:57 PM
> > >> Subject: Re: feature suggestion: initial generation of management
> > >> network
> > >>
> > >> On Thu, Dec 27, 2012 at 07:36:40AM -0500, Simon Grinberg wrote:
> > >>>
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Dan Kenigsberg" <danken at redhat.com>
> > >>>> To: "Simon Grinberg" <simon at redhat.com>
> > >>>> Cc: "arch" <arch at ovirt.org>
> > >>>> Sent: Thursday, December 27, 2012 2:14:06 PM
> > >>>> Subject: Re: feature suggestion: initial generation of management
> > >>>> network
> > >>>>
> > >>>> On Tue, Dec 25, 2012 at 09:29:26AM -0500, Simon Grinberg wrote:
> > >>>>>
> > >>>>>
> > >>>>> ----- Original Message -----
> > >>>>>> From: "Dan Kenigsberg" <danken at redhat.com>
> > >>>>>> To: "arch" <arch at ovirt.org>
> > >>>>>> Sent: Tuesday, December 25, 2012 2:27:22 PM
> > >>>>>> Subject: feature suggestion: initial generation of management
> > >>>>>> network
> > >>>>>>
> > >>>>>> Current condition:
> > >>>>>> ==================
> > >>>>>> The management network, named ovirtmgmt, is created during host
> > >>>>>> bootstrap. It consists of a bridge device, connected to the
> > >>>>>> network
> > >>>>>> device that was used to communicate with Engine (nic, bonding or
> > >>>>>> vlan).
> > >>>>>> It inherits its ip settings from the latter device.
> > >>>>>>
> > >>>>>> Why Is the Management Network Needed?
> > >>>>>> =====================================
> > >>>>>> Understandably, some may ask why do we need to have a management
> > >>>>>> network - why having a host with IPv4 configured on it is not
> > >>>>>> enough.
> > >>>>>> The answer is twofold:
> > >>>>>> 1. In oVirt, a network is an abstraction of the resources
> > >>>>>> required
> > >>>>>> for
> > >>>>>>    connectivity of a host for a specific usage. This is true for
> > >>>>>>    the
> > >>>>>>    management network just as it is for VM network or a display
> > >>>>>>    network.
> > >>>>>>    The network entity is the key for adding/changing nics and IP
> > >>>>>>    address.
> > >>>>>> 2. In many occasions (such as small setups) the management
> > >>>>>> network is
> > >>>>>>    used as a VM/display network as well.
> > >>>>>>
> > >>>>>> Problems in current connectivity:
> > >>>>>> ================================
> > >>>>>> According to alonbl of ovirt-host-deploy fame, and with no
> > >>>>>> conflict
> > >>>>>> to
> > >>>>>> my own experience, creating the management network is the most
> > >>>>>> fragile,
> > >>>>>> error-prone step of bootstrap.
> > >>>>>
> > >>>>> +1,
> > >>>>> I've raise that repeatedly in the past, bootstrap should not create
> > >>>>> the management network but pick up the existing configuration and
> > >>>>> let the engine override later with it's own configuration if it
> > >>>>> differs , I'm glad that we finally get to that.
> > >>>>>
> > >>>>>>
> > >>>>>> Currently it always creates a bridged network (even if the DC
> > >>>>>> requires a
> > >>>>>> non-bridged ovirtmgmt), it knows nothing about the defined MTU
> > >>>>>> for
> > >>>>>> ovirtmgmt, it uses ping to guess on top of which device to build
> > >>>>>> (and
> > >>>>>> thus requires Vdsm-to-Engine reverse connectivity), and is the
> > >>>>>> sole
> > >>>>>> remaining user of the addNetwork/vdsm-store-net-conf scripts.
> > >>>>>>
> > >>>>>> Suggested feature:
> > >>>>>> ==================
> > >>>>>> Bootstrap would avoid creating a management network. Instead,
> > >>>>>> after
> > >>>>>> bootstrapping a host, Engine would send a getVdsCaps probe to the
> > >>>>>> installed host, receiving a complete picture of the network
> > >>>>>> configuration on the host. Among this picture is the device that
> > >>>>>> holds
> > >>>>>> the host's management IP address.
> > >>>>>>
> > >>>>>> Engine would send setupNetwork command to generate ovirtmgmt with
> > >>>>>> details devised from this picture, and according to the DC
> > >>>>>> definition
> > >>>>>> of
> > >>>>>> ovirtmgmt.  For example, if Vdsm reports:
> > >>>>>>
> > >>>>>> - vlan bond4.3000 has the host's IP, configured to use dhcp.
> > >>>>>> - bond4 is comprises eth2 and eth3
> > >>>>>> - ovirtmgmt is defined as a VM network with MTU 9000
> > >>>>>>
> > >>>>>> then Engine sends the likes of:
> > >>>>>>   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
> > >>>>>>                 bonding=bond4: {eth2,eth3}, MTU=9000)
> > >>>>>
> > >>>>> Just one comment here,
> > >>>>> In order to save time and confusion - if the ovirtmgmt is defined
> > >>>>> with default values meaning the user did not bother to touch it,
> > >>>>> let it pick up the VLAN configuration from the first host added in
> > >>>>> the Data Center.
> > >>>>>
> > >>>>> Otherwise, you may override the host VLAN and loose connectivity.
> > >>>>>
> > >>>>> This will also solve the situation many users encounter today.
> > >>>>> 1. The engine in on a host that actually has VLAN defined
> > >>>>> 2. The ovirtmgmt network was not updated in the DC
> > >>>>> 3. A host, with VLAN already defined is added - everything works
> > >>>>> fine
> > >>>>> 4. Any number of hosts are now added, again everything seems to
> > >>>>> work fine.
> > >>>>>
> > >>>>> But, now try to use setupNetworks, and you'll find out that you
> > >>>>> can't do much on the interface that contains the ovirtmgmt since
> > >>>>> the definition does not match. You can't sync (Since this will
> > >>>>> remove the VLAN and cause connectivity lose) you can't add more
> > >>>>> networks on top since it already has non-VLAN network on top
> > >>>>> according to the DC definition, etc.
> > >>>>>
> > >>>>> On the other hand you can't update the ovirtmgmt definition on the
> > >>>>> DC since there are clusters in the DC that use the network.
> > >>>>>
> > >>>>> The only workaround not involving DB hack to change the VLAN on the
> > >>>>> network is to:
> > >>>>> 1. Create new DC
> > >>>>> 2. Do not use the wizard that pops up to create your cluster.
> > >>>>> 3. Modify the ovirtmgmt network to have VLANs
> > >>>>> 4. Now create a cluster and add your hosts.
> > >>>>>
> > >>>>> If you insist on using the default DC and cluster then before
> > >>>>> adding the first host, create an additional DC and move the
> > >>>>> Default cluster over there. You may then change the network on the
> > >>>>> Default cluster and then move the Default cluster back
> > >>>>>
> > >>>>> Both are ugly. And should be solved by the proposal above.
> > >>>>>
> > >>>>> We do something similar for the Default cluster CPU level, where we
> > >>>>> set the intial level based on the first host added to the cluster.
> > >>>>
> > >>>> I'm not sure what Engine has for Default cluster CPU level. But I
> > >>>> have
> > >>>> reservation of the hysteresis in your proposal - after a host is
> > >>>> added,
> > >>>> the DC cannot forget ovirtmgmt's vlan.
> > >>>>
> > >>>> How about letting the admin edit ovirtmgmt's vlan in the DC level,
> > >>>> thus
> > >>>> rendering all hosts out-of-sync. The the admin could manually, or
> > >>>> through a script, or in the future through a distributed operation,
> > >>>> sync
> > >>>> all the hosts to the definition?
> > >>>
> > >>> Usually if you do that you will loose connectivity to the hosts.
> > >>
> > >> Yes, changing the management vlan id (or ip address) is never fun, and
> > >> requires out-of-band intervention.
> > >>
> > >>> I'm not insisting on the automatic adjustment of the ovirtmgmt network
> > >>> to
> > >>> match the hosts' (that is just a nice touch) we can take the allow edit
> > >>> approach.
> > >>>
> > >>> But allow to change VLAN on the ovirtmgmt network will indeed solve the
> > >>> issue I'm trying to solve while creating another issue of user
> > >>> expecting
> > >>> that we'll be able to re-tag the host from the engine side, which is
> > >>> challenging to do.
> > >>>
> > >>> On the other hand, if we allow to change the VLAN as long as the change
> > >>> matches the hosts' configuration, it will both solve the issue while
> > >>> not
> > >>> eluding the user to think that we really can solve the chicken and egg
> > >>> issue of re-tag the entire system.
> > >>>
> > >>> Now with the above ability you do get a flow to do the re-tag.
> > >>> 1. Place all the hosts in maintenance
> > >>> 2. Re-tag the ovirtmgmt on all the hosts
> > >>> 3. Re-tag the hosts on which the engine on
> > >>> 4. Activate the hosts - this should work well now since connectivity
> > >>> exist
> > >>> 5. Change the tag on ovirtmgmt on the engine to match the hosts'
> > >>>
> > >>> Simple and clear process.
> > >>>
> > >>> When the workaround of creating another DC was not possible since the
> > >>> system was already long in use and the need was re-tag of the network
> > >>> the
> > >>> above is what I've recommended in the, except that steps 4-5 where done
> > >>> as:
> > >>> 4. Stop the engine
> > >>> 5. Change the tag in the DB
> > >>> 6. Start the engine
> > >>> 7. Activate the hosts
> > >>
> > >> Sounds reasonable to me - but as far as I am aware this is not tightly
> > >> related to the $Subject, which is the post-boot ovirtmgmt definition.
> > >>
> > >> I've added a few details to
> > >> http://www.ovirt.org/Features/Normalized_ovirtmgmt_Initialization#Engine
> > >> and I would apreciate a review from someone with intimate Engine
> > >> know-how.
> > >>
> > >> Dan.
> > >>
> > > _______________________________________________
> > > Arch mailing list
> > > Arch at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/arch
> > > 
> > > 
> > 
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From masayag at redhat.com  Sun May 12 08:37:01 2013
From: masayag at redhat.com (Moti Asayag)
Date: Sun, 12 May 2013 04:37:01 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <1435740579.270682.1368347145591.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<518F3DBB.6080606@redhat.com>
	<557908336.127528.1368346520205.JavaMail.root@redhat.com>
	<1435740579.270682.1368347145591.JavaMail.root@redhat.com>
Message-ID: <35164694.135768.1368347821291.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Barak Azulay" <bazulay at redhat.com>
> Cc: "arch" <arch at ovirt.org>, "Simon Grinberg" <sgrinber at redhat.com>
> Sent: Sunday, May 12, 2013 11:25:45 AM
> Subject: Re: feature suggestion: initial generation of management network
> 
> 
> 
> ----- Original Message -----
> > From: "Barak Azulay" <bazulay at redhat.com>
> > To: "Livnat Peer" <lpeer at redhat.com>
> > Cc: "Alon Bar-Lev" <abarlev at redhat.com>, "arch" <arch at ovirt.org>, "Simon
> > Grinberg" <sgrinber at redhat.com>
> > Sent: Sunday, May 12, 2013 11:15:20 AM
> > Subject: Re: feature suggestion: initial generation of management network
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Livnat Peer" <lpeer at redhat.com>
> > > To: "Moti Asayag" <masayag at redhat.com>
> > > Cc: "arch" <arch at ovirt.org>, "Alon Bar-Lev" <abarlev at redhat.com>, "Barak
> > > Azulay" <bazulay at redhat.com>, "Simon
> > > Grinberg" <sgrinber at redhat.com>
> > > Sent: Sunday, May 12, 2013 9:59:07 AM
> > > Subject: Re: feature suggestion: initial generation of management network
> > > 
> > > Thread Summary -
> > > 
> > > 1. We all agree the automatic reboot after host installation is not
> > > needed anymore and can be removed.
> > > 
> > > 2. There is a vast agreement that we need to add a new VDSM verb for
> > > reboot.
> > 
> > I disagree with the above
> > 
> > In addition to the fact that it will not work when VDSM is not responsive
> > (when this action will be needed the most)
> 
> If vdsm is unresponsive because of a fault in vdsm we can add a fail safe
> mechanism for critical commands within vdsm.
> And we can always fallback to the standard fencing in such cases.
> 
> Can you please describe the scenario of which host-deploy succeeds and vdsm
> is unresponsive?
> 
> Current sequence:
> 1. host-deploy + reboot - all via single ssh session.
> 
> New sequence:
> 1. host-deploy - via ssh.
> 2. network setup - via vdsm.

I'd like to add that if step 2 fails, VDSM should rollback to the last known
network configuration, therefore it shouldn't remain non-responsive in case the
setup network command caused a communication lose.

> 3. optional reboot - via vdsm.
> 
> In the new sequence, vdsm must be responsive to accomplish (2), and if (2)
> succeeds vdsm, again, must be responsive.
> 
> Thanks!
> 
> > 
> > 
> > > 
> > > 3. There was a suggestion to add a checkbox when adding a host to reboot
> > > the host after installation, default would be not to reboot. (leaving
> > > the option to reboot to the administrator).
> > > 
> > > 
> > > If there is no objection we'll go with the above.
> > > 
> > > Thanks, Livnat
> > > 
> > > 
> > > On 05/07/2013 02:22 PM, Moti Asayag wrote:
> > > > I stumbled upon few issues with the current design while implementing
> > > > it:
> > > > 
> > > > There seems to be a requirement to reboot the host after the
> > > > installation
> > > > is completed in order to assure the host is recoverable.
> > > > 
> > > > Therefore, the building blocks of the installation process of 3.3 are:
> > > > 1. host deploy which installs the host expect configuring its
> > > > management
> > > > network.
> > > > 2. SetupNetwork (and CommitNetworkChanges) - for creating the
> > > > management
> > > > network
> > > > on the host and persisting the network configuration.
> > > > 3. Reboot the host - This is a missing piece. (engine has FenceVds
> > > > command,
> > > > but it
> > > > requires the power management to be configured prior to the
> > > > installation
> > > > and might
> > > > be irrelevant for hosts without PM.)
> > > > 
> > > > So, there are couple of issues here:
> > > > 1. How to reboot the host?
> > > > 1.1. By exposing new RebootNode verb in VDSM and invoking it from the
> > > > engine
> > > > 1.2. By opening ssh dialog to the host in order to execute the reboot
> > > > 
> > > > 2. When to perform the reboot?
> > > > 2.1. After host deploy, by utilizing the host deploy to perform the
> > > > reboot.
> > > > It requires to configure the network by the monitor when the host is
> > > > detected by the engine,
> > > > detached from the installation flow. However it is a step toward the
> > > > non-persistent network feature
> > > > yet to be defined.
> > > > 2.2. After setupNetwork is done and network was configured and
> > > > persisted
> > > > on
> > > > the host.
> > > > There is no special advantage from recoverable aspect, as setupNetwork
> > > > is
> > > > constantly
> > > > used to persist the network configuration (by the complementary
> > > > CommitNetworkChanges command).
> > > > In case and network configuration fails, VDSM will revert to the last
> > > > well
> > > > known configuration
> > > > - so connectivity with engine should be restored. Design wise, it fits
> > > > to
> > > > configure the management
> > > >  network as part of the installation sequence.
> > > > If the network configuration fails in this context, the host status
> > > > will
> > > > be
> > > > set to "InstallFailed" rather than "NonOperational",
> > > > as might occur as a result of a failed setupNetwork command.
> > > > 
> > > > 
> > > > Your inputs are welcome.
> > > > 
> > > > Thanks,
> > > > Moti
> > > > ----- Original Message -----
> > > >> From: "Dan Kenigsberg" <danken at redhat.com>
> > > >> To: "Simon Grinberg" <simon at redhat.com>, "Moti Asayag"
> > > >> <masayag at redhat.com>
> > > >> Cc: "arch" <arch at ovirt.org>
> > > >> Sent: Tuesday, January 1, 2013 2:47:57 PM
> > > >> Subject: Re: feature suggestion: initial generation of management
> > > >> network
> > > >>
> > > >> On Thu, Dec 27, 2012 at 07:36:40AM -0500, Simon Grinberg wrote:
> > > >>>
> > > >>>
> > > >>> ----- Original Message -----
> > > >>>> From: "Dan Kenigsberg" <danken at redhat.com>
> > > >>>> To: "Simon Grinberg" <simon at redhat.com>
> > > >>>> Cc: "arch" <arch at ovirt.org>
> > > >>>> Sent: Thursday, December 27, 2012 2:14:06 PM
> > > >>>> Subject: Re: feature suggestion: initial generation of management
> > > >>>> network
> > > >>>>
> > > >>>> On Tue, Dec 25, 2012 at 09:29:26AM -0500, Simon Grinberg wrote:
> > > >>>>>
> > > >>>>>
> > > >>>>> ----- Original Message -----
> > > >>>>>> From: "Dan Kenigsberg" <danken at redhat.com>
> > > >>>>>> To: "arch" <arch at ovirt.org>
> > > >>>>>> Sent: Tuesday, December 25, 2012 2:27:22 PM
> > > >>>>>> Subject: feature suggestion: initial generation of management
> > > >>>>>> network
> > > >>>>>>
> > > >>>>>> Current condition:
> > > >>>>>> ==================
> > > >>>>>> The management network, named ovirtmgmt, is created during host
> > > >>>>>> bootstrap. It consists of a bridge device, connected to the
> > > >>>>>> network
> > > >>>>>> device that was used to communicate with Engine (nic, bonding or
> > > >>>>>> vlan).
> > > >>>>>> It inherits its ip settings from the latter device.
> > > >>>>>>
> > > >>>>>> Why Is the Management Network Needed?
> > > >>>>>> =====================================
> > > >>>>>> Understandably, some may ask why do we need to have a management
> > > >>>>>> network - why having a host with IPv4 configured on it is not
> > > >>>>>> enough.
> > > >>>>>> The answer is twofold:
> > > >>>>>> 1. In oVirt, a network is an abstraction of the resources
> > > >>>>>> required
> > > >>>>>> for
> > > >>>>>>    connectivity of a host for a specific usage. This is true for
> > > >>>>>>    the
> > > >>>>>>    management network just as it is for VM network or a display
> > > >>>>>>    network.
> > > >>>>>>    The network entity is the key for adding/changing nics and IP
> > > >>>>>>    address.
> > > >>>>>> 2. In many occasions (such as small setups) the management
> > > >>>>>> network is
> > > >>>>>>    used as a VM/display network as well.
> > > >>>>>>
> > > >>>>>> Problems in current connectivity:
> > > >>>>>> ================================
> > > >>>>>> According to alonbl of ovirt-host-deploy fame, and with no
> > > >>>>>> conflict
> > > >>>>>> to
> > > >>>>>> my own experience, creating the management network is the most
> > > >>>>>> fragile,
> > > >>>>>> error-prone step of bootstrap.
> > > >>>>>
> > > >>>>> +1,
> > > >>>>> I've raise that repeatedly in the past, bootstrap should not create
> > > >>>>> the management network but pick up the existing configuration and
> > > >>>>> let the engine override later with it's own configuration if it
> > > >>>>> differs , I'm glad that we finally get to that.
> > > >>>>>
> > > >>>>>>
> > > >>>>>> Currently it always creates a bridged network (even if the DC
> > > >>>>>> requires a
> > > >>>>>> non-bridged ovirtmgmt), it knows nothing about the defined MTU
> > > >>>>>> for
> > > >>>>>> ovirtmgmt, it uses ping to guess on top of which device to build
> > > >>>>>> (and
> > > >>>>>> thus requires Vdsm-to-Engine reverse connectivity), and is the
> > > >>>>>> sole
> > > >>>>>> remaining user of the addNetwork/vdsm-store-net-conf scripts.
> > > >>>>>>
> > > >>>>>> Suggested feature:
> > > >>>>>> ==================
> > > >>>>>> Bootstrap would avoid creating a management network. Instead,
> > > >>>>>> after
> > > >>>>>> bootstrapping a host, Engine would send a getVdsCaps probe to the
> > > >>>>>> installed host, receiving a complete picture of the network
> > > >>>>>> configuration on the host. Among this picture is the device that
> > > >>>>>> holds
> > > >>>>>> the host's management IP address.
> > > >>>>>>
> > > >>>>>> Engine would send setupNetwork command to generate ovirtmgmt with
> > > >>>>>> details devised from this picture, and according to the DC
> > > >>>>>> definition
> > > >>>>>> of
> > > >>>>>> ovirtmgmt.  For example, if Vdsm reports:
> > > >>>>>>
> > > >>>>>> - vlan bond4.3000 has the host's IP, configured to use dhcp.
> > > >>>>>> - bond4 is comprises eth2 and eth3
> > > >>>>>> - ovirtmgmt is defined as a VM network with MTU 9000
> > > >>>>>>
> > > >>>>>> then Engine sends the likes of:
> > > >>>>>>   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
> > > >>>>>>                 bonding=bond4: {eth2,eth3}, MTU=9000)
> > > >>>>>
> > > >>>>> Just one comment here,
> > > >>>>> In order to save time and confusion - if the ovirtmgmt is defined
> > > >>>>> with default values meaning the user did not bother to touch it,
> > > >>>>> let it pick up the VLAN configuration from the first host added in
> > > >>>>> the Data Center.
> > > >>>>>
> > > >>>>> Otherwise, you may override the host VLAN and loose connectivity.
> > > >>>>>
> > > >>>>> This will also solve the situation many users encounter today.
> > > >>>>> 1. The engine in on a host that actually has VLAN defined
> > > >>>>> 2. The ovirtmgmt network was not updated in the DC
> > > >>>>> 3. A host, with VLAN already defined is added - everything works
> > > >>>>> fine
> > > >>>>> 4. Any number of hosts are now added, again everything seems to
> > > >>>>> work fine.
> > > >>>>>
> > > >>>>> But, now try to use setupNetworks, and you'll find out that you
> > > >>>>> can't do much on the interface that contains the ovirtmgmt since
> > > >>>>> the definition does not match. You can't sync (Since this will
> > > >>>>> remove the VLAN and cause connectivity lose) you can't add more
> > > >>>>> networks on top since it already has non-VLAN network on top
> > > >>>>> according to the DC definition, etc.
> > > >>>>>
> > > >>>>> On the other hand you can't update the ovirtmgmt definition on the
> > > >>>>> DC since there are clusters in the DC that use the network.
> > > >>>>>
> > > >>>>> The only workaround not involving DB hack to change the VLAN on the
> > > >>>>> network is to:
> > > >>>>> 1. Create new DC
> > > >>>>> 2. Do not use the wizard that pops up to create your cluster.
> > > >>>>> 3. Modify the ovirtmgmt network to have VLANs
> > > >>>>> 4. Now create a cluster and add your hosts.
> > > >>>>>
> > > >>>>> If you insist on using the default DC and cluster then before
> > > >>>>> adding the first host, create an additional DC and move the
> > > >>>>> Default cluster over there. You may then change the network on the
> > > >>>>> Default cluster and then move the Default cluster back
> > > >>>>>
> > > >>>>> Both are ugly. And should be solved by the proposal above.
> > > >>>>>
> > > >>>>> We do something similar for the Default cluster CPU level, where we
> > > >>>>> set the intial level based on the first host added to the cluster.
> > > >>>>
> > > >>>> I'm not sure what Engine has for Default cluster CPU level. But I
> > > >>>> have
> > > >>>> reservation of the hysteresis in your proposal - after a host is
> > > >>>> added,
> > > >>>> the DC cannot forget ovirtmgmt's vlan.
> > > >>>>
> > > >>>> How about letting the admin edit ovirtmgmt's vlan in the DC level,
> > > >>>> thus
> > > >>>> rendering all hosts out-of-sync. The the admin could manually, or
> > > >>>> through a script, or in the future through a distributed operation,
> > > >>>> sync
> > > >>>> all the hosts to the definition?
> > > >>>
> > > >>> Usually if you do that you will loose connectivity to the hosts.
> > > >>
> > > >> Yes, changing the management vlan id (or ip address) is never fun, and
> > > >> requires out-of-band intervention.
> > > >>
> > > >>> I'm not insisting on the automatic adjustment of the ovirtmgmt
> > > >>> network
> > > >>> to
> > > >>> match the hosts' (that is just a nice touch) we can take the allow
> > > >>> edit
> > > >>> approach.
> > > >>>
> > > >>> But allow to change VLAN on the ovirtmgmt network will indeed solve
> > > >>> the
> > > >>> issue I'm trying to solve while creating another issue of user
> > > >>> expecting
> > > >>> that we'll be able to re-tag the host from the engine side, which is
> > > >>> challenging to do.
> > > >>>
> > > >>> On the other hand, if we allow to change the VLAN as long as the
> > > >>> change
> > > >>> matches the hosts' configuration, it will both solve the issue while
> > > >>> not
> > > >>> eluding the user to think that we really can solve the chicken and
> > > >>> egg
> > > >>> issue of re-tag the entire system.
> > > >>>
> > > >>> Now with the above ability you do get a flow to do the re-tag.
> > > >>> 1. Place all the hosts in maintenance
> > > >>> 2. Re-tag the ovirtmgmt on all the hosts
> > > >>> 3. Re-tag the hosts on which the engine on
> > > >>> 4. Activate the hosts - this should work well now since connectivity
> > > >>> exist
> > > >>> 5. Change the tag on ovirtmgmt on the engine to match the hosts'
> > > >>>
> > > >>> Simple and clear process.
> > > >>>
> > > >>> When the workaround of creating another DC was not possible since the
> > > >>> system was already long in use and the need was re-tag of the network
> > > >>> the
> > > >>> above is what I've recommended in the, except that steps 4-5 where
> > > >>> done
> > > >>> as:
> > > >>> 4. Stop the engine
> > > >>> 5. Change the tag in the DB
> > > >>> 6. Start the engine
> > > >>> 7. Activate the hosts
> > > >>
> > > >> Sounds reasonable to me - but as far as I am aware this is not tightly
> > > >> related to the $Subject, which is the post-boot ovirtmgmt definition.
> > > >>
> > > >> I've added a few details to
> > > >> http://www.ovirt.org/Features/Normalized_ovirtmgmt_Initialization#Engine
> > > >> and I would apreciate a review from someone with intimate Engine
> > > >> know-how.
> > > >>
> > > >> Dan.
> > > >>
> > > > _______________________________________________
> > > > Arch mailing list
> > > > Arch at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/arch
> > > > 
> > > > 
> > > 
> > > 
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From lpeer at redhat.com  Sun May 12 08:46:06 2013
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 12 May 2013 11:46:06 +0300
Subject: feature suggestion: initial generation of management network
In-Reply-To: <557908336.127528.1368346520205.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<518F3DBB.6080606@redhat.com>
	<557908336.127528.1368346520205.JavaMail.root@redhat.com>
Message-ID: <518F56CE.3010802@redhat.com>

On 05/12/2013 11:15 AM, Barak Azulay wrote:
> 
> 
> ----- Original Message -----
>> From: "Livnat Peer" <lpeer at redhat.com>
>> To: "Moti Asayag" <masayag at redhat.com>
>> Cc: "arch" <arch at ovirt.org>, "Alon Bar-Lev" <abarlev at redhat.com>, "Barak Azulay" <bazulay at redhat.com>, "Simon
>> Grinberg" <sgrinber at redhat.com>
>> Sent: Sunday, May 12, 2013 9:59:07 AM
>> Subject: Re: feature suggestion: initial generation of management network
>>
>> Thread Summary -
>>
>> 1. We all agree the automatic reboot after host installation is not
>> needed anymore and can be removed.
>>
>> 2. There is a vast agreement that we need to add a new VDSM verb for reboot.
> 
> I disagree with the above
> 
> In addition to the fact that it will not work when VDSM is not responsive (when this action will be needed the most) 
> 

you can fence the node if VDSM is non responsive, that's the mechanism
we use today to deal with such cases.

> 
>>
>> 3. There was a suggestion to add a checkbox when adding a host to reboot
>> the host after installation, default would be not to reboot. (leaving
>> the option to reboot to the administrator).
>>
>>
>> If there is no objection we'll go with the above.
>>
>> Thanks, Livnat
>>
>>
>> On 05/07/2013 02:22 PM, Moti Asayag wrote:
>>> I stumbled upon few issues with the current design while implementing it:
>>>
>>> There seems to be a requirement to reboot the host after the installation
>>> is completed in order to assure the host is recoverable.
>>>
>>> Therefore, the building blocks of the installation process of 3.3 are:
>>> 1. host deploy which installs the host expect configuring its management
>>> network.
>>> 2. SetupNetwork (and CommitNetworkChanges) - for creating the management
>>> network
>>> on the host and persisting the network configuration.
>>> 3. Reboot the host - This is a missing piece. (engine has FenceVds command,
>>> but it
>>> requires the power management to be configured prior to the installation
>>> and might
>>> be irrelevant for hosts without PM.)
>>>
>>> So, there are couple of issues here:
>>> 1. How to reboot the host?
>>> 1.1. By exposing new RebootNode verb in VDSM and invoking it from the
>>> engine
>>> 1.2. By opening ssh dialog to the host in order to execute the reboot
>>>
>>> 2. When to perform the reboot?
>>> 2.1. After host deploy, by utilizing the host deploy to perform the reboot.
>>> It requires to configure the network by the monitor when the host is
>>> detected by the engine,
>>> detached from the installation flow. However it is a step toward the
>>> non-persistent network feature
>>> yet to be defined.
>>> 2.2. After setupNetwork is done and network was configured and persisted on
>>> the host.
>>> There is no special advantage from recoverable aspect, as setupNetwork is
>>> constantly
>>> used to persist the network configuration (by the complementary
>>> CommitNetworkChanges command).
>>> In case and network configuration fails, VDSM will revert to the last well
>>> known configuration
>>> - so connectivity with engine should be restored. Design wise, it fits to
>>> configure the management
>>>  network as part of the installation sequence.
>>> If the network configuration fails in this context, the host status will be
>>> set to "InstallFailed" rather than "NonOperational",
>>> as might occur as a result of a failed setupNetwork command.
>>>
>>>
>>> Your inputs are welcome.
>>>
>>> Thanks,
>>> Moti
>>> ----- Original Message -----
>>>> From: "Dan Kenigsberg" <danken at redhat.com>
>>>> To: "Simon Grinberg" <simon at redhat.com>, "Moti Asayag"
>>>> <masayag at redhat.com>
>>>> Cc: "arch" <arch at ovirt.org>
>>>> Sent: Tuesday, January 1, 2013 2:47:57 PM
>>>> Subject: Re: feature suggestion: initial generation of management network
>>>>
>>>> On Thu, Dec 27, 2012 at 07:36:40AM -0500, Simon Grinberg wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Dan Kenigsberg" <danken at redhat.com>
>>>>>> To: "Simon Grinberg" <simon at redhat.com>
>>>>>> Cc: "arch" <arch at ovirt.org>
>>>>>> Sent: Thursday, December 27, 2012 2:14:06 PM
>>>>>> Subject: Re: feature suggestion: initial generation of management
>>>>>> network
>>>>>>
>>>>>> On Tue, Dec 25, 2012 at 09:29:26AM -0500, Simon Grinberg wrote:
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Dan Kenigsberg" <danken at redhat.com>
>>>>>>>> To: "arch" <arch at ovirt.org>
>>>>>>>> Sent: Tuesday, December 25, 2012 2:27:22 PM
>>>>>>>> Subject: feature suggestion: initial generation of management
>>>>>>>> network
>>>>>>>>
>>>>>>>> Current condition:
>>>>>>>> ==================
>>>>>>>> The management network, named ovirtmgmt, is created during host
>>>>>>>> bootstrap. It consists of a bridge device, connected to the
>>>>>>>> network
>>>>>>>> device that was used to communicate with Engine (nic, bonding or
>>>>>>>> vlan).
>>>>>>>> It inherits its ip settings from the latter device.
>>>>>>>>
>>>>>>>> Why Is the Management Network Needed?
>>>>>>>> =====================================
>>>>>>>> Understandably, some may ask why do we need to have a management
>>>>>>>> network - why having a host with IPv4 configured on it is not
>>>>>>>> enough.
>>>>>>>> The answer is twofold:
>>>>>>>> 1. In oVirt, a network is an abstraction of the resources
>>>>>>>> required
>>>>>>>> for
>>>>>>>>    connectivity of a host for a specific usage. This is true for
>>>>>>>>    the
>>>>>>>>    management network just as it is for VM network or a display
>>>>>>>>    network.
>>>>>>>>    The network entity is the key for adding/changing nics and IP
>>>>>>>>    address.
>>>>>>>> 2. In many occasions (such as small setups) the management
>>>>>>>> network is
>>>>>>>>    used as a VM/display network as well.
>>>>>>>>
>>>>>>>> Problems in current connectivity:
>>>>>>>> ================================
>>>>>>>> According to alonbl of ovirt-host-deploy fame, and with no
>>>>>>>> conflict
>>>>>>>> to
>>>>>>>> my own experience, creating the management network is the most
>>>>>>>> fragile,
>>>>>>>> error-prone step of bootstrap.
>>>>>>>
>>>>>>> +1,
>>>>>>> I've raise that repeatedly in the past, bootstrap should not create
>>>>>>> the management network but pick up the existing configuration and
>>>>>>> let the engine override later with it's own configuration if it
>>>>>>> differs , I'm glad that we finally get to that.
>>>>>>>
>>>>>>>>
>>>>>>>> Currently it always creates a bridged network (even if the DC
>>>>>>>> requires a
>>>>>>>> non-bridged ovirtmgmt), it knows nothing about the defined MTU
>>>>>>>> for
>>>>>>>> ovirtmgmt, it uses ping to guess on top of which device to build
>>>>>>>> (and
>>>>>>>> thus requires Vdsm-to-Engine reverse connectivity), and is the
>>>>>>>> sole
>>>>>>>> remaining user of the addNetwork/vdsm-store-net-conf scripts.
>>>>>>>>
>>>>>>>> Suggested feature:
>>>>>>>> ==================
>>>>>>>> Bootstrap would avoid creating a management network. Instead,
>>>>>>>> after
>>>>>>>> bootstrapping a host, Engine would send a getVdsCaps probe to the
>>>>>>>> installed host, receiving a complete picture of the network
>>>>>>>> configuration on the host. Among this picture is the device that
>>>>>>>> holds
>>>>>>>> the host's management IP address.
>>>>>>>>
>>>>>>>> Engine would send setupNetwork command to generate ovirtmgmt with
>>>>>>>> details devised from this picture, and according to the DC
>>>>>>>> definition
>>>>>>>> of
>>>>>>>> ovirtmgmt.  For example, if Vdsm reports:
>>>>>>>>
>>>>>>>> - vlan bond4.3000 has the host's IP, configured to use dhcp.
>>>>>>>> - bond4 is comprises eth2 and eth3
>>>>>>>> - ovirtmgmt is defined as a VM network with MTU 9000
>>>>>>>>
>>>>>>>> then Engine sends the likes of:
>>>>>>>>   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
>>>>>>>>                 bonding=bond4: {eth2,eth3}, MTU=9000)
>>>>>>>
>>>>>>> Just one comment here,
>>>>>>> In order to save time and confusion - if the ovirtmgmt is defined
>>>>>>> with default values meaning the user did not bother to touch it,
>>>>>>> let it pick up the VLAN configuration from the first host added in
>>>>>>> the Data Center.
>>>>>>>
>>>>>>> Otherwise, you may override the host VLAN and loose connectivity.
>>>>>>>
>>>>>>> This will also solve the situation many users encounter today.
>>>>>>> 1. The engine in on a host that actually has VLAN defined
>>>>>>> 2. The ovirtmgmt network was not updated in the DC
>>>>>>> 3. A host, with VLAN already defined is added - everything works
>>>>>>> fine
>>>>>>> 4. Any number of hosts are now added, again everything seems to
>>>>>>> work fine.
>>>>>>>
>>>>>>> But, now try to use setupNetworks, and you'll find out that you
>>>>>>> can't do much on the interface that contains the ovirtmgmt since
>>>>>>> the definition does not match. You can't sync (Since this will
>>>>>>> remove the VLAN and cause connectivity lose) you can't add more
>>>>>>> networks on top since it already has non-VLAN network on top
>>>>>>> according to the DC definition, etc.
>>>>>>>
>>>>>>> On the other hand you can't update the ovirtmgmt definition on the
>>>>>>> DC since there are clusters in the DC that use the network.
>>>>>>>
>>>>>>> The only workaround not involving DB hack to change the VLAN on the
>>>>>>> network is to:
>>>>>>> 1. Create new DC
>>>>>>> 2. Do not use the wizard that pops up to create your cluster.
>>>>>>> 3. Modify the ovirtmgmt network to have VLANs
>>>>>>> 4. Now create a cluster and add your hosts.
>>>>>>>
>>>>>>> If you insist on using the default DC and cluster then before
>>>>>>> adding the first host, create an additional DC and move the
>>>>>>> Default cluster over there. You may then change the network on the
>>>>>>> Default cluster and then move the Default cluster back
>>>>>>>
>>>>>>> Both are ugly. And should be solved by the proposal above.
>>>>>>>
>>>>>>> We do something similar for the Default cluster CPU level, where we
>>>>>>> set the intial level based on the first host added to the cluster.
>>>>>>
>>>>>> I'm not sure what Engine has for Default cluster CPU level. But I
>>>>>> have
>>>>>> reservation of the hysteresis in your proposal - after a host is
>>>>>> added,
>>>>>> the DC cannot forget ovirtmgmt's vlan.
>>>>>>
>>>>>> How about letting the admin edit ovirtmgmt's vlan in the DC level,
>>>>>> thus
>>>>>> rendering all hosts out-of-sync. The the admin could manually, or
>>>>>> through a script, or in the future through a distributed operation,
>>>>>> sync
>>>>>> all the hosts to the definition?
>>>>>
>>>>> Usually if you do that you will loose connectivity to the hosts.
>>>>
>>>> Yes, changing the management vlan id (or ip address) is never fun, and
>>>> requires out-of-band intervention.
>>>>
>>>>> I'm not insisting on the automatic adjustment of the ovirtmgmt network to
>>>>> match the hosts' (that is just a nice touch) we can take the allow edit
>>>>> approach.
>>>>>
>>>>> But allow to change VLAN on the ovirtmgmt network will indeed solve the
>>>>> issue I'm trying to solve while creating another issue of user expecting
>>>>> that we'll be able to re-tag the host from the engine side, which is
>>>>> challenging to do.
>>>>>
>>>>> On the other hand, if we allow to change the VLAN as long as the change
>>>>> matches the hosts' configuration, it will both solve the issue while not
>>>>> eluding the user to think that we really can solve the chicken and egg
>>>>> issue of re-tag the entire system.
>>>>>
>>>>> Now with the above ability you do get a flow to do the re-tag.
>>>>> 1. Place all the hosts in maintenance
>>>>> 2. Re-tag the ovirtmgmt on all the hosts
>>>>> 3. Re-tag the hosts on which the engine on
>>>>> 4. Activate the hosts - this should work well now since connectivity
>>>>> exist
>>>>> 5. Change the tag on ovirtmgmt on the engine to match the hosts'
>>>>>
>>>>> Simple and clear process.
>>>>>
>>>>> When the workaround of creating another DC was not possible since the
>>>>> system was already long in use and the need was re-tag of the network the
>>>>> above is what I've recommended in the, except that steps 4-5 where done
>>>>> as:
>>>>> 4. Stop the engine
>>>>> 5. Change the tag in the DB
>>>>> 6. Start the engine
>>>>> 7. Activate the hosts
>>>>
>>>> Sounds reasonable to me - but as far as I am aware this is not tightly
>>>> related to the $Subject, which is the post-boot ovirtmgmt definition.
>>>>
>>>> I've added a few details to
>>>> http://www.ovirt.org/Features/Normalized_ovirtmgmt_Initialization#Engine
>>>> and I would apreciate a review from someone with intimate Engine
>>>> know-how.
>>>>
>>>> Dan.
>>>>
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>
>>>
>>
>>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 
> 



From lpeer at redhat.com  Sun May 12 08:46:46 2013
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 12 May 2013 11:46:46 +0300
Subject: feature suggestion: initial generation of management network
In-Reply-To: <1435740579.270682.1368347145591.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<518F3DBB.6080606@redhat.com>
	<557908336.127528.1368346520205.JavaMail.root@redhat.com>
	<1435740579.270682.1368347145591.JavaMail.root@redhat.com>
Message-ID: <518F56F6.4080405@redhat.com>

On 05/12/2013 11:25 AM, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
>> From: "Barak Azulay" <bazulay at redhat.com>
>> To: "Livnat Peer" <lpeer at redhat.com>
>> Cc: "Alon Bar-Lev" <abarlev at redhat.com>, "arch" <arch at ovirt.org>, "Simon Grinberg" <sgrinber at redhat.com>
>> Sent: Sunday, May 12, 2013 11:15:20 AM
>> Subject: Re: feature suggestion: initial generation of management network
>>
>>
>>
>> ----- Original Message -----
>>> From: "Livnat Peer" <lpeer at redhat.com>
>>> To: "Moti Asayag" <masayag at redhat.com>
>>> Cc: "arch" <arch at ovirt.org>, "Alon Bar-Lev" <abarlev at redhat.com>, "Barak
>>> Azulay" <bazulay at redhat.com>, "Simon
>>> Grinberg" <sgrinber at redhat.com>
>>> Sent: Sunday, May 12, 2013 9:59:07 AM
>>> Subject: Re: feature suggestion: initial generation of management network
>>>
>>> Thread Summary -
>>>
>>> 1. We all agree the automatic reboot after host installation is not
>>> needed anymore and can be removed.
>>>
>>> 2. There is a vast agreement that we need to add a new VDSM verb for
>>> reboot.
>>
>> I disagree with the above
>>
>> In addition to the fact that it will not work when VDSM is not responsive
>> (when this action will be needed the most)
> 
> If vdsm is unresponsive because of a fault in vdsm we can add a fail safe mechanism for critical commands within vdsm.
> And we can always fallback to the standard fencing in such cases.
> 
> Can you please describe the scenario of which host-deploy succeeds and vdsm is unresponsive?
> 
> Current sequence:
> 1. host-deploy + reboot - all via single ssh session.
> 
> New sequence:
> 1. host-deploy - via ssh.
> 2. network setup - via vdsm.
> 3. optional reboot - via vdsm.
> 
> In the new sequence, vdsm must be responsive to accomplish (2), and if (2) succeeds vdsm, again, must be responsive.
> 


+1, fully agree with the above.

> Thanks!
> 
>>
>>
>>>
>>> 3. There was a suggestion to add a checkbox when adding a host to reboot
>>> the host after installation, default would be not to reboot. (leaving
>>> the option to reboot to the administrator).
>>>
>>>
>>> If there is no objection we'll go with the above.
>>>
>>> Thanks, Livnat
>>>
>>>
>>> On 05/07/2013 02:22 PM, Moti Asayag wrote:
>>>> I stumbled upon few issues with the current design while implementing it:
>>>>
>>>> There seems to be a requirement to reboot the host after the installation
>>>> is completed in order to assure the host is recoverable.
>>>>
>>>> Therefore, the building blocks of the installation process of 3.3 are:
>>>> 1. host deploy which installs the host expect configuring its management
>>>> network.
>>>> 2. SetupNetwork (and CommitNetworkChanges) - for creating the management
>>>> network
>>>> on the host and persisting the network configuration.
>>>> 3. Reboot the host - This is a missing piece. (engine has FenceVds
>>>> command,
>>>> but it
>>>> requires the power management to be configured prior to the installation
>>>> and might
>>>> be irrelevant for hosts without PM.)
>>>>
>>>> So, there are couple of issues here:
>>>> 1. How to reboot the host?
>>>> 1.1. By exposing new RebootNode verb in VDSM and invoking it from the
>>>> engine
>>>> 1.2. By opening ssh dialog to the host in order to execute the reboot
>>>>
>>>> 2. When to perform the reboot?
>>>> 2.1. After host deploy, by utilizing the host deploy to perform the
>>>> reboot.
>>>> It requires to configure the network by the monitor when the host is
>>>> detected by the engine,
>>>> detached from the installation flow. However it is a step toward the
>>>> non-persistent network feature
>>>> yet to be defined.
>>>> 2.2. After setupNetwork is done and network was configured and persisted
>>>> on
>>>> the host.
>>>> There is no special advantage from recoverable aspect, as setupNetwork is
>>>> constantly
>>>> used to persist the network configuration (by the complementary
>>>> CommitNetworkChanges command).
>>>> In case and network configuration fails, VDSM will revert to the last
>>>> well
>>>> known configuration
>>>> - so connectivity with engine should be restored. Design wise, it fits to
>>>> configure the management
>>>>  network as part of the installation sequence.
>>>> If the network configuration fails in this context, the host status will
>>>> be
>>>> set to "InstallFailed" rather than "NonOperational",
>>>> as might occur as a result of a failed setupNetwork command.
>>>>
>>>>
>>>> Your inputs are welcome.
>>>>
>>>> Thanks,
>>>> Moti
>>>> ----- Original Message -----
>>>>> From: "Dan Kenigsberg" <danken at redhat.com>
>>>>> To: "Simon Grinberg" <simon at redhat.com>, "Moti Asayag"
>>>>> <masayag at redhat.com>
>>>>> Cc: "arch" <arch at ovirt.org>
>>>>> Sent: Tuesday, January 1, 2013 2:47:57 PM
>>>>> Subject: Re: feature suggestion: initial generation of management
>>>>> network
>>>>>
>>>>> On Thu, Dec 27, 2012 at 07:36:40AM -0500, Simon Grinberg wrote:
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Dan Kenigsberg" <danken at redhat.com>
>>>>>>> To: "Simon Grinberg" <simon at redhat.com>
>>>>>>> Cc: "arch" <arch at ovirt.org>
>>>>>>> Sent: Thursday, December 27, 2012 2:14:06 PM
>>>>>>> Subject: Re: feature suggestion: initial generation of management
>>>>>>> network
>>>>>>>
>>>>>>> On Tue, Dec 25, 2012 at 09:29:26AM -0500, Simon Grinberg wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Dan Kenigsberg" <danken at redhat.com>
>>>>>>>>> To: "arch" <arch at ovirt.org>
>>>>>>>>> Sent: Tuesday, December 25, 2012 2:27:22 PM
>>>>>>>>> Subject: feature suggestion: initial generation of management
>>>>>>>>> network
>>>>>>>>>
>>>>>>>>> Current condition:
>>>>>>>>> ==================
>>>>>>>>> The management network, named ovirtmgmt, is created during host
>>>>>>>>> bootstrap. It consists of a bridge device, connected to the
>>>>>>>>> network
>>>>>>>>> device that was used to communicate with Engine (nic, bonding or
>>>>>>>>> vlan).
>>>>>>>>> It inherits its ip settings from the latter device.
>>>>>>>>>
>>>>>>>>> Why Is the Management Network Needed?
>>>>>>>>> =====================================
>>>>>>>>> Understandably, some may ask why do we need to have a management
>>>>>>>>> network - why having a host with IPv4 configured on it is not
>>>>>>>>> enough.
>>>>>>>>> The answer is twofold:
>>>>>>>>> 1. In oVirt, a network is an abstraction of the resources
>>>>>>>>> required
>>>>>>>>> for
>>>>>>>>>    connectivity of a host for a specific usage. This is true for
>>>>>>>>>    the
>>>>>>>>>    management network just as it is for VM network or a display
>>>>>>>>>    network.
>>>>>>>>>    The network entity is the key for adding/changing nics and IP
>>>>>>>>>    address.
>>>>>>>>> 2. In many occasions (such as small setups) the management
>>>>>>>>> network is
>>>>>>>>>    used as a VM/display network as well.
>>>>>>>>>
>>>>>>>>> Problems in current connectivity:
>>>>>>>>> ================================
>>>>>>>>> According to alonbl of ovirt-host-deploy fame, and with no
>>>>>>>>> conflict
>>>>>>>>> to
>>>>>>>>> my own experience, creating the management network is the most
>>>>>>>>> fragile,
>>>>>>>>> error-prone step of bootstrap.
>>>>>>>>
>>>>>>>> +1,
>>>>>>>> I've raise that repeatedly in the past, bootstrap should not create
>>>>>>>> the management network but pick up the existing configuration and
>>>>>>>> let the engine override later with it's own configuration if it
>>>>>>>> differs , I'm glad that we finally get to that.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Currently it always creates a bridged network (even if the DC
>>>>>>>>> requires a
>>>>>>>>> non-bridged ovirtmgmt), it knows nothing about the defined MTU
>>>>>>>>> for
>>>>>>>>> ovirtmgmt, it uses ping to guess on top of which device to build
>>>>>>>>> (and
>>>>>>>>> thus requires Vdsm-to-Engine reverse connectivity), and is the
>>>>>>>>> sole
>>>>>>>>> remaining user of the addNetwork/vdsm-store-net-conf scripts.
>>>>>>>>>
>>>>>>>>> Suggested feature:
>>>>>>>>> ==================
>>>>>>>>> Bootstrap would avoid creating a management network. Instead,
>>>>>>>>> after
>>>>>>>>> bootstrapping a host, Engine would send a getVdsCaps probe to the
>>>>>>>>> installed host, receiving a complete picture of the network
>>>>>>>>> configuration on the host. Among this picture is the device that
>>>>>>>>> holds
>>>>>>>>> the host's management IP address.
>>>>>>>>>
>>>>>>>>> Engine would send setupNetwork command to generate ovirtmgmt with
>>>>>>>>> details devised from this picture, and according to the DC
>>>>>>>>> definition
>>>>>>>>> of
>>>>>>>>> ovirtmgmt.  For example, if Vdsm reports:
>>>>>>>>>
>>>>>>>>> - vlan bond4.3000 has the host's IP, configured to use dhcp.
>>>>>>>>> - bond4 is comprises eth2 and eth3
>>>>>>>>> - ovirtmgmt is defined as a VM network with MTU 9000
>>>>>>>>>
>>>>>>>>> then Engine sends the likes of:
>>>>>>>>>   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
>>>>>>>>>                 bonding=bond4: {eth2,eth3}, MTU=9000)
>>>>>>>>
>>>>>>>> Just one comment here,
>>>>>>>> In order to save time and confusion - if the ovirtmgmt is defined
>>>>>>>> with default values meaning the user did not bother to touch it,
>>>>>>>> let it pick up the VLAN configuration from the first host added in
>>>>>>>> the Data Center.
>>>>>>>>
>>>>>>>> Otherwise, you may override the host VLAN and loose connectivity.
>>>>>>>>
>>>>>>>> This will also solve the situation many users encounter today.
>>>>>>>> 1. The engine in on a host that actually has VLAN defined
>>>>>>>> 2. The ovirtmgmt network was not updated in the DC
>>>>>>>> 3. A host, with VLAN already defined is added - everything works
>>>>>>>> fine
>>>>>>>> 4. Any number of hosts are now added, again everything seems to
>>>>>>>> work fine.
>>>>>>>>
>>>>>>>> But, now try to use setupNetworks, and you'll find out that you
>>>>>>>> can't do much on the interface that contains the ovirtmgmt since
>>>>>>>> the definition does not match. You can't sync (Since this will
>>>>>>>> remove the VLAN and cause connectivity lose) you can't add more
>>>>>>>> networks on top since it already has non-VLAN network on top
>>>>>>>> according to the DC definition, etc.
>>>>>>>>
>>>>>>>> On the other hand you can't update the ovirtmgmt definition on the
>>>>>>>> DC since there are clusters in the DC that use the network.
>>>>>>>>
>>>>>>>> The only workaround not involving DB hack to change the VLAN on the
>>>>>>>> network is to:
>>>>>>>> 1. Create new DC
>>>>>>>> 2. Do not use the wizard that pops up to create your cluster.
>>>>>>>> 3. Modify the ovirtmgmt network to have VLANs
>>>>>>>> 4. Now create a cluster and add your hosts.
>>>>>>>>
>>>>>>>> If you insist on using the default DC and cluster then before
>>>>>>>> adding the first host, create an additional DC and move the
>>>>>>>> Default cluster over there. You may then change the network on the
>>>>>>>> Default cluster and then move the Default cluster back
>>>>>>>>
>>>>>>>> Both are ugly. And should be solved by the proposal above.
>>>>>>>>
>>>>>>>> We do something similar for the Default cluster CPU level, where we
>>>>>>>> set the intial level based on the first host added to the cluster.
>>>>>>>
>>>>>>> I'm not sure what Engine has for Default cluster CPU level. But I
>>>>>>> have
>>>>>>> reservation of the hysteresis in your proposal - after a host is
>>>>>>> added,
>>>>>>> the DC cannot forget ovirtmgmt's vlan.
>>>>>>>
>>>>>>> How about letting the admin edit ovirtmgmt's vlan in the DC level,
>>>>>>> thus
>>>>>>> rendering all hosts out-of-sync. The the admin could manually, or
>>>>>>> through a script, or in the future through a distributed operation,
>>>>>>> sync
>>>>>>> all the hosts to the definition?
>>>>>>
>>>>>> Usually if you do that you will loose connectivity to the hosts.
>>>>>
>>>>> Yes, changing the management vlan id (or ip address) is never fun, and
>>>>> requires out-of-band intervention.
>>>>>
>>>>>> I'm not insisting on the automatic adjustment of the ovirtmgmt network
>>>>>> to
>>>>>> match the hosts' (that is just a nice touch) we can take the allow edit
>>>>>> approach.
>>>>>>
>>>>>> But allow to change VLAN on the ovirtmgmt network will indeed solve the
>>>>>> issue I'm trying to solve while creating another issue of user
>>>>>> expecting
>>>>>> that we'll be able to re-tag the host from the engine side, which is
>>>>>> challenging to do.
>>>>>>
>>>>>> On the other hand, if we allow to change the VLAN as long as the change
>>>>>> matches the hosts' configuration, it will both solve the issue while
>>>>>> not
>>>>>> eluding the user to think that we really can solve the chicken and egg
>>>>>> issue of re-tag the entire system.
>>>>>>
>>>>>> Now with the above ability you do get a flow to do the re-tag.
>>>>>> 1. Place all the hosts in maintenance
>>>>>> 2. Re-tag the ovirtmgmt on all the hosts
>>>>>> 3. Re-tag the hosts on which the engine on
>>>>>> 4. Activate the hosts - this should work well now since connectivity
>>>>>> exist
>>>>>> 5. Change the tag on ovirtmgmt on the engine to match the hosts'
>>>>>>
>>>>>> Simple and clear process.
>>>>>>
>>>>>> When the workaround of creating another DC was not possible since the
>>>>>> system was already long in use and the need was re-tag of the network
>>>>>> the
>>>>>> above is what I've recommended in the, except that steps 4-5 where done
>>>>>> as:
>>>>>> 4. Stop the engine
>>>>>> 5. Change the tag in the DB
>>>>>> 6. Start the engine
>>>>>> 7. Activate the hosts
>>>>>
>>>>> Sounds reasonable to me - but as far as I am aware this is not tightly
>>>>> related to the $Subject, which is the post-boot ovirtmgmt definition.
>>>>>
>>>>> I've added a few details to
>>>>> http://www.ovirt.org/Features/Normalized_ovirtmgmt_Initialization#Engine
>>>>> and I would apreciate a review from someone with intimate Engine
>>>>> know-how.
>>>>>
>>>>> Dan.
>>>>>
>>>> _______________________________________________
>>>> Arch mailing list
>>>> Arch at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>>
>>>>
>>>
>>>
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>



From alonbl at redhat.com  Sun May 12 11:52:51 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 12 May 2013 07:52:51 -0400 (EDT)
Subject: [ANN] New development environment for ovirt-engine
In-Reply-To: <1534961780.272884.1368354892411.JavaMail.root@redhat.com>
Message-ID: <9423451.273926.1368359571790.JavaMail.root@redhat.com>

Hello all ovirt-engine developers,

When I first joined the ovirt project, it took me about two weeks to setup a development environment, I needed to work on a bug related to host-deploy so I needed an environment that could use the ssh, PKI, vdsm-bootstrap and communicate with vdsm using SSL, this was virtually impossible to do so without tweaking the product in a way that it is so different from production use, that I cannot guarantee that whatever tested in development will actually work in production.

I peeked at the installation script in a hope that I can create partial environment similar to production, but I found that the packaging implementation makes to much assumption and is very difficult to adopt. The fact that I do not use fedora/rhel for my development made it even worse.

I had no other option than to create rpms after each of my changes and test each in real production like setup.

It was obvious to me that the manual customization of developers to achieve working product will eventually break as product grow and move away from being developer friendly to production friendly. For example, product defaults cannot be these which serve developers, but these which serve production the best, or having a valid PKI setup cannot be optional any more as components do need to use it. Same for location of files and configuration, for example, if we write a pluggable infrastructure for branding, we cannot damage the interface just because developers runs the product in their own manual customization.

I took the opportunity handed to me to port the ovirt-engine to other distributions in order to provide a development environment that is similar to production setup. Together with Sandro Bonazzola and Alex Lourie we re-wrote the whole installation of the product which can also be used to setup the desired development environment.

Within this environment the product is set up using the same tools and configuration as in production, while the process does not require special privileges nor changes the state of the developer machine. 

A complete documentation is available[1], I preferred to use README within the source tree as wiki tend to quickly become obsolete, while documentation within source tree can be modified by the commit that introduces a change. I will redirect to this file from the current wiki once the site will be up.

In a nut shell, after installing prerequisites, build and install the product using:

$ make clean install-dev PREFIX=$HOME/ovirt-engine

This will run maven and create product installation at $HOME/ovirt-engine
Next, a setup phase is required just like in production, to initialize configuration and database:

$ $HOME/ovirt-engine/bin/engine-setup-2

You have now fully functional product, including PKI, SSL, host-deploy, tools.
No manual database updates are required, no lose of functionality.

All that is left is to start the engine service:

$ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start

Access to application:
   http://localhost:8080
   https://localhost:8443
Debugging port is opened at port 8787.

Farther information exists in the documentation[1].

There are several inherit benefits of the new environment, the major one is the ability to manage several environments in parallel on the same host. For example, if we develop two separate features on two branches we can install the product into $HOME/ovirt-engine-feature1 and $HOME/ovirt-engine-feature-2 and have a separate database for each, if we modify the ports jboss is listening to we can run two instances of engine at the same time!

We will be happy to work with all developers to assist in porting into the new development environment, the simplest is to create a new database for this effort. Moti has a sequence of converting the existing database owned by postgres to be owned by the engine, Moti, can you please share that?

We are sure there are missing bits, we will be happy to know these so we can improve.

I am aware that developers (especially java) are conservative, but I ask you to give us a chance, so that we make it easy for developers to join the project, and to allow us to drop the parallel effort of packaging to production and fixing the broken development environment. 

A special thanks to developers who took the time to test and provide feedback before the merged:
- Yaniv Bronheim
- Moti Asayag
- Limor Gavish
- Sharad Mishra
- Ofer Schreiber

We are hoping that after migration you will be find this environment useful and friendly,

Sandro Bonazzola,
Alex Lourie,
Alon Bar-Lev.

[1] http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD


From danken at redhat.com  Sun May 12 12:39:54 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Sun, 12 May 2013 15:39:54 +0300
Subject: feature suggestion: initial generation of management network
In-Reply-To: <941280855.5773599.1368111436878.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<497587874.11990711.1367932265918.JavaMail.root@redhat.com>
	<1596048609.8203468.1367933507824.JavaMail.root@redhat.com>
	<20130508133549.GA17279@redhat.com>
	<1556816649.5772576.1368111300185.JavaMail.root@redhat.com>
	<941280855.5773599.1368111436878.JavaMail.root@redhat.com>
Message-ID: <20130512123954.GF26216@redhat.com>

On Thu, May 09, 2013 at 10:57:16AM -0400, Antoni Segura Puimedon wrote:
> > 
> > The risk of a deployed system (without bridge) to be unresponsive after
> > reboot is minimum.
> > 
> > 1. iptables rules are already active.
> > 2. udev rules are active.
> > 3. vdsm is up.
> > 
> > The major risk is basically if some dependency package was UPDATED during the
> > installation of vdsm, while its service/consumer is already running, then we
> > are running a host with the old software and there is a chance that after
> > reboot with the new software the host will fail.
> > 
> > I think that the decision to reboot host should be delegated to
> > administrator, adding vdsm verb to reboot is usable. This way admin will be
> > able to take a host to maintenance mode and reboot, and we can add checkbox
> > to the add host dialog '[x] reboot', rebooting the host at the end of the
> > sequence. I think the default should be off.
> 
> I'm also in agreement with the addition of a reboot verb. It could be a nice
> addition regardless of this specific use case.

A "reboot" verb is nice, but I am not yet sure that it is actually
needed. Above, Alon give one argument for it - to make sure that vdsm
(and its dependencies, and other updated packages) works smoothely after
boot. That's a good argument - but it may be acheived by post-deploy
boot as done today - without an additional frighteningly-named verb.

Note that vdsm, or any other package, may be upgraded by yum
asynchronous to Engine's operation, so we may face a surprise
cannot-start-after-boot later in the host life cycle. Not only
post-install.

As I said in my first comment to this thread - I do not think that
reboot-after-install is desperately needed, and find that it does not
deserve the Engine-side complexity of calling a new verb.

Dan.



From alonbl at redhat.com  Sun May 12 12:58:53 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 12 May 2013 08:58:53 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <20130512123954.GF26216@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<497587874.11990711.1367932265918.JavaMail.root@redhat.com>
	<1596048609.8203468.1367933507824.JavaMail.root@redhat.com>
	<20130508133549.GA17279@redhat.com>
	<1556816649.5772576.1368111300185.JavaMail.root@redhat.com>
	<941280855.5773599.1368111436878.JavaMail.root@redhat.com>
	<20130512123954.GF26216@redhat.com>
Message-ID: <2047117021.311691.1368363533872.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Antoni Segura Puimedon" <asegurap at redhat.com>
> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "arch" <arch at ovirt.org>
> Sent: Sunday, May 12, 2013 3:39:54 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> On Thu, May 09, 2013 at 10:57:16AM -0400, Antoni Segura Puimedon wrote:
> > > 
> > > The risk of a deployed system (without bridge) to be unresponsive after
> > > reboot is minimum.
> > > 
> > > 1. iptables rules are already active.
> > > 2. udev rules are active.
> > > 3. vdsm is up.
> > > 
> > > The major risk is basically if some dependency package was UPDATED during
> > > the
> > > installation of vdsm, while its service/consumer is already running, then
> > > we
> > > are running a host with the old software and there is a chance that after
> > > reboot with the new software the host will fail.
> > > 
> > > I think that the decision to reboot host should be delegated to
> > > administrator, adding vdsm verb to reboot is usable. This way admin will
> > > be
> > > able to take a host to maintenance mode and reboot, and we can add
> > > checkbox
> > > to the add host dialog '[x] reboot', rebooting the host at the end of the
> > > sequence. I think the default should be off.
> > 
> > I'm also in agreement with the addition of a reboot verb. It could be a
> > nice
> > addition regardless of this specific use case.
> 
> A "reboot" verb is nice, but I am not yet sure that it is actually
> needed. Above, Alon give one argument for it - to make sure that vdsm
> (and its dependencies, and other updated packages) works smoothely after
> boot. That's a good argument - but it may be acheived by post-deploy
> boot as done today - without an additional frighteningly-named verb.
> 
> Note that vdsm, or any other package, may be upgraded by yum
> asynchronous to Engine's operation, so we may face a surprise
> cannot-start-after-boot later in the host life cycle. Not only
> post-install.
> 
> As I said in my first comment to this thread - I do not think that
> reboot-after-install is desperately needed, and find that it does not
> deserve the Engine-side complexity of calling a new verb.
> 
> Dan.

What we are trying to say, product wise, is that the requirement to remotely reboot a host (cooperate reboot) may be available regardless of the host-deploy sequence. Administrator may decide to reboot a host right after host-deploy or once a week.

Adding the ability to perform reboot is different independent discussion.

The only reason we discuss it here is because we currently force reboot after host-deploy (although in the API it is optional).

Having the bridge created by the engine is, in my opinion, far more important than keeping the reboot feature. We can discuss if remote reboot feature should and to which version, regardless.

Regards,
Alon


From bazulay at redhat.com  Sun May 12 18:27:01 2013
From: bazulay at redhat.com (Barak Azulay)
Date: Sun, 12 May 2013 14:27:01 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <2047117021.311691.1368363533872.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<497587874.11990711.1367932265918.JavaMail.root@redhat.com>
	<1596048609.8203468.1367933507824.JavaMail.root@redhat.com>
	<20130508133549.GA17279@redhat.com>
	<1556816649.5772576.1368111300185.JavaMail.root@redhat.com>
	<941280855.5773599.1368111436878.JavaMail.root@redhat.com>
	<20130512123954.GF26216@redhat.com>
	<2047117021.311691.1368363533872.JavaMail.root@redhat.com>
Message-ID: <1837929436.302264.1368383221970.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Sunday, May 12, 2013 3:58:53 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> 
> 
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Antoni Segura Puimedon" <asegurap at redhat.com>
> > Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "arch" <arch at ovirt.org>
> > Sent: Sunday, May 12, 2013 3:39:54 PM
> > Subject: Re: feature suggestion: initial generation of management network
> > 
> > On Thu, May 09, 2013 at 10:57:16AM -0400, Antoni Segura Puimedon wrote:
> > > > 
> > > > The risk of a deployed system (without bridge) to be unresponsive after
> > > > reboot is minimum.
> > > > 
> > > > 1. iptables rules are already active.
> > > > 2. udev rules are active.
> > > > 3. vdsm is up.
> > > > 
> > > > The major risk is basically if some dependency package was UPDATED
> > > > during
> > > > the
> > > > installation of vdsm, while its service/consumer is already running,
> > > > then
> > > > we
> > > > are running a host with the old software and there is a chance that
> > > > after
> > > > reboot with the new software the host will fail.
> > > > 
> > > > I think that the decision to reboot host should be delegated to
> > > > administrator, adding vdsm verb to reboot is usable. This way admin
> > > > will
> > > > be
> > > > able to take a host to maintenance mode and reboot, and we can add
> > > > checkbox
> > > > to the add host dialog '[x] reboot', rebooting the host at the end of
> > > > the
> > > > sequence. I think the default should be off.
> > > 
> > > I'm also in agreement with the addition of a reboot verb. It could be a
> > > nice
> > > addition regardless of this specific use case.
> > 
> > A "reboot" verb is nice, but I am not yet sure that it is actually
> > needed. Above, Alon give one argument for it - to make sure that vdsm
> > (and its dependencies, and other updated packages) works smoothely after
> > boot. That's a good argument - but it may be acheived by post-deploy
> > boot as done today - without an additional frighteningly-named verb.
> > 
> > Note that vdsm, or any other package, may be upgraded by yum
> > asynchronous to Engine's operation, so we may face a surprise
> > cannot-start-after-boot later in the host life cycle. Not only
> > post-install.
> > 
> > As I said in my first comment to this thread - I do not think that
> > reboot-after-install is desperately needed, and find that it does not
> > deserve the Engine-side complexity of calling a new verb.
> > 
> > Dan.
> 
> What we are trying to say, product wise, is that the requirement to remotely
> reboot a host 


(cooperate reboot) may be available regardless of the
> host-deploy sequence. Administrator may decide to reboot a host right after
> host-deploy or once a week.




> 
> Adding the ability to perform reboot is different independent discussion.
> 
> The only reason we discuss it here is because we currently force reboot after
> host-deploy (although in the API it is optional).
> 
> Having the bridge created by the engine is, in my opinion, far more important
> than keeping the reboot feature. We can discuss if remote reboot feature
> should and to which version, regardless.
> 
> Regards,
> Alon
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 
> 
> 


From bazulay at redhat.com  Sun May 12 18:40:41 2013
From: bazulay at redhat.com (Barak Azulay)
Date: Sun, 12 May 2013 14:40:41 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <2047117021.311691.1368363533872.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<497587874.11990711.1367932265918.JavaMail.root@redhat.com>
	<1596048609.8203468.1367933507824.JavaMail.root@redhat.com>
	<20130508133549.GA17279@redhat.com>
	<1556816649.5772576.1368111300185.JavaMail.root@redhat.com>
	<941280855.5773599.1368111436878.JavaMail.root@redhat.com>
	<20130512123954.GF26216@redhat.com>
	<2047117021.311691.1368363533872.JavaMail.root@redhat.com>
Message-ID: <239113646.302830.1368384041645.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Sunday, May 12, 2013 3:58:53 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> 
> 
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Antoni Segura Puimedon" <asegurap at redhat.com>
> > Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "arch" <arch at ovirt.org>
> > Sent: Sunday, May 12, 2013 3:39:54 PM
> > Subject: Re: feature suggestion: initial generation of management network
> > 
> > On Thu, May 09, 2013 at 10:57:16AM -0400, Antoni Segura Puimedon wrote:
> > > > 
> > > > The risk of a deployed system (without bridge) to be unresponsive after
> > > > reboot is minimum.
> > > > 
> > > > 1. iptables rules are already active.
> > > > 2. udev rules are active.
> > > > 3. vdsm is up.
> > > > 
> > > > The major risk is basically if some dependency package was UPDATED
> > > > during
> > > > the
> > > > installation of vdsm, while its service/consumer is already running,
> > > > then
> > > > we
> > > > are running a host with the old software and there is a chance that
> > > > after
> > > > reboot with the new software the host will fail.
> > > > 
> > > > I think that the decision to reboot host should be delegated to
> > > > administrator, adding vdsm verb to reboot is usable. This way admin
> > > > will
> > > > be
> > > > able to take a host to maintenance mode and reboot, and we can add
> > > > checkbox
> > > > to the add host dialog '[x] reboot', rebooting the host at the end of
> > > > the
> > > > sequence. I think the default should be off.
> > > 
> > > I'm also in agreement with the addition of a reboot verb. It could be a
> > > nice
> > > addition regardless of this specific use case.
> > 
> > A "reboot" verb is nice, but I am not yet sure that it is actually
> > needed. Above, Alon give one argument for it - to make sure that vdsm
> > (and its dependencies, and other updated packages) works smoothely after
> > boot. That's a good argument - but it may be acheived by post-deploy
> > boot as done today - without an additional frighteningly-named verb.
> > 
> > Note that vdsm, or any other package, may be upgraded by yum
> > asynchronous to Engine's operation, so we may face a surprise
> > cannot-start-after-boot later in the host life cycle. Not only
> > post-install.
> > 
> > As I said in my first comment to this thread - I do not think that
> > reboot-after-install is desperately needed, and find that it does not
> > deserve the Engine-side complexity of calling a new verb.
> > 
> > Dan.
> 
> What we are trying to say, product wise, is that the requirement to remotely
> reboot a host 

No it is not a requirement - it is here because in the past it proved to be a necessity (on the early days),
i don't think it's a must today.

> (cooperate reboot) may be available regardless of the
> host-deploy sequence. Administrator may decide to reboot a host right after
> host-deploy or once a week.

Correct, and the right way to do it is first move to maintenance mode.

> 
> Adding the ability to perform reboot is different independent discussion.
> 
> The only reason we discuss it here is because we currently force reboot after
> host-deploy (although in the API it is optional).
> 
> Having the bridge created by the engine is, in my opinion, far more important
> than keeping the reboot feature. We can discuss if remote reboot feature
> should and to which version, regardless.


I agree with you that the creation of the bridge engine is more important from the reboot,
However when discussing new reboot API for VDSM, I prefer to not do reboot at all on host-deploy, and do the bridge config by engine.

The reboot API suggested is a general purpose API which in this discussion is focused around a specific use case (host-deploy),
If we had a way to enforce call for the reboot API only in the deployment scenario, I would have been o.k. with it,
But the weird thing about APIs is that people end up using them ... and not always as we intended, 
and we might end up finding ourselves in tough situations due to a stray reboot call from X ???

This is the reason I have suggested reboot over SSH which is different.

And I would argue that host deploy is here to stay hence the dependency in SSH is here to stay.


Thanks
Barak Azulay


   

> 
> Regards,
> Alon
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 
> 
> 


From alonbl at redhat.com  Sun May 12 18:59:22 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 12 May 2013 14:59:22 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <239113646.302830.1368384041645.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<1596048609.8203468.1367933507824.JavaMail.root@redhat.com>
	<20130508133549.GA17279@redhat.com>
	<1556816649.5772576.1368111300185.JavaMail.root@redhat.com>
	<941280855.5773599.1368111436878.JavaMail.root@redhat.com>
	<20130512123954.GF26216@redhat.com>
	<2047117021.311691.1368363533872.JavaMail.root@redhat.com>
	<239113646.302830.1368384041645.JavaMail.root@redhat.com>
Message-ID: <1212694039.320712.1368385162654.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Barak Azulay" <bazulay at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Dan Kenigsberg" <danken at redhat.com>, "arch" <arch at ovirt.org>
> Sent: Sunday, May 12, 2013 9:40:41 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Dan Kenigsberg" <danken at redhat.com>
> > Cc: "arch" <arch at ovirt.org>
> > Sent: Sunday, May 12, 2013 3:58:53 PM
> > Subject: Re: feature suggestion: initial generation of management network
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > To: "Antoni Segura Puimedon" <asegurap at redhat.com>
> > > Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "arch" <arch at ovirt.org>
> > > Sent: Sunday, May 12, 2013 3:39:54 PM
> > > Subject: Re: feature suggestion: initial generation of management network
> > > 
> > > On Thu, May 09, 2013 at 10:57:16AM -0400, Antoni Segura Puimedon wrote:
> > > > > 
> > > > > The risk of a deployed system (without bridge) to be unresponsive
> > > > > after
> > > > > reboot is minimum.
> > > > > 
> > > > > 1. iptables rules are already active.
> > > > > 2. udev rules are active.
> > > > > 3. vdsm is up.
> > > > > 
> > > > > The major risk is basically if some dependency package was UPDATED
> > > > > during
> > > > > the
> > > > > installation of vdsm, while its service/consumer is already running,
> > > > > then
> > > > > we
> > > > > are running a host with the old software and there is a chance that
> > > > > after
> > > > > reboot with the new software the host will fail.
> > > > > 
> > > > > I think that the decision to reboot host should be delegated to
> > > > > administrator, adding vdsm verb to reboot is usable. This way admin
> > > > > will
> > > > > be
> > > > > able to take a host to maintenance mode and reboot, and we can add
> > > > > checkbox
> > > > > to the add host dialog '[x] reboot', rebooting the host at the end of
> > > > > the
> > > > > sequence. I think the default should be off.
> > > > 
> > > > I'm also in agreement with the addition of a reboot verb. It could be a
> > > > nice
> > > > addition regardless of this specific use case.
> > > 
> > > A "reboot" verb is nice, but I am not yet sure that it is actually
> > > needed. Above, Alon give one argument for it - to make sure that vdsm
> > > (and its dependencies, and other updated packages) works smoothely after
> > > boot. That's a good argument - but it may be acheived by post-deploy
> > > boot as done today - without an additional frighteningly-named verb.
> > > 
> > > Note that vdsm, or any other package, may be upgraded by yum
> > > asynchronous to Engine's operation, so we may face a surprise
> > > cannot-start-after-boot later in the host life cycle. Not only
> > > post-install.
> > > 
> > > As I said in my first comment to this thread - I do not think that
> > > reboot-after-install is desperately needed, and find that it does not
> > > deserve the Engine-side complexity of calling a new verb.
> > > 
> > > Dan.
> > 
> > What we are trying to say, product wise, is that the requirement to
> > remotely
> > reboot a host
> 
> No it is not a requirement - it is here because in the past it proved to be a
> necessity (on the early days),
> i don't think it's a must today.
> 
> > (cooperate reboot) may be available regardless of the
> > host-deploy sequence. Administrator may decide to reboot a host right after
> > host-deploy or once a week.
> 
> Correct, and the right way to do it is first move to maintenance mode.
> 
> > 
> > Adding the ability to perform reboot is different independent discussion.
> > 
> > The only reason we discuss it here is because we currently force reboot
> > after
> > host-deploy (although in the API it is optional).
> > 
> > Having the bridge created by the engine is, in my opinion, far more
> > important
> > than keeping the reboot feature. We can discuss if remote reboot feature
> > should and to which version, regardless.
> 
> 
> I agree with you that the creation of the bridge engine is more important
> from the reboot,
> However when discussing new reboot API for VDSM, I prefer to not do reboot at
> all on host-deploy, and do the bridge config by engine.
> 
> The reboot API suggested is a general purpose API which in this discussion is
> focused around a specific use case (host-deploy),
> If we had a way to enforce call for the reboot API only in the deployment
> scenario, I would have been o.k. with it,
> But the weird thing about APIs is that people end up using them ... and not
> always as we intended,
> and we might end up finding ourselves in tough situations due to a stray
> reboot call from X ???

I must reply that, cannot help it... :)))
What if the admin just login to the server and just rebooted?
What if there is power failure?
What if there is provisioning infrastructure that manages the servers in parallel of ovirt and it decides to reboot?
We should deal with that in any case...
And doing this via VDSM has only advantages, as VDSM is aware of the reboot request and can take safety measures to complete it successfully without losing information nor state.

> This is the reason I have suggested reboot over SSH which is different.

Right, but we can do about 40% (I think closer to 80%) of VDSM functionality via SSH, right?

> And I would argue that host deploy is here to stay hence the dependency in
> SSH is here to stay.

There are talks to move to standard provisioning framework such as puppet or even foreman... not sure what the future is.

> 
> Thanks
> Barak Azulay
> 
> 
>    
> 
> > 
> > Regards,
> > Alon
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> > 
> > 
> 


From bazulay at redhat.com  Sun May 12 20:29:20 2013
From: bazulay at redhat.com (Barak Azulay)
Date: Sun, 12 May 2013 16:29:20 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <1212694039.320712.1368385162654.JavaMail.root@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<1596048609.8203468.1367933507824.JavaMail.root@redhat.com>
	<20130508133549.GA17279@redhat.com>
	<1556816649.5772576.1368111300185.JavaMail.root@redhat.com>
	<941280855.5773599.1368111436878.JavaMail.root@redhat.com>
	<20130512123954.GF26216@redhat.com>
	<2047117021.311691.1368363533872.JavaMail.root@redhat.com>
	<239113646.302830.1368384041645.JavaMail.root@redhat.com>
	<1212694039.320712.1368385162654.JavaMail.root@redhat.com>
Message-ID: <8B96DE8C-7C04-4E76-91C1-C518A9C9857B@redhat.com>





On May 12, 2013, at 21:59, Alon Bar-Lev <alonbl at redhat.com> wrote:

> 
> 
> ----- Original Message -----
>> From: "Barak Azulay" <bazulay at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Dan Kenigsberg" <danken at redhat.com>, "arch" <arch at ovirt.org>
>> Sent: Sunday, May 12, 2013 9:40:41 PM
>> Subject: Re: feature suggestion: initial generation of management network
>> 
>> 
>> 
>> ----- Original Message -----
>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>>> To: "Dan Kenigsberg" <danken at redhat.com>
>>> Cc: "arch" <arch at ovirt.org>
>>> Sent: Sunday, May 12, 2013 3:58:53 PM
>>> Subject: Re: feature suggestion: initial generation of management network
>>> 
>>> 
>>> 
>>> ----- Original Message -----
>>>> From: "Dan Kenigsberg" <danken at redhat.com>
>>>> To: "Antoni Segura Puimedon" <asegurap at redhat.com>
>>>> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "arch" <arch at ovirt.org>
>>>> Sent: Sunday, May 12, 2013 3:39:54 PM
>>>> Subject: Re: feature suggestion: initial generation of management network
>>>> 
>>>> On Thu, May 09, 2013 at 10:57:16AM -0400, Antoni Segura Puimedon wrote:
>>>>>> 
>>>>>> The risk of a deployed system (without bridge) to be unresponsive
>>>>>> after
>>>>>> reboot is minimum.
>>>>>> 
>>>>>> 1. iptables rules are already active.
>>>>>> 2. udev rules are active.
>>>>>> 3. vdsm is up.
>>>>>> 
>>>>>> The major risk is basically if some dependency package was UPDATED
>>>>>> during
>>>>>> the
>>>>>> installation of vdsm, while its service/consumer is already running,
>>>>>> then
>>>>>> we
>>>>>> are running a host with the old software and there is a chance that
>>>>>> after
>>>>>> reboot with the new software the host will fail.
>>>>>> 
>>>>>> I think that the decision to reboot host should be delegated to
>>>>>> administrator, adding vdsm verb to reboot is usable. This way admin
>>>>>> will
>>>>>> be
>>>>>> able to take a host to maintenance mode and reboot, and we can add
>>>>>> checkbox
>>>>>> to the add host dialog '[x] reboot', rebooting the host at the end of
>>>>>> the
>>>>>> sequence. I think the default should be off.
>>>>> 
>>>>> I'm also in agreement with the addition of a reboot verb. It could be a
>>>>> nice
>>>>> addition regardless of this specific use case.
>>>> 
>>>> A "reboot" verb is nice, but I am not yet sure that it is actually
>>>> needed. Above, Alon give one argument for it - to make sure that vdsm
>>>> (and its dependencies, and other updated packages) works smoothely after
>>>> boot. That's a good argument - but it may be acheived by post-deploy
>>>> boot as done today - without an additional frighteningly-named verb.
>>>> 
>>>> Note that vdsm, or any other package, may be upgraded by yum
>>>> asynchronous to Engine's operation, so we may face a surprise
>>>> cannot-start-after-boot later in the host life cycle. Not only
>>>> post-install.
>>>> 
>>>> As I said in my first comment to this thread - I do not think that
>>>> reboot-after-install is desperately needed, and find that it does not
>>>> deserve the Engine-side complexity of calling a new verb.
>>>> 
>>>> Dan.
>>> 
>>> What we are trying to say, product wise, is that the requirement to
>>> remotely
>>> reboot a host
>> 
>> No it is not a requirement - it is here because in the past it proved to be a
>> necessity (on the early days),
>> i don't think it's a must today.
>> 
>>> (cooperate reboot) may be available regardless of the
>>> host-deploy sequence. Administrator may decide to reboot a host right after
>>> host-deploy or once a week.
>> 
>> Correct, and the right way to do it is first move to maintenance mode.
>> 
>>> 
>>> Adding the ability to perform reboot is different independent discussion.
>>> 
>>> The only reason we discuss it here is because we currently force reboot
>>> after
>>> host-deploy (although in the API it is optional).
>>> 
>>> Having the bridge created by the engine is, in my opinion, far more
>>> important
>>> than keeping the reboot feature. We can discuss if remote reboot feature
>>> should and to which version, regardless.
>> 
>> 
>> I agree with you that the creation of the bridge engine is more important
>> from the reboot,
>> However when discussing new reboot API for VDSM, I prefer to not do reboot at
>> all on host-deploy, and do the bridge config by engine.
>> 
>> The reboot API suggested is a general purpose API which in this discussion is
>> focused around a specific use case (host-deploy),
>> If we had a way to enforce call for the reboot API only in the deployment
>> scenario, I would have been o.k. with it,



>> But the weird thing about APIs is that people end up using them ... and not
>> always as we intended,
>> and we might end up finding ourselves in tough situations due to a stray
>> reboot call from X ???
> 
> I must reply that, cannot help it... :)))

I know you can't ;-)


> What if the admin just login to the server and just rebooted?
> What if there is power failure?
> What if there is provisioning infrastructure that manages the servers in parallel of ovirt and it decides to reboot?
> We should deal with that in any case...
> And doing this via VDSM has only advantages, as VDSM is aware of the reboot request and can take safety measures to complete it successfully without losing information nor state.

As I said above, if we could limit the reboot API call for host deploy I was o.k with it.
Since we can't than it is likely that it will be used in some other flow, which might cause a mess.

It is one thing when an admin is doing it manually (and is aware he is loosing all the running VMs), and between having the engine call it in some other corner case flow (just because the API was there and it looked like he right thing when reviewed), and all running VMs die (just like case we have had with the lib virt crash .... Fencing race)

Eventually general purpose APIs are being used, And here you are arguing about the most destructive API in the context of a distant corner case.

I find it hard to believe such a patch will pass vdsm code review ... 


> 
>> This is the reason I have suggested reboot over SSH which is different.
> 
> Right, but we can do about 40% (I think closer to 80%) of VDSM functionality via SSH, right?

35 ? ;-)

> 
>> And I would argue that host deploy is here to stay hence the dependency in
>> SSH is here to stay.
> 
> There are talks to move to standard provisioning framework such as puppet or even foreman... not sure what the future is.


And who will install and provision those systems ? .... I assume Otopi ... Using SSH


> 
>> 
>> Thanks
>> Barak Azulay
>> 
>> 
>> 
>> 
>>> 
>>> Regards,
>>> Alon
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>> 
>>> 
>>> 
>> 


From alonbl at redhat.com  Sun May 12 21:12:33 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 12 May 2013 17:12:33 -0400 (EDT)
Subject: [ANN] New development environment for ovirt-engine
In-Reply-To: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
Message-ID: <1692979816.341418.1368393153722.JavaMail.root@redhat.com>

Hello,

As promised, I updated the wiki pages of engine developer environment to refer to this[1] single new page, I hope in time we can merge all non-trivial contributions into the README.developer.

Feel free to contribute/fix as you experience issues.

Regards,
Alon Bar-Lev.

[1] http://www.ovirt.org/OVirt_Engine_Development_Environment

----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Cc: "Yaniv Bronheim" <ybronhei at redhat.com>, "Moti Asayag" <masayag at redhat.com>, "Limor Gavish" <lgavish at gmail.com>,
> "Sharad Mishra" <snmishra at us.ibm.com>, "Alex Lourie" <alourie at redhat.com>, "Sandro Bonazzola" <sbonazzo at redhat.com>,
> "arch" <arch at ovirt.org>, "Ofer Schreiber" <oschreib at redhat.com>
> Sent: Sunday, May 12, 2013 2:52:51 PM
> Subject: [ANN] New development environment for ovirt-engine
> 
> Hello all ovirt-engine developers,
> 
> When I first joined the ovirt project, it took me about two weeks to setup a
> development environment, I needed to work on a bug related to host-deploy so
> I needed an environment that could use the ssh, PKI, vdsm-bootstrap and
> communicate with vdsm using SSL, this was virtually impossible to do so
> without tweaking the product in a way that it is so different from
> production use, that I cannot guarantee that whatever tested in development
> will actually work in production.
> 
> I peeked at the installation script in a hope that I can create partial
> environment similar to production, but I found that the packaging
> implementation makes to much assumption and is very difficult to adopt. The
> fact that I do not use fedora/rhel for my development made it even worse.
> 
> I had no other option than to create rpms after each of my changes and test
> each in real production like setup.
> 
> It was obvious to me that the manual customization of developers to achieve
> working product will eventually break as product grow and move away from
> being developer friendly to production friendly. For example, product
> defaults cannot be these which serve developers, but these which serve
> production the best, or having a valid PKI setup cannot be optional any more
> as components do need to use it. Same for location of files and
> configuration, for example, if we write a pluggable infrastructure for
> branding, we cannot damage the interface just because developers runs the
> product in their own manual customization.
> 
> I took the opportunity handed to me to port the ovirt-engine to other
> distributions in order to provide a development environment that is similar
> to production setup. Together with Sandro Bonazzola and Alex Lourie we
> re-wrote the whole installation of the product which can also be used to
> setup the desired development environment.
> 
> Within this environment the product is set up using the same tools and
> configuration as in production, while the process does not require special
> privileges nor changes the state of the developer machine.
> 
> A complete documentation is available[1], I preferred to use README within
> the source tree as wiki tend to quickly become obsolete, while documentation
> within source tree can be modified by the commit that introduces a change. I
> will redirect to this file from the current wiki once the site will be up.
> 
> In a nut shell, after installing prerequisites, build and install the product
> using:
> 
> $ make clean install-dev PREFIX=$HOME/ovirt-engine
> 
> This will run maven and create product installation at $HOME/ovirt-engine
> Next, a setup phase is required just like in production, to initialize
> configuration and database:
> 
> $ $HOME/ovirt-engine/bin/engine-setup-2
> 
> You have now fully functional product, including PKI, SSL, host-deploy,
> tools.
> No manual database updates are required, no lose of functionality.
> 
> All that is left is to start the engine service:
> 
> $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> 
> Access to application:
>    http://localhost:8080
>    https://localhost:8443
> Debugging port is opened at port 8787.
> 
> Farther information exists in the documentation[1].
> 
> There are several inherit benefits of the new environment, the major one is
> the ability to manage several environments in parallel on the same host. For
> example, if we develop two separate features on two branches we can install
> the product into $HOME/ovirt-engine-feature1 and
> $HOME/ovirt-engine-feature-2 and have a separate database for each, if we
> modify the ports jboss is listening to we can run two instances of engine at
> the same time!
> 
> We will be happy to work with all developers to assist in porting into the
> new development environment, the simplest is to create a new database for
> this effort. Moti has a sequence of converting the existing database owned
> by postgres to be owned by the engine, Moti, can you please share that?
> 
> We are sure there are missing bits, we will be happy to know these so we can
> improve.
> 
> I am aware that developers (especially java) are conservative, but I ask you
> to give us a chance, so that we make it easy for developers to join the
> project, and to allow us to drop the parallel effort of packaging to
> production and fixing the broken development environment.
> 
> A special thanks to developers who took the time to test and provide feedback
> before the merged:
> - Yaniv Bronheim
> - Moti Asayag
> - Limor Gavish
> - Sharad Mishra
> - Ofer Schreiber
> 
> We are hoping that after migration you will be find this environment useful
> and friendly,
> 
> Sandro Bonazzola,
> Alex Lourie,
> Alon Bar-Lev.
> 
> [1]
> http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD


From alonbl at redhat.com  Mon May 13 05:31:18 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 13 May 2013 01:31:18 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <3F4704D7-F7EA-4DE2-AA0B-255E117B28DB@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<518F3DBB.6080606@redhat.com>
	<557908336.127528.1368346520205.JavaMail.root@redhat.com>
	<518F56CE.3010802@redhat.com>
	<3F4704D7-F7EA-4DE2-AA0B-255E117B28DB@redhat.com>
Message-ID: <281632927.397694.1368423078891.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Barak Azulay" <bazulay at redhat.com>
> To: "Livnat Peer" <lpeer at redhat.com>
> Cc: "arch" <arch at ovirt.org>, "Alon Bar-Lev" <abarlev at redhat.com>, "Simon Grinberg" <sgrinber at redhat.com>
> Sent: Monday, May 13, 2013 8:21:33 AM
> Subject: Re: feature suggestion: initial generation of management network

> > you can fence the node if VDSM is non responsive, that's the mechanism
> > we use today to deal with such cases.
> 
> 
> There are already requests to enable:
> - ability to fence a host with no PM
> - ability to do less destructive fencing (= restart vdsm) when
> none-responsive and the host is accessible using SSH. This way the VMs
> running on the host will not get lost.
> 
> Both the above can be achieved as mentioned using SSH, and can't be achieved
> with the restart API to vdsm.

Why? I truly don't understand... we should make sure VDSM is responsive to accept new commands, and VDSM can either reboot machine or restart itself.

Alon


From bazulay at redhat.com  Mon May 13 05:21:33 2013
From: bazulay at redhat.com (Barak Azulay)
Date: Mon, 13 May 2013 01:21:33 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <518F56CE.3010802@redhat.com>
References: <20121227121406.GD8915@redhat.com>
	<11330867.78.1356611742783.JavaMail.javamailuser@localhost>
	<20130101124757.GI7274@redhat.com>
	<1264143158.8051712.1367925739116.JavaMail.root@redhat.com>
	<518F3DBB.6080606@redhat.com>
	<557908336.127528.1368346520205.JavaMail.root@redhat.com>
	<518F56CE.3010802@redhat.com>
Message-ID: <3F4704D7-F7EA-4DE2-AA0B-255E117B28DB@redhat.com>





On May 12, 2013, at 11:46, Livnat Peer <lpeer at redhat.com> wrote:

> On 05/12/2013 11:15 AM, Barak Azulay wrote:
>> 
>> 
>> ----- Original Message -----
>>> From: "Livnat Peer" <lpeer at redhat.com>
>>> To: "Moti Asayag" <masayag at redhat.com>
>>> Cc: "arch" <arch at ovirt.org>, "Alon Bar-Lev" <abarlev at redhat.com>, "Barak Azulay" <bazulay at redhat.com>, "Simon
>>> Grinberg" <sgrinber at redhat.com>
>>> Sent: Sunday, May 12, 2013 9:59:07 AM
>>> Subject: Re: feature suggestion: initial generation of management network
>>> 
>>> Thread Summary -
>>> 
>>> 1. We all agree the automatic reboot after host installation is not
>>> needed anymore and can be removed.
>>> 
>>> 2. There is a vast agreement that we need to add a new VDSM verb for reboot.
>> 
>> I disagree with the above
>> 
>> In addition to the fact that it will not work when VDSM is not responsive (when this action will be needed the most) 
>> 
> 
> you can fence the node if VDSM is non responsive, that's the mechanism
> we use today to deal with such cases.


There are already requests to enable:
- ability to fence a host with no PM 
- ability to do less destructive fencing (= restart vdsm) when none-responsive and the host is accessible using SSH. This way the VMs running on the host will not get lost.

Both the above can be achieved as mentioned using SSH, and can't be achieved with the restart API to vdsm.


> 
>> 
>>> 
>>> 3. There was a suggestion to add a checkbox when adding a host to reboot
>>> the host after installation, default would be not to reboot. (leaving
>>> the option to reboot to the administrator).
>>> 
>>> 
>>> If there is no objection we'll go with the above.
>>> 
>>> Thanks, Livnat
>>> 
>>> 
>>> On 05/07/2013 02:22 PM, Moti Asayag wrote:
>>>> I stumbled upon few issues with the current design while implementing it:
>>>> 
>>>> There seems to be a requirement to reboot the host after the installation
>>>> is completed in order to assure the host is recoverable.
>>>> 
>>>> Therefore, the building blocks of the installation process of 3.3 are:
>>>> 1. host deploy which installs the host expect configuring its management
>>>> network.
>>>> 2. SetupNetwork (and CommitNetworkChanges) - for creating the management
>>>> network
>>>> on the host and persisting the network configuration.
>>>> 3. Reboot the host - This is a missing piece. (engine has FenceVds command,
>>>> but it
>>>> requires the power management to be configured prior to the installation
>>>> and might
>>>> be irrelevant for hosts without PM.)
>>>> 
>>>> So, there are couple of issues here:
>>>> 1. How to reboot the host?
>>>> 1.1. By exposing new RebootNode verb in VDSM and invoking it from the
>>>> engine
>>>> 1.2. By opening ssh dialog to the host in order to execute the reboot
>>>> 
>>>> 2. When to perform the reboot?
>>>> 2.1. After host deploy, by utilizing the host deploy to perform the reboot.
>>>> It requires to configure the network by the monitor when the host is
>>>> detected by the engine,
>>>> detached from the installation flow. However it is a step toward the
>>>> non-persistent network feature
>>>> yet to be defined.
>>>> 2.2. After setupNetwork is done and network was configured and persisted on
>>>> the host.
>>>> There is no special advantage from recoverable aspect, as setupNetwork is
>>>> constantly
>>>> used to persist the network configuration (by the complementary
>>>> CommitNetworkChanges command).
>>>> In case and network configuration fails, VDSM will revert to the last well
>>>> known configuration
>>>> - so connectivity with engine should be restored. Design wise, it fits to
>>>> configure the management
>>>> network as part of the installation sequence.
>>>> If the network configuration fails in this context, the host status will be
>>>> set to "InstallFailed" rather than "NonOperational",
>>>> as might occur as a result of a failed setupNetwork command.
>>>> 
>>>> 
>>>> Your inputs are welcome.
>>>> 
>>>> Thanks,
>>>> Moti
>>>> ----- Original Message -----
>>>>> From: "Dan Kenigsberg" <danken at redhat.com>
>>>>> To: "Simon Grinberg" <simon at redhat.com>, "Moti Asayag"
>>>>> <masayag at redhat.com>
>>>>> Cc: "arch" <arch at ovirt.org>
>>>>> Sent: Tuesday, January 1, 2013 2:47:57 PM
>>>>> Subject: Re: feature suggestion: initial generation of management network
>>>>> 
>>>>> On Thu, Dec 27, 2012 at 07:36:40AM -0500, Simon Grinberg wrote:
>>>>>> 
>>>>>> 
>>>>>> ----- Original Message -----
>>>>>>> From: "Dan Kenigsberg" <danken at redhat.com>
>>>>>>> To: "Simon Grinberg" <simon at redhat.com>
>>>>>>> Cc: "arch" <arch at ovirt.org>
>>>>>>> Sent: Thursday, December 27, 2012 2:14:06 PM
>>>>>>> Subject: Re: feature suggestion: initial generation of management
>>>>>>> network
>>>>>>> 
>>>>>>> On Tue, Dec 25, 2012 at 09:29:26AM -0500, Simon Grinberg wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Dan Kenigsberg" <danken at redhat.com>
>>>>>>>>> To: "arch" <arch at ovirt.org>
>>>>>>>>> Sent: Tuesday, December 25, 2012 2:27:22 PM
>>>>>>>>> Subject: feature suggestion: initial generation of management
>>>>>>>>> network
>>>>>>>>> 
>>>>>>>>> Current condition:
>>>>>>>>> ==================
>>>>>>>>> The management network, named ovirtmgmt, is created during host
>>>>>>>>> bootstrap. It consists of a bridge device, connected to the
>>>>>>>>> network
>>>>>>>>> device that was used to communicate with Engine (nic, bonding or
>>>>>>>>> vlan).
>>>>>>>>> It inherits its ip settings from the latter device.
>>>>>>>>> 
>>>>>>>>> Why Is the Management Network Needed?
>>>>>>>>> =====================================
>>>>>>>>> Understandably, some may ask why do we need to have a management
>>>>>>>>> network - why having a host with IPv4 configured on it is not
>>>>>>>>> enough.
>>>>>>>>> The answer is twofold:
>>>>>>>>> 1. In oVirt, a network is an abstraction of the resources
>>>>>>>>> required
>>>>>>>>> for
>>>>>>>>>   connectivity of a host for a specific usage. This is true for
>>>>>>>>>   the
>>>>>>>>>   management network just as it is for VM network or a display
>>>>>>>>>   network.
>>>>>>>>>   The network entity is the key for adding/changing nics and IP
>>>>>>>>>   address.
>>>>>>>>> 2. In many occasions (such as small setups) the management
>>>>>>>>> network is
>>>>>>>>>   used as a VM/display network as well.
>>>>>>>>> 
>>>>>>>>> Problems in current connectivity:
>>>>>>>>> ================================
>>>>>>>>> According to alonbl of ovirt-host-deploy fame, and with no
>>>>>>>>> conflict
>>>>>>>>> to
>>>>>>>>> my own experience, creating the management network is the most
>>>>>>>>> fragile,
>>>>>>>>> error-prone step of bootstrap.
>>>>>>>> 
>>>>>>>> +1,
>>>>>>>> I've raise that repeatedly in the past, bootstrap should not create
>>>>>>>> the management network but pick up the existing configuration and
>>>>>>>> let the engine override later with it's own configuration if it
>>>>>>>> differs , I'm glad that we finally get to that.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Currently it always creates a bridged network (even if the DC
>>>>>>>>> requires a
>>>>>>>>> non-bridged ovirtmgmt), it knows nothing about the defined MTU
>>>>>>>>> for
>>>>>>>>> ovirtmgmt, it uses ping to guess on top of which device to build
>>>>>>>>> (and
>>>>>>>>> thus requires Vdsm-to-Engine reverse connectivity), and is the
>>>>>>>>> sole
>>>>>>>>> remaining user of the addNetwork/vdsm-store-net-conf scripts.
>>>>>>>>> 
>>>>>>>>> Suggested feature:
>>>>>>>>> ==================
>>>>>>>>> Bootstrap would avoid creating a management network. Instead,
>>>>>>>>> after
>>>>>>>>> bootstrapping a host, Engine would send a getVdsCaps probe to the
>>>>>>>>> installed host, receiving a complete picture of the network
>>>>>>>>> configuration on the host. Among this picture is the device that
>>>>>>>>> holds
>>>>>>>>> the host's management IP address.
>>>>>>>>> 
>>>>>>>>> Engine would send setupNetwork command to generate ovirtmgmt with
>>>>>>>>> details devised from this picture, and according to the DC
>>>>>>>>> definition
>>>>>>>>> of
>>>>>>>>> ovirtmgmt.  For example, if Vdsm reports:
>>>>>>>>> 
>>>>>>>>> - vlan bond4.3000 has the host's IP, configured to use dhcp.
>>>>>>>>> - bond4 is comprises eth2 and eth3
>>>>>>>>> - ovirtmgmt is defined as a VM network with MTU 9000
>>>>>>>>> 
>>>>>>>>> then Engine sends the likes of:
>>>>>>>>>  setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
>>>>>>>>>                bonding=bond4: {eth2,eth3}, MTU=9000)
>>>>>>>> 
>>>>>>>> Just one comment here,
>>>>>>>> In order to save time and confusion - if the ovirtmgmt is defined
>>>>>>>> with default values meaning the user did not bother to touch it,
>>>>>>>> let it pick up the VLAN configuration from the first host added in
>>>>>>>> the Data Center.
>>>>>>>> 
>>>>>>>> Otherwise, you may override the host VLAN and loose connectivity.
>>>>>>>> 
>>>>>>>> This will also solve the situation many users encounter today.
>>>>>>>> 1. The engine in on a host that actually has VLAN defined
>>>>>>>> 2. The ovirtmgmt network was not updated in the DC
>>>>>>>> 3. A host, with VLAN already defined is added - everything works
>>>>>>>> fine
>>>>>>>> 4. Any number of hosts are now added, again everything seems to
>>>>>>>> work fine.
>>>>>>>> 
>>>>>>>> But, now try to use setupNetworks, and you'll find out that you
>>>>>>>> can't do much on the interface that contains the ovirtmgmt since
>>>>>>>> the definition does not match. You can't sync (Since this will
>>>>>>>> remove the VLAN and cause connectivity lose) you can't add more
>>>>>>>> networks on top since it already has non-VLAN network on top
>>>>>>>> according to the DC definition, etc.
>>>>>>>> 
>>>>>>>> On the other hand you can't update the ovirtmgmt definition on the
>>>>>>>> DC since there are clusters in the DC that use the network.
>>>>>>>> 
>>>>>>>> The only workaround not involving DB hack to change the VLAN on the
>>>>>>>> network is to:
>>>>>>>> 1. Create new DC
>>>>>>>> 2. Do not use the wizard that pops up to create your cluster.
>>>>>>>> 3. Modify the ovirtmgmt network to have VLANs
>>>>>>>> 4. Now create a cluster and add your hosts.
>>>>>>>> 
>>>>>>>> If you insist on using the default DC and cluster then before
>>>>>>>> adding the first host, create an additional DC and move the
>>>>>>>> Default cluster over there. You may then change the network on the
>>>>>>>> Default cluster and then move the Default cluster back
>>>>>>>> 
>>>>>>>> Both are ugly. And should be solved by the proposal above.
>>>>>>>> 
>>>>>>>> We do something similar for the Default cluster CPU level, where we
>>>>>>>> set the intial level based on the first host added to the cluster.
>>>>>>> 
>>>>>>> I'm not sure what Engine has for Default cluster CPU level. But I
>>>>>>> have
>>>>>>> reservation of the hysteresis in your proposal - after a host is
>>>>>>> added,
>>>>>>> the DC cannot forget ovirtmgmt's vlan.
>>>>>>> 
>>>>>>> How about letting the admin edit ovirtmgmt's vlan in the DC level,
>>>>>>> thus
>>>>>>> rendering all hosts out-of-sync. The the admin could manually, or
>>>>>>> through a script, or in the future through a distributed operation,
>>>>>>> sync
>>>>>>> all the hosts to the definition?
>>>>>> 
>>>>>> Usually if you do that you will loose connectivity to the hosts.
>>>>> 
>>>>> Yes, changing the management vlan id (or ip address) is never fun, and
>>>>> requires out-of-band intervention.
>>>>> 
>>>>>> I'm not insisting on the automatic adjustment of the ovirtmgmt network to
>>>>>> match the hosts' (that is just a nice touch) we can take the allow edit
>>>>>> approach.
>>>>>> 
>>>>>> But allow to change VLAN on the ovirtmgmt network will indeed solve the
>>>>>> issue I'm trying to solve while creating another issue of user expecting
>>>>>> that we'll be able to re-tag the host from the engine side, which is
>>>>>> challenging to do.
>>>>>> 
>>>>>> On the other hand, if we allow to change the VLAN as long as the change
>>>>>> matches the hosts' configuration, it will both solve the issue while not
>>>>>> eluding the user to think that we really can solve the chicken and egg
>>>>>> issue of re-tag the entire system.
>>>>>> 
>>>>>> Now with the above ability you do get a flow to do the re-tag.
>>>>>> 1. Place all the hosts in maintenance
>>>>>> 2. Re-tag the ovirtmgmt on all the hosts
>>>>>> 3. Re-tag the hosts on which the engine on
>>>>>> 4. Activate the hosts - this should work well now since connectivity
>>>>>> exist
>>>>>> 5. Change the tag on ovirtmgmt on the engine to match the hosts'
>>>>>> 
>>>>>> Simple and clear process.
>>>>>> 
>>>>>> When the workaround of creating another DC was not possible since the
>>>>>> system was already long in use and the need was re-tag of the network the
>>>>>> above is what I've recommended in the, except that steps 4-5 where done
>>>>>> as:
>>>>>> 4. Stop the engine
>>>>>> 5. Change the tag in the DB
>>>>>> 6. Start the engine
>>>>>> 7. Activate the hosts
>>>>> 
>>>>> Sounds reasonable to me - but as far as I am aware this is not tightly
>>>>> related to the $Subject, which is the post-boot ovirtmgmt definition.
>>>>> 
>>>>> I've added a few details to
>>>>> http://www.ovirt.org/Features/Normalized_ovirtmgmt_Initialization#Engine
>>>>> and I would apreciate a review from someone with intimate Engine
>>>>> know-how.
>>>>> 
>>>>> Dan.
>>>>> 
>>>> _______________________________________________
>>>> Arch mailing list
>>>> Arch at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>> 
>>>> 
>>> 
>>> 
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>> 
>> 
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 
> 


From bazulay at redhat.com  Mon May 13 19:34:02 2013
From: bazulay at redhat.com (Barak Azulay)
Date: Mon, 13 May 2013 15:34:02 -0400 (EDT)
Subject: [ANN] New development environment for ovirt-engine
In-Reply-To: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
Message-ID: <545E4A23-4E49-478F-B8E8-FBB7488C22ED@redhat.com>

Good work guys,

Thanks
Barak Azulay



On May 12, 2013, at 14:52, Alon Bar-Lev <alonbl at redhat.com> wrote:

> Hello all ovirt-engine developers,
> 
> When I first joined the ovirt project, it took me about two weeks to setup a development environment, I needed to work on a bug related to host-deploy so I needed an environment that could use the ssh, PKI, vdsm-bootstrap and communicate with vdsm using SSL, this was virtually impossible to do so without tweaking the product in a way that it is so different from production use, that I cannot guarantee that whatever tested in development will actually work in production.
> 
> I peeked at the installation script in a hope that I can create partial environment similar to production, but I found that the packaging implementation makes to much assumption and is very difficult to adopt. The fact that I do not use fedora/rhel for my development made it even worse.
> 
> I had no other option than to create rpms after each of my changes and test each in real production like setup.
> 
> It was obvious to me that the manual customization of developers to achieve working product will eventually break as product grow and move away from being developer friendly to production friendly. For example, product defaults cannot be these which serve developers, but these which serve production the best, or having a valid PKI setup cannot be optional any more as components do need to use it. Same for location of files and configuration, for example, if we write a pluggable infrastructure for branding, we cannot damage the interface just because developers runs the product in their own manual customization.
> 
> I took the opportunity handed to me to port the ovirt-engine to other distributions in order to provide a development environment that is similar to production setup. Together with Sandro Bonazzola and Alex Lourie we re-wrote the whole installation of the product which can also be used to setup the desired development environment.
> 
> Within this environment the product is set up using the same tools and configuration as in production, while the process does not require special privileges nor changes the state of the developer machine. 
> 
> A complete documentation is available[1], I preferred to use README within the source tree as wiki tend to quickly become obsolete, while documentation within source tree can be modified by the commit that introduces a change. I will redirect to this file from the current wiki once the site will be up.
> 
> In a nut shell, after installing prerequisites, build and install the product using:
> 
> $ make clean install-dev PREFIX=$HOME/ovirt-engine
> 
> This will run maven and create product installation at $HOME/ovirt-engine
> Next, a setup phase is required just like in production, to initialize configuration and database:
> 
> $ $HOME/ovirt-engine/bin/engine-setup-2
> 
> You have now fully functional product, including PKI, SSL, host-deploy, tools.
> No manual database updates are required, no lose of functionality.
> 
> All that is left is to start the engine service:
> 
> $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> 
> Access to application:
>   http://localhost:8080
>   https://localhost:8443
> Debugging port is opened at port 8787.
> 
> Farther information exists in the documentation[1].
> 
> There are several inherit benefits of the new environment, the major one is the ability to manage several environments in parallel on the same host. For example, if we develop two separate features on two branches we can install the product into $HOME/ovirt-engine-feature1 and $HOME/ovirt-engine-feature-2 and have a separate database for each, if we modify the ports jboss is listening to we can run two instances of engine at the same time!
> 
> We will be happy to work with all developers to assist in porting into the new development environment, the simplest is to create a new database for this effort. Moti has a sequence of converting the existing database owned by postgres to be owned by the engine, Moti, can you please share that?
> 
> We are sure there are missing bits, we will be happy to know these so we can improve.
> 
> I am aware that developers (especially java) are conservative, but I ask you to give us a chance, so that we make it easy for developers to join the project, and to allow us to drop the parallel effort of packaging to production and fixing the broken development environment. 
> 
> A special thanks to developers who took the time to test and provide feedback before the merged:
> - Yaniv Bronheim
> - Moti Asayag
> - Limor Gavish
> - Sharad Mishra
> - Ofer Schreiber
> 
> We are hoping that after migration you will be find this environment useful and friendly,
> 
> Sandro Bonazzola,
> Alex Lourie,
> Alon Bar-Lev.
> 
> [1] http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 
> 


From emesika at redhat.com  Tue May 14 00:45:41 2013
From: emesika at redhat.com (Eli Mesika)
Date: Mon, 13 May 2013 20:45:41 -0400 (EDT)
Subject: [Engine-devel] [ANN] New development environment for ovirt-engine
In-Reply-To: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
Message-ID: <188337855.1067044.1368492341205.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Cc: "arch" <arch at ovirt.org>, "Sharad Mishra" <snmishra at us.ibm.com>, "Limor Gavish" <lgavish at gmail.com>
> Sent: Sunday, May 12, 2013 2:52:51 PM
> Subject: [Engine-devel] [ANN] New development environment for ovirt-engine
> 
> Hello all ovirt-engine developers,
> 
> When I first joined the ovirt project, it took me about two weeks to setup a
> development environment, I needed to work on a bug related to host-deploy so
> I needed an environment that could use the ssh, PKI, vdsm-bootstrap and
> communicate with vdsm using SSL, this was virtually impossible to do so
> without tweaking the product in a way that it is so different from
> production use, that I cannot guarantee that whatever tested in development
> will actually work in production.
> 
> I peeked at the installation script in a hope that I can create partial
> environment similar to production, but I found that the packaging
> implementation makes to much assumption and is very difficult to adopt. The
> fact that I do not use fedora/rhel for my development made it even worse.
> 
> I had no other option than to create rpms after each of my changes and test
> each in real production like setup.
> 
> It was obvious to me that the manual customization of developers to achieve
> working product will eventually break as product grow and move away from
> being developer friendly to production friendly. For example, product
> defaults cannot be these which serve developers, but these which serve
> production the best, or having a valid PKI setup cannot be optional any more
> as components do need to use it. Same for location of files and
> configuration, for example, if we write a pluggable infrastructure for
> branding, we cannot damage the interface just because developers runs the
> product in their own manual customization.
> 
> I took the opportunity handed to me to port the ovirt-engine to other
> distributions in order to provide a development environment that is similar
> to production setup. Together with Sandro Bonazzola and Alex Lourie we
> re-wrote the whole installation of the product which can also be used to
> setup the desired development environment.
> 
> Within this environment the product is set up using the same tools and
> configuration as in production, while the process does not require special
> privileges nor changes the state of the developer machine.
> 
> A complete documentation is available[1], I preferred to use README within
> the source tree as wiki tend to quickly become obsolete, while documentation
> within source tree can be modified by the commit that introduces a change. I
> will redirect to this file from the current wiki once the site will be up.
> 
> In a nut shell, after installing prerequisites, build and install the product
> using:
> 
> $ make clean install-dev PREFIX=$HOME/ovirt-engine
> 
> This will run maven and create product installation at $HOME/ovirt-engine
> Next, a setup phase is required just like in production, to initialize
> configuration and database:
> 
> $ $HOME/ovirt-engine/bin/engine-setup-2
> 
> You have now fully functional product, including PKI, SSL, host-deploy,
> tools.
> No manual database updates are required, no lose of functionality.
> 
> All that is left is to start the engine service:
> 
> $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> 
> Access to application:
>    http://localhost:8080
>    https://localhost:8443
> Debugging port is opened at port 8787.
> 
> Farther information exists in the documentation[1].
> 
> There are several inherit benefits of the new environment, the major one is
> the ability to manage several environments in parallel on the same host. For
> example, if we develop two separate features on two branches we can install
> the product into $HOME/ovirt-engine-feature1 and
> $HOME/ovirt-engine-feature-2 and have a separate database for each, if we
> modify the ports jboss is listening to we can run two instances of engine at
> the same time!

It is not clear to me why working on 2 bugs needs 2 installations of the development environment.
If you have 2 different git branches and a separate database for each, its enough , am I missing something ?
I was used to create a git branch with the name of the BZ# and use create_db.sh script to create a new database with the BZ# name.
Is this possible in the new method?
Also, does this mean that I will have to create/configure a new workspace for eclipse each time I am starting to work on a new bug?


Thanks


> 
> We will be happy to work with all developers to assist in porting into the
> new development environment, the simplest is to create a new database for
> this effort. Moti has a sequence of converting the existing database owned
> by postgres to be owned by the engine, Moti, can you please share that?
> 
> We are sure there are missing bits, we will be happy to know these so we can
> improve.
> 
> I am aware that developers (especially java) are conservative, but I ask you
> to give us a chance, so that we make it easy for developers to join the
> project, and to allow us to drop the parallel effort of packaging to
> production and fixing the broken development environment.
> 
> A special thanks to developers who took the time to test and provide feedback
> before the merged:
> - Yaniv Bronheim
> - Moti Asayag
> - Limor Gavish
> - Sharad Mishra
> - Ofer Schreiber
> 
> We are hoping that after migration you will be find this environment useful
> and friendly,
> 
> Sandro Bonazzola,
> Alex Lourie,
> Alon Bar-Lev.
> 
> [1]
> http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From yzaslavs at redhat.com  Tue May 14 02:39:19 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 13 May 2013 22:39:19 -0400 (EDT)
Subject: [Engine-devel] [ANN] New development environment for ovirt-engine
In-Reply-To: <188337855.1067044.1368492341205.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
	<188337855.1067044.1368492341205.JavaMail.root@redhat.com>
Message-ID: <975472192.855606.1368499159787.JavaMail.root@redhat.com>

Alon,
I have FC17, and followed the steps at the wiki , i defined the ovirt nightly repo 

[ovirt-nightly]
name=ovirt-nightly
baseurl=http://resources.ovirt.org/releases/nightly/rpm/Fedora/17/
enabled=1
gpgcheck=0
priority=1
protect=1

And performed yum install according to your guidelines.
It fails to find python-m2crypto

Can you please advise on the matter?

Many thanks,
Yair



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> Sent: Tuesday, May 14, 2013 3:45:41 AM
> Subject: Re: [Engine-devel] [ANN] New development environment for ovirt-engine
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Cc: "arch" <arch at ovirt.org>, "Sharad Mishra" <snmishra at us.ibm.com>, "Limor
> > Gavish" <lgavish at gmail.com>
> > Sent: Sunday, May 12, 2013 2:52:51 PM
> > Subject: [Engine-devel] [ANN] New development environment for ovirt-engine
> > 
> > Hello all ovirt-engine developers,
> > 
> > When I first joined the ovirt project, it took me about two weeks to setup
> > a
> > development environment, I needed to work on a bug related to host-deploy
> > so
> > I needed an environment that could use the ssh, PKI, vdsm-bootstrap and
> > communicate with vdsm using SSL, this was virtually impossible to do so
> > without tweaking the product in a way that it is so different from
> > production use, that I cannot guarantee that whatever tested in development
> > will actually work in production.
> > 
> > I peeked at the installation script in a hope that I can create partial
> > environment similar to production, but I found that the packaging
> > implementation makes to much assumption and is very difficult to adopt. The
> > fact that I do not use fedora/rhel for my development made it even worse.
> > 
> > I had no other option than to create rpms after each of my changes and test
> > each in real production like setup.
> > 
> > It was obvious to me that the manual customization of developers to achieve
> > working product will eventually break as product grow and move away from
> > being developer friendly to production friendly. For example, product
> > defaults cannot be these which serve developers, but these which serve
> > production the best, or having a valid PKI setup cannot be optional any
> > more
> > as components do need to use it. Same for location of files and
> > configuration, for example, if we write a pluggable infrastructure for
> > branding, we cannot damage the interface just because developers runs the
> > product in their own manual customization.
> > 
> > I took the opportunity handed to me to port the ovirt-engine to other
> > distributions in order to provide a development environment that is similar
> > to production setup. Together with Sandro Bonazzola and Alex Lourie we
> > re-wrote the whole installation of the product which can also be used to
> > setup the desired development environment.
> > 
> > Within this environment the product is set up using the same tools and
> > configuration as in production, while the process does not require special
> > privileges nor changes the state of the developer machine.
> > 
> > A complete documentation is available[1], I preferred to use README within
> > the source tree as wiki tend to quickly become obsolete, while
> > documentation
> > within source tree can be modified by the commit that introduces a change.
> > I
> > will redirect to this file from the current wiki once the site will be up.
> > 
> > In a nut shell, after installing prerequisites, build and install the
> > product
> > using:
> > 
> > $ make clean install-dev PREFIX=$HOME/ovirt-engine
> > 
> > This will run maven and create product installation at $HOME/ovirt-engine
> > Next, a setup phase is required just like in production, to initialize
> > configuration and database:
> > 
> > $ $HOME/ovirt-engine/bin/engine-setup-2
> > 
> > You have now fully functional product, including PKI, SSL, host-deploy,
> > tools.
> > No manual database updates are required, no lose of functionality.
> > 
> > All that is left is to start the engine service:
> > 
> > $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> > 
> > Access to application:
> >    http://localhost:8080
> >    https://localhost:8443
> > Debugging port is opened at port 8787.
> > 
> > Farther information exists in the documentation[1].
> > 
> > There are several inherit benefits of the new environment, the major one is
> > the ability to manage several environments in parallel on the same host.
> > For
> > example, if we develop two separate features on two branches we can install
> > the product into $HOME/ovirt-engine-feature1 and
> > $HOME/ovirt-engine-feature-2 and have a separate database for each, if we
> > modify the ports jboss is listening to we can run two instances of engine
> > at
> > the same time!
> 
> It is not clear to me why working on 2 bugs needs 2 installations of the
> development environment.
> If you have 2 different git branches and a separate database for each, its
> enough , am I missing something ?
> I was used to create a git branch with the name of the BZ# and use
> create_db.sh script to create a new database with the BZ# name.
> Is this possible in the new method?
> Also, does this mean that I will have to create/configure a new workspace for
> eclipse each time I am starting to work on a new bug?
> 
> 
> Thanks
> 
> 
> > 
> > We will be happy to work with all developers to assist in porting into the
> > new development environment, the simplest is to create a new database for
> > this effort. Moti has a sequence of converting the existing database owned
> > by postgres to be owned by the engine, Moti, can you please share that?
> > 
> > We are sure there are missing bits, we will be happy to know these so we
> > can
> > improve.
> > 
> > I am aware that developers (especially java) are conservative, but I ask
> > you
> > to give us a chance, so that we make it easy for developers to join the
> > project, and to allow us to drop the parallel effort of packaging to
> > production and fixing the broken development environment.
> > 
> > A special thanks to developers who took the time to test and provide
> > feedback
> > before the merged:
> > - Yaniv Bronheim
> > - Moti Asayag
> > - Limor Gavish
> > - Sharad Mishra
> > - Ofer Schreiber
> > 
> > We are hoping that after migration you will be find this environment useful
> > and friendly,
> > 
> > Sandro Bonazzola,
> > Alex Lourie,
> > Alon Bar-Lev.
> > 
> > [1]
> > http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From alonbl at redhat.com  Tue May 14 05:58:06 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 14 May 2013 01:58:06 -0400 (EDT)
Subject: [Engine-devel] [ANN] New development environment for ovirt-engine
In-Reply-To: <975472192.855606.1368499159787.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
	<188337855.1067044.1368492341205.JavaMail.root@redhat.com>
	<975472192.855606.1368499159787.JavaMail.root@redhat.com>
Message-ID: <998811568.829527.1368511086124.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> Sent: Tuesday, May 14, 2013 5:39:19 AM
> Subject: Re: [Engine-devel] [ANN] New development environment for ovirt-engine
> 
> Alon,
> I have FC17, and followed the steps at the wiki , i defined the ovirt nightly
> repo
> 
> [ovirt-nightly]
> name=ovirt-nightly
> baseurl=http://resources.ovirt.org/releases/nightly/rpm/Fedora/17/
> enabled=1
> gpgcheck=0
> priority=1
> protect=1
> 
> And performed yum install according to your guidelines.
> It fails to find python-m2crypto

Has nothing to do with ovirt :)
Try m2crypto please.

> 
> Can you please advise on the matter?
> 
> Many thanks,
> Yair
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> > Sent: Tuesday, May 14, 2013 3:45:41 AM
> > Subject: Re: [Engine-devel] [ANN] New development environment for
> > ovirt-engine
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Cc: "arch" <arch at ovirt.org>, "Sharad Mishra" <snmishra at us.ibm.com>,
> > > "Limor
> > > Gavish" <lgavish at gmail.com>
> > > Sent: Sunday, May 12, 2013 2:52:51 PM
> > > Subject: [Engine-devel] [ANN] New development environment for
> > > ovirt-engine
> > > 
> > > Hello all ovirt-engine developers,
> > > 
> > > When I first joined the ovirt project, it took me about two weeks to
> > > setup
> > > a
> > > development environment, I needed to work on a bug related to host-deploy
> > > so
> > > I needed an environment that could use the ssh, PKI, vdsm-bootstrap and
> > > communicate with vdsm using SSL, this was virtually impossible to do so
> > > without tweaking the product in a way that it is so different from
> > > production use, that I cannot guarantee that whatever tested in
> > > development
> > > will actually work in production.
> > > 
> > > I peeked at the installation script in a hope that I can create partial
> > > environment similar to production, but I found that the packaging
> > > implementation makes to much assumption and is very difficult to adopt.
> > > The
> > > fact that I do not use fedora/rhel for my development made it even worse.
> > > 
> > > I had no other option than to create rpms after each of my changes and
> > > test
> > > each in real production like setup.
> > > 
> > > It was obvious to me that the manual customization of developers to
> > > achieve
> > > working product will eventually break as product grow and move away from
> > > being developer friendly to production friendly. For example, product
> > > defaults cannot be these which serve developers, but these which serve
> > > production the best, or having a valid PKI setup cannot be optional any
> > > more
> > > as components do need to use it. Same for location of files and
> > > configuration, for example, if we write a pluggable infrastructure for
> > > branding, we cannot damage the interface just because developers runs the
> > > product in their own manual customization.
> > > 
> > > I took the opportunity handed to me to port the ovirt-engine to other
> > > distributions in order to provide a development environment that is
> > > similar
> > > to production setup. Together with Sandro Bonazzola and Alex Lourie we
> > > re-wrote the whole installation of the product which can also be used to
> > > setup the desired development environment.
> > > 
> > > Within this environment the product is set up using the same tools and
> > > configuration as in production, while the process does not require
> > > special
> > > privileges nor changes the state of the developer machine.
> > > 
> > > A complete documentation is available[1], I preferred to use README
> > > within
> > > the source tree as wiki tend to quickly become obsolete, while
> > > documentation
> > > within source tree can be modified by the commit that introduces a
> > > change.
> > > I
> > > will redirect to this file from the current wiki once the site will be
> > > up.
> > > 
> > > In a nut shell, after installing prerequisites, build and install the
> > > product
> > > using:
> > > 
> > > $ make clean install-dev PREFIX=$HOME/ovirt-engine
> > > 
> > > This will run maven and create product installation at $HOME/ovirt-engine
> > > Next, a setup phase is required just like in production, to initialize
> > > configuration and database:
> > > 
> > > $ $HOME/ovirt-engine/bin/engine-setup-2
> > > 
> > > You have now fully functional product, including PKI, SSL, host-deploy,
> > > tools.
> > > No manual database updates are required, no lose of functionality.
> > > 
> > > All that is left is to start the engine service:
> > > 
> > > $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> > > 
> > > Access to application:
> > >    http://localhost:8080
> > >    https://localhost:8443
> > > Debugging port is opened at port 8787.
> > > 
> > > Farther information exists in the documentation[1].
> > > 
> > > There are several inherit benefits of the new environment, the major one
> > > is
> > > the ability to manage several environments in parallel on the same host.
> > > For
> > > example, if we develop two separate features on two branches we can
> > > install
> > > the product into $HOME/ovirt-engine-feature1 and
> > > $HOME/ovirt-engine-feature-2 and have a separate database for each, if we
> > > modify the ports jboss is listening to we can run two instances of engine
> > > at
> > > the same time!
> > 
> > It is not clear to me why working on 2 bugs needs 2 installations of the
> > development environment.
> > If you have 2 different git branches and a separate database for each, its
> > enough , am I missing something ?
> > I was used to create a git branch with the name of the BZ# and use
> > create_db.sh script to create a new database with the BZ# name.
> > Is this possible in the new method?
> > Also, does this mean that I will have to create/configure a new workspace
> > for
> > eclipse each time I am starting to work on a new bug?
> > 
> > 
> > Thanks
> > 
> > 
> > > 
> > > We will be happy to work with all developers to assist in porting into
> > > the
> > > new development environment, the simplest is to create a new database for
> > > this effort. Moti has a sequence of converting the existing database
> > > owned
> > > by postgres to be owned by the engine, Moti, can you please share that?
> > > 
> > > We are sure there are missing bits, we will be happy to know these so we
> > > can
> > > improve.
> > > 
> > > I am aware that developers (especially java) are conservative, but I ask
> > > you
> > > to give us a chance, so that we make it easy for developers to join the
> > > project, and to allow us to drop the parallel effort of packaging to
> > > production and fixing the broken development environment.
> > > 
> > > A special thanks to developers who took the time to test and provide
> > > feedback
> > > before the merged:
> > > - Yaniv Bronheim
> > > - Moti Asayag
> > > - Limor Gavish
> > > - Sharad Mishra
> > > - Ofer Schreiber
> > > 
> > > We are hoping that after migration you will be find this environment
> > > useful
> > > and friendly,
> > > 
> > > Sandro Bonazzola,
> > > Alex Lourie,
> > > Alon Bar-Lev.
> > > 
> > > [1]
> > > http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From alonbl at redhat.com  Tue May 14 06:18:44 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 14 May 2013 02:18:44 -0400 (EDT)
Subject: [Engine-devel] [ANN] New development environment for ovirt-engine
In-Reply-To: <188337855.1067044.1368492341205.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
	<188337855.1067044.1368492341205.JavaMail.root@redhat.com>
Message-ID: <1732269511.831688.1368512324398.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> Sent: Tuesday, May 14, 2013 3:45:41 AM
> Subject: Re: [Engine-devel] [ANN] New development environment for ovirt-engine
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Cc: "arch" <arch at ovirt.org>, "Sharad Mishra" <snmishra at us.ibm.com>, "Limor
> > Gavish" <lgavish at gmail.com>
> > Sent: Sunday, May 12, 2013 2:52:51 PM
> > Subject: [Engine-devel] [ANN] New development environment for ovirt-engine
> > 
> > Hello all ovirt-engine developers,
> > 
> > When I first joined the ovirt project, it took me about two weeks to setup
> > a
> > development environment, I needed to work on a bug related to host-deploy
> > so
> > I needed an environment that could use the ssh, PKI, vdsm-bootstrap and
> > communicate with vdsm using SSL, this was virtually impossible to do so
> > without tweaking the product in a way that it is so different from
> > production use, that I cannot guarantee that whatever tested in development
> > will actually work in production.
> > 
> > I peeked at the installation script in a hope that I can create partial
> > environment similar to production, but I found that the packaging
> > implementation makes to much assumption and is very difficult to adopt. The
> > fact that I do not use fedora/rhel for my development made it even worse.
> > 
> > I had no other option than to create rpms after each of my changes and test
> > each in real production like setup.
> > 
> > It was obvious to me that the manual customization of developers to achieve
> > working product will eventually break as product grow and move away from
> > being developer friendly to production friendly. For example, product
> > defaults cannot be these which serve developers, but these which serve
> > production the best, or having a valid PKI setup cannot be optional any
> > more
> > as components do need to use it. Same for location of files and
> > configuration, for example, if we write a pluggable infrastructure for
> > branding, we cannot damage the interface just because developers runs the
> > product in their own manual customization.
> > 
> > I took the opportunity handed to me to port the ovirt-engine to other
> > distributions in order to provide a development environment that is similar
> > to production setup. Together with Sandro Bonazzola and Alex Lourie we
> > re-wrote the whole installation of the product which can also be used to
> > setup the desired development environment.
> > 
> > Within this environment the product is set up using the same tools and
> > configuration as in production, while the process does not require special
> > privileges nor changes the state of the developer machine.
> > 
> > A complete documentation is available[1], I preferred to use README within
> > the source tree as wiki tend to quickly become obsolete, while
> > documentation
> > within source tree can be modified by the commit that introduces a change.
> > I
> > will redirect to this file from the current wiki once the site will be up.
> > 
> > In a nut shell, after installing prerequisites, build and install the
> > product
> > using:
> > 
> > $ make clean install-dev PREFIX=$HOME/ovirt-engine
> > 
> > This will run maven and create product installation at $HOME/ovirt-engine
> > Next, a setup phase is required just like in production, to initialize
> > configuration and database:
> > 
> > $ $HOME/ovirt-engine/bin/engine-setup-2
> > 
> > You have now fully functional product, including PKI, SSL, host-deploy,
> > tools.
> > No manual database updates are required, no lose of functionality.
> > 
> > All that is left is to start the engine service:
> > 
> > $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> > 
> > Access to application:
> >    http://localhost:8080
> >    https://localhost:8443
> > Debugging port is opened at port 8787.
> > 
> > Farther information exists in the documentation[1].
> > 
> > There are several inherit benefits of the new environment, the major one is
> > the ability to manage several environments in parallel on the same host.
> > For
> > example, if we develop two separate features on two branches we can install
> > the product into $HOME/ovirt-engine-feature1 and
> > $HOME/ovirt-engine-feature-2 and have a separate database for each, if we
> > modify the ports jboss is listening to we can run two instances of engine
> > at
> > the same time!
> 
> It is not clear to me why working on 2 bugs needs 2 installations of the
> development environment.
> If you have 2 different git branches and a separate database for each, its
> enough , am I missing something ?

You have two different git branches, so you have two different binaries out of the build, right?
These binaries should reside some where.
Currently you are probably use maven deploy or something similar into single jboss, without proper environment, overriding each time the other branch's binaries.
What if there is a change in configuration between the two? more prerequisites, different service configuration? different database schema?

To make it easy, you can just duplicate the development environment, and be sure you are up and running.

If you still want to take the chance you can... just make install-dev PREFIX=$HOME/same-place and you will have the behavior of overriding the same environment, and hoping for the best.

> I was used to create a git branch with the name of the BZ# and use
> create_db.sh script to create a new database with the BZ# name.
> Is this possible in the new method?

Yes.
You create an empty database manually, let's say engine-branch1.
Then you install the environment to own location, let say make install-dev PREFIX=$HOME/ovirt-engine-branch1
When running engine-setup-2 you instruct the setup to use engine-branch1 database.
This database will be created out of the new branch's create_db.sh.
create_db.sh should not run manually now.

However, if you insist of creating a database manually and modify an existing environment to use the new database, it is possible as well.
Edit $PREFIX/etc/ovirt-engine/engine.conf.d/10-setup-database.conf, and specify where database is, then start the engine service.

> Also, does this mean that I will have to create/configure a new workspace for
> eclipse each time I am starting to work on a new bug?

This I do not know. How does it work now when you switch branches?

> 
> 
> Thanks
> 
> 
> > 
> > We will be happy to work with all developers to assist in porting into the
> > new development environment, the simplest is to create a new database for
> > this effort. Moti has a sequence of converting the existing database owned
> > by postgres to be owned by the engine, Moti, can you please share that?
> > 
> > We are sure there are missing bits, we will be happy to know these so we
> > can
> > improve.
> > 
> > I am aware that developers (especially java) are conservative, but I ask
> > you
> > to give us a chance, so that we make it easy for developers to join the
> > project, and to allow us to drop the parallel effort of packaging to
> > production and fixing the broken development environment.
> > 
> > A special thanks to developers who took the time to test and provide
> > feedback
> > before the merged:
> > - Yaniv Bronheim
> > - Moti Asayag
> > - Limor Gavish
> > - Sharad Mishra
> > - Ofer Schreiber
> > 
> > We are hoping that after migration you will be find this environment useful
> > and friendly,
> > 
> > Sandro Bonazzola,
> > Alex Lourie,
> > Alon Bar-Lev.
> > 
> > [1]
> > http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From yzaslavs at redhat.com  Tue May 14 06:55:52 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 14 May 2013 02:55:52 -0400 (EDT)
Subject: [Engine-devel] [ANN] New development environment for ovirt-engine
In-Reply-To: <998811568.829527.1368511086124.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
	<188337855.1067044.1368492341205.JavaMail.root@redhat.com>
	<975472192.855606.1368499159787.JavaMail.root@redhat.com>
	<998811568.829527.1368511086124.JavaMail.root@redhat.com>
Message-ID: <1540245909.911838.1368514552129.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> Cc: "Eli Mesika" <emesika at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> Sent: Tuesday, May 14, 2013 8:58:06 AM
> Subject: Re: [Engine-devel] [ANN] New development environment for ovirt-engine
> 
> 
> 
> ----- Original Message -----
> > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > To: "Eli Mesika" <emesika at redhat.com>
> > Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> > Sent: Tuesday, May 14, 2013 5:39:19 AM
> > Subject: Re: [Engine-devel] [ANN] New development environment for
> > ovirt-engine
> > 
> > Alon,
> > I have FC17, and followed the steps at the wiki , i defined the ovirt
> > nightly
> > repo
> > 
> > [ovirt-nightly]
> > name=ovirt-nightly
> > baseurl=http://resources.ovirt.org/releases/nightly/rpm/Fedora/17/
> > enabled=1
> > gpgcheck=0
> > priority=1
> > protect=1
> > 
> > And performed yum install according to your guidelines.
> > It fails to find python-m2crypto
> 
> Has nothing to do with ovirt :)
> Try m2crypto please.


Worked ! I would suggest updating the WIKI
However, now I fail at webadmin - commit hash cda607c80a19dd08585fc0271ea7d57e03f9a43f

[INFO] javac option: -s
[INFO] javac option: /home/yzaslavs/work/ovirt_git/ovirt-engine/frontend/webadmin/modules/webadmin/target/generated-sources/annotations
[INFO] diagnostic /home/yzaslavs/work/ovirt_git/ovirt-engine/frontend/webadmin/modules/gwt-common/target/gwt-common-3.3.0-SNAPSHOT.jar(org/ovirt/engine/ui/common/presenter/AbstractPopupPresenterWidget.java):27: error: method getCloseButton() is already defined in interface org.ovirt.engine.ui.common.presenter.AbstractPopupPresenterWidget.ViewDef
        HasClickHandlers getCloseButton();
                         ^
[INFO] diagnostic /home/yzaslavs/work/ovirt_git/ovirt-engine/frontend/webadmin/modules/gwt-common/target/gwt-common-3.3.0-SNAPSHOT.jar(org/ovirt/engine/ui/common/presenter/AbstractPopupPresenterWidget.java):32: error: method getCloseIconButton() is already defined in interface org.ovirt.engine.ui.common.presenter.AbstractPopupPresenterWidget.ViewDef
        HasClickHandlers getCloseIconButton();

Anyone got a clue?
                         




> 
> > 
> > Can you please advise on the matter?
> > 
> > Many thanks,
> > Yair
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Eli Mesika" <emesika at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> > > Sent: Tuesday, May 14, 2013 3:45:41 AM
> > > Subject: Re: [Engine-devel] [ANN] New development environment for
> > > ovirt-engine
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > Cc: "arch" <arch at ovirt.org>, "Sharad Mishra" <snmishra at us.ibm.com>,
> > > > "Limor
> > > > Gavish" <lgavish at gmail.com>
> > > > Sent: Sunday, May 12, 2013 2:52:51 PM
> > > > Subject: [Engine-devel] [ANN] New development environment for
> > > > ovirt-engine
> > > > 
> > > > Hello all ovirt-engine developers,
> > > > 
> > > > When I first joined the ovirt project, it took me about two weeks to
> > > > setup
> > > > a
> > > > development environment, I needed to work on a bug related to
> > > > host-deploy
> > > > so
> > > > I needed an environment that could use the ssh, PKI, vdsm-bootstrap and
> > > > communicate with vdsm using SSL, this was virtually impossible to do so
> > > > without tweaking the product in a way that it is so different from
> > > > production use, that I cannot guarantee that whatever tested in
> > > > development
> > > > will actually work in production.
> > > > 
> > > > I peeked at the installation script in a hope that I can create partial
> > > > environment similar to production, but I found that the packaging
> > > > implementation makes to much assumption and is very difficult to adopt.
> > > > The
> > > > fact that I do not use fedora/rhel for my development made it even
> > > > worse.
> > > > 
> > > > I had no other option than to create rpms after each of my changes and
> > > > test
> > > > each in real production like setup.
> > > > 
> > > > It was obvious to me that the manual customization of developers to
> > > > achieve
> > > > working product will eventually break as product grow and move away
> > > > from
> > > > being developer friendly to production friendly. For example, product
> > > > defaults cannot be these which serve developers, but these which serve
> > > > production the best, or having a valid PKI setup cannot be optional any
> > > > more
> > > > as components do need to use it. Same for location of files and
> > > > configuration, for example, if we write a pluggable infrastructure for
> > > > branding, we cannot damage the interface just because developers runs
> > > > the
> > > > product in their own manual customization.
> > > > 
> > > > I took the opportunity handed to me to port the ovirt-engine to other
> > > > distributions in order to provide a development environment that is
> > > > similar
> > > > to production setup. Together with Sandro Bonazzola and Alex Lourie we
> > > > re-wrote the whole installation of the product which can also be used
> > > > to
> > > > setup the desired development environment.
> > > > 
> > > > Within this environment the product is set up using the same tools and
> > > > configuration as in production, while the process does not require
> > > > special
> > > > privileges nor changes the state of the developer machine.
> > > > 
> > > > A complete documentation is available[1], I preferred to use README
> > > > within
> > > > the source tree as wiki tend to quickly become obsolete, while
> > > > documentation
> > > > within source tree can be modified by the commit that introduces a
> > > > change.
> > > > I
> > > > will redirect to this file from the current wiki once the site will be
> > > > up.
> > > > 
> > > > In a nut shell, after installing prerequisites, build and install the
> > > > product
> > > > using:
> > > > 
> > > > $ make clean install-dev PREFIX=$HOME/ovirt-engine
> > > > 
> > > > This will run maven and create product installation at
> > > > $HOME/ovirt-engine
> > > > Next, a setup phase is required just like in production, to initialize
> > > > configuration and database:
> > > > 
> > > > $ $HOME/ovirt-engine/bin/engine-setup-2
> > > > 
> > > > You have now fully functional product, including PKI, SSL, host-deploy,
> > > > tools.
> > > > No manual database updates are required, no lose of functionality.
> > > > 
> > > > All that is left is to start the engine service:
> > > > 
> > > > $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> > > > 
> > > > Access to application:
> > > >    http://localhost:8080
> > > >    https://localhost:8443
> > > > Debugging port is opened at port 8787.
> > > > 
> > > > Farther information exists in the documentation[1].
> > > > 
> > > > There are several inherit benefits of the new environment, the major
> > > > one
> > > > is
> > > > the ability to manage several environments in parallel on the same
> > > > host.
> > > > For
> > > > example, if we develop two separate features on two branches we can
> > > > install
> > > > the product into $HOME/ovirt-engine-feature1 and
> > > > $HOME/ovirt-engine-feature-2 and have a separate database for each, if
> > > > we
> > > > modify the ports jboss is listening to we can run two instances of
> > > > engine
> > > > at
> > > > the same time!
> > > 
> > > It is not clear to me why working on 2 bugs needs 2 installations of the
> > > development environment.
> > > If you have 2 different git branches and a separate database for each,
> > > its
> > > enough , am I missing something ?
> > > I was used to create a git branch with the name of the BZ# and use
> > > create_db.sh script to create a new database with the BZ# name.
> > > Is this possible in the new method?
> > > Also, does this mean that I will have to create/configure a new workspace
> > > for
> > > eclipse each time I am starting to work on a new bug?
> > > 
> > > 
> > > Thanks
> > > 
> > > 
> > > > 
> > > > We will be happy to work with all developers to assist in porting into
> > > > the
> > > > new development environment, the simplest is to create a new database
> > > > for
> > > > this effort. Moti has a sequence of converting the existing database
> > > > owned
> > > > by postgres to be owned by the engine, Moti, can you please share that?
> > > > 
> > > > We are sure there are missing bits, we will be happy to know these so
> > > > we
> > > > can
> > > > improve.
> > > > 
> > > > I am aware that developers (especially java) are conservative, but I
> > > > ask
> > > > you
> > > > to give us a chance, so that we make it easy for developers to join the
> > > > project, and to allow us to drop the parallel effort of packaging to
> > > > production and fixing the broken development environment.
> > > > 
> > > > A special thanks to developers who took the time to test and provide
> > > > feedback
> > > > before the merged:
> > > > - Yaniv Bronheim
> > > > - Moti Asayag
> > > > - Limor Gavish
> > > > - Sharad Mishra
> > > > - Ofer Schreiber
> > > > 
> > > > We are hoping that after migration you will be find this environment
> > > > useful
> > > > and friendly,
> > > > 
> > > > Sandro Bonazzola,
> > > > Alex Lourie,
> > > > Alon Bar-Lev.
> > > > 
> > > > [1]
> > > > http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> 


From alonbl at redhat.com  Tue May 14 06:58:46 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 14 May 2013 02:58:46 -0400 (EDT)
Subject: [Engine-devel] [ANN] New development environment for ovirt-engine
In-Reply-To: <1540245909.911838.1368514552129.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
	<188337855.1067044.1368492341205.JavaMail.root@redhat.com>
	<975472192.855606.1368499159787.JavaMail.root@redhat.com>
	<998811568.829527.1368511086124.JavaMail.root@redhat.com>
	<1540245909.911838.1368514552129.JavaMail.root@redhat.com>
Message-ID: <40963367.836876.1368514726698.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>, "Daniel Erez" <derez at redhat.com>, "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: "Eli Mesika" <emesika at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> Sent: Tuesday, May 14, 2013 9:55:52 AM
> Subject: Re: [Engine-devel] [ANN] New development environment for ovirt-engine
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > Cc: "Eli Mesika" <emesika at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> > Sent: Tuesday, May 14, 2013 8:58:06 AM
> > Subject: Re: [Engine-devel] [ANN] New development environment for
> > ovirt-engine
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > To: "Eli Mesika" <emesika at redhat.com>
> > > Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> > > Sent: Tuesday, May 14, 2013 5:39:19 AM
> > > Subject: Re: [Engine-devel] [ANN] New development environment for
> > > ovirt-engine
> > > 
> > > Alon,
> > > I have FC17, and followed the steps at the wiki , i defined the ovirt
> > > nightly
> > > repo
> > > 
> > > [ovirt-nightly]
> > > name=ovirt-nightly
> > > baseurl=http://resources.ovirt.org/releases/nightly/rpm/Fedora/17/
> > > enabled=1
> > > gpgcheck=0
> > > priority=1
> > > protect=1
> > > 
> > > And performed yum install according to your guidelines.
> > > It fails to find python-m2crypto
> > 
> > Has nothing to do with ovirt :)
> > Try m2crypto please.
> 
> 
> Worked ! I would suggest updating the WIKI
> However, now I fail at webadmin - commit hash
> cda607c80a19dd08585fc0271ea7d57e03f9a43f

Please open a new thread, this is unrelated.

> 
> [INFO] javac option: -s
> [INFO] javac option:
> /home/yzaslavs/work/ovirt_git/ovirt-engine/frontend/webadmin/modules/webadmin/target/generated-sources/annotations
> [INFO] diagnostic
> /home/yzaslavs/work/ovirt_git/ovirt-engine/frontend/webadmin/modules/gwt-common/target/gwt-common-3.3.0-SNAPSHOT.jar(org/ovirt/engine/ui/common/presenter/AbstractPopupPresenterWidget.java):27:
> error: method getCloseButton() is already defined in interface
> org.ovirt.engine.ui.common.presenter.AbstractPopupPresenterWidget.ViewDef
>         HasClickHandlers getCloseButton();
>                          ^
> [INFO] diagnostic
> /home/yzaslavs/work/ovirt_git/ovirt-engine/frontend/webadmin/modules/gwt-common/target/gwt-common-3.3.0-SNAPSHOT.jar(org/ovirt/engine/ui/common/presenter/AbstractPopupPresenterWidget.java):32:
> error: method getCloseIconButton() is already defined in interface
> org.ovirt.engine.ui.common.presenter.AbstractPopupPresenterWidget.ViewDef
>         HasClickHandlers getCloseIconButton();
> 
> Anyone got a clue?
>                          
> 
> 
> 
> 
> > 
> > > 
> > > Can you please advise on the matter?
> > > 
> > > Many thanks,
> > > Yair
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> > > > Sent: Tuesday, May 14, 2013 3:45:41 AM
> > > > Subject: Re: [Engine-devel] [ANN] New development environment for
> > > > ovirt-engine
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > > Cc: "arch" <arch at ovirt.org>, "Sharad Mishra" <snmishra at us.ibm.com>,
> > > > > "Limor
> > > > > Gavish" <lgavish at gmail.com>
> > > > > Sent: Sunday, May 12, 2013 2:52:51 PM
> > > > > Subject: [Engine-devel] [ANN] New development environment for
> > > > > ovirt-engine
> > > > > 
> > > > > Hello all ovirt-engine developers,
> > > > > 
> > > > > When I first joined the ovirt project, it took me about two weeks to
> > > > > setup
> > > > > a
> > > > > development environment, I needed to work on a bug related to
> > > > > host-deploy
> > > > > so
> > > > > I needed an environment that could use the ssh, PKI, vdsm-bootstrap
> > > > > and
> > > > > communicate with vdsm using SSL, this was virtually impossible to do
> > > > > so
> > > > > without tweaking the product in a way that it is so different from
> > > > > production use, that I cannot guarantee that whatever tested in
> > > > > development
> > > > > will actually work in production.
> > > > > 
> > > > > I peeked at the installation script in a hope that I can create
> > > > > partial
> > > > > environment similar to production, but I found that the packaging
> > > > > implementation makes to much assumption and is very difficult to
> > > > > adopt.
> > > > > The
> > > > > fact that I do not use fedora/rhel for my development made it even
> > > > > worse.
> > > > > 
> > > > > I had no other option than to create rpms after each of my changes
> > > > > and
> > > > > test
> > > > > each in real production like setup.
> > > > > 
> > > > > It was obvious to me that the manual customization of developers to
> > > > > achieve
> > > > > working product will eventually break as product grow and move away
> > > > > from
> > > > > being developer friendly to production friendly. For example, product
> > > > > defaults cannot be these which serve developers, but these which
> > > > > serve
> > > > > production the best, or having a valid PKI setup cannot be optional
> > > > > any
> > > > > more
> > > > > as components do need to use it. Same for location of files and
> > > > > configuration, for example, if we write a pluggable infrastructure
> > > > > for
> > > > > branding, we cannot damage the interface just because developers runs
> > > > > the
> > > > > product in their own manual customization.
> > > > > 
> > > > > I took the opportunity handed to me to port the ovirt-engine to other
> > > > > distributions in order to provide a development environment that is
> > > > > similar
> > > > > to production setup. Together with Sandro Bonazzola and Alex Lourie
> > > > > we
> > > > > re-wrote the whole installation of the product which can also be used
> > > > > to
> > > > > setup the desired development environment.
> > > > > 
> > > > > Within this environment the product is set up using the same tools
> > > > > and
> > > > > configuration as in production, while the process does not require
> > > > > special
> > > > > privileges nor changes the state of the developer machine.
> > > > > 
> > > > > A complete documentation is available[1], I preferred to use README
> > > > > within
> > > > > the source tree as wiki tend to quickly become obsolete, while
> > > > > documentation
> > > > > within source tree can be modified by the commit that introduces a
> > > > > change.
> > > > > I
> > > > > will redirect to this file from the current wiki once the site will
> > > > > be
> > > > > up.
> > > > > 
> > > > > In a nut shell, after installing prerequisites, build and install the
> > > > > product
> > > > > using:
> > > > > 
> > > > > $ make clean install-dev PREFIX=$HOME/ovirt-engine
> > > > > 
> > > > > This will run maven and create product installation at
> > > > > $HOME/ovirt-engine
> > > > > Next, a setup phase is required just like in production, to
> > > > > initialize
> > > > > configuration and database:
> > > > > 
> > > > > $ $HOME/ovirt-engine/bin/engine-setup-2
> > > > > 
> > > > > You have now fully functional product, including PKI, SSL,
> > > > > host-deploy,
> > > > > tools.
> > > > > No manual database updates are required, no lose of functionality.
> > > > > 
> > > > > All that is left is to start the engine service:
> > > > > 
> > > > > $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py
> > > > > start
> > > > > 
> > > > > Access to application:
> > > > >    http://localhost:8080
> > > > >    https://localhost:8443
> > > > > Debugging port is opened at port 8787.
> > > > > 
> > > > > Farther information exists in the documentation[1].
> > > > > 
> > > > > There are several inherit benefits of the new environment, the major
> > > > > one
> > > > > is
> > > > > the ability to manage several environments in parallel on the same
> > > > > host.
> > > > > For
> > > > > example, if we develop two separate features on two branches we can
> > > > > install
> > > > > the product into $HOME/ovirt-engine-feature1 and
> > > > > $HOME/ovirt-engine-feature-2 and have a separate database for each,
> > > > > if
> > > > > we
> > > > > modify the ports jboss is listening to we can run two instances of
> > > > > engine
> > > > > at
> > > > > the same time!
> > > > 
> > > > It is not clear to me why working on 2 bugs needs 2 installations of
> > > > the
> > > > development environment.
> > > > If you have 2 different git branches and a separate database for each,
> > > > its
> > > > enough , am I missing something ?
> > > > I was used to create a git branch with the name of the BZ# and use
> > > > create_db.sh script to create a new database with the BZ# name.
> > > > Is this possible in the new method?
> > > > Also, does this mean that I will have to create/configure a new
> > > > workspace
> > > > for
> > > > eclipse each time I am starting to work on a new bug?
> > > > 
> > > > 
> > > > Thanks
> > > > 
> > > > 
> > > > > 
> > > > > We will be happy to work with all developers to assist in porting
> > > > > into
> > > > > the
> > > > > new development environment, the simplest is to create a new database
> > > > > for
> > > > > this effort. Moti has a sequence of converting the existing database
> > > > > owned
> > > > > by postgres to be owned by the engine, Moti, can you please share
> > > > > that?
> > > > > 
> > > > > We are sure there are missing bits, we will be happy to know these so
> > > > > we
> > > > > can
> > > > > improve.
> > > > > 
> > > > > I am aware that developers (especially java) are conservative, but I
> > > > > ask
> > > > > you
> > > > > to give us a chance, so that we make it easy for developers to join
> > > > > the
> > > > > project, and to allow us to drop the parallel effort of packaging to
> > > > > production and fixing the broken development environment.
> > > > > 
> > > > > A special thanks to developers who took the time to test and provide
> > > > > feedback
> > > > > before the merged:
> > > > > - Yaniv Bronheim
> > > > > - Moti Asayag
> > > > > - Limor Gavish
> > > > > - Sharad Mishra
> > > > > - Ofer Schreiber
> > > > > 
> > > > > We are hoping that after migration you will be find this environment
> > > > > useful
> > > > > and friendly,
> > > > > 
> > > > > Sandro Bonazzola,
> > > > > Alex Lourie,
> > > > > Alon Bar-Lev.
> > > > > 
> > > > > [1]
> > > > > http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > 
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > 
> > 
> 


From emesika at redhat.com  Tue May 14 10:32:39 2013
From: emesika at redhat.com (Eli Mesika)
Date: Tue, 14 May 2013 06:32:39 -0400 (EDT)
Subject: [Engine-devel] [ANN] New development environment for ovirt-engine
In-Reply-To: <1732269511.831688.1368512324398.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
	<188337855.1067044.1368492341205.JavaMail.root@redhat.com>
	<1732269511.831688.1368512324398.JavaMail.root@redhat.com>
Message-ID: <1515903557.1242775.1368527559390.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> Sent: Tuesday, May 14, 2013 9:18:44 AM
> Subject: Re: [Engine-devel] [ANN] New development environment for ovirt-engine
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> > Sent: Tuesday, May 14, 2013 3:45:41 AM
> > Subject: Re: [Engine-devel] [ANN] New development environment for
> > ovirt-engine
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Cc: "arch" <arch at ovirt.org>, "Sharad Mishra" <snmishra at us.ibm.com>,
> > > "Limor
> > > Gavish" <lgavish at gmail.com>
> > > Sent: Sunday, May 12, 2013 2:52:51 PM
> > > Subject: [Engine-devel] [ANN] New development environment for
> > > ovirt-engine
> > > 
> > > Hello all ovirt-engine developers,
> > > 
> > > When I first joined the ovirt project, it took me about two weeks to
> > > setup
> > > a
> > > development environment, I needed to work on a bug related to host-deploy
> > > so
> > > I needed an environment that could use the ssh, PKI, vdsm-bootstrap and
> > > communicate with vdsm using SSL, this was virtually impossible to do so
> > > without tweaking the product in a way that it is so different from
> > > production use, that I cannot guarantee that whatever tested in
> > > development
> > > will actually work in production.
> > > 
> > > I peeked at the installation script in a hope that I can create partial
> > > environment similar to production, but I found that the packaging
> > > implementation makes to much assumption and is very difficult to adopt.
> > > The
> > > fact that I do not use fedora/rhel for my development made it even worse.
> > > 
> > > I had no other option than to create rpms after each of my changes and
> > > test
> > > each in real production like setup.
> > > 
> > > It was obvious to me that the manual customization of developers to
> > > achieve
> > > working product will eventually break as product grow and move away from
> > > being developer friendly to production friendly. For example, product
> > > defaults cannot be these which serve developers, but these which serve
> > > production the best, or having a valid PKI setup cannot be optional any
> > > more
> > > as components do need to use it. Same for location of files and
> > > configuration, for example, if we write a pluggable infrastructure for
> > > branding, we cannot damage the interface just because developers runs the
> > > product in their own manual customization.
> > > 
> > > I took the opportunity handed to me to port the ovirt-engine to other
> > > distributions in order to provide a development environment that is
> > > similar
> > > to production setup. Together with Sandro Bonazzola and Alex Lourie we
> > > re-wrote the whole installation of the product which can also be used to
> > > setup the desired development environment.
> > > 
> > > Within this environment the product is set up using the same tools and
> > > configuration as in production, while the process does not require
> > > special
> > > privileges nor changes the state of the developer machine.
> > > 
> > > A complete documentation is available[1], I preferred to use README
> > > within
> > > the source tree as wiki tend to quickly become obsolete, while
> > > documentation
> > > within source tree can be modified by the commit that introduces a
> > > change.
> > > I
> > > will redirect to this file from the current wiki once the site will be
> > > up.
> > > 
> > > In a nut shell, after installing prerequisites, build and install the
> > > product
> > > using:
> > > 
> > > $ make clean install-dev PREFIX=$HOME/ovirt-engine
> > > 
> > > This will run maven and create product installation at $HOME/ovirt-engine
> > > Next, a setup phase is required just like in production, to initialize
> > > configuration and database:
> > > 
> > > $ $HOME/ovirt-engine/bin/engine-setup-2
> > > 
> > > You have now fully functional product, including PKI, SSL, host-deploy,
> > > tools.
> > > No manual database updates are required, no lose of functionality.
> > > 
> > > All that is left is to start the engine service:
> > > 
> > > $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> > > 
> > > Access to application:
> > >    http://localhost:8080
> > >    https://localhost:8443
> > > Debugging port is opened at port 8787.
> > > 
> > > Farther information exists in the documentation[1].
> > > 
> > > There are several inherit benefits of the new environment, the major one
> > > is
> > > the ability to manage several environments in parallel on the same host.
> > > For
> > > example, if we develop two separate features on two branches we can
> > > install
> > > the product into $HOME/ovirt-engine-feature1 and
> > > $HOME/ovirt-engine-feature-2 and have a separate database for each, if we
> > > modify the ports jboss is listening to we can run two instances of engine
> > > at
> > > the same time!
> > 
> > It is not clear to me why working on 2 bugs needs 2 installations of the
> > development environment.
> > If you have 2 different git branches and a separate database for each, its
> > enough , am I missing something ?
> 
> You have two different git branches, so you have two different binaries out
> of the build, right?
> These binaries should reside some where.
> Currently you are probably use maven deploy or something similar into single
> jboss, without proper environment, overriding each time the other branch's
> binaries.
> What if there is a change in configuration between the two? more
> prerequisites, different service configuration? different database schema?
> 
> To make it easy, you can just duplicate the development environment, and be
> sure you are up and running.
> 
> If you still want to take the chance you can... just make install-dev
> PREFIX=$HOME/same-place and you will have the behavior of overriding the
> same environment, and hoping for the best.

That's good , thanks

> 
> > I was used to create a git branch with the name of the BZ# and use
> > create_db.sh script to create a new database with the BZ# name.
> > Is this possible in the new method?
> 
> Yes.
> You create an empty database manually, let's say engine-branch1.
> Then you install the environment to own location, let say make install-dev
> PREFIX=$HOME/ovirt-engine-branch1
> When running engine-setup-2 you instruct the setup to use engine-branch1
> database.
> This database will be created out of the new branch's create_db.sh.
> create_db.sh should not run manually now.
> 
> However, if you insist of creating a database manually and modify an existing
> environment to use the new database, it is possible as well.
> Edit $PREFIX/etc/ovirt-engine/engine.conf.d/10-setup-database.conf, and
> specify where database is, then start the engine service.

Great, thanks

> 
> > Also, does this mean that I will have to create/configure a new workspace
> > for
> > eclipse each time I am starting to work on a new bug?
> 
> This I do not know. How does it work now when you switch branches?

I will check that, maybe this is unrelated ...

Thanks again , will test that ASAP
> 
> > 
> > 
> > Thanks
> > 
> > 
> > > 
> > > We will be happy to work with all developers to assist in porting into
> > > the
> > > new development environment, the simplest is to create a new database for
> > > this effort. Moti has a sequence of converting the existing database
> > > owned
> > > by postgres to be owned by the engine, Moti, can you please share that?
> > > 
> > > We are sure there are missing bits, we will be happy to know these so we
> > > can
> > > improve.
> > > 
> > > I am aware that developers (especially java) are conservative, but I ask
> > > you
> > > to give us a chance, so that we make it easy for developers to join the
> > > project, and to allow us to drop the parallel effort of packaging to
> > > production and fixing the broken development environment.
> > > 
> > > A special thanks to developers who took the time to test and provide
> > > feedback
> > > before the merged:
> > > - Yaniv Bronheim
> > > - Moti Asayag
> > > - Limor Gavish
> > > - Sharad Mishra
> > > - Ofer Schreiber
> > > 
> > > We are hoping that after migration you will be find this environment
> > > useful
> > > and friendly,
> > > 
> > > Sandro Bonazzola,
> > > Alex Lourie,
> > > Alon Bar-Lev.
> > > 
> > > [1]
> > > http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> 


From masayag at redhat.com  Tue May 14 10:54:21 2013
From: masayag at redhat.com (Moti Asayag)
Date: Tue, 14 May 2013 06:54:21 -0400 (EDT)
Subject: [ANN] New development environment for ovirt-engine
In-Reply-To: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
Message-ID: <248944163.1356174.1368528861600.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Cc: "Yaniv Bronheim" <ybronhei at redhat.com>, "Moti Asayag" <masayag at redhat.com>, "Limor Gavish" <lgavish at gmail.com>,
> "Sharad Mishra" <snmishra at us.ibm.com>, "Alex Lourie" <alourie at redhat.com>, "Sandro Bonazzola" <sbonazzo at redhat.com>,
> "arch" <arch at ovirt.org>, "Ofer Schreiber" <oschreib at redhat.com>
> Sent: Sunday, May 12, 2013 2:52:51 PM
> Subject: [ANN] New development environment for ovirt-engine
> 
> Hello all ovirt-engine developers,
> 
> When I first joined the ovirt project, it took me about two weeks to setup a
> development environment, I needed to work on a bug related to host-deploy so
> I needed an environment that could use the ssh, PKI, vdsm-bootstrap and
> communicate with vdsm using SSL, this was virtually impossible to do so
> without tweaking the product in a way that it is so different from
> production use, that I cannot guarantee that whatever tested in development
> will actually work in production.
> 
> I peeked at the installation script in a hope that I can create partial
> environment similar to production, but I found that the packaging
> implementation makes to much assumption and is very difficult to adopt. The
> fact that I do not use fedora/rhel for my development made it even worse.
> 
> I had no other option than to create rpms after each of my changes and test
> each in real production like setup.
> 
> It was obvious to me that the manual customization of developers to achieve
> working product will eventually break as product grow and move away from
> being developer friendly to production friendly. For example, product
> defaults cannot be these which serve developers, but these which serve
> production the best, or having a valid PKI setup cannot be optional any more
> as components do need to use it. Same for location of files and
> configuration, for example, if we write a pluggable infrastructure for
> branding, we cannot damage the interface just because developers runs the
> product in their own manual customization.
> 
> I took the opportunity handed to me to port the ovirt-engine to other
> distributions in order to provide a development environment that is similar
> to production setup. Together with Sandro Bonazzola and Alex Lourie we
> re-wrote the whole installation of the product which can also be used to
> setup the desired development environment.
> 
> Within this environment the product is set up using the same tools and
> configuration as in production, while the process does not require special
> privileges nor changes the state of the developer machine.
> 
> A complete documentation is available[1], I preferred to use README within
> the source tree as wiki tend to quickly become obsolete, while documentation
> within source tree can be modified by the commit that introduces a change. I
> will redirect to this file from the current wiki once the site will be up.
> 
> In a nut shell, after installing prerequisites, build and install the product
> using:
> 
> $ make clean install-dev PREFIX=$HOME/ovirt-engine
> 
> This will run maven and create product installation at $HOME/ovirt-engine
> Next, a setup phase is required just like in production, to initialize
> configuration and database:
> 
> $ $HOME/ovirt-engine/bin/engine-setup-2
> 
> You have now fully functional product, including PKI, SSL, host-deploy,
> tools.
> No manual database updates are required, no lose of functionality.
> 
> All that is left is to start the engine service:
> 
> $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> 
> Access to application:
>    http://localhost:8080
>    https://localhost:8443
> Debugging port is opened at port 8787.
> 
> Farther information exists in the documentation[1].
> 
> There are several inherit benefits of the new environment, the major one is
> the ability to manage several environments in parallel on the same host. For
> example, if we develop two separate features on two branches we can install
> the product into $HOME/ovirt-engine-feature1 and
> $HOME/ovirt-engine-feature-2 and have a separate database for each, if we
> modify the ports jboss is listening to we can run two instances of engine at
> the same time!
> 
> We will be happy to work with all developers to assist in porting into the
> new development environment, the simplest is to create a new database for
> this effort. Moti has a sequence of converting the existing database owned
> by postgres to be owned by the engine, Moti, can you please share that?
> 

Reusing an existing DB schema requires a bit more work since the installation 
of dev-env advise using database as a user and not a superuser like 'postgres'
user used to create the database originally. 
Therefore if wishes to use user 'engine' as in the instructions, there is a need
to change the current schema owner and also the ownership of all of its objects.

The easiest path I found for that purpose is:
1. Create a dump of the database using the script in [1].
2. Rename the owner in the dump file to the new owner (s/OWNER TO postgres/OWNER TO engine/g).
3. Import the dump file to the new DB owned by the engine user using [2] (provide -r flag to
drop the former db).

[1] ovirt-engine/backend/manager/dbscripts/backup.sh
[2] ovirt-engine/backend/manager/dbscripts/restore.sh

> We are sure there are missing bits, we will be happy to know these so we can
> improve.
> 
> I am aware that developers (especially java) are conservative, but I ask you
> to give us a chance, so that we make it easy for developers to join the
> project, and to allow us to drop the parallel effort of packaging to
> production and fixing the broken development environment.
> 
> A special thanks to developers who took the time to test and provide feedback
> before the merged:
> - Yaniv Bronheim
> - Moti Asayag
> - Limor Gavish
> - Sharad Mishra
> - Ofer Schreiber
> 
> We are hoping that after migration you will be find this environment useful
> and friendly,
> 
> Sandro Bonazzola,
> Alex Lourie,
> Alon Bar-Lev.
> 
> [1]
> http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
> 


From leonardo.bianconi at eldorado.org.br  Tue May 14 18:05:01 2013
From: leonardo.bianconi at eldorado.org.br (Leonardo Bianconi)
Date: Tue, 14 May 2013 18:05:01 +0000
Subject: oVirt on IBM POWER (PPC64) - new feature contributors
Message-ID: <50EB20226B72D6419356FC320AB62B871896B600@SERV070.corp.eldorado.org.br>

Dear all

We would like to introduce ourselves: Leonardo Bianconi and Vitor Lima.

We would like to work on the features "Engine support for PPC64" (http://wiki.ovirt.org/Features/Engine_support_for_PPC64) and the "Vdsm for PPC64" (http://wiki.ovirt.org/Features/Vdsm_for_PPC64). This work has already been started by some developers at IBM.

We would be happy to hear opinions and comments.

About libosinfo:
=============

In the previous discussion about this topic (http://lists.ovirt.org/pipermail/arch/2012-November/000976.html), occurred in November 2012, it was suggested that integrating the libosinfo into the engine would be a better way to handle the differences between the architectures that would be supported in the future.

Is this approach still valid? If so, when will it be available? It seems to be a dependency for oVirt "Engine_support_for_PPC64" feature implementation.

Best regards

Leonardo Bianconi / Vitor Lima



From vfeenstr at redhat.com  Wed May 15 04:53:25 2013
From: vfeenstr at redhat.com (Vinzenz Feenstra)
Date: Wed, 15 May 2013 06:53:25 +0200
Subject: oVirt on IBM POWER (PPC64) - new feature contributors
In-Reply-To: <50EB20226B72D6419356FC320AB62B871896B600@SERV070.corp.eldorado.org.br>
References: <50EB20226B72D6419356FC320AB62B871896B600@SERV070.corp.eldorado.org.br>
Message-ID: <519314C5.20706@redhat.com>

On 05/14/2013 08:05 PM, Leonardo Bianconi wrote:
> Dear all
>
> We would like to introduce ourselves: Leonardo Bianconi and Vitor Lima.
>
> We would like to work on the features "Engine support for PPC64" (http://wiki.ovirt.org/Features/Engine_support_for_PPC64) and the "Vdsm for PPC64" (http://wiki.ovirt.org/Features/Vdsm_for_PPC64). This work has already been started by some developers at IBM.
>
> We would be happy to hear opinions and comments.
>
> About libosinfo:
> =============
>
> In the previous discussion about this topic (http://lists.ovirt.org/pipermail/arch/2012-November/000976.html), occurred in November 2012, it was suggested that integrating the libosinfo into the engine would be a better way to handle the differences between the architectures that would be supported in the future.
>
> Is this approach still valid? If so, when will it be available? It seems to be a dependency for oVirt "Engine_support_for_PPC64" feature implementation.
Roy is the best to answer this I guess :-)
>
> Best regards
>
> Leonardo Bianconi / Vitor Lima
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch


-- 
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com



From mburns at redhat.com  Wed May 15 14:23:10 2013
From: mburns at redhat.com (Mike Burns)
Date: Wed, 15 May 2013 10:23:10 -0400
Subject: oVirt Weekly Meeting Minutes -- 2013-05-15
Message-ID: <51939A4E.7090507@redhat.com>

Minutes: 
http://ovirt.org/meetings/ovirt/2013/ovirt.2013-05-15-14.04.html
Minutes (text): 
http://ovirt.org/meetings/ovirt/2013/ovirt.2013-05-15-14.04.txt
Log: 
http://ovirt.org/meetings/ovirt/2013/ovirt.2013-05-15-14.04.log.html


============================
#ovirt: oVirt Weekly Meeting
============================


Meeting started by mburns at 14:04:53 UTC. The full logs are available
at http://ovirt.org/meetings/ovirt/2013/ovirt.2013-05-15-14.04.log.html
.



Meeting summary
---------------
* agenda and roll call  (mburns, 14:05:06)
   * most of the maintainers aren't available today, so a slightly ad-hoc
     agenda...  (mburns, 14:05:41)
   * need better status communication on features  (mburns, 14:14:00)
   * need to review features for must/should release criteria  (mburns,
     14:14:12)
   * ACTION: mburns to update the release management page with as many
     details as he knows  (mburns, 14:14:34)
   * ACTION: mburns to reach out to other maintainers to make sure their
     pages are updated as well  (mburns, 14:15:19)

*   (mburns, 14:16:14)

* Other Topics  (mburns, 14:16:20)

Meeting ended at 14:22:15 UTC.




Action Items
------------
* mburns to update the release management page with as many details as
   he knows
* mburns to reach out to other maintainers to make sure their pages are
   updated as well




Action Items, by person
-----------------------
* mburns
   * mburns to update the release management page with as many details as
     he knows
   * mburns to reach out to other maintainers to make sure their pages
     are updated as well
* **UNASSIGNED**
   * (none)




People Present (lines said)
---------------------------
* mburns (27)
* dneary (19)
* ovirtbot (2)
* jb_netapp (1)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot


From dneary at redhat.com  Wed May 15 15:21:46 2013
From: dneary at redhat.com (Dave Neary)
Date: Wed, 15 May 2013 17:21:46 +0200
Subject: 3.3 release engineering
In-Reply-To: <518834D7.3030708@redhat.com>
References: <518834D7.3030708@redhat.com>
Message-ID: <5193A80A.4020909@redhat.com>

Hi,

On 05/07/2013 12:55 AM, Dave Neary wrote:
> http://www.ovirt.org/oVirt_3.3_release-management

<snip>

> Can I suggest one improvement which could be done this week, please?
> There's no way of knowing from this page which features in the MUST,
> SHOULD lists are done and just awaiting release, in need of QE and
> testing, being actively worked on (and if so, by who?) and which
> features are there aspirationally and won't be worked on unless someone
> volunteers to pick them up.

<snip>

> If you're working on a feature that's in this page and it's not
> finished, would you mind adding a link to the feature page (if there is
> one) and adding your name to the feature, please? And if the feature is
> done, please link to the feature page, or some other resource that
> allows people to use and test it - and (if possible) the changelog
> entry/gerrit where the patch was included.

It's been a week since I sent this email, and in that time there have
been 3 edits to the page - 2 adding new features to the infra section,
and one linking to a series of UX patches for the dashboard.

However, there has been no progress towards indicating whether the
features listed as "MUST" or "SHOULD" are actually ready for
release/testing at this point.

We're less than 2 weeks from feature freeze, 3 weeks from a test day,
with no clear test plan, and no indication on this stage of whether
features listed in the "Features" section are ready to go, or are still
in progress.

If you have added a feature here in the past, please go back and add a
sub-list with any known bugs, and a line with the status of this
(planned, in progress, complete but untested, ready to go). This will
greatly assist in understanding whether features are going into the 3.3
release, or are instead candidates for bumping to 3.4.

Underneath the "No blocker bugs" and similar items, I have also added a
sub-list section where we can list currently known bugs in each
category. It would be a good idea, for example, to either link to
individual bugs or to a saved search in Bugzilla for the various
categories (release blockers, data corruption issues, etc).

Thanks!
Dave.


-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From dneary at redhat.com  Wed May 15 15:24:30 2013
From: dneary at redhat.com (Dave Neary)
Date: Wed, 15 May 2013 17:24:30 +0200
Subject: oVirt on IBM POWER (PPC64) - new feature contributors
In-Reply-To: <50EB20226B72D6419356FC320AB62B871896B600@SERV070.corp.eldorado.org.br>
References: <50EB20226B72D6419356FC320AB62B871896B600@SERV070.corp.eldorado.org.br>
Message-ID: <5193A8AE.5000600@redhat.com>

Hi,

On 05/14/2013 08:05 PM, Leonardo Bianconi wrote:
> We would like to introduce ourselves: Leonardo Bianconi and Vitor Lima.

Welcome!

> We would like to work on the features "Engine support for PPC64" (http://wiki.ovirt.org/Features/Engine_support_for_PPC64) and the "Vdsm for PPC64" (http://wiki.ovirt.org/Features/Vdsm_for_PPC64). This work has already been started by some developers at IBM.

<snip>

> About libosinfo:
> =============
> 
> In the previous discussion about this topic (http://lists.ovirt.org/pipermail/arch/2012-November/000976.html), occurred in November 2012, it was suggested that integrating the libosinfo into the engine would be a better way to handle the differences between the architectures that would be supported in the future.
> 
> Is this approach still valid? If so, when will it be available? It seems to be a dependency for oVirt "Engine_support_for_PPC64" feature implementation.


This is great news. I don't know who, specifically, has been working on
this issue in IBM - perhaps Adam Litke (CCed) can update you on the
progress that has been made.

Cheers,
Dave.

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From kwade at redhat.com  Fri May 17 04:39:34 2013
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Thu, 16 May 2013 21:39:34 -0700
Subject: Outage :: lists.ovirt.org/resources.ovirt.org :: 2013-05-17 04:40 UTC
Message-ID: <5195B486.5030002@redhat.com>

There is about to be an outage of resources.ovirt.org/lists.ovirt.org
for a five minute reboot.

The outage is occurring directly after I send this email (and hopefully
after it's already delivered to you.)

== Details ==

We have older versions of some packages that have security fixes not yet
applied.

I'm updating the kernel and other packages then rebooting to remove the
risk before this announcement gets out.

== Affected services ==

* lists.ovirt.org
* resources.ovirt.org
* ovirtbot

=== Not-affected services ==

* gerrit.ovirt.org
* jenkins.ovirt.org
* www.ovirt.org

== Future plans ==

Get the infra at ovirt.org list or team on an advisory channel so we are
aware of package updates. Then coordinate planned downtime to upgrade.

-- 
Karsten 'quaid' Wade
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20130516/1b811842/attachment.sig>

From kwade at redhat.com  Fri May 17 04:46:34 2013
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Thu, 16 May 2013 21:46:34 -0700
Subject: Outage :: lists.ovirt.org/resources.ovirt.org :: 2013-05-17 04:40
	UTC
In-Reply-To: <5195B486.5030002@redhat.com>
References: <5195B486.5030002@redhat.com>
Message-ID: <5195B62A.1060204@redhat.com>

This outage is complete, all seems to be well. If you notice a problem,
contact us via infra at ovirt.org.

On 05/16/2013 09:39 PM, Karsten 'quaid' Wade wrote:
> There is about to be an outage of resources.ovirt.org/lists.ovirt.org
> for a five minute reboot.
> 
> The outage is occurring directly after I send this email (and hopefully
> after it's already delivered to you.)
> 
> == Details ==
> 
> We have older versions of some packages that have security fixes not yet
> applied.
> 
> I'm updating the kernel and other packages then rebooting to remove the
> risk before this announcement gets out.
> 
> == Affected services ==
> 
> * lists.ovirt.org
> * resources.ovirt.org
> * ovirtbot
> 
> === Not-affected services ==
> 
> * gerrit.ovirt.org
> * jenkins.ovirt.org
> * www.ovirt.org
> 
> == Future plans ==
> 
> Get the infra at ovirt.org list or team on an advisory channel so we are
> aware of package updates. Then coordinate planned downtime to upgrade.
> 
> 
> 
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 


-- 
Karsten 'quaid' Wade
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20130516/31053dd5/attachment.sig>

From mburns at redhat.com  Fri May 17 11:31:41 2013
From: mburns at redhat.com (Mike Burns)
Date: Fri, 17 May 2013 07:31:41 -0400
Subject: Need a new gerrit repo for ovirt-node-plugin-vdsm
Message-ID: <5196151D.2050307@redhat.com>

As part of the move to a more universal oVirt Node during the 3.3 time 
frame[1], a separate repo is needed for a plugin to allow oVirt Node to 
communicate with oVirt Engine [2].

In order to provide this plugin, I need a gerrit repo created and also 
need consensus on a name.

Name proposal:
ovirt-node-plugin-vdsm
ovirt-node-plugin-engine
ovirt-engine-node-plugin

I'm rather indifferent to what we call this, so I figured I'd include 
the arch@ list to get feedback.

Thanks

Mike

[1] http://www.ovirt.org/Features/Universal_Image
[2] http://www.ovirt.org/Features/Node_vdsm_plugin


From dougsland at redhat.com  Fri May 17 14:02:34 2013
From: dougsland at redhat.com (Douglas Schilling Landgraf)
Date: Fri, 17 May 2013 10:02:34 -0400
Subject: Need a new gerrit repo for ovirt-node-plugin-vdsm
In-Reply-To: <5196151D.2050307@redhat.com>
References: <5196151D.2050307@redhat.com>
Message-ID: <5196387A.9070604@redhat.com>

On 05/17/2013 07:31 AM, Mike Burns wrote:
> As part of the move to a more universal oVirt Node during the 3.3 time
> frame[1], a separate repo is needed for a plugin to allow oVirt Node to
> communicate with oVirt Engine [2].
>
> In order to provide this plugin, I need a gerrit repo created and also
> need consensus on a name.
>
> Name proposal:
> ovirt-node-plugin-vdsm
I would go with that one.

> I'm rather indifferent to what we call this, so I figured I'd include
> the arch@ list to get feedback.
>
> Thanks
>
> Mike
>
> [1] http://www.ovirt.org/Features/Universal_Image
> [2] http://www.ovirt.org/Features/Node_vdsm_plugin
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch


-- 
Cheers
Douglas


From danken at redhat.com  Sun May 19 12:21:11 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Sun, 19 May 2013 15:21:11 +0300
Subject: Need a new gerrit repo for ovirt-node-plugin-vdsm
In-Reply-To: <5196387A.9070604@redhat.com>
References: <5196151D.2050307@redhat.com>
 <5196387A.9070604@redhat.com>
Message-ID: <20130519122111.GC2144@redhat.com>

On Fri, May 17, 2013 at 10:02:34AM -0400, Douglas Schilling Landgraf wrote:
> On 05/17/2013 07:31 AM, Mike Burns wrote:
> >As part of the move to a more universal oVirt Node during the 3.3 time
> >frame[1], a separate repo is needed for a plugin to allow oVirt Node to
> >communicate with oVirt Engine [2].
> >
> >In order to provide this plugin, I need a gerrit repo created and also
> >need consensus on a name.
> >
> >Name proposal:
> >ovirt-node-plugin-vdsm
> I would go with that one.

me2, though I do not have a strong opinion or explanation.

> 
> >I'm rather indifferent to what we call this, so I figured I'd include
> >the arch@ list to get feedback.
> >
> >Thanks
> >
> >Mike
> >
> >[1] http://www.ovirt.org/Features/Universal_Image
> >[2] http://www.ovirt.org/Features/Node_vdsm_plugin


From liumbj at linux.vnet.ibm.com  Mon May 20 03:07:53 2013
From: liumbj at linux.vnet.ibm.com (Mei Liu)
Date: Mon, 20 May 2013 11:07:53 +0800
Subject: add blkIoTune support for a specific device at vm creation
Message-ID: <51999389.6010705@linux.vnet.ibm.com>

Hi all,
I would like to add blkIoTune support for a specific device at vm creation.

The code parses the 'blkIoTune' descrption for block devices at vm creation
time and adds iotune tag accordingly.

e.g.
Adding 'blkIoTune':{'read_bytes_sec': 6120000, 'total_iops_sec': 800} for a
block device will add the following in dom xml for that device.

<iotune>
      <read_bytes_sec>6120000</read_bytes_sec>
      <total_iops_sec>800</total_iops_sec>
</iotune>

The patch is under review in http://gerrit.ovirt.org/#/c/14636/ .

Does the patch meet the requirement of the engine or the whole 
architecture? Are the new parameters properly placed?  Any suggestions 
are welcomed.

TIA.

Best reagrds,
Mei Liu (Rose)



From lpeer at redhat.com  Mon May 20 11:49:18 2013
From: lpeer at redhat.com (Livnat Peer)
Date: Mon, 20 May 2013 14:49:18 +0300
Subject: feature suggestion: initial generation of management network
In-Reply-To: <20121225122722.GG7274@redhat.com>
References: <20121225122722.GG7274@redhat.com>
Message-ID: <519A0DBE.4050804@redhat.com>

This is a summary of the thread so far (and the AI)-

- There is an agreement we do not need machine boot in the installation
sequence.

- The current default behavior is to reboot after host installation (in
Virt)

** We are going to change current behavior in 3.3 and remove the reboot
from the host installation flow **

- Today we have a flag in the REST API to avoid host reboot,we'll
deprecate this flag since this is going to be the default behavior after
the change (and booting after installation won't be available).

- Since host reboot is not needed in the host install flow we avoid
adding VDSM verb for reboot at this point. The discussion if to do such
a verb via ssh or VDSM can be done in the context were the verb is going
to be used.


Thanks, Livnat




On 12/25/2012 02:27 PM, Dan Kenigsberg wrote:
> Current condition:
> ==================
> The management network, named ovirtmgmt, is created during host
> bootstrap. It consists of a bridge device, connected to the network
> device that was used to communicate with Engine (nic, bonding or vlan).
> It inherits its ip settings from the latter device.
> 
> Why Is the Management Network Needed?
> =====================================
> Understandably, some may ask why do we need to have a management
> network - why having a host with IPv4 configured on it is not enough.
> The answer is twofold:
> 1. In oVirt, a network is an abstraction of the resources required for
>    connectivity of a host for a specific usage. This is true for the
>    management network just as it is for VM network or a display network.
>    The network entity is the key for adding/changing nics and IP
>    address.
> 2. In many occasions (such as small setups) the management network is
>    used as a VM/display network as well.
> 
> Problems in current connectivity:
> ================================
> According to alonbl of ovirt-host-deploy fame, and with no conflict to
> my own experience, creating the management network is the most fragile,
> error-prone step of bootstrap.
> 
> Currently it always creates a bridged network (even if the DC requires a
> non-bridged ovirtmgmt), it knows nothing about the defined MTU for
> ovirtmgmt, it uses ping to guess on top of which device to build (and
> thus requires Vdsm-to-Engine reverse connectivity), and is the sole
> remaining user of the addNetwork/vdsm-store-net-conf scripts.
> 
> Suggested feature:
> ==================
> Bootstrap would avoid creating a management network. Instead, after
> bootstrapping a host, Engine would send a getVdsCaps probe to the
> installed host, receiving a complete picture of the network
> configuration on the host. Among this picture is the device that holds
> the host's management IP address.
> 
> Engine would send setupNetwork command to generate ovirtmgmt with
> details devised from this picture, and according to the DC definition of
> ovirtmgmt.  For example, if Vdsm reports:
> 
> - vlan bond4.3000 has the host's IP, configured to use dhcp.
> - bond4 is comprises eth2 and eth3
> - ovirtmgmt is defined as a VM network with MTU 9000
> 
> then Engine sends the likes of:
>   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
>                 bonding=bond4: {eth2,eth3}, MTU=9000)
> 
> A call to setSafeNetConfig would wrap the network configuration up.
> 
> Currently, the host underegoes a reboot as the last step of bootstrap.
> This allows us to verify immediately if the host would be accessible
> post-boot using its new network configuration. If we want to maintain
> this, Engine would need to send a fenceNode request.
> 
> Benefits:
> =========
> - Simplified bootstrapping
> - Simplified ovirt-node registration (similar ovirtmgmt-generation logic
>   lies there).
> - Host installation ends with an ovirtmgmt network that matches DC
>   definition (bridged-ness, mtu, vlan).
> - vdsm-to-engine connectivity is not required.
> 
> Drawbacks:
> ==========
> - We need to implement new Engine logic for devising ovirtmgmt definition out of
>   getVdsCaps output.
> - ... your input is welcome here
> 
> Missing:
> ========
> A wiki feature page for this new behavior.
> 
> 



From alonbl at redhat.com  Mon May 20 11:52:26 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 20 May 2013 07:52:26 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <519A0DBE.4050804@redhat.com>
References: <20121225122722.GG7274@redhat.com> <519A0DBE.4050804@redhat.com>
Message-ID: <1058710849.2424969.1369050746339.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: "arch" <arch at ovirt.org>, alonbl at redhat.com, "Simon Grinberg" <sgrinber at redhat.com>, "Andrew Cathrow"
> <acathrow at redhat.com>, "Moti Asayag" <masayag at redhat.com>, "Barak Azulay" <bazulay at redhat.com>
> Sent: Monday, May 20, 2013 2:49:18 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> This is a summary of the thread so far (and the AI)-
> 
> - There is an agreement we do not need machine boot in the installation
> sequence.
> 
> - The current default behavior is to reboot after host installation (in
> Virt)
> 
> ** We are going to change current behavior in 3.3 and remove the reboot
> from the host installation flow **
> 
> - Today we have a flag in the REST API to avoid host reboot,we'll
> deprecate this flag since this is going to be the default behavior after
> the change (and booting after installation won't be available).
> 
> - Since host reboot is not needed in the host install flow we avoid
> adding VDSM verb for reboot at this point. The discussion if to do such
> a verb via ssh or VDSM can be done in the context were the verb is going
> to be used.
> 
> 
> Thanks, Livnat

ACK.


From alonbl at redhat.com  Mon May 20 11:58:05 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 20 May 2013 07:58:05 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <519A0DBE.4050804@redhat.com>
References: <20121225122722.GG7274@redhat.com> <519A0DBE.4050804@redhat.com>
Message-ID: <1387474947.2425969.1369051085926.JavaMail.root@redhat.com>

Hi,

Now another issue... ovirt-node.

In ovirt-node, the node already defines a bridge which is called br at INTERFACE@, this is done automatically.
The IP address of ovirt-node is assigned to that bridge, so we always have a bridge at ovirt-node.

I have the following useless in my code, most is legacy... the question...
Can this also be automated by the new code at engine side?
It should or things will break...

Thanks,
Alon

---

        if (
            self.environment[odeploycons.VdsmEnv.OVIRT_NODE] and
            self._interfaceIsBridge(name=interface)
        ):
            nic = interface.replace('br', '', 1)
            self._removeBridge(
                name=interface,
                interface=nic,
            )
            interface = nic


    def _removeBridge(self, name, interface):
        interface, vlanid = self._getVlanMasterDevice(name=interface)
        self.execute(
            (
                os.path.join(
                    odeploycons.FileLocations.VDSM_DATA_DIR,
                    'delNetwork',
                ),
                name,
                vlanid if vlanid is not None else '',
                '',     # bonding is not supported
                interface if interface is not None else '',
            ),
        )

        #
        # vdsm interface does not handle
        # ovirt node properly.
        # we should manually delete the
        # ifcfg file to avoid having duplicate
        # bridge.
        #
        if self.environment[odeploycons.VdsmEnv.OVIRT_NODE]:
            ifcfg = '/etc/sysconfig/network-scripts/ifcfg-%s' % (
                name
            )
            if os.path.exists(ifcfg):
                from ovirtnode import ovirtfunctions
                ovirtfunctions.ovirt_safe_delete_config(ifcfg)

----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: "arch" <arch at ovirt.org>, alonbl at redhat.com, "Simon Grinberg" <sgrinber at redhat.com>, "Andrew Cathrow"
> <acathrow at redhat.com>, "Moti Asayag" <masayag at redhat.com>, "Barak Azulay" <bazulay at redhat.com>
> Sent: Monday, May 20, 2013 2:49:18 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> This is a summary of the thread so far (and the AI)-
> 
> - There is an agreement we do not need machine boot in the installation
> sequence.
> 
> - The current default behavior is to reboot after host installation (in
> Virt)
> 
> ** We are going to change current behavior in 3.3 and remove the reboot
> from the host installation flow **
> 
> - Today we have a flag in the REST API to avoid host reboot,we'll
> deprecate this flag since this is going to be the default behavior after
> the change (and booting after installation won't be available).
> 
> - Since host reboot is not needed in the host install flow we avoid
> adding VDSM verb for reboot at this point. The discussion if to do such
> a verb via ssh or VDSM can be done in the context were the verb is going
> to be used.
> 
> 
> Thanks, Livnat
> 
> 
> 
> 
> On 12/25/2012 02:27 PM, Dan Kenigsberg wrote:
> > Current condition:
> > ==================
> > The management network, named ovirtmgmt, is created during host
> > bootstrap. It consists of a bridge device, connected to the network
> > device that was used to communicate with Engine (nic, bonding or vlan).
> > It inherits its ip settings from the latter device.
> > 
> > Why Is the Management Network Needed?
> > =====================================
> > Understandably, some may ask why do we need to have a management
> > network - why having a host with IPv4 configured on it is not enough.
> > The answer is twofold:
> > 1. In oVirt, a network is an abstraction of the resources required for
> >    connectivity of a host for a specific usage. This is true for the
> >    management network just as it is for VM network or a display network.
> >    The network entity is the key for adding/changing nics and IP
> >    address.
> > 2. In many occasions (such as small setups) the management network is
> >    used as a VM/display network as well.
> > 
> > Problems in current connectivity:
> > ================================
> > According to alonbl of ovirt-host-deploy fame, and with no conflict to
> > my own experience, creating the management network is the most fragile,
> > error-prone step of bootstrap.
> > 
> > Currently it always creates a bridged network (even if the DC requires a
> > non-bridged ovirtmgmt), it knows nothing about the defined MTU for
> > ovirtmgmt, it uses ping to guess on top of which device to build (and
> > thus requires Vdsm-to-Engine reverse connectivity), and is the sole
> > remaining user of the addNetwork/vdsm-store-net-conf scripts.
> > 
> > Suggested feature:
> > ==================
> > Bootstrap would avoid creating a management network. Instead, after
> > bootstrapping a host, Engine would send a getVdsCaps probe to the
> > installed host, receiving a complete picture of the network
> > configuration on the host. Among this picture is the device that holds
> > the host's management IP address.
> > 
> > Engine would send setupNetwork command to generate ovirtmgmt with
> > details devised from this picture, and according to the DC definition of
> > ovirtmgmt.  For example, if Vdsm reports:
> > 
> > - vlan bond4.3000 has the host's IP, configured to use dhcp.
> > - bond4 is comprises eth2 and eth3
> > - ovirtmgmt is defined as a VM network with MTU 9000
> > 
> > then Engine sends the likes of:
> >   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
> >                 bonding=bond4: {eth2,eth3}, MTU=9000)
> > 
> > A call to setSafeNetConfig would wrap the network configuration up.
> > 
> > Currently, the host underegoes a reboot as the last step of bootstrap.
> > This allows us to verify immediately if the host would be accessible
> > post-boot using its new network configuration. If we want to maintain
> > this, Engine would need to send a fenceNode request.
> > 
> > Benefits:
> > =========
> > - Simplified bootstrapping
> > - Simplified ovirt-node registration (similar ovirtmgmt-generation logic
> >   lies there).
> > - Host installation ends with an ovirtmgmt network that matches DC
> >   definition (bridged-ness, mtu, vlan).
> > - vdsm-to-engine connectivity is not required.
> > 
> > Drawbacks:
> > ==========
> > - We need to implement new Engine logic for devising ovirtmgmt definition
> > out of
> >   getVdsCaps output.
> > - ... your input is welcome here
> > 
> > Missing:
> > ========
> > A wiki feature page for this new behavior.
> > 
> > 
> 
> 


From sgrinber at redhat.com  Mon May 20 12:28:12 2013
From: sgrinber at redhat.com (Simon Grinberg)
Date: Mon, 20 May 2013 08:28:12 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <1387474947.2425969.1369051085926.JavaMail.root@redhat.com>
References: <20121225122722.GG7274@redhat.com> <519A0DBE.4050804@redhat.com>
	<1387474947.2425969.1369051085926.JavaMail.root@redhat.com>
Message-ID: <22126123.161.1369052799793.JavaMail.javamailuser@localhost>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Monday, May 20, 2013 7:58:05 AM
> Subject: Re: feature suggestion: initial generation of management network
> 
> Hi,
> 
> Now another issue... ovirt-node.
> 
> In ovirt-node, the node already defines a bridge which is called
> br at INTERFACE@, this is done automatically.
> The IP address of ovirt-node is assigned to that bridge, so we always
> have a bridge at ovirt-node.
> 
> I have the following useless in my code, most is legacy... the
> question...
> Can this also be automated by the new code at engine side?
> It should or things will break...

I don't see why the flows should be kept different - so we should find a way for doing the same with the nodes. But I think to avoid confusion it needs another thread now the the previous has converged. 

> 
> Thanks,
> Alon
> 
> ---
> 
>         if (
>             self.environment[odeploycons.VdsmEnv.OVIRT_NODE] and
>             self._interfaceIsBridge(name=interface)
>         ):
>             nic = interface.replace('br', '', 1)
>             self._removeBridge(
>                 name=interface,
>                 interface=nic,
>             )
>             interface = nic
> 
> 
>     def _removeBridge(self, name, interface):
>         interface, vlanid = self._getVlanMasterDevice(name=interface)
>         self.execute(
>             (
>                 os.path.join(
>                     odeploycons.FileLocations.VDSM_DATA_DIR,
>                     'delNetwork',
>                 ),
>                 name,
>                 vlanid if vlanid is not None else '',
>                 '',     # bonding is not supported
>                 interface if interface is not None else '',
>             ),
>         )
> 
>         #
>         # vdsm interface does not handle
>         # ovirt node properly.
>         # we should manually delete the
>         # ifcfg file to avoid having duplicate
>         # bridge.
>         #
>         if self.environment[odeploycons.VdsmEnv.OVIRT_NODE]:
>             ifcfg = '/etc/sysconfig/network-scripts/ifcfg-%s' % (
>                 name
>             )
>             if os.path.exists(ifcfg):
>                 from ovirtnode import ovirtfunctions
>                 ovirtfunctions.ovirt_safe_delete_config(ifcfg)
> 
> ----- Original Message -----
> > From: "Livnat Peer" <lpeer at redhat.com>
> > To: "Dan Kenigsberg" <danken at redhat.com>
> > Cc: "arch" <arch at ovirt.org>, alonbl at redhat.com, "Simon Grinberg"
> > <sgrinber at redhat.com>, "Andrew Cathrow"
> > <acathrow at redhat.com>, "Moti Asayag" <masayag at redhat.com>, "Barak
> > Azulay" <bazulay at redhat.com>
> > Sent: Monday, May 20, 2013 2:49:18 PM
> > Subject: Re: feature suggestion: initial generation of management
> > network
> > 
> > This is a summary of the thread so far (and the AI)-
> > 
> > - There is an agreement we do not need machine boot in the
> > installation
> > sequence.
> > 
> > - The current default behavior is to reboot after host installation
> > (in
> > Virt)
> > 
> > ** We are going to change current behavior in 3.3 and remove the
> > reboot
> > from the host installation flow **
> > 
> > - Today we have a flag in the REST API to avoid host reboot,we'll
> > deprecate this flag since this is going to be the default behavior
> > after
> > the change (and booting after installation won't be available).
> > 
> > - Since host reboot is not needed in the host install flow we avoid
> > adding VDSM verb for reboot at this point. The discussion if to do
> > such
> > a verb via ssh or VDSM can be done in the context were the verb is
> > going
> > to be used.
> > 
> > 
> > Thanks, Livnat
> > 
> > 
> > 
> > 
> > On 12/25/2012 02:27 PM, Dan Kenigsberg wrote:
> > > Current condition:
> > > ==================
> > > The management network, named ovirtmgmt, is created during host
> > > bootstrap. It consists of a bridge device, connected to the
> > > network
> > > device that was used to communicate with Engine (nic, bonding or
> > > vlan).
> > > It inherits its ip settings from the latter device.
> > > 
> > > Why Is the Management Network Needed?
> > > =====================================
> > > Understandably, some may ask why do we need to have a management
> > > network - why having a host with IPv4 configured on it is not
> > > enough.
> > > The answer is twofold:
> > > 1. In oVirt, a network is an abstraction of the resources
> > > required for
> > >    connectivity of a host for a specific usage. This is true for
> > >    the
> > >    management network just as it is for VM network or a display
> > >    network.
> > >    The network entity is the key for adding/changing nics and IP
> > >    address.
> > > 2. In many occasions (such as small setups) the management
> > > network is
> > >    used as a VM/display network as well.
> > > 
> > > Problems in current connectivity:
> > > ================================
> > > According to alonbl of ovirt-host-deploy fame, and with no
> > > conflict to
> > > my own experience, creating the management network is the most
> > > fragile,
> > > error-prone step of bootstrap.
> > > 
> > > Currently it always creates a bridged network (even if the DC
> > > requires a
> > > non-bridged ovirtmgmt), it knows nothing about the defined MTU
> > > for
> > > ovirtmgmt, it uses ping to guess on top of which device to build
> > > (and
> > > thus requires Vdsm-to-Engine reverse connectivity), and is the
> > > sole
> > > remaining user of the addNetwork/vdsm-store-net-conf scripts.
> > > 
> > > Suggested feature:
> > > ==================
> > > Bootstrap would avoid creating a management network. Instead,
> > > after
> > > bootstrapping a host, Engine would send a getVdsCaps probe to the
> > > installed host, receiving a complete picture of the network
> > > configuration on the host. Among this picture is the device that
> > > holds
> > > the host's management IP address.
> > > 
> > > Engine would send setupNetwork command to generate ovirtmgmt with
> > > details devised from this picture, and according to the DC
> > > definition of
> > > ovirtmgmt.  For example, if Vdsm reports:
> > > 
> > > - vlan bond4.3000 has the host's IP, configured to use dhcp.
> > > - bond4 is comprises eth2 and eth3
> > > - ovirtmgmt is defined as a VM network with MTU 9000
> > > 
> > > then Engine sends the likes of:
> > >   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
> > >                 bonding=bond4: {eth2,eth3}, MTU=9000)
> > > 
> > > A call to setSafeNetConfig would wrap the network configuration
> > > up.
> > > 
> > > Currently, the host underegoes a reboot as the last step of
> > > bootstrap.
> > > This allows us to verify immediately if the host would be
> > > accessible
> > > post-boot using its new network configuration. If we want to
> > > maintain
> > > this, Engine would need to send a fenceNode request.
> > > 
> > > Benefits:
> > > =========
> > > - Simplified bootstrapping
> > > - Simplified ovirt-node registration (similar
> > > ovirtmgmt-generation logic
> > >   lies there).
> > > - Host installation ends with an ovirtmgmt network that matches
> > > DC
> > >   definition (bridged-ness, mtu, vlan).
> > > - vdsm-to-engine connectivity is not required.
> > > 
> > > Drawbacks:
> > > ==========
> > > - We need to implement new Engine logic for devising ovirtmgmt
> > > definition
> > > out of
> > >   getVdsCaps output.
> > > - ... your input is welcome here
> > > 
> > > Missing:
> > > ========
> > > A wiki feature page for this new behavior.
> > > 
> > > 
> > 
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From alonbl at redhat.com  Mon May 20 12:31:25 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 20 May 2013 08:31:25 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <22126123.161.1369052799793.JavaMail.javamailuser@localhost>
References: <20121225122722.GG7274@redhat.com> <519A0DBE.4050804@redhat.com>
	<1387474947.2425969.1369051085926.JavaMail.root@redhat.com>
	<22126123.161.1369052799793.JavaMail.javamailuser@localhost>
Message-ID: <1177251918.2434368.1369053085602.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Simon Grinberg" <sgrinber at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "arch" <arch at ovirt.org>, "Moti Asayag" <masayag at redhat.com>
> Sent: Monday, May 20, 2013 3:28:12 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Moti Asayag" <masayag at redhat.com>
> > Cc: "arch" <arch at ovirt.org>
> > Sent: Monday, May 20, 2013 7:58:05 AM
> > Subject: Re: feature suggestion: initial generation of management network
> > 
> > Hi,
> > 
> > Now another issue... ovirt-node.
> > 
> > In ovirt-node, the node already defines a bridge which is called
> > br at INTERFACE@, this is done automatically.
> > The IP address of ovirt-node is assigned to that bridge, so we always
> > have a bridge at ovirt-node.
> > 
> > I have the following useless in my code, most is legacy... the
> > question...
> > Can this also be automated by the new code at engine side?
> > It should or things will break...
> 
> I don't see why the flows should be kept different - so we should find a way
> for doing the same with the nodes.

Because as far as I know in current implementation, we did not take the ovirt-node specific behavior into account, right Moti?

> But I think to avoid confusion it needs
> another thread now the the previous has converged.

I removed all other people from the CC...

> 
> > 
> > Thanks,
> > Alon
> > 
> > ---
> > 
> >         if (
> >             self.environment[odeploycons.VdsmEnv.OVIRT_NODE] and
> >             self._interfaceIsBridge(name=interface)
> >         ):
> >             nic = interface.replace('br', '', 1)
> >             self._removeBridge(
> >                 name=interface,
> >                 interface=nic,
> >             )
> >             interface = nic
> > 
> > 
> >     def _removeBridge(self, name, interface):
> >         interface, vlanid = self._getVlanMasterDevice(name=interface)
> >         self.execute(
> >             (
> >                 os.path.join(
> >                     odeploycons.FileLocations.VDSM_DATA_DIR,
> >                     'delNetwork',
> >                 ),
> >                 name,
> >                 vlanid if vlanid is not None else '',
> >                 '',     # bonding is not supported
> >                 interface if interface is not None else '',
> >             ),
> >         )
> > 
> >         #
> >         # vdsm interface does not handle
> >         # ovirt node properly.
> >         # we should manually delete the
> >         # ifcfg file to avoid having duplicate
> >         # bridge.
> >         #
> >         if self.environment[odeploycons.VdsmEnv.OVIRT_NODE]:
> >             ifcfg = '/etc/sysconfig/network-scripts/ifcfg-%s' % (
> >                 name
> >             )
> >             if os.path.exists(ifcfg):
> >                 from ovirtnode import ovirtfunctions
> >                 ovirtfunctions.ovirt_safe_delete_config(ifcfg)
> > 
> > ----- Original Message -----
> > > From: "Livnat Peer" <lpeer at redhat.com>
> > > To: "Dan Kenigsberg" <danken at redhat.com>
> > > Cc: "arch" <arch at ovirt.org>, alonbl at redhat.com, "Simon Grinberg"
> > > <sgrinber at redhat.com>, "Andrew Cathrow"
> > > <acathrow at redhat.com>, "Moti Asayag" <masayag at redhat.com>, "Barak
> > > Azulay" <bazulay at redhat.com>
> > > Sent: Monday, May 20, 2013 2:49:18 PM
> > > Subject: Re: feature suggestion: initial generation of management
> > > network
> > > 
> > > This is a summary of the thread so far (and the AI)-
> > > 
> > > - There is an agreement we do not need machine boot in the
> > > installation
> > > sequence.
> > > 
> > > - The current default behavior is to reboot after host installation
> > > (in
> > > Virt)
> > > 
> > > ** We are going to change current behavior in 3.3 and remove the
> > > reboot
> > > from the host installation flow **
> > > 
> > > - Today we have a flag in the REST API to avoid host reboot,we'll
> > > deprecate this flag since this is going to be the default behavior
> > > after
> > > the change (and booting after installation won't be available).
> > > 
> > > - Since host reboot is not needed in the host install flow we avoid
> > > adding VDSM verb for reboot at this point. The discussion if to do
> > > such
> > > a verb via ssh or VDSM can be done in the context were the verb is
> > > going
> > > to be used.
> > > 
> > > 
> > > Thanks, Livnat
> > > 
> > > 
> > > 
> > > 
> > > On 12/25/2012 02:27 PM, Dan Kenigsberg wrote:
> > > > Current condition:
> > > > ==================
> > > > The management network, named ovirtmgmt, is created during host
> > > > bootstrap. It consists of a bridge device, connected to the
> > > > network
> > > > device that was used to communicate with Engine (nic, bonding or
> > > > vlan).
> > > > It inherits its ip settings from the latter device.
> > > > 
> > > > Why Is the Management Network Needed?
> > > > =====================================
> > > > Understandably, some may ask why do we need to have a management
> > > > network - why having a host with IPv4 configured on it is not
> > > > enough.
> > > > The answer is twofold:
> > > > 1. In oVirt, a network is an abstraction of the resources
> > > > required for
> > > >    connectivity of a host for a specific usage. This is true for
> > > >    the
> > > >    management network just as it is for VM network or a display
> > > >    network.
> > > >    The network entity is the key for adding/changing nics and IP
> > > >    address.
> > > > 2. In many occasions (such as small setups) the management
> > > > network is
> > > >    used as a VM/display network as well.
> > > > 
> > > > Problems in current connectivity:
> > > > ================================
> > > > According to alonbl of ovirt-host-deploy fame, and with no
> > > > conflict to
> > > > my own experience, creating the management network is the most
> > > > fragile,
> > > > error-prone step of bootstrap.
> > > > 
> > > > Currently it always creates a bridged network (even if the DC
> > > > requires a
> > > > non-bridged ovirtmgmt), it knows nothing about the defined MTU
> > > > for
> > > > ovirtmgmt, it uses ping to guess on top of which device to build
> > > > (and
> > > > thus requires Vdsm-to-Engine reverse connectivity), and is the
> > > > sole
> > > > remaining user of the addNetwork/vdsm-store-net-conf scripts.
> > > > 
> > > > Suggested feature:
> > > > ==================
> > > > Bootstrap would avoid creating a management network. Instead,
> > > > after
> > > > bootstrapping a host, Engine would send a getVdsCaps probe to the
> > > > installed host, receiving a complete picture of the network
> > > > configuration on the host. Among this picture is the device that
> > > > holds
> > > > the host's management IP address.
> > > > 
> > > > Engine would send setupNetwork command to generate ovirtmgmt with
> > > > details devised from this picture, and according to the DC
> > > > definition of
> > > > ovirtmgmt.  For example, if Vdsm reports:
> > > > 
> > > > - vlan bond4.3000 has the host's IP, configured to use dhcp.
> > > > - bond4 is comprises eth2 and eth3
> > > > - ovirtmgmt is defined as a VM network with MTU 9000
> > > > 
> > > > then Engine sends the likes of:
> > > >   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
> > > >                 bonding=bond4: {eth2,eth3}, MTU=9000)
> > > > 
> > > > A call to setSafeNetConfig would wrap the network configuration
> > > > up.
> > > > 
> > > > Currently, the host underegoes a reboot as the last step of
> > > > bootstrap.
> > > > This allows us to verify immediately if the host would be
> > > > accessible
> > > > post-boot using its new network configuration. If we want to
> > > > maintain
> > > > this, Engine would need to send a fenceNode request.
> > > > 
> > > > Benefits:
> > > > =========
> > > > - Simplified bootstrapping
> > > > - Simplified ovirt-node registration (similar
> > > > ovirtmgmt-generation logic
> > > >   lies there).
> > > > - Host installation ends with an ovirtmgmt network that matches
> > > > DC
> > > >   definition (bridged-ness, mtu, vlan).
> > > > - vdsm-to-engine connectivity is not required.
> > > > 
> > > > Drawbacks:
> > > > ==========
> > > > - We need to implement new Engine logic for devising ovirtmgmt
> > > > definition
> > > > out of
> > > >   getVdsCaps output.
> > > > - ... your input is welcome here
> > > > 
> > > > Missing:
> > > > ========
> > > > A wiki feature page for this new behavior.
> > > > 
> > > > 
> > > 
> > > 
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> 


From lpeer at redhat.com  Mon May 20 12:55:42 2013
From: lpeer at redhat.com (Livnat Peer)
Date: Mon, 20 May 2013 15:55:42 +0300
Subject: feature suggestion: initial generation of management network
In-Reply-To: <1387474947.2425969.1369051085926.JavaMail.root@redhat.com>
References: <20121225122722.GG7274@redhat.com> <519A0DBE.4050804@redhat.com>
	<1387474947.2425969.1369051085926.JavaMail.root@redhat.com>
Message-ID: <519A1D4E.7070607@redhat.com>

On 05/20/2013 02:58 PM, Alon Bar-Lev wrote:
> Hi,
> 
> Now another issue... ovirt-node.
> 
> In ovirt-node, the node already defines a bridge which is called br at INTERFACE@, this is done automatically.
> The IP address of ovirt-node is assigned to that bridge, so we always have a bridge at ovirt-node.
> 
> I have the following useless in my code, most is legacy... the question...
> Can this also be automated by the new code at engine side?
> It should or things will break...
> 

For ovirt node -

For images 3.3 and above the code below can be removed, we will make
shore that the ovirt-node-plugin-vdsm would not create the brXXX bridges
(or if we have no choice remove them).

For images 3.2 and below we still need this code, because oVirt node
creates brXXX bridges and the engine do not configure the network
automatically if a bridge exists on the interface.

The down side to the above is that for management networks that
configured in the engine as bridgeless the management network on the
host would still be bridged thus will be marked as not-in-sync.


Livnat





> Thanks,
> Alon
> 
> ---
> 
>         if (
>             self.environment[odeploycons.VdsmEnv.OVIRT_NODE] and
>             self._interfaceIsBridge(name=interface)
>         ):
>             nic = interface.replace('br', '', 1)
>             self._removeBridge(
>                 name=interface,
>                 interface=nic,
>             )
>             interface = nic
> 
> 
>     def _removeBridge(self, name, interface):
>         interface, vlanid = self._getVlanMasterDevice(name=interface)
>         self.execute(
>             (
>                 os.path.join(
>                     odeploycons.FileLocations.VDSM_DATA_DIR,
>                     'delNetwork',
>                 ),
>                 name,
>                 vlanid if vlanid is not None else '',
>                 '',     # bonding is not supported
>                 interface if interface is not None else '',
>             ),
>         )
> 
>         #
>         # vdsm interface does not handle
>         # ovirt node properly.
>         # we should manually delete the
>         # ifcfg file to avoid having duplicate
>         # bridge.
>         #
>         if self.environment[odeploycons.VdsmEnv.OVIRT_NODE]:
>             ifcfg = '/etc/sysconfig/network-scripts/ifcfg-%s' % (
>                 name
>             )
>             if os.path.exists(ifcfg):
>                 from ovirtnode import ovirtfunctions
>                 ovirtfunctions.ovirt_safe_delete_config(ifcfg)
> 
> ----- Original Message -----
>> From: "Livnat Peer" <lpeer at redhat.com>
>> To: "Dan Kenigsberg" <danken at redhat.com>
>> Cc: "arch" <arch at ovirt.org>, alonbl at redhat.com, "Simon Grinberg" <sgrinber at redhat.com>, "Andrew Cathrow"
>> <acathrow at redhat.com>, "Moti Asayag" <masayag at redhat.com>, "Barak Azulay" <bazulay at redhat.com>
>> Sent: Monday, May 20, 2013 2:49:18 PM
>> Subject: Re: feature suggestion: initial generation of management network
>>
>> This is a summary of the thread so far (and the AI)-
>>
>> - There is an agreement we do not need machine boot in the installation
>> sequence.
>>
>> - The current default behavior is to reboot after host installation (in
>> Virt)
>>
>> ** We are going to change current behavior in 3.3 and remove the reboot
>> from the host installation flow **
>>
>> - Today we have a flag in the REST API to avoid host reboot,we'll
>> deprecate this flag since this is going to be the default behavior after
>> the change (and booting after installation won't be available).
>>
>> - Since host reboot is not needed in the host install flow we avoid
>> adding VDSM verb for reboot at this point. The discussion if to do such
>> a verb via ssh or VDSM can be done in the context were the verb is going
>> to be used.
>>
>>
>> Thanks, Livnat
>>
>>
>>
>>
>> On 12/25/2012 02:27 PM, Dan Kenigsberg wrote:
>>> Current condition:
>>> ==================
>>> The management network, named ovirtmgmt, is created during host
>>> bootstrap. It consists of a bridge device, connected to the network
>>> device that was used to communicate with Engine (nic, bonding or vlan).
>>> It inherits its ip settings from the latter device.
>>>
>>> Why Is the Management Network Needed?
>>> =====================================
>>> Understandably, some may ask why do we need to have a management
>>> network - why having a host with IPv4 configured on it is not enough.
>>> The answer is twofold:
>>> 1. In oVirt, a network is an abstraction of the resources required for
>>>    connectivity of a host for a specific usage. This is true for the
>>>    management network just as it is for VM network or a display network.
>>>    The network entity is the key for adding/changing nics and IP
>>>    address.
>>> 2. In many occasions (such as small setups) the management network is
>>>    used as a VM/display network as well.
>>>
>>> Problems in current connectivity:
>>> ================================
>>> According to alonbl of ovirt-host-deploy fame, and with no conflict to
>>> my own experience, creating the management network is the most fragile,
>>> error-prone step of bootstrap.
>>>
>>> Currently it always creates a bridged network (even if the DC requires a
>>> non-bridged ovirtmgmt), it knows nothing about the defined MTU for
>>> ovirtmgmt, it uses ping to guess on top of which device to build (and
>>> thus requires Vdsm-to-Engine reverse connectivity), and is the sole
>>> remaining user of the addNetwork/vdsm-store-net-conf scripts.
>>>
>>> Suggested feature:
>>> ==================
>>> Bootstrap would avoid creating a management network. Instead, after
>>> bootstrapping a host, Engine would send a getVdsCaps probe to the
>>> installed host, receiving a complete picture of the network
>>> configuration on the host. Among this picture is the device that holds
>>> the host's management IP address.
>>>
>>> Engine would send setupNetwork command to generate ovirtmgmt with
>>> details devised from this picture, and according to the DC definition of
>>> ovirtmgmt.  For example, if Vdsm reports:
>>>
>>> - vlan bond4.3000 has the host's IP, configured to use dhcp.
>>> - bond4 is comprises eth2 and eth3
>>> - ovirtmgmt is defined as a VM network with MTU 9000
>>>
>>> then Engine sends the likes of:
>>>   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
>>>                 bonding=bond4: {eth2,eth3}, MTU=9000)
>>>
>>> A call to setSafeNetConfig would wrap the network configuration up.
>>>
>>> Currently, the host underegoes a reboot as the last step of bootstrap.
>>> This allows us to verify immediately if the host would be accessible
>>> post-boot using its new network configuration. If we want to maintain
>>> this, Engine would need to send a fenceNode request.
>>>
>>> Benefits:
>>> =========
>>> - Simplified bootstrapping
>>> - Simplified ovirt-node registration (similar ovirtmgmt-generation logic
>>>   lies there).
>>> - Host installation ends with an ovirtmgmt network that matches DC
>>>   definition (bridged-ness, mtu, vlan).
>>> - vdsm-to-engine connectivity is not required.
>>>
>>> Drawbacks:
>>> ==========
>>> - We need to implement new Engine logic for devising ovirtmgmt definition
>>> out of
>>>   getVdsCaps output.
>>> - ... your input is welcome here
>>>
>>> Missing:
>>> ========
>>> A wiki feature page for this new behavior.
>>>
>>>
>>
>>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 
> 



From masayag at redhat.com  Mon May 20 13:01:30 2013
From: masayag at redhat.com (Moti Asayag)
Date: Mon, 20 May 2013 16:01:30 +0300
Subject: feature suggestion: initial generation of management network
In-Reply-To: <1177251918.2434368.1369053085602.JavaMail.root@redhat.com>
References: <20121225122722.GG7274@redhat.com> <519A0DBE.4050804@redhat.com>
	<1387474947.2425969.1369051085926.JavaMail.root@redhat.com>
	<22126123.161.1369052799793.JavaMail.javamailuser@localhost>
	<1177251918.2434368.1369053085602.JavaMail.root@redhat.com>
Message-ID: <519A1EAA.7050606@redhat.com>

On 05/20/2013 03:31 PM, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
>> From: "Simon Grinberg" <sgrinber at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "arch" <arch at ovirt.org>, "Moti Asayag" <masayag at redhat.com>
>> Sent: Monday, May 20, 2013 3:28:12 PM
>> Subject: Re: feature suggestion: initial generation of management network
>>
>>
>>
>> ----- Original Message -----
>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>>> To: "Moti Asayag" <masayag at redhat.com>
>>> Cc: "arch" <arch at ovirt.org>
>>> Sent: Monday, May 20, 2013 7:58:05 AM
>>> Subject: Re: feature suggestion: initial generation of management network
>>>
>>> Hi,
>>>
>>> Now another issue... ovirt-node.
>>>
>>> In ovirt-node, the node already defines a bridge which is called
>>> br at INTERFACE@, this is done automatically.
>>> The IP address of ovirt-node is assigned to that bridge, so we always
>>> have a bridge at ovirt-node.
>>>
>>> I have the following useless in my code, most is legacy... the
>>> question...
>>> Can this also be automated by the new code at engine side?
>>> It should or things will break...
>>
>> I don't see why the flows should be kept different - so we should find a way
>> for doing the same with the nodes.
> 
> Because as far as I know in current implementation, we did not take the ovirt-node specific behavior into account, right Moti?

Correct. See Livnat reply.

> 
>> But I think to avoid confusion it needs
>> another thread now the the previous has converged.
> 
> I removed all other people from the CC...
> 
>>
>>>
>>> Thanks,
>>> Alon
>>>
>>> ---
>>>
>>>         if (
>>>             self.environment[odeploycons.VdsmEnv.OVIRT_NODE] and
>>>             self._interfaceIsBridge(name=interface)
>>>         ):
>>>             nic = interface.replace('br', '', 1)
>>>             self._removeBridge(
>>>                 name=interface,
>>>                 interface=nic,
>>>             )
>>>             interface = nic
>>>
>>>
>>>     def _removeBridge(self, name, interface):
>>>         interface, vlanid = self._getVlanMasterDevice(name=interface)
>>>         self.execute(
>>>             (
>>>                 os.path.join(
>>>                     odeploycons.FileLocations.VDSM_DATA_DIR,
>>>                     'delNetwork',
>>>                 ),
>>>                 name,
>>>                 vlanid if vlanid is not None else '',
>>>                 '',     # bonding is not supported
>>>                 interface if interface is not None else '',
>>>             ),
>>>         )
>>>
>>>         #
>>>         # vdsm interface does not handle
>>>         # ovirt node properly.
>>>         # we should manually delete the
>>>         # ifcfg file to avoid having duplicate
>>>         # bridge.
>>>         #
>>>         if self.environment[odeploycons.VdsmEnv.OVIRT_NODE]:
>>>             ifcfg = '/etc/sysconfig/network-scripts/ifcfg-%s' % (
>>>                 name
>>>             )
>>>             if os.path.exists(ifcfg):
>>>                 from ovirtnode import ovirtfunctions
>>>                 ovirtfunctions.ovirt_safe_delete_config(ifcfg)
>>>
>>> ----- Original Message -----
>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>> To: "Dan Kenigsberg" <danken at redhat.com>
>>>> Cc: "arch" <arch at ovirt.org>, alonbl at redhat.com, "Simon Grinberg"
>>>> <sgrinber at redhat.com>, "Andrew Cathrow"
>>>> <acathrow at redhat.com>, "Moti Asayag" <masayag at redhat.com>, "Barak
>>>> Azulay" <bazulay at redhat.com>
>>>> Sent: Monday, May 20, 2013 2:49:18 PM
>>>> Subject: Re: feature suggestion: initial generation of management
>>>> network
>>>>
>>>> This is a summary of the thread so far (and the AI)-
>>>>
>>>> - There is an agreement we do not need machine boot in the
>>>> installation
>>>> sequence.
>>>>
>>>> - The current default behavior is to reboot after host installation
>>>> (in
>>>> Virt)
>>>>
>>>> ** We are going to change current behavior in 3.3 and remove the
>>>> reboot
>>>> from the host installation flow **
>>>>
>>>> - Today we have a flag in the REST API to avoid host reboot,we'll
>>>> deprecate this flag since this is going to be the default behavior
>>>> after
>>>> the change (and booting after installation won't be available).
>>>>
>>>> - Since host reboot is not needed in the host install flow we avoid
>>>> adding VDSM verb for reboot at this point. The discussion if to do
>>>> such
>>>> a verb via ssh or VDSM can be done in the context were the verb is
>>>> going
>>>> to be used.
>>>>
>>>>
>>>> Thanks, Livnat
>>>>
>>>>
>>>>
>>>>
>>>> On 12/25/2012 02:27 PM, Dan Kenigsberg wrote:
>>>>> Current condition:
>>>>> ==================
>>>>> The management network, named ovirtmgmt, is created during host
>>>>> bootstrap. It consists of a bridge device, connected to the
>>>>> network
>>>>> device that was used to communicate with Engine (nic, bonding or
>>>>> vlan).
>>>>> It inherits its ip settings from the latter device.
>>>>>
>>>>> Why Is the Management Network Needed?
>>>>> =====================================
>>>>> Understandably, some may ask why do we need to have a management
>>>>> network - why having a host with IPv4 configured on it is not
>>>>> enough.
>>>>> The answer is twofold:
>>>>> 1. In oVirt, a network is an abstraction of the resources
>>>>> required for
>>>>>    connectivity of a host for a specific usage. This is true for
>>>>>    the
>>>>>    management network just as it is for VM network or a display
>>>>>    network.
>>>>>    The network entity is the key for adding/changing nics and IP
>>>>>    address.
>>>>> 2. In many occasions (such as small setups) the management
>>>>> network is
>>>>>    used as a VM/display network as well.
>>>>>
>>>>> Problems in current connectivity:
>>>>> ================================
>>>>> According to alonbl of ovirt-host-deploy fame, and with no
>>>>> conflict to
>>>>> my own experience, creating the management network is the most
>>>>> fragile,
>>>>> error-prone step of bootstrap.
>>>>>
>>>>> Currently it always creates a bridged network (even if the DC
>>>>> requires a
>>>>> non-bridged ovirtmgmt), it knows nothing about the defined MTU
>>>>> for
>>>>> ovirtmgmt, it uses ping to guess on top of which device to build
>>>>> (and
>>>>> thus requires Vdsm-to-Engine reverse connectivity), and is the
>>>>> sole
>>>>> remaining user of the addNetwork/vdsm-store-net-conf scripts.
>>>>>
>>>>> Suggested feature:
>>>>> ==================
>>>>> Bootstrap would avoid creating a management network. Instead,
>>>>> after
>>>>> bootstrapping a host, Engine would send a getVdsCaps probe to the
>>>>> installed host, receiving a complete picture of the network
>>>>> configuration on the host. Among this picture is the device that
>>>>> holds
>>>>> the host's management IP address.
>>>>>
>>>>> Engine would send setupNetwork command to generate ovirtmgmt with
>>>>> details devised from this picture, and according to the DC
>>>>> definition of
>>>>> ovirtmgmt.  For example, if Vdsm reports:
>>>>>
>>>>> - vlan bond4.3000 has the host's IP, configured to use dhcp.
>>>>> - bond4 is comprises eth2 and eth3
>>>>> - ovirtmgmt is defined as a VM network with MTU 9000
>>>>>
>>>>> then Engine sends the likes of:
>>>>>   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
>>>>>                 bonding=bond4: {eth2,eth3}, MTU=9000)
>>>>>
>>>>> A call to setSafeNetConfig would wrap the network configuration
>>>>> up.
>>>>>
>>>>> Currently, the host underegoes a reboot as the last step of
>>>>> bootstrap.
>>>>> This allows us to verify immediately if the host would be
>>>>> accessible
>>>>> post-boot using its new network configuration. If we want to
>>>>> maintain
>>>>> this, Engine would need to send a fenceNode request.
>>>>>
>>>>> Benefits:
>>>>> =========
>>>>> - Simplified bootstrapping
>>>>> - Simplified ovirt-node registration (similar
>>>>> ovirtmgmt-generation logic
>>>>>   lies there).
>>>>> - Host installation ends with an ovirtmgmt network that matches
>>>>> DC
>>>>>   definition (bridged-ness, mtu, vlan).
>>>>> - vdsm-to-engine connectivity is not required.
>>>>>
>>>>> Drawbacks:
>>>>> ==========
>>>>> - We need to implement new Engine logic for devising ovirtmgmt
>>>>> definition
>>>>> out of
>>>>>   getVdsCaps output.
>>>>> - ... your input is welcome here
>>>>>
>>>>> Missing:
>>>>> ========
>>>>> A wiki feature page for this new behavior.
>>>>>
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>
>>



From alonbl at redhat.com  Mon May 20 13:08:39 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 20 May 2013 09:08:39 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <519A1D4E.7070607@redhat.com>
References: <20121225122722.GG7274@redhat.com> <519A0DBE.4050804@redhat.com>
	<1387474947.2425969.1369051085926.JavaMail.root@redhat.com>
	<519A1D4E.7070607@redhat.com>
Message-ID: <233995750.2453181.1369055319701.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Moti Asayag" <masayag at redhat.com>, "arch" <arch at ovirt.org>
> Sent: Monday, May 20, 2013 3:55:42 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> On 05/20/2013 02:58 PM, Alon Bar-Lev wrote:
> > Hi,
> > 
> > Now another issue... ovirt-node.
> > 
> > In ovirt-node, the node already defines a bridge which is called
> > br at INTERFACE@, this is done automatically.
> > The IP address of ovirt-node is assigned to that bridge, so we always have
> > a bridge at ovirt-node.
> > 
> > I have the following useless in my code, most is legacy... the question...
> > Can this also be automated by the new code at engine side?
> > It should or things will break...
> > 
> 
> For ovirt node -
> 
> For images 3.3 and above the code below can be removed, we will make
> shore that the ovirt-node-plugin-vdsm would not create the brXXX bridges
> (or if we have no choice remove them).

I thought this is created in the node-core...
Just confirmed.
A node without vdsm plugin also create that bridge.
vdsm has nothing to do with this process as far as I know.
 
> For images 3.2 and below we still need this code, because oVirt node
> creates brXXX bridges and the engine do not configure the network
> automatically if a bridge exists on the interface.

It is not just 'need this code' it is that we cannot use the bridgeless solution at enigne.
Options:

1. We need to detect node version and perform bridgeless deployment if node is >= x, but we do not know this at engine when we deploy a host... we even do not know that it is ovirt-node.

2. I release a new minor version of ovirt-host-deploy that delete the bridge regardless of the mode.

3. Engine will be able to delete this bridge just like he is able to create the management bridge.

> The down side to the above is that for management networks that
> configured in the engine as bridgeless the management network on the
> host would still be bridged thus will be marked as not-in-sync.

Right, and because of that I think that (3) is the best solution.

Thanks,
Alon


From mburns at redhat.com  Mon May 20 13:11:52 2013
From: mburns at redhat.com (Mike Burns)
Date: Mon, 20 May 2013 09:11:52 -0400
Subject: Need a new gerrit repo for ovirt-node-plugin-vdsm
In-Reply-To: <20130519122111.GC2144@redhat.com>
References: <5196151D.2050307@redhat.com> <5196387A.9070604@redhat.com>
	<20130519122111.GC2144@redhat.com>
Message-ID: <519A2118.3030803@redhat.com>

On 05/19/2013 08:21 AM, Dan Kenigsberg wrote:
> On Fri, May 17, 2013 at 10:02:34AM -0400, Douglas Schilling Landgraf wrote:
>> On 05/17/2013 07:31 AM, Mike Burns wrote:
>>> As part of the move to a more universal oVirt Node during the 3.3 time
>>> frame[1], a separate repo is needed for a plugin to allow oVirt Node to
>>> communicate with oVirt Engine [2].
>>>
>>> In order to provide this plugin, I need a gerrit repo created and also
>>> need consensus on a name.
>>>
>>> Name proposal:
>>> ovirt-node-plugin-vdsm
>> I would go with that one.
>
> me2, though I do not have a strong opinion or explanation.
>

ok, let's go with that.  I've already posted initial test packages on 
ovirt.org[1] with that name, so let's just go with that.

Mike

[1] http://resources.ovirt.org/releases/node-base/beta/rpm/Fedora/18/noarch/

>>
>>> I'm rather indifferent to what we call this, so I figured I'd include
>>> the arch@ list to get feedback.
>>>
>>> Thanks
>>>
>>> Mike
>>>
>>> [1] http://www.ovirt.org/Features/Universal_Image
>>> [2] http://www.ovirt.org/Features/Node_vdsm_plugin
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>



From iheim at redhat.com  Mon May 20 19:05:51 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 20 May 2013 22:05:51 +0300
Subject: Need a new gerrit repo for ovirt-node-plugin-vdsm
In-Reply-To: <519A2118.3030803@redhat.com>
References: <5196151D.2050307@redhat.com> <5196387A.9070604@redhat.com>
	<20130519122111.GC2144@redhat.com> <519A2118.3030803@redhat.com>
Message-ID: <519A740F.2070405@redhat.com>

On 05/20/2013 04:11 PM, Mike Burns wrote:
> On 05/19/2013 08:21 AM, Dan Kenigsberg wrote:
>> On Fri, May 17, 2013 at 10:02:34AM -0400, Douglas Schilling Landgraf
>> wrote:
>>> On 05/17/2013 07:31 AM, Mike Burns wrote:
>>>> As part of the move to a more universal oVirt Node during the 3.3 time
>>>> frame[1], a separate repo is needed for a plugin to allow oVirt Node to
>>>> communicate with oVirt Engine [2].
>>>>
>>>> In order to provide this plugin, I need a gerrit repo created and also
>>>> need consensus on a name.
>>>>
>>>> Name proposal:
>>>> ovirt-node-plugin-vdsm
>>> I would go with that one.
>>
>> me2, though I do not have a strong opinion or explanation.
>>
>
> ok, let's go with that.  I've already posted initial test packages on
> ovirt.org[1] with that name, so let's just go with that.

repo created.
mike - you currently have +2/merge rights.


>
> Mike
>
> [1]
> http://resources.ovirt.org/releases/node-base/beta/rpm/Fedora/18/noarch/
>
>>>
>>>> I'm rather indifferent to what we call this, so I figured I'd include
>>>> the arch@ list to get feedback.
>>>>
>>>> Thanks
>>>>
>>>> Mike
>>>>
>>>> [1] http://www.ovirt.org/Features/Universal_Image
>>>> [2] http://www.ovirt.org/Features/Node_vdsm_plugin
>> _______________________________________________
>> Infra mailing list
>> Infra at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/infra
>>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch



From iheim at redhat.com  Mon May 20 19:10:20 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 20 May 2013 22:10:20 +0300
Subject: feature suggestion: initial generation of management network
In-Reply-To: <233995750.2453181.1369055319701.JavaMail.root@redhat.com>
References: <20121225122722.GG7274@redhat.com> <519A0DBE.4050804@redhat.com>
	<1387474947.2425969.1369051085926.JavaMail.root@redhat.com>
	<519A1D4E.7070607@redhat.com>
	<233995750.2453181.1369055319701.JavaMail.root@redhat.com>
Message-ID: <519A751C.1040505@redhat.com>

On 05/20/2013 04:08 PM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Livnat Peer" <lpeer at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Moti Asayag" <masayag at redhat.com>, "arch" <arch at ovirt.org>
>> Sent: Monday, May 20, 2013 3:55:42 PM
>> Subject: Re: feature suggestion: initial generation of management network
>>
>> On 05/20/2013 02:58 PM, Alon Bar-Lev wrote:
>>> Hi,
>>>
>>> Now another issue... ovirt-node.
>>>
>>> In ovirt-node, the node already defines a bridge which is called
>>> br at INTERFACE@, this is done automatically.
>>> The IP address of ovirt-node is assigned to that bridge, so we always have
>>> a bridge at ovirt-node.
>>>
>>> I have the following useless in my code, most is legacy... the question...
>>> Can this also be automated by the new code at engine side?
>>> It should or things will break...
>>>
>>
>> For ovirt node -
>>
>> For images 3.3 and above the code below can be removed, we will make
>> shore that the ovirt-node-plugin-vdsm would not create the brXXX bridges
>> (or if we have no choice remove them).
>
> I thought this is created in the node-core...
> Just confirmed.
> A node without vdsm plugin also create that bridge.
> vdsm has nothing to do with this process as far as I know.
>
>> For images 3.2 and below we still need this code, because oVirt node
>> creates brXXX bridges and the engine do not configure the network
>> automatically if a bridge exists on the interface.
>
> It is not just 'need this code' it is that we cannot use the bridgeless solution at enigne.
> Options:
>
> 1. We need to detect node version and perform bridgeless deployment if node is >= x, but we do not know this at engine when we deploy a host... we even do not know that it is ovirt-node.
>
> 2. I release a new minor version of ovirt-host-deploy that delete the bridge regardless of the mode.
>
> 3. Engine will be able to delete this bridge just like he is able to create the management bridge.
>
>> The down side to the above is that for management networks that
>> configured in the engine as bridgeless the management network on the
>> host would still be bridged thus will be marked as not-in-sync.
>
> Right, and because of that I think that (3) is the best solution.

adding mike - not sure if this is the solution we prefer, but if we 
don't want the bridge, it should not be there and be part of the 
responsibility of the plugins that do want it.

at some point we will move to 4.0, deprecating support for things older 
than say 3.4. so that's another way to cleanup old code if we need it 
for backward compatibility in the meantime, flagging it for removal in 4.0.


>
> Thanks,
> Alon
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>



From alonbl at redhat.com  Mon May 20 19:18:52 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 20 May 2013 15:18:52 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <519A751C.1040505@redhat.com>
References: <20121225122722.GG7274@redhat.com> <519A0DBE.4050804@redhat.com>
	<1387474947.2425969.1369051085926.JavaMail.root@redhat.com>
	<519A1D4E.7070607@redhat.com>
	<233995750.2453181.1369055319701.JavaMail.root@redhat.com>
	<519A751C.1040505@redhat.com>
Message-ID: <1254422638.2580437.1369077532335.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Livnat Peer" <lpeer at redhat.com>, "arch" <arch at ovirt.org>, "Mike Burns" <mburns at redhat.com>
> Sent: Monday, May 20, 2013 10:10:20 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> On 05/20/2013 04:08 PM, Alon Bar-Lev wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Livnat Peer" <lpeer at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: "Moti Asayag" <masayag at redhat.com>, "arch" <arch at ovirt.org>
> >> Sent: Monday, May 20, 2013 3:55:42 PM
> >> Subject: Re: feature suggestion: initial generation of management network
> >>
> >> On 05/20/2013 02:58 PM, Alon Bar-Lev wrote:
> >>> Hi,
> >>>
> >>> Now another issue... ovirt-node.
> >>>
> >>> In ovirt-node, the node already defines a bridge which is called
> >>> br at INTERFACE@, this is done automatically.
> >>> The IP address of ovirt-node is assigned to that bridge, so we always
> >>> have
> >>> a bridge at ovirt-node.
> >>>
> >>> I have the following useless in my code, most is legacy... the
> >>> question...
> >>> Can this also be automated by the new code at engine side?
> >>> It should or things will break...
> >>>
> >>
> >> For ovirt node -
> >>
> >> For images 3.3 and above the code below can be removed, we will make
> >> shore that the ovirt-node-plugin-vdsm would not create the brXXX bridges
> >> (or if we have no choice remove them).
> >
> > I thought this is created in the node-core...
> > Just confirmed.
> > A node without vdsm plugin also create that bridge.
> > vdsm has nothing to do with this process as far as I know.
> >
> >> For images 3.2 and below we still need this code, because oVirt node
> >> creates brXXX bridges and the engine do not configure the network
> >> automatically if a bridge exists on the interface.
> >
> > It is not just 'need this code' it is that we cannot use the bridgeless
> > solution at enigne.
> > Options:
> >
> > 1. We need to detect node version and perform bridgeless deployment if node
> > is >= x, but we do not know this at engine when we deploy a host... we
> > even do not know that it is ovirt-node.
> >
> > 2. I release a new minor version of ovirt-host-deploy that delete the
> > bridge regardless of the mode.
> >
> > 3. Engine will be able to delete this bridge just like he is able to create
> > the management bridge.
> >
> >> The down side to the above is that for management networks that
> >> configured in the engine as bridgeless the management network on the
> >> host would still be bridged thus will be marked as not-in-sync.
> >
> > Right, and because of that I think that (3) is the best solution.
> 
> adding mike - not sure if this is the solution we prefer, but if we
> don't want the bridge, it should not be there and be part of the
> responsibility of the plugins that do want it.
> 
> at some point we will move to 4.0, deprecating support for things older
> than say 3.4. so that's another way to cleanup old code if we need it
> for backward compatibility in the meantime, flagging it for removal in 4.0.

I do not understand why it is easy to add a bridge but not remote a bridge if it is exists.

This regardless of the requirement to remove/leave the bridge in ovirt-node.

If the feature exists in both engine and vdsm, and engine can enumerate bridges why not simply use these feature in order to provision the existing ovirt-node correctly?

Regards,
Alon


From mburns at redhat.com  Mon May 20 19:41:39 2013
From: mburns at redhat.com (Mike Burns)
Date: Mon, 20 May 2013 15:41:39 -0400
Subject: Need a new gerrit repo for ovirt-node-plugin-vdsm
In-Reply-To: <519A740F.2070405@redhat.com>
References: <5196151D.2050307@redhat.com> <5196387A.9070604@redhat.com>
	<20130519122111.GC2144@redhat.com>
	<519A2118.3030803@redhat.com> <519A740F.2070405@redhat.com>
Message-ID: <519A7C73.8030901@redhat.com>

On 05/20/2013 03:05 PM, Itamar Heim wrote:
> On 05/20/2013 04:11 PM, Mike Burns wrote:
>> On 05/19/2013 08:21 AM, Dan Kenigsberg wrote:
>>> On Fri, May 17, 2013 at 10:02:34AM -0400, Douglas Schilling Landgraf
>>> wrote:
>>>> On 05/17/2013 07:31 AM, Mike Burns wrote:
>>>>> As part of the move to a more universal oVirt Node during the 3.3 time
>>>>> frame[1], a separate repo is needed for a plugin to allow oVirt
>>>>> Node to
>>>>> communicate with oVirt Engine [2].
>>>>>
>>>>> In order to provide this plugin, I need a gerrit repo created and also
>>>>> need consensus on a name.
>>>>>
>>>>> Name proposal:
>>>>> ovirt-node-plugin-vdsm
>>>> I would go with that one.
>>>
>>> me2, though I do not have a strong opinion or explanation.
>>>
>>
>> ok, let's go with that.  I've already posted initial test packages on
>> ovirt.org[1] with that name, so let's just go with that.
>
> repo created.
> mike - you currently have +2/merge rights.

Can you give me push rights, too, so I can upload the initial code?

Mike
>
>
>>
>> Mike
>>
>> [1]
>> http://resources.ovirt.org/releases/node-base/beta/rpm/Fedora/18/noarch/
>>
>>>>
>>>>> I'm rather indifferent to what we call this, so I figured I'd include
>>>>> the arch@ list to get feedback.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Mike
>>>>>
>>>>> [1] http://www.ovirt.org/Features/Universal_Image
>>>>> [2] http://www.ovirt.org/Features/Node_vdsm_plugin
>>> _______________________________________________
>>> Infra mailing list
>>> Infra at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/infra
>>>
>>
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra



From iheim at redhat.com  Mon May 20 19:42:40 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 20 May 2013 22:42:40 +0300
Subject: Need a new gerrit repo for ovirt-node-plugin-vdsm
In-Reply-To: <519A7C73.8030901@redhat.com>
References: <5196151D.2050307@redhat.com> <5196387A.9070604@redhat.com>
	<20130519122111.GC2144@redhat.com>
	<519A2118.3030803@redhat.com> <519A740F.2070405@redhat.com>
	<519A7C73.8030901@redhat.com>
Message-ID: <519A7CB0.1040609@redhat.com>

On 05/20/2013 10:41 PM, Mike Burns wrote:
...
>>>
>>> ok, let's go with that.  I've already posted initial test packages on
>>> ovirt.org[1] with that name, so let's just go with that.
>>
>> repo created.
>> mike - you currently have +2/merge rights.
>
> Can you give me push rights, too, so I can upload the initial code?

done.


From lpeer at redhat.com  Tue May 21 06:55:13 2013
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 21 May 2013 09:55:13 +0300
Subject: feature suggestion: initial generation of management network
In-Reply-To: <233995750.2453181.1369055319701.JavaMail.root@redhat.com>
References: <20121225122722.GG7274@redhat.com> <519A0DBE.4050804@redhat.com>
	<1387474947.2425969.1369051085926.JavaMail.root@redhat.com>
	<519A1D4E.7070607@redhat.com>
	<233995750.2453181.1369055319701.JavaMail.root@redhat.com>
Message-ID: <519B1A51.5090301@redhat.com>

On 05/20/2013 04:08 PM, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
>> From: "Livnat Peer" <lpeer at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Moti Asayag" <masayag at redhat.com>, "arch" <arch at ovirt.org>
>> Sent: Monday, May 20, 2013 3:55:42 PM
>> Subject: Re: feature suggestion: initial generation of management network
>>
>> On 05/20/2013 02:58 PM, Alon Bar-Lev wrote:
>>> Hi,
>>>
>>> Now another issue... ovirt-node.
>>>
>>> In ovirt-node, the node already defines a bridge which is called
>>> br at INTERFACE@, this is done automatically.
>>> The IP address of ovirt-node is assigned to that bridge, so we always have
>>> a bridge at ovirt-node.
>>>
>>> I have the following useless in my code, most is legacy... the question...
>>> Can this also be automated by the new code at engine side?
>>> It should or things will break...
>>>
>>
>> For ovirt node -
>>
>> For images 3.3 and above the code below can be removed, we will make
>> shore that the ovirt-node-plugin-vdsm would not create the brXXX bridges
>> (or if we have no choice remove them).
> 
> I thought this is created in the node-core...
> Just confirmed.
> A node without vdsm plugin also create that bridge.
> vdsm has nothing to do with this process as far as I know.
>  

We want to discuss the bridge creation with Mike to see if it still
makes sense.
If it does we though to remove the bridges in the ovirt-node-plugin-vdsm
(which is a node code not VDSM's).

>> For images 3.2 and below we still need this code, because oVirt node
>> creates brXXX bridges and the engine do not configure the network
>> automatically if a bridge exists on the interface.
> 
> It is not just 'need this code' it is that we cannot use the bridgeless solution at enigne.

We can use it in 3.2 and 3.1 where we have sync network, a user would
need to sync network (which will remove the bridge).

> Options:
> 
> 1. We need to detect node version and perform bridgeless deployment if node is >= x, but we do not know this at engine when we deploy a host... we even do not know that it is ovirt-node.

We don't need this info.
If the bridge is there we need to run the code we have today if there is
no bridge there is nothing to do during host-deploy.

At the phase of the management bridge configuration in the engine we
detect if there is a bridge or not if there is one we don't touch the
configuration if there is none we create one (or not according to the
network definition).

> 
> 2. I release a new minor version of ovirt-host-deploy that delete the bridge regardless of the mode.
> 

That is not good as we don't have setup-network in 3.0.

> 3. Engine will be able to delete this bridge just like he is able to create the management bridge.
> 

- I don't like this as this means we need to write code for deprecated
state, we already have code for handling this today it is in the host
deploy.

- it is not a valid solution as we can't handle v 3.0

>> The down side to the above is that for management networks that
>> configured in the engine as bridgeless the management network on the
>> host would still be bridged thus will be marked as not-in-sync.
> 
> Right, and because of that I think that (3) is the best solution.
> 

> Thanks,
> Alon
> 



From lpeer at redhat.com  Tue May 21 06:58:33 2013
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 21 May 2013 09:58:33 +0300
Subject: feature suggestion: initial generation of management network
In-Reply-To: <1254422638.2580437.1369077532335.JavaMail.root@redhat.com>
References: <20121225122722.GG7274@redhat.com> <519A0DBE.4050804@redhat.com>
	<1387474947.2425969.1369051085926.JavaMail.root@redhat.com>
	<519A1D4E.7070607@redhat.com>
	<233995750.2453181.1369055319701.JavaMail.root@redhat.com>
	<519A751C.1040505@redhat.com>
	<1254422638.2580437.1369077532335.JavaMail.root@redhat.com>
Message-ID: <519B1B19.3000102@redhat.com>

On 05/20/2013 10:18 PM, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Livnat Peer" <lpeer at redhat.com>, "arch" <arch at ovirt.org>, "Mike Burns" <mburns at redhat.com>
>> Sent: Monday, May 20, 2013 10:10:20 PM
>> Subject: Re: feature suggestion: initial generation of management network
>>
>> On 05/20/2013 04:08 PM, Alon Bar-Lev wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>> Cc: "Moti Asayag" <masayag at redhat.com>, "arch" <arch at ovirt.org>
>>>> Sent: Monday, May 20, 2013 3:55:42 PM
>>>> Subject: Re: feature suggestion: initial generation of management network
>>>>
>>>> On 05/20/2013 02:58 PM, Alon Bar-Lev wrote:
>>>>> Hi,
>>>>>
>>>>> Now another issue... ovirt-node.
>>>>>
>>>>> In ovirt-node, the node already defines a bridge which is called
>>>>> br at INTERFACE@, this is done automatically.
>>>>> The IP address of ovirt-node is assigned to that bridge, so we always
>>>>> have
>>>>> a bridge at ovirt-node.
>>>>>
>>>>> I have the following useless in my code, most is legacy... the
>>>>> question...
>>>>> Can this also be automated by the new code at engine side?
>>>>> It should or things will break...
>>>>>
>>>>
>>>> For ovirt node -
>>>>
>>>> For images 3.3 and above the code below can be removed, we will make
>>>> shore that the ovirt-node-plugin-vdsm would not create the brXXX bridges
>>>> (or if we have no choice remove them).
>>>
>>> I thought this is created in the node-core...
>>> Just confirmed.
>>> A node without vdsm plugin also create that bridge.
>>> vdsm has nothing to do with this process as far as I know.
>>>
>>>> For images 3.2 and below we still need this code, because oVirt node
>>>> creates brXXX bridges and the engine do not configure the network
>>>> automatically if a bridge exists on the interface.
>>>
>>> It is not just 'need this code' it is that we cannot use the bridgeless
>>> solution at enigne.
>>> Options:
>>>
>>> 1. We need to detect node version and perform bridgeless deployment if node
>>> is >= x, but we do not know this at engine when we deploy a host... we
>>> even do not know that it is ovirt-node.
>>>
>>> 2. I release a new minor version of ovirt-host-deploy that delete the
>>> bridge regardless of the mode.
>>>
>>> 3. Engine will be able to delete this bridge just like he is able to create
>>> the management bridge.
>>>
>>>> The down side to the above is that for management networks that
>>>> configured in the engine as bridgeless the management network on the
>>>> host would still be bridged thus will be marked as not-in-sync.
>>>
>>> Right, and because of that I think that (3) is the best solution.
>>
>> adding mike - not sure if this is the solution we prefer, but if we
>> don't want the bridge, it should not be there and be part of the
>> responsibility of the plugins that do want it.
>>
>> at some point we will move to 4.0, deprecating support for things older
>> than say 3.4. so that's another way to cleanup old code if we need it
>> for backward compatibility in the meantime, flagging it for removal in 4.0.
> 
> I do not understand why it is easy to add a bridge but not remote a bridge if it is exists.

we don't have the setup network API in 3.0

> 
> This regardless of the requirement to remove/leave the bridge in ovirt-node.
> 
> If the feature exists in both engine and vdsm, and engine can enumerate bridges why not simply use these feature in order to provision the existing ovirt-node correctly?

I value the fact that you want to clean the host-deploy code so much but
I believe that adding a code that is handling a deprecate state to the
engine or VDSM is not in the best interest of our project.

> 
> Regards,
> Alon
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 
> 



From alonbl at redhat.com  Tue May 21 07:11:54 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 21 May 2013 03:11:54 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <519B1B19.3000102@redhat.com>
References: <20121225122722.GG7274@redhat.com> <519A0DBE.4050804@redhat.com>
	<1387474947.2425969.1369051085926.JavaMail.root@redhat.com>
	<519A1D4E.7070607@redhat.com>
	<233995750.2453181.1369055319701.JavaMail.root@redhat.com>
	<519A751C.1040505@redhat.com>
	<1254422638.2580437.1369077532335.JavaMail.root@redhat.com>
	<519B1B19.3000102@redhat.com>
Message-ID: <2116809742.2688577.1369120314496.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Itamar Heim" <iheim at redhat.com>, "arch" <arch at ovirt.org>
> Sent: Tuesday, May 21, 2013 9:58:33 AM
> Subject: Re: feature suggestion: initial generation of management network
> 
> On 05/20/2013 10:18 PM, Alon Bar-Lev wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Itamar Heim" <iheim at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: "Livnat Peer" <lpeer at redhat.com>, "arch" <arch at ovirt.org>, "Mike
> >> Burns" <mburns at redhat.com>
> >> Sent: Monday, May 20, 2013 10:10:20 PM
> >> Subject: Re: feature suggestion: initial generation of management network
> >>
> >> On 05/20/2013 04:08 PM, Alon Bar-Lev wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Livnat Peer" <lpeer at redhat.com>
> >>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>> Cc: "Moti Asayag" <masayag at redhat.com>, "arch" <arch at ovirt.org>
> >>>> Sent: Monday, May 20, 2013 3:55:42 PM
> >>>> Subject: Re: feature suggestion: initial generation of management
> >>>> network
> >>>>
> >>>> On 05/20/2013 02:58 PM, Alon Bar-Lev wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Now another issue... ovirt-node.
> >>>>>
> >>>>> In ovirt-node, the node already defines a bridge which is called
> >>>>> br at INTERFACE@, this is done automatically.
> >>>>> The IP address of ovirt-node is assigned to that bridge, so we always
> >>>>> have
> >>>>> a bridge at ovirt-node.
> >>>>>
> >>>>> I have the following useless in my code, most is legacy... the
> >>>>> question...
> >>>>> Can this also be automated by the new code at engine side?
> >>>>> It should or things will break...
> >>>>>
> >>>>
> >>>> For ovirt node -
> >>>>
> >>>> For images 3.3 and above the code below can be removed, we will make
> >>>> shore that the ovirt-node-plugin-vdsm would not create the brXXX bridges
> >>>> (or if we have no choice remove them).
> >>>
> >>> I thought this is created in the node-core...
> >>> Just confirmed.
> >>> A node without vdsm plugin also create that bridge.
> >>> vdsm has nothing to do with this process as far as I know.
> >>>
> >>>> For images 3.2 and below we still need this code, because oVirt node
> >>>> creates brXXX bridges and the engine do not configure the network
> >>>> automatically if a bridge exists on the interface.
> >>>
> >>> It is not just 'need this code' it is that we cannot use the bridgeless
> >>> solution at enigne.
> >>> Options:
> >>>
> >>> 1. We need to detect node version and perform bridgeless deployment if
> >>> node
> >>> is >= x, but we do not know this at engine when we deploy a host... we
> >>> even do not know that it is ovirt-node.
> >>>
> >>> 2. I release a new minor version of ovirt-host-deploy that delete the
> >>> bridge regardless of the mode.
> >>>
> >>> 3. Engine will be able to delete this bridge just like he is able to
> >>> create
> >>> the management bridge.
> >>>
> >>>> The down side to the above is that for management networks that
> >>>> configured in the engine as bridgeless the management network on the
> >>>> host would still be bridged thus will be marked as not-in-sync.
> >>>
> >>> Right, and because of that I think that (3) is the best solution.
> >>
> >> adding mike - not sure if this is the solution we prefer, but if we
> >> don't want the bridge, it should not be there and be part of the
> >> responsibility of the plugins that do want it.
> >>
> >> at some point we will move to 4.0, deprecating support for things older
> >> than say 3.4. so that's another way to cleanup old code if we need it
> >> for backward compatibility in the meantime, flagging it for removal in
> >> 4.0.
> > 
> > I do not understand why it is easy to add a bridge but not remote a bridge
> > if it is exists.
> 
> we don't have the setup network API in 3.0

But we do have delNetwork of vdsm?

> 
> > 
> > This regardless of the requirement to remove/leave the bridge in
> > ovirt-node.
> > 
> > If the feature exists in both engine and vdsm, and engine can enumerate
> > bridges why not simply use these feature in order to provision the
> > existing ovirt-node correctly?
> 
> I value the fact that you want to clean the host-deploy code so much but
> I believe that adding a code that is handling a deprecate state to the
> engine or VDSM is not in the best interest of our project.

This is not the intention, you are completely wrong.
As I wrote, host-deploy *WILL NOT* remove bridge if it does not need to create any, so currently we broke node support.
Either we handle the bridge at host-deploy or not, what you suggesting is hybrid solution, in which, once again, we duplicate logic between components.
I will release a new minor of ovirt-host-deploy to manage that, as I understand where it is heading.

Thanks,
Alon


From danken at redhat.com  Tue May 21 09:09:19 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Tue, 21 May 2013 12:09:19 +0300
Subject: feature suggestion: initial generation of management network
In-Reply-To: <1254422638.2580437.1369077532335.JavaMail.root@redhat.com>
References: <20121225122722.GG7274@redhat.com> <519A0DBE.4050804@redhat.com>
	<1387474947.2425969.1369051085926.JavaMail.root@redhat.com>
	<519A1D4E.7070607@redhat.com>
	<233995750.2453181.1369055319701.JavaMail.root@redhat.com>
	<519A751C.1040505@redhat.com>
	<1254422638.2580437.1369077532335.JavaMail.root@redhat.com>
Message-ID: <20130521090919.GA11208@redhat.com>

On Mon, May 20, 2013 at 03:18:52PM -0400, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "Livnat Peer" <lpeer at redhat.com>, "arch" <arch at ovirt.org>, "Mike Burns" <mburns at redhat.com>
> > Sent: Monday, May 20, 2013 10:10:20 PM
> > Subject: Re: feature suggestion: initial generation of management network
> > 
> > On 05/20/2013 04:08 PM, Alon Bar-Lev wrote:
> > >
> > >
> > > ----- Original Message -----
> > >> From: "Livnat Peer" <lpeer at redhat.com>
> > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > >> Cc: "Moti Asayag" <masayag at redhat.com>, "arch" <arch at ovirt.org>
> > >> Sent: Monday, May 20, 2013 3:55:42 PM
> > >> Subject: Re: feature suggestion: initial generation of management network
> > >>
> > >> On 05/20/2013 02:58 PM, Alon Bar-Lev wrote:
> > >>> Hi,
> > >>>
> > >>> Now another issue... ovirt-node.
> > >>>
> > >>> In ovirt-node, the node already defines a bridge which is called
> > >>> br at INTERFACE@, this is done automatically.
> > >>> The IP address of ovirt-node is assigned to that bridge, so we always
> > >>> have
> > >>> a bridge at ovirt-node.
> > >>>
> > >>> I have the following useless in my code, most is legacy... the
> > >>> question...
> > >>> Can this also be automated by the new code at engine side?
> > >>> It should or things will break...
> > >>>
> > >>
> > >> For ovirt node -
> > >>
> > >> For images 3.3 and above the code below can be removed, we will make
> > >> shore that the ovirt-node-plugin-vdsm would not create the brXXX bridges
> > >> (or if we have no choice remove them).
> > >
> > > I thought this is created in the node-core...
> > > Just confirmed.
> > > A node without vdsm plugin also create that bridge.
> > > vdsm has nothing to do with this process as far as I know.

Indeed. And for this reason, ovirt-node should avoid creating these
brXXX bridges when ovirt-node-plugin-vdsm is installed. Obviously, this
can be done only from 3.3 and forward.

> > >
> > >> For images 3.2 and below we still need this code, because oVirt node
> > >> creates brXXX bridges and the engine do not configure the network
> > >> automatically if a bridge exists on the interface.
> > >
> > > It is not just 'need this code' it is that we cannot use the bridgeless
> > > solution at enigne.
> > > Options:
> > >
> > > 1. We need to detect node version and perform bridgeless deployment if node
> > > is >= x, but we do not know this at engine when we deploy a host... we
> > > even do not know that it is ovirt-node.
> > >
> > > 2. I release a new minor version of ovirt-host-deploy that delete the
> > > bridge regardless of the mode.
> > >
> > > 3. Engine will be able to delete this bridge just like he is able to create
> > > the management bridge.
> > >
> > >> The down side to the above is that for management networks that
> > >> configured in the engine as bridgeless the management network on the
> > >> host would still be bridged thus will be marked as not-in-sync.
> > >
> > > Right, and because of that I think that (3) is the best solution.
> > 
> > adding mike - not sure if this is the solution we prefer, but if we
> > don't want the bridge, it should not be there and be part of the
> > responsibility of the plugins that do want it.
> > 
> > at some point we will move to 4.0, deprecating support for things older
> > than say 3.4. so that's another way to cleanup old code if we need it
> > for backward compatibility in the meantime, flagging it for removal in 4.0.
> 
> I do not understand why it is easy to add a bridge but not remote a bridge if it is exists.
> 
> This regardless of the requirement to remove/leave the bridge in ovirt-node.
> 
> If the feature exists in both engine and vdsm, and engine can
> enumerate bridges why not simply use these feature in order to
> provision the existing ovirt-node correctly?

The bootstrap-time setupNetwork has to be automatic, of course.
It should create the management network, but should not ruin
pre-existing networks, that might have been defined by an admin on the
host. But we cannot distinguish an ovirt-node automatic brXXX bridge
from a same-named network, intentionally defined there.

I'm not sure if anyone is using or expecting these breth* bridges.
In the vdsm/engine context, they are no more than nuisance. Someone once
told me that such nuisance should be removed at the nearest point
possible, and luckily, we already have the code to do this in
ovirt-host-deploy.

So I'm voting for (3): if ovirt-host-deploy does not receive
VDSM/managementBridgeName, it should still remove the brXXX bridges.

Dan.


From danken at redhat.com  Tue May 21 09:17:13 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Tue, 21 May 2013 12:17:13 +0300
Subject: Need a new gerrit repo for ovirt-node-plugin-vdsm
In-Reply-To: <519A7C73.8030901@redhat.com>
References: <5196151D.2050307@redhat.com> <5196387A.9070604@redhat.com>
	<20130519122111.GC2144@redhat.com> <519A2118.3030803@redhat.com>
	<519A740F.2070405@redhat.com> <519A7C73.8030901@redhat.com>
Message-ID: <20130521091713.GD11208@redhat.com>

On Mon, May 20, 2013 at 03:41:39PM -0400, Mike Burns wrote:
> On 05/20/2013 03:05 PM, Itamar Heim wrote:
> >On 05/20/2013 04:11 PM, Mike Burns wrote:
> >>On 05/19/2013 08:21 AM, Dan Kenigsberg wrote:
> >>>On Fri, May 17, 2013 at 10:02:34AM -0400, Douglas Schilling Landgraf
> >>>wrote:
> >>>>On 05/17/2013 07:31 AM, Mike Burns wrote:
> >>>>>As part of the move to a more universal oVirt Node during the 3.3 time
> >>>>>frame[1], a separate repo is needed for a plugin to allow oVirt
> >>>>>Node to
> >>>>>communicate with oVirt Engine [2].
> >>>>>
> >>>>>In order to provide this plugin, I need a gerrit repo created and also
> >>>>>need consensus on a name.
> >>>>>
> >>>>>Name proposal:
> >>>>>ovirt-node-plugin-vdsm
> >>>>I would go with that one.
> >>>
> >>>me2, though I do not have a strong opinion or explanation.
> >>>
> >>
> >>ok, let's go with that.  I've already posted initial test packages on
> >>ovirt.org[1] with that name, so let's just go with that.
> >
> >repo created.
> >mike - you currently have +2/merge rights.
> 
> Can you give me push rights, too, so I can upload the initial code?
> 
> Mike

It's slightly off topic, Mark, but how do you feel about not creating
the brXXX bridges when this plugin is installed?

And could you tell me if they are ever used, outside the vdsm/engine
context?

Regards,
Dan.


From danken at redhat.com  Tue May 21 09:47:04 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Tue, 21 May 2013 12:47:04 +0300
Subject: feature suggestion: initial generation of management network
In-Reply-To: <20130521090919.GA11208@redhat.com>
References: <20121225122722.GG7274@redhat.com> <519A0DBE.4050804@redhat.com>
	<1387474947.2425969.1369051085926.JavaMail.root@redhat.com>
	<519A1D4E.7070607@redhat.com>
	<233995750.2453181.1369055319701.JavaMail.root@redhat.com>
	<519A751C.1040505@redhat.com>
	<1254422638.2580437.1369077532335.JavaMail.root@redhat.com>
	<20130521090919.GA11208@redhat.com>
Message-ID: <20130521094704.GA13208@redhat.com>

On Tue, May 21, 2013 at 12:09:19PM +0300, Dan Kenigsberg wrote:
> On Mon, May 20, 2013 at 03:18:52PM -0400, Alon Bar-Lev wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Itamar Heim" <iheim at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "Livnat Peer" <lpeer at redhat.com>, "arch" <arch at ovirt.org>, "Mike Burns" <mburns at redhat.com>
> > > Sent: Monday, May 20, 2013 10:10:20 PM
> > > Subject: Re: feature suggestion: initial generation of management network
> > > 
> > > On 05/20/2013 04:08 PM, Alon Bar-Lev wrote:
> > > >
> > > >
> > > > ----- Original Message -----
> > > >> From: "Livnat Peer" <lpeer at redhat.com>
> > > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > >> Cc: "Moti Asayag" <masayag at redhat.com>, "arch" <arch at ovirt.org>
> > > >> Sent: Monday, May 20, 2013 3:55:42 PM
> > > >> Subject: Re: feature suggestion: initial generation of management network
> > > >>
> > > >> On 05/20/2013 02:58 PM, Alon Bar-Lev wrote:
> > > >>> Hi,
> > > >>>
> > > >>> Now another issue... ovirt-node.
> > > >>>
> > > >>> In ovirt-node, the node already defines a bridge which is called
> > > >>> br at INTERFACE@, this is done automatically.
> > > >>> The IP address of ovirt-node is assigned to that bridge, so we always
> > > >>> have
> > > >>> a bridge at ovirt-node.
> > > >>>
> > > >>> I have the following useless in my code, most is legacy... the
> > > >>> question...
> > > >>> Can this also be automated by the new code at engine side?
> > > >>> It should or things will break...
> > > >>>
> > > >>
> > > >> For ovirt node -
> > > >>
> > > >> For images 3.3 and above the code below can be removed, we will make
> > > >> shore that the ovirt-node-plugin-vdsm would not create the brXXX bridges
> > > >> (or if we have no choice remove them).
> > > >
> > > > I thought this is created in the node-core...
> > > > Just confirmed.
> > > > A node without vdsm plugin also create that bridge.
> > > > vdsm has nothing to do with this process as far as I know.
> 
> Indeed. And for this reason, ovirt-node should avoid creating these
> brXXX bridges when ovirt-node-plugin-vdsm is installed. Obviously, this
> can be done only from 3.3 and forward.
> 
> > > >
> > > >> For images 3.2 and below we still need this code, because oVirt node
> > > >> creates brXXX bridges and the engine do not configure the network
> > > >> automatically if a bridge exists on the interface.
> > > >
> > > > It is not just 'need this code' it is that we cannot use the bridgeless
> > > > solution at enigne.
> > > > Options:
> > > >
> > > > 1. We need to detect node version and perform bridgeless deployment if node
> > > > is >= x, but we do not know this at engine when we deploy a host... we
> > > > even do not know that it is ovirt-node.
> > > >
> > > > 2. I release a new minor version of ovirt-host-deploy that delete the
> > > > bridge regardless of the mode.
> > > >
> > > > 3. Engine will be able to delete this bridge just like he is able to create
> > > > the management bridge.
> > > >
> > > >> The down side to the above is that for management networks that
> > > >> configured in the engine as bridgeless the management network on the
> > > >> host would still be bridged thus will be marked as not-in-sync.
> > > >
> > > > Right, and because of that I think that (3) is the best solution.
> > > 
> > > adding mike - not sure if this is the solution we prefer, but if we
> > > don't want the bridge, it should not be there and be part of the
> > > responsibility of the plugins that do want it.
> > > 
> > > at some point we will move to 4.0, deprecating support for things older
> > > than say 3.4. so that's another way to cleanup old code if we need it
> > > for backward compatibility in the meantime, flagging it for removal in 4.0.
> > 
> > I do not understand why it is easy to add a bridge but not remote a bridge if it is exists.
> > 
> > This regardless of the requirement to remove/leave the bridge in ovirt-node.
> > 
> > If the feature exists in both engine and vdsm, and engine can
> > enumerate bridges why not simply use these feature in order to
> > provision the existing ovirt-node correctly?
> 
> The bootstrap-time setupNetwork has to be automatic, of course.
> It should create the management network, but should not ruin
> pre-existing networks, that might have been defined by an admin on the
> host. But we cannot distinguish an ovirt-node automatic brXXX bridge
> from a same-named network, intentionally defined there.
> 
> I'm not sure if anyone is using or expecting these breth* bridges.
> In the vdsm/engine context, they are no more than nuisance. Someone once
> told me that such nuisance should be removed at the nearest point
> possible, and luckily, we already have the code to do this in
> ovirt-host-deploy.
> 
> So I'm voting for (3): if ovirt-host-deploy does not receive
> VDSM/managementBridgeName, it should still remove the brXXX bridges.

arghh, obviously, I was voting for (1), and obviously, there were other
messages in this thread while I was writing mine.


From alonbl at redhat.com  Tue May 21 10:35:05 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 21 May 2013 06:35:05 -0400 (EDT)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <20130521094704.GA13208@redhat.com>
References: <20121225122722.GG7274@redhat.com>
	<1387474947.2425969.1369051085926.JavaMail.root@redhat.com>
	<519A1D4E.7070607@redhat.com>
	<233995750.2453181.1369055319701.JavaMail.root@redhat.com>
	<519A751C.1040505@redhat.com>
	<1254422638.2580437.1369077532335.JavaMail.root@redhat.com>
	<20130521090919.GA11208@redhat.com>
	<20130521094704.GA13208@redhat.com>
Message-ID: <1674451289.2737699.1369132505310.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>, "Mike Burns" <mburns at redhat.com>
> Cc: "Itamar Heim" <iheim at redhat.com>, "arch" <arch at ovirt.org>
> Sent: Tuesday, May 21, 2013 12:47:04 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> On Tue, May 21, 2013 at 12:09:19PM +0300, Dan Kenigsberg wrote:
> > On Mon, May 20, 2013 at 03:18:52PM -0400, Alon Bar-Lev wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Itamar Heim" <iheim at redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > Cc: "Livnat Peer" <lpeer at redhat.com>, "arch" <arch at ovirt.org>, "Mike
> > > > Burns" <mburns at redhat.com>
> > > > Sent: Monday, May 20, 2013 10:10:20 PM
> > > > Subject: Re: feature suggestion: initial generation of management
> > > > network
> > > > 
> > > > On 05/20/2013 04:08 PM, Alon Bar-Lev wrote:
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > >> From: "Livnat Peer" <lpeer at redhat.com>
> > > > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > >> Cc: "Moti Asayag" <masayag at redhat.com>, "arch" <arch at ovirt.org>
> > > > >> Sent: Monday, May 20, 2013 3:55:42 PM
> > > > >> Subject: Re: feature suggestion: initial generation of management
> > > > >> network
> > > > >>
> > > > >> On 05/20/2013 02:58 PM, Alon Bar-Lev wrote:
> > > > >>> Hi,
> > > > >>>
> > > > >>> Now another issue... ovirt-node.
> > > > >>>
> > > > >>> In ovirt-node, the node already defines a bridge which is called
> > > > >>> br at INTERFACE@, this is done automatically.
> > > > >>> The IP address of ovirt-node is assigned to that bridge, so we
> > > > >>> always
> > > > >>> have
> > > > >>> a bridge at ovirt-node.
> > > > >>>
> > > > >>> I have the following useless in my code, most is legacy... the
> > > > >>> question...
> > > > >>> Can this also be automated by the new code at engine side?
> > > > >>> It should or things will break...
> > > > >>>
> > > > >>
> > > > >> For ovirt node -
> > > > >>
> > > > >> For images 3.3 and above the code below can be removed, we will make
> > > > >> shore that the ovirt-node-plugin-vdsm would not create the brXXX
> > > > >> bridges
> > > > >> (or if we have no choice remove them).
> > > > >
> > > > > I thought this is created in the node-core...
> > > > > Just confirmed.
> > > > > A node without vdsm plugin also create that bridge.
> > > > > vdsm has nothing to do with this process as far as I know.
> > 
> > Indeed. And for this reason, ovirt-node should avoid creating these
> > brXXX bridges when ovirt-node-plugin-vdsm is installed. Obviously, this
> > can be done only from 3.3 and forward.
> > 
> > > > >
> > > > >> For images 3.2 and below we still need this code, because oVirt node
> > > > >> creates brXXX bridges and the engine do not configure the network
> > > > >> automatically if a bridge exists on the interface.
> > > > >
> > > > > It is not just 'need this code' it is that we cannot use the
> > > > > bridgeless
> > > > > solution at enigne.
> > > > > Options:
> > > > >
> > > > > 1. We need to detect node version and perform bridgeless deployment
> > > > > if node
> > > > > is >= x, but we do not know this at engine when we deploy a host...
> > > > > we
> > > > > even do not know that it is ovirt-node.
> > > > >
> > > > > 2. I release a new minor version of ovirt-host-deploy that delete the
> > > > > bridge regardless of the mode.
> > > > >
> > > > > 3. Engine will be able to delete this bridge just like he is able to
> > > > > create
> > > > > the management bridge.
> > > > >
> > > > >> The down side to the above is that for management networks that
> > > > >> configured in the engine as bridgeless the management network on the
> > > > >> host would still be bridged thus will be marked as not-in-sync.
> > > > >
> > > > > Right, and because of that I think that (3) is the best solution.
> > > > 
> > > > adding mike - not sure if this is the solution we prefer, but if we
> > > > don't want the bridge, it should not be there and be part of the
> > > > responsibility of the plugins that do want it.
> > > > 
> > > > at some point we will move to 4.0, deprecating support for things older
> > > > than say 3.4. so that's another way to cleanup old code if we need it
> > > > for backward compatibility in the meantime, flagging it for removal in
> > > > 4.0.
> > > 
> > > I do not understand why it is easy to add a bridge but not remote a
> > > bridge if it is exists.
> > > 
> > > This regardless of the requirement to remove/leave the bridge in
> > > ovirt-node.
> > > 
> > > If the feature exists in both engine and vdsm, and engine can
> > > enumerate bridges why not simply use these feature in order to
> > > provision the existing ovirt-node correctly?
> > 
> > The bootstrap-time setupNetwork has to be automatic, of course.
> > It should create the management network, but should not ruin
> > pre-existing networks, that might have been defined by an admin on the
> > host. But we cannot distinguish an ovirt-node automatic brXXX bridge
> > from a same-named network, intentionally defined there.
> > 
> > I'm not sure if anyone is using or expecting these breth* bridges.
> > In the vdsm/engine context, they are no more than nuisance. Someone once
> > told me that such nuisance should be removed at the nearest point
> > possible, and luckily, we already have the code to do this in
> > ovirt-host-deploy.
> > 
> > So I'm voting for (3): if ovirt-host-deploy does not receive
> > VDSM/managementBridgeName, it should still remove the brXXX bridges.
> 
> arghh, obviously, I was voting for (1), and obviously, there were other
> messages in this thread while I was writing mine.
> 

Regardless the implications made earlier, the mission is not originated in cleaning up the code, but reduce the risk of breakage during host-deploy.

Although we managed to reduce the risk of breakage when using standard host, we fail to do so using ovirt-node if we require to delete a bridge:

1. We continue to guess the interface used to communicate with engine by trying to find the best route from the host to vdsm, while outgoing route may be different than incoming route.

2. We continue to try to initiate outgoing communication from host to engine in order to find out when interface is up, while there is no guarantee that we can initiate communication.

3. We keep starting libvirtd, messagebus on host and use delNetwork, vdsm-store-net-config on nodes.

So unfortunately, I don't see any real value of creating the bridge at engine when we deal with ovirt-node.

I think the simplest way is to have VdsDeploy (engine side) to set bridge name if node is detected, so that bridge will be created by host-deploy using the legacy logic.

Regards,
Alon


From mburns at redhat.com  Tue May 21 12:49:28 2013
From: mburns at redhat.com (Mike Burns)
Date: Tue, 21 May 2013 08:49:28 -0400
Subject: feature suggestion: initial generation of management network
In-Reply-To: <1674451289.2737699.1369132505310.JavaMail.root@redhat.com>
References: <20121225122722.GG7274@redhat.com>
	<1387474947.2425969.1369051085926.JavaMail.root@redhat.com>
	<519A1D4E.7070607@redhat.com>
	<233995750.2453181.1369055319701.JavaMail.root@redhat.com>
	<519A751C.1040505@redhat.com>
	<1254422638.2580437.1369077532335.JavaMail.root@redhat.com>
	<20130521090919.GA11208@redhat.com>
	<20130521094704.GA13208@redhat.com>
	<1674451289.2737699.1369132505310.JavaMail.root@redhat.com>
Message-ID: <519B6D58.7070801@redhat.com>

On 05/21/2013 06:35 AM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Dan Kenigsberg" <danken at redhat.com> To: "Alon Bar-Lev"
>> <alonbl at redhat.com>, "Mike Burns" <mburns at redhat.com> Cc: "Itamar
>> Heim" <iheim at redhat.com>, "arch" <arch at ovirt.org> Sent: Tuesday,
>> May 21, 2013 12:47:04 PM Subject: Re: feature suggestion: initial
>> generation of management network
>>
>> On Tue, May 21, 2013 at 12:09:19PM +0300, Dan Kenigsberg wrote:
>>> On Mon, May 20, 2013 at 03:18:52PM -0400, Alon Bar-Lev wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Itamar Heim" <iheim at redhat.com> To: "Alon Bar-Lev"
>>>>> <alonbl at redhat.com> Cc: "Livnat Peer" <lpeer at redhat.com>,
>>>>> "arch" <arch at ovirt.org>, "Mike Burns" <mburns at redhat.com>
>>>>> Sent: Monday, May 20, 2013 10:10:20 PM Subject: Re: feature
>>>>> suggestion: initial generation of management network
>>>>>
>>>>> On 05/20/2013 04:08 PM, Alon Bar-Lev wrote:
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Livnat Peer" <lpeer at redhat.com> To: "Alon Bar-Lev"
>>>>>>> <alonbl at redhat.com> Cc: "Moti Asayag"
>>>>>>> <masayag at redhat.com>, "arch" <arch at ovirt.org> Sent:
>>>>>>> Monday, May 20, 2013 3:55:42 PM Subject: Re: feature
>>>>>>> suggestion: initial generation of management network
>>>>>>>
>>>>>>> On 05/20/2013 02:58 PM, Alon Bar-Lev wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Now another issue... ovirt-node.
>>>>>>>>
>>>>>>>> In ovirt-node, the node already defines a bridge which
>>>>>>>> is called br at INTERFACE@, this is done automatically.
>>>>>>>> The IP address of ovirt-node is assigned to that
>>>>>>>> bridge, so we always have a bridge at ovirt-node.
>>>>>>>>
>>>>>>>> I have the following useless in my code, most is
>>>>>>>> legacy... the question... Can this also be automated by
>>>>>>>> the new code at engine side? It should or things will
>>>>>>>> break...
>>>>>>>>
>>>>>>>
>>>>>>> For ovirt node -
>>>>>>>
>>>>>>> For images 3.3 and above the code below can be removed,
>>>>>>> we will make shore that the ovirt-node-plugin-vdsm would
>>>>>>> not create the brXXX bridges (or if we have no choice
>>>>>>> remove them).
>>>>>>
>>>>>> I thought this is created in the node-core... Just
>>>>>> confirmed. A node without vdsm plugin also create that
>>>>>> bridge. vdsm has nothing to do with this process as far as
>>>>>> I know.
>>>
>>> Indeed. And for this reason, ovirt-node should avoid creating
>>> these brXXX bridges when ovirt-node-plugin-vdsm is installed.
>>> Obviously, this can be done only from 3.3 and forward.
>>>
>>>>>>
>>>>>>> For images 3.2 and below we still need this code, because
>>>>>>> oVirt node creates brXXX bridges and the engine do not
>>>>>>> configure the network automatically if a bridge exists on
>>>>>>> the interface.
>>>>>>
>>>>>> It is not just 'need this code' it is that we cannot use
>>>>>> the bridgeless solution at enigne. Options:
>>>>>>
>>>>>> 1. We need to detect node version and perform bridgeless
>>>>>> deployment if node is >= x, but we do not know this at
>>>>>> engine when we deploy a host... we even do not know that it
>>>>>> is ovirt-node.
>>>>>>
>>>>>> 2. I release a new minor version of ovirt-host-deploy that
>>>>>> delete the bridge regardless of the mode.
>>>>>>
>>>>>> 3. Engine will be able to delete this bridge just like he
>>>>>> is able to create the management bridge.
>>>>>>
>>>>>>> The down side to the above is that for management
>>>>>>> networks that configured in the engine as bridgeless the
>>>>>>> management network on the host would still be bridged
>>>>>>> thus will be marked as not-in-sync.
>>>>>>
>>>>>> Right, and because of that I think that (3) is the best
>>>>>> solution.
>>>>>
>>>>> adding mike - not sure if this is the solution we prefer, but
>>>>> if we don't want the bridge, it should not be there and be
>>>>> part of the responsibility of the plugins that do want it.
>>>>>
>>>>> at some point we will move to 4.0, deprecating support for
>>>>> things older than say 3.4. so that's another way to cleanup
>>>>> old code if we need it for backward compatibility in the
>>>>> meantime, flagging it for removal in 4.0.
>>>>
>>>> I do not understand why it is easy to add a bridge but not
>>>> remote a bridge if it is exists.
>>>>
>>>> This regardless of the requirement to remove/leave the bridge
>>>> in ovirt-node.
>>>>
>>>> If the feature exists in both engine and vdsm, and engine can
>>>> enumerate bridges why not simply use these feature in order to
>>>> provision the existing ovirt-node correctly?
>>>
>>> The bootstrap-time setupNetwork has to be automatic, of course.
>>> It should create the management network, but should not ruin
>>> pre-existing networks, that might have been defined by an admin
>>> on the host. But we cannot distinguish an ovirt-node automatic
>>> brXXX bridge from a same-named network, intentionally defined
>>> there.
>>>
>>> I'm not sure if anyone is using or expecting these breth*
>>> bridges. In the vdsm/engine context, they are no more than
>>> nuisance. Someone once told me that such nuisance should be
>>> removed at the nearest point possible, and luckily, we already
>>> have the code to do this in ovirt-host-deploy.
>>>
>>> So I'm voting for (3): if ovirt-host-deploy does not receive
>>> VDSM/managementBridgeName, it should still remove the brXXX
>>> bridges.
>>
>> arghh, obviously, I was voting for (1), and obviously, there were
>> other messages in this thread while I was writing mine.
>>
>
> Regardless the implications made earlier, the mission is not
> originated in cleaning up the code, but reduce the risk of breakage
> during host-deploy.
>
> Although we managed to reduce the risk of breakage when using
> standard host, we fail to do so using ovirt-node if we require to
> delete a bridge:
>
> 1. We continue to guess the interface used to communicate with engine
> by trying to find the best route from the host to vdsm, while
> outgoing route may be different than incoming route.
>
> 2. We continue to try to initiate outgoing communication from host to
> engine in order to find out when interface is up, while there is no
> guarantee that we can initiate communication.
>
> 3. We keep starting libvirtd, messagebus on host and use delNetwork,
> vdsm-store-net-config on nodes.
>
> So unfortunately, I don't see any real value of creating the bridge
> at engine when we deal with ovirt-node.
>
> I think the simplest way is to have VdsDeploy (engine side) to set
> bridge name if node is detected, so that bridge will be created by
> host-deploy using the legacy logic.
>
> Regards, Alon
>

Catching up on this thread with analysis of impact on ovirt-node.

The request is to not create the bridge by default (or at least provide 
a method to disable bridge creation).  Having the bridge is a pretty 
basic assumption that has always been in ovirt-node.  It's not something 
we could reliably change in the timeframe of the oVirt 3.3 release. 
Beta/Feature Freeze for oVirt 3.3 is 31-May.  oVirt Node is already in 
RC for our 3.0 release.  At best, we could maybe deliver it sometime in 
June, but I don't feel it would be stable enough to be used in 3.3 GA.

Note:  there are other aspects of this as well.  We lock out network 
configuration locally based on the existence of the ovirtmgmt bridge, so 
we need to add methods to handle that issue as well.

Mike


From leonardo.bianconi at eldorado.org.br  Tue May 21 15:33:54 2013
From: leonardo.bianconi at eldorado.org.br (Leonardo Bianconi)
Date: Tue, 21 May 2013 15:33:54 +0000
Subject: oVirt on IBM POWER (PPC64) - new feature contributors
In-Reply-To: <5193A8AE.5000600@redhat.com>
References: <50EB20226B72D6419356FC320AB62B871896B600@SERV070.corp.eldorado.org.br>
	<5193A8AE.5000600@redhat.com>
Message-ID: <50EB20226B72D6419356FC320AB62B871896BB19@SERV070.corp.eldorado.org.br>

Hi all,

We are planning to deliver support for PPC64 in 4 phases. We will manage to deliver a set of patches at the end of each phase.

Phase 1

	 Change oVirt to handle other architectures by encapsulating all the architecture specific code and queries about the capabilities of the hypervisor into a new class called ArchStrategy (based on the Strategy Design Pattern). Every operation involving clusters and hosts will be validated by this new class. Some hard-coded parameters are going to be replaced by queries in the backend in order to accommodate the support for new architectures into the engine.


Phase 2

	Currently, each host hypervisor capabilities are obtained using hard-coded data structures. These structures will be replaced either by some form of integration with libosinfo or by reading internal configuration files describing these capabilities. It will be handled after Roy's patch.


Phase 3

	The code for providing the support for IBM POWER systems will be added. The encapsulation done in the previous phase will reduce the effort to include this feature into the engine. The other changes that will be introduced in this phase include:

	- Modifications in the frontend to avoid running a VM created on a POWER host in a x86-64 host (and vice-versa), 
	- All the dynamically provided capacities of the first phase will be implemented according to the capacities of the QEMU/KVM on POWER
	- The POWER processors will be available as an option in the list of processor names (this will imply in significant changes in the backend)


Phase 4

	Adapt secondary features to polish the support for POWER:

	- OVF import and export of VMs running in POWER hosts
	- Dynamic searches capable of finding hosts, pools, vms and clusters according to their architectures


Is there any ongoing oVirt architecture refactoring ? (that may conflict with Phase 1, for instance)

Any comments ?

Regards,
Vitor (vitor.lima at eldorado.org.br) / Leonardo (leonardo.bianconi at eldorado.org.br)


-----Original Message-----
From: Dave Neary [mailto:dneary at redhat.com] 
Sent: quarta-feira, 15 de maio de 2013 12:25
To: Leonardo Bianconi
Cc: arch at ovirt.org; Adam Litke
Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors

Hi,

On 05/14/2013 08:05 PM, Leonardo Bianconi wrote:
> We would like to introduce ourselves: Leonardo Bianconi and Vitor Lima.

Welcome!

> We would like to work on the features "Engine support for PPC64" (http://wiki.ovirt.org/Features/Engine_support_for_PPC64) and the "Vdsm for PPC64" (http://wiki.ovirt.org/Features/Vdsm_for_PPC64). This work has already been started by some developers at IBM.

<snip>

> About libosinfo:
> =============
> 
> In the previous discussion about this topic (http://lists.ovirt.org/pipermail/arch/2012-November/000976.html), occurred in November 2012, it was suggested that integrating the libosinfo into the engine would be a better way to handle the differences between the architectures that would be supported in the future.
> 
> Is this approach still valid? If so, when will it be available? It seems to be a dependency for oVirt "Engine_support_for_PPC64" feature implementation.


This is great news. I don't know who, specifically, has been working on this issue in IBM - perhaps Adam Litke (CCed) can update you on the progress that has been made.

Cheers,
Dave.

--
Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From rydekull at gmail.com  Wed May 22 07:41:12 2013
From: rydekull at gmail.com (Alexander Rydekull)
Date: Wed, 22 May 2013 09:41:12 +0200
Subject: oVirt on IBM POWER (PPC64) - new feature contributors
In-Reply-To: <50EB20226B72D6419356FC320AB62B871896BB19@SERV070.corp.eldorado.org.br>
References: <50EB20226B72D6419356FC320AB62B871896B600@SERV070.corp.eldorado.org.br>
	<5193A8AE.5000600@redhat.com>
	<50EB20226B72D6419356FC320AB62B871896BB19@SERV070.corp.eldorado.org.br>
Message-ID: <CAN58XQEG6zoFfo0Fo1yzaOYoRadvqUGqdGcjsWZao3hkceC09w@mail.gmail.com>

Ooh, this is like music to my ears.

If the oVirt-project needs some POWER-hardware as Jenkinsslaves, buildhosts
etc, I can surely arrange that.

/Alexander Rydekull


On Tue, May 21, 2013 at 5:33 PM, Leonardo Bianconi <
leonardo.bianconi at eldorado.org.br> wrote:

> Hi all,
>
> We are planning to deliver support for PPC64 in 4 phases. We will manage
> to deliver a set of patches at the end of each phase.
>
> Phase 1
>
>          Change oVirt to handle other architectures by encapsulating all
> the architecture specific code and queries about the capabilities of the
> hypervisor into a new class called ArchStrategy (based on the Strategy
> Design Pattern). Every operation involving clusters and hosts will be
> validated by this new class. Some hard-coded parameters are going to be
> replaced by queries in the backend in order to accommodate the support for
> new architectures into the engine.
>
>
> Phase 2
>
>         Currently, each host hypervisor capabilities are obtained using
> hard-coded data structures. These structures will be replaced either by
> some form of integration with libosinfo or by reading internal
> configuration files describing these capabilities. It will be handled after
> Roy's patch.
>
>
> Phase 3
>
>         The code for providing the support for IBM POWER systems will be
> added. The encapsulation done in the previous phase will reduce the effort
> to include this feature into the engine. The other changes that will be
> introduced in this phase include:
>
>         - Modifications in the frontend to avoid running a VM created on a
> POWER host in a x86-64 host (and vice-versa),
>         - All the dynamically provided capacities of the first phase will
> be implemented according to the capacities of the QEMU/KVM on POWER
>         - The POWER processors will be available as an option in the list
> of processor names (this will imply in significant changes in the backend)
>
>
> Phase 4
>
>         Adapt secondary features to polish the support for POWER:
>
>         - OVF import and export of VMs running in POWER hosts
>         - Dynamic searches capable of finding hosts, pools, vms and
> clusters according to their architectures
>
>
> Is there any ongoing oVirt architecture refactoring ? (that may conflict
> with Phase 1, for instance)
>
> Any comments ?
>
> Regards,
> Vitor (vitor.lima at eldorado.org.br) / Leonardo (
> leonardo.bianconi at eldorado.org.br)
>
>
> -----Original Message-----
> From: Dave Neary [mailto:dneary at redhat.com]
> Sent: quarta-feira, 15 de maio de 2013 12:25
> To: Leonardo Bianconi
> Cc: arch at ovirt.org; Adam Litke
> Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>
> Hi,
>
> On 05/14/2013 08:05 PM, Leonardo Bianconi wrote:
> > We would like to introduce ourselves: Leonardo Bianconi and Vitor Lima.
>
> Welcome!
>
> > We would like to work on the features "Engine support for PPC64" (
> http://wiki.ovirt.org/Features/Engine_support_for_PPC64) and the "Vdsm
> for PPC64" (http://wiki.ovirt.org/Features/Vdsm_for_PPC64). This work has
> already been started by some developers at IBM.
>
> <snip>
>
> > About libosinfo:
> > =============
> >
> > In the previous discussion about this topic (
> http://lists.ovirt.org/pipermail/arch/2012-November/000976.html),
> occurred in November 2012, it was suggested that integrating the libosinfo
> into the engine would be a better way to handle the differences between the
> architectures that would be supported in the future.
> >
> > Is this approach still valid? If so, when will it be available? It seems
> to be a dependency for oVirt "Engine_support_for_PPC64" feature
> implementation.
>
>
> This is great news. I don't know who, specifically, has been working on
> this issue in IBM - perhaps Adam Litke (CCed) can update you on the
> progress that has been made.
>
> Cheers,
> Dave.
>
> --
> Dave Neary - Community Action and Impact Open Source and Standards, Red
> Hat - http://community.redhat.com
> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>



-- 
/Alexander Rydekull
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20130522/cf191bbf/attachment.html>

From dfediuck at redhat.com  Wed May 22 15:55:26 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Wed, 22 May 2013 11:55:26 -0400 (EDT)
Subject: add blkIoTune support for a specific device at vm creation
In-Reply-To: <51999389.6010705@linux.vnet.ibm.com>
References: <51999389.6010705@linux.vnet.ibm.com>
Message-ID: <1600667990.9465235.1369238126197.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Mei Liu" <liumbj at linux.vnet.ibm.com>
> To: arch at ovirt.org
> Cc: dfediuck at redhat.com, wudxw at linux.vnet.ibm.com
> Sent: Monday, May 20, 2013 6:07:53 AM
> Subject: add blkIoTune support for a specific device at vm creation
> 
> Hi all,
> I would like to add blkIoTune support for a specific device at vm creation.
> 
> The code parses the 'blkIoTune' descrption for block devices at vm creation
> time and adds iotune tag accordingly.
> 
> e.g.
> Adding 'blkIoTune':{'read_bytes_sec': 6120000, 'total_iops_sec': 800} for a
> block device will add the following in dom xml for that device.
> 
> <iotune>
>       <read_bytes_sec>6120000</read_bytes_sec>
>       <total_iops_sec>800</total_iops_sec>
> </iotune>
> 
> The patch is under review in http://gerrit.ovirt.org/#/c/14636/ .
> 
> Does the patch meet the requirement of the engine or the whole
> architecture? Are the new parameters properly placed?  Any suggestions
> are welcomed.
> 
> TIA.
> 
> Best reagrds,
> Mei Liu (Rose)
> 
> 

Hi Mei Liu,
Apologies for my late response.
Is there an engine implementation for it?
This is important enough to be considered on how it works in a cluster
on not just on host level. For example, what happens during and after
live migration?


From mgoldboi at redhat.com  Thu May 23 10:50:31 2013
From: mgoldboi at redhat.com (Moran Goldboim)
Date: Thu, 23 May 2013 13:50:31 +0300
Subject: [3.3 release process] feature freeze readiness
Message-ID: <519DF477.9000300@redhat.com>

we are about a week away from feature freeze of oVirt 3.3 (May 31st). In 
order to be able to converge to this date we would need your help 
(feature owners) understanding feature/overall status.

I have updated  OVirt 3.3 release-management page [1] with features 
status table [2]. having this complete table filled will help us 
determine this version readiness.

a test page addition is needed for each feature (link through the table) 
- this will enable us good visibility and testing of those features in 
test-day.

I have left the old 3.3 feature overview -just below the new table, to 
make sure i have taken all needed from that info. please verify all you 
need is in the table, since this part will be deleted on feature freeze 
readiness review - next Wednesday meeting.

completing filling this table should be done no later than Tuesday May 28th.

Thanks.

[1]http://www.ovirt.org/OVirt_3.3_release-management
[2]http://www.ovirt.org/OVirt_3.3_release-management#Features_Status_Table
[3]http://www.ovirt.org/OVirt_3.3_release-management#Features



From mburns at redhat.com  Thu May 23 11:58:58 2013
From: mburns at redhat.com (Mike Burns)
Date: Thu, 23 May 2013 07:58:58 -0400
Subject: [3.3 release process] feature freeze readiness
In-Reply-To: <519DF477.9000300@redhat.com>
References: <519DF477.9000300@redhat.com>
Message-ID: <519E0482.9000803@redhat.com>

On 05/23/2013 06:50 AM, Moran Goldboim wrote:
> we are about a week away from feature freeze of oVirt 3.3 (May 31st). In
> order to be able to converge to this date we would need your help
> (feature owners) understanding feature/overall status.
>
> I have updated  OVirt 3.3 release-management page [1] with features
> status table [2]. having this complete table filled will help us
> determine this version readiness.
>
> a test page addition is needed for each feature (link through the table)
> - this will enable us good visibility and testing of those features in
> test-day.
>
> I have left the old 3.3 feature overview -just below the new table, to
> make sure i have taken all needed from that info. please verify all you
> need is in the table, since this part will be deleted on feature freeze
> readiness review - next Wednesday meeting.
>
> completing filling this table should be done no later than Tuesday May
> 28th.

An example of a testing chart is available on [4]

Mike

[4] http://www.ovirt.org/Features/Node_vdsm_plugin#Testing

>
> Thanks.
>
> [1]http://www.ovirt.org/OVirt_3.3_release-management
> [2]http://www.ovirt.org/OVirt_3.3_release-management#Features_Status_Table
> [3]http://www.ovirt.org/OVirt_3.3_release-management#Features
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch



From danken at redhat.com  Thu May 23 15:36:42 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Thu, 23 May 2013 18:36:42 +0300
Subject: add blkIoTune support for a specific device at vm creation
In-Reply-To: <1600667990.9465235.1369238126197.JavaMail.root@redhat.com>
References: <51999389.6010705@linux.vnet.ibm.com>
	<1600667990.9465235.1369238126197.JavaMail.root@redhat.com>
Message-ID: <20130523153642.GD20575@redhat.com>

On Wed, May 22, 2013 at 11:55:26AM -0400, Doron Fediuck wrote:
> ----- Original Message -----
> > From: "Mei Liu" <liumbj at linux.vnet.ibm.com>
> > To: arch at ovirt.org
> > Cc: dfediuck at redhat.com, wudxw at linux.vnet.ibm.com
> > Sent: Monday, May 20, 2013 6:07:53 AM
> > Subject: add blkIoTune support for a specific device at vm creation
> > 
> > Hi all,
> > I would like to add blkIoTune support for a specific device at vm creation.
> > 
> > The code parses the 'blkIoTune' descrption for block devices at vm creation
> > time and adds iotune tag accordingly.
> > 
> > e.g.
> > Adding 'blkIoTune':{'read_bytes_sec': 6120000, 'total_iops_sec': 800} for a
> > block device will add the following in dom xml for that device.
> > 
> > <iotune>
> >       <read_bytes_sec>6120000</read_bytes_sec>
> >       <total_iops_sec>800</total_iops_sec>
> > </iotune>
> > 
> > The patch is under review in http://gerrit.ovirt.org/#/c/14636/ .
> > 
> > Does the patch meet the requirement of the engine or the whole
> > architecture? Are the new parameters properly placed?  Any suggestions
> > are welcomed.
> > 
> > TIA.
> > 
> > Best reagrds,
> > Mei Liu (Rose)
> > 
> > 
> 
> Hi Mei Liu,
> Apologies for my late response.
> Is there an engine implementation for it?
> This is important enough to be considered on how it works in a cluster
> on not just on host level. For example, what happens during and after
> live migration?

As far as I know, there's nothing written on the Engine side, yet.

And in my opinion, we can aim low, and have a very minimalistic
implementation, that give a thin GUI for each block device, in where
these two parameters can be edited, and passed to Vdsm on vmCreate,
hotplug, and vmUpdateDevice.

Obviously, such an implementation affects only in the vDisk level; the
io throttling would follow the VM to the destination node, regardless of
other readers/writers on that host. This is suboptimal; it would be
cooler to have a policy that provides relative io priority to different
vDisks/VMs/users. But in my opinion, it can wait for a second phase.

I'm fine with the suggested Engine/Vdsm API (though I'd try to be even
more just-like-libvirt and call it "iotune"). But I'm no Engine expert
to judge - the may wnat to hide it in their specParam map.

I'd love to see a feature page written for this, anyway!


Dan.


From alourie at redhat.com  Tue May 14 13:28:05 2013
From: alourie at redhat.com (Alex Lourie)
Date: Tue, 14 May 2013 13:31:05 +0003
Subject: [ANN] New development environment for ovirt-engine
In-Reply-To: <248944163.1356174.1368528861600.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
	<248944163.1356174.1368528861600.JavaMail.root@redhat.com>
Message-ID: <201305141328.r4EDS6VD014561@int-mx11.intmail.prod.int.phx2.redhat.com>



On Tue, May 14, 2013 at 1:54 PM, Moti Asayag <masayag at redhat.com> wrote:
> 
> 
> ----- Original Message -----
>>  From: "Alon Bar-Lev" <alonbl at redhat.com>
>>  To: "engine-devel" <engine-devel at ovirt.org>
>>  Cc: "Yaniv Bronheim" <ybronhei at redhat.com>, "Moti Asayag" 
>> <masayag at redhat.com>, "Limor Gavish" <lgavish at gmail.com>,
>>  "Sharad Mishra" <snmishra at us.ibm.com>, "Alex Lourie" 
>> <alourie at redhat.com>, "Sandro Bonazzola" <sbonazzo at redhat.com>,
>>  "arch" <arch at ovirt.org>, "Ofer Schreiber" <oschreib at redhat.com>
>>  Sent: Sunday, May 12, 2013 2:52:51 PM
>>  Subject: [ANN] New development environment for ovirt-engine
>>  
>>  Hello all ovirt-engine developers,
>>  
>>  When I first joined the ovirt project, it took me about two weeks 
>> to setup a
>>  development environment, I needed to work on a bug related to 
>> host-deploy so
>>  I needed an environment that could use the ssh, PKI, vdsm-bootstrap 
>> and
>>  communicate with vdsm using SSL, this was virtually impossible to 
>> do so
>>  without tweaking the product in a way that it is so different from
>>  production use, that I cannot guarantee that whatever tested in 
>> development
>>  will actually work in production.
>>  
>>  I peeked at the installation script in a hope that I can create 
>> partial
>>  environment similar to production, but I found that the packaging
>>  implementation makes to much assumption and is very difficult to 
>> adopt. The
>>  fact that I do not use fedora/rhel for my development made it even 
>> worse.
>>  
>>  I had no other option than to create rpms after each of my changes 
>> and test
>>  each in real production like setup.
>>  
>>  It was obvious to me that the manual customization of developers to 
>> achieve
>>  working product will eventually break as product grow and move away 
>> from
>>  being developer friendly to production friendly. For example, 
>> product
>>  defaults cannot be these which serve developers, but these which 
>> serve
>>  production the best, or having a valid PKI setup cannot be optional 
>> any more
>>  as components do need to use it. Same for location of files and
>>  configuration, for example, if we write a pluggable infrastructure 
>> for
>>  branding, we cannot damage the interface just because developers 
>> runs the
>>  product in their own manual customization.
>>  
>>  I took the opportunity handed to me to port the ovirt-engine to 
>> other
>>  distributions in order to provide a development environment that is 
>> similar
>>  to production setup. Together with Sandro Bonazzola and Alex Lourie 
>> we
>>  re-wrote the whole installation of the product which can also be 
>> used to
>>  setup the desired development environment.
>>  
>>  Within this environment the product is set up using the same tools 
>> and
>>  configuration as in production, while the process does not require 
>> special
>>  privileges nor changes the state of the developer machine.
>>  
>>  A complete documentation is available[1], I preferred to use README 
>> within
>>  the source tree as wiki tend to quickly become obsolete, while 
>> documentation
>>  within source tree can be modified by the commit that introduces a 
>> change. I
>>  will redirect to this file from the current wiki once the site will 
>> be up.
>>  
>>  In a nut shell, after installing prerequisites, build and install 
>> the product
>>  using:
>>  
>>  $ make clean install-dev PREFIX=$HOME/ovirt-engine
>>  
>>  This will run maven and create product installation at 
>> $HOME/ovirt-engine
>>  Next, a setup phase is required just like in production, to 
>> initialize
>>  configuration and database:
>>  
>>  $ $HOME/ovirt-engine/bin/engine-setup-2
>>  
>>  You have now fully functional product, including PKI, SSL, 
>> host-deploy,
>>  tools.
>>  No manual database updates are required, no lose of functionality.
>>  
>>  All that is left is to start the engine service:
>>  
>>  $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py 
>> start
>>  
>>  Access to application:
>>     http://localhost:8080
>>     https://localhost:8443
>>  Debugging port is opened at port 8787.
>>  
>>  Farther information exists in the documentation[1].
>>  
>>  There are several inherit benefits of the new environment, the 
>> major one is
>>  the ability to manage several environments in parallel on the same 
>> host. For
>>  example, if we develop two separate features on two branches we can 
>> install
>>  the product into $HOME/ovirt-engine-feature1 and
>>  $HOME/ovirt-engine-feature-2 and have a separate database for each, 
>> if we
>>  modify the ports jboss is listening to we can run two instances of 
>> engine at
>>  the same time!
>>  
>>  We will be happy to work with all developers to assist in porting 
>> into the
>>  new development environment, the simplest is to create a new 
>> database for
>>  this effort. Moti has a sequence of converting the existing 
>> database owned
>>  by postgres to be owned by the engine, Moti, can you please share 
>> that?
>>  
>> 
> Reusing an existing DB schema requires a bit more work since the 
> installation 
> of dev-env advise using database as a user and not a superuser like 
> 'postgres'
> user used to create the database originally. 
> 

We no longer (since 3.1) create the DB in production with user 
postgres. All the DB operations are done with application user (engine 
by default), especially with remote DB installations. The application 
user doesn't have superuser privileges, only the ones required for DB 
creation and removal.

> 
> Therefore if wishes to use user 'engine' as in the instructions, 
> there is a need
> to change the current schema owner and also the ownership of all of 
> its objects.
> 
> The easiest path I found for that purpose is:
> 1. Create a dump of the database using the script in [1].
> 2. Rename the owner in the dump file to the new owner (s/OWNER TO 
> postgres/OWNER TO engine/g).
> 3. Import the dump file to the new DB owned by the engine user using 
> [2] (provide -r flag to
> drop the former db).
> 
> [1] ovirt-engine/backend/manager/dbscripts/backup.sh
> [2] ovirt-engine/backend/manager/dbscripts/restore.sh
> 
>>  We are sure there are missing bits, we will be happy to know these 
>> so we can
>>  improve.
>>  
>>  I am aware that developers (especially java) are conservative, but 
>> I ask you
>>  to give us a chance, so that we make it easy for developers to join 
>> the
>>  project, and to allow us to drop the parallel effort of packaging to
>>  production and fixing the broken development environment.
>>  
>>  A special thanks to developers who took the time to test and 
>> provide feedback
>>  before the merged:
>>  - Yaniv Bronheim
>>  - Moti Asayag
>>  - Limor Gavish
>>  - Sharad Mishra
>>  - Ofer Schreiber
>>  
>>  We are hoping that after migration you will be find this 
>> environment useful
>>  and friendly,
>>  
>>  Sandro Bonazzola,
>>  Alex Lourie,
>>  Alon Bar-Lev.
>>  
>>  [1]
>>  
>> http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
>>  
>> 



From michal.skrivanek at redhat.com  Wed May 22 07:46:43 2013
From: michal.skrivanek at redhat.com (Michal Skrivanek)
Date: Wed, 22 May 2013 09:46:43 +0200
Subject: oVirt on IBM POWER (PPC64) - new feature contributors
In-Reply-To: <50EB20226B72D6419356FC320AB62B871896BB19@SERV070.corp.eldorado.org.br>
References: <50EB20226B72D6419356FC320AB62B871896B600@SERV070.corp.eldorado.org.br>
	<5193A8AE.5000600@redhat.com>
	<50EB20226B72D6419356FC320AB62B871896BB19@SERV070.corp.eldorado.org.br>
Message-ID: <61C18AFB-AF93-48F3-BC90-6AA1B341DF27@redhat.com>


On May 21, 2013, at 17:33 , Leonardo Bianconi <leonardo.bianconi at eldorado.org.br> wrote:

> Hi all,
> 
> We are planning to deliver support for PPC64 in 4 phases. We will manage to deliver a set of patches at the end of each phase.
> 
> Phase 1
> 
> 	 Change oVirt to handle other architectures by encapsulating all the architecture specific code and queries about the capabilities of the hypervisor into a new class called ArchStrategy (based on the Strategy Design Pattern). Every operation involving clusters and hosts will be validated by this new class. Some hard-coded parameters are going to be replaced by queries in the backend in order to accommodate the support for new architectures into the engine.

If you would like to discuss some internals or if anything is unclear please feel free to set up a quick mtg with myself, Omer and Roy.
Sometimes (e.g. in the case of VmInterfaceType as mentioned on feature page) it would be actually beneficial for oVirt on x86 as well to have a greater flexibility directly in the code, without Strategy encapsulation.

> 
> 
> Phase 2
> 
> 	Currently, each host hypervisor capabilities are obtained using hard-coded data structures. These structures will be replaced either by some form of integration with libosinfo or by reading internal configuration files describing these capabilities. It will be handled after Roy's patch.
Roy's osinfo will soon be merged.

> 
> 
> Phase 3
> 
> 	The code for providing the support for IBM POWER systems will be added. The encapsulation done in the previous phase will reduce the effort to include this feature into the engine. The other changes that will be introduced in this phase include:
> 
> 	- Modifications in the frontend to avoid running a VM created on a POWER host in a x86-64 host (and vice-versa), 
> 	- All the dynamically provided capacities of the first phase will be implemented according to the capacities of the QEMU/KVM on POWER
> 	- The POWER processors will be available as an option in the list of processor names (this will imply in significant changes in the backend)
> 
> 
> Phase 4
> 
> 	Adapt secondary features to polish the support for POWER:
> 
> 	- OVF import and export of VMs running in POWER hosts
> 	- Dynamic searches capable of finding hosts, pools, vms and clusters according to their architectures
> 
> 
> Is there any ongoing oVirt architecture refactoring ? (that may conflict with Phase 1, for instance)
no, nothing major going on

> 
> Any comments ?
Looking forward to your patches!:-)

Thanks,
michal

> 
> Regards,
> Vitor (vitor.lima at eldorado.org.br) / Leonardo (leonardo.bianconi at eldorado.org.br)
> 
> 
> -----Original Message-----
> From: Dave Neary [mailto:dneary at redhat.com] 
> Sent: quarta-feira, 15 de maio de 2013 12:25
> To: Leonardo Bianconi
> Cc: arch at ovirt.org; Adam Litke
> Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
> 
> Hi,
> 
> On 05/14/2013 08:05 PM, Leonardo Bianconi wrote:
>> We would like to introduce ourselves: Leonardo Bianconi and Vitor Lima.
> 
> Welcome!
> 
>> We would like to work on the features "Engine support for PPC64" (http://wiki.ovirt.org/Features/Engine_support_for_PPC64) and the "Vdsm for PPC64" (http://wiki.ovirt.org/Features/Vdsm_for_PPC64). This work has already been started by some developers at IBM.
> 
> <snip>
> 
>> About libosinfo:
>> =============
>> 
>> In the previous discussion about this topic (http://lists.ovirt.org/pipermail/arch/2012-November/000976.html), occurred in November 2012, it was suggested that integrating the libosinfo into the engine would be a better way to handle the differences between the architectures that would be supported in the future.
>> 
>> Is this approach still valid? If so, when will it be available? It seems to be a dependency for oVirt "Engine_support_for_PPC64" feature implementation.
> 
> 
> This is great news. I don't know who, specifically, has been working on this issue in IBM - perhaps Adam Litke (CCed) can update you on the progress that has been made.

> 
> Cheers,
> Dave.
> 
> --
> Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch



From iheim at redhat.com  Sat May 25 13:11:53 2013
From: iheim at redhat.com (Itamar Heim)
Date: Sat, 25 May 2013 16:11:53 +0300
Subject: oVirt on IBM POWER (PPC64) - new feature contributors
In-Reply-To: <61C18AFB-AF93-48F3-BC90-6AA1B341DF27@redhat.com>
References: <50EB20226B72D6419356FC320AB62B871896B600@SERV070.corp.eldorado.org.br>
	<5193A8AE.5000600@redhat.com>
	<50EB20226B72D6419356FC320AB62B871896BB19@SERV070.corp.eldorado.org.br>
	<61C18AFB-AF93-48F3-BC90-6AA1B341DF27@redhat.com>
Message-ID: <51A0B899.9030600@redhat.com>

On 05/22/2013 10:46 AM, Michal Skrivanek wrote:
>
> On May 21, 2013, at 17:33 , Leonardo Bianconi <leonardo.bianconi at eldorado.org.br> wrote:
>
>> Hi all,
>>
>> We are planning to deliver support for PPC64 in 4 phases. We will manage to deliver a set of patches at the end of each phase.
>>
>> Phase 1
>>
>> 	 Change oVirt to handle other architectures by encapsulating all the architecture specific code and queries about the capabilities of the hypervisor into a new class called ArchStrategy (based on the Strategy Design Pattern). Every operation involving clusters and hosts will be validated by this new class. Some hard-coded parameters are going to be replaced by queries in the backend in order to accommodate the support for new architectures into the engine.
>
> If you would like to discuss some internals or if anything is unclear please feel free to set up a quick mtg with myself, Omer and Roy.
> Sometimes (e.g. in the case of VmInterfaceType as mentioned on feature page) it would be actually beneficial for oVirt on x86 as well to have a greater flexibility directly in the code, without Strategy encapsulation.
>
>>
>>
>> Phase 2
>>
>> 	Currently, each host hypervisor capabilities are obtained using hard-coded data structures. These structures will be replaced either by some form of integration with libosinfo or by reading internal configuration files describing these capabilities. It will be handled after Roy's patch.
> Roy's osinfo will soon be merged.

link to patches?
does it cover adding arch at cluster level?

>
>>
>>
>> Phase 3
>>
>> 	The code for providing the support for IBM POWER systems will be added. The encapsulation done in the previous phase will reduce the effort to include this feature into the engine. The other changes that will be introduced in this phase include:
>>
>> 	- Modifications in the frontend to avoid running a VM created on a POWER host in a x86-64 host (and vice-versa),
>> 	- All the dynamically provided capacities of the first phase will be implemented according to the capacities of the QEMU/KVM on POWER
>> 	- The POWER processors will be available as an option in the list of processor names (this will imply in significant changes in the backend)
>>
>>
>> Phase 4
>>
>> 	Adapt secondary features to polish the support for POWER:
>>
>> 	- OVF import and export of VMs running in POWER hosts
>> 	- Dynamic searches capable of finding hosts, pools, vms and clusters according to their architectures
>>
>>
>> Is there any ongoing oVirt architecture refactoring ? (that may conflict with Phase 1, for instance)
> no, nothing major going on
>
>>
>> Any comments ?
> Looking forward to your patches!:-)
>
> Thanks,
> michal
>
>>
>> Regards,
>> Vitor (vitor.lima at eldorado.org.br) / Leonardo (leonardo.bianconi at eldorado.org.br)
>>
>>
>> -----Original Message-----
>> From: Dave Neary [mailto:dneary at redhat.com]
>> Sent: quarta-feira, 15 de maio de 2013 12:25
>> To: Leonardo Bianconi
>> Cc: arch at ovirt.org; Adam Litke
>> Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>>
>> Hi,
>>
>> On 05/14/2013 08:05 PM, Leonardo Bianconi wrote:
>>> We would like to introduce ourselves: Leonardo Bianconi and Vitor Lima.
>>
>> Welcome!
>>
>>> We would like to work on the features "Engine support for PPC64" (http://wiki.ovirt.org/Features/Engine_support_for_PPC64) and the "Vdsm for PPC64" (http://wiki.ovirt.org/Features/Vdsm_for_PPC64). This work has already been started by some developers at IBM.
>>
>> <snip>
>>
>>> About libosinfo:
>>> =============
>>>
>>> In the previous discussion about this topic (http://lists.ovirt.org/pipermail/arch/2012-November/000976.html), occurred in November 2012, it was suggested that integrating the libosinfo into the engine would be a better way to handle the differences between the architectures that would be supported in the future.
>>>
>>> Is this approach still valid? If so, when will it be available? It seems to be a dependency for oVirt "Engine_support_for_PPC64" feature implementation.
>>
>>
>> This is great news. I don't know who, specifically, has been working on this issue in IBM - perhaps Adam Litke (CCed) can update you on the progress that has been made.
>
>>
>> Cheers,
>> Dave.
>>
>> --
>> Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com
>> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>



From liumbj at linux.vnet.ibm.com  Sun May 26 09:18:34 2013
From: liumbj at linux.vnet.ibm.com (Mei Liu)
Date: Sun, 26 May 2013 17:18:34 +0800
Subject: add blkIoTune support for a specific device at vm creation
In-Reply-To: <20130523153642.GD20575@redhat.com>
References: <51999389.6010705@linux.vnet.ibm.com>
	<1600667990.9465235.1369238126197.JavaMail.root@redhat.com>
	<20130523153642.GD20575@redhat.com>
Message-ID: <51A1D36A.9060705@linux.vnet.ibm.com>

On 05/23/2013 11:36 PM, Dan Kenigsberg wrote:
> On Wed, May 22, 2013 at 11:55:26AM -0400, Doron Fediuck wrote:
>> ----- Original Message -----
>>> From: "Mei Liu" <liumbj at linux.vnet.ibm.com>
>>> To: arch at ovirt.org
>>> Cc: dfediuck at redhat.com, wudxw at linux.vnet.ibm.com
>>> Sent: Monday, May 20, 2013 6:07:53 AM
>>> Subject: add blkIoTune support for a specific device at vm creation
>>>
>>> Hi all,
>>> I would like to add blkIoTune support for a specific device at vm creation.
>>>
>>> The code parses the 'blkIoTune' descrption for block devices at vm creation
>>> time and adds iotune tag accordingly.
>>>
>>> e.g.
>>> Adding 'blkIoTune':{'read_bytes_sec': 6120000, 'total_iops_sec': 800} for a
>>> block device will add the following in dom xml for that device.
>>>
>>> <iotune>
>>>        <read_bytes_sec>6120000</read_bytes_sec>
>>>        <total_iops_sec>800</total_iops_sec>
>>> </iotune>
>>>
>>> The patch is under review in http://gerrit.ovirt.org/#/c/14636/ .
>>>
>>> Does the patch meet the requirement of the engine or the whole
>>> architecture? Are the new parameters properly placed?  Any suggestions
>>> are welcomed.
>>>
>>> TIA.
>>>
>>> Best reagrds,
>>> Mei Liu (Rose)
>>>
>>>
>> Hi Mei Liu,
>> Apologies for my late response.
>> Is there an engine implementation for it?
>> This is important enough to be considered on how it works in a cluster
>> on not just on host level. For example, what happens during and after
>> live migration?
> As far as I know, there's nothing written on the Engine side, yet.
>
> And in my opinion, we can aim low, and have a very minimalistic
> implementation, that give a thin GUI for each block device, in where
> these two parameters can be edited, and passed to Vdsm on vmCreate,
> hotplug, and vmUpdateDevice.
>
> Obviously, such an implementation affects only in the vDisk level; the
> io throttling would follow the VM to the destination node, regardless of
> other readers/writers on that host. This is suboptimal; it would be
> cooler to have a policy that provides relative io priority to different
> vDisks/VMs/users. But in my opinion, it can wait for a second phase.
>
> I'm fine with the suggested Engine/Vdsm API (though I'd try to be even
> more just-like-libvirt and call it "iotune"). But I'm no Engine expert
> to judge - the may wnat to hide it in their specParam map.
>
> I'd love to see a feature page written for this, anyway!
>
>
> Dan.
>
Thanks Dan and Doron for your comments.

I agree that we can make it two phases. In the first phase, we provide 
the related VDSM API.

For better discussion, I created a draft wiki 
http://www.ovirt.org/SLA_for_storage_resource . We can further discuss 
the SLA based on this wiki.

Best regards,
Mei Liu(Rose)



From emesika at redhat.com  Sun May 26 13:28:41 2013
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 26 May 2013 09:28:41 -0400 (EDT)
Subject: add blkIoTune support for a specific device at vm creation
In-Reply-To: <20130523153642.GD20575@redhat.com>
References: <20130526130006.GJ27100@redhat.com>
Message-ID: <579234313.7519447.1369574921187.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>, "Eli Mesika" <emesika at redhat.com>
> Cc: "Mei Liu" <liumbj at linux.vnet.ibm.com>, arch at ovirt.org
> Sent: Thursday, May 23, 2013 6:36:42 PM
> Subject: Re: add blkIoTune support for a specific device at vm creation
> 
> On Wed, May 22, 2013 at 11:55:26AM -0400, Doron Fediuck wrote:
> > ----- Original Message -----
> > > From: "Mei Liu" <liumbj at linux.vnet.ibm.com>
> > > To: arch at ovirt.org
> > > Cc: dfediuck at redhat.com, wudxw at linux.vnet.ibm.com
> > > Sent: Monday, May 20, 2013 6:07:53 AM
> > > Subject: add blkIoTune support for a specific device at vm creation
> > > 
> > > Hi all,
> > > I would like to add blkIoTune support for a specific device at vm
> > > creation.
> > > 
> > > The code parses the 'blkIoTune' descrption for block devices at vm
> > > creation
> > > time and adds iotune tag accordingly.
> > > 
> > > e.g.
> > > Adding 'blkIoTune':{'read_bytes_sec': 6120000, 'total_iops_sec': 800} for
> > > a
> > > block device will add the following in dom xml for that device.
> > > 
> > > <iotune>
> > >       <read_bytes_sec>6120000</read_bytes_sec>
> > >       <total_iops_sec>800</total_iops_sec>
> > > </iotune>
> > > 
> > > The patch is under review in http://gerrit.ovirt.org/#/c/14636/ .
> > > 
> > > Does the patch meet the requirement of the engine or the whole
> > > architecture? Are the new parameters properly placed?  Any suggestions
> > > are welcomed.
> > > 
> > > TIA.
> > > 
> > > Best reagrds,
> > > Mei Liu (Rose)
> > > 
> > > 
> > 
> > Hi Mei Liu,
> > Apologies for my late response.
> > Is there an engine implementation for it?
> > This is important enough to be considered on how it works in a cluster
> > on not just on host level. For example, what happens during and after
> > live migration?
> 
> As far as I know, there's nothing written on the Engine side, yet.
> 
> And in my opinion, we can aim low, and have a very minimalistic
> implementation, that give a thin GUI for each block device, in where
> these two parameters can be edited, and passed to Vdsm on vmCreate,
> hotplug, and vmUpdateDevice.
> 
> Obviously, such an implementation affects only in the vDisk level; the
> io throttling would follow the VM to the destination node, regardless of
> other readers/writers on that host. This is suboptimal; it would be
> cooler to have a policy that provides relative io priority to different
> vDisks/VMs/users. But in my opinion, it can wait for a second phase.
> 
> I'm fine with the suggested Engine/Vdsm API (though I'd try to be even
> more just-like-libvirt and call it "iotune"). But I'm no Engine expert
> to judge - the may wnat to hide it in their specParam map.

Right, ant reason why not to use the specParams here ???


> 
> I'd love to see a feature page written for this, anyway!
> 
> 
> Dan.
> 


From danken at redhat.com  Sun May 26 15:42:51 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Sun, 26 May 2013 18:42:51 +0300
Subject: add blkIoTune support for a specific device at vm creation
In-Reply-To: <579234313.7519447.1369574921187.JavaMail.root@redhat.com>
References: <20130526130006.GJ27100@redhat.com>
	<579234313.7519447.1369574921187.JavaMail.root@redhat.com>
Message-ID: <20130526154251.GA2422@redhat.com>

On Sun, May 26, 2013 at 09:28:41AM -0400, Eli Mesika wrote:
> 
> 
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Doron Fediuck" <dfediuck at redhat.com>, "Eli Mesika" <emesika at redhat.com>
> > Cc: "Mei Liu" <liumbj at linux.vnet.ibm.com>, arch at ovirt.org
> > Sent: Thursday, May 23, 2013 6:36:42 PM
> > Subject: Re: add blkIoTune support for a specific device at vm creation
> > 
> > On Wed, May 22, 2013 at 11:55:26AM -0400, Doron Fediuck wrote:
> > > ----- Original Message -----
> > > > From: "Mei Liu" <liumbj at linux.vnet.ibm.com>
> > > > To: arch at ovirt.org
> > > > Cc: dfediuck at redhat.com, wudxw at linux.vnet.ibm.com
> > > > Sent: Monday, May 20, 2013 6:07:53 AM
> > > > Subject: add blkIoTune support for a specific device at vm creation
> > > > 
> > > > Hi all,
> > > > I would like to add blkIoTune support for a specific device at vm
> > > > creation.
> > > > 
> > > > The code parses the 'blkIoTune' descrption for block devices at vm
> > > > creation
> > > > time and adds iotune tag accordingly.
> > > > 
> > > > e.g.
> > > > Adding 'blkIoTune':{'read_bytes_sec': 6120000, 'total_iops_sec': 800} for
> > > > a
> > > > block device will add the following in dom xml for that device.
> > > > 
> > > > <iotune>
> > > >       <read_bytes_sec>6120000</read_bytes_sec>
> > > >       <total_iops_sec>800</total_iops_sec>
> > > > </iotune>
> > > > 
> > > > The patch is under review in http://gerrit.ovirt.org/#/c/14636/ .
> > > > 
> > > > Does the patch meet the requirement of the engine or the whole
> > > > architecture? Are the new parameters properly placed?  Any suggestions
> > > > are welcomed.
> > > > 
> > > > TIA.
> > > > 
> > > > Best reagrds,
> > > > Mei Liu (Rose)
> > > > 
> > > > 
> > > 
> > > Hi Mei Liu,
> > > Apologies for my late response.
> > > Is there an engine implementation for it?
> > > This is important enough to be considered on how it works in a cluster
> > > on not just on host level. For example, what happens during and after
> > > live migration?
> > 
> > As far as I know, there's nothing written on the Engine side, yet.
> > 
> > And in my opinion, we can aim low, and have a very minimalistic
> > implementation, that give a thin GUI for each block device, in where
> > these two parameters can be edited, and passed to Vdsm on vmCreate,
> > hotplug, and vmUpdateDevice.
> > 
> > Obviously, such an implementation affects only in the vDisk level; the
> > io throttling would follow the VM to the destination node, regardless of
> > other readers/writers on that host. This is suboptimal; it would be
> > cooler to have a policy that provides relative io priority to different
> > vDisks/VMs/users. But in my opinion, it can wait for a second phase.
> > 
> > I'm fine with the suggested Engine/Vdsm API (though I'd try to be even
> > more just-like-libvirt and call it "iotune"). But I'm no Engine expert
> > to judge - the may wnat to hide it in their specParam map.
> 
> Right, ant reason why not to use the specParams here ???

Eli, would you remind me why we need the additional level of indirection
introduced by specParams? I suspect that just like me, Mei Liu does not
know the pros and cons.

Dan.


From emesika at redhat.com  Sun May 26 18:33:10 2013
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 26 May 2013 14:33:10 -0400 (EDT)
Subject: add blkIoTune support for a specific device at vm creation
In-Reply-To: <20130526154251.GA2422@redhat.com>
References: <20130526130006.GJ27100@redhat.com>
	<579234313.7519447.1369574921187.JavaMail.root@redhat.com>
	<20130526154251.GA2422@redhat.com>
Message-ID: <90106088.7537692.1369593190810.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Mei Liu" <liumbj at linux.vnet.ibm.com>, arch at ovirt.org
> Sent: Sunday, May 26, 2013 6:42:51 PM
> Subject: Re: add blkIoTune support for a specific device at vm creation
> 
> On Sun, May 26, 2013 at 09:28:41AM -0400, Eli Mesika wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > To: "Doron Fediuck" <dfediuck at redhat.com>, "Eli Mesika"
> > > <emesika at redhat.com>
> > > Cc: "Mei Liu" <liumbj at linux.vnet.ibm.com>, arch at ovirt.org
> > > Sent: Thursday, May 23, 2013 6:36:42 PM
> > > Subject: Re: add blkIoTune support for a specific device at vm creation
> > > 
> > > On Wed, May 22, 2013 at 11:55:26AM -0400, Doron Fediuck wrote:
> > > > ----- Original Message -----
> > > > > From: "Mei Liu" <liumbj at linux.vnet.ibm.com>
> > > > > To: arch at ovirt.org
> > > > > Cc: dfediuck at redhat.com, wudxw at linux.vnet.ibm.com
> > > > > Sent: Monday, May 20, 2013 6:07:53 AM
> > > > > Subject: add blkIoTune support for a specific device at vm creation
> > > > > 
> > > > > Hi all,
> > > > > I would like to add blkIoTune support for a specific device at vm
> > > > > creation.
> > > > > 
> > > > > The code parses the 'blkIoTune' descrption for block devices at vm
> > > > > creation
> > > > > time and adds iotune tag accordingly.
> > > > > 
> > > > > e.g.
> > > > > Adding 'blkIoTune':{'read_bytes_sec': 6120000, 'total_iops_sec': 800}
> > > > > for
> > > > > a
> > > > > block device will add the following in dom xml for that device.
> > > > > 
> > > > > <iotune>
> > > > >       <read_bytes_sec>6120000</read_bytes_sec>
> > > > >       <total_iops_sec>800</total_iops_sec>
> > > > > </iotune>
> > > > > 
> > > > > The patch is under review in http://gerrit.ovirt.org/#/c/14636/ .
> > > > > 
> > > > > Does the patch meet the requirement of the engine or the whole
> > > > > architecture? Are the new parameters properly placed?  Any
> > > > > suggestions
> > > > > are welcomed.
> > > > > 
> > > > > TIA.
> > > > > 
> > > > > Best reagrds,
> > > > > Mei Liu (Rose)
> > > > > 
> > > > > 
> > > > 
> > > > Hi Mei Liu,
> > > > Apologies for my late response.
> > > > Is there an engine implementation for it?
> > > > This is important enough to be considered on how it works in a cluster
> > > > on not just on host level. For example, what happens during and after
> > > > live migration?
> > > 
> > > As far as I know, there's nothing written on the Engine side, yet.
> > > 
> > > And in my opinion, we can aim low, and have a very minimalistic
> > > implementation, that give a thin GUI for each block device, in where
> > > these two parameters can be edited, and passed to Vdsm on vmCreate,
> > > hotplug, and vmUpdateDevice.
> > > 
> > > Obviously, such an implementation affects only in the vDisk level; the
> > > io throttling would follow the VM to the destination node, regardless of
> > > other readers/writers on that host. This is suboptimal; it would be
> > > cooler to have a policy that provides relative io priority to different
> > > vDisks/VMs/users. But in my opinion, it can wait for a second phase.
> > > 
> > > I'm fine with the suggested Engine/Vdsm API (though I'd try to be even
> > > more just-like-libvirt and call it "iotune"). But I'm no Engine expert
> > > to judge - the may wnat to hide it in their specParam map.
> > 
> > Right, ant reason why not to use the specParams here ???
> 
> Eli, would you remind me why we need the additional level of indirection
> introduced by specParams? I suspect that just like me, Mei Liu does not
> know the pros and cons.

specparams - Any device specific parameters (for example memory allocation per monitor in video device)

So , in general , it was defined in order to add any special device parameters (saved and managed as JSON)

> 
> Dan.
> 


From amuller at redhat.com  Mon May 27 07:11:55 2013
From: amuller at redhat.com (Assaf Muller)
Date: Mon, 27 May 2013 03:11:55 -0400 (EDT)
Subject: Multiple Gateways 3.3 Feature
In-Reply-To: <1666592006.13063994.1369637963582.JavaMail.root@redhat.com>
Message-ID: <1038209955.13068617.1369638715648.JavaMail.root@redhat.com>

Hi all, 

The multiple gateways feature is planned for 3.3. 

http://www.ovirt.org/Features/Multiple_Gateways 

The feature page explains the need for the feature as well as the proposed solution very verbosely. 

In short: Multiple clients setup a host that is connected to two networks: ovirtmgmt, and a display network. Users then opened up a spice client from outside of the host's network to a VM residing in the host. 
The traffic reached the host, but because the host's default gateway is in the ovirtmgmt network, return traffic came back from the wrong interface. The clients opened tickets and eventually setup 
manual solutions using source routing and multiple routing tables. The multiple gateways feature will automate that process. 

I'd love any feedback, thanks! 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20130527/5575813e/attachment.html>

From mpastern at redhat.com  Mon May 27 07:55:13 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 27 May 2013 10:55:13 +0300
Subject: Custom properties on vnic
In-Reply-To: <1863722697.12848012.1369583362021.JavaMail.root@redhat.com>
References: <1863722697.12848012.1369583362021.JavaMail.root@redhat.com>
Message-ID: <51A31161.9020505@redhat.com>

On 05/26/2013 06:49 PM, Alona Kaplan wrote:
> Hi Michael,
> 
> In Device custom properties feature we are adding custom properties to a vnic.
> 
> It will work in the same way custom properties of vm work.
> When getting the vnic it will be displayed in the following way-
> <custom_properties>
>    <custom_property name="prop_name" value="prop_value"/>
> </custom_properties>
> When adding/updating a vnic the custom properties will be parsed to a string and set on vmStatic.
> 
> http://www.ovirt.org/Features/Device_Custom_Properties#REST
> 
> The feature page was sent to arch at ovirt long time ago, but I didn't see your respond.
> 
> Does the proposed rest design for the feature have ack from your side?

yes it does.

> 
> Thanks,
> Alona.
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Mon May 27 11:18:48 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 27 May 2013 14:18:48 +0300
Subject: Qos feature
In-Reply-To: <2041139267.3543084.1369294470496.JavaMail.root@redhat.com>
References: <2041139267.3543084.1369294470496.JavaMail.root@redhat.com>
Message-ID: <51A34118.8060204@redhat.com>

Hi Ofri,

On 05/23/2013 10:34 AM, Ofri Masad wrote:
> Hi Michael,
> 
> I've drafted the Network QoS feature page. www.ovirt.org/Features/Design/Network_QoS
> I'll appreciate it if you could go over it and see if you have comments or anything else to add to the API section.
> 
> Thanks,
> Ofri
> 

i have few questions/comments regarding api/general design:

1) incoming and outgoing traffic can be shaped independently, will we support
   granularity of enabling|disabling qos on inbound vs.outbound traffic?,
   then i'd suggest modelling QOS in api like this:

<qos>
  <inbound enabled="true|false">
    <average>xxx</average>
    <peak>yyy</peak>
    <burst>zzz</burst>
    <floor>qqq</floor>
  </inbound>
  <outbound enabled="true|false">
    <average>xxx</average>
    <peak>yyy</peak>
    <burst>zzz</burst>
  </outbound>
</qos>


2) at design page, i didn't saw you mentioning permission model for the QOS,
   who should be able seeing it/manipulating it (note, that in case of user
   that should not be seeing it, in api you shouldn't even show the state of the
   qos e.g active or not, maybe not even worth mentioning <qos> at all)


3) what about exposing policies?, like making admin being able to apply same policy
   on a different devices, rather than doing it manually per device.

> Change the Virtual Machine > Network Interfaces to support QoS properties Example of an XML representation of a network interface
>
> <nic id="7a3cff5e-3cc4-47c2-8388-9adf16341f5e"  ref="/api/vms/cdc0b102-fbfe-444a-b9cb-57d2af94f401/nics/7a3cff5e-3cc4-47c2-8388-9adf16341f5e">
>      <link rel="statistics" href="/api/vms/082c794b-771f-452f-83c9-b2b5a19c0399/nics/7a3cff5e-3cc4-47c2-8388-9adf16341f5e/statistics"/>
>      <name>nic1</name>
>      <interface>virtio</interface>
>      <mac address="00:1a:4a:16:84:07"/>
>      <network id="00000000-0000-0000-0000-000000000009" href="/api/networks/00000000-0000-0000-0000-000000000009"/>
>      <vm id="cdc0b102-fbfe-444a-b9cb-57d2af94f401" href="/api/vms/cdc0b102-fbfe-444a-b9cb-57d2af94f401"/>

- 'bandwidth' is not clear enough in my view, i think we should just use 'qos'

>      <bandwidth>

- we should be having <enabled>true|false</enabled> element here/peer traffic-dist?

>        <inbound average='1000' peak='5000' floor='200' burst='1024'/>
>        <outbound average='128' peak='256' burst='256'/>
>      </bandwidth>
> </nic>
>
>
> An API user modifies a network interface with a PUT request
>
> <nic>
>       <name>nic2</name>
>      <network id="00000000-0000-0000-0000-000000000010"/>
>      <type>e1000</type>
>      <bandwidth>
>        <inbound average='1000' peak='5000' floor='200' burst='1024'/>
>        <outbound average='128' peak='256' burst='256'/>
>      </bandwidth>
> </nic>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From lpeer at redhat.com  Mon May 27 11:45:26 2013
From: lpeer at redhat.com (Livnat Peer)
Date: Mon, 27 May 2013 14:45:26 +0300
Subject: Qos feature
In-Reply-To: <51A34118.8060204@redhat.com>
References: <2041139267.3543084.1369294470496.JavaMail.root@redhat.com>
	<51A34118.8060204@redhat.com>
Message-ID: <51A34756.9050902@redhat.com>

On 05/27/2013 02:18 PM, Michael Pasternak wrote:
> Hi Ofri,
> 
> On 05/23/2013 10:34 AM, Ofri Masad wrote:
>> Hi Michael,
>>
>> I've drafted the Network QoS feature page. www.ovirt.org/Features/Design/Network_QoS
>> I'll appreciate it if you could go over it and see if you have comments or anything else to add to the API section.
>>
>> Thanks,
>> Ofri
>>
> 
> i have few questions/comments regarding api/general design:
> 
> 1) incoming and outgoing traffic can be shaped independently, will we support
>    granularity of enabling|disabling qos on inbound vs.outbound traffic?,
>    then i'd suggest modelling QOS in api like this:
> 
> <qos>
>   <inbound enabled="true|false">
>     <average>xxx</average>
>     <peak>yyy</peak>
>     <burst>zzz</burst>
>     <floor>qqq</floor>
>   </inbound>
>   <outbound enabled="true|false">
>     <average>xxx</average>
>     <peak>yyy</peak>
>     <burst>zzz</burst>
>   </outbound>
> </qos>


Note that the above requires to support a mode of inbound (or outbound)
values configured while not enabled, it also requires a change in the UI.
I see how the above suggestion can be useful to users.

> 
> 
> 2) at design page, i didn't saw you mentioning permission model for the QOS,
>    who should be able seeing it/manipulating it (note, that in case of user
>    that should not be seeing it, in api you shouldn't even show the state of the
>    qos e.g active or not, maybe not even worth mentioning <qos> at all)
> 

That's a good point.
Also note that the above suggests different UI dialogs in the user
portal and the admin portal for adding vnic.


> 
> 3) what about exposing policies?, like making admin being able to apply same policy
>    on a different devices, rather than doing it manually per device.

I suggest to support having default configuration on the Network entity,
all Vnics connected to the network inherit the configuration from the
Network.
If qos is configured both on the network and on the VNIC the VNIC
configuration holds.

> 
>> Change the Virtual Machine > Network Interfaces to support QoS properties Example of an XML representation of a network interface
>>
>> <nic id="7a3cff5e-3cc4-47c2-8388-9adf16341f5e"  ref="/api/vms/cdc0b102-fbfe-444a-b9cb-57d2af94f401/nics/7a3cff5e-3cc4-47c2-8388-9adf16341f5e">
>>      <link rel="statistics" href="/api/vms/082c794b-771f-452f-83c9-b2b5a19c0399/nics/7a3cff5e-3cc4-47c2-8388-9adf16341f5e/statistics"/>
>>      <name>nic1</name>
>>      <interface>virtio</interface>
>>      <mac address="00:1a:4a:16:84:07"/>
>>      <network id="00000000-0000-0000-0000-000000000009" href="/api/networks/00000000-0000-0000-0000-000000000009"/>
>>      <vm id="cdc0b102-fbfe-444a-b9cb-57d2af94f401" href="/api/vms/cdc0b102-fbfe-444a-b9cb-57d2af94f401"/>
> 
> - 'bandwidth' is not clear enough in my view, i think we should just use 'qos'
> 
>>      <bandwidth>
> 
> - we should be having <enabled>true|false</enabled> element here/peer traffic-dist?
> 
>>        <inbound average='1000' peak='5000' floor='200' burst='1024'/>
>>        <outbound average='128' peak='256' burst='256'/>
>>      </bandwidth>
>> </nic>
>>
>>
>> An API user modifies a network interface with a PUT request
>>
>> <nic>
>>       <name>nic2</name>
>>      <network id="00000000-0000-0000-0000-000000000010"/>
>>      <type>e1000</type>
>>      <bandwidth>
>>        <inbound average='1000' peak='5000' floor='200' burst='1024'/>
>>        <outbound average='128' peak='256' burst='256'/>
>>      </bandwidth>
>> </nic>
> 
> 



From mpastern at redhat.com  Mon May 27 12:32:37 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 27 May 2013 15:32:37 +0300
Subject: Qos feature
In-Reply-To: <51A34756.9050902@redhat.com>
References: <2041139267.3543084.1369294470496.JavaMail.root@redhat.com>
	<51A34118.8060204@redhat.com> <51A34756.9050902@redhat.com>
Message-ID: <51A35265.2060306@redhat.com>


Hi Livnat,

On 05/27/2013 02:45 PM, Livnat Peer wrote:
> On 05/27/2013 02:18 PM, Michael Pasternak wrote:
>> Hi Ofri,
>>
>> On 05/23/2013 10:34 AM, Ofri Masad wrote:
>>> Hi Michael,
>>>
>>> I've drafted the Network QoS feature page. www.ovirt.org/Features/Design/Network_QoS
>>> I'll appreciate it if you could go over it and see if you have comments or anything else to add to the API section.
>>>
>>> Thanks,
>>> Ofri
>>>
>>
>> i have few questions/comments regarding api/general design:
>>
>> 1) incoming and outgoing traffic can be shaped independently, will we support
>>    granularity of enabling|disabling qos on inbound vs.outbound traffic?,
>>    then i'd suggest modelling QOS in api like this:
>>
>> <qos>
>>   <inbound enabled="true|false">
>>     <average>xxx</average>
>>     <peak>yyy</peak>
>>     <burst>zzz</burst>
>>     <floor>qqq</floor>
>>   </inbound>
>>   <outbound enabled="true|false">
>>     <average>xxx</average>
>>     <peak>yyy</peak>
>>     <burst>zzz</burst>
>>   </outbound>
>> </qos>
> 
> 
> Note that the above requires to support a mode of inbound (or outbound)
> values configured while not enabled, 

no it doesn't, all attributes can have NULLs when disabled.

> it also requires a change in the UI.

api & UI doesn't have to be the same, but i think suggested above makes sense
for UI as well.

> I see how the above suggestion can be useful to users.

it can be useful for us on a first place, cause it's easily extendible,
i.e it much easier to extend expended type with new elements rather
than inline adding attributes <outbound average='' peak='' burst='' ...../>
and in addition we can easily add system element's (if not now then in future)
such as <inbound enabled="true|false" policy='xxx' ...>

> 
>>
>>
>> 2) at design page, i didn't saw you mentioning permission model for the QOS,
>>    who should be able seeing it/manipulating it (note, that in case of user
>>    that should not be seeing it, in api you shouldn't even show the state of the
>>    qos e.g active or not, maybe not even worth mentioning <qos> at all)
>>
> 
> That's a good point.
> Also note that the above suggests different UI dialogs in the user
> portal and the admin portal for adding vnic.
> 
> 
>>
>> 3) what about exposing policies?, like making admin being able to apply same policy
>>    on a different devices, rather than doing it manually per device.
> 
> I suggest to support having default configuration on the Network entity,
> all Vnics connected to the network inherit the configuration from the
> Network.
> If qos is configured both on the network and on the VNIC the VNIC
> configuration holds.

usually QoS providers avoid having defaults cause when QoS turned on by
mistake it's simply applies these values silently, while if it has NULLs,
you cannot turn it on by mistake (i.e forcing users to set rules preferred
over default configurations)

> 
>>
>>> Change the Virtual Machine > Network Interfaces to support QoS properties Example of an XML representation of a network interface
>>>
>>> <nic id="7a3cff5e-3cc4-47c2-8388-9adf16341f5e"  ref="/api/vms/cdc0b102-fbfe-444a-b9cb-57d2af94f401/nics/7a3cff5e-3cc4-47c2-8388-9adf16341f5e">
>>>      <link rel="statistics" href="/api/vms/082c794b-771f-452f-83c9-b2b5a19c0399/nics/7a3cff5e-3cc4-47c2-8388-9adf16341f5e/statistics"/>
>>>      <name>nic1</name>
>>>      <interface>virtio</interface>
>>>      <mac address="00:1a:4a:16:84:07"/>
>>>      <network id="00000000-0000-0000-0000-000000000009" href="/api/networks/00000000-0000-0000-0000-000000000009"/>
>>>      <vm id="cdc0b102-fbfe-444a-b9cb-57d2af94f401" href="/api/vms/cdc0b102-fbfe-444a-b9cb-57d2af94f401"/>
>>
>> - 'bandwidth' is not clear enough in my view, i think we should just use 'qos'
>>
>>>      <bandwidth>
>>
>> - we should be having <enabled>true|false</enabled> element here/peer traffic-dist?
>>
>>>        <inbound average='1000' peak='5000' floor='200' burst='1024'/>
>>>        <outbound average='128' peak='256' burst='256'/>
>>>      </bandwidth>
>>> </nic>
>>>
>>>
>>> An API user modifies a network interface with a PUT request
>>>
>>> <nic>
>>>       <name>nic2</name>
>>>      <network id="00000000-0000-0000-0000-000000000010"/>
>>>      <type>e1000</type>
>>>      <bandwidth>
>>>        <inbound average='1000' peak='5000' floor='200' burst='1024'/>
>>>        <outbound average='128' peak='256' burst='256'/>
>>>      </bandwidth>
>>> </nic>
>>
>>
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From dfediuck at redhat.com  Mon May 27 16:13:39 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Mon, 27 May 2013 12:13:39 -0400 (EDT)
Subject: Qos feature
In-Reply-To: <51A35265.2060306@redhat.com>
References: <2041139267.3543084.1369294470496.JavaMail.root@redhat.com>
	<51A34118.8060204@redhat.com> <51A34756.9050902@redhat.com>
	<51A35265.2060306@redhat.com>
Message-ID: <1611981565.12724418.1369671219186.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Livnat Peer" <lpeer at redhat.com>
> Cc: "Ofri Masad" <omasad at redhat.com>, arch at ovirt.org
> Sent: Monday, May 27, 2013 3:32:37 PM
> Subject: Re: Qos feature
> 
> 
> Hi Livnat,
> 
> On 05/27/2013 02:45 PM, Livnat Peer wrote:
> > On 05/27/2013 02:18 PM, Michael Pasternak wrote:
> >> Hi Ofri,
> >>
> >> On 05/23/2013 10:34 AM, Ofri Masad wrote:
> >>> Hi Michael,
> >>>
> >>> I've drafted the Network QoS feature page.
> >>> www.ovirt.org/Features/Design/Network_QoS
> >>> I'll appreciate it if you could go over it and see if you have comments
> >>> or anything else to add to the API section.
> >>>
> >>> Thanks,
> >>> Ofri
> >>>
> >>
> >> i have few questions/comments regarding api/general design:
> >>
> >> 1) incoming and outgoing traffic can be shaped independently, will we
> >> support
> >>    granularity of enabling|disabling qos on inbound vs.outbound traffic?,
> >>    then i'd suggest modelling QOS in api like this:
> >>
> >> <qos>
> >>   <inbound enabled="true|false">
> >>     <average>xxx</average>
> >>     <peak>yyy</peak>
> >>     <burst>zzz</burst>
> >>     <floor>qqq</floor>
> >>   </inbound>
> >>   <outbound enabled="true|false">
> >>     <average>xxx</average>
> >>     <peak>yyy</peak>
> >>     <burst>zzz</burst>
> >>   </outbound>
> >> </qos>
> > 
> > 
> > Note that the above requires to support a mode of inbound (or outbound)
> > values configured while not enabled,
> 
> no it doesn't, all attributes can have NULLs when disabled.
> 

I'm ok with wither.
Just note that the hierarchy is deeper, and the design will be updated.
Basically we have:
Policy
  -> QoS
    -> Network
       -> In
       -> Out

The reason for it is that going forward Policy will include CPU QoS, memory
QoS, Storage QoS and Quota.
Most humans will want to kill us if they need to fill in all of it every
time. So policies is something which we can manage and people can actually
use. If someone needs something specific he can clone a policy and make the
relevant changes.
In this context what we need is for a network to reference a policy. The
vNIC will get the policy reference by default, and can override it by
specifying a different policy.

> > it also requires a change in the UI.
> 
> api & UI doesn't have to be the same, but i think suggested above makes sense
> for UI as well.
> 
> > I see how the above suggestion can be useful to users.
> 
> it can be useful for us on a first place, cause it's easily extendible,
> i.e it much easier to extend expended type with new elements rather
> than inline adding attributes <outbound average='' peak='' burst='' ...../>
> and in addition we can easily add system element's (if not now then in
> future)
> such as <inbound enabled="true|false" policy='xxx' ...>
> 
> > 
> >>
> >>
> >> 2) at design page, i didn't saw you mentioning permission model for the
> >> QOS,
> >>    who should be able seeing it/manipulating it (note, that in case of
> >>    user
> >>    that should not be seeing it, in api you shouldn't even show the state
> >>    of the
> >>    qos e.g active or not, maybe not even worth mentioning <qos> at all)
> >>
> > 
> > That's a good point.
> > Also note that the above suggests different UI dialogs in the user
> > portal and the admin portal for adding vnic.
> > 

The assumption is that users with permissions to modify a vNIC can
get/set the information in REST.

> > 
> >>
> >> 3) what about exposing policies?, like making admin being able to apply
> >> same policy
> >>    on a different devices, rather than doing it manually per device.
> > 
> > I suggest to support having default configuration on the Network entity,
> > all Vnics connected to the network inherit the configuration from the
> > Network.
> > If qos is configured both on the network and on the VNIC the VNIC
> > configuration holds.
> 
> usually QoS providers avoid having defaults cause when QoS turned on by
> mistake it's simply applies these values silently, while if it has NULLs,
> you cannot turn it on by mistake (i.e forcing users to set rules preferred
> over default configurations)
> 
See my response above on policies.
As for setting it, well, we prefer to start with a baseline which can be later
changed. This is better than starting in 'unlimited' mode we currently have.
In this way potential bursts are still in control and if more resources needed
than a matching policy should be assigned.

> > 
> >>
> >>> Change the Virtual Machine > Network Interfaces to support QoS properties
> >>> Example of an XML representation of a network interface
> >>>
> >>> <nic id="7a3cff5e-3cc4-47c2-8388-9adf16341f5e"
> >>> ref="/api/vms/cdc0b102-fbfe-444a-b9cb-57d2af94f401/nics/7a3cff5e-3cc4-47c2-8388-9adf16341f5e">
> >>>      <link rel="statistics"
> >>>      href="/api/vms/082c794b-771f-452f-83c9-b2b5a19c0399/nics/7a3cff5e-3cc4-47c2-8388-9adf16341f5e/statistics"/>
> >>>      <name>nic1</name>
> >>>      <interface>virtio</interface>
> >>>      <mac address="00:1a:4a:16:84:07"/>
> >>>      <network id="00000000-0000-0000-0000-000000000009"
> >>>      href="/api/networks/00000000-0000-0000-0000-000000000009"/>
> >>>      <vm id="cdc0b102-fbfe-444a-b9cb-57d2af94f401"
> >>>      href="/api/vms/cdc0b102-fbfe-444a-b9cb-57d2af94f401"/>
> >>
> >> - 'bandwidth' is not clear enough in my view, i think we should just use
> >> 'qos'
> >>
> >>>      <bandwidth>
> >>
> >> - we should be having <enabled>true|false</enabled> element here/peer
> >> traffic-dist?
> >>
> >>>        <inbound average='1000' peak='5000' floor='200' burst='1024'/>
> >>>        <outbound average='128' peak='256' burst='256'/>
> >>>      </bandwidth>
> >>> </nic>
> >>>
> >>>
> >>> An API user modifies a network interface with a PUT request
> >>>
> >>> <nic>
> >>>       <name>nic2</name>
> >>>      <network id="00000000-0000-0000-0000-000000000010"/>
> >>>      <type>e1000</type>
> >>>      <bandwidth>
> >>>        <inbound average='1000' peak='5000' floor='200' burst='1024'/>
> >>>        <outbound average='128' peak='256' burst='256'/>
> >>>      </bandwidth>
> >>> </nic>
> >>
> >>
> > 
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From lpeer at redhat.com  Mon May 27 16:55:27 2013
From: lpeer at redhat.com (Livnat Peer)
Date: Mon, 27 May 2013 19:55:27 +0300
Subject: Qos feature
In-Reply-To: <51A35265.2060306@redhat.com>
References: <2041139267.3543084.1369294470496.JavaMail.root@redhat.com>
	<51A34118.8060204@redhat.com> <51A34756.9050902@redhat.com>
	<51A35265.2060306@redhat.com>
Message-ID: <51A38FFF.8060705@redhat.com>

On 05/27/2013 03:32 PM, Michael Pasternak wrote:
> 
> Hi Livnat,
> 
> On 05/27/2013 02:45 PM, Livnat Peer wrote:
>> On 05/27/2013 02:18 PM, Michael Pasternak wrote:
>>> Hi Ofri,
>>>
>>> On 05/23/2013 10:34 AM, Ofri Masad wrote:
>>>> Hi Michael,
>>>>
>>>> I've drafted the Network QoS feature page. www.ovirt.org/Features/Design/Network_QoS
>>>> I'll appreciate it if you could go over it and see if you have comments or anything else to add to the API section.
>>>>
>>>> Thanks,
>>>> Ofri
>>>>
>>>
>>> i have few questions/comments regarding api/general design:
>>>
>>> 1) incoming and outgoing traffic can be shaped independently, will we support
>>>    granularity of enabling|disabling qos on inbound vs.outbound traffic?,
>>>    then i'd suggest modelling QOS in api like this:
>>>
>>> <qos>
>>>   <inbound enabled="true|false">
>>>     <average>xxx</average>
>>>     <peak>yyy</peak>
>>>     <burst>zzz</burst>
>>>     <floor>qqq</floor>
>>>   </inbound>
>>>   <outbound enabled="true|false">
>>>     <average>xxx</average>
>>>     <peak>yyy</peak>
>>>     <burst>zzz</burst>
>>>   </outbound>
>>> </qos>
>>
>>
>> Note that the above requires to support a mode of inbound (or outbound)
>> values configured while not enabled, 
> 
> no it doesn't, all attributes can have NULLs when disabled.
> 

Why disable+null values is better than just omitting the
inbound/outbound elements?

I liked the disable/enable idea...

>> it also requires a change in the UI.
> 
> api & UI doesn't have to be the same, but i think suggested above makes sense
> for UI as well.
> 
of course, I agree, they don't have to be the same. In this case I think
it makes sense.

>> I see how the above suggestion can be useful to users.
> 
> it can be useful for us on a first place, cause it's easily extendible,
> i.e it much easier to extend expended type with new elements rather
> than inline adding attributes <outbound average='' peak='' burst='' ...../>
> and in addition we can easily add system element's (if not now then in future)
> such as <inbound enabled="true|false" policy='xxx' ...>
> 
>>
>>>
>>>
>>> 2) at design page, i didn't saw you mentioning permission model for the QOS,
>>>    who should be able seeing it/manipulating it (note, that in case of user
>>>    that should not be seeing it, in api you shouldn't even show the state of the
>>>    qos e.g active or not, maybe not even worth mentioning <qos> at all)
>>>
>>
>> That's a good point.
>> Also note that the above suggests different UI dialogs in the user
>> portal and the admin portal for adding vnic.
>>
>>
>>>
>>> 3) what about exposing policies?, like making admin being able to apply same policy
>>>    on a different devices, rather than doing it manually per device.
>>
>> I suggest to support having default configuration on the Network entity,
>> all Vnics connected to the network inherit the configuration from the
>> Network.
>> If qos is configured both on the network and on the VNIC the VNIC
>> configuration holds.
> 
> usually QoS providers avoid having defaults cause when QoS turned on by
> mistake it's simply applies these values silently, while if it has NULLs,
> you cannot turn it on by mistake (i.e forcing users to set rules preferred
> over default configurations)
> 

I think the idea wasn't clear enough, a more detailed explanation -

A user can configure the inbound/outbound values on the network entity.
This configuration would apply to all VNICs using this network.
That approach would help the administrator to configure, in a very
simple way, a policy that prevents one VM from taking too much of the
network bandwidth.



>>
>>>
>>>> Change the Virtual Machine > Network Interfaces to support QoS properties Example of an XML representation of a network interface
>>>>
>>>> <nic id="7a3cff5e-3cc4-47c2-8388-9adf16341f5e"  ref="/api/vms/cdc0b102-fbfe-444a-b9cb-57d2af94f401/nics/7a3cff5e-3cc4-47c2-8388-9adf16341f5e">
>>>>      <link rel="statistics" href="/api/vms/082c794b-771f-452f-83c9-b2b5a19c0399/nics/7a3cff5e-3cc4-47c2-8388-9adf16341f5e/statistics"/>
>>>>      <name>nic1</name>
>>>>      <interface>virtio</interface>
>>>>      <mac address="00:1a:4a:16:84:07"/>
>>>>      <network id="00000000-0000-0000-0000-000000000009" href="/api/networks/00000000-0000-0000-0000-000000000009"/>
>>>>      <vm id="cdc0b102-fbfe-444a-b9cb-57d2af94f401" href="/api/vms/cdc0b102-fbfe-444a-b9cb-57d2af94f401"/>
>>>
>>> - 'bandwidth' is not clear enough in my view, i think we should just use 'qos'
>>>
>>>>      <bandwidth>
>>>
>>> - we should be having <enabled>true|false</enabled> element here/peer traffic-dist?
>>>
>>>>        <inbound average='1000' peak='5000' floor='200' burst='1024'/>
>>>>        <outbound average='128' peak='256' burst='256'/>
>>>>      </bandwidth>
>>>> </nic>
>>>>
>>>>
>>>> An API user modifies a network interface with a PUT request
>>>>
>>>> <nic>
>>>>       <name>nic2</name>
>>>>      <network id="00000000-0000-0000-0000-000000000010"/>
>>>>      <type>e1000</type>
>>>>      <bandwidth>
>>>>        <inbound average='1000' peak='5000' floor='200' burst='1024'/>
>>>>        <outbound average='128' peak='256' burst='256'/>
>>>>      </bandwidth>
>>>> </nic>
>>>
>>>
>>
> 
> 



From lpeer at redhat.com  Mon May 27 18:06:39 2013
From: lpeer at redhat.com (Livnat Peer)
Date: Mon, 27 May 2013 21:06:39 +0300
Subject: Qos feature
In-Reply-To: <1611981565.12724418.1369671219186.JavaMail.root@redhat.com>
References: <2041139267.3543084.1369294470496.JavaMail.root@redhat.com>
	<51A34118.8060204@redhat.com> <51A34756.9050902@redhat.com>
	<51A35265.2060306@redhat.com>
	<1611981565.12724418.1369671219186.JavaMail.root@redhat.com>
Message-ID: <51A3A0AF.3080109@redhat.com>

On 05/27/2013 07:13 PM, Doron Fediuck wrote:
> 
> 
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "Livnat Peer" <lpeer at redhat.com>
>> Cc: "Ofri Masad" <omasad at redhat.com>, arch at ovirt.org
>> Sent: Monday, May 27, 2013 3:32:37 PM
>> Subject: Re: Qos feature
>>
>>
>> Hi Livnat,
>>
>> On 05/27/2013 02:45 PM, Livnat Peer wrote:
>>> On 05/27/2013 02:18 PM, Michael Pasternak wrote:
>>>> Hi Ofri,
>>>>
>>>> On 05/23/2013 10:34 AM, Ofri Masad wrote:
>>>>> Hi Michael,
>>>>>
>>>>> I've drafted the Network QoS feature page.
>>>>> www.ovirt.org/Features/Design/Network_QoS
>>>>> I'll appreciate it if you could go over it and see if you have comments
>>>>> or anything else to add to the API section.
>>>>>
>>>>> Thanks,
>>>>> Ofri
>>>>>
>>>>
>>>> i have few questions/comments regarding api/general design:
>>>>
>>>> 1) incoming and outgoing traffic can be shaped independently, will we
>>>> support
>>>>    granularity of enabling|disabling qos on inbound vs.outbound traffic?,
>>>>    then i'd suggest modelling QOS in api like this:
>>>>
>>>> <qos>
>>>>   <inbound enabled="true|false">
>>>>     <average>xxx</average>
>>>>     <peak>yyy</peak>
>>>>     <burst>zzz</burst>
>>>>     <floor>qqq</floor>
>>>>   </inbound>
>>>>   <outbound enabled="true|false">
>>>>     <average>xxx</average>
>>>>     <peak>yyy</peak>
>>>>     <burst>zzz</burst>
>>>>   </outbound>
>>>> </qos>
>>>
>>>
>>> Note that the above requires to support a mode of inbound (or outbound)
>>> values configured while not enabled,
>>
>> no it doesn't, all attributes can have NULLs when disabled.
>>
> 
> I'm ok with wither.
> Just note that the hierarchy is deeper, and the design will be updated.
> Basically we have:
> Policy
>   -> QoS
>     -> Network
>        -> In
>        -> Out
> 
> The reason for it is that going forward Policy will include CPU QoS, memory
> QoS, Storage QoS and Quota.
> Most humans will want to kill us if they need to fill in all of it every
> time. So policies is something which we can manage and people can actually
> use. If someone needs something specific he can clone a policy and make the
> relevant changes.
> In this context what we need is for a network to reference a policy. The
> vNIC will get the policy reference by default, and can override it by
> specifying a different policy.

I assume setting QoS is done per vnic, I see above you wrote network.
Can you describe how setting a policy per vnic would look like in your mind?


> 
>>> it also requires a change in the UI.
>>
>> api & UI doesn't have to be the same, but i think suggested above makes sense
>> for UI as well.
>>
>>> I see how the above suggestion can be useful to users.
>>
>> it can be useful for us on a first place, cause it's easily extendible,
>> i.e it much easier to extend expended type with new elements rather
>> than inline adding attributes <outbound average='' peak='' burst='' ...../>
>> and in addition we can easily add system element's (if not now then in
>> future)
>> such as <inbound enabled="true|false" policy='xxx' ...>
>>
>>>
>>>>
>>>>
>>>> 2) at design page, i didn't saw you mentioning permission model for the
>>>> QOS,
>>>>    who should be able seeing it/manipulating it (note, that in case of
>>>>    user
>>>>    that should not be seeing it, in api you shouldn't even show the state
>>>>    of the
>>>>    qos e.g active or not, maybe not even worth mentioning <qos> at all)
>>>>
>>>
>>> That's a good point.
>>> Also note that the above suggests different UI dialogs in the user
>>> portal and the admin portal for adding vnic.
>>>
> 
> The assumption is that users with permissions to modify a vNIC can
> get/set the information in REST.

A user can add a VNIC to his VM if he has permission to use the network,
I'm not sure it make sense that he can also configure his own QoS.

I agree with Michael that configuring the QoS might not be relevant to
the user API/user Portal.

I would say that we should add a new permission on the network entity
for a user to configure QoS on that network.

> 
>>>
>>>>
>>>> 3) what about exposing policies?, like making admin being able to apply
>>>> same policy
>>>>    on a different devices, rather than doing it manually per device.
>>>
>>> I suggest to support having default configuration on the Network entity,
>>> all Vnics connected to the network inherit the configuration from the
>>> Network.
>>> If qos is configured both on the network and on the VNIC the VNIC
>>> configuration holds.
>>
>> usually QoS providers avoid having defaults cause when QoS turned on by
>> mistake it's simply applies these values silently, while if it has NULLs,
>> you cannot turn it on by mistake (i.e forcing users to set rules preferred
>> over default configurations)
>>
> See my response above on policies.
> As for setting it, well, we prefer to start with a baseline which can be later
> changed. This is better than starting in 'unlimited' mode we currently have.
> In this way potential bursts are still in control and if more resources needed
> than a matching policy should be assigned.
> 
>>>
>>>>
>>>>> Change the Virtual Machine > Network Interfaces to support QoS properties
>>>>> Example of an XML representation of a network interface
>>>>>
>>>>> <nic id="7a3cff5e-3cc4-47c2-8388-9adf16341f5e"
>>>>> ref="/api/vms/cdc0b102-fbfe-444a-b9cb-57d2af94f401/nics/7a3cff5e-3cc4-47c2-8388-9adf16341f5e">
>>>>>      <link rel="statistics"
>>>>>      href="/api/vms/082c794b-771f-452f-83c9-b2b5a19c0399/nics/7a3cff5e-3cc4-47c2-8388-9adf16341f5e/statistics"/>
>>>>>      <name>nic1</name>
>>>>>      <interface>virtio</interface>
>>>>>      <mac address="00:1a:4a:16:84:07"/>
>>>>>      <network id="00000000-0000-0000-0000-000000000009"
>>>>>      href="/api/networks/00000000-0000-0000-0000-000000000009"/>
>>>>>      <vm id="cdc0b102-fbfe-444a-b9cb-57d2af94f401"
>>>>>      href="/api/vms/cdc0b102-fbfe-444a-b9cb-57d2af94f401"/>
>>>>
>>>> - 'bandwidth' is not clear enough in my view, i think we should just use
>>>> 'qos'
>>>>
>>>>>      <bandwidth>
>>>>
>>>> - we should be having <enabled>true|false</enabled> element here/peer
>>>> traffic-dist?
>>>>
>>>>>        <inbound average='1000' peak='5000' floor='200' burst='1024'/>
>>>>>        <outbound average='128' peak='256' burst='256'/>
>>>>>      </bandwidth>
>>>>> </nic>
>>>>>
>>>>>
>>>>> An API user modifies a network interface with a PUT request
>>>>>
>>>>> <nic>
>>>>>       <name>nic2</name>
>>>>>      <network id="00000000-0000-0000-0000-000000000010"/>
>>>>>      <type>e1000</type>
>>>>>      <bandwidth>
>>>>>        <inbound average='1000' peak='5000' floor='200' burst='1024'/>
>>>>>        <outbound average='128' peak='256' burst='256'/>
>>>>>      </bandwidth>
>>>>> </nic>
>>>>
>>>>
>>>
>>
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 
> 



From mpastern at redhat.com  Tue May 28 07:34:55 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Tue, 28 May 2013 10:34:55 +0300
Subject: Qos feature
In-Reply-To: <1611981565.12724418.1369671219186.JavaMail.root@redhat.com>
References: <2041139267.3543084.1369294470496.JavaMail.root@redhat.com>
	<51A34118.8060204@redhat.com> <51A34756.9050902@redhat.com>
	<51A35265.2060306@redhat.com>
	<1611981565.12724418.1369671219186.JavaMail.root@redhat.com>
Message-ID: <51A45E1F.4010300@redhat.com>

On 05/27/2013 07:13 PM, Doron Fediuck wrote:
> 
> 
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "Livnat Peer" <lpeer at redhat.com>
>> Cc: "Ofri Masad" <omasad at redhat.com>, arch at ovirt.org
>> Sent: Monday, May 27, 2013 3:32:37 PM
>> Subject: Re: Qos feature
>>
>>
>> Hi Livnat,
>>
>> On 05/27/2013 02:45 PM, Livnat Peer wrote:
>>> On 05/27/2013 02:18 PM, Michael Pasternak wrote:
>>>> Hi Ofri,
>>>>
>>>> On 05/23/2013 10:34 AM, Ofri Masad wrote:
>>>>> Hi Michael,
>>>>>
>>>>> I've drafted the Network QoS feature page.
>>>>> www.ovirt.org/Features/Design/Network_QoS
>>>>> I'll appreciate it if you could go over it and see if you have comments
>>>>> or anything else to add to the API section.
>>>>>
>>>>> Thanks,
>>>>> Ofri
>>>>>
>>>>
>>>> i have few questions/comments regarding api/general design:
>>>>
>>>> 1) incoming and outgoing traffic can be shaped independently, will we
>>>> support
>>>>    granularity of enabling|disabling qos on inbound vs.outbound traffic?,
>>>>    then i'd suggest modelling QOS in api like this:
>>>>
>>>> <qos>
>>>>   <inbound enabled="true|false">
>>>>     <average>xxx</average>
>>>>     <peak>yyy</peak>
>>>>     <burst>zzz</burst>
>>>>     <floor>qqq</floor>
>>>>   </inbound>
>>>>   <outbound enabled="true|false">
>>>>     <average>xxx</average>
>>>>     <peak>yyy</peak>
>>>>     <burst>zzz</burst>
>>>>   </outbound>
>>>> </qos>
>>>
>>>
>>> Note that the above requires to support a mode of inbound (or outbound)
>>> values configured while not enabled,
>>
>> no it doesn't, all attributes can have NULLs when disabled.
>>
> 
> I'm ok with wither.
> Just note that the hierarchy is deeper, and the design will be updated.
> Basically we have:
> Policy
>   -> QoS
>     -> Network
>        -> In
>        -> Out
> 
> The reason for it is that going forward Policy will include CPU QoS, memory
> QoS, Storage QoS and Quota.

okay, but CPU is not relevant in the context of nic,
but if you say we will add more similar features under
same devices, we can have sla_policy or shaping_policy
(sla_ sounds less aggressive in my view)

> Most humans will want to kill us if they need to fill in all of it every
> time. So policies is something which we can manage and people can actually
> use. If someone needs something specific he can clone a policy and make the
> relevant changes.

this why i suggested using it :)

> In this context what we need is for a network to reference a policy. The
> vNIC will get the policy reference by default, and can override it by
> specifying a different policy.

in my opinion, no default policies should be used
(i put my two cents in other email on this tread (to livnat))

> 
>>> it also requires a change in the UI.
>>
>> api & UI doesn't have to be the same, but i think suggested above makes sense
>> for UI as well.
>>
>>> I see how the above suggestion can be useful to users.
>>
>> it can be useful for us on a first place, cause it's easily extendible,
>> i.e it much easier to extend expended type with new elements rather
>> than inline adding attributes <outbound average='' peak='' burst='' ...../>
>> and in addition we can easily add system element's (if not now then in
>> future)
>> such as <inbound enabled="true|false" policy='xxx' ...>
>>
>>>
>>>>
>>>>
>>>> 2) at design page, i didn't saw you mentioning permission model for the
>>>> QOS,
>>>>    who should be able seeing it/manipulating it (note, that in case of
>>>>    user
>>>>    that should not be seeing it, in api you shouldn't even show the state
>>>>    of the
>>>>    qos e.g active or not, maybe not even worth mentioning <qos> at all)
>>>>
>>>
>>> That's a good point.
>>> Also note that the above suggests different UI dialogs in the user
>>> portal and the admin portal for adding vnic.
>>>
> 
> The assumption is that users with permissions to modify a vNIC can
> get/set the information in REST.

i think it's a bit deeper, it should be handled by the administration,
while regular NIC changes by technical personnel.

> 
>>>
>>>>
>>>> 3) what about exposing policies?, like making admin being able to apply
>>>> same policy
>>>>    on a different devices, rather than doing it manually per device.
>>>
>>> I suggest to support having default configuration on the Network entity,
>>> all Vnics connected to the network inherit the configuration from the
>>> Network.
>>> If qos is configured both on the network and on the VNIC the VNIC
>>> configuration holds.
>>
>> usually QoS providers avoid having defaults cause when QoS turned on by
>> mistake it's simply applies these values silently, while if it has NULLs,
>> you cannot turn it on by mistake (i.e forcing users to set rules preferred
>> over default configurations)
>>
> See my response above on policies.
> As for setting it, well, we prefer to start with a baseline which can be later
> changed. This is better than starting in 'unlimited' mode we currently have.
> In this way potential bursts are still in control and if more resources needed
> than a matching policy should be assigned.
> 
>>>
>>>>
>>>>> Change the Virtual Machine > Network Interfaces to support QoS properties
>>>>> Example of an XML representation of a network interface
>>>>>
>>>>> <nic id="7a3cff5e-3cc4-47c2-8388-9adf16341f5e"
>>>>> ref="/api/vms/cdc0b102-fbfe-444a-b9cb-57d2af94f401/nics/7a3cff5e-3cc4-47c2-8388-9adf16341f5e">
>>>>>      <link rel="statistics"
>>>>>      href="/api/vms/082c794b-771f-452f-83c9-b2b5a19c0399/nics/7a3cff5e-3cc4-47c2-8388-9adf16341f5e/statistics"/>
>>>>>      <name>nic1</name>
>>>>>      <interface>virtio</interface>
>>>>>      <mac address="00:1a:4a:16:84:07"/>
>>>>>      <network id="00000000-0000-0000-0000-000000000009"
>>>>>      href="/api/networks/00000000-0000-0000-0000-000000000009"/>
>>>>>      <vm id="cdc0b102-fbfe-444a-b9cb-57d2af94f401"
>>>>>      href="/api/vms/cdc0b102-fbfe-444a-b9cb-57d2af94f401"/>
>>>>
>>>> - 'bandwidth' is not clear enough in my view, i think we should just use
>>>> 'qos'
>>>>
>>>>>      <bandwidth>
>>>>
>>>> - we should be having <enabled>true|false</enabled> element here/peer
>>>> traffic-dist?
>>>>
>>>>>        <inbound average='1000' peak='5000' floor='200' burst='1024'/>
>>>>>        <outbound average='128' peak='256' burst='256'/>
>>>>>      </bandwidth>
>>>>> </nic>
>>>>>
>>>>>
>>>>> An API user modifies a network interface with a PUT request
>>>>>
>>>>> <nic>
>>>>>       <name>nic2</name>
>>>>>      <network id="00000000-0000-0000-0000-000000000010"/>
>>>>>      <type>e1000</type>
>>>>>      <bandwidth>
>>>>>        <inbound average='1000' peak='5000' floor='200' burst='1024'/>
>>>>>        <outbound average='128' peak='256' burst='256'/>
>>>>>      </bandwidth>
>>>>> </nic>
>>>>
>>>>
>>>
>>
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Tue May 28 07:49:40 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Tue, 28 May 2013 10:49:40 +0300
Subject: Qos feature
In-Reply-To: <51A38FFF.8060705@redhat.com>
References: <2041139267.3543084.1369294470496.JavaMail.root@redhat.com>
	<51A34118.8060204@redhat.com> <51A34756.9050902@redhat.com>
	<51A35265.2060306@redhat.com> <51A38FFF.8060705@redhat.com>
Message-ID: <51A46194.7080409@redhat.com>

On 05/27/2013 07:55 PM, Livnat Peer wrote:
> On 05/27/2013 03:32 PM, Michael Pasternak wrote:
>>
>> Hi Livnat,
>>
>> On 05/27/2013 02:45 PM, Livnat Peer wrote:
>>> On 05/27/2013 02:18 PM, Michael Pasternak wrote:
>>>> Hi Ofri,
>>>>
>>>> On 05/23/2013 10:34 AM, Ofri Masad wrote:
>>>>> Hi Michael,
>>>>>
>>>>> I've drafted the Network QoS feature page. www.ovirt.org/Features/Design/Network_QoS
>>>>> I'll appreciate it if you could go over it and see if you have comments or anything else to add to the API section.
>>>>>
>>>>> Thanks,
>>>>> Ofri
>>>>>
>>>>
>>>> i have few questions/comments regarding api/general design:
>>>>
>>>> 1) incoming and outgoing traffic can be shaped independently, will we support
>>>>    granularity of enabling|disabling qos on inbound vs.outbound traffic?,
>>>>    then i'd suggest modelling QOS in api like this:
>>>>
>>>> <qos>
>>>>   <inbound enabled="true|false">
>>>>     <average>xxx</average>
>>>>     <peak>yyy</peak>
>>>>     <burst>zzz</burst>
>>>>     <floor>qqq</floor>
>>>>   </inbound>
>>>>   <outbound enabled="true|false">
>>>>     <average>xxx</average>
>>>>     <peak>yyy</peak>
>>>>     <burst>zzz</burst>
>>>>   </outbound>
>>>> </qos>
>>>
>>>
>>> Note that the above requires to support a mode of inbound (or outbound)
>>> values configured while not enabled, 
>>
>> no it doesn't, all attributes can have NULLs when disabled.
>>
> 
> Why disable+null values is better than just omitting the
> inbound/outbound elements?

basically this design serves my proposal mentioned below,
so administration can clearly see that no defaults exist,
and they have to choose policy explicitly.

but i agree "omitting" is a good way to go as well
(we actively using it across the api)

> 
> I liked the disable/enable idea...

this is exactly the same idea, just a bit visualized.

> 
>>> it also requires a change in the UI.
>>
>> api & UI doesn't have to be the same, but i think suggested above makes sense
>> for UI as well.
>>
> of course, I agree, they don't have to be the same. In this case I think
> it makes sense.
> 
>>> I see how the above suggestion can be useful to users.
>>
>> it can be useful for us on a first place, cause it's easily extendible,
>> i.e it much easier to extend expended type with new elements rather
>> than inline adding attributes <outbound average='' peak='' burst='' ...../>
>> and in addition we can easily add system element's (if not now then in future)
>> such as <inbound enabled="true|false" policy='xxx' ...>
>>
>>>
>>>>
>>>>
>>>> 2) at design page, i didn't saw you mentioning permission model for the QOS,
>>>>    who should be able seeing it/manipulating it (note, that in case of user
>>>>    that should not be seeing it, in api you shouldn't even show the state of the
>>>>    qos e.g active or not, maybe not even worth mentioning <qos> at all)
>>>>
>>>
>>> That's a good point.
>>> Also note that the above suggests different UI dialogs in the user
>>> portal and the admin portal for adding vnic.
>>>
>>>
>>>>
>>>> 3) what about exposing policies?, like making admin being able to apply same policy
>>>>    on a different devices, rather than doing it manually per device.
>>>
>>> I suggest to support having default configuration on the Network entity,
>>> all Vnics connected to the network inherit the configuration from the
>>> Network.
>>> If qos is configured both on the network and on the VNIC the VNIC
>>> configuration holds.
>>
>> usually QoS providers avoid having defaults cause when QoS turned on by
>> mistake it's simply applies these values silently, while if it has NULLs,
>> you cannot turn it on by mistake (i.e forcing users to set rules preferred
>> over default configurations)
>>
> 
> I think the idea wasn't clear enough, a more detailed explanation -
> 
> A user can configure the inbound/outbound values on the network entity.
> This configuration would apply to all VNICs using this network.
> That approach would help the administrator to configure, in a very
> simple way, a policy that prevents one VM from taking too much of the
> network bandwidth.

i understand, but this is different use-case, i was thinking about
private policies (i'm sure there are plenty use-cases for it), this
way we can help by providing policy management, like:

/api/slapolicies

<slapolicy id=xxx href=/api/slapolicies>
  <name>backup_qos_policy</name>
  <type>network</type>
  <inbound enabled="true|false">
    <average>xxx</average>
    <peak>yyy</peak>
    <burst>zzz</burst>
    <floor>qqq</floor>
  </inbound>
  <outbound enabled="true|false">
    <average>xxx</average>
    <peak>yyy</peak>
    <burst>zzz</burst>
  </outbound>
</slapolicy>

<slapolicy id=xxx href=/api/slapolicies>
  <name>user_cpu_policy</name>
  <type>cpu</type>
  ...
</slapolicy>

<slapolicy id=xxx href=/api/slapolicies>
  <name>user_memory_policy</name>
  <type>memory</type>
  ...
</slapolicy>

...

> 
> 
> 
>>>
>>>>
>>>>> Change the Virtual Machine > Network Interfaces to support QoS properties Example of an XML representation of a network interface
>>>>>
>>>>> <nic id="7a3cff5e-3cc4-47c2-8388-9adf16341f5e"  ref="/api/vms/cdc0b102-fbfe-444a-b9cb-57d2af94f401/nics/7a3cff5e-3cc4-47c2-8388-9adf16341f5e">
>>>>>      <link rel="statistics" href="/api/vms/082c794b-771f-452f-83c9-b2b5a19c0399/nics/7a3cff5e-3cc4-47c2-8388-9adf16341f5e/statistics"/>
>>>>>      <name>nic1</name>
>>>>>      <interface>virtio</interface>
>>>>>      <mac address="00:1a:4a:16:84:07"/>
>>>>>      <network id="00000000-0000-0000-0000-000000000009" href="/api/networks/00000000-0000-0000-0000-000000000009"/>
>>>>>      <vm id="cdc0b102-fbfe-444a-b9cb-57d2af94f401" href="/api/vms/cdc0b102-fbfe-444a-b9cb-57d2af94f401"/>
>>>>
>>>> - 'bandwidth' is not clear enough in my view, i think we should just use 'qos'
>>>>
>>>>>      <bandwidth>
>>>>
>>>> - we should be having <enabled>true|false</enabled> element here/peer traffic-dist?
>>>>
>>>>>        <inbound average='1000' peak='5000' floor='200' burst='1024'/>
>>>>>        <outbound average='128' peak='256' burst='256'/>
>>>>>      </bandwidth>
>>>>> </nic>
>>>>>
>>>>>
>>>>> An API user modifies a network interface with a PUT request
>>>>>
>>>>> <nic>
>>>>>       <name>nic2</name>
>>>>>      <network id="00000000-0000-0000-0000-000000000010"/>
>>>>>      <type>e1000</type>
>>>>>      <bandwidth>
>>>>>        <inbound average='1000' peak='5000' floor='200' burst='1024'/>
>>>>>        <outbound average='128' peak='256' burst='256'/>
>>>>>      </bandwidth>
>>>>> </nic>
>>>>
>>>>
>>>
>>
>>
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From liumbj at linux.vnet.ibm.com  Tue May 28 08:03:49 2013
From: liumbj at linux.vnet.ibm.com (Mei Liu)
Date: Tue, 28 May 2013 16:03:49 +0800
Subject: add blkIoTune support for a specific device at vm creation
In-Reply-To: <579234313.7519447.1369574921187.JavaMail.root@redhat.com>
References: <20130526130006.GJ27100@redhat.com>
	<579234313.7519447.1369574921187.JavaMail.root@redhat.com>
Message-ID: <51A464E5.4020908@linux.vnet.ibm.com>

On 05/26/2013 09:28 PM, Eli Mesika wrote:
>
> ----- Original Message -----
>> From: "Dan Kenigsberg" <danken at redhat.com>
>> To: "Doron Fediuck" <dfediuck at redhat.com>, "Eli Mesika" <emesika at redhat.com>
>> Cc: "Mei Liu" <liumbj at linux.vnet.ibm.com>, arch at ovirt.org
>> Sent: Thursday, May 23, 2013 6:36:42 PM
>> Subject: Re: add blkIoTune support for a specific device at vm creation
>>
>> On Wed, May 22, 2013 at 11:55:26AM -0400, Doron Fediuck wrote:
>>> ----- Original Message -----
>>>> From: "Mei Liu" <liumbj at linux.vnet.ibm.com>
>>>> To: arch at ovirt.org
>>>> Cc: dfediuck at redhat.com, wudxw at linux.vnet.ibm.com
>>>> Sent: Monday, May 20, 2013 6:07:53 AM
>>>> Subject: add blkIoTune support for a specific device at vm creation
>>>>
>>>> Hi all,
>>>> I would like to add blkIoTune support for a specific device at vm
>>>> creation.
>>>>
>>>> The code parses the 'blkIoTune' descrption for block devices at vm
>>>> creation
>>>> time and adds iotune tag accordingly.
>>>>
>>>> e.g.
>>>> Adding 'blkIoTune':{'read_bytes_sec': 6120000, 'total_iops_sec': 800} for
>>>> a
>>>> block device will add the following in dom xml for that device.
>>>>
>>>> <iotune>
>>>>        <read_bytes_sec>6120000</read_bytes_sec>
>>>>        <total_iops_sec>800</total_iops_sec>
>>>> </iotune>
>>>>
>>>> The patch is under review in http://gerrit.ovirt.org/#/c/14636/ .
>>>>
>>>> Does the patch meet the requirement of the engine or the whole
>>>> architecture? Are the new parameters properly placed?  Any suggestions
>>>> are welcomed.
>>>>
>>>> TIA.
>>>>
>>>> Best reagrds,
>>>> Mei Liu (Rose)
>>>>
>>>>
>>> Hi Mei Liu,
>>> Apologies for my late response.
>>> Is there an engine implementation for it?
>>> This is important enough to be considered on how it works in a cluster
>>> on not just on host level. For example, what happens during and after
>>> live migration?
>> As far as I know, there's nothing written on the Engine side, yet.
>>
>> And in my opinion, we can aim low, and have a very minimalistic
>> implementation, that give a thin GUI for each block device, in where
>> these two parameters can be edited, and passed to Vdsm on vmCreate,
>> hotplug, and vmUpdateDevice.
>>
>> Obviously, such an implementation affects only in the vDisk level; the
>> io throttling would follow the VM to the destination node, regardless of
>> other readers/writers on that host. This is suboptimal; it would be
>> cooler to have a policy that provides relative io priority to different
>> vDisks/VMs/users. But in my opinion, it can wait for a second phase.
>>
>> I'm fine with the suggested Engine/Vdsm API (though I'd try to be even
>> more just-like-libvirt and call it "iotune"). But I'm no Engine expert
>> to judge - the may wnat to hide it in their specParam map.
> Right, ant reason why not to use the specParam
> s here ???

No specific reason for doing so. I moved them to specParams.


>
>> I'd love to see a feature page written for this, anyway!
>>
>>
>> Dan.
>>
I have updated the patch in http://gerrit.ovirt.org/#/c/14636/ and put 
these parameters in specParams.
Appreciate that you take a look and give suggestions.



From liumbj at linux.vnet.ibm.com  Tue May 28 08:18:10 2013
From: liumbj at linux.vnet.ibm.com (Mei Liu)
Date: Tue, 28 May 2013 16:18:10 +0800
Subject: SLA feature for storage I/O bandwidth
Message-ID: <51A46842.1090901@linux.vnet.ibm.com>

Hi all,
I created a drafted wiki page on  design of storage I/O bandwidth SLA in 
the following link:

http://www.ovirt.org/SLA_for_storage_resource .

I will appreciate the efforts if anyone who works on ovirt engine, vdsm 
or mom could give some comments. TIA.


Best regards,
Mei Liu (Rose)



From emesika at redhat.com  Tue May 28 08:32:27 2013
From: emesika at redhat.com (Eli Mesika)
Date: Tue, 28 May 2013 04:32:27 -0400 (EDT)
Subject: add blkIoTune support for a specific device at vm creation
In-Reply-To: <51A464E5.4020908@linux.vnet.ibm.com>
References: <20130526130006.GJ27100@redhat.com>
	<579234313.7519447.1369574921187.JavaMail.root@redhat.com>
	<51A464E5.4020908@linux.vnet.ibm.com>
Message-ID: <324845681.8227016.1369729947029.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Mei Liu" <liumbj at linux.vnet.ibm.com>
> To: "Eli Mesika" <emesika at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
> Cc: "Doron Fediuck" <dfediuck at redhat.com>, arch at ovirt.org
> Sent: Tuesday, May 28, 2013 11:03:49 AM
> Subject: Re: add blkIoTune support for a specific device at vm creation
> 
> On 05/26/2013 09:28 PM, Eli Mesika wrote:
> >
> > ----- Original Message -----
> >> From: "Dan Kenigsberg" <danken at redhat.com>
> >> To: "Doron Fediuck" <dfediuck at redhat.com>, "Eli Mesika"
> >> <emesika at redhat.com>
> >> Cc: "Mei Liu" <liumbj at linux.vnet.ibm.com>, arch at ovirt.org
> >> Sent: Thursday, May 23, 2013 6:36:42 PM
> >> Subject: Re: add blkIoTune support for a specific device at vm creation
> >>
> >> On Wed, May 22, 2013 at 11:55:26AM -0400, Doron Fediuck wrote:
> >>> ----- Original Message -----
> >>>> From: "Mei Liu" <liumbj at linux.vnet.ibm.com>
> >>>> To: arch at ovirt.org
> >>>> Cc: dfediuck at redhat.com, wudxw at linux.vnet.ibm.com
> >>>> Sent: Monday, May 20, 2013 6:07:53 AM
> >>>> Subject: add blkIoTune support for a specific device at vm creation
> >>>>
> >>>> Hi all,
> >>>> I would like to add blkIoTune support for a specific device at vm
> >>>> creation.
> >>>>
> >>>> The code parses the 'blkIoTune' descrption for block devices at vm
> >>>> creation
> >>>> time and adds iotune tag accordingly.
> >>>>
> >>>> e.g.
> >>>> Adding 'blkIoTune':{'read_bytes_sec': 6120000, 'total_iops_sec': 800}
> >>>> for
> >>>> a
> >>>> block device will add the following in dom xml for that device.
> >>>>
> >>>> <iotune>
> >>>>        <read_bytes_sec>6120000</read_bytes_sec>
> >>>>        <total_iops_sec>800</total_iops_sec>
> >>>> </iotune>
> >>>>
> >>>> The patch is under review in http://gerrit.ovirt.org/#/c/14636/ .
> >>>>
> >>>> Does the patch meet the requirement of the engine or the whole
> >>>> architecture? Are the new parameters properly placed?  Any suggestions
> >>>> are welcomed.
> >>>>
> >>>> TIA.
> >>>>
> >>>> Best reagrds,
> >>>> Mei Liu (Rose)
> >>>>
> >>>>
> >>> Hi Mei Liu,
> >>> Apologies for my late response.
> >>> Is there an engine implementation for it?
> >>> This is important enough to be considered on how it works in a cluster
> >>> on not just on host level. For example, what happens during and after
> >>> live migration?
> >> As far as I know, there's nothing written on the Engine side, yet.
> >>
> >> And in my opinion, we can aim low, and have a very minimalistic
> >> implementation, that give a thin GUI for each block device, in where
> >> these two parameters can be edited, and passed to Vdsm on vmCreate,
> >> hotplug, and vmUpdateDevice.
> >>
> >> Obviously, such an implementation affects only in the vDisk level; the
> >> io throttling would follow the VM to the destination node, regardless of
> >> other readers/writers on that host. This is suboptimal; it would be
> >> cooler to have a policy that provides relative io priority to different
> >> vDisks/VMs/users. But in my opinion, it can wait for a second phase.
> >>
> >> I'm fine with the suggested Engine/Vdsm API (though I'd try to be even
> >> more just-like-libvirt and call it "iotune"). But I'm no Engine expert
> >> to judge - the may wnat to hide it in their specParam map.
> > Right, ant reason why not to use the specParam
> > s here ???
> 
> No specific reason for doing so. I moved them to specParams.

Thanks

> 
> 
> >
> >> I'd love to see a feature page written for this, anyway!
> >>
> >>
> >> Dan.
> >>
> I have updated the patch in http://gerrit.ovirt.org/#/c/14636/ and put
> these parameters in specParams.
> Appreciate that you take a look and give suggestions.

Looks good , gave +1

> 
> 


From mgoldboi at redhat.com  Tue May 28 14:01:11 2013
From: mgoldboi at redhat.com (Moran Goldboim)
Date: Tue, 28 May 2013 17:01:11 +0300
Subject: [3.3 release process] feature freeze readiness
In-Reply-To: <519DF477.9000300@redhat.com>
References: <519DF477.9000300@redhat.com>
Message-ID: <51A4B8A7.4070809@redhat.com>

On 05/23/2013 01:50 PM, Moran Goldboim wrote:
> we are about a week away from feature freeze of oVirt 3.3 (May 31st). 
> In order to be able to converge to this date we would need your help 
> (feature owners) understanding feature/overall status.
>
> I have updated  OVirt 3.3 release-management page [1] with features 
> status table [2]. having this complete table filled will help us 
> determine this version readiness.
>
> a test page addition is needed for each feature (link through the 
> table) - this will enable us good visibility and testing of those 
> features in test-day.
>
> I have left the old 3.3 feature overview -just below the new table, to 
> make sure i have taken all needed from that info. please verify all 
> you need is in the table, since this part will be deleted on feature 
> freeze readiness review - next Wednesday meeting.
>
> completing filling this table should be done no later than Tuesday May 
> 28th.
>
> Thanks.
>
> [1]http://www.ovirt.org/OVirt_3.3_release-management
> [2]http://www.ovirt.org/OVirt_3.3_release-management#Features_Status_Table 
>
> [3]http://www.ovirt.org/OVirt_3.3_release-management#Features
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch

Thanks for everyone who updated their status on the table.
Still there are missing features around virt, infra, storage and sla, 
please complete statuses on this missing features today so we can attend 
to understand the release status tomorrow's meeting.

Thanks.


From dneary at redhat.com  Wed May 29 07:42:40 2013
From: dneary at redhat.com (Dave Neary)
Date: Wed, 29 May 2013 09:42:40 +0200
Subject: SLA feature for storage I/O bandwidth
In-Reply-To: <51A46842.1090901@linux.vnet.ibm.com>
References: <51A46842.1090901@linux.vnet.ibm.com>
Message-ID: <51A5B170.50205@redhat.com>

Hi Mei Liu,

On 05/28/2013 10:18 AM, Mei Liu wrote:
> I created a drafted wiki page on  design of storage I/O bandwidth SLA in
> the following link:
> 
> http://www.ovirt.org/SLA_for_storage_resource .
> 
> I will appreciate the efforts if anyone who works on ovirt engine, vdsm
> or mom could give some comments. TIA.

Just out of interest - which version of oVirt are you targeting this
for? Can I assume that it's for post-3.3? Today is officially 3.3.
feature freeze (but we have a release meeting later to discuss that).

Thanks,
Dave.

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From dneary at redhat.com  Wed May 29 07:55:30 2013
From: dneary at redhat.com (Dave Neary)
Date: Wed, 29 May 2013 09:55:30 +0200
Subject: [3.3 release process] feature freeze readiness
In-Reply-To: <51A4B8A7.4070809@redhat.com>
References: <519DF477.9000300@redhat.com> <51A4B8A7.4070809@redhat.com>
Message-ID: <51A5B472.3030509@redhat.com>

Hi,

On 05/28/2013 04:01 PM, Moran Goldboim wrote:
> Thanks for everyone who updated their status on the table.
> Still there are missing features around virt, infra, storage and sla,
> please complete statuses on this missing features today so we can attend
> to understand the release status tomorrow's meeting.

The features still missing a status and owner are:

* GlusterFS Storage Domain
* Allow resign/force re-election of SPM

Also, a number of features have not set a release priority - especially
for red and orange features, we need to know whether the feature is
considered "must"/"should"/"optional" for 3.3, because those are the
ones that will end up delaying a release.

* RAM snapshots
* noVNC console
* Non Plugin RDP Invocation
* Instance Types

After that, we can start looking at red flag features to help set the
release date.

A few things jumped out at me:

== Red features marked as Must

For each of these, we need an estimate of how long the feature will take
to complete - these will almost certainly delay the release.

* Multiple Gateways
* Edit Connection Properties
* oVirt scheduler
* Scheduling API
* Networking QoS

Next priority is the orange musts - one in particular jumps out at me:
"Watchdog engine support" has a comment "REST API missing" - which
sounds ominous.

Thanks to everyone for filling this out! And thanks to Moran for taking
the lead on this, it's very useful.

Cheers,
Dave.
-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From liumbj at linux.vnet.ibm.com  Wed May 29 08:35:12 2013
From: liumbj at linux.vnet.ibm.com (Mei Liu)
Date: Wed, 29 May 2013 16:35:12 +0800
Subject: SLA feature for storage I/O bandwidth
In-Reply-To: <51A5B170.50205@redhat.com>
References: <51A46842.1090901@linux.vnet.ibm.com> <51A5B170.50205@redhat.com>
Message-ID: <51A5BDC0.2020602@linux.vnet.ibm.com>

On 05/29/2013 03:42 PM, Dave Neary wrote:
> Hi Mei Liu,
>
> On 05/28/2013 10:18 AM, Mei Liu wrote:
>> I created a drafted wiki page on  design of storage I/O bandwidth SLA in
>> the following link:
>>
>> http://www.ovirt.org/SLA_for_storage_resource .
>>
>> I will appreciate the efforts if anyone who works on ovirt engine, vdsm
>> or mom could give some comments. TIA.
> Just out of interest - which version of oVirt are you targeting this
> for? Can I assume that it's for post-3.3? Today is officially 3.3.
> feature freeze (but we have a release meeting later to discuss that).
>
> Thanks,
> Dave.
>
Hi Dave,
The basic i/o tune functionality for vdsm is almost ready. However, 
there is nothing written on the Engine side and no policy for automatic 
tuning is applied yet.
I am not sure if the basic functionality can target 3.3.


Best regards,
Mei Liu



From dneary at redhat.com  Wed May 29 14:52:00 2013
From: dneary at redhat.com (Dave Neary)
Date: Wed, 29 May 2013 16:52:00 +0200
Subject: Multiple Gateways 3.3 Feature
In-Reply-To: <1038209955.13068617.1369638715648.JavaMail.root@redhat.com>
References: <1038209955.13068617.1369638715648.JavaMail.root@redhat.com>
Message-ID: <51A61610.7070403@redhat.com>

Hi Assaf,

On 05/27/2013 09:11 AM, Assaf Muller wrote:
> The multiple gateways feature is planned for 3.3.
> 
> http://www.ovirt.org/Features/Multiple_Gateways

It's really late in the cycle to start work on a feature targeting 3.3 -
can you explain why this feature is such a high priority, please?

Also, do you have some idea when it might be release ready?

Thanks!
Dave.

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From danken at redhat.com  Wed May 29 15:26:10 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Wed, 29 May 2013 18:26:10 +0300
Subject: Multiple Gateways 3.3 Feature
In-Reply-To: <51A61610.7070403@redhat.com>
References: <1038209955.13068617.1369638715648.JavaMail.root@redhat.com>
	<51A61610.7070403@redhat.com>
Message-ID: <20130529152610.GA19068@redhat.com>

On Wed, May 29, 2013 at 04:52:00PM +0200, Dave Neary wrote:
> Hi Assaf,
> 
> On 05/27/2013 09:11 AM, Assaf Muller wrote:
> > The multiple gateways feature is planned for 3.3.
> > 
> > http://www.ovirt.org/Features/Multiple_Gateways
> 
> It's really late in the cycle to start work on a feature targeting 3.3 -
> can you explain why this feature is such a high priority, please?

We had multiple users requesting the ability to set the gateway of
display networks. Without it, spice/vnc clients cannot sit outside of
the ovirt network, which kinda hampers the whole point of spice, being a
really-remote desktop protocol.

People are hacking initscripts' route-* and rule-* files below Vdsm's
feet to enable this. That's not healthy. This feature is all about
automating this, and allowing it to inegrate with dynamic addresses
properly.

> 
> Also, do you have some idea when it might be release ready?

The stated date 2013-06-09 of beta readiness is a bit agressive, but I
am confident that this feature would be ready for the now-postponed date
of ovirt-3.3 (check point at 2013-06-15).

Nonetheless, we do need proper review and discussion of the suggested
feature. If something nasty pops up during the review, I would have to
reconsider.

Dan.


From lpeer at redhat.com  Wed May 29 15:30:24 2013
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 29 May 2013 18:30:24 +0300
Subject: Multiple Gateways 3.3 Feature
In-Reply-To: <20130529152610.GA19068@redhat.com>
References: <1038209955.13068617.1369638715648.JavaMail.root@redhat.com>
	<51A61610.7070403@redhat.com> <20130529152610.GA19068@redhat.com>
Message-ID: <51A61F10.3080000@redhat.com>

On 05/29/2013 06:26 PM, Dan Kenigsberg wrote:
> On Wed, May 29, 2013 at 04:52:00PM +0200, Dave Neary wrote:
>> Hi Assaf,
>>
>> On 05/27/2013 09:11 AM, Assaf Muller wrote:
>>> The multiple gateways feature is planned for 3.3.
>>>
>>> http://www.ovirt.org/Features/Multiple_Gateways
>>
>> It's really late in the cycle to start work on a feature targeting 3.3 -
>> can you explain why this feature is such a high priority, please?
> 
> We had multiple users requesting the ability to set the gateway of
> display networks. Without it, spice/vnc clients cannot sit outside of
> the ovirt network, which kinda hampers the whole point of spice, being a
> really-remote desktop protocol.
> 
> People are hacking initscripts' route-* and rule-* files below Vdsm's
> feet to enable this. That's not healthy. This feature is all about
> automating this, and allowing it to inegrate with dynamic addresses
> properly.
> 
>>
>> Also, do you have some idea when it might be release ready?
> 
> The stated date 2013-06-09 of beta readiness is a bit agressive, but I
> am confident that this feature would be ready for the now-postponed date
> of ovirt-3.3 (check point at 2013-06-15).
> 
> Nonetheless, we do need proper review and discussion of the suggested
> feature. If something nasty pops up during the review, I would have to
> reconsider.

In addition to the above I would like to add that we started working on
this proposal a few weeks ago, we encountered a lot of technical
difficulties and it took us relatively long time to build the proposal
for implementing this feature.


> 
> Dan.
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 



From dfediuck at redhat.com  Wed May 29 15:34:24 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Wed, 29 May 2013 11:34:24 -0400 (EDT)
Subject: SLA feature for storage I/O bandwidth
In-Reply-To: <51A5BDC0.2020602@linux.vnet.ibm.com>
References: <51A46842.1090901@linux.vnet.ibm.com> <51A5B170.50205@redhat.com>
	<51A5BDC0.2020602@linux.vnet.ibm.com>
Message-ID: <1264434811.14301245.1369841664456.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Mei Liu" <liumbj at linux.vnet.ibm.com>
> To: "Dave Neary" <dneary at redhat.com>
> Cc: arch at ovirt.org
> Sent: Wednesday, May 29, 2013 11:35:12 AM
> Subject: Re: SLA feature for storage I/O bandwidth
> 
> On 05/29/2013 03:42 PM, Dave Neary wrote:
> > Hi Mei Liu,
> >
> > On 05/28/2013 10:18 AM, Mei Liu wrote:
> >> I created a drafted wiki page on  design of storage I/O bandwidth SLA in
> >> the following link:
> >>
> >> http://www.ovirt.org/SLA_for_storage_resource .
> >>
> >> I will appreciate the efforts if anyone who works on ovirt engine, vdsm
> >> or mom could give some comments. TIA.
> > Just out of interest - which version of oVirt are you targeting this
> > for? Can I assume that it's for post-3.3? Today is officially 3.3.
> > feature freeze (but we have a release meeting later to discuss that).
> >
> > Thanks,
> > Dave.
> >
> Hi Dave,
> The basic i/o tune functionality for vdsm is almost ready. However,
> there is nothing written on the Engine side and no policy for automatic
> tuning is applied yet.
> I am not sure if the basic functionality can target 3.3.
> 
> 
> Best regards,
> Mei Liu
> 

Hi Mey Liu,
I'm still going over the wiki, but a few things we need to consider;
First of all QoS for storage I/O bandwidth is a part of a larger SLA
policy which may include network QoS, CPU and memory QoS and the quota
we implement today.

So first of all we need to make sure your design does not conflict
the other QoS parts, which is what I'm looking into now. 

Additionally, using the quota term is confusing as oVirt already has
quota today, and cpu API has his own quota definition. So please try
to come up with a different terminology.

I like your idea of setting an initial value but I need some more time
for it to come up with my insights.
Also, I completely agree with your concept of letting mom handle
it in host level. We need to verify it does not break anything related
to SPM. This is something we need to synchronize with the storage guys.

Looking into the engine area, we should start thinking on how this will
be supported in the main storage entities and VM / template / instance
entities. So you may want to add a section on this as well. This leads
me to think of importing and exporting a VM which may want to maintain
the defined IO QoS. Any thoughts around it?

Doron


From liumbj at linux.vnet.ibm.com  Thu May 30 10:05:54 2013
From: liumbj at linux.vnet.ibm.com (Mei Liu)
Date: Thu, 30 May 2013 18:05:54 +0800
Subject: move wiki page for SLA feature for storage I/O bandwidth
Message-ID: <51A72482.4030608@linux.vnet.ibm.com>

Hi all,

I move the wiki from http://ovirt.org/SLA_for_storage_resource to 
http://www.ovirt.org/Features/Design/SLA_for_storage_io_bandwidth to 
confirm

http://www.ovirt.org/Feature_template

Sorry for the inconvenience.

Best regards,
Mei Liu(Rose)




From kwade at redhat.com  Thu May 30 16:02:54 2013
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Thu, 30 May 2013 09:02:54 -0700
Subject: move wiki page for SLA feature for storage I/O bandwidth
In-Reply-To: <51A72482.4030608@linux.vnet.ibm.com>
References: <51A72482.4030608@linux.vnet.ibm.com>
Message-ID: <51A7782E.7030605@redhat.com>

On 05/30/2013 03:05 AM, Mei Liu wrote:
> Hi all,
> 
> I move the wiki from http://ovirt.org/SLA_for_storage_resource to
> http://www.ovirt.org/Features/Design/SLA_for_storage_io_bandwidth to
> confirm
> 
> http://www.ovirt.org/Feature_template

Actually, you had the page name more correct the first time.

We have a lot of page names to clean up on the wiki because they are put
in the fake-nesting of [[/Features/.../Page_name]] instead of using the
more proper [[Category:Feature]] and [[Category:Features under design]].

Here is the page that explains the page naming policy:

http://www.ovirt.org/Help#Wiki_contribution_guidelines
http://www.ovirt.org/Help:Wiki_structure

To be fair, none of us have tried hard to tell other people about the
page naming guidelines. But it is something that needs to be cleaned up,
and perhaps we can all start with that by following the guidelines for
new pages.

Thanks,

- Karsten
-- 
Karsten 'quaid' Wade
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20130530/cda63a02/attachment.sig>