Re: State should not depend on the API server
FWIW I'd favor 3 layers, though it does mean you have to do copying between structs that would likely otherwise be almost identical. A State layer for saving in the DB, an API layer for communication, and a Model layer for use in the Agents/Clients. John =:- On Mon, Sep 1, 2014 at 9:40 AM, David Cheney david.che...@canonical.com wrote: Hello, This is an introductory email to explain my upcoming series of pull requests. The theme is simple: state must not depend on the api server. This is currently not true, state depends on api/params because some of the api types have leaked into the state package and are being directly stored in mongo. Please speak up if you disagree with this proposal. Dave -- 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: juju local bootstrap from tip
I thought --target-release was supposed to just change the priorities and
prefer a target, not require it.
We need it because we add cloud-archive:tools but we explicitly pin it to
lower priority because we don't want to mess up charms that we are
installing.
John
=:-
On Mon, Sep 1, 2014 at 9:57 AM, Andrew Wilkins andrew.wilk...@canonical.com
wrote:
On Mon, Sep 1, 2014 at 1:50 PM, John Meinel j...@arbash-meinel.com
wrote:
The version of mongodb in Precise is too old (2.2.4?),
Ah, so it is. The entry in apt-cache I was looking at has main in it,
but it's actually from the juju/stable PPA.
we require a version at least 2.4.6 (which is in cloud-archive:tools and
is what we use when bootstrapping Precise instances in the cloud).
It is recommended that if you are running local on Precise that you
should have cloud-archive:tools in your apt list.
The problem is, code-wise it's currently a requirement. Should we drop
--target-release for local? I'm not apt-savvy enough to know what the right
thing to do here is.
John
=:-
On Mon, Sep 1, 2014 at 9:16 AM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
On Mon, Sep 1, 2014 at 12:53 PM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
Works fine on my trusty laptop, but I'm also getting a new error when I
try bootstrapping on precise:
2014-09-01 04:51:27 INFO juju.utils.apt apt.go:132 Running: [apt-get
--option=Dpkg::Options::=--force-confold
--option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet install
--target-release precise-updates/cloud-tools mongodb-server]
2014-09-01 04:51:37 ERROR juju.utils.apt apt.go:166 apt-get command
failed: unexpected error type *errors.errorString
args: []string{apt-get, --option=Dpkg::Options::=--force-confold,
--option=Dpkg::options::=--force-unsafe-io, --assume-yes, --quiet,
install, --target-release, precise-updates/cloud-tools,
mongodb-server}
2014-09-01 04:51:37 ERROR juju.cmd supercommand.go:323 cannot install
mongod: apt-get failed: unexpected error type *errors.errorString
Bootstrap failed, destroying environment
I'm looking into it at the moment.
So that error message was unhelpful, and I'll fix that, but the
underlying issue is that the agent is expecting to install mongodb-server
from cloud-archive:tools, and the Makefile does not add that repo. I'm not
sure it *should* add it either. Is there something wrong with the one in
main? After all, that's where the juju-local package's dependency was
resolved.
Cheers,
Andrew
On Sat, Aug 30, 2014 at 8:19 PM, Matthew Williams
matthew.willi...@canonical.com wrote:
Hi Folks,
I thought I'd try looking into the lxc failing to creates machines
bug: https://bugs.launchpad.net/juju-core/+bug/1363143
If I wanted to do a local deploy using tip I thought it would be as
simple as doing make install then juju bootstrap is that correct? It
doesn't seem to work for me, are there any steps I'm missing
Just to be annoying - I've just shutdown my precise vm so I can't
paste the errors I get here. I'll follow up with pastes next week
Matty
--
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: State should not depend on the API server
The goal I have been tasked with is breaking the interdependency between the state package and the _client_ api types in state/api/params. I don't have any opinion on adding additional layers assuming that their dependancies flow downwards, ie labix.org/mgo - juju/state - juju/apiserver On Mon, Sep 1, 2014 at 4:03 PM, John Meinel j...@arbash-meinel.com wrote: FWIW I'd favor 3 layers, though it does mean you have to do copying between structs that would likely otherwise be almost identical. A State layer for saving in the DB, an API layer for communication, and a Model layer for use in the Agents/Clients. John =:- On Mon, Sep 1, 2014 at 9:40 AM, David Cheney david.che...@canonical.com wrote: Hello, This is an introductory email to explain my upcoming series of pull requests. The theme is simple: state must not depend on the api server. This is currently not true, state depends on api/params because some of the api types have leaked into the state package and are being directly stored in mongo. Please speak up if you disagree with this proposal. Dave -- 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: juju local bootstrap from tip
On Mon, Sep 1, 2014 at 2:04 PM, John Meinel j...@arbash-meinel.com wrote:
I thought --target-release was supposed to just change the priorities and
prefer a target, not require it.
We need it because we add cloud-archive:tools but we explicitly pin it to
lower priority because we don't want to mess up charms that we are
installing.
Sorry, I should have included the error message.
andrew@precise:~$ sudo apt-get --option=Dpkg::Options::=--force-confold
--option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet install
--target-release precise-updates/cloud-tools mongodb-server
Reading package lists...
E: The value 'precise-updates/cloud-tools' is invalid for
APT::Default-Release as such a release is not available in the sources
(if I apt-add-repository cloud-archive:tools, it's happy)
John
=:-
On Mon, Sep 1, 2014 at 9:57 AM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
On Mon, Sep 1, 2014 at 1:50 PM, John Meinel j...@arbash-meinel.com
wrote:
The version of mongodb in Precise is too old (2.2.4?),
Ah, so it is. The entry in apt-cache I was looking at has main in it,
but it's actually from the juju/stable PPA.
we require a version at least 2.4.6 (which is in cloud-archive:tools and
is what we use when bootstrapping Precise instances in the cloud).
It is recommended that if you are running local on Precise that you
should have cloud-archive:tools in your apt list.
The problem is, code-wise it's currently a requirement. Should we drop
--target-release for local? I'm not apt-savvy enough to know what the right
thing to do here is.
John
=:-
On Mon, Sep 1, 2014 at 9:16 AM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
On Mon, Sep 1, 2014 at 12:53 PM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
Works fine on my trusty laptop, but I'm also getting a new error when
I try bootstrapping on precise:
2014-09-01 04:51:27 INFO juju.utils.apt apt.go:132 Running: [apt-get
--option=Dpkg::Options::=--force-confold
--option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet install
--target-release precise-updates/cloud-tools mongodb-server]
2014-09-01 04:51:37 ERROR juju.utils.apt apt.go:166 apt-get command
failed: unexpected error type *errors.errorString
args: []string{apt-get, --option=Dpkg::Options::=--force-confold,
--option=Dpkg::options::=--force-unsafe-io, --assume-yes, --quiet,
install, --target-release, precise-updates/cloud-tools,
mongodb-server}
2014-09-01 04:51:37 ERROR juju.cmd supercommand.go:323 cannot install
mongod: apt-get failed: unexpected error type *errors.errorString
Bootstrap failed, destroying environment
I'm looking into it at the moment.
So that error message was unhelpful, and I'll fix that, but the
underlying issue is that the agent is expecting to install mongodb-server
from cloud-archive:tools, and the Makefile does not add that repo. I'm not
sure it *should* add it either. Is there something wrong with the one in
main? After all, that's where the juju-local package's dependency was
resolved.
Cheers,
Andrew
On Sat, Aug 30, 2014 at 8:19 PM, Matthew Williams
matthew.willi...@canonical.com wrote:
Hi Folks,
I thought I'd try looking into the lxc failing to creates machines
bug: https://bugs.launchpad.net/juju-core/+bug/1363143
If I wanted to do a local deploy using tip I thought it would be as
simple as doing make install then juju bootstrap is that correct? It
doesn't seem to work for me, are there any steps I'm missing
Just to be annoying - I've just shutdown my precise vm so I can't
paste the errors I get here. I'll follow up with pastes next week
Matty
--
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: juju local bootstrap from tip
Right, I think it has to *know* about the target, which is obviously an
issue here. But we still do *heavily* encourage (probably just outright
require) cloud-archive:tools for running Juju agents on Precise.
John
=:-
On Mon, Sep 1, 2014 at 10:46 AM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
On Mon, Sep 1, 2014 at 2:04 PM, John Meinel j...@arbash-meinel.com
wrote:
I thought --target-release was supposed to just change the priorities and
prefer a target, not require it.
We need it because we add cloud-archive:tools but we explicitly pin it to
lower priority because we don't want to mess up charms that we are
installing.
Sorry, I should have included the error message.
andrew@precise:~$ sudo apt-get --option=Dpkg::Options::=--force-confold
--option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet install
--target-release precise-updates/cloud-tools mongodb-server
Reading package lists...
E: The value 'precise-updates/cloud-tools' is invalid for
APT::Default-Release as such a release is not available in the sources
(if I apt-add-repository cloud-archive:tools, it's happy)
John
=:-
On Mon, Sep 1, 2014 at 9:57 AM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
On Mon, Sep 1, 2014 at 1:50 PM, John Meinel j...@arbash-meinel.com
wrote:
The version of mongodb in Precise is too old (2.2.4?),
Ah, so it is. The entry in apt-cache I was looking at has main in it,
but it's actually from the juju/stable PPA.
we require a version at least 2.4.6 (which is in cloud-archive:tools
and is what we use when bootstrapping Precise instances in the cloud).
It is recommended that if you are running local on Precise that you
should have cloud-archive:tools in your apt list.
The problem is, code-wise it's currently a requirement. Should we drop
--target-release for local? I'm not apt-savvy enough to know what the right
thing to do here is.
John
=:-
On Mon, Sep 1, 2014 at 9:16 AM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
On Mon, Sep 1, 2014 at 12:53 PM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
Works fine on my trusty laptop, but I'm also getting a new error when
I try bootstrapping on precise:
2014-09-01 04:51:27 INFO juju.utils.apt apt.go:132 Running: [apt-get
--option=Dpkg::Options::=--force-confold
--option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet install
--target-release precise-updates/cloud-tools mongodb-server]
2014-09-01 04:51:37 ERROR juju.utils.apt apt.go:166 apt-get command
failed: unexpected error type *errors.errorString
args: []string{apt-get, --option=Dpkg::Options::=--force-confold,
--option=Dpkg::options::=--force-unsafe-io, --assume-yes, --quiet,
install, --target-release, precise-updates/cloud-tools,
mongodb-server}
2014-09-01 04:51:37 ERROR juju.cmd supercommand.go:323 cannot install
mongod: apt-get failed: unexpected error type *errors.errorString
Bootstrap failed, destroying environment
I'm looking into it at the moment.
So that error message was unhelpful, and I'll fix that, but the
underlying issue is that the agent is expecting to install mongodb-server
from cloud-archive:tools, and the Makefile does not add that repo. I'm not
sure it *should* add it either. Is there something wrong with the one in
main? After all, that's where the juju-local package's dependency was
resolved.
Cheers,
Andrew
On Sat, Aug 30, 2014 at 8:19 PM, Matthew Williams
matthew.willi...@canonical.com wrote:
Hi Folks,
I thought I'd try looking into the lxc failing to creates machines
bug: https://bugs.launchpad.net/juju-core/+bug/1363143
If I wanted to do a local deploy using tip I thought it would be as
simple as doing make install then juju bootstrap is that correct? It
doesn't seem to work for me, are there any steps I'm missing
Just to be annoying - I've just shutdown my precise vm so I can't
paste the errors I get here. I'll follow up with pastes next week
Matty
--
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: State should not depend on the API server
On 01/09/14 16:03, John Meinel wrote: FWIW I'd favor 3 layers, though it does mean you have to do copying between structs that would likely otherwise be almost identical. A State layer for saving in the DB, an API layer for communication, and a Model layer for use in the Agents/Clients. This is my wish too. A sane, layered architecture, devoid of inappropriate coupling between layers, and a proper separation of concerns; the result of which will lead to, amongst other things, much better and faster, true unit tests. Well, there's a bit more that needs fixing first, eg more IOC, less use of concrete structs etc, but our current woes with unreliable tests is directly attributable to the fact that we often need to bring up the entire stack to test a component. So any progress towards fixing things, in this case eliminating unnecessary and inappropriate coupling between state and api server is much appreciated. John =:- On Mon, Sep 1, 2014 at 9:40 AM, David Cheney david.che...@canonical.com wrote: Hello, This is an introductory email to explain my upcoming series of pull requests. The theme is simple: state must not depend on the api server. This is currently not true, state depends on api/params because some of the api types have leaked into the state package and are being directly stored in mongo. Please speak up if you disagree with this proposal. Dave -- 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: State should not depend on the API server
On Mon, Sep 1, 2014 at 8:03 AM, John Meinel j...@arbash-meinel.com wrote: FWIW I'd favor 3 layers, though it does mean you have to do copying between structs that would likely otherwise be almost identical. A State layer for saving in the DB, an API layer for communication, and a Model layer for use in the Agents/Clients. Yes please, in general: one set of types per layer boundary. Independent of what Dave's doing, which is necessary regardless, I agree with what you're saying: *except* that I think we really have to consider the API layer to be *two* layers. That is to say: if you can change some type in api/params and everything still works, you are Doing It Wrong. We cannot depend on servers and clients always running the same version -- so, every time you thus change server/client in a single motion, you're almost certainly introducing more or less subtle incompatibilities. So, I would be very pleased if we would stop using the same definitions (ie api/params) on both sides of the wire -- it's one of those things that's nice and easy when everyone's running the same version, but an active trap as soon as multiple versions exist (as they do). All the struct-copying is kinda boring, but the layering violations are straight-up evil. Dave, thanks very much for doing this. Cheers William -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: State should not depend on the API server
... So, I would be very pleased if we would stop using the same definitions (ie api/params) on both sides of the wire -- it's one of those things that's nice and easy when everyone's running the same version, but an active trap as soon as multiple versions exist (as they do). All the struct-copying is kinda boring, but the layering violations are straight-up evil. Yeah, we've started running into this a bit as we get into actually revving versions in the API (as yet, we haven't actually bumped an api version though all the infrastructure should be there.) John =:- Dave, thanks very much for doing this. Cheers William -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Lag for unblocking CI
We were trying to debug why the CI was still considering itself blocked trying to land some code. Andrew had already marked the bug Fix Committed, but we were still seeing this request get rejected: https://github.com/juju/juju/pull/562 When I went to this URL: https://api.launchpad.net/devel/juju-core?ws.op=searchTasksstatus%3Alist=Triagedstatus%3Alist=In+Progressimportance%3Alist=Criticaltags%3Alist=regressiontags%3Alist=citags_combinator=All It was returning an empty list. Is there some amount of caching going on somewhere? (I also noticed it took 7minutes for the bot to notice a $$merge$$ request, so maybe it does the check somehow asynchronously to processing the requests?) John =:- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Lag for unblocking CI
On 01/09/2014, John Meinel j...@arbash-meinel.com wrote: Is there some amount of caching going on somewhere? (I also noticed it took 7minutes for the bot to notice a $$merge$$ request, so maybe it does the check somehow asynchronously to processing the requests?) Maybe it was something timing related. At any rate, manually running the script shows it's happy now. $ python check_blockers.py master 562 No blocking bugs Can do this by getting the script from lp:juju-ci-tools with the params as what you want to merge into, and the pull request number. I see the proposal has still not landed, despite some subsequent comments with the merge directive. However, William has also left some additional comments, so I guess we leave it till that's all addressed? Martin -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Lag for unblocking CI
Thanks Martin, yeah things have come up since it tried to land, I'll try again later today and let you know if there are any problems On Mon, Sep 1, 2014 at 2:49 PM, Martin Packman martin.pack...@canonical.com wrote: On 01/09/2014, John Meinel j...@arbash-meinel.com wrote: Is there some amount of caching going on somewhere? (I also noticed it took 7minutes for the bot to notice a $$merge$$ request, so maybe it does the check somehow asynchronously to processing the requests?) Maybe it was something timing related. At any rate, manually running the script shows it's happy now. $ python check_blockers.py master 562 No blocking bugs Can do this by getting the script from lp:juju-ci-tools with the params as what you want to merge into, and the pull request number. I see the proposal has still not landed, despite some subsequent comments with the merge directive. However, William has also left some additional comments, so I guess we leave it till that's all addressed? Martin -- 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: Juju stable 1.20.6 is released.
Hi,
I get this when trying to bootstrap:
WARNING failed to find 1.20.6 tools, will attempt to use 1.20.5
Launching instance
WARNING picked arbitrary tools {1.20.5-trusty-amd64
https://juju-dist.s3.amazonaws.com/rc-testing/tools/releases/juju-1.20.5-trusty-amd64.tgz
052df415c790904cd93204ef1841e4e8005c6be78a8157c899173467664dc2b1 8224282}
I have juju-core 1.20.6-0ubuntu1~14.10.1~juju1 installed on an i386 machine
and I'm bootstrapping against a MAAS provider.
Do I need to upload the 1.20.6 tools somewhere?
Thanks,
Free
On Fri, Aug 29, 2014 at 8:37 PM, Aaron Bentley aaron.bent...@canonical.com
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
juju-core 1.20.6
A new stable release of Juju, juju-core 1.20.6, is now available.
This release replaces 1.20.5.
juju-core 1.20.6 is available for utopic and backported to earlier
series in the following PPA:
https://launchpad.net/~juju/+archive/stable
Noteworthy
This releases addresses stability issues, particularly with LXC.
Resolved issues
* arguments no longer passed to plugins if you don't have an
environment set
Lp 1359170
* ERROR Nonce already used
Lp 1190986
* Juju status returns private IP in 'public-ip' field.
Lp 1348287
* juju status unit nil pointer reference.
Lp 1357482
* lxc containers created, juju can't seen or communicate with them
Lp 1357552
* cannot get tools from machine for lxc container
Lp 1359800
* Tools download can fail and is not always retried
Lp 1360994
* Containers not starting on machine
Lp 1362360
* Update the add machine api to accept both environment name and UUID
Lp 1360063
Finally
We encourage everyone to subscribe the mailing list at
juju-...@lists.canonical.com, or join us on #juju-dev on freenode.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUAMh2AAoJEK84cMOcf+9h1sEH/A8jCI1SX7ZIDOY0orw9QXc2
E9L9pvazW4AhMgLHXrSPsF9xGWJFfbOupwKxYK3ItDAQgjRQlxTTgAr1PdeRIzIG
4ZpjbsyXrzOZHN6M7FFlhBL3A2lz1MN2mL6a5PqwK4yQ0HeDgbNAghEn1fEd/OyM
z8nWkfmrSbTFrKInk6B2EQSBAM5vBwS6JaS3A0lw8tgrnCLtUDChvq/x7LG2Hqls
iAWhHztgXv3XvytMN4wCjLVSrcM4pvzGtfOZ9q5iPmf2s+2h9p7KhQIpdZriPHN7
fg/UYqHJV3ai+gfSmmeUF7Zlr/vOsRnIIDU/od59jtF79JAX5TmulMRUdF3m400=
=nZdE
-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
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Juju stable 1.20.6 is released.
On Mon, Sep 1, 2014 at 10:48 PM, Free Ekanayaka
free.ekanay...@canonical.com wrote:
Hi,
I get this when trying to bootstrap:
WARNING failed to find 1.20.6 tools, will attempt to use 1.20.5
Launching instance
WARNING picked arbitrary tools {1.20.5-trusty-amd64
https://juju-dist.s3.amazonaws.com/rc-testing/tools/releases/juju-1.20.5-trusty-amd64.tgz
052df415c790904cd93204ef1841e4e8005c6be78a8157c899173467664dc2b1 8224282}
I have juju-core 1.20.6-0ubuntu1~14.10.1~juju1 installed on an i386
machine and I'm bootstrapping against a MAAS provider.
Do I need to upload the 1.20.6 tools somewhere?
Solved. It was because I had this in my environments.yaml:
tools-metadata-url: https://juju-dist.s3.amazonaws.com/rc-testing/tools
dropping it made the trick (thanks Andreas).
Sorry for the noise.
Cheers,
Free
On Fri, Aug 29, 2014 at 8:37 PM, Aaron Bentley
aaron.bent...@canonical.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
juju-core 1.20.6
A new stable release of Juju, juju-core 1.20.6, is now available.
This release replaces 1.20.5.
juju-core 1.20.6 is available for utopic and backported to earlier
series in the following PPA:
https://launchpad.net/~juju/+archive/stable
Noteworthy
This releases addresses stability issues, particularly with LXC.
Resolved issues
* arguments no longer passed to plugins if you don't have an
environment set
Lp 1359170
* ERROR Nonce already used
Lp 1190986
* Juju status returns private IP in 'public-ip' field.
Lp 1348287
* juju status unit nil pointer reference.
Lp 1357482
* lxc containers created, juju can't seen or communicate with them
Lp 1357552
* cannot get tools from machine for lxc container
Lp 1359800
* Tools download can fail and is not always retried
Lp 1360994
* Containers not starting on machine
Lp 1362360
* Update the add machine api to accept both environment name and UUID
Lp 1360063
Finally
We encourage everyone to subscribe the mailing list at
juju-...@lists.canonical.com, or join us on #juju-dev on freenode.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUAMh2AAoJEK84cMOcf+9h1sEH/A8jCI1SX7ZIDOY0orw9QXc2
E9L9pvazW4AhMgLHXrSPsF9xGWJFfbOupwKxYK3ItDAQgjRQlxTTgAr1PdeRIzIG
4ZpjbsyXrzOZHN6M7FFlhBL3A2lz1MN2mL6a5PqwK4yQ0HeDgbNAghEn1fEd/OyM
z8nWkfmrSbTFrKInk6B2EQSBAM5vBwS6JaS3A0lw8tgrnCLtUDChvq/x7LG2Hqls
iAWhHztgXv3XvytMN4wCjLVSrcM4pvzGtfOZ9q5iPmf2s+2h9p7KhQIpdZriPHN7
fg/UYqHJV3ai+gfSmmeUF7Zlr/vOsRnIIDU/od59jtF79JAX5TmulMRUdF3m400=
=nZdE
-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
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: juju local bootstrap from tip
on a similar topic (local on tip) i was debugging with pitti his lxc
environment on utopic host earlier today, and the culmination of several
rounds of debugging and bug filing revealed this one
Bug #1364069: local provider must transform localhost in apt proxy address
amd64 apport-bug utopic juju-core (Ubuntu):New
https://launchpad.net/bugs/1364069
On Mon, Sep 1, 2014 at 2:53 AM, John Meinel j...@arbash-meinel.com wrote:
Right, I think it has to *know* about the target, which is obviously an
issue here. But we still do *heavily* encourage (probably just outright
require) cloud-archive:tools for running Juju agents on Precise.
John
=:-
On Mon, Sep 1, 2014 at 10:46 AM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
On Mon, Sep 1, 2014 at 2:04 PM, John Meinel j...@arbash-meinel.com
wrote:
I thought --target-release was supposed to just change the priorities
and prefer a target, not require it.
We need it because we add cloud-archive:tools but we explicitly pin it
to lower priority because we don't want to mess up charms that we are
installing.
Sorry, I should have included the error message.
andrew@precise:~$ sudo apt-get --option=Dpkg::Options::=--force-confold
--option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet install
--target-release precise-updates/cloud-tools mongodb-server
Reading package lists...
E: The value 'precise-updates/cloud-tools' is invalid for
APT::Default-Release as such a release is not available in the sources
(if I apt-add-repository cloud-archive:tools, it's happy)
John
=:-
On Mon, Sep 1, 2014 at 9:57 AM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
On Mon, Sep 1, 2014 at 1:50 PM, John Meinel j...@arbash-meinel.com
wrote:
The version of mongodb in Precise is too old (2.2.4?),
Ah, so it is. The entry in apt-cache I was looking at has main in it,
but it's actually from the juju/stable PPA.
we require a version at least 2.4.6 (which is in cloud-archive:tools
and is what we use when bootstrapping Precise instances in the cloud).
It is recommended that if you are running local on Precise that you
should have cloud-archive:tools in your apt list.
The problem is, code-wise it's currently a requirement. Should we drop
--target-release for local? I'm not apt-savvy enough to know what the right
thing to do here is.
John
=:-
On Mon, Sep 1, 2014 at 9:16 AM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
On Mon, Sep 1, 2014 at 12:53 PM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
Works fine on my trusty laptop, but I'm also getting a new error
when I try bootstrapping on precise:
2014-09-01 04:51:27 INFO juju.utils.apt apt.go:132 Running: [apt-get
--option=Dpkg::Options::=--force-confold
--option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet install
--target-release precise-updates/cloud-tools mongodb-server]
2014-09-01 04:51:37 ERROR juju.utils.apt apt.go:166 apt-get command
failed: unexpected error type *errors.errorString
args: []string{apt-get,
--option=Dpkg::Options::=--force-confold,
--option=Dpkg::options::=--force-unsafe-io, --assume-yes, --quiet,
install, --target-release, precise-updates/cloud-tools,
mongodb-server}
2014-09-01 04:51:37 ERROR juju.cmd supercommand.go:323 cannot
install mongod: apt-get failed: unexpected error type
*errors.errorString
Bootstrap failed, destroying environment
I'm looking into it at the moment.
So that error message was unhelpful, and I'll fix that, but the
underlying issue is that the agent is expecting to install mongodb-server
from cloud-archive:tools, and the Makefile does not add that repo. I'm
not
sure it *should* add it either. Is there something wrong with the one in
main? After all, that's where the juju-local package's dependency was
resolved.
Cheers,
Andrew
On Sat, Aug 30, 2014 at 8:19 PM, Matthew Williams
matthew.willi...@canonical.com wrote:
Hi Folks,
I thought I'd try looking into the lxc failing to creates machines
bug: https://bugs.launchpad.net/juju-core/+bug/1363143
If I wanted to do a local deploy using tip I thought it would be as
simple as doing make install then juju bootstrap is that correct? It
doesn't seem to work for me, are there any steps I'm missing
Just to be annoying - I've just shutdown my precise vm so I can't
paste the errors I get here. I'll follow up with pastes next week
Matty
--
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: juju local bootstrap from tip
Yeah, this is a dupe of https://bugs.launchpad.net/bugs/1329051
which we are due to fix this cycle.
On 02/09/14 11:23, Kapil Thangavelu wrote:
on a similar topic (local on tip) i was debugging with pitti his lxc
environment on utopic host earlier today, and the culmination of several
rounds of debugging and bug filing revealed this one
Bug #1364069: local provider must transform localhost in apt proxy address
amd64 apport-bug utopic juju-core (Ubuntu):New
https://launchpad.net/bugs/1364069
On Mon, Sep 1, 2014 at 2:53 AM, John Meinel j...@arbash-meinel.com wrote:
Right, I think it has to *know* about the target, which is obviously an
issue here. But we still do *heavily* encourage (probably just outright
require) cloud-archive:tools for running Juju agents on Precise.
John
=:-
On Mon, Sep 1, 2014 at 10:46 AM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
On Mon, Sep 1, 2014 at 2:04 PM, John Meinel j...@arbash-meinel.com
wrote:
I thought --target-release was supposed to just change the priorities
and prefer a target, not require it.
We need it because we add cloud-archive:tools but we explicitly pin it
to lower priority because we don't want to mess up charms that we are
installing.
Sorry, I should have included the error message.
andrew@precise:~$ sudo apt-get --option=Dpkg::Options::=--force-confold
--option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet install
--target-release precise-updates/cloud-tools mongodb-server
Reading package lists...
E: The value 'precise-updates/cloud-tools' is invalid for
APT::Default-Release as such a release is not available in the sources
(if I apt-add-repository cloud-archive:tools, it's happy)
John
=:-
On Mon, Sep 1, 2014 at 9:57 AM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
On Mon, Sep 1, 2014 at 1:50 PM, John Meinel j...@arbash-meinel.com
wrote:
The version of mongodb in Precise is too old (2.2.4?),
Ah, so it is. The entry in apt-cache I was looking at has main in it,
but it's actually from the juju/stable PPA.
we require a version at least 2.4.6 (which is in cloud-archive:tools
and is what we use when bootstrapping Precise instances in the cloud).
It is recommended that if you are running local on Precise that you
should have cloud-archive:tools in your apt list.
The problem is, code-wise it's currently a requirement. Should we drop
--target-release for local? I'm not apt-savvy enough to know what the
right
thing to do here is.
John
=:-
On Mon, Sep 1, 2014 at 9:16 AM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
On Mon, Sep 1, 2014 at 12:53 PM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
Works fine on my trusty laptop, but I'm also getting a new error
when I try bootstrapping on precise:
2014-09-01 04:51:27 INFO juju.utils.apt apt.go:132 Running: [apt-get
--option=Dpkg::Options::=--force-confold
--option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet install
--target-release precise-updates/cloud-tools mongodb-server]
2014-09-01 04:51:37 ERROR juju.utils.apt apt.go:166 apt-get command
failed: unexpected error type *errors.errorString
args: []string{apt-get,
--option=Dpkg::Options::=--force-confold,
--option=Dpkg::options::=--force-unsafe-io, --assume-yes,
--quiet,
install, --target-release, precise-updates/cloud-tools,
mongodb-server}
2014-09-01 04:51:37 ERROR juju.cmd supercommand.go:323 cannot
install mongod: apt-get failed: unexpected error type
*errors.errorString
Bootstrap failed, destroying environment
I'm looking into it at the moment.
So that error message was unhelpful, and I'll fix that, but the
underlying issue is that the agent is expecting to install
mongodb-server
from cloud-archive:tools, and the Makefile does not add that repo. I'm
not
sure it *should* add it either. Is there something wrong with the one in
main? After all, that's where the juju-local package's dependency was
resolved.
Cheers,
Andrew
On Sat, Aug 30, 2014 at 8:19 PM, Matthew Williams
matthew.willi...@canonical.com wrote:
Hi Folks,
I thought I'd try looking into the lxc failing to creates machines
bug: https://bugs.launchpad.net/juju-core/+bug/1363143
If I wanted to do a local deploy using tip I thought it would be as
simple as doing make install then juju bootstrap is that correct? It
doesn't seem to work for me, are there any steps I'm missing
Just to be annoying - I've just shutdown my precise vm so I can't
paste the errors I get here. I'll follow up with pastes next week
Matty
--
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:
