[ovirt-users] Proper way to change and persist vdsm configuration options

Tue Aug 5 15:01:14 EDT 2014

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 <alonbl at redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Trey Dockendorf" <treydock at gmail.com>
>> To: "ybronhei" <ybronhei at redhat.com>
>> Cc: "users" <users at ovirt.org>, "Fabian Deutsch" <fabiand at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>, "Itamar
>> Heim" <iheim at redhat.com>, "Douglas Landgraf" <dougsland at redhat.com>, "Alon Bar-Lev" <alonbl at redhat.com>
>> 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 <ybronhei at redhat.com> 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" <ybronhei at redhat.com> 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
>> >>>> Users at ovirt.org
>> >>>> http://lists.ovirt.org/mailman/listinfo/users
>> >>>>
>> >>>>
>> >>>
>> >>> --
>> >>> Yaniv Bronhaim.
>> >>>
>> >>
>> >
>>