Re: Unable to kill-controller

[Andrew Wilkins]

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  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 
>> 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: Juju Storage

[Andrew Wilkins]

On Tue, Apr 5, 2016 at 10:03 PM Bruno Ranieri  wrote:

> Hi,
>

Hi Bruno,

I am working on charms for the Quobyte Storage System. These charms make
> use of the Juju Storage support,
> but unfortunately juju storage does not behave as expected:
>
> In my charms block-type storage is defined (metadata.yaml):
>
>> [...]
>> storage:
>>   registry-storage:
>> type: block
>> description: registry storage
>> minimum-size: 10G
>> multiple:
>>   range: '1'
>>
>
> When I deploy this charm to ec2 I assume that juju will create an
> ebs-volume [1].
> What it does instead is creating a loop-device?
>

The command line arguments for storage a little bit (too?) subtle. If you
don't specify any constraints for a store, then you'll get "loop" for
block-type, and "rootfs" for filesystem-type stores.

If you want to get the provider's default, you need to specify at least one
constraint for the store. For example, say you want an EBS volume of 10G.
You would deploy with "--storage registry-storage=10G". For the ec2
provider, this will allocate an EBS volume of 10GiB.

After 'juju switch amazon' and 'juju bootstrap' [2] my storage pool is
> initialized to
>
>> ubuntu@bruno:~$ juju storage pool list
>> ebs-ssd:
>>   provider: ebs
>>   attrs:
>> volume-type: ssd
>>
>
>
> When deploying this charm
>
>> ubuntu@bruno:~$ juju deploy --repository=. local:quobyte-registry
>> Added charm "local:trusty/quobyte-registry-1" to the environment.
>
>
Try one of the following:
(1) juju deploy --repository=. local:quobyte-registry --storage
registry-storage=10G
(2) juju deploy --repository=. local:quobyte-registry --storage
registry-storage=ebs
(3) juju deploy --repository=. local:quobyte-registry --storage
registry-storage=ebs-ssd

(1) will allocate the provider's native volume type (if the provider has
one; otherwise loop), of at least 10GiB
(2) will allocate an EBS magnetic volume with the store's minimum size
(3) will allocate an EBS SSD volume with the store's minimum size


> already the agent deployment fails with:
>
>> $ juju debug-log --replay
>> [...]
>> machine-1[14401]: 2016-04-05 12:06:01 ERROR juju.worker runner.go:223
>> exited "deployer": cannot create agent
>> config dir "/var/lib/juju/agents/unit-quobyte-registry-0": mkdir
>> /var/lib/juju/agents/unit-quobyte-registry-0: no space left on device
>>
>
> Debugging into the deployed machine (and ec2-console) shows that no
> ebs-volume was created but an image on the local disk:
>
>> $ juju ssh 1
>> ubuntu@ip-x.y.z.a:~$ df -h
>> Filesystem  Size  Used Avail Use% Mounted on
>> udev1.9G   12K  1.9G   1% /dev
>> tmpfs   375M  204K  375M   1% /run
>> /dev/disk/by-label/cloudimg-rootfs  7.8G  7.8G 0 100% /
>> none4.0K 0  4.0K   0% /sys/fs/cgroup
>> none5.0M 0  5.0M   0% /run/lock
>> none1.9G 0  1.9G   0% /run/shm
>> none100M 0  100M   0% /run/user
>> /dev/xvdb   3.9G  8.1M  3.7G   1% /mnt
>>
>
>
> I'm aware that it is possible to control the storage usage during
> service-deploment on the command-line
> using '--storage registry-storage=ebs', but I do not think that this is
> the correct solution? Currently I am working on tests
> for the 'juju test' -runner. There I cannot hard-wire storage to ebs,
> since these tests should be independent form a specific provider.
>

Right, so as above, you'll just need to specify the size and let Juju take
care of determining the appropriate storage provider.

Let us know how you get on.

Cheers,
Andrew

Any ideas what is possible wrong I my setup?
>
> Thanks and Regards,
>  Bruno Ranieri
>
>
> [1] 'If pool is not specified, then Juju will select the default storage
> provider for the current environment
>   (e.g. cinder for openstack, ebs for ec2, loop for local)'
> https://jujucharms.com/docs/1.25/storage
>
> [2] $ cat ~/.juju/environments.yaml
>
>> default: local
>> environments:
>>   local:
>> type: local
>> admin-secret: xyz
>> lxc-clone: true
>> allow-lxc-loop-mounts: true
>> default-series: trusty
>>
>>   amazon:
>>type: ec2
>>region: eu-central-1
>>access-key: xyz
>>secret-key: xyz
>>admin-secret: xyz
>>default-series: trusty
>>
>>
>
> --
> Quobyte GmbH
> Hardenbergplatz 2 - 10623 Berlin - Germany
> +49-30-814 591 800 - www.quobyte.com
> Amtsgericht Berlin-Charlottenburg, HRB 149012B
> management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Action return value too long for commandline

[Merlijn Sebrechts]

Hi Mark


What's your opinion to adding outflowing and peer-flowing capabilities to
resources? Outflowing: from charm to operator, peer-flowing: from charm to
charm. I'm not sure if there is such a big conceptual difference between
inflowing, outflowing and peer-flowing. I have the tendency to see an
operator as just another Charm. This might become reality when the "stacks"
functionality gets introduced because then there will be a charm-like
entity that manages a bunch of charms... This might make that transition
easier...



Kind regards
Merlijn

2016-04-05 2:42 GMT-07:00 Mark Shuttleworth :

>
> We should definitely have a mechanism for large-file output from actions
> and other hooks. I think resources are "inward flowing", they come from the
> charmer or they are provided by the operator. You're looking for "outward
> flowing" blobs.
>
> As I recall, the intention was that actions could drop results into the
> controller in a way that was friendly to large BLOB results. That's why we
> have an async action output and result mechanism. I reckon it would be fine
> to use resources for input to actions (there would just be a specific
> user-provided resource name and there would be only one version of that at
> any given time), but we want to make sure that output can also be
> efficiently handled regardless of size, so if we need to improve that,
> let's crack on.
>
> Mark
>
>
> On 04/04/16 16:56, Merlijn Sebrechts wrote:
>
> Hi Stuart
>
>
> Thanks for this explanation. 16MB is definitely a step in the right
> direction. However, in the future I'll need to transfer even bigger files.
> Is there a possibility for using resources for this in the future? It would
> be great if an action could upload a file to the resources server so the
> admin can download it from there.
>
>
>
> Kind regards
> Merlijn Sebrechts
>
> 2016-04-03 19:34 GMT-07:00 Stuart Bishop  
> :
>
>
> On 4 April 2016 at 02:00, Merlijn Sebrechts  
> 
> wrote:
>
> Hi all
>
>
> The apache-kafka charm has an action "read-topic" that can return a lot
>
> of
>
> data. Sometimes, this data is too long to be passed to `action-set` by
> commandline. You get the following error:
>
> Traceback (most recent call last):
>   File "actions/read-topic", line 36, in 
> hookenv.action_set({'output': output})
>   File
> "/usr/local/lib/python2.7/dist-packages/charmhelpers/core/hookenv.py",
>
> line
>
> 615, in action_set
> subprocess.check_call(cmd)
>   File "/usr/lib/python2.7/subprocess.py", line 535, in check_call
> retcode = call(*popenargs, **kwargs)
>   File "/usr/lib/python2.7/subprocess.py", line 522, in call
> return Popen(*popenargs, **kwargs).wait()
>   File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
> errread, errwrite)
>   File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
> raise child_exception
> OSError: [Errno 7] Argument list too long
>
>
> Is there any way to pass a file to action-set?
>
> This bug affects many of the Juju tools causing charms to fail at
> scale. https://bugs.launchpad.net/juju-core/+bug/1437366
> (relation-set) is the only one I know of that has been 
> fixed.https://bugs.launchpad.net/juju-core/+bug/1274460 (juju-log) is still
> open. leader-set also fails now I think of it, but I haven't tripped
> over that one (it limits scalability the way I'm using leadershp
> settings, but I should be able to squeeze out several hundred units).
> Maybe we can use the opportunity to fix quoting and encoding issues.
>
> I suspect if you can get past command line length limitations, I
> suspect the next glass ceiling is a 16MB document size limit in
> MongoDB (which is large enough to not need fixing?)
>
> --
> Stuart Bishop  
>
>
>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Planning for Juju 2.2 (16.10 timeframe)

[Narinder Gupta]

+1 for DNS as this was request in other community project as well which
uses JUJU.

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 Tue, Apr 5, 2016 at 2:50 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> +1 for the DNS; We could really use that!
>
> 2016-04-05 3:31 GMT-07:00 Simon Davy :
>
>> Lots of interesting ideas here.
>>
>> Some other ideas (apologies if these have already been proposed, but I
>> don't *think* they have)
>>
>> a) A small one - please can we have 'juju get  '? See
>> https://bugs.launchpad.net/juju-core/+bug/1423548
>>
>> Maybe this is already in the config schema work, but it would *really*
>> help in a lot
>> of situations, and it seems simple?
>>
>> e.g.
>>
>> $ juju get my-service foo
>> bar
>>
>> This would make me very happy :)
>>
>>
>> b) A bigger ask: DNS for units.
>>
>> Provider level dns (when present) only gives machine name dns, which
>> is not useful when working at the model level. As an operator, I've
>> generally no idea which machine unit X is on, and have to go hunting
>> in juju status. It's be great to be able to address individual units, both
>> manually when troubleshooting, and in scripts.
>>
>> One way to do this might be if juju could provide a local dns resolver
>> as part of the controller.
>>
>> e.g. if you have a model called 'bar', with service called
>> 'foo', with 2 units, the following domains[1] could be resolved by the
>> controller dns resolver:
>>
>> foo-0.bar
>> foo-1.bar
>>
>> and/or
>>
>> unit-foo-0.bar
>> unit-foo-1.bar
>>
>> or even
>>
>> 0.foo.bar
>> 1.foo.bar
>>
>>
>> Then tools can be configured to use this dns resolver. For example, we
>> have deployment servers where we manage our models from. We could add
>> the controller's dns here, making it easy for deployment/maintenance
>> scripts to target units easily.
>>
>> Right now, we have to parse json output in bash from juju status to
>> scrape ip addresses, which is horrible[2]
>>
>> Other possibilities (warning: not necessarily a good idea)
>>
>>  * add this resolver into the provisioned machine configuration, so config
>> on the units could use these domain names.
>>
>>  * the controller dns resolver can forward to a specified upstream
>> resolver (falling back to host's resolv.conf info)
>> - single point of control for dns for all models in that controller
>> - repeatability/reliability - if upsteam dns is down, controller
>>   dns still provides local resolution, and also could cache upstream,
>>   perhaps.
>>
>>  * if you ask for a service level address, rather than unit, it could
>> maybe return a dns round robin record. This would be useful for
>> internal haproxy services, for example, and could give some default
>> load-balancing OOTB
>>
>>  * would provide dns on providers that don't have native support
>> (like, erm, ps4.5 :)
>>
>> Now, there are caveats a plenty here. We'd need HA dns cluster, and
>> there's a whole bunch of security issues that would need addressing,
>> to be sure. And I would personally opt for an implementation that uses
>> proven dns technology rather than implementing a new dns
>> resolver/forwarder in go with a mongodb backend. But maybe that's just
>> me ;P
>>
>>
>> Thanks.
>>
>>
>> [1] in hindsight, I do think having a / in the unit name was not the
>> best option, due to it's path/url issues. AIUI, internally juju uses
>> unit--N as identifiers? Could this be exposed as alternate unit
>> names? i.e. cli/api commands could accept either?
>>
>> [2] At the very least, it would be great to have a cli to get the
>> ip(s) of a unit, would simplify a lot of scripts. e.g.
>>
>> $ juju get-ip foo/0 --private
>> 10.0.3.24
>> $ juju get-ip foo/0 --public
>> 1.2.3.4
>> $ juju get-ip foo --private
>> 10.0.3.24
>> 10.0.3.134
>>
>>
>> --
>> Simon
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New juju in ubuntu

[Martin Packman]

On 05/04/2016, Adam Collard  wrote:
> Will there be a transitional release of 1.25.x that also gives us a juju1
> binary to facilitate this?

Yes, the plan entails both an update to the juju in main for the 2.0
release and a new juju 1.25 in universe that cooperates with the
changes.

For the debian packaging nitty gritty, what we had before was:

Archive:
  juju (depends juju-core)
juju-core (/usr/bin/juju etc)
  juju-local (depends juju-core, juju-mongodb, lxc bits)
  juju-local-kvm (depends juju-core, juju-mongodb, libvirt bits)

Devel PPA:
  juju2 (/usr/bin/juju2 etc)

We have the following proposed:

Main:
  juju (depends juju-2.0, suggests juju-core)
juju-2.0 (/usr/lib/juju-2.0/bin/juju, linked as /usr/bin/juju and
wrapped as /usr/bin/juju-2.0)

(The lxd provider is bundled, replacing the local packaging bits for 2.0).

Universe:
  juju-core (transitional depends juju-1.25)
  juju-1 (depends juju-1.25)
juju-1.25 (/usr/lib/juju-1.25/bin/juju, wrapped as /usr/bin/juju-1)
  juju-local (depends juju-1.25, juju-mongodb, lxc bits)
  juju-local-kvm (depends juju-1.25, juju-mongodb, libvirt bits)

When upgrading, you keep your juju package and upgrade juju-core to
the new 1.X packaging, and pick up the new 2.0 package. With a fresh
install, you just get 2.0 unless you ask for juju-1 as well or take
the suggests.

Martin

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

Re: New juju in ubuntu

[Adam Collard]

Will there be a transitional release of 1.25.x that also gives us a juju1
binary to facilitate this?
On Tue, 5 Apr 2016 at 19:36, Martin Packman 
wrote:

> Some of you will be aware of the excitement over the last week getting
> Juju 2.0 into Xenial, this is an update mail so everyone knows what
> the goal is with the user experience.
>
> The challenge here is we want Juju 2.0 and all the new functionality
> to be the default on release, but not break our existing users who
> have working Juju 1.X environments and no deployment upgrade path yet.
> So, versions 1 and 2 have to be co-installable, and when upgrading to
> xenial users should get the new version without their existing working
> juju being removed.
>
> There are several ways to accomplish that, but based on feedback from
> the release team, we switched from using update-alternatives to having
> 'juju' on xenial always be 2.0, and exposing the 1.X client via a
> 'juju-1' binary wrapper. Existing scripts can either be changed to use
> the new name, or add the version-specific binaries directory
> '/var/lib/juju-1.25/bin' to the path.
>
> Because the meaning of 'juju' is changing, we want to give a
> on-first-run message about how to work with any existing environments
> the user may have. That work is covered by:
> 
> The best way to detect seems to be, when creating the new
> configuration for 2.0, if ~/.juju or JUJU_HOME is set, use the series
> to suggest ways to access or install the 1.X client.
>
> There were some other interesting points from review.
>
> The way we do plugins both leads to large binaries with a lot of
> duplication, and means the only sane way to deal with multiple juju
> versions is through path manipulation. If anyone is wants to
> distribute juju plugins, they'll need to watch out for this. See this
> bug on the binary sizes:
> 
>
> Also we've had to avoid stripping the juju binaries, which is
> otherwise standard distro practice, as it was unsupported and go 1.2
> breaks. With the switch to go 1.6 it seems like this may now work as
> expected, but needs to go through testing:
> 
>
> We also have some ongoing questions over golang packaging in the
> distro as a whole, but have demonstrated we an split out and create
> seperate golang-*-dev packages for nearly all the juju dependencies as
> needed.
>
> We hope to avoid most of the pain from this packaging process next
> cycle by putting our alpha releases into the devel disto (Y 16.10),
> rather than just adding them to our PPA. This will not need to replace
> the 2.0 version if we have compatibility concerns with early versions
> given the packaging changes from this cycle, but we will also be back
> to no-breakage mode as well.
>
> 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

New juju in ubuntu

[Martin Packman]

Some of you will be aware of the excitement over the last week getting
Juju 2.0 into Xenial, this is an update mail so everyone knows what
the goal is with the user experience.

The challenge here is we want Juju 2.0 and all the new functionality
to be the default on release, but not break our existing users who
have working Juju 1.X environments and no deployment upgrade path yet.
So, versions 1 and 2 have to be co-installable, and when upgrading to
xenial users should get the new version without their existing working
juju being removed.

There are several ways to accomplish that, but based on feedback from
the release team, we switched from using update-alternatives to having
'juju' on xenial always be 2.0, and exposing the 1.X client via a
'juju-1' binary wrapper. Existing scripts can either be changed to use
the new name, or add the version-specific binaries directory
'/var/lib/juju-1.25/bin' to the path.

Because the meaning of 'juju' is changing, we want to give a
on-first-run message about how to work with any existing environments
the user may have. That work is covered by:

The best way to detect seems to be, when creating the new
configuration for 2.0, if ~/.juju or JUJU_HOME is set, use the series
to suggest ways to access or install the 1.X client.

There were some other interesting points from review.

The way we do plugins both leads to large binaries with a lot of
duplication, and means the only sane way to deal with multiple juju
versions is through path manipulation. If anyone is wants to
distribute juju plugins, they'll need to watch out for this. See this
bug on the binary sizes:


Also we've had to avoid stripping the juju binaries, which is
otherwise standard distro practice, as it was unsupported and go 1.2
breaks. With the switch to go 1.6 it seems like this may now work as
expected, but needs to go through testing:


We also have some ongoing questions over golang packaging in the
distro as a whole, but have demonstrated we an split out and create
seperate golang-*-dev packages for nearly all the juju dependencies as
needed.

We hope to avoid most of the pain from this packaging process next
cycle by putting our alpha releases into the devel disto (Y 16.10),
rather than just adding them to our PPA. This will not need to replace
the 2.0 version if we have compatibility concerns with early versions
given the packaging changes from this cycle, but we will also be back
to no-breakage mode as well.

Martin

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

Updating bundles and publishing them.

[Jorge O. Castro]

Hello everyone,

I took to updating the wiki bundles for the 2.0 release and thought I
would share my notes on publishing bundles with the fancy new
publishing process. Here is a list of all the bundles in the store,
recommend you sort it by # of deployments.

https://jujucharms.com/q/?type=bundle

If you are looking for something to do, a bunch of these could use
with updating to the latest charm revisions, converting to the new
bundle format, and so on. It's a great way to learn how the charm
store now works and help someone else out in one go. Here's how I
updated mediawiki-scalable to a new "wiki-scalable":

charm get mediawiki-scalable

Then update the bundle, `charm proof .` will check the bundle for you
so you don't waste time deploying something broken. Publish your charm
somewhere in VCS, eg. https://github.com/juju-solutions/wiki-scalable

Publish the charm in the store, from the bundle's directory:

juju deploy . # test your work first!
charm login
charm push . bundle/wiki-scalable

Set some of the new metadata, note that we're setting these keys to a
specific revision, 0:

charm set cs:~jorge/bundle/wiki-scalable-0
bugs-url=https://github.com/juju-solutions/wiki-scalable/issues
charm set cs:~jorge/bundle/wiki-scalable-0
homepage=https://github.com/juju-solutions/wiki-scalable/

And now publish, then set the permissions for the world to see it:

charm publish cs:~jorge/bundle/wiki-scalable-0
charm grant cs:~jorge/bundle/wiki-scalable everyone

And that's it. If you want your bundle to be officially recommended
then you need to submit it to the new review queue process, which
Marco is currently working on and will mail the list this week with
updates to that. Shout out to Jay Wren for fixing the issues we found
as we tested publish.


-- 
Jorge Castro
Canonical Ltd.
http://jujucharms.com/ - The fastest way to model your service

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

Re: Charm execution graph in docs

[Nick Veitch]

Hi Paul,

Thanks very much for this. We definitely do want to include more useful
material like this in the documentation
I created a new issue on the docs site so you can track our progress:
https://github.com/juju/docs/issues/958

On 5 April 2016 at 16:57, Paul Eipper  wrote:

> Hi all,
>
> This is a documentation request for having a life cycle overview of a
> charm, linking the events in a way so that the complete set of
> possible states is visible and what are their triggers.
>
> For reference, I created a graph and shared it on stackoverflow some time
> ago:
> http://stackoverflow.com/a/25980368/324731
>
> Would be best to have an official source though, updated to latest changes.
>
> att,
> --
> Paul Eipper
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>



-- 
Nick Veitch,
CDO Documentation
Canonical
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Charm execution graph in docs

[Paul Eipper]

Hi all,

This is a documentation request for having a life cycle overview of a
charm, linking the events in a way so that the complete set of
possible states is visible and what are their triggers.

For reference, I created a graph and shared it on stackoverflow some time ago:
http://stackoverflow.com/a/25980368/324731

Would be best to have an official source though, updated to latest changes.

att,
--
Paul Eipper

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

Juju Storage

[Bruno Ranieri]

Hi,

I am working on charms for the Quobyte Storage System. These charms make
use of the Juju Storage support,
but unfortunately juju storage does not behave as expected:

In my charms block-type storage is defined (metadata.yaml):

> [...]
> storage:
>   registry-storage:
> type: block
> description: registry storage
> minimum-size: 10G
> multiple:
>   range: '1'
>

When I deploy this charm to ec2 I assume that juju will create an
ebs-volume [1].
What it does instead is creating a loop-device?

After 'juju switch amazon' and 'juju bootstrap' [2] my storage pool is
initialized to

> ubuntu@bruno:~$ juju storage pool list
> ebs-ssd:
>   provider: ebs
>   attrs:
> volume-type: ssd
>


When deploying this charm

> ubuntu@bruno:~$ juju deploy --repository=. local:quobyte-registry
> Added charm "local:trusty/quobyte-registry-1" to the environment.
>

already the agent deployment fails with:

> $ juju debug-log --replay
> [...]
> machine-1[14401]: 2016-04-05 12:06:01 ERROR juju.worker runner.go:223
> exited "deployer": cannot create agent
> config dir "/var/lib/juju/agents/unit-quobyte-registry-0": mkdir
> /var/lib/juju/agents/unit-quobyte-registry-0: no space left on device
>

Debugging into the deployed machine (and ec2-console) shows that no
ebs-volume was created but an image on the local disk:

> $ juju ssh 1
> ubuntu@ip-x.y.z.a:~$ df -h
> Filesystem  Size  Used Avail Use% Mounted on
> udev1.9G   12K  1.9G   1% /dev
> tmpfs   375M  204K  375M   1% /run
> /dev/disk/by-label/cloudimg-rootfs  7.8G  7.8G 0 100% /
> none4.0K 0  4.0K   0% /sys/fs/cgroup
> none5.0M 0  5.0M   0% /run/lock
> none1.9G 0  1.9G   0% /run/shm
> none100M 0  100M   0% /run/user
> /dev/xvdb   3.9G  8.1M  3.7G   1% /mnt
>


I'm aware that it is possible to control the storage usage during
service-deploment on the command-line
using '--storage registry-storage=ebs', but I do not think that this is the
correct solution? Currently I am working on tests
for the 'juju test' -runner. There I cannot hard-wire storage to ebs, since
these tests should be independent form a specific provider.

Any ideas what is possible wrong I my setup?

Thanks and Regards,
 Bruno Ranieri


[1] 'If pool is not specified, then Juju will select the default storage
provider for the current environment
  (e.g. cinder for openstack, ebs for ec2, loop for local)'
https://jujucharms.com/docs/1.25/storage

[2] $ cat ~/.juju/environments.yaml

> default: local
> environments:
>   local:
> type: local
> admin-secret: xyz
> lxc-clone: true
> allow-lxc-loop-mounts: true
> default-series: trusty
>
>   amazon:
>type: ec2
>region: eu-central-1
>access-key: xyz
>secret-key: xyz
>admin-secret: xyz
>default-series: trusty
>
>

-- 
Quobyte GmbH
Hardenbergplatz 2 - 10623 Berlin - Germany
+49-30-814 591 800 - www.quobyte.com
Amtsgericht Berlin-Charlottenburg, HRB 149012B
management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Planning for Juju 2.2 (16.10 timeframe)

[Simon Davy]

Lots of interesting ideas here.

Some other ideas (apologies if these have already been proposed, but I
don't *think* they have)

a) A small one - please can we have 'juju get  '? See
https://bugs.launchpad.net/juju-core/+bug/1423548

Maybe this is already in the config schema work, but it would *really*
help in a lot
of situations, and it seems simple?

e.g.

$ juju get my-service foo
bar

This would make me very happy :)


b) A bigger ask: DNS for units.

Provider level dns (when present) only gives machine name dns, which
is not useful when working at the model level. As an operator, I've
generally no idea which machine unit X is on, and have to go hunting
in juju status. It's be great to be able to address individual units, both
manually when troubleshooting, and in scripts.

One way to do this might be if juju could provide a local dns resolver
as part of the controller.

e.g. if you have a model called 'bar', with service called
'foo', with 2 units, the following domains[1] could be resolved by the
controller dns resolver:

foo-0.bar
foo-1.bar

and/or

unit-foo-0.bar
unit-foo-1.bar

or even

0.foo.bar
1.foo.bar


Then tools can be configured to use this dns resolver. For example, we
have deployment servers where we manage our models from. We could add
the controller's dns here, making it easy for deployment/maintenance
scripts to target units easily.

Right now, we have to parse json output in bash from juju status to
scrape ip addresses, which is horrible[2]

Other possibilities (warning: not necessarily a good idea)

 * add this resolver into the provisioned machine configuration, so config
on the units could use these domain names.

 * the controller dns resolver can forward to a specified upstream
resolver (falling back to host's resolv.conf info)
- single point of control for dns for all models in that controller
- repeatability/reliability - if upsteam dns is down, controller
  dns still provides local resolution, and also could cache upstream,
  perhaps.

 * if you ask for a service level address, rather than unit, it could
maybe return a dns round robin record. This would be useful for
internal haproxy services, for example, and could give some default
load-balancing OOTB

 * would provide dns on providers that don't have native support
(like, erm, ps4.5 :)

Now, there are caveats a plenty here. We'd need HA dns cluster, and
there's a whole bunch of security issues that would need addressing,
to be sure. And I would personally opt for an implementation that uses
proven dns technology rather than implementing a new dns
resolver/forwarder in go with a mongodb backend. But maybe that's just
me ;P


Thanks.


[1] in hindsight, I do think having a / in the unit name was not the
best option, due to it's path/url issues. AIUI, internally juju uses
unit--N as identifiers? Could this be exposed as alternate unit
names? i.e. cli/api commands could accept either?

[2] At the very least, it would be great to have a cli to get the
ip(s) of a unit, would simplify a lot of scripts. e.g.

$ juju get-ip foo/0 --private
10.0.3.24
$ juju get-ip foo/0 --public
1.2.3.4
$ juju get-ip foo --private
10.0.3.24
10.0.3.134


-- 
Simon

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

Re: Action return value too long for commandline

[Mark Shuttleworth]

We should definitely have a mechanism for large-file output from actions
and other hooks. I think resources are "inward flowing", they come from
the charmer or they are provided by the operator. You're looking for
"outward flowing" blobs.

As I recall, the intention was that actions could drop results into the
controller in a way that was friendly to large BLOB results. That's why
we have an async action output and result mechanism. I reckon it would
be fine to use resources for input to actions (there would just be a
specific user-provided resource name and there would be only one version
of that at any given time), but we want to make sure that output can
also be efficiently handled regardless of size, so if we need to improve
that, let's crack on.

Mark

On 04/04/16 16:56, Merlijn Sebrechts wrote:
> Hi Stuart
>
>
> Thanks for this explanation. 16MB is definitely a step in the right
> direction. However, in the future I'll need to transfer even bigger files.
> Is there a possibility for using resources for this in the future? It would
> be great if an action could upload a file to the resources server so the
> admin can download it from there.
>
>
>
> Kind regards
> Merlijn Sebrechts
>
> 2016-04-03 19:34 GMT-07:00 Stuart Bishop :
>
>> On 4 April 2016 at 02:00, Merlijn Sebrechts 
>> wrote:
>>> Hi all
>>>
>>>
>>> The apache-kafka charm has an action "read-topic" that can return a lot
>> of
>>> data. Sometimes, this data is too long to be passed to `action-set` by
>>> commandline. You get the following error:
>>>
>>> Traceback (most recent call last):
>>>   File "actions/read-topic", line 36, in 
>>> hookenv.action_set({'output': output})
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/charmhelpers/core/hookenv.py",
>> line
>>> 615, in action_set
>>> subprocess.check_call(cmd)
>>>   File "/usr/lib/python2.7/subprocess.py", line 535, in check_call
>>> retcode = call(*popenargs, **kwargs)
>>>   File "/usr/lib/python2.7/subprocess.py", line 522, in call
>>> return Popen(*popenargs, **kwargs).wait()
>>>   File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
>>> errread, errwrite)
>>>   File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
>>> raise child_exception
>>> OSError: [Errno 7] Argument list too long
>>>
>>>
>>> Is there any way to pass a file to action-set?
>> This bug affects many of the Juju tools causing charms to fail at
>> scale. https://bugs.launchpad.net/juju-core/+bug/1437366
>> (relation-set) is the only one I know of that has been fixed.
>> https://bugs.launchpad.net/juju-core/+bug/1274460 (juju-log) is still
>> open. leader-set also fails now I think of it, but I haven't tripped
>> over that one (it limits scalability the way I'm using leadershp
>> settings, but I should be able to squeeze out several hundred units).
>> Maybe we can use the opportunity to fix quoting and encoding issues.
>>
>> I suspect if you can get past command line length limitations, I
>> suspect the next glass ceiling is a 16MB document size limit in
>> MongoDB (which is large enough to not need fixing?)
>>
>> --
>> Stuart Bishop 
>>
>
>

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