Skip to content
This repository has been archived by the owner on May 12, 2021. It is now read-only.

Disable containerization when not supported. #531

Merged
merged 1 commit into from Sep 4, 2014

Conversation

frankban
Copy link
Member

@frankban frankban commented Sep 4, 2014

Implement an infrastructure to dynamically disable
containers support in the machine view based on the
environment's provider type.

A list of supported containers is defined at
environment level, and used to check containerization
support.

Avoid hard-coding the list of container types in the
create machine view.

Update the service unit token to accept a list of
available container types.
Also removed the env from the service usint token:
it doesn't appear to be used at all.

This branch also includes some drive-by fixes to
methods' docstrings and comments.


@class MachineViewPanelNoopHeaderView
*/
var MachineViewPanelNoopHeaderView = Y.Base.create(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what's the advantage of a noop header vs adding a 'disabled' state to the current header?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that having this separate view complicates things more than is necessary. You should be able to pass a flag into the header view which, on instantiation, executes the 'noop' init and render cycle. Then the attribute which is set can change, which would then run the 'setup' for the real header layout and enable the 'full' render method.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A disabled state is a state, and it complicates stuff (adding conditions to all the methods, adding a test for each of those cases, more possibility to future regressions).
Toggling components seemed to me less error prone and easier to understand. The real view can do its job, while the "dummy" one is very simple.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the discussion on IRC. I didn't at first see the test that makes sure the dummy and real classes implement the same public interface.

@jujugui
Copy link
Contributor

jujugui commented Sep 4, 2014

Test PASSed.
Refer to this link for build results: http://ci.jujugui.org:8080/job/juju-gui/1761/

// Define features exposed by each Juju provider type.
// To enable/disable containerization in the machine view, just add/remove
// supportedContainerTypes to the provider types below.
environments.providerFeatures = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if these shouldn't be defined in an external configuration file?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, provider stuff is something related to environments, but I am open to suggestions.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't feel strongly about it. They just might be easier to find/modify later if they are in an external file.

I'll leave it up to you :)

@frankban
Copy link
Member Author

frankban commented Sep 4, 2014

My apologies for the long diff, but the task was not
easy to subdivide, and lots of tests have been added.

QA:

In sandbox mode.

  • make devel;
  • open the GUI with the /:flags:/mv/ flag;
  • switch to machine view;
  • ensure containers can be correctly created by:
    • creating a machine and then a container;
    • deploying a service and then placing the unit
      in an existing top level machine;
    • using the deploy menu option in the service unit token.
      In all the cases, the container type options should
      be LXC and KVM.
  • commit the changes, ensure everything works as usual.

In a real environment (e.g. local LXC or EC2).

  • juju quickstart;
  • juju set juju-gui juju-gui-source="https://github.com/frankban/juju-gui.git disable-containers";
  • wait for the installation of the customized GUI to be completed;
  • open the GUI with the /:flags:/mv/ flag;
  • switch to machine view;
  • a message in the containers header should inform you
    that sub-containers are not supported;
  • there should be no way to create sub-containers: e.g.
    the existing machines are no longer drop targets for
    unplaced units;
  • also, container types options should no longer be available
    in the service unit token when "deploy" is clicked;
  • you should still be able to place new units to
    new machines: do that, and then commit the changes
    and ensure everything works as usual;
  • now refresh the machine view: it should load correctly
    and you should still see the "Sub-containers not supported"
    message. Note that the when refreshing the machine view unit
    icons are not shown in the machine column, but they appears
    if you switch to service view and then back to machine view.
    This bug is present also in current trunk: is it already
    known? If not, I'll file a bug.

Done, thank you.

@hatched
Copy link
Contributor

hatched commented Sep 4, 2014

Thanks for the discussion this looks really awesome.
👍
QA OK
Sandbox: Everything works as intended wrt interacting with the container column header.
Real Env: Machine creations, dropping a unit on the machine header all work as expected. Container column is indeed disabled.

Note: Yes the icons not showing is a bug: https://bugs.launchpad.net/juju-gui/+bug/1364622

@makyo
Copy link
Contributor

makyo commented Sep 4, 2014

👍 thanks for all the additional clean up, that really clarifies things. No QA yet.

@frankban
Copy link
Member Author

frankban commented Sep 4, 2014

Thank you all for the reviews!
:shipit:

@jujugui
Copy link
Contributor

jujugui commented Sep 4, 2014

Status: merge request accepted. Url: http://ci.jujugui.org:8080/job/juju-gui-merge

jujugui added a commit that referenced this pull request Sep 4, 2014
Disable containerization when not supported.

Implement an infrastructure to dynamically disable
containers support in the machine view based on the
environment's provider type.

A list of supported containers is defined at
environment level, and used to check containerization
support.

Avoid hard-coding the list of container types in the
create machine view.

Update the service unit token to accept a list of
available container types.
Also removed the env from the service usint token:
it doesn't appear to be used at all.

This branch also includes some drive-by fixes to
methods' docstrings and comments.
@jujugui jujugui merged commit 723d5b1 into juju:develop Sep 4, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants