On Tue, Nov 5, 2013 at 6:22 PM, William Reade <william.re...@canonical.com>wrote:
> On Tue, Nov 5, 2013 at 10:25 AM, Andrew Wilkins < > andrew.wilk...@canonical.com> wrote: > >> 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?) >> > > Connect to the API, find out if there are any addresses we didn't already > know about. Every command should be updating the local endpoints cache > anyway so Idon't think it needs to do anything but connect and stop. > > >> upgrade-juju: >> this requires get/set-environment >> > > Get maybe, but we really shouldn't use set-environment for this -- > allowing the set-environment path to change agent-version is a Bad Idea > because it's an automatic end-run around any upgrade sanity we ever impose. > I'd really favour explicitly matched api calls for get/set of agent-version. > Sounds good. I was doing a literal translation, obviously. > deploy, upgrade-charm: >> These require some way of uploading charms. By the way, what's our >> maximum size for charms, and for RPC messages? >> > > If there's a max rpc message size, there will be charms that are larger. > If there isn't, there should be. > Okay. I expected some sort of streaming/chunking would be required, just wanted to check assumptions before adding complexity. > > >> status: >> haven't looked into in detail, looks like a big task. don't forget >> filters :) >> > > So, there's some stupid stuff that needs to be fixed (talking to the > provider to find out about every single instance was fine for a while, but > we're way past the point where it scales sanely)... but I don't see any > serious problem with basically just passing the args over and returning the > requested format in a single string value. (I don't think we really want to > try to pass it over as structured data, because I'm not very optimistic > about the impact of jamming our structs through a json-shaped hole before > rendering them as yaml. Maybe I'm wrong there?) > It feels a bit wrong to me to be doing formatting behind the API server (conflating data and presentation), but that would certainly make it simpler. The canonical format could be YAML (or JSON), though, and the consumer can convert that to whatever they like. 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. >> > > We can fix the manual stuff as a first step; that's definitely required > regardless. What's the status on manually provisioned machines inside > normal environments? I didn't think we *disallowed* it -- we just > discourage it on the basis that it's unlikely to be useful in most cases -- > but there are reasonable use cases, I think. > Re status: not explicitly disallowed, but I haven't (yet) done any work to get it to actually work. Last I checked there were too many assumptions in the providers about the content of instance IDs. I'll get back to this soon. > 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. >> > > What does ServiceEndpoints do? > It returns the list of service's relation endpoint names. It's used for validating hook names for debug-hooks. Alternatively, we could just have an API for validating a hook name for a service. > > >> 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. >> > > And nor can the provisioner or firewaller, or even important parts of the > api server itself. So, yeah, this needs to be fixed. On balance I'm +1 on a > quick and somewhat dirty repeat of the secrets dance in api.Open (as > suggested by roger) so long as we don't spend too long on it; but gating > further cli api progress on tim's bootstrap changes is likely to be a Bad > Idea. > I will look into this. Roger and I discussed this yesterday, and it doesn't sound terribly difficult. If it's going to take a long time, I'll reassess. > > >> >> Cheers, >> Andrew >> >> >> On Tue, Nov 5, 2013 at 3:41 AM, Tim Penhey <tim.pen...@canonical.com>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 >> Juju-dev@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >> >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
