Updates from December, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • garyposter 7:03 pm on December 13, 2013 Permalink | Reply  

    Great speed improvements 

    Thanks to Matt Scott, we have some super speed and scaling improvements.

    We discovered fairly recently that the inspector was not scaling well to large numbers of units.  We wanted to support at least 2000 units or so. You can see on jujucharms.com that this wasn’t working very well.  If I go to jujucharms.com and deploy a charm with 2000 units on my machine, it can take around half a minute before the inspector starts fully showing the units.  Furthermore, the interface hiccups every few seconds afterward, being unresponsive for two to four seconds every time.  Ouch.

    Thanks to some work from Matt Scott, now the time to render the initial inspector with 2000 units is just over a second, and the subsequent hiccups are short to the point of being almost unnoticeable for me (and thanks to profiling work from Jeff Pihach, any hiccups at this stage are more likely to come from the simulator than anywhere else at this point, so it should not affect real environments).  Give it a try on comingsoon.jujucharms.com!  Yes, you can still easily scale out far enough to bring your browser to its knees, but for our current scale goals, we’re looking much better.

    For more explanation on what Matt did to speed things up, see the notes from today’s earlier post.

     
  • garyposter 4:54 pm on December 13, 2013 Permalink | Reply  

    Weekly retrospective notes 

    Git transition

    It’s done, and almost everyone has made a commit on the new tree.  No one is upset, most people are happy with the change, and we all give Rick Harding a big thank you.  Thanks!

    Next steps are to send the Juju Core team an update with where we are.  There are a few warts with what we’ve done (notably the fact that our imoported history is ugly).  We find them acceptable, but if they want to fix some of them up, we’ll gladly ride on their coattails.

    Where should our docs be?

    We’ve kept our docs in readthedocs, but we don’t use them much, if ever.  Meanwhile, git does a really nice job of rendering Markdown and ReST itself.  Should we just embrace github’s docs and make sure that our links work in github?

    Answer: yes.  Rick will make this work.  And we deleted the readthedocs site.

    What magic did Matt Scott do to make the GUI’s inspector scale so much better to a couple thousand units?

    Notes from Matt.  Thanks!

    • d3 wants its own objects (meaning, since everything is passed by reference, it’s better to wrap (see boundingbox in source code)).  Not using wrapped objects was the source of links showing up in the wrong sections (attributes on units were being overwritten due to units being refs)
    • d3 will be as efficient as possible in computing joins with data/enter/update/exit, but it will do so on in-memory data, not dom.  Tying things to the dom was the main source of slow-down – filter should have taken place on objects (first arg) rather than dom nodes (this).
     
  • garyposter 4:55 pm on December 6, 2013 Permalink | Reply
    Tags:   

    Weekly retrospective notes 

    Francesco: juju-test our charm, current status, future plans

    juju-test had a preferred solution a few months ago, but that might no longer be the case, possibly in favor of some upcoming internal juju feature. What should we do?  We could build the functionality ourselves or contribute to juju-test.

    Rick: Let’s coordinate with the community and try to contribute to juju-test.

    Gary: +1 with Rick, but let’s stick with what we have until we have to build the next big charm feature.  Then we can look at the landscape and decide how we want to refactor.

    Gary: how do we kill pyJuju support?

    After discussing options we agree on the following.

    • We will announce that the last release of the GUI was the last one to support pyJuju.
    • If someone begs us to fix a pyJuju bug, and we’re willing to prioritize it, we will branch from that release.
    • The next GUI release will be 1.0.  This will signify breaking compatibility with pyJuju, and also align with our move to Git.  Per Jeff’s warning, we will want to do extra QA for this release, but it already aligns with the kind of work that we are doing this month.
    • This will also mean that new versions of the charm will no longer support pyJuju.

    Gary: stub function approach in test/utils.js

    Look at makeStubMethod and makeStubFunction in test/utils.js. They seem like a worthwhile experiment.  Please keep them in mind when coding and reviewing.  Improvements welcome!

    Gary: formalization of story lead role

    XXX Expand

    Rick: opportunity to shorten daily calls

    Jeff: YUI Theater hangout about the GUI

    Promote it!  Share it! http://www.youtube.com/watch?v=lJPdH8xmOWg

    Rick: switch to git today

    Read the HACKING doc!  Also see the lander’s README.

     
  • garyposter 12:36 pm on December 5, 2013 Permalink | Reply  

    New Juju GUI 0.14.0, Juju Quickstart 0.5.0 

    We are very happy to announce new versions of the Juju GUI and the Juju quickstart plugin.

    On the GUI, this work represents part of our current drive to make it a more effective day-to-day tool.  For example, in the service inspectors, errors are now categorized by type, rather than grouped as “Error”, so you can see at a glance what’s going on.  Error details are displayed more clearly and reliably.  Services that are in the process of being destroyed don’t disappear immediately, so you can follow along and make sure there aren’t any problems that need your attention.  Bundle deployments now give you better feedback so you have some insight into what’s going on.  And so on, with other related features and bug fixes.  More exciting work in this direction is coming, including long-requested features like per-unit debug logs and local charm deployments!

    The quickstart plugin is nearing feature completion, and has a lot of nice additions.  For new users, if you don’t have Juju installed, after it adds the stable PPA to your system and installs Juju, it will create an environments.yaml file that you need to edit.  For everyone, when you run quickstart, it will automatically log into the GUI for you as long as you accept the security certificate in your browser within two minutes of it appearing.  We also fixed a bug triggered when your default series was not precise.  The next release will guide new users through creating environments.yaml interactively, and then we intend to declare our first quickstart effort to be feature complete.

    To try out our new releases, existing users can upgrade their GUI charm to cs:precise/juju-gui-81; or run “juju deploy juju-gui && juju expose juju-gui”; or update the juju-quickstart plugin via apt and run “juju quickstart”.

    New users on Ubuntu can do the following to get everything installed and start an environment with the GUI running and ready:

    sudo add-apt-repository ppa:juju/stable
    sudo apt-get update && sudo apt-get install juju-quickstart
    juju-quickstart
    [...edit ~/.juju/environments.yaml file...]
    juju-quickstart

    Next quickstart release will hopefully remove those last two steps.

    New users on other operating systems can’t use quickstart right now, but the Juju installation instructions can get you started, and “juju deploy juju-gui && juju expose juju-gui” can add the GUI to your bootstrapped environment.  More documentation is available!

     
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