Thank you for the updates, Andrew. When you have a chance, would you mind talking with me about debug-log, uploading a charm, and the associated changes to deploy and upgrade-charm? The GUI definitely cares about those and I'd like to make sure we have talked through the design to make sure we can use them.
Thank you, Gary On Nov 5, 2013, at 4:25 AM, Andrew Wilkins <[email protected]> wrote: I thought I'd summarise where things are at now, in case anyone else starts looking for work to do. Ignoring the DONE's, we have the following remaining (see below for commentary): api-endpoints: TODO [axwalk] debug-hooks: INPROGRESS [axwalk] debug-log: INPROGRESS deploy: TODO destroy-environment: TODO [dimitern] get-environment: INPROGRESS [axwalk] scp: INPROGRESS [natefinch] set: INPROGRESS [dimitern] set-environment: INPROGRESS [axwalk] ssh: INPROGRESS status: TODO upgrade-charm: TODO upgrade-juju: TODO As I've been looking for things to bite off, here's some comments from me (excluding things others are already looking into). api-endpoints: (I don't recall why we put this in the list at all? What needs to be done here?) upgrade-juju: this requires get/set-environment deploy, upgrade-charm: These require some way of uploading charms. By the way, what's our maximum size for charms, and for RPC messages? status: haven't looked into in detail, looks like a big task. don't forget filters :) destroy-environment: I'm told we can destroy-environment from within an environment, but that sounds perilous to me. At any rate, we need to make some changes here to accommodate manually provisioned machines inside non-manual provider environments (when we support that), and cleanly destroying manual-provider environments by enumerating/destroying state entities. debug-hooks, debug-log, scp and ssh: I'm working on these, and have them mostly done. I've added two new client API calls: ServiceEndpoints, and PublicAddress (perhaps this ought to be Addresses?), which takes a unit or machine ID and returns its public address. There's a remaining problem in that API connections do not push secrets to the API server. This means the server can't get an Environ, which means the address updater can't do its stuff. Cheers, Andrew On Tue, Nov 5, 2013 at 3:41 AM, Tim Penhey <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/11/13 00:45, John Arbash Meinel wrote: > >> https://blueprints.launchpad.net/juju-core/+spec/t-cloud-juju-cli-api > > > >> I also went through the photo I took of our big bit of paper > >> and marked done those that were (although sync-tools seemed to be > >> a bit edgy). > > > > Can you at least link the image to the blueprint so we can see the > > Size information for each item? > > Done. Description now links to this image: > > http://people.canonical.com/~tim/api-cli.jpg > > > I have also subscribed some of you to the blueprint. This means that > you'll get emails when someone edits the work items. > > Please note that since multiple people are editing the work items at > one time, it is possible that there is a race condition on the updates > (hence it is good to get the email), and this race window is much > larger if you have stale data in your web browser. > > I've seen at least one it happen where someone else's work items have > been cleared out accidentally. Please double check that this is up to > date with what you are doing. > > Cheers, > Tim > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.14 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlJ3+FkACgkQd1fvI4G7WRBGywCfczJJB0O41IBJYQ9Ir/bajKci > bI4AoLSaf5uiOrGsob5CO/JiW5UUJsB+ > =J05Q > -----END PGP SIGNATURE----- > -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
