Re: More juju upgrade-juju failings

2018-04-04 Thread Sandor Zeestraten 
Glad to help. I reported http://pad.lv/1761288 regarding the ability to
abort/rollback broken upgrades in order to get out of sticky upgrade
situations.
Also hope to see a clean up of the UX and the addition of actual dry-run
capabilities in http://pad.lv/1638714

We're looking forward to upgrading from 2.3 to 2.4 with ease and confidence!

Regards
--
Sandor Zeestraten

On Wed, Apr 4, 2018 at 8:13 PM, Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:

> Sandor, thanks for this perspective! It was really helpful to see how
> upgrades went for you in real life, and more importantly, that 2.3.x seems
> to have gone smoothly. We'll be carefully watching and monitoring 2.3->2.4
> upgrades as the release draws nearer.
>
> Nicholas
>
> On 04/01/2018 04:04 AM, Sandor Zeestraten wrote:
>
>> Hi Nicholas,
>>
>> Thanks for the input. I wrote up a short blog post about our experiences
>> going from 2.1 to 2.3. Hopefully it provides some feedback and can be
>> helpful for others in the same position.
>>
>> http://zeestrataca.com/posts/upgrading-juju/ <
>> http://zeestrataca.com/posts/upgrading-juju/>
>>
>> Regards
>> --
>> Sandor Zeestraten
>>
>>
>> On Thu, Mar 22, 2018 at 4:39 PM, Nicholas Skaggs <
>> nicholas.ska...@canonical.com >
>> wrote:
>>
>> Sandor, re:sharing experiences, if you want to frame some
>> scenarios you've had trouble with, please feel free to share
>> those. Distilling it down into a repeatable deployment -> upgrade
>> will help us understand and account for it. As Tim mentioned,
>> tools like juju-upgrader are generally candidates for
>> incorporation into juju itself, provided they prove valuable to
>> the community at large. We always welcome any PR's, but especially
>> so for improvements that add this functionality.
>>
>> Nicholas
>>
>> On 03/21/2018 08:43 PM, Tim Penhey wrote:
>>
>> Hi Sandor,
>>
>> Streamlining upgrades is definitely on the team's road-map. We
>> are aware
>> of the juju-upgrader plugin, and will be looking to
>> incorporate some of
>> that functionality into the core codebase.
>>
>> The core team has worked on better upgrade testing as part of
>> our CI,
>> which enables more test scenarios to help discover issues
>> between more
>> versions.
>>
>> Cheers,
>> Tim
>>
>> On 22/03/18 05:32, Sandor Zeestraten wrote:
>>
>> Is this shared google doc open for external contributors?
>>
>> After spending a while upgrading our 2.1.x environments to
>> 2.3.x and
>> hitting some bugs along the way in staging (see below),
>> I'd agree that
>> the process needs a bit of love and wouldn't mind sharing
>> some experiences.
>>
>> Rick mentioned https://launchpad.net/juju-upgrader
>>  on the Juju show a
>> couple of episodes back, but I haven't seen it mentioned
>> anywhere else
>> yet. Are those tools supposed to deal with some of these
>> issues and
>> eventually be rolled into juju-core?
>>
>> https://bugs.launchpad.net/juju/+bug/1746265
>> 
>> https://bugs.launchpad.net/juju/+bug/1748294
>> 
>> https://bugs.launchpad.net/juju/+bug/1697936
>> 
>>
>> Regards
>> --
>> Sandor Zeestraten
>>
>> On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth
>> mailto:m...@ubuntu.com>
>> >> wrote:
>>
>>
>>  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
>> cle

Re: More juju upgrade-juju failings

2018-04-04 Thread Nicholas Skaggs 
Sandor, thanks for this perspective! It was really helpful to see how 
upgrades went for you in real life, and more importantly, that 2.3.x 
seems to have gone smoothly. We'll be carefully watching and monitoring 
2.3->2.4 upgrades as the release draws nearer.


Nicholas

On 04/01/2018 04:04 AM, Sandor Zeestraten wrote:

Hi Nicholas,

Thanks for the input. I wrote up a short blog post about our 
experiences going from 2.1 to 2.3. Hopefully it provides some feedback 
and can be helpful for others in the same position.


http://zeestrataca.com/posts/upgrading-juju/ 



Regards
--
Sandor Zeestraten

On Thu, Mar 22, 2018 at 4:39 PM, Nicholas Skaggs 
mailto:nicholas.ska...@canonical.com>> 
wrote:


Sandor, re:sharing experiences, if you want to frame some
scenarios you've had trouble with, please feel free to share
those. Distilling it down into a repeatable deployment -> upgrade
will help us understand and account for it. As Tim mentioned,
tools like juju-upgrader are generally candidates for
incorporation into juju itself, provided they prove valuable to
the community at large. We always welcome any PR's, but especially
so for improvements that add this functionality.

Nicholas

On 03/21/2018 08:43 PM, Tim Penhey wrote:

Hi Sandor,

Streamlining upgrades is definitely on the team's road-map. We
are aware
of the juju-upgrader plugin, and will be looking to
incorporate some of
that functionality into the core codebase.

The core team has worked on better upgrade testing as part of
our CI,
which enables more test scenarios to help discover issues
between more
versions.

Cheers,
Tim

On 22/03/18 05:32, Sandor Zeestraten wrote:

Is this shared google doc open for external contributors?

After spending a while upgrading our 2.1.x environments to
2.3.x and
hitting some bugs along the way in staging (see below),
I'd agree that
the process needs a bit of love and wouldn't mind sharing
some experiences.

Rick mentioned https://launchpad.net/juju-upgrader
 on the Juju show a
couple of episodes back, but I haven't seen it mentioned
anywhere else
yet. Are those tools supposed to deal with some of these
issues and
eventually be rolled into juju-core?

https://bugs.launchpad.net/juju/+bug/1746265

https://bugs.launchpad.net/juju/+bug/1748294

https://bugs.launchpad.net/juju/+bug/1697936


Regards
--
Sandor Zeestraten

On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth
mailto:m...@ubuntu.com>
>> wrote:


     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

Re: More juju upgrade-juju failings

2018-04-01 Thread Sandor Zeestraten 
Hi Nicholas,

Thanks for the input. I wrote up a short blog post about our experiences
going from 2.1 to 2.3. Hopefully it provides some feedback and can be
helpful for others in the same position.

http://zeestrataca.com/posts/upgrading-juju/

Regards
--
Sandor Zeestraten

On Thu, Mar 22, 2018 at 4:39 PM, Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:

> Sandor, re:sharing experiences, if you want to frame some scenarios you've
> had trouble with, please feel free to share those. Distilling it down into
> a repeatable deployment -> upgrade will help us understand and account for
> it. As Tim mentioned, tools like juju-upgrader are generally candidates for
> incorporation into juju itself, provided they prove valuable to the
> community at large. We always welcome any PR's, but especially so for
> improvements that add this functionality.
>
> Nicholas
>
> On 03/21/2018 08:43 PM, Tim Penhey wrote:
>
>> Hi Sandor,
>>
>> Streamlining upgrades is definitely on the team's road-map. We are aware
>> of the juju-upgrader plugin, and will be looking to incorporate some of
>> that functionality into the core codebase.
>>
>> The core team has worked on better upgrade testing as part of our CI,
>> which enables more test scenarios to help discover issues between more
>> versions.
>>
>> Cheers,
>> Tim
>>
>> On 22/03/18 05:32, Sandor Zeestraten wrote:
>>
>>> Is this shared google doc open for external contributors?
>>>
>>> After spending a while upgrading our 2.1.x environments to 2.3.x and
>>> hitting some bugs along the way in staging (see below), I'd agree that
>>> the process needs a bit of love and wouldn't mind sharing some
>>> experiences.
>>>
>>> Rick mentioned https://launchpad.net/juju-upgrader on the Juju show a
>>> couple of episodes back, but I haven't seen it mentioned anywhere else
>>> yet. Are those tools supposed to deal with some of these issues and
>>> eventually be rolled into juju-core?
>>>
>>> https://bugs.launchpad.net/juju/+bug/1746265
>>> https://bugs.launchpad.net/juju/+bug/1748294
>>> https://bugs.launchpad.net/juju/+bug/1697936
>>>
>>> Regards
>>> --
>>> Sandor Zeestraten
>>>
>>> On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth >> > wrote:
>>>
>>>
>>>  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-f9d5
>>>

Re: More juju upgrade-juju failings

2018-03-22 Thread Nicholas Skaggs 
Sandor, re:sharing experiences, if you want to frame some scenarios 
you've had trouble with, please feel free to share those. Distilling it 
down into a repeatable deployment -> upgrade will help us understand and 
account for it. As Tim mentioned, tools like juju-upgrader are generally 
candidates for incorporation into juju itself, provided they prove 
valuable to the community at large. We always welcome any PR's, but 
especially so for improvements that add this functionality.


Nicholas

On 03/21/2018 08:43 PM, Tim Penhey wrote:

Hi Sandor,

Streamlining upgrades is definitely on the team's road-map. We are aware
of the juju-upgrader plugin, and will be looking to incorporate some of
that functionality into the core codebase.

The core team has worked on better upgrade testing as part of our CI,
which enables more test scenarios to help discover issues between more
versions.

Cheers,
Tim

On 22/03/18 05:32, Sandor Zeestraten wrote:

Is this shared google doc open for external contributors?

After spending a while upgrading our 2.1.x environments to 2.3.x and
hitting some bugs along the way in staging (see below), I'd agree that
the process needs a bit of love and wouldn't mind sharing some experiences.

Rick mentioned https://launchpad.net/juju-upgrader on the Juju show a
couple of episodes back, but I haven't seen it mentioned anywhere else
yet. Are those tools supposed to deal with some of these issues and
eventually be rolled into juju-core?

https://bugs.launchpad.net/juju/+bug/1746265
https://bugs.launchpad.net/juju/+bug/1748294
https://bugs.launchpad.net/juju/+bug/1697936

Regards
--
Sandor Zeestraten

On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth mailto:m...@ubuntu.com>> wrote:


 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:17

Re: More juju upgrade-juju failings

2018-03-22 Thread Nicholas Skaggs 
Sandor, re:sharing experiences, if you want to frame some scenarios 
you've had trouble with, please feel free to share those. Distilling it 
down into a repeatable deployment -> upgrade will help us understand and 
account for it. As Tim mentioned, tools like juju-upgrader are generally 
candidates for incorporation into juju itself, provided they prove 
valuable to the community at large. We always welcome any PR's, but 
especially so for improvements that add this functionality.


Nicholas

On 03/21/2018 08:43 PM, Tim Penhey wrote:

Hi Sandor,

Streamlining upgrades is definitely on the team's road-map. We are aware
of the juju-upgrader plugin, and will be looking to incorporate some of
that functionality into the core codebase.

The core team has worked on better upgrade testing as part of our CI,
which enables more test scenarios to help discover issues between more
versions.

Cheers,
Tim

On 22/03/18 05:32, Sandor Zeestraten wrote:

Is this shared google doc open for external contributors?

After spending a while upgrading our 2.1.x environments to 2.3.x and
hitting some bugs along the way in staging (see below), I'd agree that
the process needs a bit of love and wouldn't mind sharing some experiences.

Rick mentioned https://launchpad.net/juju-upgrader on the Juju show a
couple of episodes back, but I haven't seen it mentioned anywhere else
yet. Are those tools supposed to deal with some of these issues and
eventually be rolled into juju-core?

https://bugs.launchpad.net/juju/+bug/1746265
https://bugs.launchpad.net/juju/+bug/1748294
https://bugs.launchpad.net/juju/+bug/1697936

Regards
--
Sandor Zeestraten

On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth mailto:m...@ubuntu.com>> wrote:


 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:17

Re: More juju upgrade-juju failings

2018-03-21 Thread Tim Penhey 
Hi Sandor,

Streamlining upgrades is definitely on the team's road-map. We are aware
of the juju-upgrader plugin, and will be looking to incorporate some of
that functionality into the core codebase.

The core team has worked on better upgrade testing as part of our CI,
which enables more test scenarios to help discover issues between more
versions.

Cheers,
Tim

On 22/03/18 05:32, Sandor Zeestraten wrote:
> Is this shared google doc open for external contributors?
> 
> After spending a while upgrading our 2.1.x environments to 2.3.x and
> hitting some bugs along the way in staging (see below), I'd agree that
> the process needs a bit of love and wouldn't mind sharing some experiences.
> 
> Rick mentioned https://launchpad.net/juju-upgrader on the Juju show a
> couple of episodes back, but I haven't seen it mentioned anywhere else
> yet. Are those tools supposed to deal with some of these issues and
> eventually be rolled into juju-core?
> 
> https://bugs.launchpad.net/juju/+bug/1746265
> https://bugs.launchpad.net/juju/+bug/1748294
> https://bugs.launchpad.net/juju/+bug/1697936
> 
> Regards
> --
> Sandor Zeestraten
> 
> On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth  > wrote:
> 
> 
> 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  j

Re: More juju upgrade-juju failings

2018-03-21 Thread Sandor Zeestraten 
Is this shared google doc open for external contributors?

After spending a while upgrading our 2.1.x environments to 2.3.x and
hitting some bugs along the way in staging (see below), I'd agree that the
process needs a bit of love and wouldn't mind sharing some experiences.

Rick mentioned https://launchpad.net/juju-upgrader on the Juju show a
couple of episodes back, but I haven't seen it mentioned anywhere else yet.
Are those tools supposed to deal with some of these issues and eventually
be rolled into juju-core?

https://bugs.launchpad.net/juju/+bug/1746265
https://bugs.launchpad.net/juju/+bug/1748294
https://bugs.launchpad.net/juju/+bug/1697936

Regards
--
Sandor Zeestraten

On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth  wrote:

>
> 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.2
> unsupported
> >>
> >> 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 D

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 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-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev