Description of problem: RFE for the ability to share content views/repos/products accross multiple orgs for customers wishing to migrate systems from one org to another. How reproducible: Steps to Reproduce: 1. login to webui and create a content view and sync a repo 2. create a new org and then try to view the content view and repos 3. No where in webui to be able to change assocations either in org admin area or the content view/product page itself Actual results: unable to view repos/views Expected results: Be able to share views/repos across orgs as the admin and define which orgs can use what.
Since this issue was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
Created redmine issue http://projects.theforeman.org/issues/8877 from this bug
Upstream bug component is WebUI
Upstream bug component is Multi Org
Gosh unless I'm missing something fundamental here, this was a basic functionality in Satellite 5 that I didn't expect to lose in Satellite 6. Is it really the case at this point that I have to redefine and re-sync EPEL 7 again for each of our half dozen organizations in Satellite 6? Same goes for all of our in-house custom software channels we used extensively in Satellite 5, creating once and sharing across all orgs...
Is there any update on this RFE? Was it implemented?
We have 52K servers on a 5.7 satellite and 15 proxies that are in 55 groups and the inability to share channels, 164 of them, between the groups will be a major hindrance to our ability to even consider moving to satellite 6.2. Why would we lost a feature that was critical in the satellite 5 series just because you are now using a series of components to deliver satellite 6. We need this ability to service our client base as it continues to grow.
Woe unto Red Hat for continually ignoring this bug. Did the Foreman/Katello folks never even use Satellite 5? It's coming up on a year since I put in a paid support ticket about this, ample time for Red Hat to fix before it began to hit huge customers like @Benjamin ^^ And here we are nearly 2 years after this BZ was opened and the status: NEW *sigh*
Foreman tracker status: Backlog (last update 8mo)
Hello everyone, Satellite 6 does not support sharing Product, Repositories, Content Views or Environments across Organizations, but if a package is downloaded once in any Organization, it is shared, therefore only metadata is copied across organizations. Promoting or publishing content is fast as only metadata needs to be generated, packages stays shared. This RFE was not planned for Satellite 6.3 but I request more info about this from Bryan.
Possible workaround is to setup channel chains, where one organization could be "source" or "upstream" for other organizations. This could be implemented as custom product with YUM repositories pointing at original repositories published via HTTP.
(In reply to Lukas Zapletal from comment #29) > Hello everyone, > > Satellite 6 does not support sharing Product, Repositories, Content Views or > Environments across Organizations, but if a package is downloaded once in > any Organization, it is shared, therefore only metadata is copied across > organizations. Promoting or publishing content is fast as only metadata > needs to be generated, packages stays shared. > > This RFE was not planned for Satellite 6.3 but I request more info about > this from Bryan. Impressive misinterpretation of the problem, Lukas; go read comment 20 again and ponder how this impacts large organizations with complex hierarchies. Very glad we moved away from Satellite 6 after discovering early just how much functionality was not carried forward from Satellite 5. If I sound frustrated it's because this was a show stopper known 2.5 years ago and is still in NEW status.
My question for comment 20 is why are there groups? In 5.7 the org was a major point the security model. With Satellite 6, the RBAC can control much of the access control done by orgs. Has the customer looked at how RBAC + locations can achieve the same end?
*** Bug 683215 has been marked as a duplicate of this bug. ***
Are there any updates or ETA's on this issue? Giving permissions to a content view across multiple organizations shouldn't be this difficult that 4.5 years later we don't even have so much as a projected ETA for a fix...
So when is Red Hat going to get this implemented? AT&T currently has ~110K servers on Satellite 5.8 and we are migrating them to Satellite 6. There are a multitude of other organizations in AT&T that would like have access to our Satellite 6 content and there is no effective way to do this with organizations on Satellite 6. AT&T recently purchased Time-Warner which means we will be breaking in that organization in-house as well. If Red Hat isn't going to support sharing content between organizations then you should just kill this "feature" in Satellite 6 as it just worthless and/or extend the life of Satellite 5 until feature parity.
This BZ is when I realized that Red Hat has really changed, and not for the better. The Katello people surely know about this issue - they just don't care. If ATT/Time Warner can't get a response, and the Solutions Architects they employ from Red Hat can't force progress, improving the state of Satellite 6 is just hopeless. Sat 6 devs are just going to keep doing what they want regardless of what the customer needs - makes me wonder if they all came over from the Gnome3 dev team har har. (!!!) Status: NEW (!!!) Glad we just run Pulp bare.
Also beeing able to share the VM guests/hypervisors mapping amongst organizations too, where one organizations would manage the virtual datacenter subscriptions and all the other organizations managing their VM guests would fetch the subscriptions from the other organization (https://bugzilla.redhat.com/show_bug.cgi?id=1787070). Instead if we want to have an organized satellite server each organization needs to have it's own virtual datacenter subscriptions "duplicating" a lot the need for subscriptions, which is a budget killer.
Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Note, organizations are a type of multi-tenancy we, therefore, have no plans to share more objects between them. You can, however, create the same Content View and Product/Repository in each organization either manually or using Ansible. With the introduction of Pulp 3, we will vastly improve the performance of content operations (like Content View Version Publish/Promote) and therefore making it easier to create the same thing in each organization.