On 02/27/2012 05:06 AM, Ayal Baron wrote:
----- Original Message -----
Perry Myers píše v St 22. 02. 2012 v 11:54 -0500:
As answered in the other response, there are kernel command line parameters to set the management_server. Since this will likely be in a pxe environment, setting the pxe profile to include management_server=<engine_url> should be fine.
I agree it's a valid solution as long as you assume this is relevant for PXE only use case.
Not necessarily...
Take the ISO/USB Stick and you can embed the kargs into the ISO/USB itself so that it always boots with that mgmt server arg
This actually also enables use of 'stateless' combined with static IP addressing as well. As you can create a USB Stick and embed the kargs for the NIC configuration, rsyslog config, etc, etc.
Another solution could be to setup a specific DNS SRV record that points to the ovirt-engine and have node automatically query that for the location. This was discussed in the past and for some reason not implemented.
Concerns about security, iirc. Assumption that someone could hijack the DNS SRV record and provide a man-in-the-middle oVirt Engine server.
What about DNSSEC validation for DNS records in node?
This will require more than just changes to the registration process and it's quite difficult to track the required changes here on email. Let's setup a call to discuss this and try to capture the list of issues we already know about (I'm sure we'll discover more once we actually try to do this).
I'm fine with setting up a call as long as we publish the dial in info on list so that folks in the community can join in if they are interested. Also, stateless design has been a topic on the oVirt Node weekly IRC meeting for the last few weeks as we flesh out design issues, etc. I'd be happy for folks from other teams to join in there
To play devil's advocate though, I know there is interest, but I really don't understand the incentive. What is the *problem* you're trying to solve here (stateless is a solution)
The primary motivation is diskless nodes. Being able to purchase mass quantities of servers and not needing to put any sort of storage in them. Since disks have much lower MTBF than other components (aside from fans probably), diskless servers require less maintenance. As mentioned earlier in this thread, diskless would mean no swap and no local storage. Both of which are suitable if you're using SAN (FC/iSCSI) based storage for VM images and if memory overcommit is not allowed. The argument for 'stateless without diskless' is a little more tenuous, however, if you're going to do stateless to get support for diskless, adding in support for local VM image storage and swap is fairly trivial. Andy, I think you've got some opinions here, care to weigh in? Otherwise if there is continued pushback on this feature, I'm happy to not waste effort on it. There are other things we can work on :) Perry