From pmyers at redhat.com  Thu Dec  1 14:32:48 2011
From: pmyers at redhat.com (Perry Myers)
Date: Thu, 01 Dec 2011 09:32:48 -0500
Subject: [node-devel] oVirt Node designs for stateless operation and 3rd
	party plugins
Message-ID: <4ED79010.8060202@redhat.com>

the Node development team has been trying to write up rough requirements
around the stateless and plugins concepts.  And also some working high
level design.

They can be reviewed on these two wiki pages:

http://ovirt.org/wiki/Node_plugins
http://ovirt.org/wiki/Node_Stateless

Since the plugin model and the stateless model affect more than just the
oVirt Node itself, we definitely would like to get input from other
teams on the oVirt project.

Please add comments here or directly to the wiki.

Cheers,

Perry


From mburns at redhat.com  Thu Dec  1 15:18:33 2011
From: mburns at redhat.com (Mike Burns)
Date: Thu, 01 Dec 2011 10:18:33 -0500
Subject: [node-devel] ovirt-node Weekly meeting Summary - 2011-12-01
Message-ID: <1322752713.3839.8.camel@beelzebub.mburnsfire.net>

Minutes:        http://ovirt.org/meetings/ovirt/2011/ovirt.2011-12-01-14.00.html
Minutes (text): http://ovirt.org/meetings/ovirt/2011/ovirt.2011-12-01-14.00.txt
Log:            http://ovirt.org/meetings/ovirt/2011/ovirt.2011-12-01-14.00.log.html

Thanks

Mike


-- 
Michael Burns
Software Engineer
Red Hat
mburns at redhat.com



From akushwah at cisco.com  Sat Dec  3 00:45:59 2011
From: akushwah at cisco.com (Aruna Kushwaha (akushwah))
Date: Fri, 2 Dec 2011 16:45:59 -0800
Subject: [node-devel] Error when building the ovirt-node ISO image
In-Reply-To: <mailman.7.1321117202.3772.node-devel@ovirt.org>
References: <mailman.7.1321117202.3772.node-devel@ovirt.org>
Message-ID: <66FE7599CC65854284A2CDEE984D162B04E6254D@xmb-sjc-234.amer.cisco.com>

Getting error: make: node-creator: Command not found

[root at nexus-fedora-16 recipe]# make ovirt-node-image.iso
( \
    echo "PRODUCT='"oVirt Node Hypervisor"'" ;\
    echo "PRODUCT_SHORT='"oVirt Node Hypervisor"'" ;\
    echo "PACKAGE=ovirt-node-image" ;\
    echo "VERSION=2.1" ;\
    echo "RELEASE=0.fc16" ;\
) > version.ks
node-creator ovirt-node-image.ks
make: node-creator: Command not found
make: *** [ovirt-node-image.iso] Error 127

I followed all the steps:
This is a  fedora 16
[root at nexus-fedora-16 x86_64]# uname -a
Linux nexus-fedora-16.cisco.com 3.1.0-7.fc16.x86_64 #1 SMP Tue Nov 1
21:10:48 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

http://ovirt.org/wiki/Node_Building
and made rpm repository.
root at nexus-fedora-16 x86_64]# ls
repodata
vdsm-4.9.0-0.200.g2fc4e63.fc16.x86_64(1).rpm
vdsm-4.9.0-0.200.g2fc4e63.fc16.x86_64.rpm
vdsm-bootstrap-4.9.0-0.200.g2fc4e63.fc16.noarch(1).rpm
vdsm-bootstrap-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
vdsm-cli-4.9.0-0.200.g2fc4e63.fc16.noarch(1).rpm
vdsm-cli-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
vdsm-debuginfo-4.9.0-0.200.g2fc4e63.fc16.x86_64(1).rpm
vdsm-debuginfo-4.9.0-0.200.g2fc4e63.fc16.x86_64.rpm
vdsm-debug-plugin-4.9.0-0.200.g2fc4e63.fc16.noarch(1).rpm
vdsm-debug-plugin-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
vdsm-hook-faqemu-4.9.0-0.200.g2fc4e63.fc16.noarch(1).rpm
vdsm-hook-faqemu-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
vdsm-hook-vhostmd-4.9.0-0.200.g2fc4e63.fc16.noarch(1).rpm
vdsm-hook-vhostmd-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
vdsm-reg-4.9.0-0.200.g2fc4e63.fc16.noarch(1).rpm
vdsm-reg-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm

thanks
Aruna


Today's Topics:

   1. Re: Error when building the ovirt-node ISO image (Mike Burns)


----------------------------------------------------------------------

Message: 1
Date: Fri, 11 Nov 2011 17:23:26 -0500
From: Mike Burns <mburns at redhat.com>
To: kmestery <kmestery at cisco.com>
Cc: node-devel at ovirt.org
Subject: Re: [node-devel] Error when building the ovirt-node ISO image
Message-ID:
	<1321050207.32173.5.camel at mburns-laptop.usersys.redhat.com>
Content-Type: text/plain; charset="UTF-8"

On Fri, 2011-11-11 at 10:14 -0600, kmestery wrote:
> After getting past my RPM errors, I am now failing to build
ovirt-node. I have followed the wiki instructions, copied the VDSM RPMs
down, but it is failing as below:
> 
> [kmestery at fedora-build recipe]$ make ovirt-node-image.iso
> ( \
>     echo "PRODUCT='"oVirt Node Hypervisor"'" ;\
>     echo "PRODUCT_SHORT='"oVirt Node Hypervisor"'" ;\
>     echo "PACKAGE=ovirt-node-image" ;\
>     echo "VERSION=2.1" ;\
>     echo "RELEASE=0.fc16" ;\
> ) > version.ks
> node-creator ovirt-node-image.ks
> Error creating Live CD : Failed to find package 'vdsm-cli' : No
package(s) available to install
> [kmestery at fedora-build recipe]$ git pull
> Already up-to-date.
> [kmestery at fedora-build recipe]$ 
> 
> My RPMS directory does indeed contain vdsm-cli:
> 
> [kmestery at fedora-build RPMS]$ ls -R ~/rpmbuild/RPMS
> /home/kmestery/rpmbuild/RPMS:
> noarch  repodata  x86_64
> 
> /home/kmestery/rpmbuild/RPMS/noarch:
> ovirt-node-2.1-0.fc16.kmestery1320980168.noarch.rpm
> ovirt-node-tools-2.1-0.fc16.kmestery1320980168.noarch.rpm
> 
> /home/kmestery/rpmbuild/RPMS/repodata:
>
184ab20b6d27021cfbd0db0df047af15b5e06022d6897c6d4c3663d9c3289392-filelis
ts.sqlite.gz
>
1e196e4f6bd1d0cb2365df191de8c458b7e47de371b889379616fef381a16ca5-other.x
ml.gz
>
5d9559beefedda4d4ae1cd5d3592e9b0156265dfda09fa5e7846ab5351e988bb-primary
.sqlite.gz
>
6d5679b4076c46b7b5d136058d66fe23b254505a78ea4cd3335d26bbfefa8b2b-filelis
ts.xml.gz
>
a621e113ac015ae69cd15710a4810224e68eb518d3bb167c406a46acf6f828ce-other.s
qlite.gz
>
e100ad7336d1b7eeb16932d6a2fd66ac22bd5a49646896e581a7b9e3b42126d1-primary
.xml.gz
> repomd.xml
> 
> /home/kmestery/rpmbuild/RPMS/x86_64:
> vdsm-4.9.0-0.200.g2fc4e63.fc16.x86_64.rpm
> vdsm-bootstrap-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
> vdsm-cli-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
> vdsm-debug-plugin-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
> vdsm-debuginfo-4.9.0-0.200.g2fc4e63.fc16.x86_64.rpm
> vdsm-hook-faqemu-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
> vdsm-hook-vhostmd-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
> vdsm-reg-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
> [kmestery at fedora-build RPMS]$ 
> 
> Any ideas?
> 
> Thanks!
> Kyle
> _______________________________________________
> node-devel mailing list
> node-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/node-devel


Did you run:

createrepo /home/kmestery/rpmbuild/RPMS
export OVIRT_LOCAL_REPO=file:///home/kmestery/rpmbuild/RPMS

then

make ovirt-node-image.iso

Mike



------------------------------

_______________________________________________
node-devel mailing list
node-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/node-devel


End of node-devel Digest, Vol 3, Issue 4
****************************************


From mburns at redhat.com  Sat Dec  3 02:01:01 2011
From: mburns at redhat.com (Mike Burns)
Date: Fri, 02 Dec 2011 21:01:01 -0500
Subject: [node-devel] Error when building the ovirt-node ISO image
In-Reply-To: <66FE7599CC65854284A2CDEE984D162B04E6254D@xmb-sjc-234.amer.cisco.com>
References: <mailman.7.1321117202.3772.node-devel@ovirt.org>
	<66FE7599CC65854284A2CDEE984D162B04E6254D@xmb-sjc-234.amer.cisco.com>
Message-ID: <1322877661.3915.5.camel@beelzebub.mburnsfire.net>

On Fri, 2011-12-02 at 16:45 -0800, Aruna Kushwaha (akushwah) wrote:
> Getting error: make: node-creator: Command not found

You need to yum install the ovirt-node-tools package you just built.
I'm working on a way to not require this, but for the moment, that's
what you need to do.

Mike
> 
> [root at nexus-fedora-16 recipe]# make ovirt-node-image.iso
> ( \
>     echo "PRODUCT='"oVirt Node Hypervisor"'" ;\
>     echo "PRODUCT_SHORT='"oVirt Node Hypervisor"'" ;\
>     echo "PACKAGE=ovirt-node-image" ;\
>     echo "VERSION=2.1" ;\
>     echo "RELEASE=0.fc16" ;\
> ) > version.ks
> node-creator ovirt-node-image.ks
> make: node-creator: Command not found
> make: *** [ovirt-node-image.iso] Error 127
> 
> I followed all the steps:
> This is a  fedora 16
> [root at nexus-fedora-16 x86_64]# uname -a
> Linux nexus-fedora-16.cisco.com 3.1.0-7.fc16.x86_64 #1 SMP Tue Nov 1
> 21:10:48 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
> 
> http://ovirt.org/wiki/Node_Building
> and made rpm repository.
> root at nexus-fedora-16 x86_64]# ls
> repodata
> vdsm-4.9.0-0.200.g2fc4e63.fc16.x86_64(1).rpm
> vdsm-4.9.0-0.200.g2fc4e63.fc16.x86_64.rpm
> vdsm-bootstrap-4.9.0-0.200.g2fc4e63.fc16.noarch(1).rpm
> vdsm-bootstrap-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
> vdsm-cli-4.9.0-0.200.g2fc4e63.fc16.noarch(1).rpm
> vdsm-cli-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
> vdsm-debuginfo-4.9.0-0.200.g2fc4e63.fc16.x86_64(1).rpm
> vdsm-debuginfo-4.9.0-0.200.g2fc4e63.fc16.x86_64.rpm
> vdsm-debug-plugin-4.9.0-0.200.g2fc4e63.fc16.noarch(1).rpm
> vdsm-debug-plugin-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
> vdsm-hook-faqemu-4.9.0-0.200.g2fc4e63.fc16.noarch(1).rpm
> vdsm-hook-faqemu-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
> vdsm-hook-vhostmd-4.9.0-0.200.g2fc4e63.fc16.noarch(1).rpm
> vdsm-hook-vhostmd-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
> vdsm-reg-4.9.0-0.200.g2fc4e63.fc16.noarch(1).rpm
> vdsm-reg-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
> 
> thanks
> Aruna
> 
> 
> Today's Topics:
> 
>    1. Re: Error when building the ovirt-node ISO image (Mike Burns)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 11 Nov 2011 17:23:26 -0500
> From: Mike Burns <mburns at redhat.com>
> To: kmestery <kmestery at cisco.com>
> Cc: node-devel at ovirt.org
> Subject: Re: [node-devel] Error when building the ovirt-node ISO image
> Message-ID:
> 	<1321050207.32173.5.camel at mburns-laptop.usersys.redhat.com>
> Content-Type: text/plain; charset="UTF-8"
> 
> On Fri, 2011-11-11 at 10:14 -0600, kmestery wrote:
> > After getting past my RPM errors, I am now failing to build
> ovirt-node. I have followed the wiki instructions, copied the VDSM RPMs
> down, but it is failing as below:
> > 
> > [kmestery at fedora-build recipe]$ make ovirt-node-image.iso
> > ( \
> >     echo "PRODUCT='"oVirt Node Hypervisor"'" ;\
> >     echo "PRODUCT_SHORT='"oVirt Node Hypervisor"'" ;\
> >     echo "PACKAGE=ovirt-node-image" ;\
> >     echo "VERSION=2.1" ;\
> >     echo "RELEASE=0.fc16" ;\
> > ) > version.ks
> > node-creator ovirt-node-image.ks
> > Error creating Live CD : Failed to find package 'vdsm-cli' : No
> package(s) available to install
> > [kmestery at fedora-build recipe]$ git pull
> > Already up-to-date.
> > [kmestery at fedora-build recipe]$ 
> > 
> > My RPMS directory does indeed contain vdsm-cli:
> > 
> > [kmestery at fedora-build RPMS]$ ls -R ~/rpmbuild/RPMS
> > /home/kmestery/rpmbuild/RPMS:
> > noarch  repodata  x86_64
> > 
> > /home/kmestery/rpmbuild/RPMS/noarch:
> > ovirt-node-2.1-0.fc16.kmestery1320980168.noarch.rpm
> > ovirt-node-tools-2.1-0.fc16.kmestery1320980168.noarch.rpm
> > 
> > /home/kmestery/rpmbuild/RPMS/repodata:
> >
> 184ab20b6d27021cfbd0db0df047af15b5e06022d6897c6d4c3663d9c3289392-filelis
> ts.sqlite.gz
> >
> 1e196e4f6bd1d0cb2365df191de8c458b7e47de371b889379616fef381a16ca5-other.x
> ml.gz
> >
> 5d9559beefedda4d4ae1cd5d3592e9b0156265dfda09fa5e7846ab5351e988bb-primary
> .sqlite.gz
> >
> 6d5679b4076c46b7b5d136058d66fe23b254505a78ea4cd3335d26bbfefa8b2b-filelis
> ts.xml.gz
> >
> a621e113ac015ae69cd15710a4810224e68eb518d3bb167c406a46acf6f828ce-other.s
> qlite.gz
> >
> e100ad7336d1b7eeb16932d6a2fd66ac22bd5a49646896e581a7b9e3b42126d1-primary
> .xml.gz
> > repomd.xml
> > 
> > /home/kmestery/rpmbuild/RPMS/x86_64:
> > vdsm-4.9.0-0.200.g2fc4e63.fc16.x86_64.rpm
> > vdsm-bootstrap-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
> > vdsm-cli-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
> > vdsm-debug-plugin-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
> > vdsm-debuginfo-4.9.0-0.200.g2fc4e63.fc16.x86_64.rpm
> > vdsm-hook-faqemu-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
> > vdsm-hook-vhostmd-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
> > vdsm-reg-4.9.0-0.200.g2fc4e63.fc16.noarch.rpm
> > [kmestery at fedora-build RPMS]$ 
> > 
> > Any ideas?
> > 
> > Thanks!
> > Kyle
> > _______________________________________________
> > node-devel mailing list
> > node-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/node-devel
> 
> 
> Did you run:
> 
> createrepo /home/kmestery/rpmbuild/RPMS
> export OVIRT_LOCAL_REPO=file:///home/kmestery/rpmbuild/RPMS
> 
> then
> 
> make ovirt-node-image.iso
> 
> Mike
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> node-devel mailing list
> node-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/node-devel
> 
> 
> End of node-devel Digest, Vol 3, Issue 4
> ****************************************
> _______________________________________________
> node-devel mailing list
> node-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/node-devel




From mburns at redhat.com  Mon Dec  5 13:30:40 2011
From: mburns at redhat.com (Mike Burns)
Date: Mon, 05 Dec 2011 08:30:40 -0500
Subject: [node-devel] Reminder of action items from 2011-12-01 meeting
Message-ID: <1323091840.3915.33.camel@beelzebub.mburnsfire.net>

Just a reminder of action items out of our last meeting

Action items, by person

dougsland_
	dougsland_ get patches cleaned up and merged for vdsm
jboggs
	mburns, jboggs review and push ovirt-node patches
	jboggs to update wiki page with stacks information
mburns
	mburns will talk to engine team to get approval option prioritized
	mburns, jboggs review and push ovirt-node patches
	mburns to get ovirt-node and ovirt-node-tools builds posted to ovirt.org
	mburns to update wiki with instructions for building iso using just -tools rpm
	mburns to update First_release page as appropriate
	mburns to make RFE bug dependent on 3rd party plugin support BZ
	mburns to add info on auto-install parameters to the wiki
pmyers
	pmyers to send plugin and stateless designs to arch@ for review



From mburns at redhat.com  Mon Dec  5 20:16:35 2011
From: mburns at redhat.com (Mike Burns)
Date: Mon, 05 Dec 2011 15:16:35 -0500
Subject: [node-devel] Reminder of action items from 2011-12-01 meeting
In-Reply-To: <1323091840.3915.33.camel@beelzebub.mburnsfire.net>
References: <1323091840.3915.33.camel@beelzebub.mburnsfire.net>
Message-ID: <1323116195.3915.47.camel@beelzebub.mburnsfire.net>

Updates on my action items

On Mon, 2011-12-05 at 08:30 -0500, Mike Burns wrote:
> Just a reminder of action items out of our last meeting
> mburns
> 	mburns will talk to engine team to get approval option prioritized
		https://bugzilla.redhat.com/show_bug.cgi?id=755749
		Patch pushed to ovirt-engine 
> 	mburns, jboggs review and push ovirt-node patches
		All patches already posted
> 	mburns to get ovirt-node and ovirt-node-tools builds posted to ovirt.org
		Still pending -- waiting on vdsm changes getting pushed to ensure no
more changes need on node side.
> 	mburns to update wiki with instructions for building iso using just -tools rpm
		Instructions added to 	
 		http://ovirt.org/wiki/Node_Building 
> 	mburns to update First_release page as appropriate
		Updated as of today's status
> 	mburns to make RFE bug dependent on 3rd party plugin support BZ
		Done
> 	mburns to add info on auto-install parameters to the wiki
		Added to plugin wiki page
		http://ovirt.org/wiki/Node_plugins





From geoffocallaghan at gmail.com  Tue Dec  6 10:18:56 2011
From: geoffocallaghan at gmail.com (Geoff O'Callaghan)
Date: Tue, 06 Dec 2011 21:18:56 +1100
Subject: [node-devel] oVirt Node designs for stateless operation and 3rd
 party plugins
In-Reply-To: <4ED79010.8060202@redhat.com>
References: <4ED79010.8060202@redhat.com>
Message-ID: <1323166736.10490.46.camel@mrpointy>

On Thu, 2011-12-01 at 09:32 -0500, Perry Myers wrote: 
> the Node development team has been trying to write up rough requirements
> around the stateless and plugins concepts.  And also some working high
> level design.
> 
> They can be reviewed on these two wiki pages:
> 
> http://ovirt.org/wiki/Node_plugins
> http://ovirt.org/wiki/Node_Stateless
> 
> Since the plugin model and the stateless model affect more than just the
> oVirt Node itself, we definitely would like to get input from other
> teams on the oVirt project.
> 
> Please add comments here or directly to the wiki.
> 

Hi There

I work for a *large* organisation, I have issues with the goal of a
stateless design.

* Being able to install without a local disk

I don't see this as a compelling reason for doing anything.   In fact,
in many cases for other nameless hypervisors we use local disk as a
source for logging / dumps etc.

I think the goal for stateless should be instead be configuration
neutral.  ie.  if the node is destroyed the configuration can be
re-deployed without issue.

The other issue is that the node should continue to be re-bootable even
if the configuration server is unavailable, which is a reason for having
the configuration on a local disk or a san attached LUN.   This should
apply to the entire operational environment - if the engine is
unavailable during a restart I should continue working the way I was
configured to do so - that implies state is retained.  It needs to be
easily refreshable :-)

The configuration bundle should be refreshable from a configuration
server (part of the engine) and that could either be just configuration
or agents or even s/w images - all would be preferred and it's pretty
simple conceptually to have an active/backup image on local disk concept
to allow easy rollbacks etc.  Yes all this , except for the logging /
swap could be in a usb key.

The bundle should all be pushed via a SSL encrypted RESTful api using
known non-priv credentials, preferably with rotating passwords or some
cert based approach.   The server should also know who previously
managed it to reduce hostile attempts to change ownership of the node.

* DHCP and PXE booting

Many corporate security policies prohibit the use of DHCP or PXE booting
servers for production environments.   I don't see it as a big issue to
boot an install image and be a good woodpecker and hit enter a few times
and configure a management IP address.   It should be possible to script
the complete configuration / addition of the node after that step.   I
see the initial install as a trivial part of the complete node
lifecycle.
  
* DNS SRV records

Sorry,  I hate the idea.  Large corporates have so many different teams
doing little things that adding this in as a requirement simply adds
delays to the deployments and opportunities for misconfiguration.

Having the node image and config on local disk (or usb) avoids this
requirement as the node knows who manages it.   A complete rebuild could
occur and the configuration reloaded once added back into the engine.

* Previously configured state

Yes,  the node should remember the previous operational state if it
can't talk to the engine.   This is not a bad thing.   

*  Configuration server

This should be part of the engine.   It should know the complete
configuration of a node, right down to hypervisor 'firmware' image.  The
process should be 2-way.  An admin should be able to 'pull' the
image/config from an operational and accessible node and new
configurations/images should be pushable to it.

I really don't think this needs to be a separate server to the engine.

*  New bundle deployments / Upgrades

The engine should keep track of what images are on a node.   If a new
config / image is to be deployed then for example, the node would be
tagged with the new image.  If the node was online, an alternate image
would be pushed, vm's migrated to an alternate node and the node
restarted implementing the new image when requested.

If the node was offline at the time the new image was configured in the
engine or if the node was built say with an old image then when it
connects to the engine the image would be refreshed and the node
recycled.

* Swap

Local disk swap is likely to be required.  Overcommit is common and SSD
local disk is something that is quite useful :-)

So in summary,  I prefer to think that the target should be
configuration neutrality or even just plain old distributed
configuration from a central source rather than completely stateless.
The goal should be toleration of complete destruction of a node image
and configuration and a simple process to re-add it and automatically
re-apply the configuration/sw image.

Just some thoughts for discussion / abuse ;-)

Tks
Geoff

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




From mburns at redhat.com  Tue Dec  6 13:52:52 2011
From: mburns at redhat.com (Mike Burns)
Date: Tue, 06 Dec 2011 08:52:52 -0500
Subject: [node-devel] oVirt Node designs for stateless operation and 3rd
 party plugins
In-Reply-To: <1323166736.10490.46.camel@mrpointy>
References: <4ED79010.8060202@redhat.com> <1323166736.10490.46.camel@mrpointy>
Message-ID: <1323179572.3915.124.camel@beelzebub.mburnsfire.net>

Comments Inline

On Tue, 2011-12-06 at 21:18 +1100, Geoff O'Callaghan wrote:
> On Thu, 2011-12-01 at 09:32 -0500, Perry Myers wrote: 
> > the Node development team has been trying to write up rough requirements
> > around the stateless and plugins concepts.  And also some working high
> > level design.
> > 
> > They can be reviewed on these two wiki pages:
> > 
> > http://ovirt.org/wiki/Node_plugins
> > http://ovirt.org/wiki/Node_Stateless
> > 
> > Since the plugin model and the stateless model affect more than just the
> > oVirt Node itself, we definitely would like to get input from other
> > teams on the oVirt project.
> > 
> > Please add comments here or directly to the wiki.
> > 
> 
> Hi There
> 
> I work for a *large* organisation, I have issues with the goal of a
> stateless design.

Thanks for the feedback overall.  I'll try to address all your points
below.

> 
> * Being able to install without a local disk
> 
> I don't see this as a compelling reason for doing anything.   In fact,
> in many cases for other nameless hypervisors we use local disk as a
> source for logging / dumps etc.

That may be the case in your environment, but when we presented this at
the oVirt Workshop, the idea of a diskless deployment was very well
received.  I suppose that what we're calling stateless is really more of
a diskless feature rather than truly stateless since we're keeping the
stateful information in a configuration server.

> 
> I think the goal for stateless should be instead be configuration
> neutral.  ie.  if the node is destroyed the configuration can be
> re-deployed without issue.

Redeployed on the same machine?  Or redeployed on a different machine?
We already provide autoinstallation options that will do redeployments
easily and one of the goals or ideas along with the proposed stateless
model is that the machine gets re-provisioned and downloads its config
bundle.  This would successfully recover the node if someone were to
power it off or destroy it somehow.  If you're looking to move the
config to a new machine, then that's not quite as simple.  The easiest
would be to simply install it again from scratch.

> 
> The other issue is that the node should continue to be re-bootable even
> if the configuration server is unavailable, which is a reason for having
> the configuration on a local disk or a san attached LUN.   This should
> apply to the entire operational environment - if the engine is
> unavailable during a restart I should continue working the way I was
> configured to do so - that implies state is retained.  It needs to be
> easily refreshable :-)

I will admit that the thought of the config server being unavailable
hadn't come up previously.  If this is something that you're
legitimately concerned about, then it sounds like you'd want to continue
doing local installations and not stateless installs.

Currently, node images will install to local disk and they will boot
fine without a management server or config server.  But they won't be
truly functional unless there is a management server available to tell
it what to do.  This is the case for all hypervisors, whether they're
ovirt-node images or Fedora 16 images with VDSM installed or any of the
other distributions.  It's a limitation the VDSM and Engine need to
solve outside the scope of ovirt-node.
> 
> The configuration bundle should be refreshable from a configuration
> server (part of the engine) and that could either be just configuration
> or agents or even s/w images - all would be preferred and it's pretty
> simple conceptually to have an active/backup image on local disk concept
> to allow easy rollbacks etc.  Yes all this , except for the logging /
> swap could be in a usb key.

We do provide a RootBackup partition that we automatically activate if
something goes wrong with an upgrade.  It would make sense that we
should keep a backup configuration bundle on the management server as
well.  The actual image itself is a livecd, so updating that would be a
matter of changing the usb stick/cd-rom/pxe image to the old/new version

> 
> The bundle should all be pushed via a SSL encrypted RESTful api using
> known non-priv credentials, preferably with rotating passwords or some
> cert based approach.   The server should also know who previously
> managed it to reduce hostile attempts to change ownership of the node.

Yes, the security issues are something that we're definitely aware of
and not taking lightly.  The actual process for how we do this is
something that still would need to be worked out.  The initial design
was something along the lines of a free posting to the config server
that the admin has to approve.  The thought was that we would have
different levels of security that could be configured depending on your
deployment and the strictness of the rules in your environment.

> 
> * DHCP and PXE booting
> 
> Many corporate security policies prohibit the use of DHCP or PXE booting
> servers for production environments.   I don't see it as a big issue to
> boot an install image and be a good woodpecker and hit enter a few times
> and configure a management IP address.   It should be possible to script
> the complete configuration / addition of the node after that step.   I
> see the initial install as a trivial part of the complete node
> lifecycle.

So a couple thoughts here:

1.  If only pxe is restricted, then you could have a usb stick or cd-rom
with the image in each machine and still do stateless as defined
otherwise.
2.  If just DHCP, then you could have a pxe profile per machine that
sets up the static networking options needed
3.  If both are restricted, then you would have to go with a stateful
installation.  It's not going away, just another mode that we will
provide.

Actual installation and configuration can be completed automatically
using kernel command line options.  That is independent of whether
you're using a stateful or stateless installation.

>   
> * DNS SRV records
> 
> Sorry,  I hate the idea.  Large corporates have so many different teams
> doing little things that adding this in as a requirement simply adds
> delays to the deployments and opportunities for misconfiguration.

Sure, that's a valid possibility.  Perhaps another commandline option
that allows someone to specify the config server manually.

> 
> Having the node image and config on local disk (or usb) avoids this
> requirement as the node knows who manages it.   A complete rebuild could
> occur and the configuration reloaded once added back into the engine.

Yes, this is a valid use case.  And if that's the way you want to deploy
your environment, then use the install to disk option and not stateless.
We will provide both

> 
> * Previously configured state
> 
> Yes,  the node should remember the previous operational state if it
> can't talk to the engine.   This is not a bad thing.   
> 
> *  Configuration server
> 
> This should be part of the engine.   It should know the complete
> configuration of a node, right down to hypervisor 'firmware' image.  The
> process should be 2-way.  An admin should be able to 'pull' the
> image/config from an operational and accessible node and new
> configurations/images should be pushable to it.
> 
> I really don't think this needs to be a separate server to the engine.

I agree, it should be part of the engine, probably will be.  Depending
on time frames and availability, it might be developed separate
initially, but long term we probably want to integrate with the
management server.
> 
> *  New bundle deployments / Upgrades
> 
> The engine should keep track of what images are on a node.   If a new
> config / image is to be deployed then for example, the node would be
> tagged with the new image.  If the node was online, an alternate image
> would be pushed, vm's migrated to an alternate node and the node
> restarted implementing the new image when requested.

This is mostly already done, I think.  I know the functionality is there
in RHEV-M, but not sure if it's all in the webadmin UI yet.  I know the
backend pieces are all there though.

A running node has it's version info that vdsm reads initially and
reports back to the engine.  An admin logs into the engine, and can see
the details of the node including the version that it's currently
running.  There is an option to push out a new image to the node and
have it upgrade itself.  The node does have to be in maintenance mode to
start the process which causes all VMs to be migrated away.  

> 
> If the node was offline at the time the new image was configured in the
> engine or if the node was built say with an old image then when it
> connects to the engine the image would be refreshed and the node
> recycled.

Automatic upgrades like this aren't done at the moment.  There probably
needs to be some policy engine that can control it so all machines don't
suddenly try to upgrade themselves.  

This whole section really applies to stateful installations though.  In
Stateless, you just need to refresh the image in the PXE
server/cd-rom/usb stick and reboot the machine (after putting it in
maintenance mode)

> 
> * Swap
> 
> Local disk swap is likely to be required.  Overcommit is common and SSD
> local disk is something that is quite useful :-)

I agree, in general.  I did talk to one person at the workshop that had
a machine with 300+GB RAM and had 0 interest in doing overcommit.  So
there is certainly a use case for being able to support both.  

> 
> So in summary,  I prefer to think that the target should be
> configuration neutrality or even just plain old distributed
> configuration from a central source rather than completely stateless.
> The goal should be toleration of complete destruction of a node image
> and configuration and a simple process to re-add it and automatically
> re-apply the configuration/sw image.

I like the thought of storing the configuration to a central location
even when having the image installed locally.  I definitely think there
will be people that can't or won't go with stateless for various reasons
many of which you state above.  But I also think there are some that
will want it as well.  

The simplest use case for wanting a stateless model like we designed is
someone that has a rack of blades without local disks.  The setup pxe
and dhcp, and just turn on the blades.

Mike
> 
> Just some thoughts for discussion / abuse ;-)
> 
> Tks
> Geoff
> 
> > Cheers,
> > 
> > Perry
> > _______________________________________________
> > 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 pmyers at redhat.com  Tue Dec  6 14:11:38 2011
From: pmyers at redhat.com (Perry Myers)
Date: Tue, 06 Dec 2011 09:11:38 -0500
Subject: [node-devel] oVirt Node designs for stateless operation and 3rd
	party plugins
In-Reply-To: <1323166736.10490.46.camel@mrpointy>
References: <4ED79010.8060202@redhat.com> <1323166736.10490.46.camel@mrpointy>
Message-ID: <4EDE229A.5090306@redhat.com>

Hi Geoff,

Thanks for weighing in on this.  Let me preface my comments below by
saying that I think by and large we're on the same page with the
design/intent of stateless here.  I just think you may have some
confusion about terminology and what stateless will imply/not imply for
the end user.  I'll try to clarify below so that we can get on the same
page.

On 12/06/2011 05:18 AM, Geoff O'Callaghan wrote:
> On Thu, 2011-12-01 at 09:32 -0500, Perry Myers wrote: 
>> the Node development team has been trying to write up rough requirements
>> around the stateless and plugins concepts.  And also some working high
>> level design.
>>
>> They can be reviewed on these two wiki pages:
>>
>> http://ovirt.org/wiki/Node_plugins
>> http://ovirt.org/wiki/Node_Stateless
>>
>> Since the plugin model and the stateless model affect more than just the
>> oVirt Node itself, we definitely would like to get input from other
>> teams on the oVirt project.
>>
>> Please add comments here or directly to the wiki.
>>
> 
> Hi There
> 
> I work for a *large* organisation, I have issues with the goal of a
> stateless design.
> 
> * Being able to install without a local disk
> 
> I don't see this as a compelling reason for doing anything.   In fact,
> in many cases for other nameless hypervisors we use local disk as a
> source for logging / dumps etc.

This feature doesn't mandate that a local disk not be present.  In fact,
we must support using the local disk for things like swap and kernel
dumps as you mention.

Not sure why you thought stateless required no local disk... It's purely
one of many deployment options.

i.e. you could do:

stateless w/ no local disk
stateless w/ local disk for swap/kdump etc

> I think the goal for stateless should be instead be configuration
> neutral.  ie.  if the node is destroyed the configuration can be
> re-deployed without issue.

That is the goal

> The other issue is that the node should continue to be re-bootable even
> if the configuration server is unavailable, which is a reason for having
> the configuration on a local disk or a san attached LUN.   This should
> apply to the entire operational environment - if the engine is
> unavailable during a restart I should continue working the way I was
> configured to do so - that implies state is retained.  It needs to be
> easily refreshable :-)

The Config Server != oVirt Engine Server.  They are two separate servers.

I agree that in the event of the config server being down, you cannot
boot the oVirt Node.  However, a common deployment scenario is using PXE
to boot the node and this already suffers from this drawback and people
do seem comfortable with that scenario.

Basically, 'stateless' is an option, not a mandate.

If you want/need to continue to persist local config data on the Node,
we're not going to prevent that.  We're just adding an option to allow
people to use a centralized config server with the option of no local disks.

Adding this option won't prevent you from still doing a stateful
install, so I don't think this feature conflicts with your requirements.

> The configuration bundle should be refreshable from a configuration
> server (part of the engine) and that could either be just configuration
> or agents or even s/w images - all would be preferred and it's pretty
> simple conceptually to have an active/backup image on local disk concept
> to allow easy rollbacks etc.  Yes all this , except for the logging /
> swap could be in a usb key.
> 
> The bundle should all be pushed via a SSL encrypted RESTful api using
> known non-priv credentials, preferably with rotating passwords or some
> cert based approach.   The server should also know who previously
> managed it to reduce hostile attempts to change ownership of the node.
> 
> * DHCP and PXE booting
> 
> Many corporate security policies prohibit the use of DHCP or PXE booting
> servers for production environments.   I don't see it as a big issue to
> boot an install image and be a good woodpecker and hit enter a few times
> and configure a management IP address.   It should be possible to script
> the complete configuration / addition of the node after that step.   I
> see the initial install as a trivial part of the complete node
> lifecycle.

You are correct.  Many do prohibit this, but many don't.  So as stated
above, we'll allow both boot from USB key, local disk and PXE.  We
already do this today.

> * DNS SRV records
> 
> Sorry,  I hate the idea.  Large corporates have so many different teams
> doing little things that adding this in as a requirement simply adds
> delays to the deployments and opportunities for misconfiguration.

Sorry that you hate the idea.  Others like it, so we'll provide it as an
option.  Again, we're not _mandating_ the usage of DNS SRV, we're
providing it as an option.  If you want, you can certainly manually
configure every Node in your datacenter.

Using things like DHCP and DNS SRV help with automating large
deployments, but we certainly won't require their usage for those that
wish to have more control over every Node's configuration.

> Having the node image and config on local disk (or usb) avoids this
> requirement as the node knows who manages it.   A complete rebuild could
> occur and the configuration reloaded once added back into the engine.

We'll continue allowing local disk usage for config.  No plans to remove
this as an install option.

> * Previously configured state
> 
> Yes,  the node should remember the previous operational state if it
> can't talk to the engine.   This is not a bad thing.   
> 
> *  Configuration server
> 
> This should be part of the engine.   It should know the complete
> configuration of a node, right down to hypervisor 'firmware' image.  The
> process should be 2-way.  An admin should be able to 'pull' the
> image/config from an operational and accessible node and new
> configurations/images should be pushable to it.

It will be collocated with the Engine, but we will design it in such a
way that it can be run independently from the oVirt Engine.  There are
several reasons for this:

1. re-usability outside of the oVirt context
2. scaling multiple config servers for different areas of the datacenter
3. perhaps one part of the datacenter is comfortable using a config
   server and another is not.  You could co-locate the config server
   with the portion of Nodes that are using DNS SRV/DHCP, etc and keep
   them physically separate from the Nodes that are using static config
   and local disks for configuration

Keep in mind that most of the Node configuration is _already_ done by
oVirt Engine (advanced storage config, network config, vm information).
 The only thing that this config server will need to store are:

* config of the mgmt network interface
* config of vdsm so that the Node can talk back to the oVirt Engine
* config of the local passwd file

Most everything else can/is applied dynamically by oVirt Engine sending
config to vdsm.  So this config server really is just bootstrapping for
the basic stuff, and we let the oVirt Engine handle everything else more
complex.

> I really don't think this needs to be a separate server to the engine.

Noted.  I'd be interested to see if others have an opinion here.

> *  New bundle deployments / Upgrades
> 
> The engine should keep track of what images are on a node.   If a new
> config / image is to be deployed then for example, the node would be
> tagged with the new image.  If the node was online, an alternate image
> would be pushed, vm's migrated to an alternate node and the node
> restarted implementing the new image when requested.

Engine already does this.  It knows which version of oVirt Node ISO has
been pushed to each node in the datacenter.  That is also how it knows
when a Node is eligible for an upgrade.

> If the node was offline at the time the new image was configured in the
> engine or if the node was built say with an old image then when it
> connects to the engine the image would be refreshed and the node
> recycled.
> 
> * Swap
> 
> Local disk swap is likely to be required.  Overcommit is common and SSD
> local disk is something that is quite useful :-)

Yes, please read the wiki where it says:

> In order to overcommit a host, you need to have swap space to support it
> First implementation will probably disable swap
> Future implementation may allow the system to configure a local disk as swap space

So yes, the plan is to allow swap even during stateless operation if the
administrator chooses to do so.

> So in summary,  I prefer to think that the target should be
> configuration neutrality or even just plain old distributed
> configuration from a central source rather than completely stateless.

You're confusing stateless with diskless.

Stateless is configuration neutrality.  Nowhere in the wiki does it
imply that we must be diskless

> The goal should be toleration of complete destruction of a node image
> and configuration and a simple process to re-add it and automatically
> re-apply the configuration/sw image.

Agreed, and that is indeed the intent of this design

> Just some thoughts for discussion / abuse ;-)

Thanks for the feedback.  I think roughly speaking we are on the same
page.  It just seems like perhaps the wiki made you think we required
diskless and PXE/DNS SRV vs. making those things options that the
administrator could choose or reject as a deployment detail.

I think the only area of contention is whether or not the Config Server
should be integral with oVirt Engine, and on that point I think we can
discuss further.  But please keep in mind that this Config Engine is for
the bare minimum config info and anything more complex will be coming
from the oVirt Engine server via vdsm anyhow.  I think if you limit the
scope of the Config Server to be that, it is more reasonable to make it
a standalone/separate component

Perhaps to make it less confusing we should call it the "Bootstrap
Server" since it won't be a true "Config Server" since it only has
bootstrap config information to allow the Node to get add'l config from
the oVirt Engine via vdsm

Perry


From mburns at redhat.com  Tue Dec  6 14:26:29 2011
From: mburns at redhat.com (Mike Burns)
Date: Tue, 06 Dec 2011 09:26:29 -0500
Subject: [node-devel] oVirt Node designs for stateless operation and 3rd
 party plugins
In-Reply-To: <1323179572.3915.124.camel@beelzebub.mburnsfire.net>
References: <4ED79010.8060202@redhat.com> <1323166736.10490.46.camel@mrpointy>
	<1323179572.3915.124.camel@beelzebub.mburnsfire.net>
Message-ID: <1323181589.3915.127.camel@beelzebub.mburnsfire.net>

On Tue, 2011-12-06 at 08:52 -0500, Mike Burns wrote:
> Comments Inline
> 
> On Tue, 2011-12-06 at 21:18 +1100, Geoff O'Callaghan wrote:
> > On Thu, 2011-12-01 at 09:32 -0500, Perry Myers wrote: 
> > > the Node development team has been trying to write up rough requirements
> > > around the stateless and plugins concepts.  And also some working high
> > > level design.
> > > 
> > > They can be reviewed on these two wiki pages:
> > > 
> > > http://ovirt.org/wiki/Node_plugins
> > > http://ovirt.org/wiki/Node_Stateless
> > > 
> > > Since the plugin model and the stateless model affect more than just the
> > > oVirt Node itself, we definitely would like to get input from other
> > > teams on the oVirt project.
> > > 
> > > Please add comments here or directly to the wiki.
> > > 
> > 
> > Hi There
> > 
> > I work for a *large* organisation, I have issues with the goal of a
> > stateless design.
> 
> Thanks for the feedback overall.  I'll try to address all your points
> below.
> 
> > 
> > * Being able to install without a local disk
> > 
> > I don't see this as a compelling reason for doing anything.   In fact,
> > in many cases for other nameless hypervisors we use local disk as a
> > source for logging / dumps etc.
> 
> That may be the case in your environment, but when we presented this at
> the oVirt Workshop, the idea of a diskless deployment was very well
> received.  

> I suppose that what we're calling stateless is really more of
> a diskless feature rather than truly stateless since we're keeping the
> stateful information in a configuration server.

This is actually not correct.  My mind was just caught up in thinking of
a totally diskless system.  What Perry said is correct.  We're looking
to move all configuration to a central location (configuration
neutrality).  Disk would then become optional for things like swap
and/or kdump, etc.

> 
> > 
> > I think the goal for stateless should be instead be configuration
> > neutral.  ie.  if the node is destroyed the configuration can be
> > re-deployed without issue.
> 
> Redeployed on the same machine?  Or redeployed on a different machine?
> We already provide autoinstallation options that will do redeployments
> easily and one of the goals or ideas along with the proposed stateless
> model is that the machine gets re-provisioned and downloads its config
> bundle.  This would successfully recover the node if someone were to
> power it off or destroy it somehow.  If you're looking to move the
> config to a new machine, then that's not quite as simple.  The easiest
> would be to simply install it again from scratch.
> 
> > 
> > The other issue is that the node should continue to be re-bootable even
> > if the configuration server is unavailable, which is a reason for having
> > the configuration on a local disk or a san attached LUN.   This should
> > apply to the entire operational environment - if the engine is
> > unavailable during a restart I should continue working the way I was
> > configured to do so - that implies state is retained.  It needs to be
> > easily refreshable :-)
> 
> I will admit that the thought of the config server being unavailable
> hadn't come up previously.  If this is something that you're
> legitimately concerned about, then it sounds like you'd want to continue
> doing local installations and not stateless installs.
> 
> Currently, node images will install to local disk and they will boot
> fine without a management server or config server.  But they won't be
> truly functional unless there is a management server available to tell
> it what to do.  This is the case for all hypervisors, whether they're
> ovirt-node images or Fedora 16 images with VDSM installed or any of the
> other distributions.  It's a limitation the VDSM and Engine need to
> solve outside the scope of ovirt-node.
> > 
> > The configuration bundle should be refreshable from a configuration
> > server (part of the engine) and that could either be just configuration
> > or agents or even s/w images - all would be preferred and it's pretty
> > simple conceptually to have an active/backup image on local disk concept
> > to allow easy rollbacks etc.  Yes all this , except for the logging /
> > swap could be in a usb key.
> 
> We do provide a RootBackup partition that we automatically activate if
> something goes wrong with an upgrade.  It would make sense that we
> should keep a backup configuration bundle on the management server as
> well.  The actual image itself is a livecd, so updating that would be a
> matter of changing the usb stick/cd-rom/pxe image to the old/new version
> 
> > 
> > The bundle should all be pushed via a SSL encrypted RESTful api using
> > known non-priv credentials, preferably with rotating passwords or some
> > cert based approach.   The server should also know who previously
> > managed it to reduce hostile attempts to change ownership of the node.
> 
> Yes, the security issues are something that we're definitely aware of
> and not taking lightly.  The actual process for how we do this is
> something that still would need to be worked out.  The initial design
> was something along the lines of a free posting to the config server
> that the admin has to approve.  The thought was that we would have
> different levels of security that could be configured depending on your
> deployment and the strictness of the rules in your environment.
> 
> > 
> > * DHCP and PXE booting
> > 
> > Many corporate security policies prohibit the use of DHCP or PXE booting
> > servers for production environments.   I don't see it as a big issue to
> > boot an install image and be a good woodpecker and hit enter a few times
> > and configure a management IP address.   It should be possible to script
> > the complete configuration / addition of the node after that step.   I
> > see the initial install as a trivial part of the complete node
> > lifecycle.
> 
> So a couple thoughts here:
> 
> 1.  If only pxe is restricted, then you could have a usb stick or cd-rom
> with the image in each machine and still do stateless as defined
> otherwise.
> 2.  If just DHCP, then you could have a pxe profile per machine that
> sets up the static networking options needed
> 3.  If both are restricted, then you would have to go with a stateful
> installation.  It's not going away, just another mode that we will
> provide.
> 
> Actual installation and configuration can be completed automatically
> using kernel command line options.  That is independent of whether
> you're using a stateful or stateless installation.
> 
> >   
> > * DNS SRV records
> > 
> > Sorry,  I hate the idea.  Large corporates have so many different teams
> > doing little things that adding this in as a requirement simply adds
> > delays to the deployments and opportunities for misconfiguration.
> 
> Sure, that's a valid possibility.  Perhaps another commandline option
> that allows someone to specify the config server manually.
> 
> > 
> > Having the node image and config on local disk (or usb) avoids this
> > requirement as the node knows who manages it.   A complete rebuild could
> > occur and the configuration reloaded once added back into the engine.
> 
> Yes, this is a valid use case.  And if that's the way you want to deploy
> your environment, then use the install to disk option and not stateless.
> We will provide both
> 
> > 
> > * Previously configured state
> > 
> > Yes,  the node should remember the previous operational state if it
> > can't talk to the engine.   This is not a bad thing.   
> > 
> > *  Configuration server
> > 
> > This should be part of the engine.   It should know the complete
> > configuration of a node, right down to hypervisor 'firmware' image.  The
> > process should be 2-way.  An admin should be able to 'pull' the
> > image/config from an operational and accessible node and new
> > configurations/images should be pushable to it.
> > 
> > I really don't think this needs to be a separate server to the engine.
> 
> I agree, it should be part of the engine, probably will be.  Depending
> on time frames and availability, it might be developed separate
> initially, but long term we probably want to integrate with the
> management server.
> > 
> > *  New bundle deployments / Upgrades
> > 
> > The engine should keep track of what images are on a node.   If a new
> > config / image is to be deployed then for example, the node would be
> > tagged with the new image.  If the node was online, an alternate image
> > would be pushed, vm's migrated to an alternate node and the node
> > restarted implementing the new image when requested.
> 
> This is mostly already done, I think.  I know the functionality is there
> in RHEV-M, but not sure if it's all in the webadmin UI yet.  I know the
> backend pieces are all there though.
> 
> A running node has it's version info that vdsm reads initially and
> reports back to the engine.  An admin logs into the engine, and can see
> the details of the node including the version that it's currently
> running.  There is an option to push out a new image to the node and
> have it upgrade itself.  The node does have to be in maintenance mode to
> start the process which causes all VMs to be migrated away.  
> 
> > 
> > If the node was offline at the time the new image was configured in the
> > engine or if the node was built say with an old image then when it
> > connects to the engine the image would be refreshed and the node
> > recycled.
> 
> Automatic upgrades like this aren't done at the moment.  There probably
> needs to be some policy engine that can control it so all machines don't
> suddenly try to upgrade themselves.  
> 
> This whole section really applies to stateful installations though.  In
> Stateless, you just need to refresh the image in the PXE
> server/cd-rom/usb stick and reboot the machine (after putting it in
> maintenance mode)
> 
> > 
> > * Swap
> > 
> > Local disk swap is likely to be required.  Overcommit is common and SSD
> > local disk is something that is quite useful :-)
> 
> I agree, in general.  I did talk to one person at the workshop that had
> a machine with 300+GB RAM and had 0 interest in doing overcommit.  So
> there is certainly a use case for being able to support both.  
> 
> > 
> > So in summary,  I prefer to think that the target should be
> > configuration neutrality or even just plain old distributed
> > configuration from a central source rather than completely stateless.
> > The goal should be toleration of complete destruction of a node image
> > and configuration and a simple process to re-add it and automatically
> > re-apply the configuration/sw image.
> 
> I like the thought of storing the configuration to a central location
> even when having the image installed locally.  I definitely think there
> will be people that can't or won't go with stateless for various reasons
> many of which you state above.  But I also think there are some that
> will want it as well.  
> 
> The simplest use case for wanting a stateless model like we designed is
> someone that has a rack of blades without local disks.  The setup pxe
> and dhcp, and just turn on the blades.
> 
> Mike
> > 
> > Just some thoughts for discussion / abuse ;-)
> > 
> > Tks
> > Geoff
> > 
> > > Cheers,
> > > 
> > > Perry
> > > _______________________________________________
> > > 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
> 
> 
> _______________________________________________
> node-devel mailing list
> node-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/node-devel




From shuming at linux.vnet.ibm.com  Thu Dec  8 13:56:41 2011
From: shuming at linux.vnet.ibm.com (Shu Ming)
Date: Thu, 08 Dec 2011 21:56:41 +0800
Subject: [node-devel] ovirt node installation on x64 servers
Message-ID: <4EE0C219.9020204@linux.vnet.ibm.com>

Hi,
   We built a ovirt-node iso image to install on a x64 server.  And the 
iso image can be installed with successful message in the end.  But, the 
installed ovirt-node can not be booted from the disk directly.  With a 
help from ovirt-node CD and changing the grub boot parameters from 
"live:CDLABLE=xxxxxxx" to "live:LABEL=Root",  ovirt-node can be booted 
from the hard disk.  It is annoying to use an additional CD to boot 
ovirt-node from the target disk.  How can I check if the boot code is 
installed correctly on the hard disk?  And how can I make the hard disk 
boot-able without a CDROM?

-- 
Shu Ming<shuming at linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory




From mburns at redhat.com  Thu Dec  8 14:54:09 2011
From: mburns at redhat.com (Mike Burns)
Date: Thu, 08 Dec 2011 09:54:09 -0500
Subject: [node-devel] ovirt node installation on x64 servers
In-Reply-To: <4EE0C219.9020204@linux.vnet.ibm.com>
References: <4EE0C219.9020204@linux.vnet.ibm.com>
Message-ID: <1323356049.12161.3.camel@beelzebub.mburnsfire.net>

On Thu, 2011-12-08 at 21:56 +0800, Shu Ming wrote:
> Hi,
>    We built a ovirt-node iso image to install on a x64 server.  And the 
> iso image can be installed with successful message in the end.  But, the 
> installed ovirt-node can not be booted from the disk directly.  With a 
> help from ovirt-node CD and changing the grub boot parameters from 
> "live:CDLABLE=xxxxxxx" to "live:LABEL=Root",  ovirt-node can be booted 
> from the hard disk.  It is annoying to use an additional CD to boot 
> ovirt-node from the target disk.  How can I check if the boot code is 
> installed correctly on the hard disk?  And how can I make the hard disk 
> boot-able without a CDROM?
> 

What type of server are you installing on?  Is it a UEFI system?  If so,
can it boot with the Legacy Mode boot device?

If your system is not UEFI, then can you send the ovirt.log file from
the running system?

Thanks

Mike



From iheim at redhat.com  Thu Dec  8 15:33:55 2011
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 08 Dec 2011 17:33:55 +0200
Subject: [node-devel] oVirt Node designs for stateless operation and 3rd
	party plugins
In-Reply-To: <4EDE229A.5090306@redhat.com>
References: <4ED79010.8060202@redhat.com> <1323166736.10490.46.camel@mrpointy>
	<4EDE229A.5090306@redhat.com>
Message-ID: <4EE0D8E3.6030903@redhat.com>

On 12/06/2011 04:11 PM, Perry Myers wrote:
> Hi Geoff,
>
> Thanks for weighing in on this.  Let me preface my comments below by
> saying that I think by and large we're on the same page with the
> design/intent of stateless here.  I just think you may have some
> confusion about terminology and what stateless will imply/not imply for
> the end user.  I'll try to clarify below so that we can get on the same
> page.

+1 - thanks for the input and insights.
one more point below
...

>> *  Configuration server
>>
>> This should be part of the engine.   It should know the complete
>> configuration of a node, right down to hypervisor 'firmware' image.  The
>> process should be 2-way.  An admin should be able to 'pull' the
>> image/config from an operational and accessible node and new
>> configurations/images should be pushable to it.
>
> It will be collocated with the Engine, but we will design it in such a
> way that it can be run independently from the oVirt Engine.  There are
> several reasons for this:
>
> 1. re-usability outside of the oVirt context
> 2. scaling multiple config servers for different areas of the datacenter
> 3. perhaps one part of the datacenter is comfortable using a config
>     server and another is not.  You could co-locate the config server
>     with the portion of Nodes that are using DNS SRV/DHCP, etc and keep
>     them physically separate from the Nodes that are using static config
>     and local disks for configuration
>
> Keep in mind that most of the Node configuration is _already_ done by
> oVirt Engine (advanced storage config, network config, vm information).
>   The only thing that this config server will need to store are:
>
> * config of the mgmt network interface
> * config of vdsm so that the Node can talk back to the oVirt Engine
> * config of the local passwd file
>
> Most everything else can/is applied dynamically by oVirt Engine sending
> config to vdsm.  So this config server really is just bootstrapping for
> the basic stuff, and we let the oVirt Engine handle everything else more
> complex.
>
>> I really don't think this needs to be a separate server to the engine.
>
> Noted.  I'd be interested to see if others have an opinion here.

I understand deploying config as a separate service than the engine, but 
can it optionally use the engine to get what it need to avoid the need 
for an extra db to sync/upgrade/etc.
a deployment in a remote site could cache the information to provide it 
in case the engine is not responding (so the node can finish booting to 
be used by the engine next time it is running).

so you could configure it to use a local store, but in a ovirt-engine 
deployment it would just be a service focusing on the relevant 
communication method and delivery of image if needed.

I think that would make deployment/life cycle management much easier.


From shuming at linux.vnet.ibm.com  Fri Dec  9 01:10:44 2011
From: shuming at linux.vnet.ibm.com (Shu Ming)
Date: Fri, 09 Dec 2011 09:10:44 +0800
Subject: [node-devel] ovirt node installation on x64 servers
In-Reply-To: <1323356049.12161.3.camel@beelzebub.mburnsfire.net>
References: <4EE0C219.9020204@linux.vnet.ibm.com>
	<1323356049.12161.3.camel@beelzebub.mburnsfire.net>
Message-ID: <4EE16014.4020808@linux.vnet.ibm.com>

On 2011-12-8 22:54, Mike Burns wrote:
> On Thu, 2011-12-08 at 21:56 +0800, Shu Ming wrote:
>> Hi,
>>     We built a ovirt-node iso image to install on a x64 server.  And the
>> iso image can be installed with successful message in the end.  But, the
>> installed ovirt-node can not be booted from the disk directly.  With a
>> help from ovirt-node CD and changing the grub boot parameters from
>> "live:CDLABLE=xxxxxxx" to "live:LABEL=Root",  ovirt-node can be booted
>> from the hard disk.  It is annoying to use an additional CD to boot
>> ovirt-node from the target disk.  How can I check if the boot code is
>> installed correctly on the hard disk?  And how can I make the hard disk
>> boot-able without a CDROM?
>>
> What type of server are you installing on?  Is it a UEFI system?  If so,
> can it boot with the Legacy Mode boot device?

Unfortunately, it is UEFI.

>
> If your system is not UEFI, then can you send the ovirt.log file from
> the running system?
>
> Thanks
>
> Mike
>


-- 
Shu Ming<shuming at linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory




From mburns at redhat.com  Mon Dec 12 14:44:18 2011
From: mburns at redhat.com (Mike Burns)
Date: Mon, 12 Dec 2011 09:44:18 -0500
Subject: [node-devel] oVirt Node Weekly Meeting minutes 2011-12-08
Message-ID: <1323701058.12161.45.camel@beelzebub.mburnsfire.net>

Minutes:
http://ovirt.org/meetings/ovirt/2011/ovirt.2011-12-08-14.00.html
Minutes (text):
http://ovirt.org/meetings/ovirt/2011/ovirt.2011-12-08-14.00.txt
Log:
http://ovirt.org/meetings/ovirt/2011/ovirt.2011-12-08-14.00.log.html


Action items, by person
     1. dougsland
             1. dougsland to continue working on vdsm patches for
                registration and node/engine interoperability
             2. dougsland to provide info on the thread discussing /rhev
                vs. /ovirt
             3. dougsland to take conversation to vdsm-devel
     2. jboggs
             1. jboggs to continue updating plugin design
     3. mburns
             1. mburns to send out release notice
             2. mburns investigate branching for first release early so
                dev can proceed with 2.3.0 fixes
             3. mburns to continue updating stateless design

Thanks

Mike
-- 
Michael Burns
Software Engineer
Red Hat
mburns at redhat.com



From mburns at redhat.com  Mon Dec 12 15:19:22 2011
From: mburns at redhat.com (Mike Burns)
Date: Mon, 12 Dec 2011 10:19:22 -0500
Subject: [node-devel] ovirt-node 2.2.0 Released
Message-ID: <1323703162.12161.53.camel@beelzebub.mburnsfire.net>

I'm happy to announce that ovirt-node packages and iso image [1] for
version 2.2 are now available on ovirt.org.

Changes from 2.1.0:

- A lot of changes to make it work with Fedora 16
- finish migration to python scripts for autoinstall
- some changes to support ovirt-engine


Release Notes:

- engine registration does not work out of the box
  -- there are vdsm and engine fixes pending for this
- Booting on UEFI based hosts is not working
  -- Workaround is to use the legacy device boot target in the BIOS

http://ovirt.org/releases/stable/binary/ovirt-node-image-2.2.0-0.iso




From mburns at redhat.com  Thu Dec 15 14:44:38 2011
From: mburns at redhat.com (Mike Burns)
Date: Thu, 15 Dec 2011 09:44:38 -0500
Subject: [node-devel] oVirt Node Weekly Meeting 2011-12-15
Message-ID: <1323960278.12161.117.camel@beelzebub.mburnsfire.net>

Minutes:
http://ovirt.org/meetings/ovirt/2011/ovirt.2011-12-15-14.00.html
Minutes (text):
http://ovirt.org/meetings/ovirt/2011/ovirt.2011-12-15-14.00.txt
Log:
http://ovirt.org/meetings/ovirt/2011/ovirt.2011-12-15-14.00.log.html

Action items, by person
     1. jboggs
             1. jboggs working on uefi
             2. jboggs to start on implementing plugins after uefi is
                solved
     2. mburns
             1. mburns to follow up with dougsland on vdsm fixes for
                node/engine interaction
             2. mburns to re-run smoketesting with new 2.2.0 iso build
             3. mburns on real hardware issues
             4. dougsland on vdsm issues with mburns following up
             5. mburns to parse rhel 6 bugs for upstream inclusion
             6. mburns to review posted patches


Mike
-- 
Michael Burns
Software Engineer
Red Hat
mburns at redhat.com



From taget at linux.vnet.ibm.com  Wed Dec 21 07:47:57 2011
From: taget at linux.vnet.ibm.com (taget at linux.vnet.ibm.com)
Date: Wed, 21 Dec 2011 15:47:57 +0800
Subject: [node-devel] [PATCH] Add network configure in emergency shell
Message-ID: <1324453677-14915-1-git-send-email-taget@linux.vnet.ibm.com>

From: jimmy <taget at 163.com>

This patch is to configure networking before dropping in to emergency shell.
By doing this, user can using ssh to connect host server.

Signed-off-by: Eli <taget at vnet.linux.ibm.com>
---
 ovirt-firstboot |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/scripts/virt-firstboot b/scripts/ovirt-firstboot
index ef0a071..48f31e6 100755
--- a/scripts/ovirt-firstboot
+++ b/scripts/ovirt-firstboot
@@ -36,6 +36,9 @@ trap 'exit $?' 1 2 13 15
 autoinstall_failed(){
     log "Automatic installation failed. Please review console messages."
     log "Press Enter to drop to emergency shell."
+    /usr/libexec/ovirt-config-networking AUTO
+    log "Configure root password : "
+    /usr/bin/passwd
     read < /dev/console
     bash < /dev/console
 }
-- 
1.7.4.4



From simonjin at linux.vnet.ibm.com  Wed Dec 21 08:14:18 2011
From: simonjin at linux.vnet.ibm.com (simonjin)
Date: Wed, 21 Dec 2011 16:14:18 +0800
Subject: [node-devel] ovirt node installation on x64 servers
In-Reply-To: <4EE16014.4020808@linux.vnet.ibm.com>
References: <4EE0C219.9020204@linux.vnet.ibm.com>
	<1323356049.12161.3.camel@beelzebub.mburnsfire.net>
	<4EE16014.4020808@linux.vnet.ibm.com>
Message-ID: <4EF1955A.7040903@linux.vnet.ibm.com>

On 12/09/2011 09:10 AM, Shu Ming wrote:
> On 2011-12-8 22:54, Mike Burns wrote:
>> On Thu, 2011-12-08 at 21:56 +0800, Shu Ming wrote:
>>> Hi,
>>>     We built a ovirt-node iso image to install on a x64 server.  And 
>>> the
>>> iso image can be installed with successful message in the end.  But, 
>>> the
>>> installed ovirt-node can not be booted from the disk directly.  With a
>>> help from ovirt-node CD and changing the grub boot parameters from
>>> "live:CDLABLE=xxxxxxx" to "live:LABEL=Root",  ovirt-node can be booted
>>> from the hard disk.  It is annoying to use an additional CD to boot
>>> ovirt-node from the target disk.  How can I check if the boot code is
>>> installed correctly on the hard disk?  And how can I make the hard disk
>>> boot-able without a CDROM?
>>>
>> What type of server are you installing on?  Is it a UEFI system?  If so,
>> can it boot with the Legacy Mode boot device?
>
> Unfortunately, it is UEFI.
>
This is a known issue on UEFI:
https://bugzilla.redhat.com/show_bug.cgi?id=747102

>>
>> If your system is not UEFI, then can you send the ovirt.log file from
>> the running system?
>>
>> Thanks
>>
>> Mike
>>
>
>



From jboggs at redhat.com  Wed Dec 21 14:14:34 2011
From: jboggs at redhat.com (Joey Boggs)
Date: Wed, 21 Dec 2011 09:14:34 -0500
Subject: [node-devel] ovirt node installation on x64 servers
In-Reply-To: <4EF1955A.7040903@linux.vnet.ibm.com>
References: <4EE0C219.9020204@linux.vnet.ibm.com>
	<1323356049.12161.3.camel@beelzebub.mburnsfire.net>
	<4EE16014.4020808@linux.vnet.ibm.com>
	<4EF1955A.7040903@linux.vnet.ibm.com>
Message-ID: <4EF1E9CA.2030607@redhat.com>

On 12/21/2011 03:14 AM, simonjin wrote:
> On 12/09/2011 09:10 AM, Shu Ming wrote:
>> On 2011-12-8 22:54, Mike Burns wrote:
>>> On Thu, 2011-12-08 at 21:56 +0800, Shu Ming wrote:
>>>> Hi,
>>>>     We built a ovirt-node iso image to install on a x64 server.  
>>>> And the
>>>> iso image can be installed with successful message in the end.  
>>>> But, the
>>>> installed ovirt-node can not be booted from the disk directly.  With a
>>>> help from ovirt-node CD and changing the grub boot parameters from
>>>> "live:CDLABLE=xxxxxxx" to "live:LABEL=Root",  ovirt-node can be booted
>>>> from the hard disk.  It is annoying to use an additional CD to boot
>>>> ovirt-node from the target disk.  How can I check if the boot code is
>>>> installed correctly on the hard disk?  And how can I make the hard 
>>>> disk
>>>> boot-able without a CDROM?
>>>>
>>> What type of server are you installing on?  Is it a UEFI system?  If 
>>> so,
>>> can it boot with the Legacy Mode boot device?
>>
>> Unfortunately, it is UEFI.
>>
> This is a known issue on UEFI:
> https://bugzilla.redhat.com/show_bug.cgi?id=747102
>
>>>
>>> If your system is not UEFI, then can you send the ovirt.log file from
>>> the running system?
>>>
>>> Thanks
>>>
>>> Mike
>>>
>>
>>
>
> _______________________________________________
> node-devel mailing list
> node-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/node-devel

If you pull from the latest patches out of gerrit I've added some uefi 
installation bits. It works on usb, but I'm having issues verifying that 
it works on actual hard drives. Feel free to give it a shot at let me 
know if it works since it could just be the drives I'm testing with. For 
now the bootloader is placed in /EFI/BOOT/BOOTX64.EFI once further 
testing is completed with efibootmgr adding entries it will be updated.


From mburns at redhat.com  Wed Dec 21 14:41:27 2011
From: mburns at redhat.com (Mike Burns)
Date: Wed, 21 Dec 2011 09:41:27 -0500
Subject: [node-devel] [PATCH] Add network configure in emergency shell
In-Reply-To: <1324453677-14915-1-git-send-email-taget@linux.vnet.ibm.com>
References: <1324453677-14915-1-git-send-email-taget@linux.vnet.ibm.com>
Message-ID: <1324478487.12161.177.camel@beelzebub.mburnsfire.net>

Thanks for the patch.

Just so you're aware, the normal process for patch submissions is to
post patches to gerrit:

http://ovirt.org/wiki/Working_with_oVirt_Gerrit

It looks like you're working off a rather old version.  The
autoinstall_failed function was moved to ovirt-functions back in
September.

The current repo is at:  
Gitweb: http://gerrit.ovirt.org/gitweb?p=ovirt-node.git
giturl: http://gerrit.ovirt.org/p/ovirt-node.git

The actual commit that moved the function is here:

http://gerrit.ovirt.org/gitweb?p=ovirt-node.git;a=commit;h=a6f000ae812ee1ee4d762ba1f6c807968ac13170


Some initial comments on you're patch are below:

On Wed, 2011-12-21 at 15:47 +0800, taget at linux.vnet.ibm.com wrote:
> From: jimmy <taget at 163.com>
> 
> This patch is to configure networking before dropping in to emergency shell.
> By doing this, user can using ssh to connect host server.
> 
> Signed-off-by: Eli <taget at vnet.linux.ibm.com>
> ---
>  ovirt-firstboot |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/scripts/virt-firstboot b/scripts/ovirt-firstboot
> index ef0a071..48f31e6 100755
> --- a/scripts/ovirt-firstboot
> +++ b/scripts/ovirt-firstboot
> @@ -36,6 +36,9 @@ trap 'exit $?' 1 2 13 15
>  autoinstall_failed(){
>      log "Automatic installation failed. Please review console messages."
>      log "Press Enter to drop to emergency shell."
> +    /usr/libexec/ovirt-config-networking AUTO

Since changed to use python scripts instead of bash.  This should be
calling the network_auto function in network.py.  You can see how this
is called in ovirt-auto-install.py

> +    log "Configure root password : "
> +    /usr/bin/passwd

This will set the root password, but ssh password authentication is
disabled by default, so you need to enable that too.

>      read < /dev/console
>      bash < /dev/console
>  }


The overall concept of being able to ssh in when auto-installation fails
is good, but it's not solved completely here.  Assuming I understand
correctly, you're looking to be able to start the installation process
and then ssh in to debug it if/when it fails.  You're current patch
doesn't remove the need for console access since you need to be able to
type the password anyway to set it.

My recommendation would be to:

1.  get the updated repo
2.  work in ovirt-auto-install.py to configure networking in the else
condition
3.  use existing means to set passwords and ssh password authentication
        you can set root password with rootpw commandline option
        you can set admin password with adminpw commandline option
        you can enable ssh password auth with ssh_pwauth option
        These options are documented in ovirt-early where they're
        parsed.



From taget at linux.vnet.ibm.com  Thu Dec 22 06:41:18 2011
From: taget at linux.vnet.ibm.com (Eli Qiao)
Date: Thu, 22 Dec 2011 14:41:18 +0800
Subject: [node-devel] [PATCH] Add network configure in emergency shell
In-Reply-To: <1324478487.12161.177.camel@beelzebub.mburnsfire.net>
References: <1324453677-14915-1-git-send-email-taget@linux.vnet.ibm.com>
	<1324478487.12161.177.camel@beelzebub.mburnsfire.net>
Message-ID: <4EF2D10E.9080107@linux.vnet.ibm.com>



? 2011?12?21? 22:41, Mike Burns ??:
> Thanks for the patch.
>
> Just so you're aware, the normal process for patch submissions is to
> post patches to gerrit:
>
> http://ovirt.org/wiki/Working_with_oVirt_Gerrit
>
> It looks like you're working off a rather old version.  The
> autoinstall_failed function was moved to ovirt-functions back in
> September.
>
> The current repo is at:
> Gitweb: http://gerrit.ovirt.org/gitweb?p=ovirt-node.git
> giturl: http://gerrit.ovirt.org/p/ovirt-node.git
>
> The actual commit that moved the function is here:
>
> http://gerrit.ovirt.org/gitweb?p=ovirt-node.git;a=commit;h=a6f000ae812ee1ee4d762ba1f6c807968ac13170
>
>
> Some initial comments on you're patch are below:
>
> On Wed, 2011-12-21 at 15:47 +0800, taget at linux.vnet.ibm.com wrote:
>> From: jimmy<taget at 163.com>
>>
>> This patch is to configure networking before dropping in to emergency shell.
>> By doing this, user can using ssh to connect host server.
>>
>> Signed-off-by: Eli<taget at vnet.linux.ibm.com>
>> ---
>>   ovirt-firstboot |    3 +++
>>   1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/scripts/virt-firstboot b/scripts/ovirt-firstboot
>> index ef0a071..48f31e6 100755
>> --- a/scripts/ovirt-firstboot
>> +++ b/scripts/ovirt-firstboot
>> @@ -36,6 +36,9 @@ trap 'exit $?' 1 2 13 15
>>   autoinstall_failed(){
>>       log "Automatic installation failed. Please review console messages."
>>       log "Press Enter to drop to emergency shell."
>> +    /usr/libexec/ovirt-config-networking AUTO
> Since changed to use python scripts instead of bash.  This should be
> calling the network_auto function in network.py.  You can see how this
> is called in ovirt-auto-install.py
>
>> +    log "Configure root password : "
>> +    /usr/bin/passwd
> This will set the root password, but ssh password authentication is
> disabled by default, so you need to enable that too.
>
>>       read<  /dev/console
>>       bash<  /dev/console
>>   }
>
> The overall concept of being able to ssh in when auto-installation fails
> is good, but it's not solved completely here.  Assuming I understand
> correctly, you're looking to be able to start the installation process
> and then ssh in to debug it if/when it fails.  You're current patch
> doesn't remove the need for console access since you need to be able to
> type the password anyway to set it.
>
> My recommendation would be to:
>
> 1.  get the updated repo
> 2.  work in ovirt-auto-install.py to configure networking in the else
> condition
> 3.  use existing means to set passwords and ssh password authentication
>          you can set root password with rootpw commandline option
>          you can set admin password with adminpw commandline option
>          you can enable ssh password auth with ssh_pwauth option
>          These options are documented in ovirt-early where they're
>          parsed.
>
hi Mike,
I don't think add network configure and enable ssh password in the else 
condition is a good way , cause if so , the code is duplicated and ugly.


So , can we just configure networking and enable ssh password before we 
call storage_auto() ? By doing this , we could access the host even the 
automatic installation failed.
like this :

*in scripts/ovirt-auto-install.py*/
....
import os
import sys
from ovirtnode.ovirtfunctions import *
from ovirtnode.storage import *
from ovirtnode.install import *
from ovirtnode.network import *
from ovirtnode.log import *
from ovirtnode.kdump import *
from ovirtnode.snmp import *
from ovirt_config_setup.collectd import *

# store /etc/shadow if adminpw/rootpw are set, handled already in 
ovirt-early
     file = open("/proc/cmdline")
     args = file.read()
     if "adminpw" in args or "rootpw" in args:
         print "Storing /etc/shadow"
         ovirt_store_config("/etc/passwd")
         ovirt_store_config("/etc/shadow")
     file.close()
     # network configuration
     print "Configuring Network"
     if OVIRT_VARS["OVIRT_BOOTIF"] != "":
         network_auto()

     if OVIRT_VARS.has_key("OVIRT_HOSTNAME"):
         system("hostname %s" % OVIRT_VARS["OVIRT_HOSTNAME"])
     #set ssh_passwd_auth
     if OVIRT_VARS.has_key("OVIRT_SSH_PWAUTH"):
         if self.ssh_passwd_status.value() == 1:
             
augtool("set","/files/etc/ssh/sshd_config/PasswordAuthentication", "yes")
         elif self.ssh_passwd_status.value() == 0:
             
augtool("set","/files/etc/ssh/sshd_config/PasswordAuthentication", "no")/
/print "Performing automatic disk partitioning"/
/if storage_auto():
     # iscsi handled in install.py
     print "Configuring Logging"
     logging_auto()
     print "Configuring Collectd"
     collectd_auto()
     install = Install()
     print "Configuring KDump"
     kdump_auto()
     print "Configuring SNMP"
     snmp_auto()
     ... ...
else
     print "Automatic installation failed. Please review /tmp/ovirt.log"
     sys.exit(1)/

-- 
best regards
eli

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/node-devel/attachments/20111222/d9da3b34/attachment.html>