Ohai Chefs!
I just released Chef Sugar v2.1.0
solaris2? matcheraix? matcherThis release is fully backwards-compatible.
Keep makin’ it sweet!
Seth
@sethvargo
Should we start packaging sugar up as a dep of Chef, both in the
chef-client and the chef-dk?
That way we would just pick up the enhancements as we go, and it could
maintain a separate release cadence.
Adam
On Sat, Jul 26, 2014 at 6:33 PM, Seth Vargo sethvargo@getchef.com wrote:
Ohai Chefs!
I just released Chef Sugar v2.1.0
Improvements
- Add
solaris2?matcher- Add
aix?matcher- Add 'lxc?' matcher
Bug Fixes
- Fix a bug in namespace memoization during attribute initialization
This release is fully backwards-compatible.
Keep makin' it sweet!
Seth
@sethvargo
On Monday, July 28, 2014 at 10:08 AM, Adam Jacob wrote:
Should we start packaging sugar up as a dep of Chef, both in the chef-client and the chef-dk?
That way we would just pick up the enhancements as we go, and it could maintain a separate release cadence.
Adam
The tricky part of that is, if chef-sugar needs/wants to make a breaking change, then we have to decide whether or not we pull the update in to chef-client. If we do pull it in, then chef-client is making a breaking change and we should rev the major version number, which we may not want to do. If we don’t pull it in, then we have to pin our dependency to an older version, which will conflict with the newer version if someone tries to use it. More concretely, chef-client would have a dependency like “chef-sugar”, “~>2.1”. Seth realizes he can make feature X 1000% awesome-er if he changes something in a way that’s not completely backwards compat, so he releases sugar 3.0. Upon trying to load it, rubygems will see I’ve already loaded 2.1.x and complain.
I’m definitely in favor of pulling at least some chef-sugar features into core. I think a good way to do it that works well with the technologies we’re stuck with (ruby/rubygems dependency model) and lets the individual projects release at their own pace is to have chef-sugar be the experimental/“future” features, and move them into core completely once they’re stable and accepted by the community as “good”. We probably need to coordinate a bit to have one implementation defer to the other so things don’t go haywire if you have versions of chef-sugar and chef-client that implement the same behavior.
Noah also made a good point last we brought this up, that if we have a dependency will the sole purpose of adding features to chef, but the project doesn’t follow our (currently TBD) governance model, then it’s kind of an end run around the governance policy. It should be up to Seth if he wants to be the “BDFL” of chef-sugar or not.
Anyway, tl;dr, there’s some stuff to figure out implementation-wise but I’m in favor in principle.
--
Daniel DeLeo
Perhaps we pull in the stable parts of Sugar?
Adam
On Mon, Jul 28, 2014 at 10:35 AM, Daniel DeLeo dan@kallistec.com wrote:
On Monday, July 28, 2014 at 10:08 AM, Adam Jacob wrote:
Should we start packaging sugar up as a dep of Chef, both in the
chef-client and the chef-dk?That way we would just pick up the enhancements as we go, and it could
maintain a separate release cadence.Adam
The tricky part of that is, if chef-sugar needs/wants to make a breaking
change, then we have to decide whether or not we pull the update in to
chef-client. If we do pull it in, then chef-client is making a breaking
change and we should rev the major version number, which we may not want to
do. If we don’t pull it in, then we have to pin our dependency to an
older version, which will conflict with the newer version if someone tries
to use it. More concretely, chef-client would have a dependency like
“chef-sugar”, “~>2.1”. Seth realizes he can make feature X 1000% awesome-er
if he changes something in a way that’s not completely backwards compat, so
he releases sugar 3.0. Upon trying to load it, rubygems will see I’ve
already loaded 2.1.x and complain.I’m definitely in favor of pulling at least some chef-sugar features into
core. I think a good way to do it that works well with the technologies
we’re stuck with (ruby/rubygems dependency model) and lets the individual
projects release at their own pace is to have chef-sugar be the
experimental/“future” features, and move them into core completely once
they’re stable and accepted by the community as “good”. We probably need to
coordinate a bit to have one implementation defer to the other so things
don’t go haywire if you have versions of chef-sugar and chef-client that
implement the same behavior.Noah also made a good point last we brought this up, that if we have a
dependency will the sole purpose of adding features to chef, but the
project doesn’t follow our (currently TBD) governance model, then it’s kind
of an end run around the governance policy. It should be up to Seth if he
wants to be the “BDFL” of chef-sugar or not.Anyway, tl;dr, there’s some stuff to figure out implementation-wise but
I’m in favor in principle.--
Daniel DeLeo
I wanted to clear up two misconceptions:
I don't mind maintaining it, and I prefer the quick release cycles I can have with it. It's a very simple cookbook that does a gem install.
Seth
On Jul 28, 2014, at 2:19 PM, Adam Jacob adam@getchef.com wrote:
Perhaps we pull in the stable parts of Sugar?
Adam
On Mon, Jul 28, 2014 at 10:35 AM, Daniel DeLeo dan@kallistec.com wrote:
On Monday, July 28, 2014 at 10:08 AM, Adam Jacob wrote:
Should we start packaging sugar up as a dep of Chef, both in the chef-client and the chef-dk?
That way we would just pick up the enhancements as we go, and it could maintain a separate release cadence.
Adam
The tricky part of that is, if chef-sugar needs/wants to make a breaking change, then we have to decide whether or not we pull the update in to chef-client. If we do pull it in, then chef-client is making a breaking change and we should rev the major version number, which we may not want to do. If we don’t pull it in, then we have to pin our dependency to an older version, which will conflict with the newer version if someone tries to use it. More concretely, chef-client would have a dependency like “chef-sugar”, “~>2.1”. Seth realizes he can make feature X 1000% awesome-er if he changes something in a way that’s not completely backwards compat, so he releases sugar 3.0. Upon trying to load it, rubygems will see I’ve already loaded 2.1.x and complain.
I’m definitely in favor of pulling at least some chef-sugar features into core. I think a good way to do it that works well with the technologies we’re stuck with (ruby/rubygems dependency model) and lets the individual projects release at their own pace is to have chef-sugar be the experimental/“future” features, and move them into core completely once they’re stable and accepted by the community as “good”. We probably need to coordinate a bit to have one implementation defer to the other so things don’t go haywire if you have versions of chef-sugar and chef-client that implement the same behavior.
Noah also made a good point last we brought this up, that if we have a dependency will the sole purpose of adding features to chef, but the project doesn’t follow our (currently TBD) governance model, then it’s kind of an end run around the governance policy. It should be up to Seth if he wants to be the “BDFL” of chef-sugar or not.
Anyway, tl;dr, there’s some stuff to figure out implementation-wise but I’m in favor in principle.
--
Daniel DeLeo
Don't you have the problem that if someone wants to use a matcher in
attribute files you can't use chef_gem to install it?
On Mon Jul 28 14:31:01 2014, Seth Vargo wrote:
I wanted to clear up two misconceptions:
- Chef Sugar would get pulled into Ohai.
- Chef Sugar is in use in other projects (see Omnibus), and therefore
I think it should be it's own library.I don't mind maintaining it, and I prefer the quick release cycles I
can have with it. It's a very simple cookbook that does a gem install.
On Monday, July 28, 2014 at 2:31 PM, Seth Vargo wrote:
I wanted to clear up two misconceptions:
- Chef Sugar would get pulled into Ohai.
- Chef Sugar is in use in other projects (see Omnibus), and therefore I think it should be it's own library.
I don't mind maintaining it, and I prefer the quick release cycles I can have with it. It's a very simple cookbook that does a gem install.
Seth
That said, there’s some valuable features we’d like to have as part of the out-of-the-box experience for chef. My favorite is the deep_fetch thing, and I think the “deep set” stuff could be handy for doing attributes tracing without massive changes to the underlying attributes classes.
Can a compromise be reached?
--
Daniel DeLeo
Using the matcher in an attributes file is awkward, but you can totally use
it in recipe after chef_gem "chef-sugar". If you need to reload an
attribute, use the ohai resource on that one attribute.
On Mon, Jul 28, 2014 at 4:03 PM, Lamont Granquist lamont@opscode.com
wrote:
Don't you have the problem that if someone wants to use a matcher in
attribute files you can't use chef_gem to install it?On Mon Jul 28 14:31:01 2014, Seth Vargo wrote:
I wanted to clear up two misconceptions:
- Chef Sugar would get pulled into Ohai.
- Chef Sugar is in use in other projects (see Omnibus), and therefore
I think it should be it's own library.I don't mind maintaining it, and I prefer the quick release cycles I
can have with it. It's a very simple cookbook that does a gem install.
--
Joshua Timberman, Chef.
I'm stoked to see it be its own library - it makes total sense that it is.
Just seems clearly useful. 
Adam
On Mon, Jul 28, 2014 at 2:31 PM, Seth Vargo sethvargo@getchef.com wrote:
I wanted to clear up two misconceptions:
- Chef Sugar would get pulled into Ohai.
- Chef Sugar is in use in other projects (see Omnibus), and therefore I
think it should be it's own library.I don't mind maintaining it, and I prefer the quick release cycles I can
have with it. It's a very simple cookbook that does a gem install.Seth
On Jul 28, 2014, at 2:19 PM, Adam Jacob adam@getchef.com wrote:
Perhaps we pull in the stable parts of Sugar?
Adam
On Mon, Jul 28, 2014 at 10:35 AM, Daniel DeLeo dan@kallistec.com wrote:
On Monday, July 28, 2014 at 10:08 AM, Adam Jacob wrote:
Should we start packaging sugar up as a dep of Chef, both in the
chef-client and the chef-dk?That way we would just pick up the enhancements as we go, and it could
maintain a separate release cadence.Adam
The tricky part of that is, if chef-sugar needs/wants to make a breaking
change, then we have to decide whether or not we pull the update in to
chef-client. If we do pull it in, then chef-client is making a breaking
change and we should rev the major version number, which we may not want to
do. If we don’t pull it in, then we have to pin our dependency to an
older version, which will conflict with the newer version if someone tries
to use it. More concretely, chef-client would have a dependency like
“chef-sugar”, “~>2.1”. Seth realizes he can make feature X 1000% awesome-er
if he changes something in a way that’s not completely backwards compat, so
he releases sugar 3.0. Upon trying to load it, rubygems will see I’ve
already loaded 2.1.x and complain.I’m definitely in favor of pulling at least some chef-sugar features into
core. I think a good way to do it that works well with the technologies
we’re stuck with (ruby/rubygems dependency model) and lets the individual
projects release at their own pace is to have chef-sugar be the
experimental/“future” features, and move them into core completely once
they’re stable and accepted by the community as “good”. We probably need to
coordinate a bit to have one implementation defer to the other so things
don’t go haywire if you have versions of chef-sugar and chef-client that
implement the same behavior.Noah also made a good point last we brought this up, that if we have a
dependency will the sole purpose of adding features to chef, but the
project doesn’t follow our (currently TBD) governance model, then it’s kind
of an end run around the governance policy. It should be up to Seth if he
wants to be the “BDFL” of chef-sugar or not.Anyway, tl;dr, there’s some stuff to figure out implementation-wise but
I’m in favor in principle.--
Daniel DeLeo