Tagged: juju-core Toggle Comment Threads | Keyboard Shortcuts

  • garyposter 9:20 pm on April 10, 2013 Permalink | Reply
    Tags: juju-core   

    I wonder about visually exposing the “user-” prefix in the Juju core version of the GUI authentication (user-admin). Can’t we hide the prefix within the login method, since it must always be applied?

    Advertisements
     
  • bradcrittenden 8:42 pm on April 8, 2013 Permalink | Reply
    Tags: annoyance, bootstrap, juju-core   

    Hurrah, this tip is now obsolete.  –fake-series is gone and now is implied by –upload-tools.

    tl;dr

    Use ‘juju bootstrap ‑‑fake-series precise ‑‑upload-tools’

    The longer boring version:

    I made some changes to the struct that is returned by an API call but the data being returned was the old version. Nothing worked to ensure I was using the newly built juju. I deleted $GOPATH/bin and $GOPATH/pkg and rebuilt with ‘go build ./… && go install ./…’. At Benji’s suggestion I deleted my S3 control bucket. Nothing worked.

    Turns out I had not used ‘‑‑fake-series precise’ when I bootstrapped. So you should do that. Use ‑‑fake-series whether you think you need to or not.

    Thanks to Roger for helping me to figure it out and get back to real work.

     
  • Francesco 10:42 am on April 4, 2013 Permalink | Reply
    Tags: juju-core,   

    Debugging Juju GUI / juju-core connection 

    The GUI communicates with the juju-core API backend using a secure WebSocket connection. Several operations are performed as the user starts a GUI session:

    • the GUI connects and authenticates to the API server;
    • the GUI subscribes to the juju-core “mega watcher” and starts listening for all state changes;
    • the GUI reacts to those changes (a.k.a. delta stream) updating its internal database;
    • when the user modifies the environment, the GUI makes the corresponding API calls, and waits for responses coming from juju-core.

    Debugging those interactions is not straightforward, but some tools, described below, can simplify the process.

    A precise environment

    juju-core is released more or less every two weeks. Most of the time we need to bootstrap the environment using juju-core trunk, so that we can test the GUI against the newer changes in the API layer, e.g.:

    go install -v launchpad.net/juju-core/...
    $GOPATH/bin/juju bootstrap --upload-tools

    The –upload-tools flag uploads the local juju-core binaries to the environment node. At this point, the best way to set up the GUI and connect it to the bootstrap node is deploying the Juju GUI charm. Here comes the first problem: the Juju GUI charm, at the time of this writing, only works on precise. What if your juju-core development environment is on quantal? The quantal tools are installed in the bootstrap node, but in practice they cannot be reused in other nodes. As a consequence, as far as I know, when starting the agent on the charm machine, juju-core installs the latest precise tools it finds in the cache. If juju-core was recently released this could just work, but often happens that some changes in juju-core trunk break the compatibility between the uploaded quantal tools and the precise ones taken from the cache. In this case, one solution is bootstrapping a precise environment.
    In essence we need to compile and upload tools from precise: there can be many ways to do that, I ended up using a precise LXC container (which can seem convoluted but actually works and is fast enough to set up).

    Create an LXC template in /etc/lxc/local.conf containing the following lines:

    lxc.network.type=veth
    lxc.network.link=lxcbr0
    lxc.network.flags=up

    Create a precise LXC, binding your home directory:

    sudo lxc-create -t ubuntu -n juju-precise -f /etc/lxc/local.conf -- \
    -r precise -a `dpkg-architecture -qDEB_HOST_ARCH` -b $USER

    Start the container:

    sudo lxc-start -n juju-precise -d

    SSH into the container and install some required packages (from now on, all operations are intended to be run inside the LXC container).

    sudo apt-get update && sudo apt-get upgrade
    sudo apt-get install language-pack-en
    sudo apt-get install bzr bzrtools build-essential python-software-properties

    Add the Gophers PPA to package sources:

    sudo apt-add-repository ppa:gophers/go && sudo apt-get update

    Install golang, taking version 1.0.3 from the Gophers PPA

    sudo apt-get install golang-stable

    At this point, since your home directory is shared between the host and the container, you should already have the GOPATH environment variable set up.
    We need to rebuild juju-core from precise, and therefore we need to delete the existing quantal binaries. I guess there are better ways to do this, but this is what I came up with:

    rm -rf $GOPATH/pkg/linux_amd64
    go install -v launchpad.net/juju-core/... launchpad.net/goamz/... \
    launchpad.net/goose/...

    Time to bootstrap the new precise environment, and deploy the Juju GUI charm into it:

    $GOPATH/bin/juju bootstrap --upload-tools
    $GOPATH/bin/juju deploy cs:~juju-gui/precise/juju-gui
    $GOPATH/bin/juju expose juju-gui
    $GOPATH/bin/juju status

    Debugging

    The first step is exposing the GUI branch we want to debug, e.g.:

    $GOPATH/bin/juju set juju-gui juju-gui-source=lp:juju-gui

    The easiest way to check the API logs is to use the debug-log command, recently reintroduced in juju-core (hooray!):

    $GOPATH/bin/juju debug-log

    Trying to log in from the GUI you will see something like:

    domU-12-31-39-0C-24-F7:2013/04/04 09:44:28 DEBUG JUJU:jujud:machine api: <- {"Request": "Login", "Params": {"Password": "passwd", "AuthTag": "user-admin"}, "Type": "Admin", "RequestId": 0}
    domU-12-31-39-0C-24-F7:2013/04/04 09:44:28 DEBUG JUJU:jujud:machine api: -> {"RequestId":0,"Response":{}}

    The debug-log includes delta events. Anyway, you can also use the short Python script in http://pastebin.ubuntu.com/5676102/: it connects to the bootstrap node address (passed as first argument), authenticates to the API server, and subscribes to the mega watcher, printing to stdout (using a more readable formatting) new events as they arrive.

     
    • Francesco 3:26 pm on April 8, 2013 Permalink | Reply

      Update: I have not tried, but a recent juju-core change should allow for deploying a precise charm on an environment bootstrapped from quantal with –upload-tools.

      juju bootstrap –upload-tools –fake-series precise

    • garyposter 3:35 pm on April 9, 2013 Permalink | Reply

      Even if you just want to play around, you’ll want to do the first line of the “Debugging” section in Francesco’s blog post, until we make a go-compatible release.

    • Matthew Scott (Makyo) 4:16 pm on May 2, 2013 Permalink | Reply

      Since testing is unhappy on raring, this might be pertinent again.

  • garyposter 12:31 pm on April 2, 2013 Permalink | Reply
    Tags: golang, juju-core   

    Beware of Go tests! build before you test. 

    Matt and I were just burned by an issue in running Go tests. We broke juju-core trunk. How? As rogpeppe explains:

    go test ./… does not *build* everything. if there’s a package with no tests (which builddb is) it will just be ignored

    So, the way I read that is that go test is broken! You have to run this command to actually be sure that your changes are OK.

    go build ./... && go test ./...

     
    • Benji York 12:42 pm on April 2, 2013 Permalink | Reply

      This sounds like something that should be in the lbox pre-propose/submit hook.

      • garyposter 1:00 pm on April 2, 2013 Permalink | Reply

        Yeah. juju-core only runs the linter there. I know this is a considered position of theirs. Maybe they will reconsider, or maybe they will add tarmac support to lbox.

        • Benji York 1:01 pm on April 2, 2013 Permalink

          I’m sure the more we break it the more they will reconsider.

    • bradcrittenden 2:00 pm on April 2, 2013 Permalink | Reply

      Benji that sounds like an evil plan.

  • Francesco 3:48 pm on March 28, 2013 Permalink | Reply
    Tags: juju-core,   

    Deploying the GUI in a juju-core environment 

    I just proposed a branch of the Juju GUI charm including support for juju-core. Assuming your juju-core environment is named “go”, it is possible to deploy the charm as usual:

    juju bootstrap -e go

    juju deploy -e go –repository=/my/local/charm/store local:precise/juju-gui

    juju expose -e go juju-gui

    If you want the charm to expose the newest version of the GUI, you can run:

    juju set -e go juju-gui juju-gui-source=lp:juju-gui

    As you probably already noticed, it is possible to pass an arbitrary Bazaar branch to juju-gui-source, and this allows for easy debugging changes on the GUI code, especially if those changes involve the interaction between the Juju GUI environment object and the juju-core API server.

    Once the Juju environment is created, it is possible to ssh into the Juju GUI machine by running:

    juju ssh -e go 1

    Here the charm hooks operations are logged in /var/log/juju/unit-juju-gui-0.log.

    All the API calls are logged by juju-core, and the logs are stored in /var/log/juju/machine-0.log of the bootstrap node, e.g.:

    juju ssh -e go 0

    tailf /var/log/juju/machine-0.log

     
    • Benji York 3:55 pm on March 28, 2013 Permalink | Reply

      Good stuff.

    • garyposter 4:51 pm on March 28, 2013 Permalink | Reply

      Definitely! I think we’re a few commits away, on the go side and the gui side, from being able to have a demoable story. Pretty cool.

c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel