[chef] Re: Re: Re: New RFCs: local mode and multitenancy


Chronological Thread 
  • From: Tensibai Zhaoying < >
  • To:
  • Subject: [chef] Re: Re: Re: New RFCs: local mode and multitenancy
  • Date: Wed, 03 Sep 2014 23:12:28 +0200

May you explain me how dealing with multiple orgs is something taking OSS mono org system in-line ?

Sounds like efforts are (logically) on the pay system with far less efforts on OSS, just maintaining more or less in-line the parts of OSS used in entreprise Chef.

Sounds like: don't expect anything stunning in OSS model. If something could be of interest it will stay in pay services only.

Already done with UI, reports, ACL... As far as it was enhanced systems I was ok with it. I fear it will become more and more a cfengine model, core for all, for the others enhancements don't even count on it if you can't pay in dollars...

For the last, it's open source, just rebuild what you need...

Sorry I may be a little caricatural for chef team, but it's my feeling as a chef user spending time and giving back the fixes I need to write... And sounds I'll have to reinvent an existing paying wheel again and again as my needs are quite the same



---- Morgan Blackthorne a écrit ----

It actually sounds the other way around to me, that OSS chef is moving to be more in-line with the way that Enterprise Chef is organized and presented, feature-wise. Better compatibility between the two offerings seems like a bonus to me, not a detriment... anything that breaks likely would have had issues for enterprise customers.

--
~*~ StormeRider ~*~

"Every world needs its heroes [...] They inspire us to be better than we are. And they protect from the darkness that's just around the corner."

(from Smallville Season 6x1: "Zod")

On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS


On Wed, Sep 3, 2014 at 1:23 PM, Tensibai Zhaoying < " target="_blank"> > wrote:

I didn't read carefully but it sounds like OSS chef will die soon as it will break more and more tools around.

Or to say it differently, those willing to use OSS would have to fork and support it... As history always repeat itself I fear seeing a new product coming to fix what chef did with Puppet closed Dsl. But the announced death of the OSS web-ui have been a first step toward this...

In brief, I feel sad the feeling OSS chef server will be left on the side of the road is confirmed day after day.

Nothing personal to anyone, just one more information giving me the feeling OSS chef is left behind in favor of pay services

I just hope I'm wrong with that



---- John Keiser a écrit ----


Hey all!

The new RFC process has been working pretty well, and is only heating up as time goes by.  I've put up a few new RFCs up at chef-rfc that are worth taking a look at and commenting on while there's still time:

1. Turn on local mode by defaulthttps://github.com/opscode/chef-rfc/pull/48

This means that you no longer need to specify -z in most cases to get local mode.  You can walk up to a new directory and do this:

~/test> echo "puts 'hi'" > recipe.rb
~/test> chef-client recipe.rb
Starting Chef Client, version 12.0.0.alpha.1
... hi ...
Chef Client finished, 0/0 resources updated in 2.574202 seconds
~/test> knife node list
johns-mbp-3.lan
~/test>

Of course, you can do all the normal things with nodes--add to run lists, manipulate data bags, do searches and roles and all that.  The only change here is that you used to have to put a -z on every command you types.

This will not affect knife and chef-client runs that have config: anything that is already pointed at a chef_server_url will remain pointed at a chef_server_url.

2. Add multi-org to chef and local mode: https://github.com/opscode/chef-rfc/pull/49

First, this upgrades local mode to emulate a Hosted or Enterprise organization by default, so that you can test recipes which work in those environments, which are becoming more and more common.  Chef 11 non-multitenant compatibility can be flipped back on with a config option.

It also adds chef_server_root and organization to Chef::Config, so that config files can look like this:

organization 'myorg'

# chef_server_url will automatically be set to https://my.enterprise.chef.server.com/organizations/myorg

There's even a Hosted default for a very common case:

organization 'myorg'

# chef_server_url will automatically be set to https://api.opscode.com/organizations/myorg

Existing config files, which do not set chef_server_root or organization, will be unaffected except that if chef_server_url is set to <url>/organizations/myorg, chef_server_root and organization will be inferred.

This paves the way for developer features that create, list, download, upload, or otherwise manipulate organizations and users in Enterprise and Hosted Chef--for example, cheffish's soon-to-be-released chef_acl and chef_organization resources, or expanding knife upload and download to deal with full Enterprise a la knife-ec-backup.

3. Tangentially, you should also check out https://github.com/opscode/chef-rfc/pull/50, which proposes removing the ability to specify HTTP config files, because low bang, big buck.

Please comment on anything relevant to you!  We're looking for your feedback :)

Happy Cheffing,

--John Keiser




Archive powered by MHonArc 2.6.16.

§