Updates from May, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • garyposter 3:13 pm on May 24, 2013 Permalink | Reply
    Tags:   

    switch from 127.0.0.1 to 0.0.0.0 (from Jon)

    Working on code in an lxc or other virtual instance is great, but accessing it via a browser then turns into a bunch of s/127.0.0.1/0.0.0.0 only to try to back it out again before committing. Then re-applying in the next branch.

    Jeff had some custom /etc/hosts that set 0.0.0.0 to a custom hostname and broke using it for others. I’d suggest everyone check out their networking and see if we can’t get things working with 0.0.0.0 as the default as it’ll be helpful to newer common dev practices.

    explanation: binding to 0.0.0.0 will bind on all available ports on a system and thus make the juju gui instance running available on the public ip as well as 127.0.0.1. This means the host OS can access the gui running on the guest OS by default.

    Resolution: Jon or Rick will land change.

    Advertisements
     
  • garyposter 12:36 am on May 24, 2013 Permalink | Reply
    Tags: , jenkins, rietveld, tarmac   

    Thanks to Diogo Matsubara, we’ll be migrating to tarmac soon for landing our branches. Meanwhile, we owe more thanks to Aaron Bentley, who made a nice way to integrate rietveld and tarmac: the bzr plugin rvsubmit. We can’t use it until tarmac is turned on, but when you want to give it a whirl, do the following:

    cd ~/.bazaar/plugins
    bzr branch lp:rvsubmit

    Congratulations! You’ve installed the plugin. You can read a bit about the new command with bzr rv-submit --help. Notice that the project does not have a hyphen, but the command does.

    When tarmac has actually been set up, our workflow initially will be the following.

    lbox propose
    (Get the reviews you need…)
    bzr rv-submit
    (Hope that the fragile test suite passes :-/ )

    Other improvements (like supporting pipelines) might come soon, thanks to Aaron! We’ll be working on making the test suite more robust too.

     
  • garyposter 5:14 pm on May 23, 2013 Permalink | Reply
    Tags:   

    Potential GUI issues while jujucharms.com DNS change propagates 

    Unfortunately, some users of the Juju GUI may have difficulty deploying charms while a DNS change of jujucharms.com propagates. If you encounter problems, switching to a fast DNS server like Google’s should help.

     
  • Benji York 3:59 pm on May 23, 2013 Permalink | Reply  

    Replaying websocket traffic 

    The Juju GUI communicates with Juju via a websocket. We wanted to be able to capture and replay the websocket traffic as a debugging aid, especially when tracking down memory leaks. We imagined that we would have to add client-side logging in order to capture the websocket traffic, but in doing my due diligence before implementing such a thing I decided to see if there was a way to capture the data without writing any code.

    It turns out that Chrome’s built-in network inspector panel will let you see the frames sent across a web socket but I could not find a built-in way to export the data. The best you can get is copy/paste the frame data.

    Unfortunately the copy/paste omits an important detail. Chrome indicates the direction of the data flow (from the client to the server or vice versa) as the color of each row (green for sent frames, white for received frames). That coloration is, of course, lost when the text is copied.

    This would seem to be a critical failure, but I realized that given the constraints of the protocol spoken between the GUI and Juju, we can always infer the direction of communication from the message itself.

    After realizing this I built a proof-of-concept program that, given a copy/pasted log from Chrome will replay a websocket session. It waits for the GUI to make a request and then parrots the response read from the log. If the GUI makes a request that does not match the log the server raises an exception and the party is over.

    This is how you collect a websocket traffic log that can be replayed:

    1. Open a new tab in Chrome
    2. Open the developer tools (Control-Shift-i)
    3. Select the “Network” pane
    4. Click the “Websockets” filter at the bottom of the pane
    5. Navigate to the GUI (e.g., localhost:8888)
    6. Perform the actions you want logged.
    7. Click on the single “ws” entry on the left of the Network pane.
    8. Select the “Frames” tab to the right.
    9. Click on the first entry in the frames table.
    10. Type Control-a to select all.
    11. Open a text editor and middle-click to paste the log.
    12. Save the log to a file.

    Note: If you are taken to the “Sources” view by a breakpoint being triggered you need to disable breakpoints by selecting the “Sources” pane and clicking on the pause symbol in a stop sign at the bottom of the pane until it is grey (i.e., no stopping on breakpoints).

     
  • garyposter 2:06 pm on May 22, 2013 Permalink | Reply
    Tags:   

    Juju GUI 0.5.0 released 

    We released a new version of the Juju GUI yesterday. It has a number of important bug fixes. There are also more than a few hidden experimental and incremental features that we will mention on the blog later, for those who want to explore.

    Here’s some of the bugfix highlights.

    • initial layout of services is much nicer. This is particularly evident for large deployments, such as with OpenStack.
    • Configuration values can now be multi-line. This fixes an issue people encountered when deploying haproxy, because one of the configuration strings was actually interpreted as a YAML file by the charm.
    • Mousewheel zoom now works again in Firefox. (Note that as of 0.4.0 the GUI no longer suggested that Firefox users try Chrome/Chromium. Firefox is fully supported, though Chrome/Chromium is noticeably faster).
    • Read-only mode no longer reports errors when you drag services.
    • We found and fixed a memory leak. We are now building tools to help us diagnose future memory leak reports, and will have more information about that soon.

    New instances of the GUI charm will automatically use the new release by default.

    You can change existing GUI services to use the new release by changing the charm config variable “juju-gui-source” to “0.5.0”. The update will take a minute or two, during which you can still use the old version of the GUI, except for a brief interruption of the connection to Juju right before the update’s completion. You will need to reload the GUI in your browser to get the new version, and you may need to clear your browser cache. Once you have the new version, you can verify in your browser by looking at /juju-ui/version.js on the GUI’s server.

    Enjoy!

     
  • garyposter 4:02 pm on May 17, 2013 Permalink | Reply  

    [Weekly review notes] We should make a concerted effort to reduce noise emails.

    What are the noise emails?
    Duplicate and near duplicates of branch reviews: tarmac will help somewhat
    warthogs, canonical-tech and gophers
    bad build emails, Merge proposal emails: hack launchpad to give more options to not send emails?

    Resolution: discuss hacking Launchpad later.

     
  • garyposter 3:50 pm on May 17, 2013 Permalink | Reply  

    [Weekly review notes] unit test documentation (in docs directory) keeps track of unit test gotchas. Read it and maintain it! Gary should add the app mock documentation there, and maybe we want to document some of the test utils there too.

     
  • garyposter 3:48 pm on May 17, 2013 Permalink | Reply  

    [Weekly review notes]

    test titles as it(‘[active verb]…), for example it(‘runs circles’) (not it(‘should run circles’)). If there is not object to test (not “it”) then aliasing “test = it” is fine until proven otherwise.

     
  • garyposter 3:42 pm on May 17, 2013 Permalink | Reply  

    [Weekly review notes] Don’t use a pastebin for permanent items, like bug report artifacts. pastebins can be cleaned up and thus lose your data.

     
  • garyposter 3:40 pm on May 17, 2013 Permalink | Reply  

    [Weekly review notes] We diplicated effort with an unreleased YUI widget that someone happened to know about and tell us about after we had done the work. We had done a decent amount of diligence in looking for prior work. We didn’t find it. Do we need to change our process? Answer: no.

     
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