Re: arch constraint default changed?
On Wed, May 14, 2014 at 4:28 AM, William Reade william.re...@canonical.comwrote: We shouldn't ever have to worry about whether or not --upload-tools was used, because it's *already* been used at the point where we pick instances, and the single possible arch is thus already chosen, entirely independent of constraints or anything else. The only question should be: given *multiple* possible architectures to launch, with nothing else to decide between them, which do we pick? The original algorithm was amd64 if available; if not, first alphabetical. I still think that'd be better than what we have, but as our options expand I think I'd prefer to go with first alphabetical 64-bit arch, falling back to first alphabetical. Dissent? I am working on implementing this algorithm as a part of fixing https://bugs.launchpad.net/juju-core/+bug/1262967 Cheers William On Tue, May 13, 2014 at 3:59 PM, Nate Finch nate.fi...@canonical.comwrote: For what it's worth, I agree with everyone. John and I discussed it, and I thought we had decided that we needed to use the local arch because of upload tools, evidently John though we'd decided in the other direction. And Gustavo is right that we should have pushed the discussion to the mailing list regardless. I didn't want the local arch have any influence on the arch we pick, unless the user uses --upload-tools, because as Gustavo said, where I'm sitting right now shouldn't affect what architecture my cloud uses. Honestly, the reason I didn't code the fix to take --upload-tools into consideration is because that was going to be more complicated and I didn't have time for it (the fix I made was tiny and quick). Perhaps that was a misjudgment, and perhaps if we had moved the question to the mailing list it would have become obvious the time would be worth it. If people think it's worth it, we can just go ahead and make the right fix to use the local arch only when we use --upload-tools, but it still doesn't help us with the problem of which one we pick if they don't use upload tools, and multiple arches are available. What logic would people recommend? I don't think alphabetical is really the best choice, though at least it's deterministic, unlike take whatever happens to be listed first which is what we seemed to be doing before. On Tue, May 13, 2014 at 8:17 AM, Gustavo Niemeyer gust...@niemeyer.netwrote: On Tue, May 13, 2014 at 8:18 AM, John Meinel j...@arbash-meinel.com wrote: FWIW, I've gotten bug requests from a user that did a regular bootstrap and then was trying to juju upgrade-juju --upload-tools and was confused that his local machine wasn't able to upgrade tools for his environment. (he was running i386 locally, and bootstrap created an amd64 machine). And while we desperately want to not expose --upload-tools in its current incarnation, we haven't given an alternative for those use cases. There's nothing wrong with tweaking constraints if the application sees the --upload-tools option. At the same time, getting a bug from a user is not enough reason to tweak the defaults for everybody. Also, while we have a reasonably clear model for if you have the choice between amd64 and i386 pick amd64, I don't think people disagree with that. But what if you have the choice between amd64 and ppc64le and the client is running on ppc64le? Is it likely that they are actually thinking in a ppc world? I don't see how that logic holds. Using an arm laptop as a client does not imply I want to use all my server deployments on arm. The same holds true for the operating system, or to the Ubuntu series, or to pretty much anything else: I would not expect the tool to deploy a completely different environment based on where I'm sitting this second. We certainly had a lot of discussions around this between Nate and myself, and while I think I was reasonably convinced that we could just pick amd64 if it was an option, it seems he was also reasonably convinced that we'd want to use the client arch if available. (He wrote it as just pick amd64, I argued against it but ended up feeling it was a reasonable pick among alternatives, but then he changed it before landing.) If I had the chance, I would submit these kinds of decisions to the development mailing list, rather than arbitrating it back and forth in isolation like that. This is changing the default behavior for everybody, so sending it for the team's appraisal feels cheap. gustavo @ http://niemeyer.net -- 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 -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list
Problem deploying test charm
Hi all, I am trying to create an ownCloud charm with Ceph support. (I already had a more or less working dev version) When I try to deploy my latest revision, juju doesn’t seem to get the latest (local) revision. I noticed this, as I had a typo in my config.yaml (For your info: My MaaS environment is Ubuntu 14.04 based, but my juju nodes are 12.04) Xander signature.asc Description: Message signed with OpenPGP using GPGMail -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Problem deploying test charm
On Fri, May 16, 2014 at 11:15 AM, Xander Maas xjm...@gmail.com wrote: Hi all, I am trying to create an ownCloud charm with Ceph support. (I already had a more or less working dev version) When I try to deploy my latest revision, juju doesn’t seem to get the latest (local) revision. I noticed this, as I had a typo in my config.yaml It may not be the same reason, but I have seen this when I've got multiple copies of the same charm in my local JUJU_REPOSITORY, ie. something like: ~/myrepo/precise/my-charm and ~/myrepo/precise/an-older-charm-version juju uses the first charm which matches name in the metadata, so you want to move any old charm versions out of your juju repo. Another reason can be that the version of the charm that your bootstrap node has cached is greater than the one you're deploying, but you shouldn't normally get into that situation. -Michael -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
[ANN] charmworldlib 0.4.0
Hello all, charmworldlib is a Python library designed to make interfacing with the Charmworld API in Python easy. Today charmworldlib 0.4.0 was released which brings the project up to feature parity with the bundles API endpoint in charmworld (many thanks to Tim Van Steenburgh for his work making this happen). Also, charmworldlib is available as both a python2 and python3 package. (python-charmworldlib and python3-charmworldlib) # Installing/Upgrading For Ubuntu users, add ppa:juju/stable if you haven't already and run the following ``` sudo apt-get update sudo apt-get install python-charmworldlib python3-charmworldlib ``` For other users, charmworldlib is available on pypi https://pypi.python.org/pypi/charmworldlib/0.4.0 and via pip: `pip install charmworldlib` # Changes - [lp:1319178] Bundle searching doesn't exist # Support The 0.4.1 milestone has been opened for any bugs which may arise. At this time no 0.5 series is planned as the charmworld API has no future versions planned. Support for charmworldlib is available via bug reporting at https://bugs.launchpad.net/charmworldlib Thanks, Marco Ceppi, on behalf of the Juju Solutions team -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Clarifying cloud-specific charms in the store
Hi everyone, As part of the review process for the backup charm this came up: https://bugs.launchpad.net/charms/+bug/1259630 Policy states: Should not use anything infrastructure-provider specific (i.e. querying EC2 metadata service) Note that this is a should, not a must, in the same way that charms should use apparmor, but we don't nack things when they don't. We had a quick discussion on IRC and this is what I am proposin, clarify policy on cloud specific charms by stating: - Charms that use cloud specific features should have these as options whenever possible - Charms that exist soley to provide cloud specific features should be obvious, like aws-rds-database or something; a generic service name like say haproxy should work on all clouds. Charms should strive to be cloud-agnostic, but do we want to strictly stop people from making optimized charms for their specific providers? The charm store will make it obvious to users on what clouds the charm runs on anyway. -- Jorge Castro Canonical Ltd. http://juju.ubuntu.com/ - Automate your Cloud Infrastructure -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Ubuntu Vagrant boxes with Juju
Trusty images are now available, testing on these is greatly appreciated: http://cloud-images.ubuntu.com/vagrant/trusty/current/ On Thu, May 15, 2014 at 2:50 PM, Sebastian sebas5...@gmail.com wrote: Can Ben share your Vagrantfile code to see if I can help too :) As per the IRC discussion Chuck will push the work to github as part of the charm school today. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Ubuntu Vagrant boxes with Juju
Awesome! Thanks! Abs, Sebas. Enviado pelo meu celular. Em 16/05/2014, às 10:56, Jorge O. Castro jo...@ubuntu.com escreveu: Trusty images are now available, testing on these is greatly appreciated: http://cloud-images.ubuntu.com/vagrant/trusty/current/ On Thu, May 15, 2014 at 2:50 PM, Sebastian sebas5...@gmail.com wrote: Can Ben share your Vagrantfile code to see if I can help too :) As per the IRC discussion Chuck will push the work to github as part of the charm school today. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Problem deploying test charm
Hi Matt and Michael, That was the 'problem'. I now can deploy my test ownCloud unit, with (alpha) Ceph support. My additions for Ceph is quite basic and needs some additional testing before I commit a new 'build' I hope to do so coming week Xander Sent from my iPhone On 16 mei 2014, at 17:18, Matt Bruzek matthew.bru...@canonical.com wrote: Xander, Michael is correct the charm name is based on the name in the metadata.yaml file not the directory. So watch out for that. Are you working on adding support for ceph in the current owncloud charm? If so please work with José Antonio Rey j...@ubuntu.com I am reviewing the owncloud charm right now: https://code.launchpad.net/~jose/charms/precise/owncloud/port-change+repo+ssl-support/+merge/215527 Thank you, - Matt Bruzek matthew.bru...@canonical.com On Fri, May 16, 2014 at 4:24 AM, Michael Nelson michael.nel...@canonical.com wrote: On Fri, May 16, 2014 at 11:15 AM, Xander Maas xjm...@gmail.com wrote: Hi all, I am trying to create an ownCloud charm with Ceph support. (I already had a more or less working dev version) When I try to deploy my latest revision, juju doesn’t seem to get the latest (local) revision. I noticed this, as I had a typo in my config.yaml It may not be the same reason, but I have seen this when I've got multiple copies of the same charm in my local JUJU_REPOSITORY, ie. something like: ~/myrepo/precise/my-charm and ~/myrepo/precise/an-older-charm-version juju uses the first charm which matches name in the metadata, so you want to move any old charm versions out of your juju repo. Another reason can be that the version of the charm that your bootstrap node has cached is greater than the one you're deploying, but you shouldn't normally get into that situation. -Michael -- 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: [Proposal] Requiring Go 1.2 across the board
On Fri, May 16, 2014 at 3:08 PM, David Cheney david.che...@canonical.comwrote: Hello, This is a proposal that we raise the minimum Go spec from Go 1.1 to Go 1.2. Motivation: * Now that T is out, we have to support Juju on two series (Precise and Trusty[1]) with two compilers, gc and gccgo. * gccgo-4.9, which is version we using in trusty, supports the Go 1.2 spec * gc-1.1.2 which is available in a ppa for precise, obviously supports Go 1.1 * gc-1.2.1 is the shipping compiler on Trusty, it supports Go 1.2 So now we have three compilers, two versions of gc, and one of gccgo. We are in the situation where code written for gccgo under T on ppc64 or armv8 will not pass the bot running Go 1.1.1. For this reason I would like to reduce this matrix. Recommendation: * Get the trusty compiler into a backport ppa for precise[1] * Upgrade the bot to use that compiler, raising the minimum compiler spec to 1.2 across the board SGTM. The bot will be changing soon to a Jenkins lander; seems like an opportune time for making the change. Thoughts / Discussion / Spoiled fruit ? Dave [1] I am ignoring the intermediate, non LTS series', as there are no charms for them, nor do CTS offer support for them. If this is unacceptable, anything which applies to Precise wrt. backports, also applies to Q, R and S. -- 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: [Proposal] Requiring Go 1.2 across the board
William, could you please raise this at the team leads meeting tonight on my behalf. The steps look quite straight forward, they just need to go on a card and get done. On Fri, May 16, 2014 at 5:53 PM, William Reade william.re...@canonical.com wrote: +1 On Fri, May 16, 2014 at 9:18 AM, Andrew Wilkins andrew.wilk...@canonical.com wrote: On Fri, May 16, 2014 at 3:08 PM, David Cheney david.che...@canonical.com wrote: Hello, This is a proposal that we raise the minimum Go spec from Go 1.1 to Go 1.2. Motivation: * Now that T is out, we have to support Juju on two series (Precise and Trusty[1]) with two compilers, gc and gccgo. * gccgo-4.9, which is version we using in trusty, supports the Go 1.2 spec * gc-1.1.2 which is available in a ppa for precise, obviously supports Go 1.1 * gc-1.2.1 is the shipping compiler on Trusty, it supports Go 1.2 So now we have three compilers, two versions of gc, and one of gccgo. We are in the situation where code written for gccgo under T on ppc64 or armv8 will not pass the bot running Go 1.1.1. For this reason I would like to reduce this matrix. Recommendation: * Get the trusty compiler into a backport ppa for precise[1] * Upgrade the bot to use that compiler, raising the minimum compiler spec to 1.2 across the board SGTM. The bot will be changing soon to a Jenkins lander; seems like an opportune time for making the change. Thoughts / Discussion / Spoiled fruit ? Dave [1] I am ignoring the intermediate, non LTS series', as there are no charms for them, nor do CTS offer support for them. If this is unacceptable, anything which applies to Precise wrt. backports, also applies to Q, R and S. -- 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 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
What is required to switch back to using the tip of goose ?
Why is the Openstack provider pinned to an old version of lauchpad.net/goose ? What is required to use the latest version ? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: [Proposal] Requiring Go 1.2 across the board
I believe the team lead meeting is last night, not tonight. I'm fine with this, AFAIK the only specific change that needs to be made is to get golang-go 1.2.* into ppa:juju/golang. I hope the people (Curtis and Ian) are still planning on configuring the new Jenkins lander as a Precise machine, since I still expect that to be the place where we are the most likely to accidentally break things. (Most developers will be running Trusty, so are likely to catch issues there.) John =:- On Fri, May 16, 2014 at 11:56 AM, David Cheney david.che...@canonical.comwrote: William, could you please raise this at the team leads meeting tonight on my behalf. The steps look quite straight forward, they just need to go on a card and get done. On Fri, May 16, 2014 at 5:53 PM, William Reade william.re...@canonical.com wrote: +1 On Fri, May 16, 2014 at 9:18 AM, Andrew Wilkins andrew.wilk...@canonical.com wrote: On Fri, May 16, 2014 at 3:08 PM, David Cheney david.che...@canonical.com wrote: Hello, This is a proposal that we raise the minimum Go spec from Go 1.1 to Go 1.2. Motivation: * Now that T is out, we have to support Juju on two series (Precise and Trusty[1]) with two compilers, gc and gccgo. * gccgo-4.9, which is version we using in trusty, supports the Go 1.2 spec * gc-1.1.2 which is available in a ppa for precise, obviously supports Go 1.1 * gc-1.2.1 is the shipping compiler on Trusty, it supports Go 1.2 So now we have three compilers, two versions of gc, and one of gccgo. We are in the situation where code written for gccgo under T on ppc64 or armv8 will not pass the bot running Go 1.1.1. For this reason I would like to reduce this matrix. Recommendation: * Get the trusty compiler into a backport ppa for precise[1] * Upgrade the bot to use that compiler, raising the minimum compiler spec to 1.2 across the board SGTM. The bot will be changing soon to a Jenkins lander; seems like an opportune time for making the change. Thoughts / Discussion / Spoiled fruit ? Dave [1] I am ignoring the intermediate, non LTS series', as there are no charms for them, nor do CTS offer support for them. If this is unacceptable, anything which applies to Precise wrt. backports, also applies to Q, R and S. -- 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 -- 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: What is required to switch back to using the tip of goose ?
AFAIK there is one patch which landed a couple of days ago that changes an API that used to only return an io.ReadCloser, error that now returns io.ReadCloser, Headers, error, and we can safely ignore the Headers (someone else needed it who wanted to use goose). I think the only reason we aren't running an updated version is because nobody has cared to do so. I believe it is a 3 character fix for Get() but I haven't really tested the rest. John =:- On Fri, May 16, 2014 at 12:47 PM, David Cheney david.che...@canonical.comwrote: Why is the Openstack provider pinned to an old version of lauchpad.net/goose ? What is required to use the latest version ? -- 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: What is required to switch back to using the tip of goose ?
There also appears to be a small API breakage # launchpad.net/juju-core/provider/openstack provider/openstack/storage.go:59: assignment count mismatch: 2 = 3 On Fri, May 16, 2014 at 7:48 PM, John Meinel j...@arbash-meinel.com wrote: AFAIK there is one patch which landed a couple of days ago that changes an API that used to only return an io.ReadCloser, error that now returns io.ReadCloser, Headers, error, and we can safely ignore the Headers (someone else needed it who wanted to use goose). I think the only reason we aren't running an updated version is because nobody has cared to do so. I believe it is a 3 character fix for Get() but I haven't really tested the rest. John =:- On Fri, May 16, 2014 at 12:47 PM, David Cheney david.che...@canonical.com wrote: Why is the Openstack provider pinned to an old version of lauchpad.net/goose ? What is required to use the latest version ? -- 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: What is required to switch back to using the tip of goose ?
Oh yes, we are talking about the same thing. I'll propose a branch On Fri, May 16, 2014 at 7:50 PM, David Cheney david.che...@canonical.com wrote: There also appears to be a small API breakage # launchpad.net/juju-core/provider/openstack provider/openstack/storage.go:59: assignment count mismatch: 2 = 3 On Fri, May 16, 2014 at 7:48 PM, John Meinel j...@arbash-meinel.com wrote: AFAIK there is one patch which landed a couple of days ago that changes an API that used to only return an io.ReadCloser, error that now returns io.ReadCloser, Headers, error, and we can safely ignore the Headers (someone else needed it who wanted to use goose). I think the only reason we aren't running an updated version is because nobody has cared to do so. I believe it is a 3 character fix for Get() but I haven't really tested the rest. John =:- On Fri, May 16, 2014 at 12:47 PM, David Cheney david.che...@canonical.com wrote: Why is the Openstack provider pinned to an old version of lauchpad.net/goose ? What is required to use the latest version ? -- 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: Making juju work better with gccgo
FWIW, I wrote this little bash function and put it in my ~/.bashrc
function gotest {
p=-gocheck.v
f=
if [ -n $1 ]; then
if [ $1 = -r ]; then
p=./...
else
f=-gocheck.f=$f
fi
fi
go test $p $f go test -compiler=gccgo $p $f
}
That lets my write:
gotest
gotest -r
and
gotest justOneSuite
I'm sure something better could be done, but that makes things immediately
useful.
The compile time is noticeably slower at getting the tests running (so this
slows down iteration 2x), but until gccgo is ironed out it is probably
still worthwhile.
John
=:-
On Fri, May 16, 2014 at 6:53 AM, David Cheney david.che...@canonical.comwrote:
Thanks Tim,
I think we're in the position that even if you don't use gccgo for
your own development (understandable, it is slower), now that we have
platforms we support in Trusty that must use gccgo, armv8 and ppc64el,
for any new development, the code has to pass under both compilers.
This is a bit of a bummer, but at least if you are running trusty on
your development environment, you have all the bits you need[1][2].
Running tests, for a single package then becomes
go test go test -compiler=gccgo
With respect to the whole Juju test suite, even after months of work
there still remain a few tests which do not pass under trusty, these
are tracked with bugs in lp, just look for the gccgo label if you find
yourself at a loose end.
Cheers
Dave
[1] Prior to trusty, you'd probably be using gccgo-4.8, which is not
of acceptable quality for use with Juju.
[2] If for some reason you don't want to upgrade to trusty, we may be
able to ask Doko for a backport of gccgo-4.9, but really, just upgrade
to trusty.
On Fri, May 16, 2014 at 12:44 PM, Tim Penhey tim.pen...@canonical.com
wrote:
I realise I left this bit hanging:
On 16/05/14 14:41, Tim Penhey wrote:
A key issue that Dave and I have been poking with a stick is the test
suite for juju/errgo, as it had some failures with gccgo (all passed
with gc).
In the end it had to do with the runtime.Caller method for stack
analysis, and the synthetic methods that gccgo was creating. The
solution was simply enough to convert the tests to use gocheck, that way
the synthetic methods that were being created are higher in the stack
that we ever look in the tests, and it is all good.
Tim
--
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
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: What is required to switch back to using the tip of goose ?
FYI. This change has landed, please do the godeps dance. On Fri, May 16, 2014 at 7:54 PM, David Cheney david.che...@canonical.com wrote: Oh yes, we are talking about the same thing. I'll propose a branch On Fri, May 16, 2014 at 7:50 PM, David Cheney david.che...@canonical.com wrote: There also appears to be a small API breakage # launchpad.net/juju-core/provider/openstack provider/openstack/storage.go:59: assignment count mismatch: 2 = 3 On Fri, May 16, 2014 at 7:48 PM, John Meinel j...@arbash-meinel.com wrote: AFAIK there is one patch which landed a couple of days ago that changes an API that used to only return an io.ReadCloser, error that now returns io.ReadCloser, Headers, error, and we can safely ignore the Headers (someone else needed it who wanted to use goose). I think the only reason we aren't running an updated version is because nobody has cared to do so. I believe it is a 3 character fix for Get() but I haven't really tested the rest. John =:- On Fri, May 16, 2014 at 12:47 PM, David Cheney david.che...@canonical.com wrote: Why is the Openstack provider pinned to an old version of lauchpad.net/goose ? What is required to use the latest version ? -- 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: [Proposal] Requiring Go 1.2 across the board
On Fri, May 16, 2014 at 5:44 AM, John Meinel j...@arbash-meinel.com wrote: to get golang-go 1.2.* into ppa:juju/golang. I hope the people (Curtis and Ian) are still planning on configuring the new Jenkins lander as a Precise machine, since I still expect that to be the place where we are the most likely to accidentally break things. (Most developers will be running Trusty, so are likely to catch issues there.) We are reaching the limits of my backporting skill. Next week I will attempt a backport to verify Lp will let me build for precise and saucy. If I get binaries, I can setup unit test runs for both series on machines with the new package. If everything passes, I will then copy the package to golang. We will also need to put golang into ctools: http://ubuntu-cloud.archive.canonical.com/ubuntu/pool/main/g/golang/ -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: [Proposal] Requiring Go 1.2 across the board
+1 On May 16, 2014 3:53 AM, William Reade william.re...@canonical.com wrote: +1 On Fri, May 16, 2014 at 9:18 AM, Andrew Wilkins andrew.wilk...@canonical.com wrote: On Fri, May 16, 2014 at 3:08 PM, David Cheney david.che...@canonical.com wrote: Hello, This is a proposal that we raise the minimum Go spec from Go 1.1 to Go 1.2. Motivation: * Now that T is out, we have to support Juju on two series (Precise and Trusty[1]) with two compilers, gc and gccgo. * gccgo-4.9, which is version we using in trusty, supports the Go 1.2 spec * gc-1.1.2 which is available in a ppa for precise, obviously supports Go 1.1 * gc-1.2.1 is the shipping compiler on Trusty, it supports Go 1.2 So now we have three compilers, two versions of gc, and one of gccgo. We are in the situation where code written for gccgo under T on ppc64 or armv8 will not pass the bot running Go 1.1.1. For this reason I would like to reduce this matrix. Recommendation: * Get the trusty compiler into a backport ppa for precise[1] * Upgrade the bot to use that compiler, raising the minimum compiler spec to 1.2 across the board SGTM. The bot will be changing soon to a Jenkins lander; seems like an opportune time for making the change. Thoughts / Discussion / Spoiled fruit ? Dave [1] I am ignoring the intermediate, non LTS series', as there are no charms for them, nor do CTS offer support for them. If this is unacceptable, anything which applies to Precise wrt. backports, also applies to Q, R and S. -- 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 -- 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: [Proposal] Requiring Go 1.2 across the board
fwiw the only interim release still under support is S (along with lts releases of L, P, T). interim releases get 9 months of support, and S expires in July. https://wiki.ubuntu.com/Releases On Fri, May 16, 2014 at 9:15 AM, Gustavo Niemeyer gust...@niemeyer.netwrote: On Fri, May 16, 2014 at 4:08 AM, David Cheney david.che...@canonical.com wrote: This is a proposal that we raise the minimum Go spec from Go 1.1 to Go 1.2. Sounds sensible. [1] I am ignoring the intermediate, non LTS series', as there are no charms for them, nor do CTS offer support for them. If this is unacceptable, anything which applies to Precise wrt. backports, also applies to Q, R and S. I suppose we do want people using these releases on their own machines to be able to use juju, at least as a client. What's the proposed mechanism for getting it to them? gustavo @ http://niemeyer.net -- 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
