Ah, thank you for the input! Just so I'm not spending time implementing the wrong changes, let me confirm I understand your comments.
1) Deploy host with Foreman 2) Apply Puppet catalog including ovirt Puppet module 3) Initiate host-deploy via rest API In the ovirt module the following takes place: 2a) Add yum repos 2b) Manage /etc/ovirt-host-deploy.conf.d/40-xxx.conf For #2b I have a few questions * The name of the ".conf" file is simply for sorting and labeling/organization, it has not functional impact on what those overrides apply to? * That file is managed on the ovirt-engine server, not the actual nodes? * Is there any way to apply overrides to specific hosts? For example if I have some hosts that require a config and others that don't, how would I separate those *.conf files? This is more theoretical as right now my setup is common across all nodes. For #3...the implementation of API calls from within Puppet is a challenge and one I can't tackle yet, but definitely will make it a goal for the future. In the mean time, what's the "manual" way to initiate host-deploy? Is there a CLI command that would have the same result as an API call or is the recommended way to perform the API call manually (ie curl)? Thanks! - Trey On Tue, Aug 5, 2014 at 1:45 PM, Alon Bar-Lev <[email protected]> wrote: > > > ----- Original Message ----- >> From: "Trey Dockendorf" <[email protected]> >> To: "ybronhei" <[email protected]> >> Cc: "users" <[email protected]>, "Fabian Deutsch" <[email protected]>, "Dan >> Kenigsberg" <[email protected]>, "Itamar >> Heim" <[email protected]>, "Douglas Landgraf" <[email protected]>, "Alon >> Bar-Lev" <[email protected]> >> Sent: Tuesday, August 5, 2014 9:36:24 PM >> Subject: Re: [ovirt-users] Proper way to change and persist vdsm >> configuration options >> >> On Tue, Aug 5, 2014 at 12:32 PM, ybronhei <[email protected]> wrote: >> > Hey, >> > >> > Just noticed something that I forgot about.. >> > before filing new BZ, see in ovirt-host-deploy README.environment [1] the >> > section: >> > VDSM/configOverride(bool) [True] >> > Override vdsm configuration file. >> > >> > changing it to false will keep your vdsm.conf file as is after deploying >> > the >> > host again (what happens after node upgrade) >> > >> > [1] >> > https://github.com/oVirt/ovirt-host-deploy/blob/master/README.environment >> > >> > please check if that what you meant.. >> > >> > Thanks, >> > Yaniv Bronhaim. >> > >> >> I was unaware of that package. I will check that out as that seems to >> be what I am looking for. >> >> I have not filed this in BZ and will hold off pending >> ovirt-host-deploy. If you feel a BZ is still necessary then please do >> file one and I would be happy to provide input if it would help. >> >> Right now this is my workflow. >> >> 1. Foreman provisions bare-metal server with CentOS 6.5 >> 2. Once provisioned and system rebooted Puppet applies puppet-ovirt >> [1] module that adds the necessary yum repos > > and should stop here.. > >> , and installs packages. >> Part of my Puppet deployment is basic things like sudo management >> (vdsm's sudo is account for), sssd configuration, and other aspects >> that are needed by every system in my infrastructure. Part of the >> ovirt::node Puppet class is managing vdsm.conf, and in my case that >> means ensuring iSER is enabled for iSCSI over IB. > > you can create a file /etc/ovirt-host-deploy.conf.d/40-xxx.conf > --- > VDSM_CONFIG/section/key=str:content > --- > > this will create a proper vdsm.conf when host-deploy is initiated. > > you should now use the rest api to initiate host-deploy. > >> 3. Once host is online and has had the full Puppet catalog applied I >> log into ovirt-engine web interface and add those host (pulling it's >> data via the Foreman provider). > > right, but you should let this process install packages and manage > configuration. > >> What I've noticed is that after step #3, after a host is added by >> ovirt-engine, the vdsm.conf file is reset to default and I have to >> reapply Puppet before it can be used as the one of my Data Storage >> Domains requires iSER (not available over TCP). > > right, see above. > >> What would be the workflow using ovirt-host-deploy? Thus far I've had >> to piece together my workflow based on the documentation and filling >> in blanks where possible since I do require customizations to >> vdsm.conf and the documented workflow of adding a host via web UI does >> not allow for such customization. >> >> Thanks, >> - Trey >> >> [1] - https://github.com/treydock/puppet-ovirt (README not fully >> updated as still working out how to use Puppet with oVirt) >> >> > >> > On 08/05/2014 08:12 AM, Trey Dockendorf wrote: >> >> >> >> I'll file BZ. As far as I can recall this has been an issue since 3.3.x >> >> as >> >> I have been using Puppet to modify values and have had to rerun Puppet >> >> after installing a node via GUI and when performing update from GUI. >> >> Given >> >> that it has occurred when VDSM version didn't change on the node it seems >> >> likely to be something being done by Python code that bootstraps a node >> >> and >> >> performs the other tasks. I won't have any systems available to test with >> >> for a few days. New hardware specifically for our oVirt deployment is on >> >> order so should be able to more thoroughly debug and capture logs at that >> >> time. >> >> >> >> Would using vdsm-reg be a better solution for adding new nodes? I only >> >> tried using vdsm-reg once and it went very poorly...lots of missing >> >> dependencies not pulled in from yum install I had to install manually via >> >> yum. Then the node was auto added to newest cluster with no ability to >> >> change the cluster. Be happy to debug that too if there's some docs that >> >> outline the expected behavior. >> >> >> >> Using vdsm-reg or something similar seems like a better fit for puppet >> >> deployed nodes, as opposed to requiring GUI steps to add the node. >> >> >> >> Thanks >> >> - Trey >> >> On Aug 4, 2014 5:53 AM, "ybronhei" <[email protected]> wrote: >> >> >> >>> On 07/31/2014 01:28 AM, Trey Dockendorf wrote: >> >>> >> >>>> I'm running ovirt nodes that are stock CentOS 6.5 systems with VDSM >> >>>> installed. I am using iSER to do iSCSI over RDMA and to make that >> >>>> work I have to modify /etc/vdsm/vdsm.conf to include the following: >> >>>> >> >>>> [irs] >> >>>> iscsi_default_ifaces = iser,default >> >>>> >> >>>> I've noticed that any time I upgrade a node from the engine web >> >>>> interface that changes to vdsm.conf are wiped out. I don't know if >> >>>> this is being done by the configuration code or by the vdsm package. >> >>>> Is there a more reliable way to ensure changes to vdsm.conf are NOT >> >>>> removed automatically? >> >>>> >> >>> >> >>> Hey, >> >>> >> >>> vdsm.conf shouldn't wiped out and shouldn't changed at all during >> >>> upgrade. >> >>> other related conf files (such as libvirtd.conf) might be overrided to >> >>> keep >> >>> defaults configurations for vdsm. but vdsm.conf should persist with >> >>> user's >> >>> modification. from my check, regular yum upgrade doesn't touch vdsm.conf >> >>> >> >>> Douglas can you verify that with node upgrade? might be specific to that >> >>> flow.. >> >>> >> >>> Trey, can file a bugzilla on that and describe your steps there? >> >>> >> >>> Thanks >> >>> >> >>> Yaniv Bronhaim, >> >>> >> >>>> >> >>>> Thanks, >> >>>> - Trey >> >>>> _______________________________________________ >> >>>> Users mailing list >> >>>> [email protected] >> >>>> http://lists.ovirt.org/mailman/listinfo/users >> >>>> >> >>>> >> >>> >> >>> -- >> >>> Yaniv Bronhaim. >> >>> >> >> >> > >> _______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
