A getting started guide for juju

[whitmo]

A guide for deploying a kubernetes cluster with Juju (https://juju.ubuntu.com/).

[googlebot]

Thanks for your pull request.

It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA) at https://cla.developers.google.com/.

If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check the information on your CLA or see this help article on setting the email on your git commits.

Once you've done that, please reply here to let us know. If you signed the CLA as a corporation, please let us know the company's name.

[erictune]

Would you mind adding a line or lines to https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/getting-started-guides/README.md

[yujuhong]

@whitmo, could you make sure that you sign the CLA? Thanks!
@erictune, are you the right person to review this?

[erictune]

Thanks for getting Kubernetes running on another platform.

I have a couple of questions.

What version of the kubernetes binaries or source does this use, and could
I easily have determined that myself?

Where are the flags for the various binaries set?

On Thu, Feb 19, 2015 at 10:19 AM, Yu-Ju Hong notifications@github.com
wrote:

@whitmo https://github.com/whitmo, could you make sure that you sign
the CLA? Thanks!
@erictune https://github.com/erictune, are you the right person to
review this?

—
Reply to this email directly or view it on GitHub
#4597 (comment)
.

[mbruzek]

Thanks for the feedback on our work.

Currently the v0.8.1 Kubernetes binaries are included in the the files directory of the kubernetes and kubernetes-master charm and that is the default version installed unless the charms are configured to different versions. The gsutils python package is used to pull the Kubernetes binaries if the user configures a version other than default. We are working on a way to build the binaries from source but that is not implemented yet.

https://github.com/whitmo/charm-kubernetes
https://github.com/whitmo/charm-kubernetes-master

In Juju the charms install the software and a bundle defines the Kubernetes system/cluster. The bundle can pass configuration to the charms. For example to install a different version of Kubernetes by passing 'version: v0.10.0' to the options of the charms. We have several bundles that configure different versions of Kubernetes in the specs directory of the Kubernetes bundle.

https://github.com/whitmo/bundle-kubernetes

Thanks!

[whitmo]

Thanks for the quick responses!

@erictune once we get deployment from source landed, we'll default the bundle in github to run from source. In the meantime I guess we should add instructions about how to parameterize a cluster deployment to pick a version.

And we'll update the PR to add info about this to the kubernetes README asap.

@yujuhong we are trying to get the corporate CLA cleared with legal. Hopefully that will all get wrapped up today.

[erictune]

I think it is fine if you only support deployment from binary releases at
first.
I'm trying to work out whether it is practical for the core Kubernetes team
to make updates the flags used by this "Getting Started Guide".

On Mon, Feb 23, 2015 at 8:06 AM, Whit Morriss notifications@github.com
wrote:

Thanks for the quick responses!

@erictune https://github.com/erictune once we get deployment from
source landed, we'll default the bundle in github to run from source. In
the meantime I guess we should add instructions about how to parameterize a
cluster deployment to pick a version.

And we'll update the PR to add info about this to the kubernetes README
asap.

@yujuhong https://github.com/yujuhong we are trying to get the
corporate CLA cleared with legal. Hopefully that will all get wrapped up
today.

—
Reply to this email directly or view it on GitHub
#4597 (comment)
.

[erictune]

Thank you again for this PR. After considerable thought, I'm not going to merge it right now.

There has been a lot of discussion recently about the number of different configurations that we advertise to our users (19 at the moment, here). It is getting quite difficult for the core Kubernetes team to maintain all those combinations. In particular, it is hard for us to support configurations that don't use a configuration distribution mechanism that core team members are familiar with (e.g. saltstack). At the same time, we don't want to visitors to the github repo to see instructions that we can't maintain and that may bitrot.

We are sorry we can't support more configurations right now, but as we sprint towards releasing version 1.0.0, we have to defer some things. We plan to more clearly define the criteria for being a supported configuration, and for being listed in this repo. But, until we are ready to define the requirements, I think it is best to put a hold on accepting new getting-started-guides. Once we define the criteria, we'll clean up the existing list of getting-started-guides too. We'll announce the new criteria when they are ready on kubernetes-announce@googlegroups.com (a low-traffic list).

I'd encourage you to share the Juju getting-started-guide on another repo or blog. And we still welcome code contributions.

[whitmo]

@erictune thanks for taking the time for consideration and I understand the time constraints and changes that occur as a project approaches 1.0. We expect to maintain the getting started guide just as we maintain the opensource projects for the charms and bundle for deploying kubernetes with juju and will be happy to contribute if and when it's appropriate.

[brendandburns]

After some further discussion w/ folks here, I'm re-opening this. @erictune and I dug in and came up with the requirements that we need to make sure we are making the right statements to users who may come across it in the future. Namely:

• Please update the matrix of supported platform/os contributions, indicating the concrete binary version that you tested, the date it was tested, and the github user (@whitmo) that tested it.
• Please add this same information to the documentation in your juju.md as well.
• Any future version revisions to support future versions should come in the form of a PR to rev. the statements above.

It would be great if you also ran CI for this and notified us of build breaks as issues, although that is not a hard requirement.

Thanks for your help and patience as we figure this stuff out.
Best
--brendan

[lazypower]

Thank you for taking a look at our proposal @brendanburns and @erictune

I've taken a look at the requested feedback and I've addressed the issues with adding Juju to the getting started README.md, and put links in the table to our CI results in the Juju getting started guide under cloud integration.

Our Matrix would be slightly different than most listed here, as we're working across all substrates, and this would make your integration table huge. I don't want to be presumptuous about implementation, and left the detailed view to our scoped Juju getting started guide.

@brendandburns we're actively working on the CI stack with regard to our Kubernetes bundles, and would like to offer that level of integration. I'll have more details about that as work starts to land that will enable this.

[erictune]

LGTM