Hi, My wish-list:
* Puppet smart class parameters and other config related parameters management like Content view: The goal here is to manage multiple parameters changes as a transaction, for easy review and rollback * More integration with compute resources #10539, #10539, #10244, #5441... * Access compute resources via foreman proxies * Isolated foreman proxies #8172 * Simple Errata import API (for CentOS errata management for example) #8656 * Nested organizations in Katello #10789 I'm working on #10539 (PR 4095 and 4096) and on prerequisites for #5441 (rbovirt part was merged and there is a PR3936 open on the fog part) Thanks for your work, foreman/katello devs, i've seen a lot of improvements since we started to use it few years ago, and i think the best is still to come :) Regards. ----- Le 19 Déc 16, à 22:28, Dirk Götz <[email protected]> a écrit : > Hi, > my wishlist: > * Handling OS for provisioning is still complicated: What I mean in detail is > every OS is listed also if not prepared for provisioning because every minor > release is autocreated when an updated system shows up in a puppet run. > Listing > only the prepared once and/or add templates, media and so on when autocreate > another minor release would make handling easier. > * Katello adds to much complexity: As others mentioned Katello, I think its to > complex by default. Not everyone needs multitenancy, docker, ... when he needs > content staging. Having this things as separate plugins would be more helpful. > * Having to use IDs in API/CLI instead of names > * Redmine vs. Github: Having same issue in both trackers or having the feeling > of added the bug to the wrong tracker is unsatisfactory > * Long-standing bugs/feature request: As for all software seeing bugs many > years > old makes me sad, sometimes reviewing and closing as wont fix would be more > honest > And my +1 list: > * A huge +1 for stability as updating the training material always ends in > creating to many bugs. > * Ability to add a new Lifecycle stage to the middle of a Lifecycle Path. >> * Default Owner of Hosts (RM #14013) >> The default owner of hosts should be configurable. The default user might be >> a >> group where the user is a member of. >> * Linking of Compute Resources VLANs to Subnet (RM #10539) >> Foreman should know more about the Network of a Compute Resource. The subnet >> should be linked to VLANs on the Compute Resource. That would prevent a lot >> of >> errors when manually deploying a VM. > But with all the negative things mentioned I have to say Foreman is one of my > favorite tools and developers do a great job. This is why I care about these > details. > Regards, > Dirk > -- > You received this message because you are subscribed to the Google Groups > "Foreman users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email > to [email protected] . > To post to this group, send email to [email protected] . > Visit this group at https://groups.google.com/group/foreman-users . > For more options, visit https://groups.google.com/d/optout . -- Baptiste -- You received this message because you are subscribed to the Google Groups "Foreman users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/foreman-users. For more options, visit https://groups.google.com/d/optout.
