Re: Juju 2.0-beta17 is here!
On Fri, Sep 2, 2016 at 3:26 AM Marco Ceppi wrote: > On Thu, Sep 1, 2016 at 3:10 PM Nicholas Skaggs < > nicholas.ska...@canonical.com> wrote: > >> A new development release of Juju, 2.0-beta17, is here! >> >> ## What's new? >> >> * add-model now takes region name as an optional positional argument, >>to be consistent with bootstrap. The --region flag has been removed. >> > > If I read this correctly, I can bootstrap eastus2 controller on Azure and > create a model on westus? I was always under the impression that most > clouds don't have cross region communication. > This was possible in beta16, just using a different CLI syntax. When you create models in different regions, their agents will communicate with the controller across the public network. * show-controller now includes the agent version >> * show-controllers has been removed as an alias to show-controller >> >> ## How do I get it? >> >> If you are running Ubuntu, you can get it from the juju devel ppa: >> >> sudo add-apt-repository ppa:juju/devel >> sudo apt update; sudo apt install juju-2.0 >> >> Or install it from the snap store >> >> snap install juju --beta --devmode >> >> Windows, Centos, and OS X users can get a corresponding installer at: >> >> https://launchpad.net/juju/+milestone/2.0-beta17 >> >> >> ## Feedback Appreciated! >> >> We encourage everyone to subscribe the mailing list at >> j...@lists.ubuntu.com and join us on #juju on freenode. We would love to >> hear >> your feedback and usage of juju. >> >> >> ## Anything else? >> >> You can read more information about what's in this release by viewing the >> release notes here: >> >> https://jujucharms.com/docs/devel/temp-release-notes >> >> >> >> -- >> 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 2.0-beta17 is here!
On Thu, Sep 1, 2016 at 3:10 PM Nicholas Skaggs < nicholas.ska...@canonical.com> wrote: > A new development release of Juju, 2.0-beta17, is here! > > ## What's new? > > * add-model now takes region name as an optional positional argument, >to be consistent with bootstrap. The --region flag has been removed. > If I read this correctly, I can bootstrap eastus2 controller on Azure and create a model on westus? I was always under the impression that most clouds don't have cross region communication. * show-controller now includes the agent version > * show-controllers has been removed as an alias to show-controller > > ## How do I get it? > > If you are running Ubuntu, you can get it from the juju devel ppa: > > sudo add-apt-repository ppa:juju/devel > sudo apt update; sudo apt install juju-2.0 > > Or install it from the snap store > > snap install juju --beta --devmode > > Windows, Centos, and OS X users can get a corresponding installer at: > > https://launchpad.net/juju/+milestone/2.0-beta17 > > > ## Feedback Appreciated! > > We encourage everyone to subscribe the mailing list at > j...@lists.ubuntu.com and join us on #juju on freenode. We would love to > hear > your feedback and usage of juju. > > > ## Anything else? > > You can read more information about what's in this release by viewing the > release notes here: > > https://jujucharms.com/docs/devel/temp-release-notes > > > > -- > 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 2.0-beta17 is here!
A new development release of Juju, 2.0-beta17, is here! ## What's new? * add-model now takes region name as an optional positional argument, to be consistent with bootstrap. The --region flag has been removed. * show-controller now includes the agent version * show-controllers has been removed as an alias to show-controller ## How do I get it? If you are running Ubuntu, you can get it from the juju devel ppa: sudo add-apt-repository ppa:juju/devel sudo apt update; sudo apt install juju-2.0 Or install it from the snap store snap install juju --beta --devmode Windows, Centos, and OS X users can get a corresponding installer at: https://launchpad.net/juju/+milestone/2.0-beta17 ## Feedback Appreciated! We encourage everyone to subscribe the mailing list at j...@lists.ubuntu.com and join us on #juju on freenode. We would love to hear your feedback and usage of juju. ## Anything else? You can read more information about what's in this release by viewing the release notes here: https://jujucharms.com/docs/devel/temp-release-notes -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: juju-1.25.6 on xenial not using lxd containers
On 01/09/16 10:17, John Meinel wrote: > > 1.25 does not support LXD managed containers as it uses the old > lxc-foo CLI to manage containers (lxc-start is not the same as "lxc > start"). > juju-2.0 will use LXD managed containers but there are no plans to > backport that support to 1.25 > To be clear, then plan once 2.x is out is to provide an upgrade path from Juju 1.x with LXC 1.x to Juju 2.x with LXD. That may not come about for a while, but it will come. Mark -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: kill-controller, unregister, destroy-controller
I get the desire to remove friction everywhere we can, but unless destroying controllers is a regular activity, I actually think SOME friction is valuable here. If controllers are constantly getting into a wedged state where they must be killed, that's likely a product of a fast moving set of betas, and should be addressed *directly* rather than as they say "applying lipstick to a pig" On Thu, Sep 1, 2016 at 4:04 PM, Marco Ceppi wrote: > On Thu, Sep 1, 2016 at 9:59 AM Mark Ramm-Christensen (Canonical.com) < > mark.ramm-christen...@canonical.com> wrote: > >> I believe keeping the --destroy-all-models flag is helpful in keeping >> you from accidentally destroying a controller that is hosting important >> models for someone without thinking. >> > > What happens if I destroy-controller without that flag? Do I have to go > into my cloud portal to kill those instances? Is there any way to recover > from that to get juju reconnected? If not, it's just a slower death. > > >> On Thu, Sep 1, 2016 at 3:40 PM, Marco Ceppi >> wrote: >> >>> Hey everyone, >>> >>> I know we've had discussions about this over the past few months, but it >>> seems we have three commands that overlap pretty aggressively. >>> >>> Using Juju beta16, and trying to 'destroy' a controller it looks like >>> this now: >>> >>> ``` >>> root@ubuntu:~# juju help destroy-controller >>> Usage: juju destroy-controller [options] >>> >>> ... >>> >>> Details: >>> All models (initial model plus all workload/hosted) associated with the >>> controller will first need to be destroyed, either in advance, or by >>> specifying `--destroy-all-models`. >>> >>> Examples: >>> juju destroy-controller --destroy-all-models mycontroller >>> >>> See also: >>> kill-controller >>> unregister >>> ``` >>> >>> When would you ever want to destroy-controller and not >>> destroy-all-models? I have to specify that flag everytime, it seems it >>> should just be the default behavior. Kill-controller seems to do what >>> destroy-controller --destroy-all-models does but more aggressively? >>> >>> Finally, unregister and destroy-controller (without >>> --destroy-all-models) does the same thing. Can we consider dropping the - >>> very long winded almost always required - flag for destroy-controller? >>> >>> Finally, there used to be a pretty good amount of feedback during >>> destroy-controller, while it was rolling text, I at least knew what was >>> happening. Now it's virtually silent. Given it runs for quite a long time, >>> can we get some form of feedback to the user back into the command? >>> >>> ``` >>> root@ubuntu:~# juju destroy-controller --destroy-all-models cabs >>> WARNING! This command will destroy the "cabs" controller. >>> This includes all machines, applications, data and other resources. >>> >>> Continue? (y/N):y >>> ERROR failed to destroy controller "cabs" >>> >>> If the controller is unusable, then you may run >>> >>> juju kill-controller >>> >>> to forcibly destroy the controller. Upon doing so, review >>> your cloud provider console for any resources that need >>> to be cleaned up. >>> >>> ERROR cannot connect to API: unable to connect to API: websocket.Dial >>> wss://10.0.0.4:17070/api: dial tcp 10.0.0.4:17070: getsockopt: no route >>> to host >>> root@ubuntu:~# juju kill-controller cabs >>> WARNING! This command will destroy the "cabs" controller. >>> This includes all machines, applications, data and other resources. >>> >>> Continue? (y/N):y >>> Unable to open API: open connection timed out >>> Unable to connect to the API server. Destroying through provider. >>> ERROR listing resource groups: azure.ServicePrincipalToken#Refresh: >>> Failure sending request for Service Principal >>> 83d638b0-841c-4bd1-9e7c-868cae3393f4: >>> StatusCode=0 -- Original Error: http: nil Request.URL >>> root@ubuntu:~# juju bootstrap cabs azure >>> ERROR controller "cabs" already exists >>> ``` >>> >>> Marco >>> >>> -- >>> 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-1.25.6 on xenial not using lxd containers
1.25 does not support LXD managed containers as it uses the old lxc-foo CLI to manage containers (lxc-start is not the same as "lxc start"). juju-2.0 will use LXD managed containers but there are no plans to backport that support to 1.25 John =:-> On Sep 1, 2016 4:12 PM, "Daniel Bidwell" wrote: > I have juju-1.25.6 on xenial and am trying to configure it to use the > local lxc containers. I have lxd configured to use a zfs volume for > containers. My .juju/environment.yaml looks like: > > local: > type: local > lxc-clone: true > > root-dir: /envision/lxc > > network-bridge: lxdbr0 > > default-series: trusty > > lxd is configured correctly to use the zfs storage. When I do the juju > bootstrap and deploys, they look like containers but do not show up in > "lxc list". They are also stored in /var/lib/... They look like old > style lxc containers instead of lxd containers. > > What do I need to do differently to get juju to use the lxc launch > containers? > > > -- > Daniel Bidwell > > > -- > 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-1.25.6 on xenial not using lxd containers
Hi Daniel The transition from "1.0 everything" to "2.0 everything" is significant. 1.x Juju, 1.x MAAS and 1.x LXC all line up pretty well, as do 2.x MAAS, 2.x LXC/D, and 2.x Juju. Crossing wires between those is not very easy at the moment - we do intend to provide upgrade mechanisms but are focused on the GA 2.x releases initially. My recommendation would be to focus on the 2.x series of all of these unless you require to be in production before 16.10. Apologies that might be a tough choice, but I think you'll find that the 2.x series benefits outweigh the timeline impact in most cases. Mark On 01/09/16 08:12, Daniel Bidwell wrote: > I have juju-1.25.6 on xenial and am trying to configure it to use the > local lxc containers. I have lxd configured to use a zfs volume for > containers. My .juju/environment.yaml looks like: > > local: > type: local > lxc-clone: true > > root-dir: /envision/lxc > > network-bridge: lxdbr0 > > default-series: trusty > > lxd is configured correctly to use the zfs storage. When I do the juju > bootstrap and deploys, they look like containers but do not show up in > "lxc list". They are also stored in /var/lib/... They look like old > style lxc containers instead of lxd containers. > > What do I need to do differently to get juju to use the lxc launch > containers? > > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: kill-controller, unregister, destroy-controller
On 1 September 2016 at 14:59, Mark Ramm-Christensen (Canonical.com) < mark.ramm-christen...@canonical.com> wrote: > I believe keeping the --destroy-all-models flag is helpful in keeping you > from accidentally destroying a controller that is hosting important models > for someone without thinking. > I agree, though actually all that happens is that after a while people type ' juju destroy-controller --destroy-all-models mycontroller' without thinking. Perhaps it would be better to have a confirmation: juju destroy-controller mycontroller This command will also destroy the following models: mymodel, myimportantmodel Proceed (y/n)? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: kill-controller, unregister, destroy-controller
On Thu, Sep 1, 2016 at 9:59 AM Mark Ramm-Christensen (Canonical.com) < mark.ramm-christen...@canonical.com> wrote: > I believe keeping the --destroy-all-models flag is helpful in keeping you > from accidentally destroying a controller that is hosting important models > for someone without thinking. > What happens if I destroy-controller without that flag? Do I have to go into my cloud portal to kill those instances? Is there any way to recover from that to get juju reconnected? If not, it's just a slower death. > On Thu, Sep 1, 2016 at 3:40 PM, Marco Ceppi > wrote: > >> Hey everyone, >> >> I know we've had discussions about this over the past few months, but it >> seems we have three commands that overlap pretty aggressively. >> >> Using Juju beta16, and trying to 'destroy' a controller it looks like >> this now: >> >> ``` >> root@ubuntu:~# juju help destroy-controller >> Usage: juju destroy-controller [options] >> >> ... >> >> Details: >> All models (initial model plus all workload/hosted) associated with the >> controller will first need to be destroyed, either in advance, or by >> specifying `--destroy-all-models`. >> >> Examples: >> juju destroy-controller --destroy-all-models mycontroller >> >> See also: >> kill-controller >> unregister >> ``` >> >> When would you ever want to destroy-controller and not >> destroy-all-models? I have to specify that flag everytime, it seems it >> should just be the default behavior. Kill-controller seems to do what >> destroy-controller --destroy-all-models does but more aggressively? >> >> Finally, unregister and destroy-controller (without --destroy-all-models) >> does the same thing. Can we consider dropping the - very long winded almost >> always required - flag for destroy-controller? >> >> Finally, there used to be a pretty good amount of feedback during >> destroy-controller, while it was rolling text, I at least knew what was >> happening. Now it's virtually silent. Given it runs for quite a long time, >> can we get some form of feedback to the user back into the command? >> >> ``` >> root@ubuntu:~# juju destroy-controller --destroy-all-models cabs >> WARNING! This command will destroy the "cabs" controller. >> This includes all machines, applications, data and other resources. >> >> Continue? (y/N):y >> ERROR failed to destroy controller "cabs" >> >> If the controller is unusable, then you may run >> >> juju kill-controller >> >> to forcibly destroy the controller. Upon doing so, review >> your cloud provider console for any resources that need >> to be cleaned up. >> >> ERROR cannot connect to API: unable to connect to API: websocket.Dial >> wss://10.0.0.4:17070/api: dial tcp 10.0.0.4:17070: getsockopt: no route >> to host >> root@ubuntu:~# juju kill-controller cabs >> WARNING! This command will destroy the "cabs" controller. >> This includes all machines, applications, data and other resources. >> >> Continue? (y/N):y >> Unable to open API: open connection timed out >> Unable to connect to the API server. Destroying through provider. >> ERROR listing resource groups: azure.ServicePrincipalToken#Refresh: >> Failure sending request for Service Principal >> 83d638b0-841c-4bd1-9e7c-868cae3393f4: StatusCode=0 -- Original Error: http: >> nil Request.URL >> root@ubuntu:~# juju bootstrap cabs azure >> ERROR controller "cabs" already exists >> ``` >> >> Marco >> >> -- >> 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: kill-controller, unregister, destroy-controller
I believe keeping the --destroy-all-models flag is helpful in keeping you from accidentally destroying a controller that is hosting important models for someone without thinking. On Thu, Sep 1, 2016 at 3:40 PM, Marco Ceppi wrote: > Hey everyone, > > I know we've had discussions about this over the past few months, but it > seems we have three commands that overlap pretty aggressively. > > Using Juju beta16, and trying to 'destroy' a controller it looks like this > now: > > ``` > root@ubuntu:~# juju help destroy-controller > Usage: juju destroy-controller [options] > > ... > > Details: > All models (initial model plus all workload/hosted) associated with the > controller will first need to be destroyed, either in advance, or by > specifying `--destroy-all-models`. > > Examples: > juju destroy-controller --destroy-all-models mycontroller > > See also: > kill-controller > unregister > ``` > > When would you ever want to destroy-controller and not destroy-all-models? > I have to specify that flag everytime, it seems it should just be the > default behavior. Kill-controller seems to do what destroy-controller > --destroy-all-models does but more aggressively? > > Finally, unregister and destroy-controller (without --destroy-all-models) > does the same thing. Can we consider dropping the - very long winded almost > always required - flag for destroy-controller? > > Finally, there used to be a pretty good amount of feedback during > destroy-controller, while it was rolling text, I at least knew what was > happening. Now it's virtually silent. Given it runs for quite a long time, > can we get some form of feedback to the user back into the command? > > ``` > root@ubuntu:~# juju destroy-controller --destroy-all-models cabs > WARNING! This command will destroy the "cabs" controller. > This includes all machines, applications, data and other resources. > > Continue? (y/N):y > ERROR failed to destroy controller "cabs" > > If the controller is unusable, then you may run > > juju kill-controller > > to forcibly destroy the controller. Upon doing so, review > your cloud provider console for any resources that need > to be cleaned up. > > ERROR cannot connect to API: unable to connect to API: websocket.Dial > wss://10.0.0.4:17070/api: dial tcp 10.0.0.4:17070: getsockopt: no route > to host > root@ubuntu:~# juju kill-controller cabs > WARNING! This command will destroy the "cabs" controller. > This includes all machines, applications, data and other resources. > > Continue? (y/N):y > Unable to open API: open connection timed out > Unable to connect to the API server. Destroying through provider. > ERROR listing resource groups: azure.ServicePrincipalToken#Refresh: > Failure sending request for Service Principal > 83d638b0-841c-4bd1-9e7c-868cae3393f4: > StatusCode=0 -- Original Error: http: nil Request.URL > root@ubuntu:~# juju bootstrap cabs azure > ERROR controller "cabs" already exists > ``` > > Marco > > -- > 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
kill-controller, unregister, destroy-controller
Hey everyone, I know we've had discussions about this over the past few months, but it seems we have three commands that overlap pretty aggressively. Using Juju beta16, and trying to 'destroy' a controller it looks like this now: ``` root@ubuntu:~# juju help destroy-controller Usage: juju destroy-controller [options] ... Details: All models (initial model plus all workload/hosted) associated with the controller will first need to be destroyed, either in advance, or by specifying `--destroy-all-models`. Examples: juju destroy-controller --destroy-all-models mycontroller See also: kill-controller unregister ``` When would you ever want to destroy-controller and not destroy-all-models? I have to specify that flag everytime, it seems it should just be the default behavior. Kill-controller seems to do what destroy-controller --destroy-all-models does but more aggressively? Finally, unregister and destroy-controller (without --destroy-all-models) does the same thing. Can we consider dropping the - very long winded almost always required - flag for destroy-controller? Finally, there used to be a pretty good amount of feedback during destroy-controller, while it was rolling text, I at least knew what was happening. Now it's virtually silent. Given it runs for quite a long time, can we get some form of feedback to the user back into the command? ``` root@ubuntu:~# juju destroy-controller --destroy-all-models cabs WARNING! This command will destroy the "cabs" controller. This includes all machines, applications, data and other resources. Continue? (y/N):y ERROR failed to destroy controller "cabs" If the controller is unusable, then you may run juju kill-controller to forcibly destroy the controller. Upon doing so, review your cloud provider console for any resources that need to be cleaned up. ERROR cannot connect to API: unable to connect to API: websocket.Dial wss:// 10.0.0.4:17070/api: dial tcp 10.0.0.4:17070: getsockopt: no route to host root@ubuntu:~# juju kill-controller cabs WARNING! This command will destroy the "cabs" controller. This includes all machines, applications, data and other resources. Continue? (y/N):y Unable to open API: open connection timed out Unable to connect to the API server. Destroying through provider. ERROR listing resource groups: azure.ServicePrincipalToken#Refresh: Failure sending request for Service Principal 83d638b0-841c-4bd1-9e7c-868cae3393f4: StatusCode=0 -- Original Error: http: nil Request.URL root@ubuntu:~# juju bootstrap cabs azure ERROR controller "cabs" already exists ``` Marco -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
juju-1.25.6 on xenial not using lxd containers
I have juju-1.25.6 on xenial and am trying to configure it to use the local lxc containers. I have lxd configured to use a zfs volume for containers. My .juju/environment.yaml looks like: local: type: local lxc-clone: true root-dir: /envision/lxc network-bridge: lxdbr0 default-series: trusty lxd is configured correctly to use the zfs storage. When I do the juju bootstrap and deploys, they look like containers but do not show up in "lxc list". They are also stored in /var/lib/... They look like old style lxc containers instead of lxd containers. What do I need to do differently to get juju to use the lxc launch containers? -- Daniel Bidwell -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
