On Wed, Sep 3, 2014 at 4:49 PM, John Meinel <[email protected]> wrote: > It feels like this should be something that the API server is looking up in > the database/some sort of query, not just munging a URL. I'm fine with > having a Params struct, though I worry that it isn't really appropriate to > be passing all possible Params to all facades. They already have a State > connection, I'd like us to at least be designing the layering appropriately. > I feel like state.State is intended to be where "Knowledge" resides. Why > isn't what we want there?
Yeah, constructing it based on the current known addresses of the state servers seems best. Do we maybe actually want a list of URLs where the tools are available? That'd be the HA thing to do, I suspect. Cheers William > > John > =:-> > > On Sep 3, 2014 6:03 PM, "Andrew Wilkins" <[email protected]> > wrote: >> >> I'm working on moving all tools downloads to download from the API server. >> There will are a few APIs that return tools: >> - Upgrader.Tools >> - Client.FindTools >> - Provisioner.FindTools >> >> These APIs will need to return URLs pointing at the API server. I'm >> intending to change the facade constructors to take a parameter struct, and >> extend it with the API server's root URL (i.e. >> https://<address>:<port>/environment/<uuid>), where the address is the one >> used by the client to connect. >> >> Any reason I should not go ahead and do that? This will probably make it >> easier to slot in a "Restarter" or whatever as well. >> >> Cheers, >> Andrew >> >> -- >> 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 > -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
