juju-core gui questions and notes

Gary Poster gary.poster at canonical.com
Wed Feb 20 02:22:46 UTC 2013

Hi Roger.  Here are some quick notes for discussion when we get a
chance.  I'm cc'ing the GUI list in case anyone else wants to join in.

First, on the basis of reports from the team I filed
https://bugs.launchpad.net/juju-core/+bug/1130372 .  We have a
work-around, but we thought it might be important.

Second, I've done a quick survey of the API that we will need.  First,
the good news.  Here are the API calls that have a one-to-one
correspondence with regular Juju commands.  Note that I have not yet
done a review of any argument changes between the two.  I'll do that next.

get_service == get
set_config == set

The two name changes for get_service and set_config can be completely
hidden on our side.  I personally have no opinion in this name change: I
think you are leaning towards keeping "get" and "set" in the API. This
works for me.  We'll translate it internally.

I'll revisit add_unit and remove_unit below.

Next, we have two API calls that don't correspond to commands, but that
don't require data model changes.

get_charm: This takes a charm uri (e.g., cs:precise/wordpress-5) and
returns all charm data.  For a charm store charm, for instance, the data
is identical from the charm store and from this call (except that you
are guaranteed that the data from the environment is what juju is
actually using!).

get_endpoints: This optionally takes a set of service names (otherwise
it analyzes all deployed services) and returns the interfaces they
provide and require.  This is an optimization, and we could find a way
to do without it if necessary, handling it all in Javascript, as long as
we had get_charm.  See Python code at bottom of this email.

Now we are getting into the bigger problems: API calls that are missing
and that require a data model change.

remove_annotations, get_annotations, update_annotations: I imagine you
can guess what these are about.  We need annotations on everything,
including the environment.  We need this both for Landscape integration
and for keeping simultaneous positioning updates roughly in sync.

change_unit (can be deferred): add_unit and remove_unit are poor APIs
for a UX that handles changes and simultaneous users smoothly.  It would
be much better if we could tell Juju what the desired total number of
units is, and have Juju be in charge of adding or removing the necessary
units.  We'd also want to be able to get this value (the *desired* total
unit count for a service) back, and see changes to it in the watchers.

Finally, it's worth mentioning two command line calls that we'll want,
but that we don't use immediately.


We will eventually want these.

Any thoughts or concerns about all of this so far?

I'll report back on a review of argument changes for the one-to-one
calls tomorrow.



def get_endpoints(context, service_names=()):
    service_manager = ServiceStateManager(context.client)
    if not service_names:
        services = yield service_manager.get_all_service_states()
        services = []
        for s in service_names:
                (yield service_manager.get_service_state(s)))

    endpoint_mapping = {}

    for svc in services:
        charm = yield svc.get_charm_state()
        metadata = yield charm.get_metadata()
        endpoint_mapping[svc.service_name] = svc_rel_meta = {}
        svc_rel_meta['provides'] = _flatter(metadata.provides)
        svc_rel_meta['requires'] = _flatter(metadata.requires)


def _flatter(rel_meta):
    flattened = []
    if not rel_meta:
        return flattened

    for k in rel_meta:
        rel = dict(rel_meta[k])
        rel['name'] = k
    return flattened

More information about the Juju-GUI mailing list