Re: kubernetes
On Thu, Oct 30, 2014 at 2:00 PM, Kapil Thangavelu kapil.thangav...@canonical.com wrote: Hi Folks, I wrote up some kubernetes charms and a bundle to make it easy to deploy kubernetes on different clouds and baremetal via juju. Kubernetes is a docker container management system from google with support for health checks, round robin upgrades, load balancers, etc. To get started you can use juju-quickstart or juju-deployer ala juju-quickstart \ https://raw.githubusercontent.com/kapilt/bundle-kubernetes/master/bundles.yaml more instructions over here https://github.com/kapilt/bundle-kubernetes and of course at the project site https://github.com/GoogleCloudPlatform/kubernetes Solid work Kapil. Thanks for getting this charmed out so of folks can easily give Kubernetes a spin. -Antonio cheers, Kapil -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: how to update dependencies.tsv
On 29 October 2014 21:03, Tim Penhey tim.pen...@canonical.com wrote: On 30/10/14 01:11, roger peppe wrote: A better solution here, which I've been meaning to do for a while, would be to change godeps so that it can explore all possible targets. I had a go at that this morning (just adding all tags to build.Context) but it's not quite as easy as that. I should be able to fix it soon though. While you are looking at godeps, I don't suppose you can fix it so it looks for the upstream remote? As things currently are, godeps doesn't know about any remote in particular, and I think that's probably correct - it just uses git fetch (with no arguments) to fetch, and relies on the defaults for that. I was told that we should have the origin remote being our personal github repo and upstream being the team repo. I actually think that this is not a great way to configure things. When you clone a git repository (for example by doing go get) there is only one remote configured, and that's origin. So if I changed godeps to pull from upstream, it would have to fall back to pulling from origin in this, the most common case. Personally, I find the very word upstream confusing when used in this area - information flows both ways. The one certainty is that everything is destined for the main repo, so naming that origin makes sense to me. I never create a repo named upstream - I have origin and I name other remotes after github users, e.g. rogpeppe, which seems to scale better when I'm collaborating with other people. When godeps tries to pull in new revisions into a repo where I have the remotes set as I was told to, godeps fails to pull in new revisions and I normally do something like: (cd ../names git fetch upstream master) Then run the godeps command again. All the above said, I don't think there's anything stopping you from using this. Just do: git branch --set-upstream-to upstream/master and I think it should work (though I haven't actually tried it) cheers, rog. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Menno's reviewer graduation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30.10.2014 03:13, Tim Penhey wrote: Hey there fellow Juju developers, I'd like to announce Menno's reviewer graduation. I have been very happy with the quality and understanding shown in Menno's reviews. Congratulations. Tim Yay, way to go Menno! :) I think this should encourage other mentored reviewers to heed the call and graduate. Cheers, - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUUgcPAAoJENzxV2TbLzHwGmEIAIh6Flv+HKF9UGTCUY6dezGU LhoqeCbhSdJB4dyazITcHN+akdYXuR9OEBmbr1rzripAFiwWRiLz1O6SPGRpL4de 4Gq4Gzpd4RooLIBncnQOCWX6eGv01AVohxdBC06xaX2Ne94dm/vxdVcJ3JR1NY9O aPHa5cu/6+CNo9A9lULl5Vm2tS+IrMWSd/gfNxCXektz0Kv2RApOC1gNdfB3uvnT uNcOyOATntBkr02ewzd0SgqOK57vVjbtuUv5+PVw4bFt3wC3+pB+wHROjxOuPAjM gjVTn+MVotCJHuGT0FPmYfcP9jcR6qho1MXTSbj4R5Fdm/X8XiWDUGL3ehgNjJY= =hpNO -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: how to update dependencies.tsv
Upstream and origin are very very common in the git world. Most any how to or stack overflow answer uses those by default. Origin is your repo and upstream is the repo you branched from. I started out doing it your way, Roger, since I agree that information does flow both ways, and naming my repo after myself made sense, but I got so annoyed with every answer I looked up using origin and upstream that I changed to just use those terms. Using standard terms is a good thing so we all know what we're talking about. On Oct 30, 2014 4:22 AM, roger peppe roger.pe...@canonical.com wrote: On 29 October 2014 21:03, Tim Penhey tim.pen...@canonical.com wrote: On 30/10/14 01:11, roger peppe wrote: A better solution here, which I've been meaning to do for a while, would be to change godeps so that it can explore all possible targets. I had a go at that this morning (just adding all tags to build.Context) but it's not quite as easy as that. I should be able to fix it soon though. While you are looking at godeps, I don't suppose you can fix it so it looks for the upstream remote? As things currently are, godeps doesn't know about any remote in particular, and I think that's probably correct - it just uses git fetch (with no arguments) to fetch, and relies on the defaults for that. I was told that we should have the origin remote being our personal github repo and upstream being the team repo. I actually think that this is not a great way to configure things. When you clone a git repository (for example by doing go get) there is only one remote configured, and that's origin. So if I changed godeps to pull from upstream, it would have to fall back to pulling from origin in this, the most common case. Personally, I find the very word upstream confusing when used in this area - information flows both ways. The one certainty is that everything is destined for the main repo, so naming that origin makes sense to me. I never create a repo named upstream - I have origin and I name other remotes after github users, e.g. rogpeppe, which seems to scale better when I'm collaborating with other people. When godeps tries to pull in new revisions into a repo where I have the remotes set as I was told to, godeps fails to pull in new revisions and I normally do something like: (cd ../names git fetch upstream master) Then run the godeps command again. All the above said, I don't think there's anything stopping you from using this. Just do: git branch --set-upstream-to upstream/master and I think it should work (though I haven't actually tried it) cheers, rog. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: how to update dependencies.tsv
On 30 October 2014 09:47, Nate Finch nate.fi...@canonical.com wrote: Upstream and origin are very very common in the git world. Most any how to or stack overflow answer uses those by default. Origin is your repo and upstream is the repo you branched from. I started out doing it your way, Roger, since I agree that information does flow both ways, and naming my repo after myself made sense, but I got so annoyed with every answer I looked up using origin and upstream that I changed to just use those terms. Using standard terms is a good thing so we all know what we're talking about. It's a pity then that if you go get a package, origin is the repo you've branched from. There is always one of those, but you don't necessary have a fork of the repo yourself. Hence I think that it's worth reconsidering this for our Go-centric world. It's good to have things work correctly by default. Also, as I said, godeps doesn't have any special preference for upstream or origin - it just does a git fetch. It's interesting to read in the comments on the top answer in this SO question: http://stackoverflow.com/questions/9257533/what-is-the-difference-between-origin-and-upstream-in-github : It is worth mentioning in context of github it makes more sense to have origin be the master-repo and use github username as the remote name for your and other forks. Tools like defunkt.io/hub does this and makes working with repositories and collaborating across forks much more uniform. So I'm not the only one that feels this way. On Oct 30, 2014 4:22 AM, roger peppe roger.pe...@canonical.com wrote: On 29 October 2014 21:03, Tim Penhey tim.pen...@canonical.com wrote: On 30/10/14 01:11, roger peppe wrote: A better solution here, which I've been meaning to do for a while, would be to change godeps so that it can explore all possible targets. I had a go at that this morning (just adding all tags to build.Context) but it's not quite as easy as that. I should be able to fix it soon though. While you are looking at godeps, I don't suppose you can fix it so it looks for the upstream remote? As things currently are, godeps doesn't know about any remote in particular, and I think that's probably correct - it just uses git fetch (with no arguments) to fetch, and relies on the defaults for that. I was told that we should have the origin remote being our personal github repo and upstream being the team repo. I actually think that this is not a great way to configure things. When you clone a git repository (for example by doing go get) there is only one remote configured, and that's origin. So if I changed godeps to pull from upstream, it would have to fall back to pulling from origin in this, the most common case. Personally, I find the very word upstream confusing when used in this area - information flows both ways. The one certainty is that everything is destined for the main repo, so naming that origin makes sense to me. I never create a repo named upstream - I have origin and I name other remotes after github users, e.g. rogpeppe, which seems to scale better when I'm collaborating with other people. When godeps tries to pull in new revisions into a repo where I have the remotes set as I was told to, godeps fails to pull in new revisions and I normally do something like: (cd ../names git fetch upstream master) Then run the godeps command again. All the above said, I don't think there's anything stopping you from using this. Just do: git branch --set-upstream-to upstream/master and I think it should work (though I haven't actually tried it) cheers, rog. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: how to update dependencies.tsv
I have never used upstream as an actual remote name. I see people commonly using the term as a wildcard to refer to the upstream branch whatever it is. The term is also used widely in git itself with the same meaning, including in the command line interface. For example, you set the upstream branch with --set-upstream (or -u for short), and in most cases people set their origin branch as upstream. Most posts in StackOverflow follow that: http://stackoverflow.com/search?q=%5Bgit%5D+upstream This confirms what Roger pointed out: upstream is well established as a concept, not as a remote label, so it's best to use a well defined name that points out where the code was taken from, rather than overloading the term to mean something else. On Thu Oct 30 2014 at 7:47:49 AM Nate Finch nate.fi...@canonical.com wrote: Upstream and origin are very very common in the git world. Most any how to or stack overflow answer uses those by default. Origin is your repo and upstream is the repo you branched from. I started out doing it your way, Roger, since I agree that information does flow both ways, and naming my repo after myself made sense, but I got so annoyed with every answer I looked up using origin and upstream that I changed to just use those terms. Using standard terms is a good thing so we all know what we're talking about. On Oct 30, 2014 4:22 AM, roger peppe roger.pe...@canonical.com wrote: On 29 October 2014 21:03, Tim Penhey tim.pen...@canonical.com wrote: On 30/10/14 01:11, roger peppe wrote: A better solution here, which I've been meaning to do for a while, would be to change godeps so that it can explore all possible targets. I had a go at that this morning (just adding all tags to build.Context) but it's not quite as easy as that. I should be able to fix it soon though. While you are looking at godeps, I don't suppose you can fix it so it looks for the upstream remote? As things currently are, godeps doesn't know about any remote in particular, and I think that's probably correct - it just uses git fetch (with no arguments) to fetch, and relies on the defaults for that. I was told that we should have the origin remote being our personal github repo and upstream being the team repo. I actually think that this is not a great way to configure things. When you clone a git repository (for example by doing go get) there is only one remote configured, and that's origin. So if I changed godeps to pull from upstream, it would have to fall back to pulling from origin in this, the most common case. Personally, I find the very word upstream confusing when used in this area - information flows both ways. The one certainty is that everything is destined for the main repo, so naming that origin makes sense to me. I never create a repo named upstream - I have origin and I name other remotes after github users, e.g. rogpeppe, which seems to scale better when I'm collaborating with other people. When godeps tries to pull in new revisions into a repo where I have the remotes set as I was told to, godeps fails to pull in new revisions and I normally do something like: (cd ../names git fetch upstream master) Then run the godeps command again. All the above said, I don't think there's anything stopping you from using this. Just do: git branch --set-upstream-to upstream/master and I think it should work (though I haven't actually tried it) cheers, rog. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/ mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: User Management part 1 all there for 1.21
2014-10-30 3:54 GMT+03:00 Tim Penhey tim.pen...@canonical.com: This is just the start of more magical things to come. The Onyx team is focused on enabling multiple environments within a single juju deployment. This means that there will be able to be multiple running independent juju environments running through one state server (or highly available state server collection). As this ability gets closer to reality we'll start seeing more commands around listing environments, and sharing environments with other users. Nice! I'm ready to test this when it can be tested =)) -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
deprecating the juju-backup (and juju-restore) CLI plugin
The new juju backups create can be used instead of juju backup (a CLI plugin). So you would think we could deprecate and later remove the old plugin. Unfortunately, juju backups create won't work with 1.20 or earlier API servers. So it's not quite as simple as I'd hoped as long as newer clients will be connecting to older servers. What would be the best approach for deprecating the old backup plugin? I was going to simply gut it (it's a bash script) and stick in a deprecation warning message and a call to juju backups create --download. However, jam rightly pointed out to me that this may be a sticky situation (as described above). I'd really like to find a way to eliminate the old backup implementation. Thoughts? -eric -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: how to update dependencies.tsv
On Thu, Oct 30, 2014 at 10:34 PM, Eric Snow eric.s...@canonical.com wrote:
On Thu, Oct 30, 2014 at 4:40 AM, roger peppe roger.pe...@canonical.com
wrote:
It's a pity then that if you go get a package, origin is the repo
you've branched from. There is always one of those, but you
don't necessary have a fork of the repo yourself.
Why wouldn't you want go get to fetch from your clone by default?
Naturally master on origin should be match upstream, which may require
you to pull-upstream-push-origin.
Why naturally? I don't use master in my fork of juju, I just use
feature/bug branches.
The master branch in my repo tracks upstream/master.
For local clones in my $GOPATH
where I'm not doing development (i.e. ones created by go get), I don't
have upstream set and origin still points to github (or wherever). So
the behavior of go get works fine for me.
As to making godeps honor the upstream remote, the focus for godeps
should be on what's in each official repo. The revisions in our
dependencies.tsv should be coming only from there. If it's
conventional to use upstream for those official remotes (it *is* our
recommended convention in {juju}/CONTRIBUTING), then it would be nice
for godeps to try it first. The alternative is that folks be more
diligent about making sure their origin clones are up-to-date with
upstream, which is sometimes easy to do before running godeps.
-eric
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
