Add Katello support for RHVH/oVirt Node provisioning

[iNecas]

Leverages repository_url helper to generate full url to
Katello-provided squashfs img, based on relative path.

Requires Katello/katello#7215

The process I was following was:

1. extract the squashfs.img from the rhvh rpm
2. create custom product (name:rhv) and repository (content type: file, name:rhvh)
3. upload the squashfs.img to the repository (hammer repository upload-content --organization 'Default Organization' --name rhvh --product rhv --path ~/squashfs.img)
4. used 'custom/RHV/rhvh' as 'liveimg_content_path' host parameter.

With this patch (and the katello PR), this will lead to using http://katello.example.com/pulp/isos/Default_Organization/Library/custom/RHV/rhvh/squashfs.img for liveimg

[ghost]

Small typo -- otherwise looks great

[ghost]

Small typo here

[iNecas]

Updated

[ghost]

@sandrobonazzola

[lzap]

Can you merge liveimg_content_path and liveimg_name so there is just one parameter that works for both? They are both relative paths, the only difference should be base URL (IM or Katello CV) I believe. This way it is little bit confusing.

[iNecas]

There is another difference, which is that the 'liveimg_content_path` also enforces using the subscription manager.

If I unified those two, I would need another parameter to specify, that the katello url should be used, instead of installation media.

If we want to eliminate the number of parameters, I would probably go for not exposing liveimg_name at all, and instead expecting that if using IM for this purpose, the IM is expecting the squashfs.img to be placed on recommended location.

[lzap]

Yes, that's another reason why to merge it, this is a side effect you don't want to always have. Imagine a Katello user doing CentOS CV provisioning, or even SUSE or Debian which is coming.

We still want to expose a plain URL because this will be useful in non-oVirt provisioning, you can create your own image/squashimg and provision normal OS using this technique, this is in Anaconda starting from RHEL 7.3 and it's a valid provisioning option. We want to have the same parameter also in normal kickstart, not only oVirt.

I am searching for consistency between katello and non-katello users and ovirt and non-ovirt users, please don't get me wrong.

[iNecas]

Unifying liveimg_content_path and liveimg_name by itself is not enough. Are you suggesting to add additional parameter to determine if to use katello or not?

[lzap]

There is already a condition there: if @host.operatingsystem.name == 'RHVH' it is kind of lame, so an explicit parameter might be a good idea for those who do not want to name OS like that.

[lzap]

@iNecas this has been merged recently

https://github.com/theforeman/community-templates/pull/302/files#diff-62c51493c4aee87824ebe40d58fe4382R62

I wonder if this template can be designed in the same way, I think so. We can remove the RHVH name check and simply use the snippet, it will render to nothing when there is no rhsm available.

[iNecas]

Good idea, updated

[lzap]

Anyway, I am fine with that. Thanks.

[lzap]

Where repository_url helper is defined? Can't find it in katello codebase.

[iNecas]

I mentioned that in the first comment: Katello/katello#7215 - it's close to merge.

[lzap]

Haven't tried the katello workflow, but I am good with this. TY

[mykaul]

@lzap - in which Foreman version will it be available?

[lzap]

Hello @mykaul it's 1.19 but you can easily import fresh templates via foreman_templates plugin into any Foreman release.

[ekohl]

Note we do have stable-x.y branches and we should be importing those into .z releases. You can create a PR against those branches so they'll be synced on the next release.