Deploy OpenStack HA failed on regular HDDs by juju-deployer

[曾建銘]

Hi all,

I tried to deploy OpenStack HA by juju-deployer on several physical
machines. (with MAAS)

When the OSs on those physical machines are installed in SSD, deploy
OpenStack by juju-deployer will be success.

But if the OSs are installed in regular HDDs, deploy OpenStack by
juju-deployer always failed.

I used the same configuration file to deploy on different type of disks,
and I got the different results. It really surprised me when I got these
results.

Is SSD required if deploy a lot of charms simultaneously(e.g. OpenStack HA)
by juju-deployer?

By the way, my OpenStack deploy configuration contains 20 charms and more
than 60 relations, is that matter?

Thanks for your response in advanced.

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

Re: Deploy OpenStack HA failed on regular HDDs by juju-deployer

[曾建銘]

Hi  Ray,

many thanks for your response.

As you mentioned, juju-deployer has the options to set the delays when
adding relations.

Did you mean juju-deployer can add delay when adding every relation? If so,
which option can do that? I can not find it in "juju-deployer -h".

I have tried "-s" and "-w" two options to delay the deploy process. But I
still failed when deploy OpenStack(20 charms and 60+ relations) in physical
machines with regular hard disks.

Sincerely yours,
Leon



On Fri, Oct 23, 2015 at 6:26 PM, Ray Wang  wrote:

> Hello 建铭
>
> On Fri, Oct 23, 2015 at 4:57 PM, 曾建銘  wrote:
> > Hi all,
> >
> > I tried to deploy OpenStack HA by juju-deployer on several physical
> > machines. (with MAAS)
> >
> > When the OSs on those physical machines are installed in SSD, deploy
> > OpenStack by juju-deployer will be success.
> >
> > But if the OSs are installed in regular HDDs, deploy OpenStack by
> > juju-deployer always failed.
> >
> > I used the same configuration file to deploy on different type of disks,
> and
> > I got the different results. It really surprised me when I got these
> > results.
> >
> > Is SSD required if deploy a lot of charms simultaneously(e.g. OpenStack
> HA)
> > by juju-deployer?
>
> juju-deployer has the options to set the delays when adding relations,
> deploy services etc, so it's worth to try to set different delays for
> both services deployment and add relations.
>
> >
> > By the way, my OpenStack deploy configuration contains 20 charms and more
> > than 60 relations, is that matter?
> >
> > Thanks for your response in advanced.
>
> Do you have the error logs, so that we can see where is the problem?
> Or is it possible to post your bundle file?
>
> >
> > Sincerely yours,
> > Leon
> >
> > --
> > Juju mailing list
> > Juju@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju
> >
>
>
>
> --
> Ray Wang
> Canonical  www.canonical.com | Ubuntu  www.ubuntu.com
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: UOS Sessions, anyone?

[Samuel Cozannet]

I have a few meaningful demos for big data with datasets ready and
everything scripted on my github (
HTTPS://github.com/SaMnCo/juju-strata-demos, pick saiku or SpagoBI branch)

But I will be off during the sessions so someone else would have to run
them.

I can and would be happy to train or help whoever volunteers prior to the
30th of October.

Best,
Sam
On Oct 23, 2015 3:35 PM, "Rick Harding"  wrote:

> Definitely think it'd be great to get some sessions going. Some ideas:
>
> reactive framework from ben/cory and maybe some talk through how to join
> into the community/guide folks to submitting new layers/stubs
>
> using the big-data solutions to do something interesting, work on the
> reuse of existing work story there
>
> the UI Eng folks could walk through the plans for the new charm upload
> process and possibly recruit some beta users as that moves forward
>
> might also get them to show off some of the GUI 2.0 goodness coming and
> discuss the roadmap there a bit
>
> Alexis, do you think someone could pull together a core demo of new stuff
> from the lightning talks we had recently? Storage, networking, lxd provider
> demos? It'd be great to double dip and use the recorded sessions as
> potential anchors to blog/announcements about new features in 1.25 perhaps?
>
> Jose, we'll chat with folks and see what we can get pulled together.
> Thanks for reaching out!
>
> Rick
>
>
> On Fri, Oct 23, 2015 at 3:13 AM José Antonio Rey  wrote:
>
>> Hey guys,
>>
>> UOS is just around the corner. Do you have anything to tell people
>> about, anything you'd like to discuss about Juju or the Cloud and
>> Ubuntu? Let me know, and let's get your session on UOS!
>>
>> Yes, we accept cool ideas. If you're working and want to show it to the
>> world - it's the perfect time.
>>
>> If you have any other questions about UOS or sessions/the schedule,
>> don't hesitate to send me an email. I'll be more than glad to help you
>> out!
>>
>> --
>> José Antonio Rey
>>
>> --
>> 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

[Review Queue] Hectane

[Charles Butler]

I had a chance to review the Hectane charm today from Nathan Osman, its a
GoLang based API that aim at being a simple email service (similar to
mandrill). The charm was a great first submission, and well formed. It's
been +1'd and promulgated.

https://bugs.launchpad.net/charms/+bug/1504375



Charles Butler  - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Renaming of environments

[Andrew Wilkins]

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

Re: UOS Sessions, anyone?

[Rick Harding]

Definitely think it'd be great to get some sessions going. Some ideas:

reactive framework from ben/cory and maybe some talk through how to join
into the community/guide folks to submitting new layers/stubs

using the big-data solutions to do something interesting, work on the reuse
of existing work story there

the UI Eng folks could walk through the plans for the new charm upload
process and possibly recruit some beta users as that moves forward

might also get them to show off some of the GUI 2.0 goodness coming and
discuss the roadmap there a bit

Alexis, do you think someone could pull together a core demo of new stuff
from the lightning talks we had recently? Storage, networking, lxd provider
demos? It'd be great to double dip and use the recorded sessions as
potential anchors to blog/announcements about new features in 1.25 perhaps?

Jose, we'll chat with folks and see what we can get pulled together. Thanks
for reaching out!

Rick


On Fri, Oct 23, 2015 at 3:13 AM José Antonio Rey  wrote:

> Hey guys,
>
> UOS is just around the corner. Do you have anything to tell people
> about, anything you'd like to discuss about Juju or the Cloud and
> Ubuntu? Let me know, and let's get your session on UOS!
>
> Yes, we accept cool ideas. If you're working and want to show it to the
> world - it's the perfect time.
>
> If you have any other questions about UOS or sessions/the schedule,
> don't hesitate to send me an email. I'll be more than glad to help you out!
>
> --
> José Antonio Rey
>
> --
> 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: Deploy OpenStack HA failed on regular HDDs by juju-deployer

[Ray Wang]

Hello 建铭

On Fri, Oct 23, 2015 at 4:57 PM, 曾建銘  wrote:
> Hi all,
>
> I tried to deploy OpenStack HA by juju-deployer on several physical
> machines. (with MAAS)
>
> When the OSs on those physical machines are installed in SSD, deploy
> OpenStack by juju-deployer will be success.
>
> But if the OSs are installed in regular HDDs, deploy OpenStack by
> juju-deployer always failed.
>
> I used the same configuration file to deploy on different type of disks, and
> I got the different results. It really surprised me when I got these
> results.
>
> Is SSD required if deploy a lot of charms simultaneously(e.g. OpenStack HA)
> by juju-deployer?

juju-deployer has the options to set the delays when adding relations,
deploy services etc, so it's worth to try to set different delays for
both services deployment and add relations.

>
> By the way, my OpenStack deploy configuration contains 20 charms and more
> than 60 relations, is that matter?
>
> Thanks for your response in advanced.

Do you have the error logs, so that we can see where is the problem?
Or is it possible to post your bundle file?

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



-- 
Ray Wang
Canonical  www.canonical.com | Ubuntu  www.ubuntu.com

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

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

Juju stable 1.25.0 is proposed for release.

[Curtis Hovey-Canonical]

# juju-core 1.25.0

A new proposed stable release of Juju, juju-core 1.25.0, is now available.
This release may replace version 1.24.7 on Thursday October 29.


## Getting Juju

juju-core 1.25.0 is available for Wily and backported to earlier
series in the following PPA:

https://launchpad.net/~juju/+archive/proposed

Windows Centos, and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.25.0

Proposed releases use the "proposed" simple-streams. You must configure
the `agent-stream` option in your environments.yaml to use the matching
juju agents.


## Notable Changes
  * (Experimental) Improved networking features for AWS
* New 'spaces' and 'subnet' commands
* New 'spaces' constraints support
  * Support for "devices" on MAAS 1.8+
  * Storage support for GCE and Azure providers
  * Payload management for charmers


### (Experimental) Improved networking features for AWS

Juju has experimental support for deploying services on AWS in isolation,
taking advantage of the enhanced AWS VPC networking features. This is just a
first step towards a full-fledged networking model support in Juju.


 New 'spaces' and 'subnet' commands

Juju introduces the 'space' and 'subnet' commands to manage the networks
available to services. A Juju network space is a collection of related subnets
that have no firewalls between each other and have the same ingress and egress
policies.

You can create a new Juju space, and optionally associate existing subnets
with it by specifying their CIDRs using the 'create' subcommand. The command
looks like this:

juju space create  [  …]

The list of registered spaces can be seen using the 'list' subcommand:

juju space list [--short] [--format yaml|json] [--output ]

You can add an existing AWS subnet to a space by CIDR or AWS ID, for example:

juju subnet add | 

You can list all the subnets known by Juju and optionally filtering them by
space and/or availability zone like so:

juju subnet list [--zone ] [--space ] [  …]

For more information about these commands, type:

juju  --help


 New 'spaces' constraints support

The new 'spaces' constraint instructs Juju to deploy a service's units in
subnets of the given space.

Similar to the 'tags' constraint, the 'spaces' constraint takes a comma-
delimited list of existing Juju network spaces. Both positive (without prefix)
and negative (prefixed by "^") spaces are allowed in the list. For this alpha
release, the first positive space name is used, the rest is ignored.

You can constrain a service to a space like this:

juju deploy  [] [--constraints "spaces="]

For more information, run

juju help glossary

and

juju help constraints


 Known issues

Deploying a service to a space that has no subnets will cause the agent to
panic and is a known issue (https://launchpad.net/bugs/1499426). This issue
can be mitigated by always adding at least one subnet to the space.


### Support "devices" on MAAS 1.8+

MAAS 1.8 introduced a new feature called "devices". This allows the
association of a "device", that requires an IP address, with a parent machine
managed by MAAS. There is a view in the MAAS UI showing all devices.

With the "address-allocation" feature flag enabled, Juju will register LXC and
KVM containers as devices on MAAS 1.8+. They are visible in the MAAS UI. If
the environment is forcibly shut down, the IP addresses allocated to the
containers will be released by MAAS.

You can enable "address-allocation" is new Juju environments like so:

JUJU_DEV_FEATURE_FLAG=address-allocation juju bootstrap


### Storage support for GCE and Azure providers

Juju's storage feature can now be used with the Google Compute Engine and
Azure providers. Storage is now supported for local, AWS, Openstack, MAAS, GCE
and Azure. See https://jujucharms.com/docs/devel/storage for more information.


### Status for storage volumes

Volumes now have status associated, so provisioning progress can be observed.
List the volumes to see their status:

juju storage volume list


### Payload management for charmers

The new payload management feature allows charmers to more accurately define
large and complex deployments by registering different payloads, such as LXC,
KVM, and docker, with Juju. This lets the operator better understand the
purpose and function of these payloads on a given machine.

You define these payloads in the metadata.yaml of the charm under the
payloads section. You create a class for the payload, "monitoring" or "kvm-
guest", and assign the type.

payloads:
monitoring:
type: docker
kvm-guest:
type: kvm

From your charm hook you can manage your payload with the following
commands:

payload-register[tags]
payload-unregister   
payload-status-set

From the Juju command line you can view your payloads like this:

  juju list-payloads 

For more 

Re: Juju stable 1.25.0 is proposed for release.

[Mark Shuttleworth]

On 24/10/15 02:30, Curtis Hovey-Canonical wrote:
> # juju-core 1.25.0
>
> A new proposed stable release of Juju, juju-core 1.25.0, is now available.
> This release may replace version 1.24.7 on Thursday October 29.
>

Congrats all, looking forward to taking this for a spin.

Especially keen to see how people use the docker container management
features in payload management! This makes it really easy to write a
charm that handles all the setup and teardown, but uses a docker
container for the actual app. Same thing goes for the KVM payloads which
folks are using to charm old OS applications.

> ### Payload management for charmers
>
> The new payload management feature allows charmers to more accurately define
> large and complex deployments by registering different payloads, such as LXC,
> KVM, and docker, with Juju. This lets the operator better understand the
> purpose and function of these payloads on a given machine.
>
> You define these payloads in the metadata.yaml of the charm under the
> payloads section. You create a class for the payload, "monitoring" or "kvm-
> guest", and assign the type.
>
> payloads:
> monitoring:
> type: docker
> kvm-guest:
> type: kvm
>
> From your charm hook you can manage your payload with the following
> commands:
>
> payload-register[tags]
> payload-unregister   
> payload-status-set stopping, stopped>
>
> From the Juju command line you can view your payloads like this:
>
>   juju list-payloads 
>
> For more information run:
>
> juju help payloads




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

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

[Aaron Bentley]

bzr has a similar feature, but the problem with such a feature is that
it can break scripts that expect the normal behaviour.  That's why bzr
provides a --no-aliases option, which all scripts calling bzr should use.

The same applies to Juju.  If "status" gets defaulted to "status
--format=tabular", most of our test scripts will break.  This isn't
likely to happen on our test machines, but could easily happen when
devs run our test scripts.

Could you please provide a similar --no-aliases option for juju, so
that we can ensure people don't break our scripts by specifying
surprising defaults?

Thanks,

Aaron

On 2015-10-23 12:12 AM, Tim Penhey wrote:
> Hi folks,
> 
> I scratched a personal itch yesterday and added the ability for
> users to specify their own aliases for juju commands.
> 
> There are two primary use cases that I was trying to address.
> 
> Firstly, the ability to specify default flags for commands: status
> = status --format=tabular
> 
> I could never remember the right environment variable to set to
> get tabular by default.
> 
> The second was to allow quicker iteration around playing with new
> CLI structure.  As most people are aware, the 2.0 CLI is going to
> be somewhat different to the current one, and I thought it would be
> good to provide a way in which we could "test drive" the new CLI
> with the existing codebase without having to actually code
> anything.
> 
> The aliases files lives in JUJU_HOME, and is a simple text file.
> Each non blank line that doesn't start with a '#' is considered to
> be an alias. The format is expected to be:
> 
>  =  [...]
> 
> So we can do things like:
> 
> # stat is like two whole letters shorter... stat = status
> --format=tabular
> 
> # list tests list-environments = system environments list-users =
> user list
> 
> and so on.
> 
> Tim
> 

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

[Review Queue] kibana, ibm java sdk, jenkins-bundle

[Andrew Mcleod]

Your friendly Big Data team managed to get some quality review queue time
yesterday. Below are the results!


*kibana*

https://code.launchpad.net/~chris.macnaughton/charms/trusty/kibana/version_bump/+merge/274029

This review was for a version bump from 3 to 4 - The charm itself looks
good, the GUI is accessible after deployment, etc. However, two tests were
failing with connectivity issues - these seem to be relatively trivial
failures so I don't think this one is far off approval.


*IBM Java SDK*

https://bugs.launchpad.net/charms/+bug/1477067

This charm is interesting as it is the second from an ISV that offers an
alternative to our default openjdk/jre environment.  Azul Systems had Zulu8
promulgated a few weeks ago -- their charm is a subordinate designed to be
installed on an existing service unit (e.g tomcat).  This charm, by
contrast, is a primary service that installs a JDK, which would be useful
to develop/test java apps with the IBM JRE on different architectures.
We’re planning to sync with both Azul and IBM next week to discuss the
design of a common jre/jdk interface that all java-based services might
leverage.

In this iteration, the author addressed issues raised from a previous
review, and the charm installed with nice status messages along the way.

We found additional areas for improvement and created a merge proposal to
address them -- things like verifying the sha1sum of the installer, failing
fast on unsupported architectures, and additional status when the charm is
blocked for configuration.


*jenkins-bundle*

https://code.launchpad.net/~matsubara/charms/trusty/jenkins/jenkins-bundle/+merge/270415

This one also looks good, but there were a few minor items that need to be
addressed, such as some lint errors that were introduced, and some
questions / comments on the handling of the extension relation.


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

UOS Sessions, anyone?

[José Antonio Rey]

Hey guys,

UOS is just around the corner. Do you have anything to tell people 
about, anything you'd like to discuss about Juju or the Cloud and 
Ubuntu? Let me know, and let's get your session on UOS!


Yes, we accept cool ideas. If you're working and want to show it to the 
world - it's the perfect time.


If you have any other questions about UOS or sessions/the schedule, 
don't hesitate to send me an email. I'll be more than glad to help you out!


--
José Antonio Rey

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

Re: How to make Juju High Availability work properly?

[Mark Shuttleworth]

On 23/10/15 00:54, 曾建銘 wrote:
> Was the juju doing something for fixing specific problem? I think that
> service on failed node should only become lost and not interfere services
> on workings nodes. But it didn't act as I expected.
>
> By the way, I used Juju to deploy OpenStack, so I deployed a lot of charms
> on it. Is that matter?

No, the scale of the model you're managing should not affect HA in any way.

The team is trying to reproduce your situation by repeatedly causing
failover, but I'm told has not seen anything like your symptoms. Can you
provide copies of logs to Marco?

Mark

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

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

[Dimiter Naydenov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Awesome!! \o/

As a big fan of aliases (bash, git, etc.) I'd start using this right
away with juju now! :)

Thanks Tim!

Dimiter

On 23.10.2015 07:12, Tim Penhey wrote:
> Hi folks,
> 
> I scratched a personal itch yesterday and added the ability for
> users to specify their own aliases for juju commands.
> 
> There are two primary use cases that I was trying to address.
> 
> Firstly, the ability to specify default flags for commands: status
> = status --format=tabular
> 
> I could never remember the right environment variable to set to
> get tabular by default.
> 
> The second was to allow quicker iteration around playing with new
> CLI structure.  As most people are aware, the 2.0 CLI is going to
> be somewhat different to the current one, and I thought it would be
> good to provide a way in which we could "test drive" the new CLI
> with the existing codebase without having to actually code
> anything.
> 
> The aliases files lives in JUJU_HOME, and is a simple text file.
> Each non blank line that doesn't start with a '#' is considered to
> be an alias. The format is expected to be:
> 
>  =  [...]
> 
> So we can do things like:
> 
> # stat is like two whole letters shorter... stat = status
> --format=tabular
> 
> # list tests list-environments = system environments list-users =
> user list
> 
> and so on.
> 
> Tim
> 


- -- 
Dimiter Naydenov 
Juju Core Sapphire team 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWKeZDAAoJENzxV2TbLzHwOuMH/Rt5OqT29cGheVBNGraC0guR
qYSyS8nqsSKb7gizmu9HrbJeQjpQfv+Dskc97yOXlxsQbhfBrFGHkkHl15jsKHBh
XCx531/olNhs8Y9uqfI31SjMqRW4U0wylF4sVfMOpIsrTlJcuU7EQ8meYj0ObR7T
RWv9Rg6pg6b6fQ5tylVV+8LjE6YyRUr+V+8rQp/PLwVrACJQqVyi+tL5UQKd53vj
pgCqEbRJ/wN8fcQP7Pf6jh+FC84xecwmAd9Zc/toHXHh0ZYSKl022h0pPff/1XoB
JQqGyH4SS7XAR3T6jiy6ub7wYCe0LgkPtl13nbcrWR1YYZK1pJxtH+kdkwfYaXk=
=UrrP
-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

Re: How to make Juju High Availability work properly?

[曾建銘]

Hi Marco,

Many thanks for your reply, the juju version I used is 1.24.6-trusty-amd64.

I found that when a juju node failed, not only the services on the node
change to lost, but alse services on other working nodes change to
executing or even error.

I tried to log into the other working node and use "top" to check resource
usage. I found that a lot of CPU power was consumed by jujud in this time.
And it may take hours to become normal again.

Was the juju doing something for fixing specific problem? I think that
service on failed node should only become lost and not interfere services
on workings nodes. But it didn't act as I expected.

By the way, I used Juju to deploy OpenStack, so I deployed a lot of charms
on it. Is that matter?

Sincerely yours,
Leon

On Sun, Oct 18, 2015 at 7:16 AM, Marco Ceppi  wrote:

> Hi Leon,
>
> Sorry to hear you're having issues, I haven't seen this problem before but
> I'm curious what version of Juju you're using (`juju version`) I know there
> was recent work to make ensure-availability more robust. As to how to solve
> the issue, could you run `juju ssh 0` then once on the zero node run:
>
> sudo apt-get install pastebinit
> pastebinit /var/log/juju/machine-0.log
>
> This will provide a URL with the pastebin of the machine-0 log which would
> be helpful in diagnosing this issue further and potentially ways to resolve
> this.
>
> Thanks,
> Marco Ceppi
>
> On Fri, Oct 16, 2015 at 3:56 AM 曾建銘  wrote:
>
>> Hi All,
>>
>> I got some problems when I was testing Juju High Availability after
>> deploying OpenStack on my physical servers.
>>
>> I used "juju ensure-availability" to generate 3 state servers. Juju
>> became unnormal after the bootstrap node was shutdown.
>>
>> When the bootstrap node was gone, the whole juju tasks seemed not
>> switched to another state server successfully. I found agent-states of all
>> services became "lost", workload-state of all services become unknown or
>> error.
>>
>> I used "juju debug-log" to check the juju working status, a lot of
>> messages passed by, they looked like there were many communications between
>> services and the state server.
>>
>> I tried to wait for a while, I found that agent-states of services became
>> idle again. But they will become lost again later. Then I try to wait for
>> more a long time(more than 1 hour), I found the agent-state of all services
>> were change from lost to executing, then to idle, then to lost finally.
>>
>> No matter how long I waited, I always found the same result I mentioned
>> above. Then I could use juju commands normally.
>>
>> Did anyone get the same problem? I will be really appreciated if someone
>> can tell me how to solve this issue.
>>
>> Thanks in advanced.
>>
>> Sincerely yours,
>> Leon
>>
>> --
>> 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 feature for 1.26 (master), $(JUJU_HOME)/aliases

[roger peppe]

On 23 October 2015 at 05:12, Tim Penhey  wrote:
> Hi folks,
>
> I scratched a personal itch yesterday and added the ability for users to
> specify their own aliases for juju commands.
>
> There are two primary use cases that I was trying to address.
>
> Firstly, the ability to specify default flags for commands:
>   status = status --format=tabular

This sounds useful, thanks. Presumably additional arguments are
just tacked onto the end?

> I could never remember the right environment variable to set to get
> tabular by default.
>
> The second was to allow quicker iteration around playing with new CLI
> structure.  As most people are aware, the 2.0 CLI is going to be
> somewhat different to the current one, and I thought it would be good to
> provide a way in which we could "test drive" the new CLI with the
> existing codebase without having to actually code anything.

Unless the new CLI is non-hierarchical I'm thinking that may
not work unless you can specify multi-level aliases;
For example:

model destroy = environment destroy

which might be a little harder.

While I'm on the subject of hierarchical CLIs, I often have difficulty
remembering where a given command is buried. "juju commands | grep"
was often a decent solution but doesn't work when the command
I'm looking for is buried two levels deep. Any chance of something like
"juju commands --all" to show all commands, even those two or more
levels down?

  cheers,
rog.

>
> The aliases files lives in JUJU_HOME, and is a simple text file. Each
> non blank line that doesn't start with a '#' is considered to be an
> alias. The format is expected to be:
>
>  =  [...]
>
> So we can do things like:
>
> # stat is like two whole letters shorter...
> stat = status --format=tabular
>
> # list tests
> list-environments = system environments
> list-users = user list
>
> and so on.
>
> 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

New feature in 1.25.0: Payload Management!

[Katherine Cox-Buday]

Hey All,

Moonstone have been working hard this cycle on delivering a way to manage 
payloads from within a Juju Charm, and providing a nice way to expose 
information about the payloads through the Juju client. We got off course for a 
bit there, but with the help of Mark and some others, we're very happy to 
announce that this work has landed in v1.25.0 (now in proposed)!

Throughout work on this feature, we've worked very closely with our amazing 
Ecosystems team, and we're happy to point you all to a blog post[1] Chuck 
(lazypower) put together demonstrating a charm he's written utilizing payload 
management (as well as our awesome new reactive charming!). The payload 
management stuff starts @ 3:40 in Chuck's video[2], but it's only 6 minutes 
long, so go ahead and watch the entire thing :)

Enjoy, and let me know if you have any questions!

-
Katherine

[1] http://blog.dasroot.net/2015-charming-2-point-oh.html
[2] https://youtu.be/aRQcERLnbIQ?t=221

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

Re: [Blog] - Post Series on Charming 2.0 (reactive, layers, and payloads)

[Rick Harding]

Great stuff! Really shows of some great work.

On Fri, Oct 23, 2015 at 11:43 AM Charles Butler <
charles.but...@canonical.com> wrote:

> Greetings!
>
> As some of you may know, we've been talking quite a bit about the new
> emerging patterns in charming, which covers a few new tools, and a
> framework for writing your charms. There was an overview/walkthrough on
> yesterday's Office Hours, and I've been publishing a blog series covering
> the introduction of the new tooling.
>
> These will eventually be extrapolated into the docs, but this is a great
> first round introduction to charming with layers, in the reactive
> framework, and delivering payloads (containers, vms, warfiles, etc) with
> Juju.
>
> http://blog.dasroot.net/2015-charming-2-point-oh.html
> http://blog.dasroot.net/2015-charming-2-point-oh-pt2.html
>
> Look forward to even more in-depth content on these subjects over the next
> month.
>
> All the best,
>
> Charles
>
>
> Charles Butler  - Juju Charmer
> Come see the future of datacenter orchestration: http://jujucharms.com
> --
> 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