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 <goetz.dir...@gmail.com> 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 foreman-users+unsubscr...@googlegroups.com . > To post to this group, send email to foreman-users@googlegroups.com . > 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 foreman-users+unsubscr...@googlegroups.com. To post to this group, send email to foreman-users@googlegroups.com. Visit this group at https://groups.google.com/group/foreman-users. For more options, visit https://groups.google.com/d/optout.
