Hide Forgot
Description of problem: Lets say there are two capsules, external A and Satellite internal. If Puppet environment wasn't synced to one of capsules, then import from that capsule will suggest to remove\add the classes\environment. This requires the user to hand pick the correct changes. Version-Release number of selected component (if applicable): Snap 8.2 How reproducible: Always Steps to Reproduce: 1. Add two capsules to the organization with life cycle Library 2. Publish new Content view with Puppet modules to life cycle Library 3. Make sure the Environment doesn't exist on one of the capsules (This can happen for many reasons) for example Capsule A. 4. Go to Puppet environments page 5. click "import from capsule-a.com" at the top of the page Actual results: In the list of changes, there will be an option to remove the puppet environment we created. This is False option. Expected results: List of changes that are correspond to description in Satellite. Additional info:
Could you descirbe more on what "List of changes that are correspond to description in Satellite" means?
"List of changes that are correspond to description in Satellite", example: Content view "my_content_view" has a published version in "Library" life cycle, with Puppet module "stdlib" by "puppetlabs". Capsule A doesn't have the puppet environment synced. Current result of "import from capsule-a.com", is a suggestion of removal "stdlib" class or the entire puppet environment of "my_content_view" (depends on which button you click). Expected results: No changes suggested Improvement: warning message regarding difference in Satellite description of the "my_content_view" puppet environment and actual files in Capsule.
Thanks, marking this for sat-future as this will need some design first to support this case.
Looking at this from different angle, I think it's still valuable to differentiate between what's is planned to be on the capsule vs. what's actually synchronized. What about just making it clear when importing the classes from capsule, that the capsule was not synchornized and refusing to do the import until it's done?
Listing the difference is a good idea, but: 1. the user doesn't need to actually try to import to get a refuse, just have specific environment grayed out\un-selectable with a note that it is not properly synced. 2. environments that doesn't have problems should allow import 3. this must not effect hammer execution (hammer doesn't support fine selection of imports)
So in hammer, it would sync just the environments that were properly synced, right and skip the rest, right?
Ivan, c(In reply to Ivan Necas from comment #7) > So in hammer, it would sync just the environments that were properly synced, > right and skip the rest, right? Correct. A message about skipped environments will be helpful.
Thinking about it with fresh mind, it seems the right thing to do would be to provide ability to import from all the capsules as once: this way we would not offer to delete the environments if there is at least one proxy with it. Would that work for you Alexander?
@onjdrej: if https://bugzilla.redhat.com/show_bug.cgi?id=1330049#c9 would be valid fix, I would suggest to keep it in configuration management component
That means that if one capsule is in a bad state, then no matter what, Satellite will keep the classes and environments in the system. I can't think of other issues it can cause, but I think people will find it annoying. How about disable the feature for regular capsules. I mean if its under control of Satellite, then it doesn't really need to do the whole class\environment import from remote capsule, it just has to be in sync. For special cases where puppet environments are managed by third party (i.e r10k), if it is supported, Satellite will allow tracking "external" puppet modules and environments. what do you think?
Importing from all capsules has a catch - you would have to make sure that the subset of your capsules that have the environments you want to keep is online/reachable. If environments do not have to be imported and being properly synced is all that is needed, then why even attempt the import? The thing that seems strange to me is that if 2 proxies have an environment with the same name and different puppet modules and we try to import from both, we always modify the same environment. Is this a bug or a feature? Shouldn't we keep track where we imported the stuff from?
If we assume that the internal capsule is always reachable, (well, if it isn't, we have a problem anyway), than this eliminates the whole set of issues described here: if the internal capsule is not reachable, that we would just refuse to the the import. Anyway, @ondrej: your thinking about the origin of the environments/classes is right: if we had the link to those, we would know that we can only remove, when we have no links from proxies to the envs/classes. I think fixing that would also resolve the original issue
Created redmine issue http://projects.theforeman.org/issues/21115 from this bug
Cloned into upstream and proposed adding a link to import source, thanks everyone for ideas and suggestions.
Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you.