Re: Juju 2.4.0 has been released

[Rick Harding]

Sorry, after hitting send I woke up some more and realized what you're
asking. Only the Juju client on your machine is in the snap. The controller
and models need to be manually upgraded. We don't deliver those and auto
upgrade them as a snap.

The proper upgrade doc for the 2.4.0 series is here:
https://docs.jujucharms.com/2.4/en/models-upgrade

Start with the controller and you should be good to go.

On Tue, Jul 3, 2018 at 7:34 AM Rick Harding 
wrote:

> On Tue, Jul 3, 2018 at 7:11 AM Bogdan Kowalczyk <
> bogdan.kowalc...@canonical.com> wrote:
>
>> Thanks Vinodhin
>>
>> I just installed juju from snap and wanted to test couple of deployments.
>>
>> Should the controller version be 2.4.0 as well or are we keeping 2.3.7?
>>
>
> Is this on an existing deployment? If this controller was already up then
> you'll need to make sure to upgrade the controller.
>
> Check out https://docs.jujucharms.com/1.25/en/juju-upgrade for
> assistance.
>
> Rick
>
-- 
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.4.0 has been released

[Rick Harding]

On Tue, Jul 3, 2018 at 7:11 AM Bogdan Kowalczyk <
bogdan.kowalc...@canonical.com> wrote:

> Thanks Vinodhin
>
> I just installed juju from snap and wanted to test couple of deployments.
>
> Should the controller version be 2.4.0 as well or are we keeping 2.3.7?
>

Is this on an existing deployment? If this controller was already up then
you'll need to make sure to upgrade the controller.

Check out https://docs.jujucharms.com/1.25/en/juju-upgrade for assistance.

Rick
-- 
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.4-rc2 has been released

[Rick Harding]

I want to make sure it's clear that this is the last exected RC release. If
no issues are found in testing from the community we plan on a final
release next week. Please give it a spin attempt to crush it for all your
worth!

Thanks!

On Mon, Jun 18, 2018 at 6:36 PM Chris Lee 
wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *A new development release of Juju is here, 2.4-rc2.## Fixes - A bug
> introduced in RC1 for the Oracle and Joyent providers has been
> corrected.For a list of all bugs fixed in this release,
> seehttps://launchpad.net/juju/+milestone/2.4-rc2
> ## How can I get it?The best
> way to get your hands on this release of Juju is to install it as a snap
> package (see https://snapcraft.io/  for more info on
> snaps). sudo snap install juju --classic --candidateOther packages
> are available for a variety of platforms. Please see the online
> documentation at https://jujucharms.com/docs/stable/reference-install
> . Those subscribed to
> a snap channel should be automatically upgraded. If you’re using the
> ppa/homebrew, you should see an upgrade available.## Feedback
> Appreciated!We encourage everyone to let us know how you're using Juju.
> Send us amessage on Twitter using #jujucharms, join us at #juju on
> freenode, and subscribe to the mailing list at j...@lists.ubuntu.com
> .## More informationTo 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
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: adding nics to a vm in vmware built by juju deploy

[Rick Harding]

I'm not familiar if there's any way to unlock/force through VMWare but Juju
doesn't currently support the idea of adding nics to running instances at
this moment. It's something we're definitely looking for the future as
clouds do support things like hot plugging nics. It might be worth a test
to see if you can adjust the nics on the VMWare side. In some cases you can
work around Juju like adding storage to the root disk by upgrading the
instance through the cloud tooling.

On Fri, Jun 8, 2018 at 7:58 AM Daniel Bidwell  wrote:

> I have a vmware server that I am using as the target for deploying vms
> with juju.  I have a set of vms that need multiple nics on different
> vlans/vmware networks.  I want the vm to be on the primary network, but
> also have nics for 4 other secondary networks.
>
> Once the vm is deployed, vmware considers it locked and will not let me
> add additional nics.  Is there a way to unlock it?  Or is there a way
> to deploy the vm with the nics installed from the start?
>
> I didn't see anything in the online docs about adding additional
> networks to the constraints clause of the deploy.  If this feature is
> not available at this time, could it be considered for the future?
> --
> 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 2.4-rc1 Released

[Rick Harding]

Not yet. This enables bootstrapping on a clustered lxd that's also
localhost. It's a step toward making Juju aware of the clustering APIs but
does not yet enable the work of adding a remote lxd cloud. I showed this in
last week's Juju show.

https://youtu.be/CidoBy3iqUw

On Wed, Jun 6, 2018, 6:58 PM Marco Ceppi  wrote:

> On Wed, Jun 6, 2018, 21:33 Kelvin Liu  wrote:
>
>>
>>
>>
>>
>> *A new development release of Juju is here, 2.4-rc1.## New and Improved -
>> LXD functionality has been updated to support version 3 of LXD. Better
>> support exists for LXD installed as a Snap, defaulting to Snap-installed
>> LXD by default if it is present. Initial support for LXD clustering is
>> available under constrained conditions:*
>>
>
> Does this mean that I can bootstrap a remote LXD cluster now?
> --
> 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: Statistics and metrics about Charm, layer and interface usage

[Rick Harding]

https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md is the docs
for the API to the charmstore itself. As Adam notes, you can pull down any
file and there's manifest call that lists out the files in the charm. From
there you could probably check if the charm has a layers.yaml and if so
fetch that file, parse it, etc.

https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md#get-idmetamanifest

On Thu, Jan 25, 2018 at 11:22 AM Adam Collard 
wrote:

> Hi Merlijn,
>
>
> On Thu, 25 Jan 2018 at 16:17 Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Hi all
>>
>>
>> I'm writing a Juju-related paper and I'd like to get statistics on Charm,
>> layer and interface usage. Are these publicly available?
>>
>> Related: is there a documented API to get the code of the charms that are
>> available in the charm store?
>>
>
> GET https://api.jujucharms.com/charmstore/v5/$MY_CHARM_NAME/archive/ will
> give you a .zip
> and
>
> GET
> https://api.jujucharms.com/charmstore/v5/$MY_CHARM_NAME/archive/$PATH/$TO/$FILE
> will give you the 'raw' contents.
>
> e.g. curl
> https://api.jujucharms.com/charmstore/v5/postgresql/archive/hooks/install
>
> YMMV,
>
> Adam
> --
> 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.3.0 is here!

[Rick Harding]

Hey, how did you know I was working on a plugin for that :P

I just started poking at the problem of easier management of what version
your controller and models are on and a helper to maas upgrade. I'll reach
out for some testing once it's there.

On Fri, Dec 8, 2017 at 7:22 AM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Slightly related; is there a way to update _all_ models on a controller
> with one command?
>
> 2017-12-08 10:14 GMT+01:00 Andrew Wilkins :
>
>> On Fri, Dec 8, 2017 at 6:59 AM Nicholas Skaggs <
>> nicholas.ska...@canonical.com> wrote:
>>
>>> The Juju team are extremely pleased to announce the release of Juju 2.3.
>>> Juju is now more versatile, more efficient, and more configurable than ever.
>>>
>>> Cross Model Relations deliver a new way of organising your software
>>> stack. Deploy a database in one model and connect it to an application
>>> running another, even one running on a different controller, or even a
>>> different cloud.
>>>
>>> For containers at scale, Juju now integrates Canonical's Fan overlay
>>> network system. This allows containers to map network traffic to any other
>>> container on the fan network without distributed databases, consensus
>>> protocols, or any extra overhead.
>>>
>>> Juju's support for bundles has made it possible to quickly deploy
>>> connected sets of applications for some time now, but no two use cases are
>>> the same. That's why we have introduced the concept of an 'overlay' bundle
>>> - now you can easily add your own configuration and tweaks to a bundle at
>>> deploy time. See below for links to more information on this and other key
>>> features.
>>>
>>
>> Hi folks,
>>
>> Unfortunately a critical bug [0] has escaped to the field. This bug
>> affects existing relations in upgraded models. Models created after
>> upgrading, or with a fresh bootstrap, or where relations are created after
>> upgrading, will not be affected.
>>
>> I would not recommend upgrading from 2.x. to 2.3.0. We will be working on
>> a fix for 2.3.1, and I expect this issue will bring that release forward
>> much sooner. If you have already upgraded and are affected, then you can
>> fix it by adding a document to the "statuses" collection in Mongo, as
>> described in the bug.
>>
>> Cheers,
>> Andrew
>>
>> [0] https://bugs.launchpad.net/juju/+bug/1737107
>>
>>
>>>
>>>
>>> ## How can I get it?
>>>
>>>
>>> The best way to get your hands on this release of Juju is to install it
>>> via snap packages (see https://snapcraft.io/for more info on snaps).
>>>
>>>
>>>snap install juju --classic
>>>
>>>
>>> Other packages are available for a variety of platforms. Please see the
>>> online documentation at
>>> https://jujucharms.com/docs/2.3/reference-install <
>>> https://jujucharms.com/docs/stable/reference-install>. Those subscribed
>>> to a snap channel should be automatically upgraded. If you’re using the
>>> ppa/homebrew, you should see an upgrade available.
>>>
>>>
>>> For highlights of this release, please see the documentation at
>>>
>>> https://jujucharms.com/docs/2.3/whats-new. Further details are below.
>>>
>>>
>>>
>>> ## New
>>>
>>>
>>> * Cross Model Relations:
>>>
>>>  - see https://jujucharms.com/docs/2.3/models-cmr
>>>
>>>
>>> * Persistent Storage:
>>>
>>>  - see https://jujucharms.com/docs/2.3/charms-storage
>>>
>>>
>>> * FAN:
>>>
>>>  - see https://jujucharms.com/docs/2.3/charms-fan
>>>
>>>
>>> * Bundle deployments:
>>>
>>>  - Changed flags for deploying bundles to existing machines
>>>
>>>  - Bundle deploy flag --bundle-config replaced with --overlay
>>>
>>>  - Deploying bundles now supports --dry-run
>>>
>>>  - Deploying bundles can now target existing machines
>>>
>>>
>>> * Update Application Series:
>>>
>>>  - see https://jujucharms.com/docs/2.3/howto-updateseries
>>>
>>>
>>> * Parallelization of the Machine Provisioner:
>>>
>>> - Groups of machines will now be provisioned in parallel reducing
>>> deployment time, especially on large bundles.
>>>
>>>
>>> * open_port and close_port hook tools now support ICMP
>>>
>>> - The open_port and close_port hook tools now support opening firewall
>>> access for ICMP. The syntax is:
>>>
>>> open_port icmp
>>>
>>>
>>> * LXD Storage Provider:
>>>
>>>  - see https://jujucharms.com/docs/2.3/charms-storage#lxd-(lxd)
>>>
>>>
>>> ## Fixes
>>>
>>>
>>> * Listing of Juju models is more efficient and can now handle more
>>> models gracefully
>>>
>>> * Leadership coordinations is no longer tied to local time which avoids
>>> problems with clock skew and reduces overall load on the database
>>>
>>> * Models are now more reliably destroyed and several fixes to avoid
>>> negative impacts while they are being removed
>>>
>>>
>>> You can check the milestones for a detailed breakdown of the Juju bugs
>>> we have fixed:
>>>
>>>
>>> https://launchpad.net/juju/+milestone/2.3.0
>>>
>>> https://launchpad.net/juju/+milestone/2.3-rc2
>>>
>>> https://launchpad.net/juju/+milestone/2.3-rc1
>>>
>>> 

Re: Charm snap is now strictly confined

[Rick Harding]

+1 awesome work folks.

On Fri, Sep 8, 2017 at 2:49 PM Tim Van Steenburgh <
tim.van.steenbu...@canonical.com> wrote:

>
>
> On Fri, Sep 8, 2017 at 2:44 PM, Tom Barber  wrote:
>
>> good effort devs!
>>
>
> +1, thanks Cory.
>
>
>>
>> On 8 Sep 2017 7:42 pm, "Cory Johns"  wrote:
>>
>>> Greetings,
>>>
>>> I just wanted to make a quick announcement that the charm snap is now
>>> strictly confined on the stable channel (rev 17).  This fixes issues like
>>> https://github.com/juju/charm-tools/issues/339 and
>>> https://github.com/juju/charm-tools/issues/319 and prevents similar
>>> issues from cropping up in the future.
>>>
>>> In general, this change should be pretty much transparent, with the one
>>> caveat being that you can only build charms from under your HOME directory.
>>>
>>> --
>>> Juju mailing list
>>> j...@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>>
>> --
>> Juju mailing list
>> j...@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>> --
> 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

collecting tips, how-tos, tools used in troubleshooting Juju

[Rick Harding]

I'm working to build out the troubleshooting section of the Juju
documentation. [1] I'd like to collate common issues, tips, scripts, and
tools folks have buried in wikis, google docs, or their brains. I'd like to
ask you send anything you've got, as raw an unproofed as it lives today, my
way. I'll worry about organizing, cleaning up, fine tuning the language,
etc. I just want to ask everyone to help me brainstorm the things they can
think of that'll be useful in a full fleshed out troubleshooting guide. No
issue is too big or too small.

Example useful things that can be generically hit could be I've got X
configured wrong, or I hit the limit on my cloud compute instances allowed,
or this is what happens when Y over there goes down.

Potential moving parts to trigger ideas include:
general help in diagnosing what's going on beyond the logs
issues getting setup (add-cloud/add-credential) (the rackspace id needs to
be in quotes)
errors while bootstrapping
common issues with deploying, scaling, relations
issues with sharing/revoking models
Cloud specific issues and trouble spots
  - MAAS
  - LXD
  - OpenStack
  - AWS/GCE/Azure
  - Manual Provider

Items I'm currently calling out of scope include issues around charming as
I think that's going to be another big chunk with a different enough scope
to focus on separately.

Thanks for the assistance everyone. From here I'll start to build up a
"best practices" guide for operating Juju itself and we'll hopefully have a
lot of useful material going forward that users will be able to self-help
themselves much more easily.

Rick

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

Re: A new release of Juju, 2.2-beta1 and conjure-up are here!

[Rick Harding]

This is awesome Adam. Testing and bugs filing. Thanks for the work on this.

On Tue, Mar 28, 2017 at 6:56 AM Adam Stokes 
wrote:

> conjure-up was merged into hombrew last night, please give the macOS
> version a try and let us know if there are any issues:
>
> brew install conjure-up
>
> Thanks!
>
> On Fri, Mar 24, 2017 at 4:21 PM Curtis Hovey-Canonical <
> cur...@canonical.com> wrote:
>
> A new release of Juju, 2.2-beta1, and conjure-up, are here!
>
>
> ## What's new in 2.2-beta1
>
> - juju login updates
> - [conjure-up] Integrated JAAS support
> - [conjure-up] Steps now support handling actions that require sudo
>   (ie sudo snap install kubectl --classic --edge)
> - [conjure-up] macOS port (waiting on merge
>   https://github.com/Homebrew/homebrew-core/pull/11488)
> - [conjure-up] Lots of step processing polishes
>
>
> ### juju login updates
>
> Juju login command now accepts the name or hostname of a public
> controller as a parameter.
>
> juju login jaas
>
> This would add the jaas public controller to the list of the controllers
> you can use, it will also get cached in the controllers.yaml. Public
> controllers usually use external identity providers. JAAS uses Ubuntu
> SSO as an external provider, so in order to use this controller, you
> have to register at Ubuntu SSO. In order to get access to the JAAS
> public controller, please register through jujucharms.com or using this
> URL:
>
> https://jujucharms.com/login
>
> The previous version of the command accepted the user name as a
> parameter. In order to login as a local user, you can specify a user
> name as the argument to the -u flag.
>
> juju login -u bob
>
> Note that this release includes only the initial implementation of the
> juju login command changes. Polishing and improved UX will come with
> following releases.
>
>
> ## Resolved Issues
>
> Check the milestones for a detailed breakdown of Juju and conjure-up
> bugs corrected.
>
> https://github.com/conjure-up/conjure-up/milestone/19?closed=1
> https://launchpad.net/juju/+milestone/2.2-beta1
>
>
> ## How do I get it?
>
> If you are running Ubuntu, you can get Juju from the juju stable ppa:
>
>sudo add-apt-repository ppa:juju/devel; sudo apt-get update
>
>sudo apt-get install juju
>
> Or install Juju from the snap store:
>
>snap install juju --classic --beta
>
> Install conjure-up from the snap store:
>
>snap install conjure-up --classic --beta
>
> If you are on Trusty, you'll need to run a few extra commands:
>
>sudo apt-get install snapd
>sudo groupadd lxd && sudo usermod -a -G lxd $USER
>sudo reboot
>
> Now you can install snaps, including conjure-up, as normal:
>
>snap install conjure-up --classic --beta
>
> macOS users can install conjure-up with brew:
>
>brew install conjure-up --devel
>
> Windows, CentOS, and MacOS users can get a corresponding Juju
> installer at:
>
>https://launchpad.net/juju/+milestone/2.2-beta1
>
>
> ## 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, and
> subscribe to the mailing list at j...@lists.ubuntu.com.
>
>
> ## More information
>
> To learn more about these great technologies please visit
> https://jujucharms.com and http://conjure-up.io.
>
> --
> Curtis Hovey
> Canonical Cloud Development and Operations
> http://launchpad.net/~sinzui
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
> --
> 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: ssh keys

[Rick Harding]

This is definitely on the todo list. It's completely correct that users
should be able to manage their own keys.

On Wed, Mar 8, 2017 at 11:01 AM James Beedy  wrote:

> I'm quickly finding myself maintaining users ssh keys. How do people feel
> about making ssh keys bound to the user instead of the model? This way,
> when a user is added to a model ssh access comes with the package.
> Moreover, can we allow users to manage their own keys?
> --
> 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.1-beta5 is here

[Rick Harding]

Narinder, so the beta5 includes the container networking changes that are
required to help make sure that Juju stops guessing bindings incorrectly.
If you look at the error messages in those commands you can see a new error
that the beta5 presents:

  message: 'unable to setup network: no obvious space for container
"0/lxd/10",
host machine has spaces: "admin-api", "external",
"internal-api"'

This generally means that you need to be explicit in the bindings. I see in
your bundle paste that you have bindinds for each application on machine 0.
I would suggest checking if there are any endpoints that are missing form
the definition? There's a mechanism to define a default binding for the
application, but I'm unable to recall/find that at the moment. I've /cc'd
John who's been working on this and might have another hint for you.

I'd check the bindings for the ones that don't come up and see if that
helps.

Rick

On Sat, Feb 4, 2017 at 1:06 PM Narinder Gupta <narinder.gu...@canonical.com>
wrote:

> Here you go.
>
> juju status --format yaml
>
> http://paste.ubuntu.com/23927017/
>
> juju show-machine 0
>
> http://paste.ubuntu.com/23927020/
>
> pastebinit bundles.yaml
>
> http://paste.ubuntu.com/23927027/
>
> Thanks and Regards,
> Narinder Gupta (PMP)   narinder.gu...@canonical.com
> Canonical, Ltd.narindergupta 
> [irc.freenode.net]+1.281.736.5150 <(281)%20736-5150>  
>   narindergupta2007[skype]
>
> Ubuntu- Linux for human beings | www.ubuntu.com | www.canonical.com
>
>
> On Sat, Feb 4, 2017 at 9:20 AM, Rick Harding <rick.hard...@canonical.com>
> wrote:
>
> Narinder, can you share the output of juju status --format=yaml and juju
> show-machine 0
>
>
> On Sat, Feb 4, 2017, 5:15 AM Narinder Gupta <narinder.gu...@canonical.com>
> wrote:
>
> Hi Nicholas,
> I am finding issues when do the deployment. Bundle i used to deploy with
> juju 2.1-beta4 does not get deployed with juju-2.1-beta5.
>
> Reason of that is mongodb lxd container still waiting to get machine which
> was not the case for juju 2.1-beta4
> mongodb/0 waiting  allocating  0/lxd/3
>   waiting for machine
>
> You can see here http://pastebin.ubuntu.com/23924329/ all services came
> up except mongodb and openfv-promise. I can confirm that if I switch to
> beta4 everything works. Here is the bundle i am deploying
> http://paste.ubuntu.com/23924334/
>
>
>
> Thanks and Regards,
> Narinder Gupta (PMP)   narinder.gu...@canonical.com
> Canonical, Ltd.narindergupta 
> [irc.freenode.net]+1.281.736.5150 <(281)%20736-5150>  
>   narindergupta2007[skype]
>
> Ubuntu- Linux for human beings | www.ubuntu.com | www.canonical.com
>
>
> On Fri, Feb 3, 2017 at 5:54 PM, Nicholas Skaggs <
> nicholas.ska...@canonical.com> wrote:
>
> The Juju team would like to introduce Juju and conjure-up 2.1-beta5! The
> most visible changes are to container networking and that juju controllers
> now expose Prometheus metrics over an HTTPS endpoint. Finally, conjure-up
> is also a snap, provides juju, and can be installed on trusty as a snap as
> well!
>
> We would especially like feedback on the container networking changes. Do
> let us know of your experiences, and feel free to open bugs and threads to
> discuss.
>
> ## What’s New in Beta 5
>
> [conjure-up] Now snapped for Trusty and Xenial.
> [conjure-up] Support for Canonical Kubernetes 1.5.2.
> [conjure-up] Ability to teardown models with the new `conjure-down`
> command.
> [juju] Container networking improvements:
> - LXD and KVM guests no longer join all spaces on the host
> machine, but use constraints and bindings to determine what spaces should
> be used
> - Bridges are not created during provisioning, but only created on demand
> for containers that will use them.
> - For clouds other than MAAS, we continue to put containers onlocal
> bridges (lxdbr0)
>[juju] Juju ssh/scp now selects correct address to use to connect to
> the controller.
> [juju] Model config now supports an "extra-info" field for holding
> additional metadata.
> [juju] More memory leaks have been addressed.
> [juju] Stricter rules for validating charm metadata field names to
> conform to data storage requirements. Charm metadata fields can not contain
> dots.
> [juju] controllers now expose HTTPS endpoints under “/introspection/”,
> accessible to controller superusers, and users with read access to the
> controller model:/introspection/debug/pprof/profile,
> /introspection/depengin

Re: Juju 2.1-beta5 is here

[Rick Harding]

Narinder, can you share the output of juju status --format=yaml and juju
show-machine 0

On Sat, Feb 4, 2017, 5:15 AM Narinder Gupta 
wrote:

> Hi Nicholas,
> I am finding issues when do the deployment. Bundle i used to deploy with
> juju 2.1-beta4 does not get deployed with juju-2.1-beta5.
>
> Reason of that is mongodb lxd container still waiting to get machine which
> was not the case for juju 2.1-beta4
> mongodb/0 waiting  allocating  0/lxd/3
>   waiting for machine
>
> You can see here http://pastebin.ubuntu.com/23924329/ all services came
> up except mongodb and openfv-promise. I can confirm that if I switch to
> beta4 everything works. Here is the bundle i am deploying
> http://paste.ubuntu.com/23924334/
>
>
>
> Thanks and Regards,
> Narinder Gupta (PMP)   narinder.gu...@canonical.com
> Canonical, Ltd.narindergupta [irc.freenode.net]
> +1.281.736.5150narindergupta2007[skype]
>
> Ubuntu- Linux for human beings | www.ubuntu.com | www.canonical.com
>
>
> On Fri, Feb 3, 2017 at 5:54 PM, Nicholas Skaggs <
> nicholas.ska...@canonical.com> wrote:
>
> The Juju team would like to introduce Juju and conjure-up 2.1-beta5! The
> most visible changes are to container networking and that juju controllers
> now expose Prometheus metrics over an HTTPS endpoint. Finally, conjure-up
> is also a snap, provides juju, and can be installed on trusty as a snap as
> well!
>
> We would especially like feedback on the container networking changes. Do
> let us know of your experiences, and feel free to open bugs and threads to
> discuss.
>
> ## What’s New in Beta 5
>
> [conjure-up] Now snapped for Trusty and Xenial.
> [conjure-up] Support for Canonical Kubernetes 1.5.2.
> [conjure-up] Ability to teardown models with the new `conjure-down`
> command.
> [juju] Container networking improvements:
> - LXD and KVM guests no longer join all spaces on the host
> machine, but use constraints and bindings to determine what spaces should
> be used
> - Bridges are not created during provisioning, but only created on demand
> for containers that will use them.
> - For clouds other than MAAS, we continue to put containers onlocal
> bridges (lxdbr0)
>[juju] Juju ssh/scp now selects correct address to use to connect to
> the controller.
> [juju] Model config now supports an "extra-info" field for holding
> additional metadata.
> [juju] More memory leaks have been addressed.
> [juju] Stricter rules for validating charm metadata field names to
> conform to data storage requirements. Charm metadata fields can not contain
> dots.
> [juju] controllers now expose HTTPS endpoints under “/introspection/”,
> accessible to controller superusers, and users with read access to the
> controller model:/introspection/debug/pprof/profile,
> /introspection/depengine/,/introspection/metrics.
>
>
> ## Bugs Addressed
>
> Check the milestones for a detailed breakdown of juju and conjure-up bugs
> corrected.
>
> https://launchpad.net/juju/+milestone/2.1-beta5
>
> https://github.com/conjure-up/conjure-up/milestone/14?closed=1
>
> ## How do I get it?
>
> If you are running Ubuntu, you can get Juju from the juju devel ppa:
>
>sudo add-apt-repository ppa:juju/devel; sudo apt-get update
>
>sudo apt-get install juju
>
> Or install Juju from the snap store:
>
>snap install juju --beta --devmode
>
> Install conjure-up from the snap store:
>
> snap install conjure-up --classic --beta
>
> If you are on Trusty, you'll need to run a few extra commands:
>sudo apt-get install snapd
>sudo groupadd lxd && sudo usermod -a -G lxd $USER
>sudo reboot
>
> Now you can install snaps, including conjure-up, as normal:
>snap install conjure-up --classic --beta
>
> Windows, Centos, and macOS users can get a corresponding Juju installer at:
>
>https://launchpad.net/juju/+milestone/2.1-beta5
>
> ## 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, and
> subscribe to the mailing list at j...@lists.ubuntu.com.
>
>
>
> --
> Juju mailing list
> j...@lists.ubuntu.com
>
>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
> --
> Juju mailing list
> j...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: lxd and constraints

[Rick Harding]

In the end, you say you want an instance with 2gb of ram and if the cloud
has an instance with that exact limit it is in fact an exact limit. The key
things here is the clouds don't have infinite malleable instance types like
containers (this works for kvm and for lxd). So I'm not sure the mis-match
is as far apart as it seems. root disk means give me a disk this big, if
you ask for 2 core as long as you can match an instance type with 2 cores
it's exactly the max you get.

It seems part of this can be more adjusting the language from "minimum" to
something closer to "requested X" where request gives it more of a "I want
X" without the min/max boundaries.



On Fri, Jan 13, 2017 at 3:14 AM John Meinel  wrote:

> So we could make it so that constraints are actually 'exactly' for LXD,
> which would then conform to both minimum and maximum, and would still be
> actually useful for people deploying to containers. We could certainly
> probe the host machine and say "you asked for 48 cores, and the host
> machine doesn't have it".
>
> However, note that explicit placement also takes precedence over
> constraints anyway. If you do:
>   juju deploy mysql --constraints mem=4G
> today, and then do:
>  juju add-unit --to 2
> We don't apply the constraint limitations to that specific unit. Arguably
> we should at *least* be warning that the constraints for the overall
> application don't appear to be valid for this instance.
>
> I guess I'd rather see constraints still set limits for containers,
> because people really want that functionality, and that we warn any time
> you do a direct placement and the constraints aren't satisfied. (but warn
> isn't failing the attempt)
>
> John
> =:->
>
> On Fri, Jan 13, 2017 at 10:09 AM, Stuart Bishop <
> stuart.bis...@canonical.com> wrote:
>
> On 13 January 2017 at 02:20, Nate Finch  wrote:
>
> I'm implementing constraints for lxd containers and provider... and
> stumbled on an impedance mismatch that I don't know how to handle.
>
>
>
> I'm not really sure how to resolve this problem.  Maybe it's not a
> problem.  Maybe constraints just have a different meaning for containers?
> You have to specify the machine number you're deploying to for any
> deployment past the first anyway, so you're already manually choosing the
> machine, at which point, constraints don't really make sense anyway.
>
>
> I don't think Juju can handle this. Either constraints have different
> meanings with different cloud providers, or lxd needs to accept minimum
> constraints (along with any other cloud providers with this behavior).
>
> If you decide constraints need to consistently mean minimum, then I'd
> argue it is best to not pass them to current-gen lxd at all. Enforcing that
> containers are restricted to the minimum viable resources declared in a
> bundle does not seem helpful, and Juju does not have enough information to
> choose suitable maximums (and if it did, would not know if they would
> remain suitable tomorrow).
>
> --
> Stuart Bishop 
>
> --
> 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: A new development release of Juju, 2.1-beta4, is here!

[Rick Harding]

You will notice this is beta4 vs the rc1 we had been working toward.

Part of 2.1 is an improvement to juju container networking that corrects
issues that many users are facing. This updates Juju to only create bridges
on a host machine only when a container is placed on the host and only for
the specific network interfaces that the container needs to function. This
code has been moving along and has been demonstrated to work properly when
used correctly.

However, in working to complete those changes it came up that we're missing
the ability to specify the correct network spaces that the application and
thus the container need to be on in the current bundle spec and format. We
support specifying on a per-endpoint basis with the changes done in Juju
2.0, however there's not a key to set the default value the charm wants to
use for any hook/endpoint that it leverages. These updates will hold the
RC1 while those are updated and landed.

If anyone is curious and would like to try out the new networking container
behavior please try out the feature branch that the work is taking place in
here:

https://github.com/juju/juju/tree/2.1-dynamic-bridges

We refer to this as dynamic bridging because the changes cause bridges to
be dynamically generated as required based on direct spaces information.

If you have any questions please let me know.

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

Re: Juju Wikipedia Needs Update

[Rick Harding]

Thanks for the heads up. I'll take a look at it. I've wanted to write for
wikipedia sometime.

On Tue, Jan 3, 2017 at 12:55 PM James Beedy  wrote:

> Wikipedia entry for Juju needs update
> https://en.m.wikipedia.org/wiki/Juju_(software)
>
> --
> 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

charmv6-unstable...long live charmv6?

[Rick Harding]

I went to the GH repo for /juju/charm and noticed that it was missing code.
After too long a time I realized I was looking at the v5 branch and
actually we're all using v6-unstable now.

With the release of 2.0 I wanted to see if we're all ready to make v6
stable and update the default branch for the GH repo to the new v6 branch.
Is there anyone out there that might cause an issue?

Thanks

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

Re: Juju Show #2 Wed Dec 14th

[Rick Harding]

Check out the recording of the show in case you missed it.

https://www.youtube.com/watch?v=FwLEMa7XE64

I want to thank everyone that joined us for the show this week. Some great
info on the new tools to aid in charm testing, reviewing, and an exciting
demo of the upcoming juju migrate feature in Juju 2.1.

With the holidays we'll be having our next Juju Show on January 4th and the
one after that will be the 18th. We'll have links and announcements out
after folks get back from the holidays.

On Tue, Dec 13, 2016 at 3:47 PM Rick Harding <rick.hard...@canonical.com>
wrote:

> Come join us as we host the next Juju Show live stream tomorrow. We'll be
> going over the latest in community news, demoing the new developments in
> tools for charming, and getting a demonstration of the new model migration
> feature coming in Juju 2.1.
>
> When: Nov 30th, at 19:00 GMT, 2:00pm EST
> Where: https://www.youtube.com/watch?v=FwLEMa7XE64
> How to participate: Hang out in the #juju Freenode IRC channel
>
> Join us in the IRC channel to ask questions, get a link to the hangout to
> join the live stream, or just to listen in on the latest news.
>
> Make sure to subscribe to the Juju Youtube channel so you never miss any
> of the happenings in and around Juju!
>
> https://www.youtube.com/channel/UCSsoSZBAZ3Ivlbt_fxyjIkw
>
> See you there!
>
> Rick
> Juju Engineering
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju Show #2 Wed Dec 14th

[Rick Harding]

Come join us as we host the next Juju Show live stream tomorrow. We'll be
going over the latest in community news, demoing the new developments in
tools for charming, and getting a demonstration of the new model migration
feature coming in Juju 2.1.

When: Nov 30th, at 19:00 GMT, 2:00pm EST
Where: https://www.youtube.com/watch?v=FwLEMa7XE64
How to participate: Hang out in the #juju Freenode IRC channel

Join us in the IRC channel to ask questions, get a link to the hangout to
join the live stream, or just to listen in on the latest news.

Make sure to subscribe to the Juju Youtube channel so you never miss any of
the happenings in and around Juju!

https://www.youtube.com/channel/UCSsoSZBAZ3Ivlbt_fxyjIkw

See you there!

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

Re: One instance manual provider

[Rick Harding]

I'll have to test it out but I would think that you could

1) bring up a machine, create a container on it, bootstrap to that
container as the controller, create another container, and then add-machine
it as a second machine and things should work ok.

2) I wonder if you can bootstrap to a machine, manually add container on
that machine, and then add that container with add-machine.

I'm guessing there's some bits about making sure the added containers have
the ssh key you want to use for the ssh connection for add-machine.

On Mon, Dec 5, 2016 at 3:18 PM Matthew Williams <
matthew.willi...@canonical.com> wrote:

> Hey Folks,
>
> I notice the docs state that at least two instances are needed for the
> manual provider: https://jujucharms.com/docs/stable/clouds-manual. Some
> quick playing around suggests that this is indeed the case.
>
> Is there a technical reason why? I'd love to spin up a charm on [insert
> vps provider here] and only spend money for one instance
>
> Matty
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Deployment Oversight

[Rick Harding]

That's very true on the items that are different. I wonder if we could work
with the CPC team and note the things that are assumed promises when using
cloud images so that it'd be easy to build a "patch" for manually
provisioned machines. If we know specific packages or configuration is
there on our images it should be do-able to help have some sort of
"manual-init" script that could try to bring things in line.

Merlijn, do you have any notes on the changes that you were suffering
through? Was there anything that didn't fit the "using your own ubuntu
install vs a CPC certified image"?

On Sun, Nov 27, 2016 at 1:26 AM John Meinel  wrote:

> From what I can tell, there are a number of places where these manual
> machines differ from our "standard" install. I think the charms can be
> written defensively around this, but its why you're running into more
> issues than you normally would.
>
>1. 'noexec' for /tmp. I've heard of this, but as layer-ruby wants to
>build something, where *should* it build something. Maybe we could do
>something in /var, but it does seem like the intermediate files are all
>temporary (thus why someone picked /tmp). I don't have any details on
>layer-ruby
>2. python-yaml not installed. Most of the places where we run juju
>uses 'cloud-init' in order to set up the machine for the first time, and
>I'm pretty sure cloud-init has a dependency on python-yaml (cause its how
>some of the cloud-init config is written). Again, charms can just include
>python-yaml as a dependency, I'm guessing they just didn't notice because
>all the other places they tested it was already there.
>
> John
> =:->
>
>
> On Sun, Nov 27, 2016 at 4:45 AM, Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
> I feel you, James
>
> We've been battling with weird issues / compatibility problems with the
> manual provider on private infra for the past year. Just finding out where
> the problem is requires diving deep into the internals of Juju and the
> Charms. In the end, we patched our own servers heavily and had to patch
> ~30% of the Charms we tried. This slowed us down so much that we just gave
> up and moved to MAAS. We're having a lot less problems now..
>
>
>
> 2016-11-27 0:03 GMT+01:00 James Beedy :
>
> Was a bit flustered earlier when I sent off this email, I've looked a bit
> closer at each of the individual problems, thought I would report back with
> my findings.
>
> 1. Job for systemd-sysctl.service failed because the control process
> exited
> - This is an error I'm seeing when installing juju (not sure if this
> is adding to any other issues or not), didn't look into it much, but filed
> a bug here -> https://bugs.launchpad.net/juju/+bug/1645025
>
> 2. ERROR juju.state database.go:231 using unknown collection
> "remoteApplications"
> - This seems to only exist in 2.0.1, installed from juju/stable ppa,
> when I reverted back to 2.0.0, this went away.
>
> Charm/Layer Issues
>
> 3. Problem with Ruby: ["env: './configure': Permission denied"]
> - Both of my charms were utilizing layer-ruby. When deployed to lxd,
> and EC2, I don't seem to get this error, but deploying on this
> private/dedicated infra doesn't like python running `./configure` I feel
> (could also be permissions on /tmp, but I tried moving the upacking and
> configuring to another dir, and still got this error).
> - Filed bug here ->
> https://github.com/battlemidget/juju-layer-ruby/issues/12
> - Removing layer-ruby was my fix here, this allowed my charms to
> deploy w/o error.
>
> 4.  Elasticsearch
> - Seems the es charm can't find the yaml module (possibly a python3.5
> thing)???
> - Filed bug here ->
> https://bugs.launchpad.net/charms/+source/elasticsearch/+bug/1645043
> - My workaround here, just to get the app deployed, was to deploy
> elasticsearch to a lxd container on one of my hosts. Of course this isn't
> an answer for anything more then POC, but worked to allow me to
> deploy/troubleshoot the rest of my bundle.
>
>
> Aside from the remaining elasticsearch issue, I was able to get my stack
> deployed -> http://paste.ubuntu.com/23540146/
>
> My earlier baffled and confused cry for help seems now just revolve around
> getting es to deploy.
>
> My apologies for reaching out in such a way earlier before diving into
> what was going on, hopefully we can work out whats going on with my infra
> <-> ES.
>
> Thanks
>
> --
> Juju mailing list
> j...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
>
> --
> Juju mailing list
> j...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
> --
> 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 

Re: Bootstrap Constraints

[Rick Harding]

James, can you provider more detailed info on the rules of your deployment
you're looking for?

You mention wanting a controller away from other things on a subnet? Does
this reach out true for HA nodes on that controller, workloads brought up
by that controller? Are you expecting some sort of subnet affinity for
everything from a controller given it's deployed to a specific subnet? If
so, what's the use case you're driving forward with?

Thanks for the insight to help us better plan what we want to do to enable
different end user situations.

On Sat, Oct 29, 2016 at 7:40 PM James Beedy  wrote:

> Dimiter,
>
> Thanks for looking into this. That sounds like an awesome solution!
>
> ~James
>
>
> > Team,
> >
> > From what I can gather, Juju either allows or disallows you to bootstrap
> > to a specific network/subnet dependent on whether or not the provider
> > supports a network space bootstrap constraint. The EC2 provider just so
> > happens to be one of the providers which doesn't support controller
> > placement on bootstrap. This is a massive problem for me, seeing as I
> > have many subnets for things other than controller nodes. I just can't
> > seem to get the controller to land in a subnet (seems to be chosen at
> > some sort of random) that doesn't already have other things in it that I
> > don't want around my controller. To facilitate bootstrap network
> > constraints on the EC2 provider, I think a 'network' constraint is
> > needed, along with some filtering of the provided 'network' constraint
> > value to ensure the subnet exists, is in the current region and current
> > vpc - seems like it might do the trick until we have a flat model for
> > controller placement that works across all providers.
> >
> > Thoughts?
> >
> >
> Hey James,
>
> Sorry for the late reply! The EC2 provider does not support the tags=
> constraint, and it has limited support for the spaces= constraint - but
> not for the controller, as at bootstrap time no spaces are yet defined.
> So unfortunately you can't yet explicitly specify where a controller
> instance will end up on.
>
> To allow explicit placement for EC2 instances, including Juju
> controllers, we could (trivially) implement support for `--to
> subnet=` placement (like the existing - and supported - `--to
> zone=`).
>
> Then you could do `juju bootstrap ... --to subnet=172.31.5.0/24`
>  (with
> or without --config vpc-id=vpc-xyz) to achieve what you want.
>
> Thoughts?
>
> Cheers,
> Dimiter
> --
> 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: List plugins installed?

[Rick Harding]

This is just a miss. The original ability to see the plugins was a subset
of the help command and didn't make our CLI spreadsheet for things to
rework. I agree that list-plugins is the right idea here and that means
that plugins becomes a noun in our language.

What's interesting is that add/remove fall out because that
installing/uninstalling. I think that show-plugin might be interesting to
auto run the --description flag to bring it into CLI alignment with the new
world order.

I've filed a bug to track adding the support for plugin into the CLI.
https://bugs.launchpad.net/juju/+bug/1628538

Thanks for the catch Marco!



On Wed, Sep 28, 2016 at 6:24 AM Marco Ceppi 
wrote:

> Hello everyone,
>
> I've started building plugins again, starting with `juju watch-status`[0].
> I wanted to test the --description flag in Juju but `juju help plugins` and
> a myriad of other commands (I guessed) didn't work (juju list-plugins, juju
> plugins, etc).
>
> Do we plan on having the ability to list plugins in 2.0?
>
> [0]: https://github.com/juju/plugins/pull/69
>
> Thanks,
> Marco Ceppi
> --
> 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: Reviews on Github

[Rick Harding]

I spoke with Alexis today about this and it's on her list to check with her
folks on this. The tech board has been tasked with he decision, so please
feel free to shoot a copy of your opinions their way. As you say, on the
one hand it's a big impact on the team, but it's also a standard developer
practice that not everyone will agree with so I'm sure the tech board is a
good solution to limiting the amount of bike-shedding and to have some
multi-mind consensus.

On Tue, Sep 20, 2016 at 1:52 PM Katherine Cox-Buday <
katherine.cox-bu...@canonical.com> wrote:

> Seems like a good thing to do would be to ensure the tech board doesn't
> have any objections and then put it to a vote since it's more a property of
> the team and not the codebase.
>
> I just want some consistency until a decision is made. E.g. "we will be
> trying out GitHub reviews for the next two weeks; all reviews should be
> done on there".
>
> --
> Katherine
>
> Nate Finch  writes:
>
> > Can we try reviews on github for a couple weeks? Seems like we'll
> > never know if it's sufficient if we don't try it. And there's no setup
> > cost, which is nice.
> >
> > On Tue, Sep 20, 2016 at 12:44 PM Katherine Cox-Buday
> >  wrote:
> >
> > I see quite a few PRs that are being reviewed in GitHub and not
> > ReviewBoard. I really don't care where we do them, but can we
> > please pick a direction and move forward? And until then, can we
> > stick to our previous decision and use RB? With people using both
> > it's much more difficult to tell what's been reviewed and what
> > hasn't.
> >
> > --
> > Katherine
> >
> > Nate Finch  writes:
> >
> > > In case you missed it, Github rolled out a new review process.
> > It
> > > basically works just like reviewboard does, where you start a
> > review,
> > > batch up comments, then post the review as a whole, so you don't
> > just
> > > write a bunch of disconnected comments (and get one email per
> > review,
> > > not per comment). The only features reviewboard has is the edge
> > case
> > > stuff that we rarely use: like using rbt to post a review from a
> > > random diff that is not connected directly to a github PR. I
> > think
> > > that is easy enough to give up in order to get the benefit of
> > not
> > > needing an entirely separate system to handle reviews.
> > >
> > > I made a little test review on one PR here, and the UX was
> > almost
> > > exactly like working in reviewboard:
> > > https://github.com/juju/juju/pull/6234
> > >
> > > There may be important edge cases I'm missing, but I think it's
> > worth
> > > looking into.
> > >
> > > -Nate
>
> --
> 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: Bootstraping Rackspace

[Rick Harding]

James, what good timing. The streams with image info is just going through
getting setup.

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

It took a bit for the images for trusty/xenial to get setup and the team's
working to make it all work out of the box.

We had demo streams up for testing and it's in the rackspace documentation:
https://jujucharms.com/docs/master/help-rackspace

Unfortunately, the metadata-url is 404'ing so looks like they've been moved
and the documentation needs to be updated. I'll see what I can find out as
to a new location. You might also track the bug to watch the progress of
the official path going forward.

Apologies for the trouble getting it going as we ramp things up.

On Mon, Sep 19, 2016 at 7:26 PM James Beedy  wrote:

> I am trying to bootstrap the rackspace provider and cannot seem to get
> past "ERROR failed to bootstrap model: no image metadata found". Do I
> need to generate metadata for rackspace provider? I feel like I need to
> get some images in rackspace and generate the image metadata using the
> image ids for said images. Is there any difference between the way this is
> done for openstack and the way it should be done here?
>
> Could someone who has successfully bootstrapped rackspace shed some light
> here?
>
> thx
> --
> Juju mailing list
> j...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Reviews on Github

[Rick Harding]

I think that the issue is that someone has to maintain the RB and the
cost/time spent on that does not seem commensurate with the bonus features
in my experience.

On Wed, Sep 14, 2016 at 6:13 PM Ian Booth  wrote:

> One thing review board does better is use gutter indicators so as not to
> interrupt the flow of reading the code with huge comment blocks. It also
> seems
> much better at allowing previous commits with comments to be viewed in
> their
> entirety. And it allows the reviewer to differentiate between issues and
> comments (ie fix this vs take note of this), plus it allows the notion of
> marking stuff as fixed vs dropped, with a reason for dropping if needed.
> So the
> github improvements are nice but there's still a large and significant gap
> that
> is yet to be filled. I for one would miss all the features reviewboard
> offers.
> Unless there's a way of doing the same thing in github that I'm not aware
> of.
>
> On 15/09/16 07:22, Tim Penhey wrote:
> > I'm +1 if we can remove the extra tools and we don't get email per
> comment.
> >
> > On 15/09/16 08:03, Nate Finch wrote:
> >> In case you missed it, Github rolled out a new review process.  It
> >> basically works just like reviewboard does, where you start a review,
> >> batch up comments, then post the review as a whole, so you don't just
> >> write a bunch of disconnected comments (and get one email per review,
> >> not per comment).  The only features reviewboard has is the edge case
> >> stuff that we rarely use:  like using rbt to post a review from a random
> >> diff that is not connected directly to a github PR. I think that is easy
> >> enough to give up in order to get the benefit of not needing an entirely
> >> separate system to handle reviews.
> >>
> >> I made a little test review on one PR here, and the UX was almost
> >> exactly like working in reviewboard:
> https://github.com/juju/juju/pull/6234
> >>
> >> There may be important edge cases I'm missing, but I think it's worth
> >> looking into.
> >>
> >> -Nate
> >>
> >>
> >
>
> --
> 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: Reviews on Github

[Rick Harding]

/me is always +1 on reducing the number of things we have to maintain and
keeping things simpler.

On Wed, Sep 14, 2016 at 4:04 PM Nate Finch  wrote:

> In case you missed it, Github rolled out a new review process.  It
> basically works just like reviewboard does, where you start a review, batch
> up comments, then post the review as a whole, so you don't just write a
> bunch of disconnected comments (and get one email per review, not per
> comment).  The only features reviewboard has is the edge case stuff that we
> rarely use:  like using rbt to post a review from a random diff that is not
> connected directly to a github PR. I think that is easy enough to give up
> in order to get the benefit of not needing an entirely separate system to
> handle reviews.
>
> I made a little test review on one PR here, and the UX was almost exactly
> like working in reviewboard: https://github.com/juju/juju/pull/6234
>
> There may be important edge cases I'm missing, but I think it's worth
> looking into.
>
> -Nate
> --
> 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: 2.0 as default on main repos?

[Rick Harding]

Thanks for the feedback Jose. Merlijn also brought up a similar note and I
replied on the main juju list to help explain the current pain window we're
working through. Rather than copy/paste you can see it here:

https://lists.ubuntu.com/archives/juju/2016-August/007679.html

Please let me know if you'd like to chat. I understand that it feels very
awkward right now, but it's part 'by the plan' as far as the plan went, but
also 'not by the plan' as we'd hoped to have Juju 2.0 GA for folks at this
time. We're very close now and the feedback from users of 2.0 has been
essential to getting so much right and better for everyone.

Jose, let me know if you want to reach out and chat about the transition
and why things are setup they way they are. We really appreciate the
feedback and patience as we go through the 1.X to 2.X transition.

Rick

On Mon, Aug 8, 2016 at 11:32 AM José Antonio Rey  wrote:

> Hey Matt,
>
> Thanks for the link.
>
> If anyone reading has a way to help get it fixed, please do so. This is a
> horrible bug that causes inconsistencies, and until 2.0 is released it
> should not be in main.
>
> On Mon, Aug 8, 2016, 09:22 Matt Bruzek 
> wrote:
>
>> Hello José,
>>
>> I ran into this problem myself and filed a bug with the packaging.
>>
>> https://bugs.launchpad.net/juju-release-tools/+bug/1609437
>>
>> While I still think this is a bug, I did find a work around which I put
>> in the bug for other people having this same problem. Hope that helps!
>>
>>- Matt Bruzek 
>>
>> On Wed, Aug 3, 2016 at 7:49 PM, José Antonio Rey  wrote:
>>
>>> Hello everyone,
>>>
>>> I am deploying some production servers and am seeing a weird behavior:
>>>
>>> 2.0~beta12-0ubuntu1.16.04.1 is the default for the 'main' repositories
>>> of archive.ubuntu.com
>>>
>>> 1.25.6-0ubuntu1~16.04.1~juju1 is the default for ppa:juju/stable
>>>
>>> Is this intended? Doesn't feel right to me.
>>>
>>> Thanks in advance for the insight!
>>>
>>> --
>>> Juju mailing list
>>> j...@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>> --
> Juju mailing list
> j...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: hub github helper

[Rick Harding]

Thanks Nate, that's really useful info and Hub makes it easy to get at
other folk's repos/forks of Juju to really collaborate, look at code that's
WIP and such.

I highly recommend folks take a peek and see how it can improve their
collaboration and workflows. Especially when reviewing and QA'ing pull
requests from folks.

On Tue, Aug 2, 2016 at 12:08 PM Nate Finch  wrote:

> I've mentioned this before, but with some of our new code review
> guidelines, I figured it's good to reiterate.  Github has a CLI tool that
> helps with doing git-related things with github.  It's called hub. It's
> written in Go, so installing it is as easy as go get github.com/github/hub
>
> Github recommends making an alias to have hub replace git, since it
> forwards everything to git that it doesn't understand.  Honestly, I don't
> really see any benefit to that.  I prefer to understand what git is doing
> versus what hub is doing.
>
> It can do a whole bunch of stuff, but there are two things I use it for
> the most - checking out PRs and making PRs.
>
> Since we're supposed to be doing manual testing on people's PRs when we
> review them, we need a way to do that.  With hub it's one command:
>
> hub checkout 
>
> so, for example:
>
> hub checkout https://github.com/juju/juju/pull/5915
>
> Bam, your local branch is set to a copy of the PR (don't forget to run
> godeps).
>
> To make a PR from the CLI using hub, make sure the repo you want to PR
> against is the git remote called origin, then you can make a PR with your
> current branch by just doing
>
> hub pull-request
>
> This will open an editor to write the PR message, or you can use -m just
> like with git commit.
>
> -Nate
> --
> 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: top-issues preventing Juju from passing

[Rick Harding]

On Tue, Aug 2, 2016 at 2:28 PM Curtis Hovey-Canonical 
wrote:

> NEW:
>
> Deployer: KeyError: 'uuid' connecting to environment
> https://bugs.launchpad.net/juju-core/+bug/1608952
> ^ Juju or deployer needs to change
>

The conversation here was that the deployer had been updated? If not looks
like that you've called out Ian's commit there to follow up.


> Race in github.com/juju/juju/cmd/modelcmd
> https://bugs.launchpad.net/juju-core/+bug/1609041
> ^ There are two immediate suspect commits, but the race
>appears to involve older commits.
>

Thanks, will look into.


>
>
> OUTSTANDING
>
> Charms utilizing storage fail on LXD
> https://bugs.launchpad.net/juju-core/+bug/1604474
> ^ Has been assigned for weeks, but no sign of progress.
>

Sorry, we assigned but it was in a queue. It was picked up by the developer
EOD yesterday and progressing today.


> Restore from backup continues to fail
> https://bugs.launchpad.net/juju-core/+bug/1606308
> https://bugs.launchpad.net/juju-core/+bug/1604959
> https://bugs.launchpad.net/juju-core/+bug/1605653
> ^ There are many issues seen in testing restore. Mongo setup is the
> dominate theme of the faillures
>
> Juju 2.0-beta12 userdata execution fails on Windows
> https://bugs.launchpad.net/juju-core/+bug/1604474
> ^ This bug has a fix committed, but the test that deploys windows
> charms on azure still fails. Testing with a juju from the first week
> of July passes. We might decide this bug is fixed, but separate one of
> the duplicate bugs to track a new issue about workloads not deploying.
>

Thanks, I've pulled back in and we'll investigate with the additional data
provided. Thanks for the heads up.


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

Re: Schema for Juju RPC messages

[Rick Harding]

>
> That being said, any API client that requires three API calls to login
> should be beat over the head with a fail stick, but there are many cases
> where performing some workflow might require multiple api calls. The API
> clients should work out a single function of "doSomethingAwesome(param1,
> pararm1)" when it's in fact performing multiple API steps because it makes
> sense for end users, or I guess developers in this case.
>

Just to flesh this out with an obvious example that came to mind. There are
three "addCharm"-ish API calls.

addCharm [1]
addCharmWithAuthorization [2]
addLocalCharm [3]

Writing an API client in Python or other languages I'd want to provide a
single addCharm method that just made the right API call to Juju based on
the arguments provided. If you provided a macaroon  from a current logged
in session, I'd make a addCharmWithAuthorization. If you passed a local
'./' path as the charm url then I'd call out with addLocalCharm.
There's no need to push the complexity of those three different calls to
the end user of the API client.

My understanding is that we need three distinct calls in the API because of
Go and the way that these things need to be declared/defined. However,
pushing that down into API clients is pushing implementation details (Go in
this case) down into clients in other languages where this would not be so
required.

1: https://godoc.org/github.com/juju/juju/api#Client.AddCharm
2:
https://godoc.org/github.com/juju/juju/api#Client.AddCharmWithAuthorization
3: https://godoc.org/github.com/juju/juju/api#Client.AddLocalCharm
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Schema for Juju RPC messages

[Rick Harding]

On Wed, Jul 27, 2016 at 3:18 PM Katherine Cox-Buday <
katherine.cox-bu...@canonical.com> wrote:

> Good point, Mark. I agree that it's difficult to make an auto-generated
> client idiomatic/nice to use. What I like to do is use the schema to
> auto-generate the boilerplate, and then wrap that with a small shim that is
> more crisp.
>
> Do you have an opinion on this approach?


I think that using a schema to help generate useful documentation and
improved error messaging/API input validation when the API isn't used
correctly (as in the case of what drove John to chase this down originally
[1]) is great and awesome. It keeps docs in sync with reality and forces us
to focus on the naming and thoughtfulness of the API since future work is
generated from the actual code. We don't get to fake it.

However, an API client in any language should never be auto generated.
Languages are unque and value different things. An API client is all about
taking a given API, and mapping it to the ideas and constructs a language
values. For instance, a python client for an API would not expect to expose
to users of that client HTTP error codes. They'd expect those to get mapped
to proper exceptions that mean something in Python to the user. A
JavaScript API would expect to have the API mapped to data types and other
constraints that JS present that won't make sense for other languages.

On top of that, clients are meant to be used by users farther down the
pipe. The API calls themselves are meant to be used by a few client
authors. Those client authors are intended to provide abstractions,
shortcuts, and workflows that may span multiple API calls to the end user.
Imagine an API that takes three steps to login. API clients should work
hard to map those to a single API client function call, internalizing the
complexity of the API so that the broad user base of the client does't have
to deal with that complexity.

There's no way to auto generate a client that does these helpful and
necessary simplifications across a given API automatically.

That being said, any API client that requires three API calls to login
should be beat over the head with a fail stick, but there are many cases
where performing some workflow might require multiple api calls. The API
clients should work out a single function of "doSomethingAwesome(param1,
pararm1)" when it's in fact performing multiple API steps because it makes
sense for end users, or I guess developers in this case.

1: https://bugs.launchpad.net/juju-core/+bug/1585289
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju CI is updated to test the autoload-credentials changes

[Rick Harding]

Thanks Curtis, appreciate the catch and the update.

On Mon, Jul 25, 2016 at 6:34 PM Curtis Hovey-Canonical 
wrote:

> We saw the autoload-credential test failures this morning. The test is
> strongly coupled to the prompt text. We updated the test to support
> the new text, then re-ran the last failure to show there is no issue
> in master
>
> https://bugs.launchpad.net/juju-ci-tools/+bug/1606242
>
> --
> Curtis Hovey
> Canonical Cloud Development and Operations
> http://launchpad.net/~sinzui
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: RFC: remove juju publish?

[Rick Harding]

/me takes Tim's candy and yells "bad Tim! that was Aaron's candy!"

On Sun, Jul 17, 2016 at 4:53 PM Tim Penhey <tim.pen...@canonical.com> wrote:

> Was actually Aaron, I was just confirming with the list :-)
>
> Tim
>
> On 16/07/16 00:08, Rick Harding wrote:
> > +1, good catch thanks Tim.
> >
> > On Fri, Jul 15, 2016 at 3:15 AM roger peppe <rogpe...@gmail.com
> > <mailto:rogpe...@gmail.com>> wrote:
> >
> > Yes, it should be removed. It's superceded by charm push.
> >
> > On 15 July 2016 at 04:32, Tim Penhey <tim.pen...@canonical.com
> > <mailto:tim.pen...@canonical.com>> wrote:
> >  > Does 'juju publish' still serve a purpose in Juju 2.0?
> >  >
> >  > Should we just remove it?
> >  >
> >  > Tim
> >  >
> >  > --
> >  > Juju-dev mailing list
> >  > Juju-dev@lists.ubuntu.com <mailto: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 <mailto: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: Verification of proper model destroy in Azure

[Rick Harding]

and decided to update the bug so whe, time to put things away for the
night.

On Fri, Jul 15, 2016 at 10:03 PM Rick Harding <rick.hard...@canonical.com>
wrote:

> I upgraded to b12 and repeated. The error is different in b12:
>
> juju status
> ERROR unknown model: "55459f0f-56c8-4f0b-8cf7-b8a1042df2aa" (not found)
>
> It's the same deal where you give a destroy, but it takes some 60+ seconds
> for status to give up the ghost. You get the lack of focus message on the
> first juju status, but if you switch away and back to the dying model, you
> can run status up until it gives you either the b11 or b12 errors.
>
> On Fri, Jul 15, 2016 at 9:35 PM Rick Harding <rick.hard...@canonical.com>
> wrote:
>
>> It's a timing thing. I bootstrapped with b11 on azure and will here's my
>> shell history:
>>
>> https://pastebin.canonical.com/161089/
>>
>> Note that after destroy the model was still around, I could switch of/to
>> it, and it showed in the model list. It was somewhere in there were it
>> finally went away. My attempt at debug-log hung so I ctrl-c'd and then
>> after that, while still on the model that should be gone, I got the error
>> that Mark did.
>>
>> Let me know if you want to pull this into the bug or you'd like me to add
>> to it in any way.
>>
>> On Fri, Jul 15, 2016 at 9:13 PM Alexis Bruemmer <
>> alexis.bruem...@canonical.com> wrote:
>>
>>> *If* someone is in azure already can they please verify that they can
>>> destroy a model and get this message when running "juju status" in the
>>> destroyed model:
>>>
>>> "juju status
>>> ERROR no model in focus
>>>
>>> Please use "juju models" to see models available to you.
>>> You can set current model by running "juju switch"
>>> or specify any other model on the command line using the "-m" flag."
>>>
>>> see https://bugs.launchpad.net/juju-core/+bug/1602034 for background.
>>> The code path mark hit is not in beta12 anymore (thank you roger!)  but I
>>> dont want to push back until we verified in azure.
>>>
>>>
>>> --
>>> Alexis Bruemmer
>>> Juju Core Manager, Canonical Ltd.
>>> (503) 686-5018
>>> alexis.bruem...@canonical.com
>>>
>>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Verification of proper model destroy in Azure

[Rick Harding]

I upgraded to b12 and repeated. The error is different in b12:

juju status
ERROR unknown model: "55459f0f-56c8-4f0b-8cf7-b8a1042df2aa" (not found)

It's the same deal where you give a destroy, but it takes some 60+ seconds
for status to give up the ghost. You get the lack of focus message on the
first juju status, but if you switch away and back to the dying model, you
can run status up until it gives you either the b11 or b12 errors.

On Fri, Jul 15, 2016 at 9:35 PM Rick Harding <rick.hard...@canonical.com>
wrote:

> It's a timing thing. I bootstrapped with b11 on azure and will here's my
> shell history:
>
> https://pastebin.canonical.com/161089/
>
> Note that after destroy the model was still around, I could switch of/to
> it, and it showed in the model list. It was somewhere in there were it
> finally went away. My attempt at debug-log hung so I ctrl-c'd and then
> after that, while still on the model that should be gone, I got the error
> that Mark did.
>
> Let me know if you want to pull this into the bug or you'd like me to add
> to it in any way.
>
> On Fri, Jul 15, 2016 at 9:13 PM Alexis Bruemmer <
> alexis.bruem...@canonical.com> wrote:
>
>> *If* someone is in azure already can they please verify that they can
>> destroy a model and get this message when running "juju status" in the
>> destroyed model:
>>
>> "juju status
>> ERROR no model in focus
>>
>> Please use "juju models" to see models available to you.
>> You can set current model by running "juju switch"
>> or specify any other model on the command line using the "-m" flag."
>>
>> see https://bugs.launchpad.net/juju-core/+bug/1602034 for background.
>> The code path mark hit is not in beta12 anymore (thank you roger!)  but I
>> dont want to push back until we verified in azure.
>>
>>
>> --
>> Alexis Bruemmer
>> Juju Core Manager, Canonical Ltd.
>> (503) 686-5018
>> alexis.bruem...@canonical.com
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Verification of proper model destroy in Azure

[Rick Harding]

It's a timing thing. I bootstrapped with b11 on azure and will here's my
shell history:

https://pastebin.canonical.com/161089/

Note that after destroy the model was still around, I could switch of/to
it, and it showed in the model list. It was somewhere in there were it
finally went away. My attempt at debug-log hung so I ctrl-c'd and then
after that, while still on the model that should be gone, I got the error
that Mark did.

Let me know if you want to pull this into the bug or you'd like me to add
to it in any way.

On Fri, Jul 15, 2016 at 9:13 PM Alexis Bruemmer <
alexis.bruem...@canonical.com> wrote:

> *If* someone is in azure already can they please verify that they can
> destroy a model and get this message when running "juju status" in the
> destroyed model:
>
> "juju status
> ERROR no model in focus
>
> Please use "juju models" to see models available to you.
> You can set current model by running "juju switch"
> or specify any other model on the command line using the "-m" flag."
>
> see https://bugs.launchpad.net/juju-core/+bug/1602034 for background.
> The code path mark hit is not in beta12 anymore (thank you roger!)  but I
> dont want to push back until we verified in azure.
>
>
> --
> Alexis Bruemmer
> Juju Core Manager, Canonical Ltd.
> (503) 686-5018
> alexis.bruem...@canonical.com
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: juju beta upgrade woes

[Rick Harding]

Daniel, sorry for the trouble there. As we work on things in the beta there
are times when the upgrade from one beta to another might cause issues like
this. You're hitting an incompatibility between the beta you were on and
the latest. The only fix is to tear down and redeploy with the latest beta.

As we get closer to feature complete and RC that will change and things
will stabilize and upgrades between releases will not have this side
drawback but we're not there yet.

Please beat on and abuse 2.0 betas as much as you can as it helps provide
great feedback from users that are getting into all the exciting
improvements to the Juju experience we've made. However, if it's something
that's mission critical please do use 1.25 until we can get to our RC
status on 2.0.

On Fri, Jul 15, 2016 at 1:00 PM Daniel Bidwell  wrote:

> using juju-2.0 beta 9 or 10 I bootstrapped a local/lxd instance and
> installed wordpress on it.  The containers are running.  Now juju has
> upgraded to 2.0 beta 11 and "juju status" returns:
>
> ERERROR connecting with bootstrap config: getting API info: model is
> not bootstrapped
>
> juju controllers returns:
>
> CONCONTROLLER  MODELUSER CLOUD/REGION
> local.wp*   default  admin@local
>
> Is there a way for me to "get it back" or do I just need to blow it
> away and start again?
>
> Should I be dropping back to juju 1.25.x for this?
>
> --
> 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: RFC: remove juju publish?

[Rick Harding]

+1, good catch thanks Tim.

On Fri, Jul 15, 2016 at 3:15 AM roger peppe  wrote:

> Yes, it should be removed. It's superceded by charm push.
>
> On 15 July 2016 at 04:32, Tim Penhey  wrote:
> > Does 'juju publish' still serve a purpose in Juju 2.0?
> >
> > Should we just remove it?
> >
> > Tim
> >
> > --
> > Juju-dev mailing list
> > Juju-dev@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: authorized-keys is now optional

[Rick Harding]

Thanks Andrew.

On Fri, Jul 8, 2016 at 8:50 AM Andrew Wilkins <andrew.wilk...@canonical.com>
wrote:

> On Fri, Jul 8, 2016 at 8:30 PM Rick Harding <rick.hard...@canonical.com>
> wrote:
>
>> Thanks Andrew. Do we hvae some hinting error messages in place for when a
>> user attempts to juju ssh, juju run, etc and the ssh key is not set for the
>> user that leads them to the add-ssh-key commands?
>>
>
> No. I've filed https://bugs.launchpad.net/juju-core/+bug/1600221.
>
>
>> Thanks
>>
>> Rick
>>
>> On Fri, Jul 8, 2016 at 12:15 AM Andrew Wilkins <
>> andrew.wilk...@canonical.com> wrote:
>>
>>> Hi users of the add-model API,
>>>
>>> The authorized-keys config is now only required at bootstrap time,
>>> because bootstrapping involves an SSH step. This means you no longer need
>>> to specify authorized-keys in your config for add-model.
>>>
>>> The Juju CLI will now automatically read ~/.ssh/id_rsa.pub and friends
>>> into authorized-keys when adding a model, just as bootstrap does. If no
>>> public keys are found, a warning will be displayed. You can still add keys
>>> later using the "juju add-ssh-key" command.
>>>
>>> If you've been specifying a nonsense authorized-keys value just to get
>>> add-model to work (hi Juju GUI), then please change your code to not pass
>>> anything. At the moment we do not validate the input, but we may want to
>>> change that later on.
>>>
>>> (This is on master, and will go into 2.0-beta12.)
>>>
>>> Cheers,
>>> Andrew
>>>
>> --
>>> 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: authorized-keys is now optional

[Rick Harding]

Thanks Andrew. Do we hvae some hinting error messages in place for when a
user attempts to juju ssh, juju run, etc and the ssh key is not set for the
user that leads them to the add-ssh-key commands?

Thanks

Rick

On Fri, Jul 8, 2016 at 12:15 AM Andrew Wilkins 
wrote:

> Hi users of the add-model API,
>
> The authorized-keys config is now only required at bootstrap time, because
> bootstrapping involves an SSH step. This means you no longer need to
> specify authorized-keys in your config for add-model.
>
> The Juju CLI will now automatically read ~/.ssh/id_rsa.pub and friends
> into authorized-keys when adding a model, just as bootstrap does. If no
> public keys are found, a warning will be displayed. You can still add keys
> later using the "juju add-ssh-key" command.
>
> If you've been specifying a nonsense authorized-keys value just to get
> add-model to work (hi Juju GUI), then please change your code to not pass
> anything. At the moment we do not validate the input, but we may want to
> change that later on.
>
> (This is on master, and will go into 2.0-beta12.)
>
> Cheers,
> Andrew
> --
> 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: Automatic commit squashing

[Rick Harding]

I'm going to push back on the why squash or even the "let's make it just
auto clean it up".

A commit to the tree should be a single, well thought out, chunk of work
that another can review and process easily. Having the history of how you
got there isn't valuable in my opinion. The most important thing is to have
something I can look at in a diff, code review, etc and make sense of it.
If I need to go through the 10 commits that built it up to make sense of
it, then the commit is too big or fails in some other way.

Doing this helps with the ideas we're all talking about. Making things
easier to review, easier to land against master, easier to review and
debug. This comes down to things I've discussed about breaking kanban cards
down into a single pull request worth of work, and breaking it down smaller
and smaller until you get there. The ideas need to get cut down and be
something that someone else can look at and understand. Doing it any other
way I think just continues with many of the issues we're fighting today.

On Thu, Jun 16, 2016 at 12:16 PM James Tunnicliffe <
james.tunnicli...@canonical.com> wrote:

> TLDR: Having guidelines rather than rules is good. Having a tool
> mindlessly squashing commits can throw away valuable information.
>
> I am a little confused as to why we need to squash stuff at all. Git
> history isn't flat so if you don't want to see every commit in a
> branch that has landed then you don't have to. I realise that I am a
> scummy GUI user and I haven't looked at how to use the git CLI to do
> this. I am not against squashing commits to provide a nice logical
> history without the 'fix the fact that I am dumb and missed that
> rename' noise, but I don't think squashing to a single commit is
> always the right thing to do.
>
> Once code is up for review I want the history to remain from the start
> to the end of the review loop so if I ask someone to change something
> I can actually see that change. I have no problem with those commits
> being squashed pre-merge if they are minor changes to the originally
> proposed code.
>
> James
>
> On 16 June 2016 at 08:25, Marco Ceppi  wrote:
> > This is purely anecdotal, but on the ecosystem side for a lot of our
> > projects I've tried to psuedo-enforce the "one commit", or really, a
> > change/fix/feature per commit. Thereby allowing me to cherrypick for
> patch
> > releases to stable (or revert a commit) with confidence and without a
> lot of
> > hunting for the right grouping.
> >
> > With the advent of squashing in github I've dropped this push and use
> this
> > unless the author has already done the logical grouping of commits, in
> which
> > case I'll merge them myself, out of github, to avoid merge messages but
> > retain their grouping (and potentially modify commit messages, to make it
> > easier to identify the PR number and the bug number it fixes).
> >
> > I don't think the Juju core project can just carte blanche squash every
> pull
> > request, but I do think it's up to the code authors to put an effort in
> to
> > squashing/rewriting/managing their commits prior to submittion to make
> the
> > code's history more observable and manageable overtime. Much in the same
> way
> > you would document or comment blocks of code, commits are a window into
> what
> > this patch does, if you want to keep your history, for reference,
> branching
> > is cheap in git and you absolutely can.
> >
> > Happy to share more of the latter mentioned workflow for those
> interested,
> > but otherwise just some 2¢
> >
> > Marco
> >
> > On Thu, Jun 16, 2016 at 10:12 AM John Meinel 
> wrote:
> >>
> >> Note that if github is squashing the commits when it lands into Master,
> I
> >> believe that this breaks the ancestry with your local branch. So it
> isn't a
> >> matter of "the history just isn't present in the master branch", but "it
> >> looks like a completely independent commit revision, and you have no
> obvious
> >> way to associate it with the branch that you have at all".
> >>
> >> It may be that git adds information to the commit ('this commit is a
> >> rollup of hash deadbeef") in which case the git tool could look it up.
> >>
> >> I don't know the github UI around this. If I do "git merge --squash"
> then
> >> it leaves me with an uncommitted tree with the file contents updated,
> and
> >> then I can do "git commit -m new-content"
> >>
> >> And then if I try to do:
> >> $ git branch -d test-branch
> >> error: The branch 'test-branch' is not fully merged.
> >> If you are sure you want to delete it, run 'git branch -D test-branch'
> >>
> >> Which indicates to me that it intentionally forgets everything about all
> >> of your commits, which mean you need to know when it got merged so that
> you
> >> can prune your branches, because the tool isn't going to track what has
> and
> >> hasn't been merged.
> >>
> >> (I don't know about other people, but because of the delays of waiting
> for
> 

Re: Juju 2.0-beta9 ETA

[Rick Harding]

Thanks Tim and I want to say that I really appreciate this change. The way
the API exposed the Go-ism that all exported attributes are capitalized has
been annoying for some time. I really appreciate you cleaning that up for
users of the API.

I think the only thing I'd change on this is that we notify users that it's
going on with an email to the public Juju list. We've got the patch and
let's definitely consider this heads up to everyone in the ecosystem that
the change is coming and look for this in a daily build coming to you very
soon.

On Wed, Jun 15, 2016 at 4:36 PM Tim Penhey  wrote:

> Hi folks,
>
> Due to a change I landed without fully thinking through the
> implications, the reverting of said change has pushed us out a day.
>
> I was trying to add consistency to the wire-protocol that Juju uses by
> changing the serialisation names. Thinking that we were still in the "we
> don't need no backward compatibility phase" I made this change without
> bumping the facade versions. This would have broken all the API users.
> This is what we are backing out.
>
> Sorry for the inconvenience.
>
> Tim
>
> On 15/06/16 12:19, Cheryl Jennings wrote:
> > Hi Everyone,
> >
> > Due to a critical bug [0] found in the daily PPA, the release of
> > 2.0-beta9 will be delayed while we test the fix.  We are aiming for a
> > release tomorrow.
> >
> > Thanks!
> > -Cheryl
> >
> > [0] https://bugs.launchpad.net/juju-core/+bug/1592210
> >
> > On Fri, Jun 10, 2016 at 1:20 PM, Cheryl Jennings
> > >
> > wrote:
> >
> > The team has been busily working on 2.0-beta9 with an aim to address
> > usability feedback and ensure that beta9 will be upgradeable to
> > subsequent releases.  Ensuring upgradeability has required a
> > significant amount of work to finalize internal details, and the
> > team needs a few extra days to make sure this work is completed.
> >
> > To achieve this guarantee, we are moving the expected date for
> > 2.0-beta9 to Tuesday, June 14.
> >
> > Some of the great things coming in beta9 include:
> > - Renaming of 'service' to 'application' to better align terminology
> > - Shortened instance IDs for the lxd provider (ex: 'juju-622af3-0')
> > - Addition of a `juju unregister` command to remove references to
> > controllers
> > - Separation of controller config vs. model config
> > - Improved status output
> > - Numerous bug fixes
> >
> > There is an early beta9 available in the juju daily ppa
> > (ppa:juju/daily) for those who wish early access to the above
> features.
> >
> > If you have any questions, please let me know.
> > Thanks!
> > -Cheryl
> >
> >
> >
> >
>
> --
> 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-beta9 ETA

[Rick Harding]

On Sat, Jun 11, 2016 at 6:32 PM Ian Booth  wrote:

> We are also storing any config specified in clouds.yaml separately. These
> items,
> such as apt-mirror, are shared between models and are used by default if
> not
> specified in a hosted model. But you can override any such items as well
> simply
> by setting them on the model. For now, the semantics of this change are
> transparent - get-model-config will show the accumulation of shared and
> model
> specific settings. But we are looking to add a command to show/set shared
> config. Thus you will be able to say update a http-proxy setting across all
> hosted models within a controller with one command:
>
> juju set-shared-config http-proxy=foo
>
> NB command name to be decided.
>

Ian, can we setup some time to chat on this. I'm curious if, rather than a
command to explicitly "set everywhere" we follow the model that the config
is inherited unless overridden for a specific model. Then by setting it on
the controller all models would get it. If you want it set on a specific
model, you'd set it on the model. In that way there'd not be a third/new
command for setting config.
-- 
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-beta9 ETA

[Rick Harding]

On Sat, Jun 11, 2016 at 11:33 AM Mark Shuttleworth  wrote:

> On 10/06/16 19:20, Cheryl Jennings wrote:
> > - Addition of a `juju unregister` command to remove references to
> > controllers
>
> Seems we have two different cases
>
>  * the opposite of register
>  * the opposite of bootstrap
>
> Why not just remove-controller and remove-account ?
>

The opposite of bootstrap we stuck with destroy as we kept destroy and
remove in the vocabulary because it was helpful to keep "not coming back"
like destroy-service and destroy-controller. I think with the safe guards
in place around destroy-controller I'm +1 with just moving to remove across
the board. It simplifies the language if we're ok with not keeping the
destroy vs remove semantics.

The opposite of register is harder. You're looking to remove an entry of
something you see in list-controllers. You put it there by registering and
giving it a name in that process. We don't have the noun/idea of "account"
in Juju at the moment. You add a User, which lead that user to registering
that controller. It lead us through share/unshare, register/unregister,
etc. It's not a remove/destroy controller as that's limited in who can do
that and is not something you want to accidentally do if you typo the wrong
entry in list-controllers.  I've felt like the least oddball of things was
to tie the command to remove the entry to the command you used to add it
and so we've been running with unregister.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju on Synnefo - which version?

[Rick Harding]

Hi Stavros, definitely target Juju 2.0. It's soon to be released and great
changes some fundamentals of Juju in order to make it easier for users to
use. You'll be much happier following the development release for this
early project of yours. I'm a bit biased, but I also think that path 2, a
real provider, is best because it lets you leverage the tooling around Juju
that users come to expect to help them manage large deployments of big
software on the cloud. While the first path might work out, I think in the
long run you'll end up finding more work to make things work for your users
as smoothly as you will get with path #2.

Please let me know if you have any other questions and I can't wait to see
how it works out.

On Tue, May 31, 2016 at 7:05 AM Stavros Sachtouris 
wrote:

> Hello, we are investigating the idea of a provider for our cloud
> software "Synnefo". We are currently in the "proof of concept" stage,
> but we like to plan ahead as early as possible, so I need your advice:
> what version of Juju should we work with? Are there considerable changes
> between the stable version and the one currently developed?
>
> More details on Synnefo and our Juju adventure:
>
> Synnefo (www.synnefo.org) is an OpenStack compatible (at least, in
> theory :) ) IaaS software. It is open source (GPLv3).
> The largest Synnefo deployment is ~okeanos (okeanos.grnet.gr) which
> provides thousands of VMs and terabytes of storage resources to the
> members of Greek and European accademic communities.
> Both are developed and supported by the Greek Reasearch Network of
> Technology (grnet.gr).
> We considering Juju as a solution for providing PaaS services to our
> users and we are in the investigation phase.
> We found out there are two ways of utilizing Juju:
>* we can use our own CLI to provision and register cloud resources to
> Juju, which will allow our users to deploy their charms on predefined
> sets of resources. This is easy to implement but requires more
> operations on our part.
>* we can "hack" into Juju and develop our own Synnefo provider with
> full support. We cannot use the OpenStack provider out of the box, but
> we can use most of it in our own extension. This will require
> considerably more effort, but will allow our users to fully utilize Juju
> on Synnefo and ~okeanos (e.g., GUI provisioning and scaling).
>
> --
> 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: admin model now called "controller" model

[Rick Harding]

This was brought up via a bug before the sprint and confirmed during the
sprint. Apolgoies Adam, while the bug was public, we failed to reach out as
this effects conjure up.

There are some other requests that the team are processing. I'd like to ask
that someone from Core meet with and Prep Adam on those so that he can be
aware as Conjure up is a big stakeholder here. Alexis, can you get someone
to run through them please? I'm thinking of things like
s/services/applications, status output format, bundle output format,
defaulting to the non-list commands, etc.

On Wed, May 25, 2016 at 12:13 PM Nate Finch 
wrote:

> I believe it was discussed at the Vancouver sprint.
>
> On Wed, May 25, 2016 at 12:09 PM Adam Stokes 
> wrote:
>
>> Where was this discussed?
>>
>> On Wed, May 25, 2016, 10:56 AM Nate Finch 
>> wrote:
>>
>>> The change is merging as we speak, so if you have scripts etc that need
>>> to be updated, do so before pulling master.
>>>
>> --
>>> 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: Fixing "juju help commands"

[Rick Harding]

Some feedback

If we have a debug command we should just show the debug commands. If we
don't want users to have them ootb they should be plugins then I would
think. This assumes the commands can't  do anything destructive or
otherwise harm a running model/etc by being run.

The get is there because of the set. Some things are read/write properties
and those are get/set. list vs show is meant to be around entities in the
Juju model. You can list them to see tabular output of info about the
entity and you can show them for single details. I appreciate the config
case seems odd, but config isn't a root model entity, it's a property and
you can set that and you can't set other entities in the model. I think it
makes sense to keep these.

The list one is tricky. list is there to be consistent, help users discover
entities in the model (list-), and to help easily see things in the
help text as it jumps out as a common pattern (you can list, show, etc
things). However, it was agreed that leaving off the list should default to
the list output. It reads nicer and seems to make the most sense for users
that know enough Juju to know what they're doing.

With that in mind, hiding them behind an --alias or what not seems counter
productive. It's not there in the main output for new users, the ones we're
aiming to serve. With this in mind, it makes the most sense to just remove
them then, which I don't personally like, but I think makes things the most
clean and with the most consistent story.

On Wed, May 25, 2016 at 2:52 PM Nate Finch  wrote:

> +1 ... one and only one way to do something is a lot easier to
> understand.  Either we like juju list-foos or we like juju foos... pick one
> and move on.  This feels like two camps agreed to disagree and just kept
> both.
>
> On Wed, May 25, 2016 at 10:12 AM Katherine Cox-Buday <
> katherine.cox-bu...@canonical.com> wrote:
>
>>
>> I think this has come up before on this list, but: isn't having 2 sets of
>> commands in the first place a design smell? If we need aliases because
>> users aren't using the originals, then  shouldn't we fix the original
>> commands?
>>
>> Tim Penhey  writes:
>>
>> > On 25/05/16 00:12, Marco Ceppi wrote:
>> >> Even if you don't expect people to run them, hidding them seems
>> >> awkward.
>> >> Better to simply educate with good help output about what the
>> >> command
>> >> does and when/why use the command.
>> >
>> > Was thinking, perhaps it would be better to have a feature flag to use
>> > the "hidden" commands instead of the ability to hide commands.
>> >
>> > If you set the feature flag, you get the additional commands, and they
>> > show up in help etc.  That way a way to get users to run them could be
>> > something like:
>> >
>> >   JUJU_FEATURE_FLAGS=dev-debug juju dump-model
>> >
>> > or something like that.
>> >
>> > Tim
>>
>> --
>> Katherine
>>
>> --
>> 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: auto-upgrading models

[Rick Harding]

The key thing is that soon our path on upgrading models is via model
migration. We should keep that in mind as we think of how best to lead the
user to 'just do the right thing'

On Mon, Apr 25, 2016, 2:38 PM Andrew Wilkins 
wrote:

> On Sat, Apr 23, 2016 at 4:15 AM Eric Snow  wrote:
>
>> In a recent bug I was working on the issue of auto-upgrading models
>> came up.  I also ran into this personally not too long ago.
>> Currently, running "juju upgrade-juju -m admin --upload-tools"[1]
>> upgrades the admin model to a new version.  To set the version of any
>> other model to the uploaded one, you must do so separately afterward,
>> e.g. "juju upgrade-juju -m default 2.0-rc1.3". [2]
>>
>> The fact that you must upgrade the non-admin model separately is
>> something new with multi-model support.  Perhaps it is only something
>> that will throw off folks that have relied on --upload-tools
>> previously and perhaps it is something that we'll just adjust to.
>> However, I wanted to bring the matter up here and identify potential
>> courses of action (not all mutually exclusive):
>>
>> 1. do nothing (rely on users to know to always upgrade juju per-model)
>> 2. clearly point this out in the documentation
>> 3. add a note in the output of "juju upgrade-juju --upload-tools"
>> reminding admins to manually upgrade each model
>> 4. make the "juju is out-of-date" warnings also show up for models
>> relative to the controller
>> 5. auto-upgrade models when the controller is upgraded
>> 6. auto-upgrade but have a flag to not auto-upgrade
>> 7. have a flag to auto-upgrade
>>
>
> Whatever we do, #2 should never be optional.
>
> I would like us to have all of #2, #3, #4, #7. For #3, we could say
> "upgrade each model ... or run `juju upgrade-juju --all-models
>  `".
>
> I don't think this should be restricted to "--upload-tools", but rather
> just upgrading the admin model in general.
>
> Cheers,
> Andrew
>
> FWIW, I don't consider #1 or #5 to be acceptable options.  I'm on the
>> fence about #6; it aligns with what I expect would be a better default
>> experience but hesitate to make unrequested changes of that sort by
>> default.  So #7 might be more appropriate if the consequences of #6
>> would be too risky.  Regardless, I do think the user experience of
>> upgrade-juju could be improved.
>>
>> Thoughts?
>>
>> -eric
>>
>>
>> [1] You can no longer upload tools to any other model than admin.
>> [2] Thankfully, due to some recent work by axw the new version is
>> *available* to all models.
>>
>> --
>> 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: Unable to kill-controller

[Rick Harding]

On Wed, Apr 6, 2016 at 8:25 PM Andrew Wilkins <andrew.wilk...@canonical.com>
wrote:

> On Wed, Apr 6, 2016 at 11:28 PM Rick Harding <rick.hard...@canonical.com>
> wrote:
>
>> I strongly feel that we're avoiding and dancing around the issue.
>>
>> The user should NEVER EVER have to use kill-controller. If someone types
>> that we've failed to build Juju to the standards to which I feel we all
>> should expect us to live up to. There is only ONE way for a user to take
>> down a controller, destroy-controller.
>>
>
> I think it would be better if we hid kill-controller, but it's clear from
> the bugs that people *are* using kill-controller and expecting it to be
> more or less safe to use.
>

But this comes back to what started this. People are using it because
destroy-model isn't working for them. It's one part bug that it's not the
reverse of bootstrap in its current form and one part that we've broken
cleanup between betas so folks are looking for something that works. People
are looking for it because they've got no choice.



> What about this scenario:
> - Alice bootstraps, and adds user Bob with admin access.
> - Bob registers the controller.
> 
> - The controller is still running and available, but Bob no longer needs
> access to it.
>
> How does Bob remove the controller from his client without destroying it?
> He's an admin, so "destroy-controller" will happily destroy everything.
>
> If we add a flag to destroy-controller to only clean up the cache, then
> "oops, I forgot to add the flag" and now all the models are gone.
>
>
Agree that this is a mess. This is part that we don't have a way to give
folks access without making them admins. I've got this towards the top of
our 16.10 roadmap. I'd rather we did something temp with a plugin here or
the like until we can get a real solution in place. This does bring up how
this is going to work with other hosted model solutions.


> I don't feel that adding another command for another way to remove a
>> controller from list-controllers is something we want to do and we
>> especially don't want to do it this week as we try to freeze 2.0 for
>> release.
>>
>> If folks think I'm missing a point please reach out to me and lets move
>> this to a high-bandwidth discussion, but I wanted to share the original
>> design/thought on the destroy vs kill controller commands. I want everyone
>> to share the feeling that if our users ever type kill-controller into their
>> terminals we've failed them and realize that.
>>
>
> If you like, we can leave it as-is for 2.0 -- no command to clean up the
> cache -- and talk about it at the next sprint.
>

I think that's best. I'd love to stop and figure this out right, but with
everything breathing down our neck I fear we'll make a mistake we're stuck
with until 3.0.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Unable to kill-controller

[Rick Harding]

I strongly feel that we're avoiding and dancing around the issue.

The user should NEVER EVER have to use kill-controller. If someone types
that we've failed to build Juju to the standards to which I feel we all
should expect us to live up to. There is only ONE way for a user to take
down a controller, destroy-controller.

If a user has models running on that controller we've given them a flag to
safely say "I know I have stuff running, but I don't care" with the current
stuff running on there.

I completely understand that destroy-controller is not the reverse of
bootstrap. We've filed a bug for that and should correct the bug rather
than moving to other commands and processes to deal with that.

https://bugs.launchpad.net/juju-core/+bug/1563615

kill-controller is a top secret tool we keep in our back pockets for
emergency debugging when crap that's beyond our planning/control has
occurred and we've not yet updated destroy-controlller to be able to handle
that. It should not be in the main docs, release notes, etc. It's
dangerous, folks should be discouraged from ever using it. Even when we do
use it, we should be saying things like "Well, destroy-controller seems to
be broken, we've got this potentially messy/risky way of trying to work
around it that we can try...but..."

As for the user case where a user registers on someone else's controller
and wants to no longer have that controller appear, then we should update
destroy-controller to handle that. There's only ONE way to remove a
controller from your list, destroy-controller. We should be able to note
that the user requesting destroy-controller does not have sufficient access
to remove it and tell them "You've got these models running on this
controller". And if they want to destroy with the flag to remove all their
models, then we should do that and remove it from their system. If they
have no running models, we should note that we're removing that
controller's information from their system. If there's user confusion we
can look at a message "You are not the controller admin, removing the
controller information from your cache" or the like.

I don't feel that adding another command for another way to remove a
controller from list-controllers is something we want to do and we
especially don't want to do it this week as we try to freeze 2.0 for
release.

If folks think I'm missing a point please reach out to me and lets move
this to a high-bandwidth discussion, but I wanted to share the original
design/thought on the destroy vs kill controller commands. I want everyone
to share the feeling that if our users ever type kill-controller into their
terminals we've failed them and realize that.

Thanks

Rick

On Wed, Apr 6, 2016 at 11:02 AM Cheryl Jennings <
cheryl.jenni...@canonical.com> wrote:

> Another relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1566426
>
> Maybe kill-controller tries to destroy through the API, but has a time out
> if things get "stuck" where it will fall back to the provider.  I was
> joking when I suggested yesterday in IRC that we should bring back --force
> for kill-controller, but maybe we need it (or at least a timeout).
>
> On Wed, Apr 6, 2016 at 7:53 AM, Nate Finch 
> wrote:
>
>> Oh I see.  Yes, I agree that we should always try the right way first and
>> only use the provider if necessary (especially if using the provider leaves
>> garbage around).
>>
>> It seems like there's no reason why we couldn't make a --force flag do it
>> that way in 2.0 (aside from time constraints).
>>
>> On Wed, Apr 6, 2016 at 10:48 AM Aaron Bentley <
>> aaron.bent...@canonical.com> wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> On 2016-04-06 10:45 AM, Nate Finch wrote:
>>> > Wait, didn't destroy-environment --force fall back to the provider?
>>> > I thought that was the whole point of --force
>>>
>>> No, it didn't fall back.  It uses the provider unconditionally,
>>> without trying a normal destroy-controller first.
>>>
>>> Aaron
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v2
>>>
>>> iQEcBAEBCAAGBQJXBSG5AAoJEK84cMOcf+9hzSQIAJ/vNKIa1/TnDSyvC2U9ApzW
>>> TAEvSqaEUw0ZL2dl2tiNKTp3JPzcnCR4VKrBIsh1xi0hB1UNtJR+IW4O46gRI6ok
>>> ZvA1cAvoJvRdmqf1ntNzYwHRSn/Tm82DGzixTPt0TcTn3KYrk13XpRJuxMbbvHDM
>>> LfYG0zglGmVKUaWs4rBogh4H4OaiOIR8lORXSC8GRQjA1/C4c+FjIg+KeW5Yw2Ti
>>> XnG87BPyJ1TtPGWxxeKAk4tnkZwnZKtJOnHU/IfvTFOpECdBjojWnnc6VbQ1um0H
>>> WwjR6EcA4qxkkhND6ypIGkt9A4k3ZZvckCau52EgIn3pnwhk5OSw64MURJAEmn0=
>>> =vm/H
>>> -END PGP SIGNATURE-
>>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Unable to kill-controller

[Rick Harding]

+1 to the -1 of a new command for this. I'd like to raise the discussion
with the technical board as I'd like understand why the change the change
that the team had to make made it impossible for kill-controller to
function and what we could do to allow the team to remove legacy code, but
still be able to kill off things.

On Tue, Apr 5, 2016 at 11:55 PM Andrew Wilkins <andrew.wilk...@canonical.com>
wrote:

> On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings <
> cheryl.jenni...@canonical.com> wrote:
>
>> Relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1553059
>>
>> We should provide a way to clean up controllers without making the user
>> manually edit juju's files.
>>
>
> Unless anyone objects, or has a better spelling, I will be adding a
> command to do this:
>
> juju purge-controller 
>
> The command will require a "-y" or prompt for confirmation, like
> kill-controller. It will not attempt to destroy the controller, it will
> just remove the details of it from the client.
>
> (Alternative suggestion for spelling: "juju forget-controller".
> Purge-controller may suggest that we're purging a controller of its
> contents, rather than purging the controller from the client?)
>
> Cheers,
> Andrew
>
> On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch <nate.fi...@canonical.com>
>> wrote:
>>
>>> This just happened to me, too.  Kill-controller needs to work if at all
>>> possible.  That's the whole point.  And yes, users may not hit specific
>>> problems, but devs do, and that wastes our time trying to figure out how to
>>> manually clean up the garbage.
>>>
>>> On Mon, Apr 4, 2016 at 8:33 AM Rick Harding <rick.hard...@canonical.com>
>>> wrote:
>>>
>>>> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
>>>> andrew.wilk...@canonical.com> wrote:
>>>>
>>>>> In a non-beta release we would make sure that the config changes
>>>>> aren't backwards incompatible.
>>>>>
>>>>
>>>> I think this is the key thing. I think that kill-controller is an
>>>> exception to this rule. I think we should always at least give the user the
>>>> ability to remove their stuff and start over with the new alpha/beta/rc
>>>> release. I'd like to ask us to explore making kill-controller an exception
>>>> to this policy and that if tests prove we can't bootstrap on one beta and
>>>> kill with trunk that it's a blocking bug for us.
>>>> --
>>>> 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: Unable to kill-controller

[Rick Harding]

On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins 
wrote:

> In a non-beta release we would make sure that the config changes aren't
> backwards incompatible.
>

I think this is the key thing. I think that kill-controller is an exception
to this rule. I think we should always at least give the user the ability
to remove their stuff and start over with the new alpha/beta/rc release.
I'd like to ask us to explore making kill-controller an exception to this
policy and that if tests prove we can't bootstrap on one beta and kill with
trunk that it's a blocking bug for us.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Reserved actions

[Rick Harding]

+1 to reserving the juju* space just as we do with relations and such.

On Mon, Mar 28, 2016 at 10:12 PM Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:

> On Tue, Mar 29, 2016 at 10:03 AM Marco Ceppi 
> wrote:
>
>> On Mon, Mar 28, 2016 at 9:49 PM Andrew Wilkins <
>> andrew.wilk...@canonical.com> wrote:
>>
>>> Hi,
>>>
>>> There's a code review in progress (http://reviews.vapour.ws/r/4286/)
>>> that will introduce a predefined action, "juju-run", which is part of the
>>> replacement for the current SSH-based juju-run.
>>>
>>
>> This is interesting. What's the semantics for this? How does juju-run
>> action work for machine level items?
>>
>
> From the end-user perspective, juju run should work just the same as
> before. There will be a machine-level worker in Juju that will initially
> handle only juju-run actions. It's not expected that you'll use juju-run
> actions directly, but I don't think there's anything stopping you.
>
> This means that "juju-run" will no longer be a valid action name for use
>>> in a charm. This may come up again in the future, so we think it would be
>>> prudent to reserve a namespace for additional predefined actions. The most
>>> straightforward thing to do would be to reserve the "juju-" prefix, like we
>>> do for relations.
>>>
>>
>> This seems fine, we'll add "juju-run" as a blacklist in charm proof.
>>
>
> If everyone's OK with reserving the "juju-" prefix, I think it would be
> better to blacklist the whole namespace. Nip it in the bud.
>
>
>> Any objections? Does anyone have any actions using the "juju-" prefix
>>> already?
>>>
>>
>> I don't believe so, I'l do a quick search in the charm store though to
>> verify
>>
>>
>>> Cheers,
>>> Andrew
>>>
>> --
>>> 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: Openstack HA Portland Meetup Present

[Rick Harding]

Thanks for the update James, glad things went so well! From our end, we
appreciate the awesome first hand user feedback you're always willing to
reach out and provide. Our stuff just gets better with folks like you
putting it to the test day in and day out. I can't wait to get you some of
the new stuff coming that I think will greatly improve your next
presentation!

Rick

On Fri, Mar 18, 2016 at 1:42 AM James Beedy  wrote:

> I just gave this presentation --> http://54.172.233.114/ at an Openstack
> meetup at puppet headquarters in Portland, geared around HA Openstack
> production deployments. I wanted to update the team of the great news! It
> was by far the best presentation I have ever given, which isn't saying
> much, but peoples heads were turning in disbelief of what they were
> seeing the entire time :-) Alongside my slides, I gave a live demo of the
> load balancing of my juju deployed presentation in real time as the group
> was accessing it. Following that, I scaled out my presentation by adding a
> unit of `present` live. Also, I went out on a limb and live demoed a fully
> ha test stack, adding a lxc unit of glance to one machine and removing it
> from another whilst keeping quorum, and lightly touched on how the
> hacluster charm works, and a bit on the concept of interfaces and deploying
> from the juju-gui. There was a surprising amount of interest in Juju
> following my presentation, a good amount of people had never heard of juju,
> most of them seemed to be blown away by what they had just witnessed :-)
>
> On that note, I want to thank everyone for the work you have all done to
> get the Juju ecosystem/framework to where it is today. As nice as it was to
> see my test stack preforming so well at the demo, its much more fulfilling
> to know that my production stack is purring like a kitten too... no
> downtime for 6+ months (since her production inception)!!!  Over the past 6
> months, I have had some major issues that I have resolved, and with no
> service downtime! To that extent, I may of ripped my stacks guts out and
> then put them back in again... quite a few times with services running
> atop her -- its nice to see I can do all of that and she still stands and
> is able to recover and regain a healthy state.
>
> Here are the ip addresses and repos for my presentation. For anyone
> interested, you can login to the haproxy stats and see the traffic
> generated! As a side note - I was able to spin this all up and present
> using my charm dev amazon account --> HUGE +1 for the charm developer
> program!!
>
>
> presentation: http://54.172.233.114/
> haproxy stats: http://54.172.233.114:1/  --> un: admin, pw: password
> presentation markdown: https://github.com/jamesbeedy/os-ha-meetup-present
> layer present: https://github.com/jamesbeedy/layer-present
> https://github.com/jamesbeedy/os_ha_test_stack
>
>
> Thanks all!
>
> ~James
>
>
> --
> Juju mailing list
> j...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Do we still need juju upgrade-charm --switch ... ?

[Rick Harding]

The one use case that came up just this week is the ability to crosscrade
from different channels of charms in the new charm publishing world. You
deploy the charm from the stable path.

You find a bug, and the charm author tests a fix and publishes it to the
development channel. The author then reaches out to you to test the fix.
You could use upgrade-charm to switch tracking the stable channel to the
development channel and back.

I think it's typically used to move a running deployment to a fork of a
charm that is either maintained, has a bugfix you want, or other such
reasons.

I think we want to keep it. Can we make it safer? Provider better docs? I
think so, but I don't think we can remove it.

On Thu, Mar 10, 2016 at 10:28 PM Ian Booth  wrote:

> So we have a feature of upgrade-charm which allows you to crossgrade to a
> different charm than the one originally deployed.
>
> From the upgrade-charm help docs:
>
> The new charm's URL and revision are inferred as they would be when
> running a
> deploy command.
> Please note that --switch is dangerous, because juju only has limited
> information with which to determine compatibility; the operation will
> succeed,
> regardless of potential havoc.
>
> What is the use case for this functionality? I seemed to get the
> impression it
> was used mainly with local repos? But given local repos are going away in
> 2.0,
> do we still need it? And given the potential for users getting things
> wrong, do
> we even want to keep it regardless? Note also --switch is not allowed with
> --path which is how local charms are upgraded.
>
> What would folks lose if --switch were to be dropped for 2.0? Any
> objections to
> doing this?
>
>
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

[Rick Harding]

Thanks Ian, after thinking about it I think what we want to do is really
#2. The reasoning I think is:

1) we want to make things consistent. The CLI experience is present a charm
and override series with --series=
2) more consistent, if you do it with local charms you can always do it
3) we want to encourage folks to drop series from the charmstore urls and
worry less about series over time. Just deploy X and let the charm author
pick the default best series. I think we should encourage this in the error
message for #2. "Please remove the series section of the charm url" or the
like when we error on the conflict, pushing users to use the series
override.

Uros, Francesco, this brings up a point that I think for multi-series
charms we want the deploy cli snippets to start to drop the series part of
the url as often as we can. If the url doesn't have the series specified,
e.g. jujucharms.com/mysql then the cli command should not either. Right now
I know we add the series/revision info and such. Over time we want to try
to get to as simple a command as possible.

On Thu, Mar 10, 2016 at 7:23 AM Ian Booth <ian.bo...@canonical.com> wrote:

> I've implemented option 1:
>
>  error if Series attribute is used at all with a store charm URL
>
> Trivial to change if needed.
>
> On 10/03/16 12:58, Ian Booth wrote:
> > Yeah, agreed having 2 ways to specify store series can be suboptimal.
> > So we have 2 choices:
> >
> > 1. error if Series attribute is used at all with a store charm URL
> > 2. error if the Series attribute is used and conflicts
> >
> > Case 1
> > --
> >
> > Errors:
> >
> > Series: trusty
> > Charm: cs:mysql
> >
> > Series: trusty
> > Charm: cs:trusty/mysql
> >
> > Ok:
> >
> > Series: trusty
> > Charm: ./mysql
> >
> >
> > Case 2
> > --
> >
> > Ok:
> >
> > Series: trusty
> > Charm: cs:mysql
> >
> > Series: trusty
> > Charm: cs:trusty/mysql
> >
> > Series: trusty
> > Charm: ./mysql
> >
> > Errors:
> >
> > Series: xenial
> > Charm: cs:trusty/mysql
> >
> >
> > On 10/03/16 12:51, Rick Harding wrote:
> >> Bah maybe you're right. I want to sleep on it. It's kind of ugh either
> way.
> >>
> >> On Wed, Mar 9, 2016, 9:50 PM Rick Harding <rick.hard...@canonical.com>
> >> wrote:
> >>
> >>> I think there's already rules for charmstore charms. it uses the
> default
> >>> if not specified. I totally agree that for local charms we have to have
> >>> this. For remote charms though this is providing the user two ways to
> do
> >>> the same thing
> >>>
> >>> On Wed, Mar 9, 2016, 9:46 PM Ian Booth <ian.bo...@canonical.com>
> wrote:
> >>>
> >>>> If the charm store charm defines a series in the URL, then we will
> >>>> consider it
> >>>> an error to specify a different series using the attribute. But charm
> >>>> store URLs
> >>>> are not required to have a series, so we can use the attribute in that
> >>>> case. It
> >>>> also allows users to easily switch between store and local charms
> during
> >>>> development just by replacing "./" with "cs:"
> >>>>
> >>>>  nova-compute:
> >>>>series: xenial
> >>>>charm: ./nova-compute
> >>>>
> >>>>  nova-compute:
> >>>>series: xenial
> >>>>charm: cs:nova-compute
> >>>>
> >>>>
> >>>> On 10/03/16 12:21, Rick Harding wrote:
> >>>>> I'm not sure we want to make this attribute apply to charmstore
> charms.
> >>>>> We've an established practice of the charmstore url being the series
> >>>>> information. It gives the user a chance to have conflicting
> information
> >>>> if
> >>>>> the charmstore url is cs:trusty/nova-compute and the series
> attribute is
> >>>>> set to xenial. I think we should toss an error to a bundle that has
> >>>> series:
> >>>>> specified for a charmstore based charm value (or non-local value
> >>>> whichever
> >>>>> way you want to think about it)
> >>>>>
> >>>>> On Wed, Mar 9, 2016 at 6:29 PM Ian Booth <ian.bo...@canonical.com>
> >>>> wrote:
> >>>>>
> >>>>>> One additional enhancement we need

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

[Rick Harding]

I think there's already rules for charmstore charms. it uses the default if
not specified. I totally agree that for local charms we have to have this.
For remote charms though this is providing the user two ways to do the same
thing

On Wed, Mar 9, 2016, 9:46 PM Ian Booth <ian.bo...@canonical.com> wrote:

> If the charm store charm defines a series in the URL, then we will
> consider it
> an error to specify a different series using the attribute. But charm
> store URLs
> are not required to have a series, so we can use the attribute in that
> case. It
> also allows users to easily switch between store and local charms during
> development just by replacing "./" with "cs:"
>
>  nova-compute:
>series: xenial
>charm: ./nova-compute
>
>  nova-compute:
>series: xenial
>charm: cs:nova-compute
>
>
> On 10/03/16 12:21, Rick Harding wrote:
> > I'm not sure we want to make this attribute apply to charmstore charms.
> > We've an established practice of the charmstore url being the series
> > information. It gives the user a chance to have conflicting information
> if
> > the charmstore url is cs:trusty/nova-compute and the series attribute is
> > set to xenial. I think we should toss an error to a bundle that has
> series:
> > specified for a charmstore based charm value (or non-local value
> whichever
> > way you want to think about it)
> >
> > On Wed, Mar 9, 2016 at 6:29 PM Ian Booth <ian.bo...@canonical.com>
> wrote:
> >
> >> One additional enhancement we need for bundles concerns specifying
> series
> >> for
> >> multi-series charms, in particular local charms now that the local repo
> >> will be
> >> going away.
> >>
> >> Consider:
> >>
> >> A new multi-series charm may have a URL which does not specify the
> series.
> >> In
> >> that case, the series used will be the default specified in the charm
> >> metadata
> >> or the latest LTS. But we want to allow people to choose their own
> series
> >> also.
> >>
> >> So we need a new (optional) Series attribute in the bundle metadata.
> >>
> >> bundle.yaml
> >>   series: trusty
> >>   services:
> >> nova-compute:
> >>   series: xenial <-- new
> >>   charm: ./nova-compute
> >>   num_units: 2
> >>
> >> or with a charm store charm
> >>
> >> bundle.yaml
> >>   series: trusty
> >>   services:
> >> nova-compute:
> >>   series: xenial<-- new
> >>   charm: cs:nova-compute
> >>   num_units: 2
> >>
> >>
> >> Note: the global series in the bundle still applies if series is not
> >> otherwise
> >> known.
> >> The new series attribute is per charm.
> >>
> >> So in the case above, cs:nova-compute may ordinarily be deployed on
> trusty
> >> (the
> >> default series in that charm's metadata). But the bundle requires the
> >> xenial
> >> version. With the charm store URL, we can currently use
> >> cs:xenial/nova-compute
> >> but that's not the case for local charms deployed out of a directory. We
> >> need a
> >> way to allow the series to be specified in that latter case.
> >>
> >> We'll look to make the changes in core initially and can followup later
> >> with the
> >> GUI etc. The attribute is optional and only really affects bundles with
> >> local
> >> charms.
> >>
> >>
> >>
> >> On 09/03/16 09:53, Ian Booth wrote:
> >>> So to clarify what we'll do. We'll support the same syntax in bundle
> >> files as we
> >>> do for deploy.
> >>>
> >>> Deploys charm store charms:
> >>>
> >>> $ juju deploy cs:wordpress
> >>> $ juju deploy wordpress
> >>>
> >>> Deploys a local charm from a directory:
> >>>
> >>> $ juju deploy ./charms/wordpress
> >>> $ juju deploy ./wordpress
> >>>
> >>> So below deploys a local nova-compute charm in a directory co-located
> >> with the
> >>> bundle.yaml file.
> >>>
> >>>  series: trusty
> >>>  services:
> >>>nova-compute:
> >>>  charm: ./nova-compute
> >>>  num_units: 2
> >>>
> >>> This one deploys a charm store charm:
> >>>
> >>>  

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

[Rick Harding]

I'm not sure we want to make this attribute apply to charmstore charms.
We've an established practice of the charmstore url being the series
information. It gives the user a chance to have conflicting information if
the charmstore url is cs:trusty/nova-compute and the series attribute is
set to xenial. I think we should toss an error to a bundle that has series:
specified for a charmstore based charm value (or non-local value whichever
way you want to think about it)

On Wed, Mar 9, 2016 at 6:29 PM Ian Booth <ian.bo...@canonical.com> wrote:

> One additional enhancement we need for bundles concerns specifying series
> for
> multi-series charms, in particular local charms now that the local repo
> will be
> going away.
>
> Consider:
>
> A new multi-series charm may have a URL which does not specify the series.
> In
> that case, the series used will be the default specified in the charm
> metadata
> or the latest LTS. But we want to allow people to choose their own series
> also.
>
> So we need a new (optional) Series attribute in the bundle metadata.
>
> bundle.yaml
>   series: trusty
>   services:
> nova-compute:
>   series: xenial <-- new
>   charm: ./nova-compute
>   num_units: 2
>
> or with a charm store charm
>
> bundle.yaml
>   series: trusty
>   services:
> nova-compute:
>   series: xenial<-- new
>   charm: cs:nova-compute
>   num_units: 2
>
>
> Note: the global series in the bundle still applies if series is not
> otherwise
> known.
> The new series attribute is per charm.
>
> So in the case above, cs:nova-compute may ordinarily be deployed on trusty
> (the
> default series in that charm's metadata). But the bundle requires the
> xenial
> version. With the charm store URL, we can currently use
> cs:xenial/nova-compute
> but that's not the case for local charms deployed out of a directory. We
> need a
> way to allow the series to be specified in that latter case.
>
> We'll look to make the changes in core initially and can followup later
> with the
> GUI etc. The attribute is optional and only really affects bundles with
> local
> charms.
>
>
>
> On 09/03/16 09:53, Ian Booth wrote:
> > So to clarify what we'll do. We'll support the same syntax in bundle
> files as we
> > do for deploy.
> >
> > Deploys charm store charms:
> >
> > $ juju deploy cs:wordpress
> > $ juju deploy wordpress
> >
> > Deploys a local charm from a directory:
> >
> > $ juju deploy ./charms/wordpress
> > $ juju deploy ./wordpress
> >
> > So below deploys a local nova-compute charm in a directory co-located
> with the
> > bundle.yaml file.
> >
> >  series: trusty
> >  services:
> >nova-compute:
> >  charm: ./nova-compute
> >  num_units: 2
> >
> > This one deploys a charm store charm:
> >
> >  series: trusty
> >  services:
> >nova-compute:
> >charm: nova-compute
> >num_units: 2
> >
> >
> >
> > On 09/03/16 03:59, Rick Harding wrote:
> >> Long term we want to have a pattern when the bundle is a directory with
> >> local charms in a directory next to the bundles.yaml file. We could not
> do
> >> this cleanly before the multi-series charms that are just getting out
> the
> >> door. I think that bundles with local charms will be suboptimal until we
> >> can get those bits to line up.
> >>
> >> I don't think we want to be doing the file based urls, but to build a
> >> pattern that's reusable and makes sense across systems. Creating a
> standard
> >> pattern I think is the best path forward.
> >>
> >> On Tue, Mar 8, 2016 at 12:26 PM Martin Packman <
> martin.pack...@canonical.com>
> >> wrote:
> >>
> >>> On 05/03/2016, Ian Booth <ian.bo...@canonical.com> wrote:
> >>>>>
> >>>>> How will bundles work which reference local charms? Will this work as
> >>>>> expected where nova-compute is a directory at the same level as a
> bundle
> >>>>> file?
> >>>>>
> >>>>> ```
> >>>>> series: trusty
> >>>>> services:
> >>>>>   nova-compute:
> >>>>> charm: ./nova-compute
> >>>>> num_units: 2
> >>>>> ```
> >>>>>
> >>>>
> >>>> The above will work but not until a tweak is made to bundle
> deployment to
> >>>> interpret a path on disk rather than a url. It's

Re: Juju 2.0 and local charm deployment

[Rick Harding]

Long term we want to have a pattern when the bundle is a directory with
local charms in a directory next to the bundles.yaml file. We could not do
this cleanly before the multi-series charms that are just getting out the
door. I think that bundles with local charms will be suboptimal until we
can get those bits to line up.

I don't think we want to be doing the file based urls, but to build a
pattern that's reusable and makes sense across systems. Creating a standard
pattern I think is the best path forward.

On Tue, Mar 8, 2016 at 12:26 PM Martin Packman 
wrote:

> On 05/03/2016, Ian Booth  wrote:
> >>
> >> How will bundles work which reference local charms? Will this work as
> >> expected where nova-compute is a directory at the same level as a bundle
> >> file?
> >>
> >> ```
> >> series: trusty
> >> services:
> >>   nova-compute:
> >> charm: ./nova-compute
> >> num_units: 2
> >> ```
> >>
> >
> > The above will work but not until a tweak is made to bundle deployment to
> > interpret a path on disk rather than a url. It's a small change. This
> would
> > be done as part of the work to remove the local repo support.
>
> Can we keep interpreting the the reference in the bundle as a url, but
> start supporting file urls? That seems neater than treating the cs:
> prefix as magic not-a-filename.
>
> The catch is that there's no sane way of referencing locations outside
> a base url.
>
> charm: file:nova-compute
>
> Works as a reference to a dir inside the base location, but:
>
> charm: file:../nova-compute
>
> Will not work as a reference to a sibling directory. And absolute file
> paths are pretty useless across machines.
>
> Martin
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju 2.0 and local charm deployment

[Rick Harding]

No, right now charms can be multiple series but must be of the same OS. If
there is truly portable code they can be wrapped as Layers to be shared
among the charms, but in practice, it turns into to much ifdef style
development that's difficult to debug and things like resources that are
vastly different from OS to OS. In the case of those OS's we expect the
charms to use naming to help distinguish.

mysql
mysql-windows
mysql-centos

Rick

On Fri, Mar 4, 2016 at 7:24 AM Vasiliy Tolstov  wrote:

> 2016-03-04 8:55 GMT+03:00 Ian Booth :
> > Hopefully everyone is aware that Juju 2.0 and the charm store will
> support
> > multi-series charms. To recap, a multi-series charm is one which can
> declare
> > that it supports more than just the one series; you no longer need to
> have a
> > separate copy of the charm for precise vs trusty vs xenial. Note that
> all series
> > must be for the same OS so you'll still need separate charm sources for
> Windows
> > vs Ubuntu vs Centos.
>
>
> Thanks, but do you have plans to support multi os charms ?
>
> --
> Vasiliy Tolstov,
> e-mail: v.tols...@selfip.ru
>
> --
> 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: admin is dead, long live $USER

[Rick Harding]

If we do that we need to also make it configurable on bootstrap as an
option.

+1 overall

On Thu, Mar 3, 2016, 4:07 PM Tim Penhey  wrote:

> Hi folks,
>
> I was thinking that with the upcoming big changes with 2.0, we should
> tackle a long held issue where we have the initial user called "admin".
>
> There was a request some time back that we should use the current user's
> name. The reason it wasn't implemented at that time was due to logging
> into the GUI issues. These have been resolved some time back with the
> multiple user support that was added.
>
> All the server side code handles the ability to define the initial user
> for the controller model, and we do this in all the tests, so the
> default test user is actually called "test-admin".
>
> I *think* that all we need to do is change the default value we use in
> the bootstrap command for the AdminUserName (--admin-user flag) from
> "admin" to something we derive from the current user.
>
> Probably worth doing now.
>
> Thoughts?
>
> Tim
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Units & resources: are units homogeneous?

[Rick Harding]

I wanted to add that the reason we're curious about this is because we're
working on how Juju can help provide insights into things that could be
off/wrong between units. If we expect the units to be the same, then things
like warning users that a unit hasn't yet gotten a resource that the others
have seems like a good idea. However, if you're expecting different units
to appear differently, then it's like having an error dialog always be
there that you end up ignoring because that's the way it's meant to be.

It influences the design of how Juju thinks about the resources across the
units if we're expecting them to look the same or not. There have been
discussions of how unit entropy is something to try to work on cutting out
of the system. If I add-unit, it should be the same code at the same
revision as the one I started previously, even if it's been months since I
deployed that unit.

The landscape example is interesting, but I can't help but feel like that
it's abusing the system a bit. The end user doesn't really know what's
running where if it's a self-adapting system based on the number of units.
It's really interesting because I guess the end user just wants to know
they've got landscape running and working properly, but the tech person in
me is a bit scared that it's not clear what services I'm running where
setup and exposed in what ways.

On Tue, Feb 16, 2016 at 1:20 PM Katherine Cox-Buday <
katherine.cox-bu...@canonical.com> wrote:

> Hey All,
>
> The team is looking closely at some of our CLI surrounding resources, and
> an interesting question came up: should units be considered homogeneous?
>
> My understanding is that it's a goal to make the management of units more
> consistent, and making the units more homogeneous would support this, but
> I'm wondering from a workload perspective if this is also true? One example
> I could think of to support the discussion is a unit being elected leader
> and thus taking a different path through it's workflow than the other
> units. When it comes to resources, maybe this means it pulls a different
> sub-set of the declared resources, or maybe doesn't pull resources at all
> (e.g. it's coordinating the rest of the units or something).
>
> I'm curious what people are seeing out in the field, and hearing opinions
> too.
>
> Thanks :)
>
>
> -
> Katherine
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Ubuntu in GSOC

[Rick Harding]

I just want to say that I ran GSoC for my side open source project a couple
of years ago and it was really awesome. I worked to setup standup meetings,
a kanban board, and did things like code reviews and such. So this is
something, that if folks are interested, can be really useful as far as
mentoring someone on the great practices we use here today.

Let me know if you're curious about the experience.

Rick

On Tue, Feb 16, 2016 at 12:09 PM José Antonio Rey  wrote:

> Hello everyone!
>
> I just wanted to let you know that we as Ubuntu are planning on running
> as an organization for Google Summer of Code. This is a program where
> university students from all around the world help with open source
> organizations.
>
> However, for this to happen, we need to have mentors on board. These are
> one-to-one mentors that will help the student develop its project during
> the US summer.
>
> If you have an idea of something that you'd like to see in Juju or Juju
> Core, and would like to become a mentor, I encourage you to list it
> here: https://wiki.ubuntu.com/GoogleSoC2016/Ideas
>
> The deadline for listing ideas is in two days (registration finishes on
> Fri) so please make sure to get yours in asap!
>
> If you have any questions about the program, feel free to email me.
>
> --
> José Antonio Rey
>
> --
> Juju mailing list
> j...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Introducing, juju resources!

[Rick Harding]

On Sun, Feb 14, 2016 at 12:50 PM Aaron Bentley 
wrote:

> Another use case is when you want to create a charm deploys Python
> code.  You want it to use "resources" instead of downloading
> dependencies from PyPI.
>
> 1. The list of resources can change over time.  You don't want the
> charm to have to change every time the deployed software adds/removes
> a dependency.
>
> 2. The version numbers are embedded in the filenames.  You don't want
> the charm to have to change ever time deployed software changes its
> version numbers.
>
> Yes, you can work around this with tarfiles, but why do we want to?
> It's a pain to build a tar file every time a single dependency
> changes.  It's easier to use S3 instead for a particular use case, but
> it doesn't solve the general case.
>

I'd push back a little bit here though. We do this in a couple of python
web applications. We keep a repo of 'download-cache' which is the current
pypi .tar.gz and use that built into a single download-cache tarball for
deliver in the charms. This would be one resource. The second resource
would then be the actual python application. It would have the makefile,
requirements.txt file, source code, etc. It would depend on the
download-cache file being there and so with the two, you'd manage both the
source code and the dependencies as two different resource files that are
all updated individually from the actual charm itself.

So if a dependency is updated you can just update the source/download cache
resources and not the charm. If the source code is updated and no deps are
updated you just update the source code.

Again, there's room to improve the idea for the 'many resources' ideas, but
the current work moves things forward into a nice direction reducing the
need for fat charms and allowing some flexibility.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Introducing, juju resources!

[Rick Harding]

On Fri, Feb 12, 2016 at 11:06 PM Aaron Bentley 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 2016-02-12 04:26 PM, Katherine Cox-Buday wrote:
> > Moonstone have been working hard on a new feature coming up in Juju
> > 2.0 called "Juju Resources", and we're now at a point where we can
> > share the goodness and call for bugs/feedback!
>
> I'm glad to see you folks are working on this. On the QA side, we've
> been wanting Juju to support some kind of native blob storage,
> basically since we started.
>
> Is is necessary to enumerate the names in the charm? I'd rather we
> didn't. One of our use cases is plugins for Jenkins. The Jenkins charm
> has has a setting that tells it which plugins to install, but there's
> no predetermined list. It would be nice if the plugins could be
> retrieved in a Juju-native way, but it would be painful to have to
> update the charm every time we added a new plugin.  And it would be
> bad if people ended up forking the charm just to adjust the list of
> plugins.
>
> We could bundle the plugins in a single tarfile, but then updating the
> tarfile would be annoying. For plugins, it's best if each plugin is
> its own file and there are no restrictions on the filenames.


Your read is correct. You must declare the resources. It's helpful to users
to know what to stick in there and for the charm to be able to handle
different items. In your case, a single tar file of the plugins you'd like
to enable could be sent up and the charm would be able to untar, loop
through them, etc. Ideally the charm would be uploaded to the store with a
standard set of plugins and folks could then customize which ones they
wanted by creating their own tar of plugins.

I'll make sure we keep this in mind though. We've started with one file per
resource, and maybe there's an idea here of "one or more" where you might
have a charm that takes a data set file. You can deploy with a data set, or
multiple files of data that all need to be processed, rather than building
into a single file. We'll have to think it through for a future iteration
of resources.

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

Re: Defaulting tests internal to the package

[Rick Harding]

I've got to toss another +1 for tests at both levels. One set of tests are
tests against your contract to outsiders. Another is confidence that your
internals are resilient. There are a ton of cases I can think of such as
internal code that validates changes in state, validates various forms of
input, deals with internal changes to document structure over time.
Ideally, when an external contract test fails, one of the internal ones
just blew up to point directly at the culprit within all your internal
code.

Yes, it can mean that internal tests need to be kept up to date more as the
internals change, but even then tests provide another layer of "did you
cover all these cases in your refactoring".

On Sun, Jan 24, 2016 at 4:47 PM Tim Penhey  wrote:

> I'm going to throw my cool-blue paint against the bike shed.
>
> I disagree that we should change the default expectations of package tests.
>
> By default, package tests should be external tests, small and fast, not
> full stack, and parameterize from above rather than patch.
>
> However, I also see much value in internal unit tests for exactly the
> same reason as Nate and Roger. It gives me confidence in my
> implementation. These tests have nothing to do really with the exposed
> interface of the package, but with the current implementation.
>
> This whole issue is close to my heart right now as I deal with model
> migrations. Many of the tests I am writing are internal tests.
>
> Tim
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Automatic retries of hooks

[Rick Harding]

+1 retries are great, with backoff, when you know you're doing it because
you have experience that certain api requests to clouds, or to other known
failure points.

Blindly just saying "if at first you don't succeed, go go go" isn't a
better UX. It adds another layer of complexity in debugging, and doesn't
really improve the product. Only the charm author knows enough about what
it's trying to achieve to do intelligent retry.

In this case, if there's something about unexpected reboots of machines,
perhaps there's some specific case that Juju can grow some intelligence and
hint at the charm author what happened. The charm can then react to that
information as it deems necessary.

On Wed, Jan 20, 2016 at 8:42 AM Dean Henrichsmeyer 
wrote:

> Hi,
>
> It seems the original point James was making is getting missed. No one is
> arguing over the value of being able to retry and/or idempotent hooks.
> Yes, you should be able to retry them and yes nothing should break if you
> run them over and over.
>
> The point made is that Juju shouldn't be automatically retrying them. The
> argument of "no one knows what went wrong so Juju automatically retrying
> them is a better experience" doesn't work. The intelligence of the stack in
> question, regardless of what it is, goes in the charms. If you start
> conflating and mixing up where the intelligence goes then creating,
> running, and debugging those distributed systems will be a nightmare.
>
> The magic should only be in Juju's ability to effectively drive the models
> and intelligence encoded in the charms. It shouldn't make assumptions about
> what that intelligence is or what those models require.
>
> Thanks.
>
>
> -Dean
> --
> 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: "environment" vs "model" in the code

[Rick Harding]

No, there's not been a public note yet. It's work going into the 2.0
updates currently.

The gist of the reason is that as support for things such as networking,
storage, and workloads expand out the idea is that Juju is doing more to
model your infrastructure and workloads vs an environment. So far it's
helped one of the issue that Juju has had in that it takes time to explain
what it's actually doing before folks 'get it'. Starting from the point of
'take what you have running and let Juju model it' seems to be clicking
with new folks more.

On Mon, Jan 18, 2016 at 9:15 AM Kapil Thangavelu  wrote:

> out of curiosity is there any public explanation on the reason for the
> change? environments map fairly naturally to various service topology
> stages, ie my prod, qa, dev environments. while model is a rather opaque
> term that doesn't convey much.
>
> On Thu, Jan 14, 2016 at 7:16 PM, Menno Smits 
> wrote:
>
>> Hi all,
>>
>> We've committed to renaming "environment" to "model" in Juju's CLI and
>> API but what do we want to do in Juju's internals? I'm currently adding
>> significant new model/environment related functionality to the state
>> package which includes adding new database collections, structs and
>> functions which could include either "env/environment" or "model" in their
>> names.
>>
>> One approach could be that we only use the word "model" at the edges -
>> the CLI, API and GUI - and continue to use "environment" internally. That
>> way the naming of environment related things in most of Juju's code and
>> database stays consistent.
>>
>> Another approach is to use "model" for new work[1] with a hope that it'll
>> eventually become the dominant name for the concept. This will however
>> result in a long period of widespread inconsistency, and it's unlikely that
>> things we'll ever completely get rid of all uses of "environment".
>>
>> I think we need arrive at some sort of consensus on the way to tackle
>> this. FWIW, I prefer the former approach. Having good, consistent names for
>> things is important[2].
>>
>> Thoughts?
>>
>> - Menno
>>
>> [1] - but what defines "new" and what do we do when making significant
>> changes to existing code?
>> [2] - http://martinfowler.com/bliki/TwoHardThings.html
>>
>> --
>> 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: Comprehensive reviews & when to do them?

[Rick Harding]

I think this is a bit of a difference in code review and feature QA. Doing
something big at the end misses all the knowledge share, keeps things in
silos for longer lengths of time without understanding the history, etc.
Hey, maybe someone sees an obvious way to suggest doing those
shortcuts/stubs!

However, I do think there's room for folks to really help validate the
feature branch is a complete solid feature before getting rubber stamped.
I'd think of this more as a feature review/QA though vs expecting anyone to
do a big code review of an entire feature branch to master.

On Mon, Dec 14, 2015 at 10:39 AM Katherine Cox-Buday <
katherine.cox-bu...@canonical.com> wrote:

> Hey All,
>
> I think we have a mis-alignment in how we currently do reviews and
> feature branches.
>
> We've switched over to feature-branches which is great and has allowed
> Moonstone to land "good enough" code into our feature branch to support
> a bi-weekly demo and solicit feedback. At the same time, I feel like
> we're wasting people's time asking for a +1 on code that is not intended
> to be landed into master. Often this code will take shortcuts or stub
> out some code, and as the lead I'll make a judgment call to circle-back
> later. Reviewers don't necessarily know this.
>
> Conversely, when we go to land the feature branch into master, these PRs
> are generally rubber-stamped.
>
> I feel like maybe we have this backwards?
>
> -
> Katherine
>
> --
> 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 devel 1.26-alpha2 is available for testing

[Rick Harding]

On Fri, Nov 27, 2015 at 11:35 AM Mark Shuttleworth  wrote:

> On 27/11/15 16:21, Aaron Bentley wrote:
>
> It's dependent on what compiler was used to create the jujud binary.
> AIUI, the Ubuntu policy is that nothing goes into a distroseries which
> cannot be compiled with the tools in that distroseries.  Thus the
> jujud for Trusty is compiled with the version of Go provided by that
> platform.
>
>
> My understanding is that a Go 1.5 backport to Trusty is part of the
> current cycle planned work.
>

Yes, the work for Go 1.5 into Trusty moves forward. For this alpha it's not
yet ready to provide the build so my understanding is that the alpha build
for Trusty is done with the current outdated tool chain. Once the Go
toolchain is updated for Trusty the builds released will be in order.

Aaron, please correct me if I'm mistaken there.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Feature Request: -about-to-depart hook

[Rick Harding]

Thanks for the feedback. I think this is something we should try to make
some time for. I've copied Alexis and we'll see what can be done with the
team.

Alexis, can you put this on the list of things to investigate for future
roadmap?

Thanks

On Tue, Nov 10, 2015 at 8:22 AM Mario Splivalo 
wrote:

> On 02/12/2015 07:41 PM, Jorge Niedbalski wrote:
> >> While typing up https://bugs.launchpad.net/juju-core/+bug/1417874 I
> >> realized that your proposed solution of a pre-departure hook is the
> >> only one that can work. Once -departed hooks start firing both the
> >> doomed unit and the leader have already lost the access needed to
> >> decommission the departing node.
> >
> > I have been struggling the last hours with the same exact issue trying
> > to add replication to memcached.
> >
> > The problem is that there is no a point on which i can identify
> > what's the exact departing unit?
> >
> > And this leads to manual operator intervention, which is _highly_ non
> > desirable for a juju deployed environment.
> >
> > +1 for having this feature implemented.
>
> Hola!
>
> I'm bumping this thread to get some chatter going on - we hit a similar
> issue with percona-cluster charm, which is reported in this bug:
>
> https://bugs.launchpad.net/charms/+source/percona-cluster/+bug/1514472
>
> The issue is somewhat similar as to those with mongodb - when unit is
> leaving relation (issued by 'juju remove-unit'), charm should first shut
> down percona server on the departing unit. Failing to do results in
> 'lost quorum' situation where remaining node thinks that network has
> partitioned. Unfortunately there is now way for a relation's -departed
> hook to know if it's executing on departing unit or on the other one so
> it can't know weather or not to stop percona server. Implementing a
> -about-to-depart hook would solve this issue.
>
> Mario
>
>
> --
> 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: Feature Request: -about-to-depart hook

[Rick Harding]

Thank you Cheryl!

On Mon, Nov 23, 2015, 6:33 PM Cheryl Jennings <cheryl.jenni...@canonical.com>
wrote:

> This is already on my list.  I'm still figuring out a good way to organize
> / record these in a publicly viewable place.
>
> I'll send out a link once I get something together.  (Hopefully tonight!)
>
> Thanks!
>
>
> -Cheryl
> On Nov 23, 2015 5:20 PM, "Rick Harding" <rick.hard...@canonical.com>
> wrote:
>
>> Thanks for the feedback. I think this is something we should try to make
>> some time for. I've copied Alexis and we'll see what can be done with the
>> team.
>>
>> Alexis, can you put this on the list of things to investigate for future
>> roadmap?
>>
>> Thanks
>>
>> On Tue, Nov 10, 2015 at 8:22 AM Mario Splivalo <
>> mario.spliv...@canonical.com> wrote:
>>
>>> On 02/12/2015 07:41 PM, Jorge Niedbalski wrote:
>>> >> While typing up https://bugs.launchpad.net/juju-core/+bug/1417874 I
>>> >> realized that your proposed solution of a pre-departure hook is the
>>> >> only one that can work. Once -departed hooks start firing both the
>>> >> doomed unit and the leader have already lost the access needed to
>>> >> decommission the departing node.
>>> >
>>> > I have been struggling the last hours with the same exact issue trying
>>> > to add replication to memcached.
>>> >
>>> > The problem is that there is no a point on which i can identify
>>> > what's the exact departing unit?
>>> >
>>> > And this leads to manual operator intervention, which is _highly_ non
>>> > desirable for a juju deployed environment.
>>> >
>>> > +1 for having this feature implemented.
>>>
>>> Hola!
>>>
>>> I'm bumping this thread to get some chatter going on - we hit a similar
>>> issue with percona-cluster charm, which is reported in this bug:
>>>
>>> https://bugs.launchpad.net/charms/+source/percona-cluster/+bug/1514472
>>>
>>> The issue is somewhat similar as to those with mongodb - when unit is
>>> leaving relation (issued by 'juju remove-unit'), charm should first shut
>>> down percona server on the departing unit. Failing to do results in
>>> 'lost quorum' situation where remaining node thinks that network has
>>> partitioned. Unfortunately there is now way for a relation's -departed
>>> hook to know if it's executing on departing unit or on the other one so
>>> it can't know weather or not to stop percona server. Implementing a
>>> -about-to-depart hook would solve this issue.
>>>
>>> Mario
>>>
>>>
>>> --
>>> 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 and monitoring systems

[Rick Harding]

Awesome to hear you're enjoying Juju Vasiliy. We don't currently have plans
to build monitoring directly into Juju. We've found most places have their
preferred tool for that, zabbix, munin, nagios, etc. We love that folks
have built charms that allow integration of their preferred tool through
charms that are typically used as subordinate services. It looks
like prometheus would be another service along those lines that would be
great to charm for use.

Rick



On Fri, Nov 13, 2015 at 3:39 AM Vasiliy Tolstov  wrote:

> I like juju (and already use it to provide predefined vps with
> wordpress etc) and i like prometheus monitoring system.
> Does juju devs have any plans to export metrics to prometheus? Or
> somebody who use juju and prometheus?
> Also does juju running on machines or on the state server have ability
> (internally collect) to get performance metrics like: cpu, memory
> utilization, disk space etc ?
> This brings ability to easy add/remove units.
>
> --
> Vasiliy Tolstov,
> e-mail: v.tols...@selfip.ru
>
> --
> 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: Renaming of environments

[Rick Harding]

That's interesting Andrew and not something considered in the conversations
around this so far. With the new Azure provider and resource groups is the
name of that group mutable? For Azure at least the resource groupings
should help with the tags/identification though it does complicate things
for the other providers. Are the tags typically not able to be updated?
Maybe we can provide some help to the user to map uuid to the names with
something like a juju show environment $uuid? and get name and some other
info back?



On Fri, Oct 23, 2015 at 6:33 AM Andrew Wilkins 
wrote:

> On Fri, Oct 23, 2015 at 3:32 PM John Meinel 
> wrote:
>
>> We can put the environment name in a field that is visible, but isn't
>> canonical. It depends on the specific use case, but if we can use tags, we
>> can use "juju-environment-uuid" or some tag like that as the official "what
>> environment is this in", and then "name" is just a local value, which can
>> be changed as it isn't a critical piece.
>>
>
> It won't be quite as clear, but I suppose it's a fair price to pay. It
> would be good if we updated tags for things that change, like this.
>
> I'm doing the new Azure provider now, I've updated it so resource names do
> not include the environment name.
>
> Cheers,
> Andrew
>
>
>> John
>> =:->
>>
>>
>> On Fri, Oct 23, 2015 at 9:19 AM, Andrew Wilkins <
>> andrew.wilk...@canonical.com> wrote:
>>
>>> On Fri, Oct 23, 2015 at 1:00 PM Menno Smits 
>>> wrote:
>>>
 While working on the environment migrations spec I noticed that it is
 currently not possible to change the name of a Juju environment once it has
 been created. This creates an unfortunate corner case in the context of
 environment migrations, where you might have an environment that can't be
 migrated to another controller because you've already created another
 (unrelated) environment with the same name on the target controller.

 Rick pointed out that it would also be nice to be able to rename an
 environment when its purpose has changed. For example, you might have
 created an environment called "test" which you build up and end up using
 for production purposes. At that point the environment name doesn't make
 much sense.

 We will fix this. The rename itself is fairly easy to implement but
 environment names have also been used as part of things such as EC2 and
 Openstack security group names so this will need to change too. It would be
 better if the names of external environment-related resources used the
 environment UUID instead. There is a card for this work in Onyx's backlog.

>>>
>>> It was specifically requested that we include the environment name in
>>> resource names for debugging purposes (e.g. I'm looking at the AWS console
>>> and want to know which Juju machine this instance corresponds to). Some of
>>> this was done in 1.25, some was pre-existing.
>>>
>>> These requirements are at odds with each other. Just wondering if this
>>> has been considered.
>>>
>>> Cheers,
>>> Andrew
>>>
>>> --
>>> 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 min version feature

[Rick Harding]

Then we should take up the burden to help others realize that their code
will work with older versions of juju. Perhaps I am assuming, but if I am a
charm author and I am wondering what my minimum version of juju is I will
select the one I am currently using. Running tests and older versions are
not something I'm going to do want to take up the burden on. This means
that users of juju will have a smaller set of charms available to them
because of this declaration even though it may actually work.

Rick
On Dec 15, 2014 11:51 AM, Nate Finch nate.fi...@canonical.com wrote:

 OK, so, many people in juju-core have talked about this with Eco, and we
 came to the conclusion that per-feature flags would be way too confusing
 for the charm consumer.  When I want to deploy a charm, I don't wnat to
 have to figure out what version of juju supports leader election so I can
 know if the charm I want is supported by my version of juju.  I just want
 to see a min version and compare it to my version of juju.

 This does put a little more burden on charm authors, to do that
 translation themselves, but they would need to be able to do that anyway to
 understand what versions of juju support their charm.  This way we at least
 take that burden off the person deploying the charm.

 Also, we very specifically only support min version.  This just means
 we'll need to be backwards compatible. There won't be leader election 2.0
 that makes 1.0 not work.

 On Mon, Dec 15, 2014 at 11:47 AM, Nate Finch nate.fi...@canonical.com
 wrote:

 last copy of context to juju-dev

 On Mon, Dec 15, 2014 at 10:17 AM, Adam Collard 
 adam.coll...@canonical.com wrote:

 On 15 December 2014 at 15:06, Marco Ceppi marco.ce...@canonical.com
 wrote:

 I'm against this idea, what if something changes in the implementation
 of leader_election? Now there's a requirement to track version of features
 released and complexity grows.


 Well if that were to happen, the charm author would have to know which
 version of Juju they need anyway? In fact the version based tracking of
 this makes it even worse, let's for the sake of argument assume that leader
 election 1.0 comes in Juju 1.22.0 and leader election 2.0 comes in Juju
 1.24.0. If the charm is using the 1.0 model they have to say I require
 Juju = 1.22.0  and  Juju 1.24.0. In the capability model they simply
 state I require a Juju capable of leader_election_2 (or some other better
 token that describes the change in a semantic way).

 I think the capabilities based model can easily extend into a provider
 based constraint as well. So the charm can say I require container
 addressing and MAAS Provider will be fine but everything else will fail as
 per the current spec. Using a capabilities model is more expressive and can
 be extended. Using version numbers is clunky.


 It seems much easier (testing and comprehension-wise) to have the
 author say Won't work unless you have this version of Juju or higher.
 This makes testing, linting, and other typical charm author actions simpler
 while yielding virtually the same result.


 I don't think manually mapping features to Juju versions is simple for
 anyone now, let alone the expanded base of charm authors that we're
 targetting.


 As for your use case of bugs in juju break user experience is an
 already existent risk and can be improved in other ways that I think are
 outside the scope of this.


 Agreed.


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