team support for managing cookbooks

prometheanfire commented 10 years ago

I'd like to see teams able to be created and managed.

This will help us manage the users on more then one cookbook at a time (we plan on managing a few cookbooks) as people move around.

This would be for ongoing cookbook user management, just just a one time thing.

jtimberman commented 10 years ago

I'd love to see this as well, since we at CHEF have several people that need to update cookbooks, and adding everyone to "collaborators" for all of them is tedious.

paulmooring commented 10 years ago

+1 on this, it sounds useful

sethvargo commented 10 years ago

I'd like to see something very similar to GitHub's organizations with a permission model as well.

tristanoneil commented 10 years ago

So we're trying to understand the ideal implementation for this a bit better. Are there any users that can chime in that are owners of many cookbooks as to how this should ideally function? We'll need to consider how we'll handle things from the knife side of things as well since you'll need the ability to specify the team or organization you're sharing a new cookbook as.

It's worth noting that based on a production dump from about 5 months ago there aren't many users on Supermarket that have a large number of cookbooks. There are only 8 users with 20 or more cookbooks the majority of users have 1 - 4 cookbooks. So I think the current use of this feature would target a smaller audience.

prometheanfire commented 10 years ago

we (rackspace) have a few cookbooks, but no clear group yet, I estemate we will end up with 20+ cookbooks though. I don't think we need the ability to control which group we upload as, as long as we are a member of a group that has permission to upload.

upload cookbook (initial)
change owner to group
group admin adds people with permission to upload
people can now upload

leftathome commented 10 years ago

Honestly, I would LOVE to be able to pull group data from another source rather than manage this in Supermarket. Most enterprise-y users will no doubt be familiar with jumping through hoops in order to get a new team member added to all of the access groups in access systems that don't talk to each other (either by casual or intentional design stupidity).

Would OC-ID be the right place to determine a Chef-tool-user's group memberships? No reason to force them to be local to each tool, surely?

smith commented 10 years ago

@leftathome yes, oc-id might be the right place to determine that. We've had some internal discussion about using oc-id for this with regard to the group membership on the Chef server itself.

While in normal cases we don't want Supermarket teams and Chef server organizations to be connected, if oc-id had the capability to resolve those groups, we could use it for either.

I can tell you that any plans to do this kind of thing are not in the immediate future for Chef Software, but a pull request on oc-id that implemented something would absolutely be considered.

leftathome commented 10 years ago

Kicking the tires some more on Supermarket internally - we're definitely going to need this. We have a number of teams who are rather emotionally invested in certain cookbooks or sets of cookbooks. It actually probably makes more sense to have individual users or teams be cookbook collaborators. This would allow a co-ownership / stewardship model.

Some of this information could come from GitHub, not necessarily an LDAP-ish corporate data store. Have you thought about pushing some of the GitHub integration up into OC-ID? Then users have the option of providing group data from some or all available sources.

I'd love to provide you with a PR. Also a signed CCLA. That's still not quite done yet so until then I'm limited to what I can do in my off-hours and my quiet coding time is severely constrained these days.

Though maybe if I could make it to the hack day next month...

prometheanfire commented 9 years ago

Is this on the roadmap at all or still just a feature request?