Re: Juju stable 1.25.0 is proposed for release.
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: How to make Juju High Availability work properly?
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: [Blog] - Post Series on Charming 2.0 (reactive, layers, and payloads)
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
Juju stable 1.25.0 is proposed for release.
# 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 information run: juju help payloads
Re: UOS Sessions, anyone?
That's great, Samuel! If anyone can help with them, I can help you schedule the session :) -- José Antonio Rey On Fri, Oct 23, 2015, 10:23 Samuel Cozannet wrote: > 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
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
[Blog] - Post Series on Charming 2.0 (reactive, layers, and payloads)
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
[Review Queue] kibana, ibm java sdk, jenkins-bundle
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
Re: UOS Sessions, anyone?
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
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?
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
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
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: 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
UOS Sessions, anyone?
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