On 02/22/2012 03:38 PM, Itamar Heim wrote:
On 02/22/2012 07:23 PM, Perry Myers wrote:
Well, if the network is busted which leads to the bridge rename failing, wouldn't the fact that the network is broken cause other problems anyhow?
Perry, my point is that we're increasing the chances to get into these holes. Network is not busted most of the time, but occasionally there's a glitch and we'd like to stay away from it. I'm sure you know what I'm talking about.
What if oVirt Node creates ifcfg-ovirt (instead of ifcfg-br0) by default as part of bringing up the network on each boot (via either DHCP or kernel args)?
what if admin wants this bonded, or bridgeless, or jumbo frames?
Right now those aren't things you can configure via oVirt Node, they're things you configure via oVirt Engine/vdsm. If we want to add things like this to oVirt Node, we can (just file some RFEs for us) and then we'll expose this sort of stuff via the kernel cmd line args as we do with all of our other config params
stateless doesn't mean you can't save configuration somewhere on the network, right (could be on engine, could be just on some nfs or http location).
Correct. Our present thinking is that oVirt Node specific stuff us saved via kernel cmd line args persisted either on PXE server or directly on boot media. Anything else (oVirt Engine specific for example) would be stored in the mgmt server (OE) itself
if you have a tpm, just encrypt all the data to make sure no one tampered with your config, or if you don't care, just download your config (well, you trust the network to download your image without encryption, so no need to be fanatic i guess).
so in short: 1. pxe boot the image 2. download from known location (kernerl param) the rest of the config you care about, certificates, etc. 3. use tpm for private key (or get the password to keystore in config via kernel parameter if you don't want/have tpm.
Agreed, though w/ vdsm you can simplify by just encrypting the certs 1. boot up, network and basics are configured via kernel cmd args or DNS SRV 2. vdsm retrieves cert from OE and decrypts via locally stored key (TPM or embedded in ISO) 3. vdsm now can securely communicate with OE, so it retrieves config for network/storage from OE and applies that config
I guess my main question is why does stateless implies no saved config for all the various issues
It doesn't imply no saved config, it implies no saved config on the local node itself. Config absolutely will need to be retrieved from a remote server. Right now, oVirt Node config (outside of vdsm) consists of: * network config (dhcp vs. static) * logging/rsyslog config/collectd * mgmt server config (oVirt Engine IP/port) * kdump remote config * auth info (admin password, etc) All of that can be handled through some combination of: * DNS SRV * kernel command line args * embedding things in the ISO pre-deployment (passwords for example) The remaining config is what vdsm does after the node has the above configured, so things like bonding, add'l interfaces, storage, should all be configured by vdsm on each boot by retrieving the configuration details from oVirt Engine and applying them on vdsm startup Perry