date:20180227

Re: More juju upgrade-juju failings

2018-02-27 Thread Mark Shuttleworth


I think this UX on the upgrade process has obvious problems. Nobody
should have to guess at what to do, in which sequence.

Can I suggest that we have a shared Google doc to mock up a nice
experience starting with the simple command 'juju upgrade' which then
walks people through the process, including the distinction between
upgrading charms, agents and controllers, as well as the ability to do
aerospace-grade upgrades through live migration to newer controllers?

Mark

On 02/27/2018 11:26 PM, Tim Penhey wrote:
> Hi Daniel,
>
> The issue here is that you are upgrading the default model, not the
> controller model itself.
>
> I think we could make the error messaging more clear, and also have the
> command also check the controller version before showing a lot of
> baffling output.
>
> What you need to do is upgrade the controller model first, so either
> switch to it or run:
>
>   juju upgrade-juju -m controller --agent-version 2.3.3
>
> Cheers,
> Tim
>
> On 28/02/18 11:19, Daniel Bidwell wrote:
>> I am running on juju 2.3.3-xenial-amd64 and my controllers are running
>> in VMware Vsphere with version 2.3.2.  I thought that it would be a
>> good thing for me to upgrade the controllers.
>>
>> I have a controller, "juju switch" generates:
>> bannercontroller:admin/default
>>
>> and juju status generates:
>> ModelControllerCloud/Region  Version  SLA
>> default  bannercontroller  myvscloud/New Datacenter  2.3.2unsupported
>>
>> App  Version  Status  Scale  Charm  Store  Rev  OS  Notes
>>
>> Unit  Workload  Agent  Machine  Public address  Ports  Message
>>
>> Machine  State  DNS  Inst id  Series  AZ  Message
>>
>> doing "juju upgrade-juju --agent-version 2.3.3 --debug" generates:
>>
>> 17:16:19 INFO  juju.cmd supercommand.go:56 running juju [2.3.3 gc go1.9.2]
>> 17:16:19 DEBUG juju.cmd supercommand.go:57   args: 
>> []string{"/snap/juju/3452/bin/juju", "upgrade-juju", "--agent-version", 
>> "2.3.3", "--debug"}
>> 17:16:19 INFO  juju.juju api.go:67 connecting to API addresses: 
>> [10.1.61.239:17070]
>> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed 
>> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
>> 17:16:19 INFO  juju.api apiclient.go:597 connection established to 
>> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
>> 17:16:19 INFO  juju.juju api.go:67 connecting to API addresses: 
>> [10.1.61.239:17070]
>> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed 
>> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
>> 17:16:19 INFO  juju.api apiclient.go:597 connection established to 
>> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
>> 17:16:19 INFO  juju.juju api.go:67 connecting to API addresses: 
>> [10.1.61.239:17070]
>> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed 
>> "wss://10.1.61.239:17070/api"
>> 17:16:19 INFO  juju.api apiclient.go:597 connection established to 
>> "wss://10.1.61.239:17070/api"
>> 17:16:19 DEBUG juju.cmd.juju.commands upgradejuju.go:466 searching for agent 
>> binaries with major: 2
>> 17:16:22 INFO  cmd upgradejuju.go:363 available agent binaries:
>> 2.3.3-artful-amd64
>> 2.3.3-artful-arm64
>> 2.3.3-artful-ppc64el
>> 2.3.3-artful-s390x
>> 2.3.3-bionic-amd64
>> 2.3.3-bionic-arm64
>> 2.3.3-bionic-ppc64el
>> 2.3.3-bionic-s390x
>> 2.3.3-centos7-amd64
>> 2.3.3-trusty-amd64
>> 2.3.3-trusty-arm64
>> 2.3.3-trusty-ppc64el
>> 2.3.3-trusty-s390x
>> 2.3.3-win10-amd64
>> 2.3.3-win2012-amd64
>> 2.3.3-win2012hv-amd64
>> 2.3.3-win2012hvr2-amd64
>> 2.3.3-win2012r2-amd64
>> 2.3.3-win2016-amd64
>> 2.3.3-win2016nano-amd64
>> 2.3.3-win7-amd64
>> 2.3.3-win8-amd64
>> 2.3.3-win81-amd64
>> 2.3.3-xenial-amd64
>> 2.3.3-xenial-arm64
>> 2.3.3-xenial-ppc64el
>> 2.3.3-xenial-s390x
>> best version:
>> 2.3.3
>> 17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
>> 17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
>> 17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
>> ERROR a hosted model cannot have a higher version than the server model: 
>> 2.3.3 > 2.3.2
>> 17:16:22 DEBUG cmd supercommand.go:459 error stack: 
>> a hosted model cannot have a higher version than the server model: 2.3.3 > 
>> 2.3.2
>> github.com/juju/juju/rpc/client.go:149: 
>> github.com/juju/juju/api/apiclient.go:924: 
>>
>>
>> I am a little baffled at what the problem might be.  This controller has no 
>> vm associated with it.
>>


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: More juju upgrade-juju failings

2018-02-27 Thread Mark Shuttleworth


I think this UX on the upgrade process has obvious problems. Nobody
should have to guess at what to do, in which sequence.

Can I suggest that we have a shared Google doc to mock up a nice
experience starting with the simple command 'juju upgrade' which then
walks people through the process, including the distinction between
upgrading charms, agents and controllers, as well as the ability to do
aerospace-grade upgrades through live migration to newer controllers?

Mark

On 02/27/2018 11:26 PM, Tim Penhey wrote:
> Hi Daniel,
>
> The issue here is that you are upgrading the default model, not the
> controller model itself.
>
> I think we could make the error messaging more clear, and also have the
> command also check the controller version before showing a lot of
> baffling output.
>
> What you need to do is upgrade the controller model first, so either
> switch to it or run:
>
>   juju upgrade-juju -m controller --agent-version 2.3.3
>
> Cheers,
> Tim
>
> On 28/02/18 11:19, Daniel Bidwell wrote:
>> I am running on juju 2.3.3-xenial-amd64 and my controllers are running
>> in VMware Vsphere with version 2.3.2.  I thought that it would be a
>> good thing for me to upgrade the controllers.
>>
>> I have a controller, "juju switch" generates:
>> bannercontroller:admin/default
>>
>> and juju status generates:
>> ModelControllerCloud/Region  Version  SLA
>> default  bannercontroller  myvscloud/New Datacenter  2.3.2unsupported
>>
>> App  Version  Status  Scale  Charm  Store  Rev  OS  Notes
>>
>> Unit  Workload  Agent  Machine  Public address  Ports  Message
>>
>> Machine  State  DNS  Inst id  Series  AZ  Message
>>
>> doing "juju upgrade-juju --agent-version 2.3.3 --debug" generates:
>>
>> 17:16:19 INFO  juju.cmd supercommand.go:56 running juju [2.3.3 gc go1.9.2]
>> 17:16:19 DEBUG juju.cmd supercommand.go:57   args: 
>> []string{"/snap/juju/3452/bin/juju", "upgrade-juju", "--agent-version", 
>> "2.3.3", "--debug"}
>> 17:16:19 INFO  juju.juju api.go:67 connecting to API addresses: 
>> [10.1.61.239:17070]
>> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed 
>> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
>> 17:16:19 INFO  juju.api apiclient.go:597 connection established to 
>> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
>> 17:16:19 INFO  juju.juju api.go:67 connecting to API addresses: 
>> [10.1.61.239:17070]
>> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed 
>> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
>> 17:16:19 INFO  juju.api apiclient.go:597 connection established to 
>> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
>> 17:16:19 INFO  juju.juju api.go:67 connecting to API addresses: 
>> [10.1.61.239:17070]
>> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed 
>> "wss://10.1.61.239:17070/api"
>> 17:16:19 INFO  juju.api apiclient.go:597 connection established to 
>> "wss://10.1.61.239:17070/api"
>> 17:16:19 DEBUG juju.cmd.juju.commands upgradejuju.go:466 searching for agent 
>> binaries with major: 2
>> 17:16:22 INFO  cmd upgradejuju.go:363 available agent binaries:
>> 2.3.3-artful-amd64
>> 2.3.3-artful-arm64
>> 2.3.3-artful-ppc64el
>> 2.3.3-artful-s390x
>> 2.3.3-bionic-amd64
>> 2.3.3-bionic-arm64
>> 2.3.3-bionic-ppc64el
>> 2.3.3-bionic-s390x
>> 2.3.3-centos7-amd64
>> 2.3.3-trusty-amd64
>> 2.3.3-trusty-arm64
>> 2.3.3-trusty-ppc64el
>> 2.3.3-trusty-s390x
>> 2.3.3-win10-amd64
>> 2.3.3-win2012-amd64
>> 2.3.3-win2012hv-amd64
>> 2.3.3-win2012hvr2-amd64
>> 2.3.3-win2012r2-amd64
>> 2.3.3-win2016-amd64
>> 2.3.3-win2016nano-amd64
>> 2.3.3-win7-amd64
>> 2.3.3-win8-amd64
>> 2.3.3-win81-amd64
>> 2.3.3-xenial-amd64
>> 2.3.3-xenial-arm64
>> 2.3.3-xenial-ppc64el
>> 2.3.3-xenial-s390x
>> best version:
>> 2.3.3
>> 17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
>> 17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
>> 17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
>> ERROR a hosted model cannot have a higher version than the server model: 
>> 2.3.3 > 2.3.2
>> 17:16:22 DEBUG cmd supercommand.go:459 error stack: 
>> a hosted model cannot have a higher version than the server model: 2.3.3 > 
>> 2.3.2
>> github.com/juju/juju/rpc/client.go:149: 
>> github.com/juju/juju/api/apiclient.go:924: 
>>
>>
>> I am a little baffled at what the problem might be.  This controller has no 
>> vm associated with it.
>>


-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Intro to Juju webinar in about 13 hours

2018-02-27 Thread Tim Penhey

Hi folks,

I'm going to be presenting an Introduction to Juju on the BrightTALK
platform tomorrow morning (my time).

https://www.brighttalk.com/webcast/6793/298241

It is a high level introduction, nothing too technical, and ideal for
someone that has no understanding of Juju wondering whether or not they
should dig deeper.

Cheers,
Tim

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Juju 2.3.4 has been released

2018-02-27 Thread Eric Claude Jones


Juju 2.3.4 has arrived. This is primarily a bug fix release.


## Critical bugs fixed.

Among the bugs fixed, one was considered critical.

 *

   1748275 Juju HA fails
   due to demotion of Machine 0


If you were affected by any of the bugs fixed in this release 
, your feedback is 
appreciated. Please contact the Juju team using the communication 
channels specified in the feedback section.



## Get Juju.


The easiest way to get Juju is using the snap package.


sudo snap install juju --classic


## Feedback Appreciated!


We encourage everyone to let us know how you're using Juju. Send us a

message on Twitter using #jujucharms, join us at #juju on freenode IRC, and

subscribe to the mailing list at juju@lists.ubuntu.com 
.



## More information


To learn more about Juju please visit https://jujucharms.com.

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Juju 2.3.4 has been released

2018-02-27 Thread Eric Claude Jones


Juju 2.3.4 has arrived. This is primarily a bug fix release.


## Critical bugs fixed.

Among the bugs fixed, one was considered critical.

 *

   1748275 Juju HA fails
   due to demotion of Machine 0


If you were affected by any of the bugs fixed in this release 
, your feedback is 
appreciated. Please contact the Juju team using the communication 
channels specified in the feedback section.



## Get Juju.


The easiest way to get Juju is using the snap package.


sudo snap install juju --classic


## Feedback Appreciated!


We encourage everyone to let us know how you're using Juju. Send us a

message on Twitter using #jujucharms, join us at #juju on freenode IRC, and

subscribe to the mailing list at j...@lists.ubuntu.com 
.



## More information


To learn more about Juju please visit https://jujucharms.com.

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: More juju upgrade-juju failings

2018-02-27 Thread Tim Penhey

Hi Daniel,

The issue here is that you are upgrading the default model, not the
controller model itself.

I think we could make the error messaging more clear, and also have the
command also check the controller version before showing a lot of
baffling output.

What you need to do is upgrade the controller model first, so either
switch to it or run:

  juju upgrade-juju -m controller --agent-version 2.3.3

Cheers,
Tim

On 28/02/18 11:19, Daniel Bidwell wrote:
> I am running on juju 2.3.3-xenial-amd64 and my controllers are running
> in VMware Vsphere with version 2.3.2.  I thought that it would be a
> good thing for me to upgrade the controllers.
> 
> I have a controller, "juju switch" generates:
> bannercontroller:admin/default
> 
> and juju status generates:
> ModelControllerCloud/Region  Version  SLA
> default  bannercontroller  myvscloud/New Datacenter  2.3.2unsupported
> 
> App  Version  Status  Scale  Charm  Store  Rev  OS  Notes
> 
> Unit  Workload  Agent  Machine  Public address  Ports  Message
> 
> Machine  State  DNS  Inst id  Series  AZ  Message
> 
> doing "juju upgrade-juju --agent-version 2.3.3 --debug" generates:
> 
> 17:16:19 INFO  juju.cmd supercommand.go:56 running juju [2.3.3 gc go1.9.2]
> 17:16:19 DEBUG juju.cmd supercommand.go:57   args: 
> []string{"/snap/juju/3452/bin/juju", "upgrade-juju", "--agent-version", 
> "2.3.3", "--debug"}
> 17:16:19 INFO  juju.juju api.go:67 connecting to API addresses: 
> [10.1.61.239:17070]
> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed 
> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
> 17:16:19 INFO  juju.api apiclient.go:597 connection established to 
> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
> 17:16:19 INFO  juju.juju api.go:67 connecting to API addresses: 
> [10.1.61.239:17070]
> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed 
> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
> 17:16:19 INFO  juju.api apiclient.go:597 connection established to 
> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
> 17:16:19 INFO  juju.juju api.go:67 connecting to API addresses: 
> [10.1.61.239:17070]
> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed 
> "wss://10.1.61.239:17070/api"
> 17:16:19 INFO  juju.api apiclient.go:597 connection established to 
> "wss://10.1.61.239:17070/api"
> 17:16:19 DEBUG juju.cmd.juju.commands upgradejuju.go:466 searching for agent 
> binaries with major: 2
> 17:16:22 INFO  cmd upgradejuju.go:363 available agent binaries:
> 2.3.3-artful-amd64
> 2.3.3-artful-arm64
> 2.3.3-artful-ppc64el
> 2.3.3-artful-s390x
> 2.3.3-bionic-amd64
> 2.3.3-bionic-arm64
> 2.3.3-bionic-ppc64el
> 2.3.3-bionic-s390x
> 2.3.3-centos7-amd64
> 2.3.3-trusty-amd64
> 2.3.3-trusty-arm64
> 2.3.3-trusty-ppc64el
> 2.3.3-trusty-s390x
> 2.3.3-win10-amd64
> 2.3.3-win2012-amd64
> 2.3.3-win2012hv-amd64
> 2.3.3-win2012hvr2-amd64
> 2.3.3-win2012r2-amd64
> 2.3.3-win2016-amd64
> 2.3.3-win2016nano-amd64
> 2.3.3-win7-amd64
> 2.3.3-win8-amd64
> 2.3.3-win81-amd64
> 2.3.3-xenial-amd64
> 2.3.3-xenial-arm64
> 2.3.3-xenial-ppc64el
> 2.3.3-xenial-s390x
> best version:
> 2.3.3
> 17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
> 17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
> 17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
> ERROR a hosted model cannot have a higher version than the server model: 
> 2.3.3 > 2.3.2
> 17:16:22 DEBUG cmd supercommand.go:459 error stack: 
> a hosted model cannot have a higher version than the server model: 2.3.3 > 
> 2.3.2
> github.com/juju/juju/rpc/client.go:149: 
> github.com/juju/juju/api/apiclient.go:924: 
> 
> 
> I am a little baffled at what the problem might be.  This controller has no 
> vm associated with it.
> 

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: More juju upgrade-juju failings

2018-02-27 Thread Tim Penhey

Hi Daniel,

The issue here is that you are upgrading the default model, not the
controller model itself.

I think we could make the error messaging more clear, and also have the
command also check the controller version before showing a lot of
baffling output.

What you need to do is upgrade the controller model first, so either
switch to it or run:

  juju upgrade-juju -m controller --agent-version 2.3.3

Cheers,
Tim

On 28/02/18 11:19, Daniel Bidwell wrote:
> I am running on juju 2.3.3-xenial-amd64 and my controllers are running
> in VMware Vsphere with version 2.3.2.  I thought that it would be a
> good thing for me to upgrade the controllers.
> 
> I have a controller, "juju switch" generates:
> bannercontroller:admin/default
> 
> and juju status generates:
> ModelControllerCloud/Region  Version  SLA
> default  bannercontroller  myvscloud/New Datacenter  2.3.2unsupported
> 
> App  Version  Status  Scale  Charm  Store  Rev  OS  Notes
> 
> Unit  Workload  Agent  Machine  Public address  Ports  Message
> 
> Machine  State  DNS  Inst id  Series  AZ  Message
> 
> doing "juju upgrade-juju --agent-version 2.3.3 --debug" generates:
> 
> 17:16:19 INFO  juju.cmd supercommand.go:56 running juju [2.3.3 gc go1.9.2]
> 17:16:19 DEBUG juju.cmd supercommand.go:57   args: 
> []string{"/snap/juju/3452/bin/juju", "upgrade-juju", "--agent-version", 
> "2.3.3", "--debug"}
> 17:16:19 INFO  juju.juju api.go:67 connecting to API addresses: 
> [10.1.61.239:17070]
> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed 
> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
> 17:16:19 INFO  juju.api apiclient.go:597 connection established to 
> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
> 17:16:19 INFO  juju.juju api.go:67 connecting to API addresses: 
> [10.1.61.239:17070]
> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed 
> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
> 17:16:19 INFO  juju.api apiclient.go:597 connection established to 
> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
> 17:16:19 INFO  juju.juju api.go:67 connecting to API addresses: 
> [10.1.61.239:17070]
> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed 
> "wss://10.1.61.239:17070/api"
> 17:16:19 INFO  juju.api apiclient.go:597 connection established to 
> "wss://10.1.61.239:17070/api"
> 17:16:19 DEBUG juju.cmd.juju.commands upgradejuju.go:466 searching for agent 
> binaries with major: 2
> 17:16:22 INFO  cmd upgradejuju.go:363 available agent binaries:
> 2.3.3-artful-amd64
> 2.3.3-artful-arm64
> 2.3.3-artful-ppc64el
> 2.3.3-artful-s390x
> 2.3.3-bionic-amd64
> 2.3.3-bionic-arm64
> 2.3.3-bionic-ppc64el
> 2.3.3-bionic-s390x
> 2.3.3-centos7-amd64
> 2.3.3-trusty-amd64
> 2.3.3-trusty-arm64
> 2.3.3-trusty-ppc64el
> 2.3.3-trusty-s390x
> 2.3.3-win10-amd64
> 2.3.3-win2012-amd64
> 2.3.3-win2012hv-amd64
> 2.3.3-win2012hvr2-amd64
> 2.3.3-win2012r2-amd64
> 2.3.3-win2016-amd64
> 2.3.3-win2016nano-amd64
> 2.3.3-win7-amd64
> 2.3.3-win8-amd64
> 2.3.3-win81-amd64
> 2.3.3-xenial-amd64
> 2.3.3-xenial-arm64
> 2.3.3-xenial-ppc64el
> 2.3.3-xenial-s390x
> best version:
> 2.3.3
> 17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
> 17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
> 17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
> ERROR a hosted model cannot have a higher version than the server model: 
> 2.3.3 > 2.3.2
> 17:16:22 DEBUG cmd supercommand.go:459 error stack: 
> a hosted model cannot have a higher version than the server model: 2.3.3 > 
> 2.3.2
> github.com/juju/juju/rpc/client.go:149: 
> github.com/juju/juju/api/apiclient.go:924: 
> 
> 
> I am a little baffled at what the problem might be.  This controller has no 
> vm associated with it.
> 

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

More juju upgrade-juju failings

2018-02-27 Thread Daniel Bidwell

I am running on juju 2.3.3-xenial-amd64 and my controllers are running
in VMware Vsphere with version 2.3.2.  I thought that it would be a
good thing for me to upgrade the controllers.

I have a controller, "juju switch" generates:
bannercontroller:admin/default

and juju status generates:
ModelControllerCloud/Region  Version  SLA
default  bannercontroller  myvscloud/New Datacenter  2.3.2unsupported

App  Version  Status  Scale  Charm  Store  Rev  OS  Notes

Unit  Workload  Agent  Machine  Public address  Ports  Message

Machine  State  DNS  Inst id  Series  AZ  Message

doing "juju upgrade-juju --agent-version 2.3.3 --debug" generates:

17:16:19 INFO  juju.cmd supercommand.go:56 running juju [2.3.3 gc go1.9.2]
17:16:19 DEBUG juju.cmd supercommand.go:57   args: 
[]string{"/snap/juju/3452/bin/juju", "upgrade-juju", "--agent-version", 
"2.3.3", "--debug"}
17:16:19 INFO  juju.juju api.go:67 connecting to API addresses: 
[10.1.61.239:17070]
17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed 
"wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
17:16:19 INFO  juju.api apiclient.go:597 connection established to 
"wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
17:16:19 INFO  juju.juju api.go:67 connecting to API addresses: 
[10.1.61.239:17070]
17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed 
"wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
17:16:19 INFO  juju.api apiclient.go:597 connection established to 
"wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
17:16:19 INFO  juju.juju api.go:67 connecting to API addresses: 
[10.1.61.239:17070]
17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed 
"wss://10.1.61.239:17070/api"
17:16:19 INFO  juju.api apiclient.go:597 connection established to 
"wss://10.1.61.239:17070/api"
17:16:19 DEBUG juju.cmd.juju.commands upgradejuju.go:466 searching for agent 
binaries with major: 2
17:16:22 INFO  cmd upgradejuju.go:363 available agent binaries:
2.3.3-artful-amd64
2.3.3-artful-arm64
2.3.3-artful-ppc64el
2.3.3-artful-s390x
2.3.3-bionic-amd64
2.3.3-bionic-arm64
2.3.3-bionic-ppc64el
2.3.3-bionic-s390x
2.3.3-centos7-amd64
2.3.3-trusty-amd64
2.3.3-trusty-arm64
2.3.3-trusty-ppc64el
2.3.3-trusty-s390x
2.3.3-win10-amd64
2.3.3-win2012-amd64
2.3.3-win2012hv-amd64
2.3.3-win2012hvr2-amd64
2.3.3-win2012r2-amd64
2.3.3-win2016-amd64
2.3.3-win2016nano-amd64
2.3.3-win7-amd64
2.3.3-win8-amd64
2.3.3-win81-amd64
2.3.3-xenial-amd64
2.3.3-xenial-arm64
2.3.3-xenial-ppc64el
2.3.3-xenial-s390x
best version:
2.3.3
17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
ERROR a hosted model cannot have a higher version than the server model: 2.3.3 
> 2.3.2
17:16:22 DEBUG cmd supercommand.go:459 error stack: 
a hosted model cannot have a higher version than the server model: 2.3.3 > 2.3.2
github.com/juju/juju/rpc/client.go:149: 
github.com/juju/juju/api/apiclient.go:924: 


I am a little baffled at what the problem might be.  This controller has no vm 
associated with it.

-- 
Daniel Bidwell 


-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

More juju upgrade-juju failings

2018-02-27 Thread Daniel Bidwell

I am running on juju 2.3.3-xenial-amd64 and my controllers are running
in VMware Vsphere with version 2.3.2.  I thought that it would be a
good thing for me to upgrade the controllers.

I have a controller, "juju switch" generates:
bannercontroller:admin/default

and juju status generates:
ModelControllerCloud/Region  Version  SLA
default  bannercontroller  myvscloud/New Datacenter  2.3.2unsupported

App  Version  Status  Scale  Charm  Store  Rev  OS  Notes

Unit  Workload  Agent  Machine  Public address  Ports  Message

Machine  State  DNS  Inst id  Series  AZ  Message

doing "juju upgrade-juju --agent-version 2.3.3 --debug" generates:

17:16:19 INFO  juju.cmd supercommand.go:56 running juju [2.3.3 gc go1.9.2]
17:16:19 DEBUG juju.cmd supercommand.go:57   args: 
[]string{"/snap/juju/3452/bin/juju", "upgrade-juju", "--agent-version", 
"2.3.3", "--debug"}
17:16:19 INFO  juju.juju api.go:67 connecting to API addresses: 
[10.1.61.239:17070]
17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed 
"wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
17:16:19 INFO  juju.api apiclient.go:597 connection established to 
"wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
17:16:19 INFO  juju.juju api.go:67 connecting to API addresses: 
[10.1.61.239:17070]
17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed 
"wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
17:16:19 INFO  juju.api apiclient.go:597 connection established to 
"wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
17:16:19 INFO  juju.juju api.go:67 connecting to API addresses: 
[10.1.61.239:17070]
17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed 
"wss://10.1.61.239:17070/api"
17:16:19 INFO  juju.api apiclient.go:597 connection established to 
"wss://10.1.61.239:17070/api"
17:16:19 DEBUG juju.cmd.juju.commands upgradejuju.go:466 searching for agent 
binaries with major: 2
17:16:22 INFO  cmd upgradejuju.go:363 available agent binaries:
2.3.3-artful-amd64
2.3.3-artful-arm64
2.3.3-artful-ppc64el
2.3.3-artful-s390x
2.3.3-bionic-amd64
2.3.3-bionic-arm64
2.3.3-bionic-ppc64el
2.3.3-bionic-s390x
2.3.3-centos7-amd64
2.3.3-trusty-amd64
2.3.3-trusty-arm64
2.3.3-trusty-ppc64el
2.3.3-trusty-s390x
2.3.3-win10-amd64
2.3.3-win2012-amd64
2.3.3-win2012hv-amd64
2.3.3-win2012hvr2-amd64
2.3.3-win2012r2-amd64
2.3.3-win2016-amd64
2.3.3-win2016nano-amd64
2.3.3-win7-amd64
2.3.3-win8-amd64
2.3.3-win81-amd64
2.3.3-xenial-amd64
2.3.3-xenial-arm64
2.3.3-xenial-ppc64el
2.3.3-xenial-s390x
best version:
2.3.3
17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
ERROR a hosted model cannot have a higher version than the server model: 2.3.3 
> 2.3.2
17:16:22 DEBUG cmd supercommand.go:459 error stack: 
a hosted model cannot have a higher version than the server model: 2.3.3 > 2.3.2
github.com/juju/juju/rpc/client.go:149: 
github.com/juju/juju/api/apiclient.go:924: 


I am a little baffled at what the problem might be.  This controller has no vm 
associated with it.

-- 
Daniel Bidwell 


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju Charm Store and CI

2018-02-27 Thread Sandor Zeestraten

Hey Tom.

Yes, I saw your hack in
https://lists.ubuntu.com/archives/juju/2017-November/009691.html which was
handy, however I was hoping for something less hacky from the charm store
folks.

--
Sandor Zeestraten

On Feb 27, 2018 22:54, "Tom Barber"  wrote:

I have a proper hack for a circleci build chain I wrote, but works pretty
well:

https://github.com/spiculedata/circleci-juju


On 27/02/18 21:44, Sandor Zeestraten wrote:

Hey Juju folks,

I feel like I'm hitting some rough spots while setting up a simple pipeline
which pushes a charm build to the edge channel using the charm store CLI.
The last Juju Show (#30) talked about macaroon support in libjuju and CI
which sounds great, but that seems to be aimed at those using libjuju
and/or JAAS controllers.

Here are some of the steps for a new project:
* Create a launchpad team for a namespace in the charm store
- Fair enough
* Create a launchpad CI user/bot and add it project so we can push to the
store without using personal credentials
- This feels like a hack and rather insecure. Why not use limited
deploy/API keys? https://github.com/juju/charmstore/issues/776
* Manually login to launchpad with the CI user in order to activate it in
the charm store
- This gotcha took me a few moments to figure out.
https://jujucharms.com/docs/stable/authors-charm-store#the-juju-charm-store
* Manually login to the charm store with the CI user with `charm login` to
create a token.
- Had to find this bug, https://github.com/juju/c
harmstore-client/issues/61, after I figured out that `charm login` did not
have a non-interactive way to authenticate
- This is still not document anywhere as far as I can tell.
https://github.com/juju/charmstore-client/issues/145
- According to the comments in #61 it needs to be updated periodically
- I've seen another approach using expect, https://lists.ubuntu.c
om/archives/juju/2017-November/009691.html, but that seems like a
workaround too
* Encrypt and deploy token to a specific directory in CI in order for
`charm login` to work
- Again, https://github.com/juju/charmstore-client/issues/61 and
https://github.com/juju/charmstore-client/issues/145
* Mess around with `charm push` and `charm release` in order to push charm
to the edge channel
- This involves dealing with revisions which feels rather unnecessary
- See https://github.com/juju/charmstore-client/issues/135 and
https://github.com/juju/charmstore-client/issues/146
* Celebrate with your favourite beverage

How are you all interacting with the charm store with your charm CI?
Am I missing some obvious steps which would simplify things?
Is anyone working on proper deploy/API keys for the charm store?

Cheers
--
Sandor Zeestraten




Spicule Limited is registered in England & Wales. Company Number: 09954122.
Registered office: First Floor, Telecom House, 125-135 Preston Road,
Brighton, England, BN1 6AF. VAT No. 251478891.


All engagements are subject to Spicule Terms and Conditions of Business.
This email and its contents are intended solely for the individual to whom
it is addressed and may contain information that is confidential,
privileged or otherwise protected from disclosure, distributing or copying.
Any views or opinions presented in this email are solely those of the
author and do not necessarily represent those of Spicule Limited. The
company accepts no liability for any damage caused by any virus transmitted
by this email. If you have received this message in error, please notify us
immediately by reply email before deleting it from your system. Service of
legal notice cannot be effected on Spicule Limited by email.

--
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: Juju Charm Store and CI

2018-02-27 Thread Tom Barber

I have a proper hack for a circleci build chain I wrote, but works 
pretty well:


https://github.com/spiculedata/circleci-juju

On 27/02/18 21:44, Sandor Zeestraten wrote:

Hey Juju folks,

I feel like I'm hitting some rough spots while setting up a simple 
pipeline which pushes a charm build to the edge channel using the 
charm store CLI.
The last Juju Show (#30) talked about macaroon support in libjuju and 
CI which sounds great, but that seems to be aimed at those using 
libjuju and/or JAAS controllers.


Here are some of the steps for a new project:
* Create a launchpad team for a namespace in the charm store
  - Fair enough
* Create a launchpad CI user/bot and add it project so we can push to 
the store without using personal credentials
  - This feels like a hack and rather insecure. Why not use limited 
deploy/API keys? https://github.com/juju/charmstore/issues/776 

* Manually login to launchpad with the CI user in order to activate it 
in the charm store
    - This gotcha took me a few moments to figure out. 
https://jujucharms.com/docs/stable/authors-charm-store#the-juju-charm-store 

* Manually login to the charm store with the CI user with `charm 
login` to create a token.
  - Had to find this 
bug,https://github.com/juju/charmstore-client/issues/61 
, after I figured 
out that `charm login` did not have a non-interactive way to authenticate
  - This is still not document anywhere as far as I can tell. 
https://github.com/juju/charmstore-client/issues/145 


  - According to the comments in #61 it needs to be updated periodically
  - I've seen another approach using expect, 
https://lists.ubuntu.com/archives/juju/2017-November/009691.html 
, 
but that seems like a workaround too
* Encrypt and deploy token to a specific directory in CI in order for 
`charm login` to work
  - Again, https://github.com/juju/charmstore-client/issues/61 
 and 
https://github.com/juju/charmstore-client/issues/145 

* Mess around with `charm push` and `charm release` in order to push 
charm to the edge channel

  - This involves dealing with revisions which feels rather unnecessary
  - Seehttps://github.com/juju/charmstore-client/issues/135 
and 
https://github.com/juju/charmstore-client/issues/146 


* Celebrate with your favourite beverage

How are you all interacting with the charm store with your charm CI?
Am I missing some obvious steps which would simplify things?
Is anyone working on proper deploy/API keys for the charm store?

Cheers
--
Sandor Zeestraten





--


Spicule Limited is registered in England & Wales. Company Number: 09954122. 
Registered office: First Floor, Telecom House, 125-135 Preston Road, 
Brighton, England, BN1 6AF. VAT No. 251478891.



All engagements are subject to Spicule Terms and Conditions of Business. 
This email and its contents are intended solely for the individual to whom 
it is addressed and may contain information that is confidential, 
privileged or otherwise protected from disclosure, distributing or copying. 
Any views or opinions presented in this email are solely those of the 
author and do not necessarily represent those of Spicule Limited. The 
company accepts no liability for any damage caused by any virus transmitted 
by this email. If you have received this message in error, please notify us 
immediately by reply email before deleting it from your system. Service of 
legal notice cannot be effected on Spicule Limited by email.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Juju Charm Store and CI

2018-02-27 Thread Sandor Zeestraten

 Hey Juju folks,

I feel like I'm hitting some rough spots while setting up a simple pipeline
which pushes a charm build to the edge channel using the charm store CLI.
The last Juju Show (#30) talked about macaroon support in libjuju and CI
which sounds great, but that seems to be aimed at those using libjuju
and/or JAAS controllers.

Here are some of the steps for a new project:
* Create a launchpad team for a namespace in the charm store
- Fair enough
* Create a launchpad CI user/bot and add it project so we can push to the
store without using personal credentials
- This feels like a hack and rather insecure. Why not use limited
deploy/API keys? https://github.com/juju/charmstore/issues/776
* Manually login to launchpad with the CI user in order to activate it in
the charm store
- This gotcha took me a few moments to figure out.
https://jujucharms.com/docs/stable/authors-charm-store#the-juju-charm-store
* Manually login to the charm store with the CI user with `charm login` to
create a token.
- Had to find this bug, https://github.com/juju/c
harmstore-client/issues/61, after I figured out that `charm login` did not
have a non-interactive way to authenticate
- This is still not document anywhere as far as I can tell.
https://github.com/juju/charmstore-client/issues/145
- According to the comments in #61 it needs to be updated periodically
- I've seen another approach using expect, https://lists.ubuntu.c
om/archives/juju/2017-November/009691.html, but that seems like a
workaround too
* Encrypt and deploy token to a specific directory in CI in order for
`charm login` to work
- Again, https://github.com/juju/charmstore-client/issues/61 and
https://github.com/juju/charmstore-client/issues/145
* Mess around with `charm push` and `charm release` in order to push charm
to the edge channel
- This involves dealing with revisions which feels rather unnecessary
- See https://github.com/juju/charmstore-client/issues/135 and
https://github.com/juju/charmstore-client/issues/146
* Celebrate with your favourite beverage

How are you all interacting with the charm store with your charm CI?
Am I missing some obvious steps which would simplify things?
Is anyone working on proper deploy/API keys for the charm store?

Cheers
--
Sandor Zeestraten
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: More juju upgrade-juju failings

Re: More juju upgrade-juju failings

Intro to Juju webinar in about 13 hours

Juju 2.3.4 has been released

Juju 2.3.4 has been released

Re: More juju upgrade-juju failings

Re: More juju upgrade-juju failings

More juju upgrade-juju failings

More juju upgrade-juju failings

Re: Juju Charm Store and CI

Re: Juju Charm Store and CI

Juju Charm Store and CI

12 matches

Site Navigation

Mail list logo

Footer information