Updates from March, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • garyposter 8:59 pm on March 29, 2013 Permalink | Reply
    Tags: Futures   

    What’s next?

    There are a lot of plans and thoughts for where the GUI should go next, from many stakeholders. We’ll be researching, considering, and hardening some of those plans in the next couple of months, so I’ve encouraged us all to think about our own ideas, observations, and desires. Where should we go next?

    • garyposter 9:03 pm on March 29, 2013 Permalink | Reply

      Users have told us from near the beginning that they want access to logs. It looks like Juju Core will have them after all. Let’s give access to them in the GUI!

      But how? What do users want from these logs? I think the main use case is debugging. We should go back to the user research and see what details we can pull up.

    • garyposter 9:19 pm on March 29, 2013 Permalink | Reply

      Speed. We could speed up the GUI when downloading code, when receiving data from Juju, and when rendering, particularly on mobile devices.

      For downloading code, we’ve talked about CDNs before. But what about installable Chrome apps and Firefox extensions? We might have to restructure a few things, but I think that might be doable, and it would address what I believe to be the most important day-to-day download speed scenarios for users.

      For receiving data from Juju, we have some disagreement about whether we need to redesign our approach to getting regular status updates from Juju.

      For rendering, we will be doing a lot of work on new designs, and we’ll be using simpler SVG resources, so we have an opportunity to improve if we focus on mobile from the beginning of that effort.

      How much of this is a priority? How should we decide? The mobile focus is strategic, but the rest is more debatable.

  • garyposter 2:04 pm on March 29, 2013 Permalink | Reply  

    Here’s a teeny tiny convenience. The basic idea is that you can use virtualenv’s bin directory for more than just Python conveniences: it gives you temporary PATH changes too, which can be convenient for switching between the Go and Python implementations of Juju.

    While we’re in the transition state between the legacy, Python-based, system-installed Juju and the golang, from source Juju Core, we sometimes want to switch back and forth between the two definitions of “juju.” I’ve followed the Juju Core instructions to add the Go bin to my path, so that’s the juju that “wins” normally.

    If you want easy access to Python Juju, you can just make a symlink from “pyjuju” to the system’s juju. That works fine for some stories.

    However, it is inconvenient for using old workflows, such as testing our charms with jujujitsu, which expects “juju” to be the legacy Python Juju implementation. For this, I made a virtualenv with the –system-site-packages flag, installed the Python dependencies that hacking the charm needs (see the charm’s HACKING document), and then added a “juju” symlink to the system’s Python-based juju in the virtualenv bin. Now if I source the virtualenv’s bin/activate, I have all the dependencies I need for testing, plus “juju” is the Python implementation.

  • garyposter 5:08 pm on March 28, 2013 Permalink | Reply

    I’ve turned the CI on. What does that mean?

    • Commits to trunk will fire off tests.
    • Failures will send emails to the juju-gui list.
    • To access the Jenkins instance that runs these tests you need Canonical credentials. See docs/continuous-integration.rst in the tree for details.
    • We will have spurious failures. The only ones we have left are because of Canonistack flakiness. Sorry. Retry. We’ll be bringing these failures up with IS when we have more stats.
    • We will have hangs. We can convert most or all of these into failures (I have a sketch), but for now, go to Jenkins, kill the build, and retry.
    • You can run the tests yourself using bin/test-charm in the tree–see docs/continuous-integration.rst.
    • See docs/continuous-integration.rst for information on how to write reliable tests.

    I think we’ll declare this CI task complete once we have a few successes under our belts.

    What do we want to do later?

    • Reduce spurious failures, by hook or by crook.
    • Convert these tests from CI to gatekeeper, a la tarmac.
  • Francesco 3:48 pm on March 28, 2013 Permalink | Reply
    Tags: ,   

    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.

  • garyposter 10:14 pm on March 27, 2013 Permalink | Reply

    Just worked with hatch, based on work he and bcsaller did, to get our continuous integration working. It looks like we are on the right track! We’ll hopefully turn it on tomorrow, even though we still may get occasional false negatives. We also want to share some of our lessons learned, particularly in regards to making Selenium tests pass on IE 10.

  • Benji York 5:11 pm on March 27, 2013 Permalink | Reply  

    Firefox locks up (100% CPU) when I turn on the “Web Console” (not the “Error Console”).

    • Benji York 5:35 pm on March 27, 2013 Permalink | Reply

      It turns out that the lock-up only happens in the Juju-GUI. Other pages do not exhibit the problem.

    • Benji York 5:41 pm on March 27, 2013 Permalink | Reply

      Another detail: it un-freezes after approximately 60 seconds and then appears to act normally.

    • Benji York 5:54 pm on March 27, 2013 Permalink | Reply

      After un-freezing it generates this error, which would seem to be related: “InternalError: allocation size overflow.”

      Oddly, the time stamps in the error log show the pause happening just after the above message is logged, but it was not visible during the freeze. Perhaps cleaning up after the error is what is taking so long. The last item displayed in the log during the hang was: “GET https://ec2-54-224-116-8.compute-1.amazonaws.com:17070/ [HTTP/1.1 101 Switching Protocols 207ms]”

    • Benji York 6:04 pm on March 27, 2013 Permalink | Reply

      Wow, it appears that a call to console.log() (which I added to try to debug a different issue) is the cause. Once I removed that line the hang went away.

    • Benji York 6:26 pm on March 27, 2013 Permalink | Reply

      The reason the console.log() call was using so much memory was that it was in a function that was incorrectly bound to an event (by me in a different branch) and the wrong thing (an instance of the Environment) was being passed to the event handler. That instance is huge, so stringifying it apparently used too much memory.

      Issue solved.

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc