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.
I'd be interested to see Razor integration into Foreman…
I know Foreman already does the Provisioning piece, I chose Razor due to
it's existing integration with Puppet, and the fact that it's designed to
maintain a machine state…
Cheers
Gav
···
On Sunday, 6 January 2013 15:12:14 UTC, 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 >>
>
>
>
>
>> Hi Ohad,
>>
>> there are two things that would be very helpful for us:
>> - having the Foreman configuration available in Puppet via ENC Variables,
>> e.g. the IP addresses configured for the host.
>>
> I think thats already supported (assuming you turn on
> ignore_puppet_facts_for_provisioning setting, you would get a mac/ip
> values in your enc), but that was done mostly as a solution for something
> else, and would not report other interfaces (now that 1.1 supports multiple
> nics).
> would you mind opening an issue, it should not be hard (read easy) to add
> that info to the ENC output.
>
> Thank you, i created ticket #2111 for that.
> - the API covering all configurable aspects of the Foreman (no need to
>> access reports, audits, …) to make an automated
>>
>
>
>> customization easier and independent of the database structure.
>>
> Thats one of the main things we added in 1.1 (along side with multi
> orgs/locations support and param classes), there is no pretty useful (i
> think) documented api (with multiple version support - read - we dont break
> your scripts if we change our api)
> you can get a glance at the new api at
> http://server2.theforeman.org/api.html
>
> there are a couple of CLI that are now done, there is a ruby one, that can
> be auto generated via the api docuemntation, and another python version
> called foreman buddy (https://github.com/jpoppe/foremanBuddy).
>
I will have a look at the new API, thx.
···
Am Montag, 7. Januar 2013 08:13:41 UTC+1 schrieb ohad: > On Mon, Jan 7, 2013 at 7:32 AM, Peter Bauer <p.b...@avibit.com > > wrote:br,
PeterAm Sonntag, 6. Januar 2013 16:12:14 UTC+1 schrieb ohad:
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/-/sp-MtKJFup0J.To post to this group, send email to forema...@googlegroups.com<javascript:>
.
To unsubscribe from this group, send email to
foreman-user...@googlegroups.com <javascript:>.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.
+1 for documentation, both for installation and the UI.
···
Am Montag, 7. Januar 2013 03:58:26 UTC+1 schrieb Claer: > > On Sun, Jan 06 2013 at 12:17, Ohad Levy wrote: > > 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. > > - 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) > > Regards, > > Benjamin >Why use hiera when foreman does the same thing?
···
On Jan 7, 2013 4:05 AM, "Andy Taylor" 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 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.
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> > 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:
- to create a new terminus (instead of standard ENC)
- extend puppet enc interface
- come up with better examples of using create_resources.
Did i miss anything?
Ohad
···
On Sun, Jan 6, 2013 at 9:21 PM, Jan Vansteenkiste wrote: > On 01/06/2013 04:12 PM, Ohad Levy wrote:-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/iQIcBAEBCgAGBQJQ6c6dAAoJEH9K6PHMcbUroIEQAKndO+KnhD6jltCTkYJv12NP
yOaKKOf52QIzGE9IvJDD1Ooo7UOr9k8pwp+aZdirqXudg0wDphioxXGnQzb8iewh
XgPxCwg9EfSVVRQbYCbgc6jZOR42pTqY69i8x7VJr2K447lEesCb8YYCNAfwQAs1
nQdzay6nC8XYJJneJSwJAio+pf6Y0HqeYxDPj4FyMCo+HxGFxwVBQkpC0+sHnZJY
zp2FvmOo74xRFoSjauyqzjZun9Y0drXNZvIxQwwem/jODm0NbZZRktqyhfa6bPze
sshIdYBhY1YEEjpPuPCJIFYlQDkLZ+/90CerbmbRj/AXpUCCAq6cL+AvoH+LNqKR
o4Mfp/uXVtsqQ2gwz9gOexdb+VcZrmRmP/jieKN9mftxB/SwXeU1QxYcSAkfTJd9
oGRrutBoG7y+B/1wCE5ZTzQB7IE/08i4eWsLMv+DJLWN1ZbRceehwxF7Hcs17Jtt
TO1LJJbUwUvtN4EWW2jDTvgeUeU+VrFpmsT32/BWm6snW96Oa8BbjfHmGgK52ROB
iOJG/pQEb5efANwM+B2nH+K0ILr2lrVKsig0V60PjbdXwgWv6ccZ1B8pm4bD9VeK
Pcet4P30mM+tkZ9mIkDODsNBXNoaLAtviy/5Go7LSD4EgsxBtmeUqSA8jEcR9380
2928KEBwTceEH3+x1gzd
=tWEp
-----END PGP SIGNATURE-----
> > 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 
>
> - 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?
···
On Mon, Jan 7, 2013 at 4:58 AM, Claer wrote: > On Sun, Jan 06 2013 at 12:17, Ohad Levy wrote:Regards,
Benjamin
>
>> I'm not sure if this is best done by foreman, but I'll try to describe
>> what I'm working on should anyone have suggestions: I would like to see a
>> way of generating yaml files not necessarily associated with a host.
>>
>> The problem that I'm trying to solve is keeping puppet config data
>> unified. I have an apache farm serving out 700-some virtual hosts. For that
>> large amount of apache config files, I don't want to have puppet directly
>> manage them as iterating through a large list of files and checking sums
>> would be an intensive process. So I'd like to have a deb file built with
>> the needed bits. That deb file is generated from a yaml file of sites.
>
>
> Are foreman smart variables (or maybe even class params) are in any use
> here?
>
Maybe? When we get things settled and some fires put out, I'll be able to
play around with this workflow a bit more. At the moment we just have a 700
or so line yaml file that a puppet module reads. I would like this manged
in foreman to keep auditing constant and give access as necessary to junior
admins. Although, I guess we would have to work out a workflow by which
updating foreman can trigger an external event like an svn/git post commit
hook.
> I wonder if on a higher level, we can't simply store BLOB (e.g. whatever)
> data as a paramter, i think we can, if you had a simple way to upload YAML
> (or whatever) is that good enough? or do you need to perform some logic on
> that data?
>
As of now, for our needs, that would be just fine. (With the above
mentioned post-commit hook)
> Thus, our workflow is currently:
>> check site.yaml into git -> post commit hook kicks off a jenkins run ->
>> builds a deb file of apache configs -> kicks off an mcollective message to
>> kick puppet on the apache servers to ensure they are running the latest
>> version of our sites.deb file.
>>
>> So as it stands we have some config info in foreman for most host
>> configuration, and now some config info in extra yaml files managed in git.
>> It would be nice if there was some way to manage bulk data like that in
>> foreman, so we could use one tool for our systems administration and
>> auditing.
>>
>>
>>
>> Additionally, we patched foreman to run an mco command to trigger client
>> puppet runs using the puppetkick bits. It would be nice if there was
>> mcollective support natively.
>>
>
> 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"
>
>> Finally, I would also like to see foreman utilize puppetdb since
>> storedconfigs seems to be going that way.
>>
>
> The main question I have here, is which kind of data do you want to pull
> from puppetdb? if its plain facts, I'm not sure i see the benefit, if its
> catalog, then the first question, is what do you want to do with it, then
> we could figure out what exactly and where we pull data from, it is true
> however, that we are moving away from traditional store configs, and i
> think that starting 1.2 version we would not support sharing the two
> databases (simply dump the db to another db and use it as foreman one).
>
I was just thinking as a cleanup for fact importing/storage. We should not
have to keep a duplicate fact database if the same info is easily and
quickly query-able from puppetdb. We currently run in a shared database
foreman setup, and sounds like we need to move. If we also have to have a
puppetdb instance around, might as well use it.
Additionally, there seems to be a bit of discussion around hiera support. I
can gladly report that this is done (at least for as far as I've needed it)
https://github.com/torrancew/hiera-foreman
I've patched it a little bit for our needs (see the open issues). I'm not a
developer so the code is kind of ugly, but (again) "works for me".
With that hiera lookups function against both variables and smart variables
(seem to be separate APIs) and it supports hiera arrays, hashes, and
strings. It also supports hiera_include, should you only wish to sort of
use forman as an enc and pull puppet classes from it.
So if that is useful, enjoy!
···
On Monday, January 7, 2013 1:07:37 AM UTC-6, ohad wrote: > On Sun, Jan 6, 2013 at 10:24 PM, Christian McHugh <christia...@gmail.com > > wrote:I would like to see local delayed report processing that works well with
load-balanced foreman servers. We've got a concern now that if the foreman
database server has hiccups the reports will hang in passenger processes on
the puppetmaster waiting on Foreman and grind the whole puppet
infrastructure to a halt.
Robert Birnie
rbirnie@gmail.com
···
On Mon, Jan 7, 2013 at 9:47 AM, Joshua hoblitt wrote:Almost all of the features I’d like to see already have feature request
bugs open on them.
the ability to have a host be a member of multiple host groups.
Currently, I have a bad mix of hardware sets and roles defined as
hostgroups.the ability to remove a class from a hostgroup that is inherited from
a parent hostgroup. I have several examples where just one of many sub
hostgroups doesn’t need/want a particular class defined.the UI for BMC control to be implemented. I really want this feature
for “the boss” to be able to reprovision real hardware without having to
logon to the real host’s BMC or use the PDU.the garbage libvirt VNC console password issue is driving me bonkers!
At a minimum, I need to be able to turn off console password setting
and have the option to fix the password so foreman doesn’t keep changing
it.there are a couple of messy bugs dealing with foreman role users that
are preventing me from letting our internal development group having
access.there are a number of VM management issues; there’s no way to
[re]associate a VM with a particular libvirt hypervisor so
relocations/migrations are a mess. If you change the hostname/domain
name of a VM, you can’t ever remove the original foreman host entry or
it deletes the VM image (we had a VM get accidentally deleted again last
week).hiera integration
import/export of all foreman enc data as one big yaml dump such that
it can be used as a fast backup / restore mechanism, and as a means to
provide rspec-puppet testing for our local site configuration, eg., this
important host should have these classes defined on it).a UI element to view / flush storeconfigs (export resources)
route53 DNS support
-Josh
–
On 01/06/2013 08:12 AM, 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
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: > > * https://supportforums.cisco.com/docs/DOC-6110 > * > http://viewyonder.com/2009/10/04/vmware-ubuntu-ruby-rest-xml-cisco-ucs-api/ > ( > http://viewyonder.com/2010/10/01/easy-access-to-the-cisco-ucs-api-via-the-ruby-ucsapi-module/ > > 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 >> >Since there have been many requests for MCollective integration, I've
filed two feature requests in Redmine. It seems the requests cover two
topics which we could address separately.
- Use MCollective to trigger Puppet runs, i.e. a replacement for
puppetrun/kick. This should be relatively easy to add.
Feature #2116: Use MCollective to trigger Puppet runs - Foreman
- MCollective user interface. A more generic tool, perhaps akin to
Puppet Dashboard's live management feature.
Feature #2117: MCollective integration - Foreman
Particularly on the second issue, comments with specific use-cases and
examples would be welcome.
···
On 08/01/13 08:14, F�lix Barbeira wrote: > +1 mcollective integration–
Dominic Cleal
Red Hat Engineering
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 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,
RomainOn 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.
Hi Flo,
>> 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 think it is planned anyway, but I would really like to see some chef
> integration.
>
> Also I would love to see more documentation on a smart-proxy is
> organised (think basic skeleton needed ).
> For example, i have a script that use the foreman API to get a list of
> host and go create gdash dashboard accordingly. It would be better if
> i could have a smart proxy being notified on host creations and then
> add the logic to do the dirty work.
You might find the plugin support in 1.1 useful for extending Foreman to
do other jobs. Have a look in particular at the custom hooks Joseph
added, e.g. after_build.
http://groups.google.com/group/foreman-dev/browse_thread/thread/964f78bbb71dcfc3/98635d98a10a7534?lnk=gst&q=plugin#98635d98a10a7534
http://projects.theforeman.org/projects/foreman/wiki/Plugins
This would of course run on the Foreman node itself rather than a remote
proxy, so perhaps adding extension points there too would be useful?
···
On 17/01/13 12:46, florentin raud wrote: > On 6 January 2013 15:12, Ohad Levy wrote:–
Dominic Cleal
Red Hat Engineering
> 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
···
----- Original Message -----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 .
I investigated this possibility a while back for a special reason
which I since forgot…
There's code in Foreman to do this already.
If you place a file in
foreman/app/views/unattended_local/script/grubby.local.rhtml
You can access it at:
https://foreman/unattended/script/grubby
Also works:
https://foreman/unattended/provision/foo =>
unattended_local/provision/foo.local.rhtml
https://foreman/unattended/finish/bar =>
unattended_local/finish/bar.local.rhtml
Try putting a file in one of those locations and then add
?spoof=some_valid_ip and see for yourself!
···
On Wed, Mar 27, 2013 at 7:26 PM, Stephen Wood wrote: > 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.–
Mikael Fridh
We looked at that, but Razor duplicates many things Foreman already has -
we'd have to re-invent a lot of wheels (mostly around templating). We're
doing our own take on bare metal stuff - you can try out the experimental
Metal-as-a-service plugin for Foreman today, if you like. Details were
published to the Dev list a while back, you can get the latest version at
https://github.com/GregSutcliffe/foreman_discovery. I'd love feedback on
it, so play with it on an isolated network, and let me know 
Greg
···
On 2 April 2013 09:57, Gavin Williams wrote:I’d be interested to see Razor integration into Foreman…
I know Foreman already does the Provisioning piece, I chose Razor due to
it’s existing integration with Puppet, and the fact that it’s designed to
maintain a machine state…
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.
···
On 01/07/2013 08:03 AM, Ohad Levy wrote: > > > > On Sun, Jan 6, 2013 at 9:21 PM, Jan Vansteenkiste > 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>
>
>
>
>> 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.
Jan was showing me his hiera_resources function recently, which is a
wrapper around hiera_hash + create_resources:
>> Did i miss anything?
I think that's accurate, but here are a few other points:
This came up on puppet-dev too in the thread "hiera + defines":
http://groups.google.com/group/puppet-dev/browse_thread/thread/2be8bfcad9ee488d#
R.I.Pienaar was recently experimenting with a YAML structure that
essentially became a Puppet "data DSL" (as he termed it). I think
this would be quite interesting for us, as we'd be looking for similar
levels of functionality. The implementation relied again on a
server-side function to generate the resources in the catalog.
(Incidentally, this DSL reminds me of GitHub - lak/pzero: Minimal Puppet Format)
Once we start adding resources to the catalog, it'll inevitably need
support for relationships and ordering too - the data DSL has this.
Lastly, an unconnected piece of the puzzle is that Puppet 3 introduces
Hiera support in core. What's interesting is that this is implemented
as a terminus ("data_binding"), potentially allowing us to hook
Foreman in here (though with the ENC interface that both includes and
supplies data, I'm not sure how useful it is).
I think there's enough similarity between Hiera and Foreman's needs to
find some common solutions.
Dominic Cleal
Red Hat Engineering
···
On 07/01/13 07:03, Ohad Levy wrote: > On Sun, Jan 6, 2013 at 9:21 PM, Jan Vansteenkiste > wrote: > On 01/06/2013 04:12 PM, Ohad Levy wrote: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
···
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.
I think that falls more generally into the need for a queuing system to handle jobs that need persistence beyond the current session. +1 to getting that in place.
···
----- Original Message ----- From: "Robert" To: foreman-dev@googlegroups.com Sent: Monday, January 7, 2013 2:31:46 PM Subject: Re: [foreman-dev] What do you want to see in Foreman next?I would like to see local delayed report processing that works well with load-balanced foreman servers. We’ve got a concern now that if the foreman database server has hiccups the reports will hang in passenger processes on the puppetmaster waiting on Foreman and grind the whole puppet infrastructure to a halt.
Robert Birnie
rbirnie@gmail.com
On Mon, Jan 7, 2013 at 9:47 AM, Joshua hoblitt < josh@hoblitt.com > wrote:
Almost all of the features I’d like to see already have feature request
bugs open on them.
-
the ability to have a host be a member of multiple host groups.
Currently, I have a bad mix of hardware sets and roles defined as
hostgroups. -
the ability to remove a class from a hostgroup that is inherited from
a parent hostgroup. I have several examples where just one of many sub
hostgroups doesn’t need/want a particular class defined. -
the UI for BMC control to be implemented. I really want this feature
for “the boss” to be able to reprovision real hardware without having to
logon to the real host’s BMC or use the PDU. -
the garbage libvirt VNC console password issue is driving me bonkers!
At a minimum, I need to be able to turn off console password setting
and have the option to fix the password so foreman doesn’t keep changing it. -
there are a couple of messy bugs dealing with foreman role users that
are preventing me from letting our internal development group having access. -
there are a number of VM management issues; there’s no way to
[re]associate a VM with a particular libvirt hypervisor so
relocations/migrations are a mess. If you change the hostname/domain
name of a VM, you can’t ever remove the original foreman host entry or
it deletes the VM image (we had a VM get accidentally deleted again last
week). -
hiera integration
-
import/export of all foreman enc data as one big yaml dump such that
it can be used as a fast backup / restore mechanism, and as a means to
provide rspec-puppet testing for our local site configuration, eg., this
important host should have these classes defined on it). -
a UI element to view / flush storeconfigs (export resources)
-
route53 DNS support
-Josh
–
On 01/06/2013 08:12 AM, 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