Add new scenario for vifib without re6st
The changes were merged into master. The source branch has been removed.
Seems fine, but please test a bit. I think upgrade will call re6stnet role here:
I don't think it will configure anything, but you could just check. If it is ok, no objections to merge it.
re6stnetrole does configure it, unless you set
I totally removed
vifib-upgraderole was used in the following playbooks:
vifib-base.yml vifib-kernel-upgrade.yml vifib-shuttle.yml vifib-upgrade.yml vifib-upgrader-install.yml vifib.yml
re6stnetrole is already explicitly called in the following playbooks:
so @rafael, should we add it to the following:
vifib-kernel-upgrade.yml vifib-shuttle.yml vifib-upgrade.yml vifib-upgrader-install.yml
I would say maybe add it only to
In any case, I don't think the configuration for token is propagated to upgrader, so I think package will be installed but not configured (which means your code is ok, I just add a note to check when you setup something to see).
Full explanation... until now, when you setup re6st you would configure re6st, but the role has tree parts: One is install re6st package, Second is configure, Third is to ensure it is running (by checking if service is start).
So, on vifib.yml required it to setup it, on vifib-base.yml required it to install package only (not configure), and it is present on vifib-upgrade*.yml to ensure it was running (if configured).... the vifib-shuttle.yml wasn't actually used, it was legacy.
In short, you can (if you want to clean up):
1) remove the role from upgrade 2) Split role in 2 (setup in one, ensure it is running if configured in another) 3) Add the role for ensure it is running if configured in another on the upgrader.
From implementation point of view, It was explicitly added to vifib.yml because there was no vifib-upgrade.yml when it was added. And it was kept on the vifib.yml to be explicit (and to not require propagate extra variables).
Now seems fine... (no objections you can merge)
mergedToggle commit list