Creating partitions/vgs/lvms

[Murray Collier]

Hi,

I am struggling to find an obvious way to work with partions and lvm in cfengine. Is this possible within cfengine?

Thanks,

Murray.

[Stefan Skoglund]

lvm itself can export information as json (and then convert that into
an data container and do decisions after that.)

Use predefined UUID to chose lv id ?

And use that onwards ?

[Vratislav Podzimek]

On Tue, 2021-11-16 at 13:20 +0100, Stefan Skoglund wrote:
> tis 2021-11-16 klockan 03:41 -0800 skrev Murray Collier:
> > Hi,
> > I am struggling to find an obvious way to work with partions and lvm
> > in cfengine. Is this possible within cfengine?

Not in any easy/nice way, unfortunately.

> >
> > Thanks,
> > Murray.
>
> lvm itself can export information as json (and then convert that into
> an data container and do decisions after that.)

Yes, that's possible.

But I would encourage you to look at the Custom promise types functionality [1] availble in the
recent versions of CFEngine. Writing a custom promise module working with LVM will definitely be
easier than doing a lot of JSON data manipulation in CFEngine policy and using lots of 'commands'
promises. Especially if you use things like libblockdev [2] or blivet [3]. It would be great to have
a 'block_device' promise type implemented as a custom promise type! (I could help a lot with its
development, I believe).

[1] https://docs.cfengine.com/docs/master/reference-promise-types-custom.html
[2] https://github.com/storaged-project/libblockdev
[3] https://github.com/storaged-project/blivet

--
Vratislav

[t.d...@servicemusic.org.uk]

Another view to consider...

In the machine lifecycle

• initial OS provisioning and installation is one step, and a few minutes in duration
• the ongoing configuration and maintenance is a subsequent stage, and a few years in duration.

CFEngine is primarily about that second stage, less about the first.  At large sites, the first, provisioning step is often handled systematically by kickstart or something similar.

Do you regard your LVM/partitioning work as a "provisioned immediately from the outset" thing or as a "sometime later in the lifecycle I may want to make this mid-course adjustment" thing?

If it is "later in the lifecyle", then config. management (CFEngine) is, indeed, a good choice.  But if it is "right from the outset", then perhaps consider doing it in your early, provisioning step where you are probably already doing other LVM/partitioning operations anyway, and this might be a natural extension.

-- David Lee

[Vratislav Podzimek]

On Thu, 2021-11-18 at 01:42 -0800, t.d...@servicemusic.org.uk wrote:
> Another view to consider...
>
> In the machine lifecycle

>  * initial OS provisioning and installation is one step, and a few minutes in duration
>  * the ongoing configuration and maintenance is a subsequent stage, and a few years in duration.

> CFEngine is primarily about that second stage, less about the first.  At large sites, the first,
> provisioning step is often handled systematically by kickstart or something similar.
>
> Do you regard your LVM/partitioning work as a "provisioned immediately from the outset" thing or
> as a "sometime later in the lifecycle I may want to make this mid-course adjustment" thing?
>
> If it is "later in the lifecyle", then config. management (CFEngine) is, indeed, a good choice. 
> But if it is "right from the outset", then perhaps consider doing it in your early, provisioning
> step where you are probably already doing other LVM/partitioning operations anyway, and this might
> be a natural extension.

Good point, indeed. But I can see use cases where LVM management can actually be part of
configuration management. For example, if you run a Gluster setup or something similar.

Also, monitoring/reporting some parameters/aspects of the LVM setups on hosts might be useful.

My two cents.

--
Vratislav