Is Supermarket replacing Berkshelf-API server?

Should I be spending time setting up a Berkshelf API server or a Supermarket server?

Thanks,
Bernie

On Monday, August 25, 2014 at 2:14 PM, Durfee, Bernie (GE Global Research) wrote:

Should I be spending time setting up a Berkshelf API server or a Supermarket server?

Thanks,
Bernie

The answer to this is, it depends on what you want to do.

Supermarket is open source and you are certainly welcome to set up your own if you like. To run it, you’ll need to manage a few services (I haven’t done this personally, but I think you at least need the supermarket service and a service called oc-id that uses oauth2 to authenticate you to supermarket using your enterprise chef credentials).

That said, we have accepted an RFC to implement a “universe” endpoint for chef-server that will provide a tool like berkshelf with the data it needs to solve dependencies so you can host your cookbooks on your regular Chef server. See: https://github.com/opscode/chef-rfc/blob/master/rfc014-universe-endpoint.md

How are you using Berkshelf API now (or, what configuration were you considering)?

--
Daniel DeLeo

So here is where I stand on things (full disclosure, Supermarket is kinda my thing at Chef):

The Berkshelf API server is perfect if what you want to do is index what you Chef Server has. It is simple and lightweight.

On the other hand, if what you are trying to do is build an internal community around cookbooks and want to have a Berkshelf endpoint that has more than what is on your Chef Server, Supermarket may make more sense but there is more involved in running it, especially since we haven’t built an omnibus package yet.

Supermarket at a base level is a rails app with sidekiq, using postgres and redis. If you plan to support more than one frontend you will need to have an S3 compatible backend for storage as well.

Thanks.

— cwebber

On Aug 25, 2014, at 2:23 PM, Daniel DeLeo dan@kallistec.com wrote:

On Monday, August 25, 2014 at 2:14 PM, Durfee, Bernie (GE Global Research) wrote:

Should I be spending time setting up a Berkshelf API server or a Supermarket server?

Thanks,
Bernie

The answer to this is, it depends on what you want to do.

Supermarket is open source and you are certainly welcome to set up your own if you like. To run it, you’ll need to manage a few services (I haven’t done this personally, but I think you at least need the supermarket service and a service called oc-id that uses oauth2 to authenticate you to supermarket using your enterprise chef credentials).

That said, we have accepted an RFC to implement a “universe” endpoint for chef-server that will provide a tool like berkshelf with the data it needs to solve dependencies so you can host your cookbooks on your regular Chef server. See: https://github.com/opscode/chef-rfc/blob/master/rfc014-universe-endpoint.md

How are you using Berkshelf API now (or, what configuration were you considering)?

--
Daniel DeLeo

Another alternative if you need a /universe endpoint is to use Goiardi
[0], the golang chefserver. It's extremely light weight. The
functionality was added recently! [1]

It can run in-memory with optional journals to disk and is completely
suitable for a few hundred cookbooks. For over a couple of thousand
(the full Supermarket universe has been tested!) you'll want
MySQL/PGSQL.

we have heard some reports of users making use of temporal goiardi
instances as part of continuous integration pipeline "environment
generators" where a job can push cookbooks to, automatically!

cheers,

--aj

[0] Goiardi
[1] https://github.com/ctdk/goiardi/blob/master/CHANGELOG#L21-L24

P.S:

launch like this:
goiardi -VVVV -I 127.0.0.1 -H localhostchef.junglist.io -P 1025 -i goiardi.index -D goiardi.data -A --disable-webui --log-events

On Tue, Aug 26, 2014 at 10:32 AM, Christopher Webber
cwebber@getchef.com wrote:

So here is where I stand on things (full disclosure, Supermarket is kinda my thing at Chef):

The Berkshelf API server is perfect if what you want to do is index what you Chef Server has. It is simple and lightweight.

On the other hand, if what you are trying to do is build an internal community around cookbooks and want to have a Berkshelf endpoint that has more than what is on your Chef Server, Supermarket may make more sense but there is more involved in running it, especially since we haven’t built an omnibus package yet.

Supermarket at a base level is a rails app with sidekiq, using postgres and redis. If you plan to support more than one frontend you will need to have an S3 compatible backend for storage as well.

Thanks.

— cwebber

On Aug 25, 2014, at 2:23 PM, Daniel DeLeo dan@kallistec.com wrote:

On Monday, August 25, 2014 at 2:14 PM, Durfee, Bernie (GE Global Research) wrote:

Should I be spending time setting up a Berkshelf API server or a Supermarket server?

Thanks,
Bernie

The answer to this is, it depends on what you want to do.

Supermarket is open source and you are certainly welcome to set up your own if you like. To run it, you’ll need to manage a few services (I haven’t done this personally, but I think you at least need the supermarket service and a service called oc-id that uses oauth2 to authenticate you to supermarket using your enterprise chef credentials).

That said, we have accepted an RFC to implement a “universe” endpoint for chef-server that will provide a tool like berkshelf with the data it needs to solve dependencies so you can host your cookbooks on your regular Chef server. See: https://github.com/opscode/chef-rfc/blob/master/rfc014-universe-endpoint.md

How are you using Berkshelf API now (or, what configuration were you considering)?

--
Daniel DeLeo

Why does a cookbook repository need to live behind a fancy server anyway?
A repository, by nature, is static. Wouldn¹t a Yum or Apt style repo with
just files and an index be good enough and simpler? Seems like an S3
bucket and an indexer would be all you need, no?

Bernie

On 8/25/14, 7:32 PM, "AJ Christensen" aj@junglist.io wrote:

Another alternative if you need a /universe endpoint is to use Goiardi
[0], the golang chefserver. It's extremely light weight. The
functionality was added recently! [1]

It can run in-memory with optional journals to disk and is completely
suitable for a few hundred cookbooks. For over a couple of thousand
(the full Supermarket universe has been tested!) you'll want
MySQL/PGSQL.

we have heard some reports of users making use of temporal goiardi
instances as part of continuous integration pipeline "environment
generators" where a job can push cookbooks to, automatically!

cheers,

--aj

[0] Goiardi
[1] https://github.com/ctdk/goiardi/blob/master/CHANGELOG#L21-L24

P.S:

launch like this:
goiardi -VVVV -I 127.0.0.1 -H localhostchef.junglist.io -P 1025 -i goiardi.index -D goiardi.data -A --disable-webui --log-events

On Tue, Aug 26, 2014 at 10:32 AM, Christopher Webber
cwebber@getchef.com wrote:

So here is where I stand on things (full disclosure, Supermarket is
kinda my thing at Chef):

The Berkshelf API server is perfect if what you want to do is index
what you Chef Server has. It is simple and lightweight.

On the other hand, if what you are trying to do is build an internal
community around cookbooks and want to have a Berkshelf endpoint that
has more than what is on your Chef Server, Supermarket may make more
sense but there is more involved in running it, especially since we
haven¹t built an omnibus package yet.

Supermarket at a base level is a rails app with sidekiq, using postgres
and redis. If you plan to support more than one frontend you will need
to have an S3 compatible backend for storage as well.

Thanks.

‹ cwebber

On Aug 25, 2014, at 2:23 PM, Daniel DeLeo dan@kallistec.com wrote:

On Monday, August 25, 2014 at 2:14 PM, Durfee, Bernie (GE Global
Research) wrote:

Should I be spending time setting up a Berkshelf API server or a
Supermarket server?

Thanks,
Bernie

The answer to this is, it depends on what you want to do.

Supermarket is open source and you are certainly welcome to set up
your own if you like. To run it, you¹ll need to manage a few services
(I haven¹t done this personally, but I think you at least need the
supermarket service and a service called oc-id that uses oauth2 to
authenticate you to supermarket using your enterprise chef credentials).

That said, we have accepted an RFC to implement a ³universe² endpoint
for chef-server that will provide a tool like berkshelf with the data
it needs to solve dependencies so you can host your cookbooks on your
regular Chef server. See:
https://github.com/opscode/chef-rfc/blob/master/rfc014-universe-endpoint
.md

How are you using Berkshelf API now (or, what configuration were you
considering)?

--
Daniel DeLeo

Bernie,

That’s exactly what Supermarket/Chef Server are. In fact, the Chef Server, once it has the Berkshelf-style universe endpoint, will work pretty much exactly like a yum/apt repo; you’ll query it for the collection of cookbooks is has, then dependency resolve based on the results & what you need.

Right now, you need your own Berkshelf API server that’s indexing your Chef Server to do that for your private cookbooks. For public, community cookbooks, the Supermarket provides its own Berkshelf universe endpoint to provide that sort of depsolving.

Supermarket just happens to offer a web UI on top of all of that, which does require the “fancy” bits you speak of, but at its heart, it’s an artifact store & dependency tree.

--
Jeff Byrnes
@berkleebassist
Operations Engineer
EverTrue
704.516.4628

On August 26, 2014 at 8:43:11 AM, Durfee, Bernie (GE Global Research) (bernie.durfee@ge.com) wrote:

Why does a cookbook repository need to live behind a fancy server anyway?
A repository, by nature, is static. Wouldn¹t a Yum or Apt style repo with
just files and an index be good enough and simpler? Seems like an S3
bucket and an indexer would be all you need, no?

Bernie

On 8/25/14, 7:32 PM, "AJ Christensen" aj@junglist.io wrote:

Another alternative if you need a /universe endpoint is to use Goiardi
[0], the golang chefserver. It's extremely light weight. The
functionality was added recently! [1]

It can run in-memory with optional journals to disk and is completely
suitable for a few hundred cookbooks. For over a couple of thousand
(the full Supermarket universe has been tested!) you'll want
MySQL/PGSQL.

we have heard some reports of users making use of temporal goiardi
instances as part of continuous integration pipeline "environment
generators" where a job can push cookbooks to, automatically!

cheers,

--aj

[0] Goiardi
[1] https://github.com/ctdk/goiardi/blob/master/CHANGELOG#L21-L24

P.S:

launch like this:
goiardi -VVVV -I 127.0.0.1 -H localhostchef.junglist.io -P 1025 -i goiardi.index -D goiardi.data -A --disable-webui --log-events

On Tue, Aug 26, 2014 at 10:32 AM, Christopher Webber
cwebber@getchef.com wrote:

So here is where I stand on things (full disclosure, Supermarket is
kinda my thing at Chef):

The Berkshelf API server is perfect if what you want to do is index
what you Chef Server has. It is simple and lightweight.

On the other hand, if what you are trying to do is build an internal
community around cookbooks and want to have a Berkshelf endpoint that
has more than what is on your Chef Server, Supermarket may make more
sense but there is more involved in running it, especially since we
haven¹t built an omnibus package yet.

Supermarket at a base level is a rails app with sidekiq, using postgres
and redis. If you plan to support more than one frontend you will need
to have an S3 compatible backend for storage as well.

Thanks.

‹ cwebber

On Aug 25, 2014, at 2:23 PM, Daniel DeLeo dan@kallistec.com wrote:

On Monday, August 25, 2014 at 2:14 PM, Durfee, Bernie (GE Global
Research) wrote:

Should I be spending time setting up a Berkshelf API server or a
Supermarket server?

Thanks,
Bernie

The answer to this is, it depends on what you want to do.

Supermarket is open source and you are certainly welcome to set up
your own if you like. To run it, you¹ll need to manage a few services
(I haven¹t done this personally, but I think you at least need the
supermarket service and a service called oc-id that uses oauth2 to
authenticate you to supermarket using your enterprise chef credentials).

That said, we have accepted an RFC to implement a ³universe² endpoint
for chef-server that will provide a tool like berkshelf with the data
it needs to solve dependencies so you can host your cookbooks on your
regular Chef server. See:
https://github.com/opscode/chef-rfc/blob/master/rfc014-universe-endpoint
.md

How are you using Berkshelf API now (or, what configuration were you
considering)?

--
Daniel DeLeo

Is there any difference in how berkshelf-api and supermarket resolve
cookbook's dependencies? We used berkshelf-api a while ago and having
multiple sources in Berksfile it's wasn't clear which one will be used for
each dependency.

On Tue, Aug 26, 2014 at 5:06 PM, Jeff Byrnes jeff@evertrue.com wrote:

Bernie,

That’s exactly what Supermarket/Chef Server are. In fact, the Chef Server,
once it has the Berkshelf-style universe endpoint, will work pretty much
exactly like a yum/apt repo; you’ll query it for the collection of
cookbooks is has, then dependency resolve based on the results & what you
need.

Right now, you need your own Berkshelf API server that’s indexing your
Chef Server to do that for your private cookbooks. For public, community
cookbooks, the Supermarket provides its own Berkshelf universe endpoint
to provide that sort of depsolving.

Supermarket just happens to offer a web UI on top of all of that, which
does require the “fancy” bits you speak of, but at its heart, it’s an
artifact store & dependency tree.

--
Jeff Byrnes
@berkleebassist http://twitter.com/berkleebassist
Operations Engineer
EverTrue http://www.evertrue.com/
704.516.4628

On August 26, 2014 at 8:43:11 AM, Durfee, Bernie (GE Global Research) (
bernie.durfee@ge.com) wrote:

Why does a cookbook repository need to live behind a fancy server anyway?
A repository, by nature, is static. Wouldn¹t a Yum or Apt style repo with
just files and an index be good enough and simpler? Seems like an S3
bucket and an indexer would be all you need, no?

Bernie

On 8/25/14, 7:32 PM, "AJ Christensen" aj@junglist.io wrote:

Another alternative if you need a /universe endpoint is to use Goiardi
[0], the golang chefserver. It's extremely light weight. The
functionality was added recently! [1]

It can run in-memory with optional journals to disk and is completely
suitable for a few hundred cookbooks. For over a couple of thousand
(the full Supermarket universe has been tested!) you'll want
MySQL/PGSQL.

we have heard some reports of users making use of temporal goiardi
instances as part of continuous integration pipeline "environment
generators" where a job can push cookbooks to, automatically!

cheers,

--aj

[0] Goiardi
[1] https://github.com/ctdk/goiardi/blob/master/CHANGELOG#L21-L24

P.S:

launch like this:
goiardi -VVVV -I 127.0.0.1 -H localhostchef.junglist.io -P 1025 -i goiardi.index -D goiardi.data -A --disable-webui --log-events

On Tue, Aug 26, 2014 at 10:32 AM, Christopher Webber
cwebber@getchef.com wrote:

So here is where I stand on things (full disclosure, Supermarket is
kinda my thing at Chef):

The Berkshelf API server is perfect if what you want to do is index
what you Chef Server has. It is simple and lightweight.

On the other hand, if what you are trying to do is build an internal
community around cookbooks and want to have a Berkshelf endpoint that
has more than what is on your Chef Server, Supermarket may make more
sense but there is more involved in running it, especially since we
haven¹t built an omnibus package yet.

Supermarket at a base level is a rails app with sidekiq, using postgres
and redis. If you plan to support more than one frontend you will need
to have an S3 compatible backend for storage as well.

Thanks.

‹ cwebber

On Aug 25, 2014, at 2:23 PM, Daniel DeLeo dan@kallistec.com wrote:

On Monday, August 25, 2014 at 2:14 PM, Durfee, Bernie (GE Global
Research) wrote:

Should I be spending time setting up a Berkshelf API server or a
Supermarket server?

Thanks,
Bernie

The answer to this is, it depends on what you want to do.

Supermarket is open source and you are certainly welcome to set up
your own if you like. To run it, you¹ll need to manage a few services
(I haven¹t done this personally, but I think you at least need the
supermarket service and a service called oc-id that uses oauth2 to
authenticate you to supermarket using your enterprise chef
credentials).

That said, we have accepted an RFC to implement a ³universe² endpoint
for chef-server that will provide a tool like berkshelf with the data
it needs to solve dependencies so you can host your cookbooks on your
regular Chef server. See:

https://github.com/opscode/chef-rfc/blob/master/rfc014-universe-endpoint

.md

How are you using Berkshelf API now (or, what configuration were you
considering)?

--
Daniel DeLeo

--
Best regards,
Koldaev Anton

no

On Aug 26, 2014, at 10:02 AM, Anton Koldaev koldaevav@gmail.com wrote:

Is there any difference in how berkshelf-api and supermarket resolve cookbook's dependencies? We used berkshelf-api a while ago and having multiple sources in Berksfile it's wasn't clear which one will be used for each dependency.

On Tue, Aug 26, 2014 at 5:06 PM, Jeff Byrnes <jeff@evertrue.com mailto:jeff@evertrue.com> wrote:
Bernie,

That’s exactly what Supermarket/Chef Server are. In fact, the Chef Server, once it has the Berkshelf-style universe endpoint, will work pretty much exactly like a yum/apt repo; you’ll query it for the collection of cookbooks is has, then dependency resolve based on the results & what you need.

Right now, you need your own Berkshelf API server that’s indexing your Chef Server to do that for your private cookbooks. For public, community cookbooks, the Supermarket provides its own Berkshelf universe endpoint to provide that sort of depsolving.

Supermarket just happens to offer a web UI on top of all of that, which does require the “fancy” bits you speak of, but at its heart, it’s an artifact store & dependency tree.

--
Jeff Byrnes
@berkleebassist http://twitter.com/berkleebassist
Operations Engineer
EverTrue http://www.evertrue.com/
704.516.4628

On August 26, 2014 at 8:43:11 AM, Durfee, Bernie (GE Global Research) (bernie.durfee@ge.com mailto:bernie.durfee@ge.com) wrote:

Why does a cookbook repository need to live behind a fancy server anyway?
A repository, by nature, is static. Wouldn¹t a Yum or Apt style repo with
just files and an index be good enough and simpler? Seems like an S3
bucket and an indexer would be all you need, no?

Bernie

On 8/25/14, 7:32 PM, "AJ Christensen" <aj@junglist.io mailto:aj@junglist.io> wrote:

Another alternative if you need a /universe endpoint is to use Goiardi
[0], the golang chefserver. It's extremely light weight. The
functionality was added recently! [1]

It can run in-memory with optional journals to disk and is completely
suitable for a few hundred cookbooks. For over a couple of thousand
(the full Supermarket universe has been tested!) you'll want
MySQL/PGSQL.

we have heard some reports of users making use of temporal goiardi
instances as part of continuous integration pipeline "environment
generators" where a job can push cookbooks to, automatically!

cheers,

--aj

[0] Goiardi https://ctdk.github.io/goiardi/
[1] https://github.com/ctdk/goiardi/blob/master/CHANGELOG#L21-L24 https://github.com/ctdk/goiardi/blob/master/CHANGELOG#L21-L24

P.S:

launch like this:
goiardi -VVVV -I 127.0.0.1 -H localhostchef.junglist.io <http://localhostchef.junglist.io/> -P 1025 -i goiardi.index -D goiardi.data -A --disable-webui --log-events

On Tue, Aug 26, 2014 at 10:32 AM, Christopher Webber
<cwebber@getchef.com mailto:cwebber@getchef.com> wrote:

So here is where I stand on things (full disclosure, Supermarket is
kinda my thing at Chef):

The Berkshelf API server is perfect if what you want to do is index
what you Chef Server has. It is simple and lightweight.

On the other hand, if what you are trying to do is build an internal
community around cookbooks and want to have a Berkshelf endpoint that
has more than what is on your Chef Server, Supermarket may make more
sense but there is more involved in running it, especially since we
haven¹t built an omnibus package yet.

Supermarket at a base level is a rails app with sidekiq, using postgres
and redis. If you plan to support more than one frontend you will need
to have an S3 compatible backend for storage as well.

Thanks.

‹ cwebber

On Aug 25, 2014, at 2:23 PM, Daniel DeLeo <dan@kallistec.com mailto:dan@kallistec.com> wrote:

On Monday, August 25, 2014 at 2:14 PM, Durfee, Bernie (GE Global
Research) wrote:

Should I be spending time setting up a Berkshelf API server or a
Supermarket server?

Thanks,
Bernie

The answer to this is, it depends on what you want to do.

Supermarket is open source and you are certainly welcome to set up
your own if you like. To run it, you¹ll need to manage a few services
(I haven¹t done this personally, but I think you at least need the
supermarket service and a service called oc-id that uses oauth2 to
authenticate you to supermarket using your enterprise chef credentials).

That said, we have accepted an RFC to implement a ³universe² endpoint
for chef-server that will provide a tool like berkshelf with the data
it needs to solve dependencies so you can host your cookbooks on your
regular Chef server. See:
https://github.com/opscode/chef-rfc/blob/master/rfc014-universe-endpoint https://github.com/opscode/chef-rfc/blob/master/rfc014-universe-endpoint
.md

How are you using Berkshelf API now (or, what configuration were you
considering)?

--
Daniel DeLeo

--
Best regards,
Koldaev Anton

Probably worth mentioning at this point that neither the Berkshelf API server nor Supermarket do any depsolving. They provide a complete index of what they know about and Berkshelf the client handles the actual depsolving.

— cwebber

On Aug 26, 2014, at 7:16 AM, Seth Vargo sethvargo@gmail.com wrote:

no

On Aug 26, 2014, at 10:02 AM, Anton Koldaev koldaevav@gmail.com wrote:

Is there any difference in how berkshelf-api and supermarket resolve cookbook's dependencies? We used berkshelf-api a while ago and having multiple sources in Berksfile it's wasn't clear which one will be used for each dependency.

On Tue, Aug 26, 2014 at 5:06 PM, Jeff Byrnes jeff@evertrue.com wrote:
Bernie,

That’s exactly what Supermarket/Chef Server are. In fact, the Chef Server, once it has the Berkshelf-style universe endpoint, will work pretty much exactly like a yum/apt repo; you’ll query it for the collection of cookbooks is has, then dependency resolve based on the results & what you need.

Right now, you need your own Berkshelf API server that’s indexing your Chef Server to do that for your private cookbooks. For public, community cookbooks, the Supermarket provides its own Berkshelf universe endpoint to provide that sort of depsolving.

Supermarket just happens to offer a web UI on top of all of that, which does require the “fancy” bits you speak of, but at its heart, it’s an artifact store & dependency tree.

--
Jeff Byrnes
@berkleebassist
Operations Engineer
EverTrue
704.516.4628

On August 26, 2014 at 8:43:11 AM, Durfee, Bernie (GE Global Research) (bernie.durfee@ge.com) wrote:

Why does a cookbook repository need to live behind a fancy server anyway?
A repository, by nature, is static. Wouldn¹t a Yum or Apt style repo with
just files and an index be good enough and simpler? Seems like an S3
bucket and an indexer would be all you need, no?

Bernie

On 8/25/14, 7:32 PM, "AJ Christensen" aj@junglist.io wrote:

Another alternative if you need a /universe endpoint is to use Goiardi
[0], the golang chefserver. It's extremely light weight. The
functionality was added recently! [1]

It can run in-memory with optional journals to disk and is completely
suitable for a few hundred cookbooks. For over a couple of thousand
(the full Supermarket universe has been tested!) you'll want
MySQL/PGSQL.

we have heard some reports of users making use of temporal goiardi
instances as part of continuous integration pipeline "environment
generators" where a job can push cookbooks to, automatically!

cheers,

--aj

[0] Goiardi
[1] https://github.com/ctdk/goiardi/blob/master/CHANGELOG#L21-L24

P.S:

launch like this:
goiardi -VVVV -I 127.0.0.1 -H localhostchef.junglist.io -P 1025 -i goiardi.index -D goiardi.data -A --disable-webui --log-events

On Tue, Aug 26, 2014 at 10:32 AM, Christopher Webber
cwebber@getchef.com wrote:

So here is where I stand on things (full disclosure, Supermarket is
kinda my thing at Chef):

The Berkshelf API server is perfect if what you want to do is index
what you Chef Server has. It is simple and lightweight.

On the other hand, if what you are trying to do is build an internal
community around cookbooks and want to have a Berkshelf endpoint that
has more than what is on your Chef Server, Supermarket may make more
sense but there is more involved in running it, especially since we
haven¹t built an omnibus package yet.

Supermarket at a base level is a rails app with sidekiq, using postgres
and redis. If you plan to support more than one frontend you will need
to have an S3 compatible backend for storage as well.

Thanks.

‹ cwebber

On Aug 25, 2014, at 2:23 PM, Daniel DeLeo dan@kallistec.com wrote:

On Monday, August 25, 2014 at 2:14 PM, Durfee, Bernie (GE Global
Research) wrote:

Should I be spending time setting up a Berkshelf API server or a
Supermarket server?

Thanks,
Bernie

The answer to this is, it depends on what you want to do.

Supermarket is open source and you are certainly welcome to set up
your own if you like. To run it, you¹ll need to manage a few services
(I haven¹t done this personally, but I think you at least need the
supermarket service and a service called oc-id that uses oauth2 to
authenticate you to supermarket using your enterprise chef credentials).

That said, we have accepted an RFC to implement a ³universe² endpoint
for chef-server that will provide a tool like berkshelf with the data
it needs to solve dependencies so you can host your cookbooks on your
regular Chef server. See:
https://github.com/opscode/chef-rfc/blob/master/rfc014-universe-endpoint
.md

How are you using Berkshelf API now (or, what configuration were you
considering)?

--
Daniel DeLeo

--
Best regards,
Koldaev Anton

Thanks Seth and Christopher.

On Tue, Aug 26, 2014 at 6:21 PM, Christopher Webber cwebber@getchef.com
wrote:

Probably worth mentioning at this point that neither the Berkshelf API
server nor Supermarket do any depsolving. They provide a complete index of
what they know about and Berkshelf the client handles the actual depsolving.

— cwebber

On Aug 26, 2014, at 7:16 AM, Seth Vargo sethvargo@gmail.com wrote:

no

On Aug 26, 2014, at 10:02 AM, Anton Koldaev koldaevav@gmail.com wrote:

Is there any difference in how berkshelf-api and supermarket resolve
cookbook's dependencies? We used berkshelf-api a while ago and having
multiple sources in Berksfile it's wasn't clear which one will be used for
each dependency.

On Tue, Aug 26, 2014 at 5:06 PM, Jeff Byrnes jeff@evertrue.com wrote:

Bernie,

That’s exactly what Supermarket/Chef Server are. In fact, the Chef
Server, once it has the Berkshelf-style universe endpoint, will work pretty
much exactly like a yum/apt repo; you’ll query it for the collection of
cookbooks is has, then dependency resolve based on the results & what you
need.

Right now, you need your own Berkshelf API server that’s indexing your
Chef Server to do that for your private cookbooks. For public, community
cookbooks, the Supermarket provides its own Berkshelf universe endpoint
to provide that sort of depsolving.

Supermarket just happens to offer a web UI on top of all of that, which
does require the “fancy” bits you speak of, but at its heart, it’s an
artifact store & dependency tree.

--
Jeff Byrnes
@berkleebassist http://twitter.com/berkleebassist
Operations Engineer
EverTrue http://www.evertrue.com/
704.516.4628

On August 26, 2014 at 8:43:11 AM, Durfee, Bernie (GE Global Research) (
bernie.durfee@ge.com) wrote:

Why does a cookbook repository need to live behind a fancy server anyway?
A repository, by nature, is static. Wouldn¹t a Yum or Apt style repo with
just files and an index be good enough and simpler? Seems like an S3
bucket and an indexer would be all you need, no?

Bernie

On 8/25/14, 7:32 PM, "AJ Christensen" aj@junglist.io wrote:

Another alternative if you need a /universe endpoint is to use Goiardi
[0], the golang chefserver. It's extremely light weight. The
functionality was added recently! [1]

It can run in-memory with optional journals to disk and is completely
suitable for a few hundred cookbooks. For over a couple of thousand
(the full Supermarket universe has been tested!) you'll want
MySQL/PGSQL.

we have heard some reports of users making use of temporal goiardi
instances as part of continuous integration pipeline "environment
generators" where a job can push cookbooks to, automatically!

cheers,

--aj

[0] Goiardi
[1] https://github.com/ctdk/goiardi/blob/master/CHANGELOG#L21-L24

P.S:

launch like this:
goiardi -VVVV -I 127.0.0.1 -H localhostchef.junglist.io -P 1025 -i goiardi.index -D goiardi.data -A --disable-webui --log-events

On Tue, Aug 26, 2014 at 10:32 AM, Christopher Webber
cwebber@getchef.com wrote:

So here is where I stand on things (full disclosure, Supermarket is
kinda my thing at Chef):

The Berkshelf API server is perfect if what you want to do is index
what you Chef Server has. It is simple and lightweight.

On the other hand, if what you are trying to do is build an internal
community around cookbooks and want to have a Berkshelf endpoint that
has more than what is on your Chef Server, Supermarket may make more
sense but there is more involved in running it, especially since we
haven¹t built an omnibus package yet.

Supermarket at a base level is a rails app with sidekiq, using
postgres
and redis. If you plan to support more than one frontend you will need
to have an S3 compatible backend for storage as well.

Thanks.

‹ cwebber

On Aug 25, 2014, at 2:23 PM, Daniel DeLeo dan@kallistec.com wrote:

On Monday, August 25, 2014 at 2:14 PM, Durfee, Bernie (GE Global
Research) wrote:

Should I be spending time setting up a Berkshelf API server or a
Supermarket server?

Thanks,
Bernie

The answer to this is, it depends on what you want to do.

Supermarket is open source and you are certainly welcome to set up
your own if you like. To run it, you¹ll need to manage a few services
(I haven¹t done this personally, but I think you at least need the
supermarket service and a service called oc-id that uses oauth2 to
authenticate you to supermarket using your enterprise chef
credentials).

That said, we have accepted an RFC to implement a ³universe² endpoint
for chef-server that will provide a tool like berkshelf with the data
it needs to solve dependencies so you can host your cookbooks on your
regular Chef server. See:

https://github.com/opscode/chef-rfc/blob/master/rfc014-universe-endpoint

.md

How are you using Berkshelf API now (or, what configuration were you
considering)?

--
Daniel DeLeo

--
Best regards,
Koldaev Anton

--
Best regards,
Koldaev Anton