[MIR] juju, txaws, txzookeeper

Bug #912861 reported by Clint Byrum on 2012-01-06
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
juju (Ubuntu)
High
Unassigned
txaws (Ubuntu)
High
Unassigned
txzookeeper (Ubuntu)
High
Unassigned

Bug Description

This is a MIR for juju, and two of its chief dependencies, txaws and txzookeeper. There will be a separate MIR for zookeeper since it is a substantial project and stands alone by itself.

== Availability ==

juju was called ensemble before, and entered universe during the oneiric dev cycle. txzookeeper is a twisted zookeeper plugin that was created specifically for juju, and also entered universe during the oneiric cycle. txaws has been available since lucid.

== Rationale ==

juju addresses a need not addressed by plain configuration management or "Platform as a service" offerings. Juju allows one to create and share sets of automated tools for managing services called charms. It has been identified as strategically important to help Ubuntu users take advantage of the cloud and also to create their own scale-out clouds.

== Security ==

juju has not had any "CVE"'s reported against it, and has not been recommended for production usage just yet. It does have a well defined security model that relies mostly on SSH and firewalls for transport layer security. The security model has been examined for weaknesses and bugs are open and tracked upstream to address those weaknesses.

https://bugs.launchpad.net/juju/+bugs?field.tag=security

== Quality assurance ==

Juju is a CLI tool and so does require a bit of documentation reading to understand it.

There are no major bugs open in Debian or Ubuntu for any of these packages.

Upstream uses a Test Driven Dev model, and so there is a rich and rigorous test suite which is run on package build and will fail the build if the test suite fails. Packages are built daily using launchpad daily build PPA's and most developers and interested users test these packages so quality remains high. There are also functional tests that are run on each commit upstream here:

http://wtf.labix.org/

txaws has a rich test suite, which is run and failed on during build.

txzookeeper also has a rich test suite, however, it is somewhat dangerous to run as it will completely delete a local zookeeper's contents, so until this bug is fixed, we can't run it on package build:

https://bugs.launchpad.net/ubuntu/+source/txzookeeper/+bug/912508

UI standards:

N/A

== Dependencies ==

These are the non-main deps/build-deps for the 3 libraries mentioned here:

Deps/Build_Deps:
zookeeper - being addressed in a seperate MIR

Recommends:
pydot - Used to produce "dot" output. Can be dropped to Suggests or added to this MIR. It is a very small python library. I think its worthwhile to add it, but would not want to see this MIR blocked because of it, as this is a very small bit of functionality. pydot also depends on pyparsing, which is in universe. pydot does not seem well maintained, having missed *many* upstream releases.

== Standards compliance ==

All 3 packages are very straightforward and use minimal dh7 rules. They have a few lintian warnings, but mostly due to out of date standards or minor formatting issues.

== Maintenance ==

The package is well maintained in Ubuntu directly. The server team is committed to making juju a big part of Ubuntu's cloud strategy. The package is not in Debian just yet, as its ties to Ubuntu are very strong, though at some point we'd like to make it available in Debian once things stop changing so rapidly.

== Background information ==

This MIR is a part of the following blueprint:

https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-juju-mir

Michael Terry (mterry) on 2012-01-13
Changed in juju (Ubuntu):
assignee: nobody → Jamie Strandboge (jdstrand)
Changed in txaws (Ubuntu):
assignee: nobody → Jamie Strandboge (jdstrand)
Changed in txzookeeper (Ubuntu):
assignee: nobody → Jamie Strandboge (jdstrand)
Dave Walker (davewalker) on 2012-01-31
Changed in juju (Ubuntu):
importance: Undecided → High
Changed in txaws (Ubuntu):
importance: Undecided → High
Changed in txzookeeper (Ubuntu):
importance: Undecided → High
Jamie Strandboge (jdstrand) wrote :

txzookeeper review:
 * no CVE history
 * no sudo fragments, dbus services, setuid binaries, initscripts or daemons
 * lintian clean
 * has test suite, but not run (LP: #912508). Wrote QRT script for this for now
 * code is very clean with more that 3x more test code than library code. I like that. :)
 * build depends are all in main
 * while the package is only in Ubuntu, it is supported by the server team and with upstream employed by Canonical

With the above review, txzookeeper looks good for main.

Changed in txzookeeper (Ubuntu):
assignee: Jamie Strandboge (jdstrand) → nobody
status: New → Fix Committed
Jamie Strandboge (jdstrand) wrote :

txaws review:
 * no CVE history
 * no sudo fragments, privileged operations, dbus services, setuid binaries, initscripts or daemons
 * has a test suite and it is run in the build and will fail the build on error
 * build logs are clean
 * lots of binaries without man pages
 * build depends are all in main
 * while the package is only in Ubuntu, it is supported by the server team and with upstream employed by Canonical
 * aws-status: uses gnome-keyring, which is fine, but this doesn't work with Unity (gtk.StatusIcon needs to move to app indicators). There is no documentation. Should be fixed and documented or dropped. Could alternatively leave binary in universe, but it is unusable atm so I'm not sure of the benefit there.

Conditional ACK provided the following is fixed:
 * binaries have worthwhile man pages (--help is useful, but aws-status doesn't
   have it and at least txaws-discover is out of date)
 * aws-status be fixed and documented or dropped. Optionally put this binary in universe.

Changed in txaws (Ubuntu):
assignee: Jamie Strandboge (jdstrand) → nobody
status: New → Fix Committed
status: Fix Committed → In Progress
assignee: nobody → Clint Byrum (clint-fewbar)
Jamie Strandboge (jdstrand) wrote :

I just noticed that 'juju bootstrap' dies with:
$ juju bootstrap
2012-03-14 08:54:00,190 INFO Bootstrapping environment 'local' (type: local)...
2012-03-14 08:54:00,191 INFO Checking for required packages...
Missing packages apt-cacher-ng
2012-03-14 08:54:01,387 ERROR Missing packages apt-cacher-ng

This dependency is not declared in the packaging though. Also, it seems odd that this is required. Perhaps making it a Suggests and then having juju have a configurable mirror would be good (I know personally I would rather point juju at a mirror than magic with apt-cacher-ng). Some environments may have squid installed also.

Clint Byrum (clint-fewbar) wrote :

apt-cacher-ng is already a Suggests of juju. Its only necessary for use in the local provider, and the error message is graceful enough that I'm comfortable with it as-is (notice that the other local-only requirements are recommends.. I dropped apt-cacher-ng to Suggests because it is not in main). Agreed that being strict about only using apt-cacher-ng is not the best plan. bug #897645 is open upstream for a more flexible way to specify the proxy to use.

Clint Byrum (clint-fewbar) wrote :

txaws man pages are generated from help2man now, so its at least more discoverable. I also added indicator support to aws-status, a basic manpage, and a desktop file.

Clint Byrum (clint-fewbar) wrote :

These fixes, btw, are awaiting release team approval given beta freeze

Changed in txaws (Ubuntu):
assignee: Clint Byrum (clint-fewbar) → Jamie Strandboge (jdstrand)
Jamie Strandboge (jdstrand) wrote :

FYI, review is mostly complete. Discussing some things with the server team before posting here.

Jamie Strandboge (jdstrand) wrote :

txaws looks good. Thanks! Please feel free to seed.

Changed in txaws (Ubuntu):
assignee: Jamie Strandboge (jdstrand) → nobody
status: In Progress → Fix Committed
Jamie Strandboge (jdstrand) wrote :
Download full text (10.9 KiB)

= Review =
Juju is a very flexible system for deploying services based on industry best practices and expertise. It is very capable and can deploy services to multiple providers. As such, though my review took quite a bit of time, it should still be considered a shallow audit. Understanding this, here is my security review:

juju has support for different providers which are simply the types of cloud frameworks it can use. For example, there is an EC2 provider (which also works with OpenStack) and a Local (LXC) provider. More providers are expected. The providers are configured via ~/.juju/environments.yaml on the admin system. juju abstracts out the specifics of working with a provider one environments.yaml is correctly configured. juju admin host stores sensitive information in ~/.juju/environments.yaml. It does not enforce safe permissions currently (LP: #956009).

juju's architecture is such that an admin runs juju commands on her system and they are delivered to a bootstrapping node. The bootstrapping node runs a zookeeper database and has the ability to start and stop units (nodes) and deliver setup code (charms) to the nodes. The nodes execute the charms code as root. In addition to setup code, charms provide other hooks like 'start' and 'stop' which are executed when the service unit is stopped or started. All the hooks run with root permissions. All the nodes share the same database, but there is only one zookeeper leader so nodes should not be able to be elected as a zookeeper leader (see server.* in /etc/zookeeper/conf/zoo.cfg). All nodes currently are able to read and write to the zookeeper database. With the Local provider, zookeeper is started as the user invoking juju (uses a high non-default port), not in a separate bootstrapping node. In all ways I could see, the admin's system is effectively the bootstrapping node with the Local provider.

In terms of network connectivity, juju allows ssh access to all nodes. When the admin deploys a node via a charm, the node's new service is still not available over the network (but is to other nodes in the environment). Only when the service is 'exposed' does the application become available over the network. For example, if an admin deploys mysql and wordpress services, wordpress is only available to the world after the admin uses 'juju expose wordpress'. This is a good design as it allows the admin to verify the configuration, perform updates, etc before it is exposed to the world. Also, in this example, mysql is correctly not exposed to the world. This is all accomplished via security groups in EC2/OpenStack. In the current version of juju, network access is not a problem with the Local provider because zookeeper and the services are all on the libvirt NAT network and not exposed to the world directly. Expose/unexpose doesn't seem to have any meaning with the Local provider as no firewall rules are added via iptables and the service is not accessible from other hosts (besides the admin machine).

There are many problems surrounding zookeeper access. Anyone who can connect zookeeper (ie, all nodes) can see and modify anything in the database. Note that this does not require subvertin...

Changed in juju (Ubuntu):
assignee: Jamie Strandboge (jdstrand) → nobody
status: New → Fix Committed
Jamie Strandboge (jdstrand) wrote :

I am going to mark this back to 'In Progress'. The server team decided not to pursue juju for main inclusion in 12.04 so I am removing the conditional ACK until the bugs I outlined are fixed.

Changed in juju (Ubuntu):
status: Fix Committed → In Progress
James Page (james-page) wrote :

Marking bugs as invalid as this codebase is no longer under MIR

Changed in juju (Ubuntu):
status: In Progress → Invalid
Changed in txaws (Ubuntu):
status: Fix Committed → Invalid
Changed in txzookeeper (Ubuntu):
status: Fix Committed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers