Re: Blog post about expanding Ceph clusters with Juju
That's a great walkthrough. Thanks for sharing it - and including plenty of links! On 9 May 2018 at 10:37, Sandor Zeestraten wrote: > Hey Juju folks, I wrote up a short blog post about expanding Ceph clusters > with Juju in case anyone is interested and looking to do the same. > > https://zeestrataca.com/posts/expanding-ceph-clusters-with-juju/ > > Cheers > -- > Sandor Zeestraten > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju > > -- Nick Veitch, Documentation Canonical -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: JUJU_UNIT_NAME no longer set in env
On 23 May 2017 at 14:12, Jay Wren wrote: > I was under the impression that `juju run --unit` does run in a hook > context. In fact, the help for `juju help run` explicitly says: > ah yes, sorry, I missed the --unit bit. -- Nick Veitch, Documentation Canonical -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: JUJU_UNIT_NAME no longer set in env
On 23 May 2017 at 11:23, Junien Fridrick wrote: > > You can run some hooks like config-changed with e.g. : > > $ juju run --unit foo/0 hooks/config-changed > You can run any hook like that, but if it requires a hook context (as in the example of trying to read $JUJU_UNIT_NAME ) it won't work. A lot of hooks in common charms don't need context, but you can't guarantee that. N.B. Also when using `juju debug-hooks` once any hook fires and you are in the hook environment, you can then execute any hook (not just the one that has been triggered), if you need to test them. -- Nick Veitch, Documentation Canonical -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: JUJU_UNIT_NAME no longer set in env
I don't believe you can (usually) execute hooks properly e.g. via 'juju run' or ssh, precisely because the hook doesn't then run in a hook context. If you run 'juju debug-hooks' and wait for a hook to fire, then the various $ENV variables should be available in that session. https://jujucharms.com/docs/stable/developer-debugging#the-'debug-hooks'-command On 23 May 2017 at 08:56, John Meinel wrote: > > I *think* the hook context actually runs in the directory just above > 'hooks', but I'm not 100% positive. > it does :) -- Nick Veitch, Documentation Canonical -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: kill-controller, unregister, destroy-controller
On 1 September 2016 at 14:59, Mark Ramm-Christensen (Canonical.com) < mark.ramm-christen...@canonical.com> wrote: > I believe keeping the --destroy-all-models flag is helpful in keeping you > from accidentally destroying a controller that is hosting important models > for someone without thinking. > I agree, though actually all that happens is that after a while people type ' juju destroy-controller --destroy-all-models mycontroller' without thinking. Perhaps it would be better to have a confirmation: juju destroy-controller mycontroller This command will also destroy the following models: mymodel, myimportantmodel Proceed (y/n)? -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Bootstrap to a specific series
This is due to an update to streams to support xenial. For now you can do: juju bootstrap --config default-series="trusty" On 21 April 2016 at 16:28, Ney Moura wrote: > Hey guys! > > I'm currently trying do bootstrap my Juju environment using ec2 but, since > today =D, I'm not able to do this because apparently there's no Xenial > images on my region (us-east-1) so I thought using trusty series to solve > the problem! But is that possible? How do I do? > > Thanks in advice! > > -- > *Ney Moura Conceição* > > -- > 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
Re: Charm execution graph in docs
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
Re: Getting started?
Hi Ramsey, Sorry you haven't had a good start. With your setup and needs, I would follow the documentation at https://jujucharms.com/docs/stable/getting-started Install Juju as described and then set up for a local environment with the instructions here: https://jujucharms.com/docs/stable/config-LXC note in particular: https://jujucharms.com/docs/stable/config-LXC#bootstrapping-and-destroying If you want to add more nodes to your environment in future, you can do that by using MAAS to control all your nodes(http://maas.io), and Juju to control MAAS. It is also worth pointing out that the upcoming Juju 2.0 release has much better local provider support as it uses LXD, and if you are just experimenting, it may be better for you to try that! There are details on installing the Juju 2.0 alpha here: https://jujucharms.com/docs/1.25/reference-releases#development and configuration for LXD is here: https://jujucharms.com/docs/devel/config-LXD Let me know if you have any more problems Nick On 16 February 2016 at 04:49, Ramsey Gurley wrote: > Hi all, > > I'm trying > > https://jujucharms.com/get-started > > and failing hard. I get juju installed at step one, but when I paste the > command from step 3, I finish with > > juju-quickstart: error: cannot retrieve the environment type: upgrade in > progress - Juju functionality is limited > > Above that I see the warning: > > 21:35:03 WARNING app:201 cannot retrieve the API address: cannot connect > to any of the following addresses: localhost:17070, 10.0.3.1:17070, > 172.17.0.1:17070, 192.168.11.115:17070 > > I am now noticing > > https://jujucharms.com/docs/stable/getting-started > > Looks like considerably different instructions. So maybe I should just ask > where to start? > > I have an Intel NUC i7 with 16GB of RAM and it is running Ubuntu 15.10. > I'd like to install juju locally on this machine and possibly add new nodes > (more NUCs) later. Is there a good place for me to start with that in mind? > > Thank you, > > Ramsey > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > -- Nick Veitch, CDO Documentation nick.vei...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju devel 2.0-alpha2 is available for testing
atically > updates its definitions when the controller starts, so forcing a restart > of the controller is a workaround. > > > ### Juju Logging Improvements > > Logs from Juju's machine and unit agents are now streamed to the Juju > controllers over the Juju API in preference to using rsyslogd. This is > more robust and is a requirement now that multi-model support is enabled > by default. Additionally, the centralised logs are now stored in Juju's > database instead of the all-machines.log file. This improves log query > flexibility and performance as well as opening up the possibility of > structured log output in future Juju releases. > > Logging to rsyslogd is currently still in place with logs being sent > both to rsyslogd and Juju's DB. Logging to rsyslogd will be removed > before the final Juju 2.0 release. > > The 'juju debug-log' command will continue to function as before and > should be used as the default way of accessing Juju's logs. > > This change does not affect the per machine (machine-N.log) and per unit > (unit-*-N.log) log files that exist on each Juju managed host. These > continue to function as they did before. > > A new 'juju-dumplogs' tool is also now available. This can be run on > Juju controllers to extract the logs from Juju's database even when the > Juju server isn't available. It is intended to be used as a last resort > in emergency situations. 'juju-dumplogs' will be available on the system > $PATH and requires no command line options in typical usage. > > > ### API Login with Macaroons > > Juju 2.0 supports an alternate API long method based on macaroons. This > will support the new charm publishing workflow coming future releases > > > ### Unit Agent Improvements > > We've made improvements to worker lifecycle management in the unit agent > in this release. The resource dependencies (API connections, locks, > etc.) shared among concurrent workers that comprise the agent are now > well-defined, modeled and coordinated by an engine, in a design inspired > by Erlang supervisor trees. > > This improves the long-term testability of the unit agent, and should > improve the agent's resilience to failure. This work also allows hook > contexts to execute concurrently, which supports features in development > targeting 2.0. > > > ### Juju Status Improvements > > The default Juju status format is now tabular (not yaml). Yaml can still > be output by using the '--format yaml' arguments. The deprecated agent- > state and associated yaml attributes are now deleted (these have been > replaced since 1.24 by agent status and workload status attributes). > > The tabular status output now also includes relation information. This > was previously only shown in the yaml and json output formats. > > > ### Relation get-config And set-config Compatibility > > See https://bugs.launchpad.net/juju-core/+bug/1382274 > > If 'juju get-config' is used to save YAML output to a file, the same > file can now be used as input to 'juju set-config'. The functions are > now reciprocal such that the output of one can be used as the input of > the other with no changes required, so that: > 1. complex configuration data containing multiple levels of quotes can > be modified via YAML without needing to be escaped on shell command > lines, and > 2. large amounts of config data can be transported from one juju model > to another in a trivial fashion. > > > ### Known issues > * GUI and Landscape don’t work with this alpha 2 release > As we transition to using the new "controller" and "model" related > terminology, and remove deprecated APIs, for this release only > downstream products like the GUI, Landscape (and anything else using > the Python Juju Client) will not work. Please continue to use the > alpha 1 release found in ppa:juju/experimental. > > * Some providers release wrong resources when destroying hosted models > Lp 1536792 > > * Destroying a hosted model in the local provider leaves the > controller unusable > Lp 1534636 > > * Unable to create hosted environments with MAAS provider > Lp 1535165 > > > ## Resolved issues > > * Agent install dies randomly on azure > Lp 1533275 > > * Unable to create hosted models with maas provider > Lp 1535165 > > * Jujud offers poodle vulnerable sslv3 on 17070 > Lp 1536269 > > * Fslock staleness checks are broken > Lp 1536378 > > * Get and set are not reciprocal > Lp 1382274 > > * Provider/maas: data races > Lp 1497802 > > * Destroyed leader, new leader not elected. > Lp 1511659 > > * Bootstrap node does not use the proxy to fetch tools from > streams.c.c > Lp 1515289 > > * Metadata worker repeatedly errors on new azure > Lp 1533896 > > * Status format should default to tabular in 2.0 > Lp 1537717 > > * Juju deploy silently ignores most cli flags > Lp 1540701 > > * Provider/maas: race in launchpad.net/gomaasapi > Lp 1468972 > > > Finally > > We encourage everyone to subscribe the mailing list at > juju-...@lists.canonical.com, or join us on #juju-dev on freenode. > > > -- > Curtis Hovey > Canonical Cloud Development and Operations > http://launchpad.net/~sinzui > > -- > Juju-dev mailing list > juju-...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > -- Nick Veitch, Documentation nick.vei...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju configuration in bash
Hi, There is a config-get hook tool which does the same job ( https://jujucharms.com/docs/stable/authors-hook-environment#config-get) Actually, that whole page is a good read because there is a lot of info about the hook environment and other hooks tools there. hth On 3 October 2015 at 00:32, Frederico Araujo wrote: > Hi list, > > Is there a way to get the configuration options from config.yaml from a > hook written in Bash (e.g., environment variable)? I noticed that in Python > we can import from the charmshelper API like this: > >1. from charmhelpers.core.hookenv import ( >2. config as config_get, >3. ... > > > And then use config_get['option'] to retrieve the option value. > > Thanks, > > Fred > > > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > > -- Nick Veitch nick.vei...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju on CloudStack
Unless anyone knows of any secret switches for the Amazon provider, I think manual provider is the easier option, though you do miss out on some of the joys of Juju that way. https://jujucharms.com/docs/stable/config-manual But don't let me dissuade you from writing a CloudStack provider! You might want to look at the DigitalOcean provider plugin, which uses the manual provider: https://github.com/kapilt/juju-digitalocean On 18 September 2015 at 16:55, Herman Bergwerf wrote: > Ok, I suspected that. But I don't think it is already enabled so I'll have > to contact my hosting company to ask if they can enable it (I think it's > this: > http://cloudstack-installation.readthedocs.org/en/latest/optional_installation.html#enabling-the-ec2-and-s3-compatible-interface > ) > Also, the docs (https://jujucharms.com/docs/stable/config-aws) do not > mention a way to use another ec2 endpoint in the current version of juju. I > read some stuff about specifying another ec2 endpoint for cloudstack but it > was all pretty old (2013 or something, I think juju was still in python > back then) > > Alternatively I could write a set of shell scripts to make it work with > manual provisioning. Or maybe I can compile my own version of juju and > write a cloudstack provider? ( > https://github.com/juju/juju/tree/8da94246468a4da71e62894f7a8a1bbbce112697/provider/ec2, > it seems like a provider implementation is pretty extensive in juju, cloud > drivers in salt seemed more straightforward) > > Op vr 18 sep. 2015 om 17:44 schreef José Antonio Rey : > >> CloudStack as CloudStack is not supported. However, Jorge mentions that, >> if he recalls correctly, it works like if it was EC2. So he's suggesting >> setting CloudStack as an amazon or ec2 environment, even though it's >> CloudStack, because it may work this way. It's a workaround since we >> don't have official direct CloudStack support. >> >> >> On 09/18/2015 10:40 AM, Herman Bergwerf wrote: >> > Im not sure what you mean but I don't think I have access to the >> > cloudstack configuration (the interface is provided by the hosting >> > company I'm with) >> > Also, would that mean I can maybe already use the ec2 driver in juju by >> > pointing it to the cloudstack endpoint from my hosting provider? Because >> > the docs are not really clear about this... >> > >> > >> > On Fri, Sep 18, 2015, 17:21 Jorge O. Castro > > <mailto:jo...@ubuntu.com>> wrote: >> > >> > On Thu, Sep 17, 2015 at 9:47 AM, Herman Bergwerf >> > mailto:hermanbergw...@gmail.com>> wrote: >> > > (how) can I run Juju on CloudStack? >> > >> > It's my understanding that CloudStack emulates an EC2 environment's >> > APIs, have you tried configuring it as an EC2 environment? >> > >> > >> > >> >> -- >> José Antonio Rey >> > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > > -- Nick Veitch nick.vei...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju on CloudStack
I don't believe that will work - the amazon provider naturally talks to *Amazon's* EC2 - I don't know of an easy way to redirect it to a different service (there is no equivalent auth-url setting for the amazon provider AFAIK) On 18 September 2015 at 16:44, José Antonio Rey wrote: > CloudStack as CloudStack is not supported. However, Jorge mentions that, > if he recalls correctly, it works like if it was EC2. So he's suggesting > setting CloudStack as an amazon or ec2 environment, even though it's > CloudStack, because it may work this way. It's a workaround since we don't > have official direct CloudStack support. > > > On 09/18/2015 10:40 AM, Herman Bergwerf wrote: > >> Im not sure what you mean but I don't think I have access to the >> cloudstack configuration (the interface is provided by the hosting >> company I'm with) >> Also, would that mean I can maybe already use the ec2 driver in juju by >> pointing it to the cloudstack endpoint from my hosting provider? Because >> the docs are not really clear about this... >> >> >> On Fri, Sep 18, 2015, 17:21 Jorge O. Castro > <mailto:jo...@ubuntu.com>> wrote: >> >> On Thu, Sep 17, 2015 at 9:47 AM, Herman Bergwerf >> mailto:hermanbergw...@gmail.com>> wrote: >> > (how) can I run Juju on CloudStack? >> >> It's my understanding that CloudStack emulates an EC2 environment's >> APIs, have you tried configuring it as an EC2 environment? >> >> >> >> > -- > José Antonio Rey > > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > -- Nick Veitch nick.vei...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Pushing to Launchpad
Let us know if that was the problem! I will take a pass through the docs and see if there is anything we should add/clarify on that page On 20 August 2015 at 18:58, Tom Barber wrote: > Thanks Nick, Marco > > I've joined the team I'll give it a try. > > Tom > On 20 Aug 2015 18:55, "Marco Ceppi" wrote: > >> This is a launchpad error, not a bazaar one. I believe you will need to >> first be a member of https://launchpad.net/~charm-contributors in order >> to create new "packages" in launchpad. >> >> Thanks, >> Marco Ceppi >> >> On Thu, Aug 20, 2015 at 1:41 PM Nick Veitch >> wrote: >> >>> Hi >>> >>> >>> >>>> I followed the instructions on the juju charm page to submit my charm >>>> to my namespace but all I get is >>>> >>>> bzr: ERROR: Invalid url supplied to transport: >>>> "lp:~f-tom-n/charms/trusty/saikuanalytics/trunk": No such source package >>>> saikuanalytics. >>>> >>> >>> >>> are you running: >>> >>> bzr push lp:~f-tom-n/charms/trusty/saikuanalytics/trunk >>> >>> ? >>> >>> You should run `bzr init` in the root of the charm itself - in your case >>> 'charms/trusty/saikuanalytics' >>> >>> >>> >>> Nick >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >> -- Nick Veitch nick.vei...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Pushing to Launchpad
Hi > I followed the instructions on the juju charm page to submit my charm to > my namespace but all I get is > > bzr: ERROR: Invalid url supplied to transport: > "lp:~f-tom-n/charms/trusty/saikuanalytics/trunk": No such source package > saikuanalytics. > are you running: bzr push lp:~f-tom-n/charms/trusty/saikuanalytics/trunk ? You should run `bzr init` in the root of the charm itself - in your case 'charms/trusty/saikuanalytics' Nick -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Messaging to new users
I don't think it is a docs thing. The https://jujucharms.com/get-started page doesn't even mention MAAS, the test runthrough is provider-agnostic and the install page only mentions MAAS alongside a number of other cloud providers. I think the culprit may be google - historically there were a lot of blogs and youtube videos about MAAS and Juju and the two come up quite prominently even if you just search for things like "juju test " or "juju install" That said, if we should steer newcomers to a particular first-time experience, that can be easily done. On 2 July 2015 at 11:21, Mario Splivalo wrote: > Hi, Jose! > > Probably there should be a 'introduction to maas' or 'maas by example' > which would help new users to get started with new MAAS cluster in KVM > virtual machines - I'm assuming not a lot of newcomers have several > bare-metal boxes lying around just to play with MAAS. > > There is a very good blog from Chris Arges that explains how one could > start with MAAS in KVM - it even explains how to connect juju to that MAAS: > > > http://dinosaursareforever.blogspot.co.uk/2014/06/manually-deploying-openstack-with.html > > The blog talks about OpenStack but it starts with creating VMs, > installing MAAS on one of them, configuring it, enlisting other VMs, > etc, etc... > > Mario > > On 07/02/2015 05:13 AM, José Antonio Rey wrote: > > Unfortunately there is no easy way. Even though the docs are quite clear > > people are always looking to have a bit of human interaction. Hence, the > > questions on IRC. I think it's just a matter of us being humans and > > trying to reach another human. As I mentioned, the docs are quite clear > > and understandable. > > > > -- > > José Antonio Rey > > > > > > On Wed, Jul 1, 2015, 20:54 Tim Penhey > <mailto:tim.pen...@canonical.com>> wrote: > > > > I have been wondering for a while how we message to new users. > > > > I raise this because I see quite a few messages on stack overflow > that > > go something like this: > > > >"I'm really new to Juju and I'm trying to set up MaaS." > > > > I feel that if we are getting to this, we are doing something wrong. > > Perhaps we should have better docs around initial evaluation testing? > > How do we direct people more to the local provider and manual > > provisioning on existing hardware over setting up their own MaaS to > try > > Juju? > > > > Tim > > > > -- > > Juju mailing list > > Juju@lists.ubuntu.com <mailto: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 > -- Nick Veitch nick.vei...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju Documentation - what can we improve?
> > For instance, for the > relation hooks, there is no reference - what hooks are there, what can I > pass to them, what will they return, etc, etc https://jujucharms.com/docs/stable/authors-charm-hooks > (For instance, what > are the options that I can pass to 'juju-log' - the documentation states > that one can pass --debug, but in fact there are several log levels that > one can utilize). > https://jujucharms.com/docs/stable/commands#debug-log > > Also reference for juju leader election, still experimental in last week's release. It would be nice to have in dev docs though > then juju actions would be of > immense help. > https://jujucharms.com/docs/stable/actions https://jujucharms.com/docs/stable/authors-charm-actions There are plenty of things we can do to improve docs! Here is a list of 68 of them: https://github.com/juju/docs/issues All contributions happily accepted! Nick -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: What's the future of Juju?
Hi, Thanks for the useful feedback on docs! I agree that good examples for Python and the charm helpers are things that are sorely missing, and we will address that soon. I don't want to burden you further, but would you mind if I emailed you some questions about your experience with the documentation? I don't like to pass up the opportunity to talk to real users! In the meantime if you have any more suggestions for docs, please feel free to email me or you can report specific issues on the docs repository (https://github.com/juju/docs/issues). -- Nick Veitch, Documentation Team nick.vei...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: State of the "Best Practices Guide"
Hi, I should clarify that the tips on this page are for charm authors - i.e. writing charms. If you have any tips for using Juju, we'd be happy to hear those too though! On 2 March 2015 at 16:30, Jorge O. Castro wrote: > Hi everyone, > > We have a best practices guide in the docs, initially it was a brain dump of > what Canonical IS was doing with Juju: > > https://jujucharms.com/docs/authors-charm-best-practice > > However if you look at the history of the page it hasn't been touched in a > long time, and there are tons of new tips and tricks that we have neglected > to put on this page. In many cases we've just added the tip to the > corresponding page in the docs, so the question becomes, do any of you have > any tips/tricks that can help this page be more useful to users? > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > -- Nick Veitch nick.vei...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Screenshots in charm READMEs (policy request)
I like the idea in general. We may want to be careful as to allowed domains though, (I think imgur generates specific urls per image, so they can't be swapped out, but not all sites do) which may increase the overhead on implementing it. I think you would definitely need to add some text specifying that the images must be their own! On Mon, Feb 2, 2015 at 12:16 PM, Jorge O. Castro wrote: > Hi everyone, > > Rick H. mentioned to me that if a charm has a Markdown image snippet, like > say: > >  > > ... then jujucharms.com will render the screenshot. > > Clearly this is a nice easy way to allow charm authors to add > screenshots to their charm in the store, however, since we're serving > the entire charm store over https the image URLs need to be served > over https, so I would like to add the following to charm store > policy: > > "You can add screenshots to your readme using standard markdown > format(link), however in order to be rendered in the store, the images > must be served over https", > > We recommend something like imgur that has https and a CDN that makes > it dead easy for people to host images. Over time Rick plans to enable > us to host images and do fancier things, but the intent of this is > just to allow images for people with little effort on the backend > engineering. > > Thoughts? > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju -- Nick Veitch nick.vei...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Lets version lock the docs!
I agree that we wish to update old versions. It isn't so much work if: 1. We remain reasonably consistent, so merges can easily be done across multiple branches. Therefore, keep your merges small and limited to single files where possible - if you have more to update, do it in different branches. I will add something like this to the contributor guide. 2. We don't try and support a ridiculous number of versions, just the ones people may/should be using. E.g. I don't see why we would have more than one version of the 1.20 series. We may wish to retire some versions at some point also. As an additional note, I think there are better things we can do with the file structure to avoid duplication and issues with images, and to ensure that the tip version is *not* the default version of the docs you see - the current version should be the default, the master branch should be available to see (labelled as 'dev' or something?) but typically it may include documentation about features not currently landed in a stable version. I will also add a note about versions to the intro page. > > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: new release of jujucharms.com with docs and perf improvements.
José, we do have a plan for translations too. I will mail you when we have a repo set up for it. On Nov 26, 2014 1:13 AM, "José Antonio Rey" wrote: > Question! > > Does this release will be able to support localized docs? If so, I would > love to start working on translating the docs to Spanish. > > On 11/25/2014 08:11 PM, Rick Harding wrote: > > The full blog post is > > here: > http://jujugui.wordpress.com/2014/11/26/jujucharms-com-large-sweeping-update-1/ > > > > The big thing is that we've gotten out first big iteration of the new > > site out the door which includes a number of performance improvements > > and the big thing to note is that the site is now ingesting the Juju > > docs (https://jujucharms.com/docs/). We'll be working with folks to > > update links to the new site. The urls should be consistent just with > > the different domain name. > > > > Currently they auto ingest and update every 15min, like charms/bundles, > > and are rebuilt. We've talked with the docs team about making sure we > > can support their upcoming work towards versioned docs and we'll also be > > working with UX on an experience for the start of a 'global juju search' > > that includes the charm/bundle data as well as docs and any other > > content as we move the new home site of Juju forward. > > > > Please make sure to try it out and file bugs > > at https://github.com/CanonicalLtd/jujucharms.com/issues > > > > > > I want to thank the team for their hard work on this update! > > > > -- > > > > > > Rick Harding > > > > Juju UI Engineering > > https://launchpad.net/~rharding > > @mitechie > > > > > > -- > 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: Adding docs about HA logging
Hi Michael, thanks for taking the time to think about adding to the docs. If you ever have something you want to add but don't know where it goes, just ask me! HA isn't in the published docs yet because it isn't in a stable release, which is why we currently have a dev branch as Curtis mentioned. For new features, there often isn't an existing page where they would naturally go, which means we need to create a new page and link it somewhere appropriate. If that seems like too much work you can either: * just email me the stuff you want to add OR * Add it to a bug, either on LP or as an issue at github https://github.com/juju/docs/issues?state=open Thanks! On Thu, May 15, 2014 at 2:08 PM, Curtis Hovey-Canonical wrote: > On Thu, May 15, 2014 at 6:37 AM, Michael Foord > wrote: >> I'd like to add a note about logging with HA to the docs (user docs), but it >> isn't clear where to add them. >> >> I could add them as a note on the "commands" page, but it would be the only >> note (command documentation is "sparse") or create a new doc. Any better >> suggestions? > > We are adding devel features into the devel branch. > https://github.com/juju/docs/tree/dev > > When we release 1.20, we will merge devel into stable. > > I have a task for every new and notable section in the release notes. > When I write the release notes for 1.20.0 from the the 1.19.x release > notes, I will also update the docs to ensure 1.20.0 docs are released > the same day as the packages. > > > -- > Curtis Hovey > Canonical Cloud Development and Operations > http://launchpad.net/~sinzui > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju -- Nick Veitch nick.vei...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju Academy
Nate, thanks for reminding me, juju help commands is also wrong! https://bugs.launchpad.net/juju-core/+bug/1299120 On Wed, May 7, 2014 at 7:27 PM, Nate Finch wrote: > Actually, init is the main command, generate-config is an alias for init > (see juju help commands). > > > On Wed, May 7, 2014 at 1:55 PM, Nick Veitch > wrote: >> >> Nice work, when it is ready we can add it to the getting started >> section of the docs too. >> >> Small point - 'juju generate-config', not 'juju init', you may await my PR >> >> On Wed, May 7, 2014 at 6:24 PM, Gustavo Niemeyer >> wrote: >> > This is _extremely_ cool, Marco. Very well done! >> > >> > One tiny suggestion, for anyone interested in contributing: it would >> > be great to have "ls [-la]" at some point. That's the first thing most >> > people will type when seeing a prompt, and gives them room for >> > navigating to the juju configuration directory. >> > >> > On Wed, May 7, 2014 at 1:16 PM, Marco Ceppi wrote: >> >> Hi everyone! >> >> >> >> I was trying to keep this under wraps as I worked on it more before >> >> announcing to the world but I'm too excited with the progress so far so >> >> here's the "SUPER ALPHA BETA OMEGA" introduction to Juju Academy. >> >> >> >> I started this, http://juju.academy (http://learnjuju.com) based on my >> >> own >> >> experiences when trying new software. Primarily modeled after the Learn >> >> Go >> >> Lang webiste (http://tour.golang.org/) I set out to create an easy >> >> platform >> >> that emulates a terminal environment and allows a user to try Juju >> >> before >> >> ever having to install it. In addition I wanted to make a lightweight >> >> lesson >> >> framework to help guide new users in this exciting new Service >> >> Orchestration >> >> paradigm. Finally, the last goal of this project was to build an easy >> >> to >> >> embed module that could live in the docs to provide very lightweight >> >> terminal sessions that users could use to review what portions of the >> >> docs >> >> they were reading. >> >> >> >> Right now I've modeled just a hand full of lessons and only a few of >> >> the >> >> juju commands have actually been implemented. As this is a spare time >> >> project progress comes in chunks of time over the weekend and in the >> >> evenings. However, if you're interested in piloting the demoware and >> >> shaking >> >> out bugs please do so! You can view the lessons at http://juju.academy >> >> the >> >> source code is https://github.com/marcoceppi/juju-academy and the issue >> >> tracker is on that repo. >> >> >> >> Your juju environment(s) persist not only between lessons but also >> >> between >> >> page visits. If at anytime you wish to start anew you can do so by >> >> issuing >> >> the "reset" command in the terminal. I'm working on finishing >> >> http://help.juju.academy which will have this and other FAQ/Guide like >> >> questions to use the software. All Juju help can be found, as always, >> >> at >> >> https://juju.ubuntu.com/docs >> >> >> >> This is also a call for help! Anyone interested in writing lessons, >> >> command >> >> modules, fixing bugs, making this look nicer, etc - pull requests are >> >> welcome! The entire project aims to be modular (in that this framework >> >> could >> >> be used for non juju terminal lessons). Lessons are simply JSONP files >> >> that >> >> contain a set number of keys and commands are functions that perform >> >> some >> >> rudimentary validation. >> >> >> >> I eagerly await feedback and have had an immense amount of fun working >> >> on >> >> this so far! I'll likely follow up with a more official announcement >> >> when >> >> more of the commands have been implemented. >> >> >> >> Thanks, >> >> Marco Ceppi >> >> >> >> -- >> >> Juju mailing list >> >> Juju@lists.ubuntu.com >> >> Modify settings or unsubscribe at: >> >> https://lists.ubuntu.com/mailman/listinfo/juju >> >> >> > >> > >> > >> > -- >> > >> > gustavo @ http://niemeyer.net >> > >> > -- >> > Juju mailing list >> > Juju@lists.ubuntu.com >> > Modify settings or unsubscribe at: >> > https://lists.ubuntu.com/mailman/listinfo/juju >> >> >> >> -- >> Nick Veitch >> nick.vei...@canonical.com >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju > > -- Nick Veitch nick.vei...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju Academy
Nice work, when it is ready we can add it to the getting started section of the docs too. Small point - 'juju generate-config', not 'juju init', you may await my PR On Wed, May 7, 2014 at 6:24 PM, Gustavo Niemeyer wrote: > This is _extremely_ cool, Marco. Very well done! > > One tiny suggestion, for anyone interested in contributing: it would > be great to have "ls [-la]" at some point. That's the first thing most > people will type when seeing a prompt, and gives them room for > navigating to the juju configuration directory. > > On Wed, May 7, 2014 at 1:16 PM, Marco Ceppi wrote: >> Hi everyone! >> >> I was trying to keep this under wraps as I worked on it more before >> announcing to the world but I'm too excited with the progress so far so >> here's the "SUPER ALPHA BETA OMEGA" introduction to Juju Academy. >> >> I started this, http://juju.academy (http://learnjuju.com) based on my own >> experiences when trying new software. Primarily modeled after the Learn Go >> Lang webiste (http://tour.golang.org/) I set out to create an easy platform >> that emulates a terminal environment and allows a user to try Juju before >> ever having to install it. In addition I wanted to make a lightweight lesson >> framework to help guide new users in this exciting new Service Orchestration >> paradigm. Finally, the last goal of this project was to build an easy to >> embed module that could live in the docs to provide very lightweight >> terminal sessions that users could use to review what portions of the docs >> they were reading. >> >> Right now I've modeled just a hand full of lessons and only a few of the >> juju commands have actually been implemented. As this is a spare time >> project progress comes in chunks of time over the weekend and in the >> evenings. However, if you're interested in piloting the demoware and shaking >> out bugs please do so! You can view the lessons at http://juju.academy the >> source code is https://github.com/marcoceppi/juju-academy and the issue >> tracker is on that repo. >> >> Your juju environment(s) persist not only between lessons but also between >> page visits. If at anytime you wish to start anew you can do so by issuing >> the "reset" command in the terminal. I'm working on finishing >> http://help.juju.academy which will have this and other FAQ/Guide like >> questions to use the software. All Juju help can be found, as always, at >> https://juju.ubuntu.com/docs >> >> This is also a call for help! Anyone interested in writing lessons, command >> modules, fixing bugs, making this look nicer, etc - pull requests are >> welcome! The entire project aims to be modular (in that this framework could >> be used for non juju terminal lessons). Lessons are simply JSONP files that >> contain a set number of keys and commands are functions that perform some >> rudimentary validation. >> >> I eagerly await feedback and have had an immense amount of fun working on >> this so far! I'll likely follow up with a more official announcement when >> more of the commands have been implemented. >> >> Thanks, >> Marco Ceppi >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> > > > > -- > > gustavo @ http://niemeyer.net > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju -- Nick Veitch nick.vei...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: juju manual bootstrap - does it work?
;>>>> >>>>> $ juju switch manual >>>>> >>>>> then >>>>> >>>>> $ juju bootstrap >>>>> >>>>> Juju appears to connect to the Server ok but I keep getting asked for a >>>>> password?? >>>> >>>> >>>> Would you mind doing this again with "--debug" and replying with the >>>> output? >>> >>> >>> bmullan@brians-juju:~$ juju bootstrap --debug >>> >>> 2014-05-04 11:11:00 INFO juju.cmd supercommand.go:297 running >>> juju-1.18.1-trusty-amd64 [gc] >>> 2014-05-04 11:11:00 DEBUG juju.environs.configstore disk.go:64 Making >>> /home/bmullan/.juju/environments >>> 2014-05-04 11:11:00 INFO juju.environs.manual init.go:139 initialising >>> "173.39.236.162", user "" >>> 2014-05-04 11:11:00 DEBUG juju.utils.ssh ssh.go:234 using OpenSSH ssh >>> client >>> 2014-05-04 11:11:00 DEBUG juju.utils.ssh ssh_openssh.go:122 running: ssh >>> -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" -i >>> /home/bmullan/.juju/ssh/juju_id_rsa -i /home/bmullan/.ssh/id_rsa >>> ubuntu@173.39.236.162 sudo -n true >>> Password: >>> 2014-05-04 11:11:49 INFO juju.environs.manual init.go:150 ubuntu user is >>> already initialised >>> 2014-05-04 11:11:49 INFO juju.provider.manual provider.go:33 initialized >>> ubuntu user >>> 2014-05-04 11:11:50 DEBUG juju.provider.manual environ.go:194 using ssh >>> storage at host "ubuntu@173.39.236.162" dir "/var/lib/juju/storage" >>> 2014-05-04 11:11:50 DEBUG juju.utils.ssh ssh.go:234 using OpenSSH ssh >>> client >>> 2014-05-04 11:11:50 DEBUG juju.utils.ssh ssh_openssh.go:122 running: ssh >>> -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" -i >>> /home/bmullan/.juju/ssh/juju_id_rsa -i /home/bmullan/.ssh/id_rsa >>> ubuntu@173.39.236.162 sudo -n /bin/bash >>> Password: >>> 2014-05-04 11:12:39 DEBUG juju.utils.ssh ssh.go:234 using OpenSSH ssh >>> client >>> 2014-05-04 11:12:39 DEBUG juju.utils.ssh ssh_openssh.go:122 running: ssh >>> -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" -i >>> /home/bmullan/.juju/ssh/juju_id_rsa -i /home/bmullan/.ssh/id_rsa >>> ubuntu@173.39.236.162 bash >>> Password: >>> >>> I enter my password and it will just keep reprompting for "a password"... >>> I'm not sure what password though as there is only one account on both my >>> laptop and on the server. >>> >>> >>> >>>> >>>>> >>>>> The Juju Documentation at: >>>>> https://juju.ubuntu.com/docs/config-manual.html >>>>> says... >>>>> >>>>> The manual provider does not perform automatic machine provisioning >>>>> like other providers; instead, you must manually provision machines into >>>>> the >>>>> environment. Provisioning machines is described in the following sections. >>>>> >>>>> Bootstrapping >>>>> >>>>> To bootstrap a manual environment, you must specify the bootstrap-host >>>>> configuration, and optionally the bootstrap-user configuration. If >>>>> bootstrap-user is not specified, then Juju will ssh to the bootstrap host >>>>> as >>>>> the current user. Once the configuration is specified, you bootstrap as >>>>> usual: >>>>> >>>>> juju bootstrap >>>>> >>>>> The juju bootstrap command will connect to bootstrap-host via SSH, and >>>>> copy across and install the Juju agent. >>>>> >>>>> When bootstrapping, Juju will create the "ubuntu" user if it does not >>>>> already exist. To eliminate the need for repeated password prompts, Juju >>>>> will configure password-less ssh and sudo for the ubuntu user. >>>>> >>>>> I've tried with the environments.yaml "bootstrap-user" set to my User >>>>> ID and i have also tried with "bootstrap-user" commented out which as the >>>>> above documentation states "should" default to me as the "current user". >>>>> >>>>> First... Why would the juju bootstrap prompt for a passworrd >>>> >>>> >>>> The only thing that springs to mind is that juju may be attempting to >>>> use an SSH key that is not loaded by the SSH agent. The debug log should >>>> help narrow this down. >>> >>> >>> as I pointed out above locally on my laptop after creating the Key I used >>> - ssh-add >>> >>>> >>>>> Second... What password can this be?? Its not mine on either system >>>>> and I also tried just "ubuntu" in case but neither is accepted. >>>>> >>>>> Both Ubuntu systems, my lapttop and the server, have had sudo apt-get >>>>> update && sudo apt-get upgrade so they both should have had all latest >>>>> package updates. >>>>> >>>>> Anyone got any ideas? >>>>> >>>>> Does juju manual bootstrap work in 14.04? >>>> >>>> >>>> It works well for me, and there is automated testing in place for the >>>> manual provider. >>>> >>>>> thanks in advance >>>>> >>>>> Brian >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 > -- Nick Veitch nick.vei...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Release Notes
Just a quick, erm, note to let you know that release notes for stable versions are now on the docs page, so you can easily find out which version your favourite features were added in, wallow in the nostalgia of the 1.14.x series or appreciate the minimalism of 1.16.1. https://juju.ubuntu.com/docs/reference-release-notes.html The notes use a cunning twisty thing so you only need see the version you are interested in. P.S. Grammatical foibles have been preserved in the interests of historical accuracy. Nick -- Nick Veitch -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
1.18 docs
Denizens of the Jujusphere! With the 1.18 release of Juju came loads of new features, and thanks to some outstanding teamwork we managed to document pretty much everything already! So, if you want to: * Configure proxies for your environment - https://juju.ubuntu.com/docs/howto-proxies.html * Manage your SSH keys - https://juju.ubuntu.com/docs/howto-authorised-keys.html * Backup and restore your bootstrap environment - https://juju.ubuntu.com/docs/howto-backup-restore.html * Set up simplestreams for a private cloud - https://juju.ubuntu.com/docs/howto-privatecloud.html or simply update yourself on syntax changes for local provider (https://juju.ubuntu.com/docs/config-LXC.html) or how to dest^h^h^h^h, ahem, remove things (https://juju.ubuntu.com/docs/charms-destroy.html), you should check out the new docs. As always, if there are errors or omissions, ping me or file a bug (https://bugs.launchpad.net/juju-core/+filebug) Nick -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: I WANT YOU, to give me your feedback (Juju docs!)
I feel there needs to be a slight (big) addendum to this: 1. There is no specific timetable for this, so people shouldn't be expecting big changes next week or something. 2. It isn't a question of Markdown or stay as it is. If you have strong feelings about RsT or SGML or Mallard or who knows what, I'd like to hear about them too. If there are specific reasons for using a particular format, please mention them. Bear in mind that the primary goal is to give USERS the documentation they want/need. 3. Ideally I would like to move to a position where we could use one source format and set of tools for all docs projects in CDO, but that is a longer term goal. 4. This isn't a democracy. I would be interested to hear what formats people are comfortable with, but if 10 people who have never contributed to the docs before all say DocBook or something, that will have to be slightly balanced by whether we can make an acceptable workflow around that for the people who actually do the majority of the work (i.e. me) and others who make more frequent contributions. The bottom line is, I would like the docs to be easier to contribute to. There are too many features landing that aren't documented and this really needs to change, for everyone's benefit. Nick On Fri, Mar 21, 2014 at 6:45 PM, Curtis Hovey-Canonical wrote: > On Fri, Mar 21, 2014 at 1:47 PM, Marco Ceppi > wrote: >> I'm spreading this email out across the juju-core, juju, and juju-gui list >> to start a discussion about the next format for the docs. Currently, I've >> worked on a proof of concept to converting the docs to Markdown and it's >> going really well. Using python-markdown with a few custom plugins to handle >> the unique user friendly features the docs provide. >> >> However, I wanted to get feedback on the choice of formatting. Markdown has > > +1 > > Caveat that I think we need a post proc to format input examples and > output examples and possibly glossary links. > > Given that 1.18.0 can be out next week. 1.18.0's docs will be written > in the current HTML format so that we can deliver them next week > too...unless you happen to already have tip and unstable docs already > converted to markdown and a post processor ready to go. > > > -- > Curtis Hovey > Canonical Cloud Development and Operations > http://launchpad.net/~sinzui > > -- > 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: Juju command cheat sheet
I like it. I am not sure we want to include charm author stuff in a quickstart page though, or at least, not the same one. On Fri, Jan 31, 2014 at 3:29 PM, Jorge O. Castro wrote: > http://pastebin.ubuntu.com/6849895/ > > I'll find a more accessible place for it. > > On Thu, Jan 30, 2014 at 4:08 PM, Sebastian wrote: >> I cant access the document, even after signing in :( >> >> >> 2014-01-30 Sebastian >> >>> thanks Jorge!! will be really handy! >>> >>> Abs, >>> Sebas. >>> >>> (11) 8572 - 4372 >>> >>> >>> 2014-01-30 Jorge O. Castro >>> Hi everyone, I was giving a class to some people and while they knew how to use Juju I realized they didn't know some commands. So I check out the docs and the CLI help, and while they are thorough, there isn't a "I need to learn Juju in 5 minutes" cheat sheet. So I made one: http://pad.ubuntu.com/juju-cheatsheet I figure we can bang on this for a bit, find out which bits people use/need the most, then maybe evolve this to a newer quickstart page on the docs? Add your favorite tips and tricks! -- Jorge Castro Canonical Ltd. http://juju.ubuntu.com/ - Automate your Cloud Infrastructure -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju >>> >>> >> > > > > -- > Jorge Castro > Canonical Ltd. > http://juju.ubuntu.com/ - Automate your Cloud Infrastructure > > -- > 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: how to create "config-changed" hook
Hi Saurabh, Hooks are rather fundamental to how charms work. If you have defined a relation but have no hooks for it at all then it isn't going to achieve anything. I imagine you would want at least a website-relation-joined hook to pass the host/port details of your website, but I'm not exactly sure what your charm is for. I would recommend taking a look at the walkthrough in the docs (at https://juju.ubuntu.com/docs/authors-charm-writing.html) as this seems like it may be a similar charm. Nick On Wed, Jan 22, 2014 at 2:06 PM, saurabh wrote: > Hi all, > > I have created a charm and am planning to publish it to the charm store. The > problem I am facing is when I do a charm-proof of my charm it says: > > I: relation website has no hooks > I: missing recommended hook config-changed > > I have no idea how to write these hooks. Please guide me through this. > > > Thanks, > Saurabh > > > > -- > 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: Jenkins and Jenkins-slave charms
Hi Steve, I managed to give the Juju hook debugging page a bit of an overhaul. I think there were several key things that were tripping people up: 1. You need to manually execute the hook to get it to run. 2. You need to exit nicely to make Juju carry on with other queued events on that unit. 3. The shell environment is a customised byobu/tmux session. I think all of these are addressed in the docs now, including a sort of quickstart to tmux. The docs page is at https://juju.ubuntu.com/docs/authors-hook-debug.html I have also filed a bug - I think it would be a good idea if the debug-hooks shell started up with a message making the user aware of some of these things: https://bugs.launchpad.net/juju-core/+bug/1270856 As for juju debug-log, I have added a section for that: https://juju.ubuntu.com/docs/authors-hook-debug.html#debuglogcommand The syntax of the command was chosen to mirror that of 'tail', but that isn't well explained in the command help. I have filed a bug for that also: https://bugs.launchpad.net/juju-core/+bug/1270923 I aim to fix it tomorrow but it will be a while before it filters through to a release. I hope the docs examples are helpful enough in the meantime. Do let me know if you have any other issues with docs. It is great to get feedback from real users! Nick On Thu, Jan 9, 2014 at 3:43 PM, Nick Veitch wrote: >> On Jan 9, 2014 7:30 PM, "Mark Shuttleworth" wrote: >>> >>> On 09/01/14 14:36, Steve Powell wrote: >>> > 1) the `debug-log` command is not documented very well: executing it >>> > without parameters tails the log (forever) until ^C’d out. To see the >>> > whole of the log so far execute "juju debug-log -n 1”, and then ^C >>> > out. (“-n 0” is invalid for some reason); >>> >>> Nick, could you review the docs for this piece and make sure they >>> reflect current reality? And perhaps a juju-core person can comment on >>> the -n 0 situation. > > This section is next on my todo list for a refresh - it could > certainly do with more explanation and some worked examples. I think > overhauling it may produce some good recommendations for tweaking the > implementation somewhat to deliver what the user expects/needs. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Jenkins and Jenkins-slave charms
> On Jan 9, 2014 7:30 PM, "Mark Shuttleworth" wrote: >> >> On 09/01/14 14:36, Steve Powell wrote: >> > 1) the `debug-log` command is not documented very well: executing it >> > without parameters tails the log (forever) until ^C’d out. To see the >> > whole of the log so far execute "juju debug-log -n 1”, and then ^C >> > out. (“-n 0” is invalid for some reason); >> >> Nick, could you review the docs for this piece and make sure they >> reflect current reality? And perhaps a juju-core person can comment on >> the -n 0 situation. This section is next on my todo list for a refresh - it could certainly do with more explanation and some worked examples. I think overhauling it may produce some good recommendations for tweaking the implementation somewhat to deliver what the user expects/needs. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Adding two more charm feature bullets
A > foreseeable problem is there is really no documentation on how to implement > or prepare your charm to connect to either of these. Adding them as a > feature, +1, but we need to go one step further to enable charm authors to > easily include these in their charm with documentation and possibly with > charm helpers where appropriate. The monitors interface is on the list of interfaces to be added to the docs. In the meantime I don't really see that as a blocker to policy Nick -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: High Availability command line interface - future plans.
just my tuppence...
Would it not be clearer to add an additional command to implement your
proposal? E.g. "add-manager" and possibly "destroy/remove-manager"
This could also support switches for later fine control, and possibly
be less open to misinterpretation than overloading the add-machine
command?
Nick
On Wed, Nov 6, 2013 at 6:49 PM, roger peppe wrote:
> The current plan is to have a single "juju ensure-ha-state" juju
> command. This would create new state server machines if there are less
> than the required number (currently 3).
>
> Taking that as given, I'm wondering what we should do
> in the future, when users require more than a single
> big On switch for HA.
>
> How does the user:
>
> a) know about the HA machines so the costs of HA are not hidden, and that
> the implications of particular machine failures are clear?
>
> b) fix the system when a machine dies?
>
> c) scale up the system to x thousand nodes?
>
> d) scale down the system?
>
> For a), we could tag a machine in the status as a "state server", and
> hope that the user knows what that means.
>
> For b) the suggestion is that the user notice that a state server machine
> is non-responsive (as marked in status) and runs destroy-machine on it,
> which will notice that it's a state server machine and automatically
> start another one to replace it. Destroy-machine would refuse to work
> on a state server machine that seems to be alive.
>
> For c) we could add a flag to ensure-ha-state suggesting a desired number
> of state-server nodes.
>
> I'm not sure what the suggestion is for d) given that we refuse to
> destroy live state-server machines.
>
> Although ensure-ha-state might be a fine way to turn
> on HA initially I'm not entirely happy with expanding it to cover
> all the above cases. It seems to me like we're going
> to create a leaky abstraction that purports to be magic ("just wave the
> HA wand!") and ends up being limiting, and in some cases confusing
> ("Huh? I asked to destroy that machine and there's another one
> just been created")
>
> I believe that any user that's using HA will need to understand that
> some machines are running state servers, and when things fail, they
> will need to manage those machines individually (for example by calling
> destroy-machine).
>
> I also think that the solution to c) is limiting, because there is
> actually no such thing as a "state server" - we have at least three
> independently scalable juju components (the database servers (mongodb),
> the API servers and the environment managers) with different scaling
> characteristics. I believe that in any sufficiently large environment,
> the user will not want to scale all of those at the same rate. For example
> MongoDB will allow at most 12 members of a replica set, but a caching API
> server could potentially usefully scale up much higher than that. We could
> add more flags to ensure-ha-state (e.g.--state-server-count) but we then
> we'd lack the capability to suggest which might be grouped with which.
>
> PROPOSAL
>
> My suggestion is that we go for a "slightly less magic" approach.
> that provides the user with the tools to manage
> their own high availability set up, adding appropriate automation in time.
>
> I suggest that we let the user know that machines can run as juju server
> nodes, and provide them with the capability to *choose* which machines
> will run as server nodes and which can host units - that is, what *jobs*
> a machine will run.
>
> Here's a possible proposal:
>
> We already have an "add-machine" command. We'd add a "--jobs" flag
> to allow the user to specify the jobs that the new machine(s) will
> run. Initially we might have just two jobs, "manager" and "unit"
> - the machine can either host service units, or it can manage the
> juju environment (including running the state server database),
> or both. In time we could add finer levels of granularity to allow
> separate scalability of juju server components, without losing backwards
> compatibility.
>
> If the new machine is marked as a "manager", it would run a mongo
> replica set peer. This *would* mean that it would be possible to have
> an even number of mongo peers, with the potential for a split vote
> if the nodes were partitioned evenly, and resulting database stasis.
> I don't *think* that would actually be a severe problem in practice.
> We would make juju status point out the potential problem very clearly,
> just as it should point out the potential problem if one of an existing
> odd-sized replica set dies. The potential problems are the same in both
> cases, and are straightforward for even a relatively naive user to avoid.
>
> Thus, juju ensure-ha-state is almost equivalent to:
>
> juju add-machine --jobs manager -n 2
>
> In my view, this command feels less "magic" than ensure-ha-state - the
> runtime implication (e.g. cost) of what's going on are easier for the
> user to understand and it requires no new entities in a user's model of
> the sy
Re: setup tutorial with local provider - never goes beyond pending
Thanks for that, I will add a note to the docs, although I think you may have just been a bit unlucky, my first run through only took a couple of minutes. Nick On Oct 7, 2013 11:21 AM, "Dan Kortschak" wrote: > Thanks Andrew. Yes, leaving it alone for a long time helped - it was > probably still downloading the cloud image the last few times I > destroyed having given up. > > It might be worth adding a note to the docs to the effect that the first > run may take a significant amount of time. > > cheers > Dan > > On Mon, 2013-10-07 at 14:29 +0800, Andrew Wilkins wrote: > > > It may take a while to come up the first time, as the LXC template > > will need to debootstrap. If it never comes up, then > > ~/.juju/local/log/machine-0.log is probably the best bet for > > diagnosis. If you could share that, I'll take a look. In the mean > > time, I'm installing 12.04.03 and juju 1.14.1, and I'll see what I > > get. > > > > > -- > 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: Charm Quality Ratings updates
On Fri, Oct 4, 2013 at 12:28 PM, Mark Shuttleworth wrote: > > I think we'll need the ability both to document the interface in a particular > charm, and to link to other charms > interface docs from inside such documentation. It is easy enough to do that by using Markdown, since we already render that. Do we want it as a separate file? In many ways, it *could* just be part of a well-written README, but then it isn't so obvious where the information actually is. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Charm Quality Ratings updates
The issue which I think kicked this off is that charm authors wishing to build against the interfaces offered by a specific charm have nowhere to go to find out e.g. what is exposed by relation_set for a particular interface, or what those values relate to. We can include best practice guidelines for common interfaces (http say) in the main documentation, but for specific stuff I currently see nowhere, other than trawling through individual hook code, where that information can be obtained (and even then it often isn't explained). It has to go with the charm itself *somewhere*, doesn't it? On Thu, Oct 3, 2013 at 7:21 PM, Gary Poster wrote: > On 10/03/2013 01:50 PM, Mark Shuttleworth wrote: > > > > Are we talking about documentation of the config (lightweight) or > > documentation of the whole interface, for development purposes? > > Ah, thanks. I was obviously speaking of the former, but after > re-reading the start of the thread, it seems Jorge was discussing > documentation of the whole interface. > > I think that whole-interface documentation should be outside of a charm, > because mutiple charms can fulfill a given interface. In that case, > doing what Jorge seemed to be suggesting initially--putting it in the > primary Juju docs--seems the right way within our current doc world. We > don't use YAML for that, so Nate's point is good. > > Gary > > > > > > > On 01/10/13 14:40, Gary Poster wrote: > >> On 09/30/2013 09:47 AM, Nate Finch wrote: > >>> I would recommend not making documentation an attribute in yaml. That > >>> puts strong pressure on writers to make their documentation extremely > >>> short. No one will want to type out a full page of documentation into > a > >>> yaml attribute. Far better to make the documentation into a separate > >>> file, to emphasize that you can write as much as you want (and more > >>> documentation is almost always better). > >> I'm not sure I agree with you here, but AFAIK the discussion is moot > >> unless we want to rejigger most or all of our charms. The config > >> documentation is already in the YAML. > >> > >> Every config element in config.yaml has a description. A majority of > >> them have multi-line descriptions, which describe how to use them. > >> Here's one of bunches of examples. > >> > >> nagios_context: > >> description: | > >> Used by the nrpe-external-master subordinate charm. > >> A string that will be prepended to instance name to set the host > name > >> in nagios. So for instance the hostname would be something like: > >> juju-myservice-0 > >> If you are running multiple environments with the same services in > >> them > >> this allows you to differentiate between them. > >> type: string > >> default: "juju" > >> > >> Gary > >> > >>> > >>> On Mon, Sep 30, 2013 at 9:16 AM, Richard Harding > >>> mailto:rick.hard...@canonical.com>> > wrote: > >>> > >>> Yes, we can do this. We currently support doing markdown rendering > of a > >>> charm's readme in JS. Jorge, how are we looking to have users > document > >>> their interfaces? As a description attribute in the yaml? Could > that be > >>> easy to write out as markdown? > >>> > >>> On Mon, 30 Sep 2013, Mark Shuttleworth wrote: > >>> > >>> > > >>> > Are there good markdown renderers in JS? Should we aim for > interface > >>> > documentation in MD? > >>> > > >>> > On 30/09/13 12:32, Richard Harding wrote: > >>> > > On Wed, 25 Sep 2013, Luca Paulina wrote: > >>> > > > >>> > >> On Wed, Sep 25, 2013 at 3:06 PM, Jorge O. Castro > >>> mailto:jo...@ubuntu.com>> wrote: > >>> > >> > >>> > >>> Hi everyone, > >>> > >>> > >>> > >>> I'd like to revise the charm quality stuff a bit, mostly the > >>> ~charmers > >>> > >>> have captured that we would like to encourage folks to > >>> document the > >>> > >>> interfaces in their charms and I'd like to add that as a > charm > >>> quality > >>> > >>> bullet item. > >>> > >>> > >>> > >>> In the past that just meant getting a +1 from some charmers > and > >>> > >>> editing the docs, but now that we have a GUI I want to make > >>> sure we > >>> > >>> don't add things to the guidelines and not sync up with the > >>> GUI and > >>> > >>> design teams, so what would be the best way for me to drive > that > >>> > >>> forward? > >>> > >> Thanks for the email Jorge, maybe we can find sometime to > >>> discuss it > >>> > >> tomorrow over a hangout. There is a need to revise the copy of > >>> the intro > >>> > >> paragraph as well, we should discuss that at the same time. > >>> > >> > >>> > >> Thanks, > >>> > >> > >>> > >> Luca > >>> > > Did this happen? To answer the first, question, a bit on > >>> charmworld to add > >>> > > the new QA item with the text and section to place it in will > >>> allow us to > >>> > > add it to the QA pr
New Pages in docs!
Or to be more specific, creating them. I have taken on board various feedback about creating new pages, and to make everyone's life a little easier(especially mine), if you want to create new pages in docs you will find new instructions on the contributing page and a new template and build script in the tools directory. In short, the build script will replace all the commented sections of a page with the correct template files, so you don't need to copy and paste stuff or write a document full of the ever-growing headers, footers, scripts and other bits. As you will see from the template file, you don't need anything in those spaces at all, bar the comments themselves. I hope this will make things easier for people with a valuable contribution to make! Onwards, Nick -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Bigger, better, more...
Big thanks to everyone who participated in the Juju Docs virtual mini-sprint on 30th August! 20 outstanding tasks were completed (outstandingly) 7 completely new pages added 12+ participants Across the day we made great progress in a number of areas, adding examples, more explanations and reference material. Among the highlights are: * new HowTo section, with walkthroughs like this: https://juju.ubuntu.com/docs/howto-node.html * documentation for the local provider * a comprehensive (for now) list of constraints * explanation of how/why to group services * better documentation for charm authors on interfaces Extra special thanks to Martin Packman, Nate Finch, Frank Mueller, William Reade and Kapil Thangavelu for some valuable input from core developers. Feel free to also appraise us of any errors or omissions - file a bug report for the docs! https://bugs.launchpad.net/juju-core/docs/ Or you can contribute the old-fashioned but much appreciated way - by writing something: https://juju.ubuntu.com/docs/contributing.html Thanks! Nick -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
