On Tue, 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?) > > shouldn't be on the list, its sole purpose is to allow api clients to discover the api endpoint to communicate with, ie pure discovery. > 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? > > no predefined max on charms atm, will likely need to be split up across a stream of 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. > not sure what that means, the api server already has access to the db and secrets. thanks for the update, cheers, -kapil > > 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
