New RFCs: local mode and multitenancy

Chef Infra (archive)
1

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 default:
https://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:

chef_server_root 'https://my.enterprise.chef.server.com'
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
/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
https://github.com/opscode/cheffish/blob/master/spec/integration/chef_acl_spec.rb#L432-434
and chef_organization
https://github.com/opscode/cheffish/blob/master/spec/integration/chef_organization_spec.rb#L63-65
resources, or expanding knife upload and download to deal with full
Enterprise a la knife-ec-backup https://github.com/opscode/knife-ec-backup
.

  1. 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 :slight_smile:

Happy Cheffing,

--John Keiser

2

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 default: "local_mode by default" proposal by jkeiser · Pull Request #48 · chef-boneyard/chef-rfc · GitHub

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.

  1. Add multi-org to chef and local mode: Add multitenancy support to Chef client config and local mode by jkeiser · Pull Request #49 · chef-boneyard/chef-rfc · GitHub

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:

chef_server_root 'https://my.enterprise.chef.server.com'

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 Sign In - Chef Manage

Existing config files, which do not set chef_server_root or organization, will be unaffected except that if chef_server_url is set to /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.

  1. Tangentially, you should also check out Proposal to remove HTTP config file by jkeiser · Pull Request #50 · chef-boneyard/chef-rfc · GitHub, 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 :slight_smile:

Happy Cheffing,

--John Keiser

3

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 tensibai@iabis.net
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 default:
"local_mode by default" proposal by jkeiser · Pull Request #48 · chef-boneyard/chef-rfc · GitHub

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:
Add multitenancy support to Chef client config and local mode by jkeiser · Pull Request #49 · chef-boneyard/chef-rfc · GitHub

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:

chef_server_root 'https://my.enterprise.chef.server.com'
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

Sign In - Chef Manage

Existing config files, which do not set chef_server_root or organization,
will be unaffected except that if chef_server_url is set to
/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
https://github.com/opscode/cheffish/blob/master/spec/integration/chef_acl_spec.rb#L432-434
and chef_organization
https://github.com/opscode/cheffish/blob/master/spec/integration/chef_organization_spec.rb#L63-65
resources, or expanding knife upload and download to deal with full
Enterprise a la knife-ec-backup
https://github.com/opscode/knife-ec-backup.

  1. Tangentially, you should also check out
    Proposal to remove HTTP config file by jkeiser · Pull Request #50 · chef-boneyard/chef-rfc · GitHub, 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 :slight_smile:

Happy Cheffing,

--John Keiser

4

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 tensibai@iabis.net 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 default: "local_mode by default" proposal by jkeiser · Pull Request #48 · chef-boneyard/chef-rfc · GitHub

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.

  1. Add multi-org to chef and local mode: Add multitenancy support to Chef client config and local mode by jkeiser · Pull Request #49 · chef-boneyard/chef-rfc · GitHub

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:

chef_server_root 'https://my.enterprise.chef.server.com'

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 Sign In - Chef Manage

Existing config files, which do not set chef_server_root or organization, will be unaffected except that if chef_server_url is set to /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.

  1. Tangentially, you should also check out Proposal to remove HTTP config file by jkeiser · Pull Request #50 · chef-boneyard/chef-rfc · GitHub, 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 :slight_smile:

Happy Cheffing,

--John Keiser

5

I would not be mad if we got the enterprise/hosted chef feature set
for free in f/oss Chef Server 12+.

--aj

On Thu, Sep 4, 2014 at 9:12 AM, Tensibai Zhaoying tensibai@iabis.net wrote:

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 tensibai@iabis.net
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 default:
    "local_mode by default" proposal by jkeiser · Pull Request #48 · chef-boneyard/chef-rfc · GitHub

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.

  1. Add multi-org to chef and local mode:
    Add multitenancy support to Chef client config and local mode by jkeiser · Pull Request #49 · chef-boneyard/chef-rfc · GitHub

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:

chef_server_root 'https://my.enterprise.chef.server.com'
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

Sign In - Chef Manage

Existing config files, which do not set chef_server_root or organization,
will be unaffected except that if chef_server_url is set to
/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.

  1. Tangentially, you should also check out
    Proposal to remove HTTP config file by jkeiser · Pull Request #50 · chef-boneyard/chef-rfc · GitHub, 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 :slight_smile:

Happy Cheffing,

--John Keiser

6

Indeed I won't be neither. But my poor English level may have fooled me, so far I did not saw something toward this path :wink:

---- AJ Christensen a écrit ----

I would not be mad if we got the enterprise/hosted chef feature set
for free in f/oss Chef Server 12+.

--aj

On Thu, Sep 4, 2014 at 9:12 AM, Tensibai Zhaoying tensibai@iabis.net wrote:

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 tensibai@iabis.net
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 default:
    "local_mode by default" proposal by jkeiser · Pull Request #48 · chef-boneyard/chef-rfc · GitHub

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.

  1. Add multi-org to chef and local mode:
    Add multitenancy support to Chef client config and local mode by jkeiser · Pull Request #49 · chef-boneyard/chef-rfc · GitHub

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:

chef_server_root 'https://my.enterprise.chef.server.com'
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

Sign In - Chef Manage

Existing config files, which do not set chef_server_root or organization,
will be unaffected except that if chef_server_url is set to
/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.

  1. Tangentially, you should also check out
    Proposal to remove HTTP config file by jkeiser · Pull Request #50 · chef-boneyard/chef-rfc · GitHub, 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 :slight_smile:

Happy Cheffing,

--John Keiser

7

On Wednesday, September 3, 2014 at 2:12 PM, Tensibai Zhaoying wrote:

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

For various reasons, I’m going to stick to generalities, but things will be much clearer soon.

On the general topic, I can say this: As a business, Chef Software needs to give people reasons to buy our stuff, and some of that is going to be server features that we don’t include in the paid version. However, we have and will continue to design these features in such a way that interested community members can recreate the functionality on their own if they wish. In some cases, things will be open sourced once we decide there’s enough new stuff that we don’t need them to differentiate (like the erlang-based Chef Server).

Here’s an example of the benefit of open APIs for OSS users: the node history reporting feature, on the chef-client side of things, is built upon an event stream that anyone can create a plugin for. A community member was interested in integrating chef-client with the Foreman tool, and I pointed them at the relevant client-side reporting code and APIs. Based on that, they were able to integrate Chef with foreman (GitHub - theforeman/chef-handler-foreman: This handler allow Chef to send reports to Foreman) with all the same data that chef-client sends to the proprietary reporting service. And I’ve further had no trouble recommending that users look at this as an alternative to the proprietary reporting service if they can’t afford that or want an open source solution.

I’ll finish up by saying there’s enough negative examples in the Open Source community of projects becoming crippled by the company that “owns” them, that it’s a valid concern. But I also think CHEF’s overall track record here has been pretty good. Also, if you feel strongly about these topics, you can join the developer meeting in IRC, which occurs every two weeks. The next one is tomorrow at 9AM Pacific time (aka America/Los Angeles).

--
Daniel DeLeo

8

Le 2014-09-04 00:31, Daniel DeLeo a écrit :

On the general topic, I can say this: As a business, Chef Software needs to give people reasons to buy our stuff, and some of that is going to be server features that we don't include in the paid version. However, we have and will continue to design these features in such a way that interested community members can recreate the functionality on their own if they wish. In some cases, things will be open sourced once we decide there's enough new stuff that we don't need them to differentiate (like the erlang-based Chef Server).

Here's an example of the benefit of open APIs for OSS users: the node history reporting feature, on the chef-client side of things, is built upon an event stream that anyone can create a plugin for. A community member was interested in integrating chef-client with the Foreman tool, and I pointed them at the relevant client-side reporting code and APIs. Based on that, they were able to integrate Chef with foreman (GitHub - theforeman/chef-handler-foreman: This handler allow Chef to send reports to Foreman [1]) with all the same data that chef-client sends to the proprietary reporting service. And I've further had no trouble recommending that users look at this as an alternative to the proprietary reporting service if they can't afford that or want an open source solution.

I'll finish up by saying there's enough negative examples in the Open Source community of projects becoming crippled by the company that "owns" them, that it's a valid concern. But I also think CHEF's overall track record here has been pretty good. Also, if you feel strongly about these topics, you can join the developer meeting in IRC, which occurs every two weeks. The next one is tomorrow at 9AM Pacific time (aka America/Los Angeles).

--
Daniel DeLeo

I really do understand, I also tried having an entreprise chef, but our
financial services have a problem with other currency than Euro ... and
for our ~350 nodes, I sounds expensive to my managers at $6/node and per
month :slight_smile: (but its off topic here)

I agree to everything you said, I'm just saying how I feel seeing more
and more tooling around chef oriented to entreprise only and which can't
be used with OSS Chef Server. If I'm the only one feeling that, its that
I'm wrong, but I wished to open the debate.

For why on mailing list over IRC meetings, unfortunately 9AM PDT is 6PM
here, when I'm heading back home (1h trip) which does not let me join.

I really do NOT want to be rude, I just wanted to say what I feel and
know if I'm the only one feeling that.

Thanks for the answer

Links:

[1] GitHub - theforeman/chef-handler-foreman: This handler allow Chef to send reports to Foreman

9

I hope some of the context behind these is a bit clearer now: local mode by
default stands on its own, but multitenant+rbac mode by default is a
deliberate attempt to match up Chef 12 client to the Chef 12 server, making
it so that when you test, by default you are testing in an environment as
close as possible to the real one.

On Wed, Sep 3, 2014 at 10:11 AM, John Keiser jkeiser@getchef.com wrote:

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 default:
"local_mode by default" proposal by jkeiser · Pull Request #48 · chef-boneyard/chef-rfc · GitHub

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:
Add multitenancy support to Chef client config and local mode by jkeiser · Pull Request #49 · chef-boneyard/chef-rfc · GitHub

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:

chef_server_root 'https://my.enterprise.chef.server.com'
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

Sign In - Chef Manage

Existing config files, which do not set chef_server_root or organization,
will be unaffected except that if chef_server_url is set to
/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
https://github.com/opscode/cheffish/blob/master/spec/integration/chef_acl_spec.rb#L432-434
and chef_organization
https://github.com/opscode/cheffish/blob/master/spec/integration/chef_organization_spec.rb#L63-65
resources, or expanding knife upload and download to deal with full
Enterprise a la knife-ec-backup
https://github.com/opscode/knife-ec-backup.

  1. Tangentially, you should also check out
    Proposal to remove HTTP config file by jkeiser · Pull Request #50 · chef-boneyard/chef-rfc · GitHub, 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 :slight_smile:

Happy Cheffing,

--John Keiser