What do you want to see in Foreman next?

Support
41

Is BMC not working on UCS? Don't suppose you can test with a non production UCS system?

Try using the underlying ruby-ipmi gem that the smart proxy uses.

Details below. You could run the tests but only do so if it does not affect production systems.

https://github.com/logicminds/rubyipmi (view the testing section for how to test)

Thanks,

Corey Osman
corey@logicminds.biz

Green IT and Data Center Automation Specialist

··· On Jan 7, 2013, at 11:58 AM, Rodrique Heron wrote:

Also, a way to import existing host, especially from compute resources. Just think, being able to drop foreman into existing environments. Make it easy for folks just discovering Foreman to incorporate it into their environments.

On Monday, January 7, 2013 2:53:33 PM UTC-5, Rodrique Heron wrote:
Most of these are already feature request.

Puppet params via hostgroups
Force much of what you can do via host into hostgroups to make it so you can force defaults by way of hostgroups. This way a operator only have to supply a hostname and a IP in case of static ip config.

Build a host from vmware templates

Extend BMC support to include Cisco UCS:

Surely continue with OpenStack, make it easier to just pick images from glance.
Perhaps closer focus on JeOS type templates, using OZ or Imagefactory .

On Sunday, January 6, 2013 10:12:14 AM UTC-5, ohad wrote:
Hi Everyone,

as we wrap Foreman 1.1, I wanted to check with Foreman users on what they find good/useful in Foreman, and what they would like to see improved/added in coming versions?

Thanks,
Ohad

–
You received this message because you are subscribed to the Google Groups “Foreman users” group.
To view this discussion on the web visit https://groups.google.com/d/msg/foreman-users/-/8fsvuLDymr0J.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/foreman-users?hl=en.

42

I like the hierarchical nature of data stored in Hiera, especially using
Facter facts as part of the hierarchy - it can be quite powerful, and is
now essential to our implementation of Puppet. Additional factors for us
are the pluggable nature of Hiera and its adoption by Puppet Labs.

Andy

··· On Monday, 7 January 2013 13:29:56 UTC, Corey Osman wrote: > > Why use hiera when foreman does the same thing? > On Jan 7, 2013 4:05 AM, "Andy Taylor" <andyta...@gmail.com > > wrote: > >> Hiera support would be very useful - we've just externalised a lot of our >> configuration data into Hiera, but getting people to edit YAML/JSON files >> isn't nearly as nice as being able to do it via the Foreman interface. At >> the moment I use Foreman for unattended builds and as an ENC, so Hiera is >> the last component that isn't under Foreman. >> >> Andy >> >> On Sunday, 6 January 2013 15:12:14 UTC, ohad wrote: >>> >>> Hi Everyone, >>> >>> as we wrap Foreman 1.1, I wanted to check with Foreman users on what >>> they find good/useful in Foreman, and what they would like to see >>> improved/added in coming versions? >>> >>> Thanks, >>> Ohad >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Foreman users" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/foreman-users/-/ZRkxlVZnGUIJ. >> To post to this group, send email to forema...@googlegroups.com >> . >> To unsubscribe from this group, send email to >> foreman-user...@googlegroups.com . >> For more options, visit this group at >> http://groups.google.com/group/foreman-users?hl=en. >> >
43

>
> > > Hi Everyone,
> > Hello, and happy new year!
> >
> > > as we wrap Foreman 1.1, I wanted to check with Foreman users on what they
> > > find good/useful in Foreman, and what they would like to see
> > improved/added
> > > in coming versions?
> >
> > I see main axes where Foreman can improve :
> > - Better data management. Foreman was born as a Puppet ENC. IT's main
> > role is
> > to be the glue between hosts, variables and classes. The bug tracker
> > contains already good feature requests in this field. I wish Foreman
> > add
> > as much features as possible regarding data management.
> >
> Can you explain or reference to the feature requests? I'm not sure I
> understand what you mean :slight_smile:
I mean every way to improve organize/search of data. Here are some feature requests related to this :

1987 Ability to specify meta-parameters on classes, e.g. run stage
1910 add password type for class params
1903 Make search based on parent hostgroup possible
1896 Allow selection of hostgroups that will only be used for nesting
1853 hostgroups can not be listed if filter = null
1845 Add an option to Edit any host value for multiple hosts at once
1805 support in hosts_and_facts to use any host fact to be display name
1791 We should be able to tell foreman that a vm has moved from a compute resource to another
1731 Inherited parameters display improvements
1722 Partition table / hostgroup /environment
1732 Owner choosing issue when creating a new host
1652 Fix privacy for puppetclasses.
1636 Array support in host YAML
1616 Ability to add default class(es) to all systems
1611 Search for hosts without certain facts
1584 Add the ability to change ownership on a set of hosts.
1583 Assign roles and filters to usergroups
1562 Auto-assign a 'finish deploy' class to new hosts
1527 Add support for per OS classes list
1526 Addition of classes/puppetclasses to hostgroup/REST
1480 Smart variables unique per puppet class
1464 Parameters in subnets
1435 Add Checkbox "Force remove classes" to classes import
1425 Support for booleans in parameters
1402 [foreman] [functionality] [RFE] - smart proxies allow to sign/destroy few servers at the same time
1360 one click provision workflow
1359 export to csv, excel
1353 Foreman should be able to handle pre and post hook action.
1327 Foreman should allow BMC importing value from custum facts
1307 It should be possible to Create/Delete parameters for multiple hosts.
1249 Add ability to schedule changes
1215 add a check if a user is allowed to search
1206 Track additional service/virtual IPs assigned to a host
1168 Ability to search for Facts (and Param) without providing a value
1107 variables in settings
985 no permission corresponds to 'Run Puppet' feature
848 add classes the host object
819 foreman should delete puppet node / facts information too
812 cant assign roles to groups, just to users
692 Implement a way to export/import host groups and their associated puppet modules
686 Normal implement inherit environment for a domain
658 Dependency information
593 split log for facts, reports and everything else
564 Implement OUs hierarchy to allow reusing (host) groups with client/OU specific classes and parameters.
563 Allow import and export "parameters" to/from a file (Global and on every level I can set parameters)
499 freeze certian host values after creation
473 Add the ability to have a set of default classes apply to all nodes via the UI
416 Report on inconsistant facts
387 Add select options ("all" and "none") on the Web GUI for bulk operations
215 Allow blank values for parameters
110 support hostname naming standards

> >
> > - Polishing Foreman as application. Better error description and
> > reporting,
> > more careful to small details, better documentation (This one is
> > directed
> > also at me as I could help making the one in place better)
> >
> Totally agree, how about a documentation squashing day? :slight_smile:
Hahaha :slight_smile:

If I remember, Sam tried to develop a new website for foreman. Maybe I'll ask him how he sees the documentation part.

Benjamin

··· On Mon, Jan 07 2013 at 08:09, Ohad Levy wrote: > On Mon, Jan 7, 2013 at 4:58 AM, Claer wrote: > > On Sun, Jan 06 2013 at 12:17, Ohad Levy wrote:
44

I might be saying this from a place of over optimism, but I think it's totally possible to add support for other configuration management tools. It will be a large project initially, but the hope would be that members of the Chef, CFengine, etc. communities would help us maintain support for their respective platforms.

I said this on IRC so sorry if it's repetitive, but one of the most complex parts of Foreman right now is compute resources/provisioning, which would require no changes apart from configuration templates.

Thoughts?

··· ----- Original Message ----- From: "Josh Baird" To: foreman-users@googlegroups.com Sent: Tuesday, January 8, 2013 2:09:51 PM Subject: Re: [foreman-users] Re: What do you want to see in Foreman next?

This may sound cool in theory, but I’m guessing it’s nearly impossible. I vote to keep Foreman in “Puppet-land.”

Josh

On Tue, Jan 8, 2013 at 1:50 PM, Walid Shaari < walid.shaari@gmail.com > wrote:

I second that the Configuration management system should be abstracted so Foreman can be used with either (CFengine3, Ansible, saltstack, and chef)

regards

Walid Shaari

On Tuesday, January 8, 2013 2:23:09 PM UTC+3, Romain Vrignaud wrote:

Hello everybody,

  • I think that we would need a better ACL user management.
    The one already in place is a bit complicated to use and we can’t express lots of case.

  • On second hand maybe a notion to apply logic both from hostgroup and something like labels (see my previous mail http://bit.ly/XHzn4b )

  • I don’t use it, but IMHO I think this would be really a great benefit for the project to be agnostic on the configuration management system, with maybe on the
    a Chef integration at the beginning. I’m not a Chef user so I don’t know how it would be possible / interesting. But I think that Foreman is a greatest tool but have competitor
    in puppet world. If it become a standard with Puppet and Chef and Cfengine this would be really great.

Regards,
Romain

On Sunday, January 6, 2013 4:12:14 PM UTC+1, ohad wrote:

Hi Everyone,

as we wrap Foreman 1.1, I wanted to check with Foreman users on what they find good/useful in Foreman, and what they would like to see improved/added in coming versions?

Thanks,
Ohad

–
You received this message because you are subscribed to the Google Groups “Foreman users” group.
To view this discussion on the web visit https://groups.google.com/d/msg/foreman-users/-/jswCOPsx1QIJ .

To post to this group, send email to foreman-users@googlegroups.com .
To unsubscribe from this group, send email to foreman-users+unsubscribe@googlegroups.com .
For more options, visit this group at http://groups.google.com/group/foreman-users?hl=en .

–
You received this message because you are subscribed to the Google Groups “Foreman users” group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/foreman-users?hl=en.

45

Actually, making this "pluggable" would be really cool. So it could point
to mcollective or some other mechanism, like ansible, etc… to trigger the
puppet runs.

··· On Mon, Jan 7, 2013 at 9:21 AM, Christian McHugh wrote:

Would you mind sharing your patches? I"m sure you are not the only one
who wants this feature, and it could be used as a starting point for
implementation?

Sure. We didn’t do anything fancy: http://pastebin.com/1U8ibyrt
Simply changed the puppetrun logic to be mco for mcollective. “Works for
me”

–
Romeo

46

+1

··· On 03/28/2013 02:19 AM, Ivan Necas wrote: > > > ----- Original Message ----- >> I'd love to see the ability to control the provisioning templates as >> a flatfile so it can be stored and managed with github. This would >> give the added benefit of opening up changes for comment and review. > > +1 - I like this one! > > -- Ivan > >> >> On Sunday, January 6, 2013 7:12:14 AM UTC-8, ohadlevy wrote: >> >> >> >> Hi Everyone, >> >> >> as we wrap Foreman 1.1, I wanted to check with Foreman users on what >> they find good/useful in Foreman, and what they would like to see >> improved/added in coming versions? >> >> >> Thanks, >> Ohad >> >> -- >> You received this message because you are subscribed to the Google >> Groups "foreman-dev" group. >> To unsubscribe from this group and stop receiving emails from it, >> send an email to foreman-dev+unsubscribe@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out . >> >> >> >
47

Well, since we want to allow non-techy people do some provisioning /
configuration, it would be great if we could somewhat format /
validate the hash. Something like the parameters but then manually add
different keys and allowed values.

Jan.

··· On 01/07/2013 08:21 AM, Ohad Levy wrote: > > > > On Mon, Jan 7, 2013 at 9:18 AM, Jan Vansteenkiste > wrote: > > On 01/07/2013 08:03 AM, Ohad Levy wrote: >> >> >> >> On Sun, Jan 6, 2013 at 9:21 PM, Jan Vansteenkiste > <jan@vstone.eu >> <mailto:jan@vstone.eu >> wrote: >> >> On 01/06/2013 04:12 PM, Ohad Levy wrote: >>> Hi Everyone, >> >>> as we wrap Foreman 1.1, I wanted to check with Foreman users >>> on what they find good/useful in Foreman, and what they would >>> like to see improved/added in coming versions? >> >>> Thanks, Ohad >> >> I would love to see support for parameterized definitions next >> to classes. Should probably be optional and will require to have >> some work done on the puppet side too. >> >> >>> Thats an interesting idea, and I don't think it would be >>> difficult to implement from foreman point of view, however as >>> long as the ENC is the only interface, we can't create >>> resources via define. >> >>> the long term alternatives are: 1. to create a new terminus >>> (instead of standard ENC) 2. extend puppet enc interface 3. >>> come up with better examples of using create_resources. >> >>> Did i miss anything? Ohad > > > As an alternative, the focus could be on hashes as parameter > values: Allowing to configure required/optional hash keys, what > kind of values are allowed and ultimately, nesting of hashes. > > This way, all we need to do is call a wrapper class which could > use create_resources. > > > foreman supports hashes, e.g. you can dump your hashes into a > param value and mark it as a hash. the downside is the UI, e.g. we > cant assume we know anything about the other params type and cant > do any validations. > > Ohad >
48

I personally feel that adding additional configuration management system
support to Foreman is one of the most pressing issues for the project. The
reason I feel this is that it's becoming standard for provisioning
frameworks to become agnostic here. Crowbar, Razor, Cobbler, PXE_dust,
Ubuntu MaaS, etc are all cfg-mgt neutral or are working on it. (Of course
our bar of support is higher than many of these as we do more than just
provisioning.)

That said, I do think the priority is to pick two projects and add support
so that we will have a cross section of three projects keeping us honest on
the abstraction front. The projects I would chose are:

  1. Puppet (obviously since it's already there, but we will need to refactor
    much of the current puppet support, particularly at the inventory layer)
  2. Chef - I think Chef is important as it does have some traction in the
    devops community, but more importantly, since Chef users write their
    recipes in Ruby, and many come from Rails shops, it would be a pool of
    potential users that already know some Ruby/Rails and could potentially
    contribute code to the project.
  3. Salt stack - Salt already has ENC support, and should in theory be an
    easy project to integrate with. (Once the heavy lifting is done to
    accomodate puppet/chef.)

Other projects:

  1. cfengine - I think this would be worth doing after we get support for
    the first three, since it does have a decent sized user base
  2. ansible - I am unsure. That said once we have cfg mgt abstraction in
    place, we would in almost all certainty take commits here.

Cheers,
Brian

··· On Tue, Jan 8, 2013 at 2:47 PM, Sam Kottler wrote:

I might be saying this from a place of over optimism, but I think it’s
totally possible to add support for other configuration management tools.
It will be a large project initially, but the hope would be that members of
the Chef, CFengine, etc. communities would help us maintain support for
their respective platforms.

I said this on IRC so sorry if it’s repetitive, but one of the most
complex parts of Foreman right now is compute resources/provisioning, which
would require no changes apart from configuration templates.

Thoughts?

----- Original Message -----
From: “Josh Baird” joshbaird@gmail.com
To: foreman-users@googlegroups.com
Sent: Tuesday, January 8, 2013 2:09:51 PM
Subject: Re: [foreman-users] Re: What do you want to see in Foreman next?

This may sound cool in theory, but I’m guessing it’s nearly impossible. I
vote to keep Foreman in “Puppet-land.”

Josh

On Tue, Jan 8, 2013 at 1:50 PM, Walid Shaari < walid.shaari@gmail.com > > wrote:

I second that the Configuration management system should be abstracted so
Foreman can be used with either (CFengine3, Ansible, saltstack, and chef)

regards

Walid Shaari

On Tuesday, January 8, 2013 2:23:09 PM UTC+3, Romain Vrignaud wrote:

Hello everybody,

  • I think that we would need a better ACL user management.
    The one already in place is a bit complicated to use and we can’t express
    lots of case.

  • On second hand maybe a notion to apply logic both from hostgroup and
    something like labels (see my previous mail http://bit.ly/XHzn4b )

  • I don’t use it, but IMHO I think this would be really a great benefit
    for the project to be agnostic on the configuration management system, with
    maybe on the
    a Chef integration at the beginning. I’m not a Chef user so I don’t know
    how it would be possible / interesting. But I think that Foreman is a
    greatest tool but have competitor
    in puppet world. If it become a standard with Puppet and Chef and Cfengine
    this would be really great.

Regards,
Romain

On Sunday, January 6, 2013 4:12:14 PM UTC+1, ohad wrote:

Hi Everyone,

as we wrap Foreman 1.1, I wanted to check with Foreman users on what they
find good/useful in Foreman, and what they would like to see improved/added
in coming versions?

Thanks,
Ohad

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/foreman-users/-/jswCOPsx1QIJ .

To post to this group, send email to foreman-users@googlegroups.com .
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com .
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en .

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.

–
http://aws.amazon.com/solutions/solution-providers/brandorr/

49

The two propositions of :

Romeo : " Would personally like to see the ability to have hosts
automatically assigned to specific hostgroups based on certain puppet
facts" +1
Nowder : "I'd like to see customized reporting, and the ability to
customize the dashboard and the statistics page." +1

··· 2013/1/9 Romeo Theriault

On Mon, Jan 7, 2013 at 9:21 AM, Christian McHugh < > christian.mchugh@gmail.com> wrote:

Would you mind sharing your patches? I"m sure you are not the only one
who wants this feature, and it could be used as a starting point for
implementation?

Sure. We didn’t do anything fancy: http://pastebin.com/1U8ibyrt
Simply changed the puppetrun logic to be mco for mcollective. “Works for
me”

Actually, making this “pluggable” would be really cool. So it could point
to mcollective or some other mechanism, like ansible, etc… to trigger the
puppet runs.

–
Romeo

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.

50

Romeo : " Would personally like to see the ability to have hosts
automatically assigned to specific hostgroups based on certain puppet
facts" +1

Nowder : "I'd like to see customized reporting, and the ability to
customize the dashboard and the statistics page." +1

The issue Steve Traylen (from CERN) raised regarding Foreman gracefully
ignoring classes loaded into a hostgroup if the class isn't in that servers
environment (even providing a gentle warning rather than making the
puppetrun bomb out). That way you can add classes to hostgroups then push
them through Dev, Test then Production easily regardless of how many
servers you have.

The last one is smart proxy control of an IPA server.

Thanks,
Charlie

··· On Wed, Jan 9, 2013 at 9:22 AM, Romain Vrignaud wrote:

The two propositions of :

Romeo : " Would personally like to see the ability to have hosts
automatically assigned to specific hostgroups based on certain puppet
facts" +1
Nowder : “I’d like to see customized reporting, and the ability to
customize the dashboard and the statistics page.” +1

2013/1/9 Romeo Theriault romeo.theriault@maine.edu

On Mon, Jan 7, 2013 at 9:21 AM, Christian McHugh < >> christian.mchugh@gmail.com> wrote:

Would you mind sharing your patches? I"m sure you are not the only one
who wants this feature, and it could be used as a starting point for
implementation?

Sure. We didn’t do anything fancy: http://pastebin.com/1U8ibyrt
Simply changed the puppetrun logic to be mco for mcollective. “Works for
me”

Actually, making this “pluggable” would be really cool. So it could point
to mcollective or some other mechanism, like ansible, etc… to trigger the
puppet runs.

–
Romeo

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.