RedHatSatellite/katello-cvmanager

Does it honor a different config file at all?

D43m0n opened this issue ยท 12 comments

I've created a few .yaml files, some with a complex content view set up and some with a very simple set up. No matter what option I provide on the command line -c or --config=somefile.yaml, it doesn't seem to pick that up.

Besides that, how can I get some more verbose feedback?

Can you please post some logs?

Please start posting the yaml and the command you are running, with the output that you get :-)

OK, this is the yaml I've got:

---
:settings:
  :user: admin
  :pass: some_long_pass
  :uri: https://localhost
  :timeout: 300
  :org: 3
  :lifecycle: 2
  :keep: 2
:cv:
  cv_RHEL_Server_6: latest
:publish:
  - cv_RHEL_Server_6
:promote:
  - cv_RHEL_Server_6

I'm running this on the Satellite 6 host itself:

:~/satellite/katello-cvmanager# ./cvmanager publish

no output at all.
Next, I try:

:~/satellite/katello-cvmanager# ./cvmanager update

and get:

Inspecting ccv RHEL Server 7
 Checking cv RHEL Server 7
 Checking cv RHSCL Server 7
 Checking cv EPEL 7
 Checking cv Third Party Repositories for RHEL Server 7

I don't understand why it's referring to a RHEL 7 related content view with the yaml I configured. There is no mentioning of the RHEL 6 related content at all.

When I run a promote, no feedback too:

:~/satellite/katello-cvmanager# ./cvmanager promote

But when I run a clean, I get all content views:

:~/satellite/katello-cvmanager# ./cvmanager clean
Inspecting Default Organization View
Inspecting cv Third Party Repositories for RHEL Server 7
Inspecting cv RHSCL Server 7
Inspecting cv RHEL Server 7
Inspecting cv RHEL Server 6
Inspecting cv RHEL Server 5
Inspecting cv Puppet SVD
 keeping 642.0
 keeping 641.0
Inspecting cv EPEL 7
Inspecting ccv RHEL Server 7

From the output I'm getting, my guess is the :settings: part in the yaml file is correct. I don't see any task being started or triggered in Satellite's WebUI.

Sorry about closing and reopening, I got distracted

ooooh, I see multiple ways this can fail for you, let me dump some thoughts:

  • in your yaml you refer to cv_something_something (a label), but in the cvmanager output we see cv something something (a name) - spaces vs underscores. cvmanager expects names in the yaml (which is probably wrong on itself), not labels (as you put it). my own satellites always have labels and names identical, so thats probably why I never encountered the issue before. this is why your publish and promote runs did not have any output -- there is no output for skipping (which again should be probably fixed)
  • clean runs over everything, so that is why you see all CVs there - but nothings was removed, so that is why you dont have any tasks in Satellite
  • the update logic is a bit "complicated" (I had discussed this with @Rocco83 the other day, we might want to simplify that): mentioning a cv in :cv: means that cvmanager will inspect all CCVs and update the CV if it is in the cv Hash. And it only mentions the RHEL7 one, as the other seem to be CVs, not CCVs, and update only works on CCVs (as update means: update its components).

Does that explain the situation a bit?

Sorry for the delayed answer - was a bit busy at work.

opened/referenced related issues. first come, first patch ;-)

Hah, damn, we are not even consistent. Some code uses names, some code uses labels when checking, it's all a mess. sorry.

Well, good to know you've discovered that ๐Ÿ‘

So if I understand this correctly, it depends on whether you're doing an update, promote or publish for instance, you need to use labels, or names? ๐Ÿค”

I'd expect (as an outsider) cvmanager to use labels to improve predictable behavior and to avoid spaces completely, so us mere humans can use those in names to improve readability ๐Ÿ˜‡

Yeah I have been using names and labels internally inconsistently. Esp as my own setups always have name==label as I never use spaces or special chars.

I just need to sit down on a quiet day and fix up the code to work internally everywhere with labels and print all messages with name AND label. And the config should also only have labels, as spaces suck :)

fm0l commented

I think we can close this issue, since the merging of #50

true that