Hi all,
Anastasia raised an issue in http://reviews.vapour.ws/r/885/ about how to
cut down on struct conversions between params, state, and domain packages.
In this case we're talking about storage. The following API server facades
currently participate in storage:
- client
- storage
-
So, I think you *do* need conversion code specific to state -- the
methods exported from state should be in terms of the storage types,
because they're the language we've chosen to model storage, so there
needs to be conversion code in state (or possibly in an internal
package -- but either way
On Tue, Feb 10, 2015 at 12:13 PM, William Reade
william.re...@canonical.com wrote:
really ought to include a bunch more mechanism for finding out
*precisely* what should have been assigned to what
To be clear: I do not think we should do this, because the
interpretation of those entities would
On Tue, Feb 10, 2015 at 6:16 PM, roger peppe roger.pe...@canonical.com
wrote:
On 10 February 2015 at 10:06, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
On Tue, Feb 10, 2015 at 5:57 PM, roger peppe roger.pe...@canonical.com
wrote:
On 10 February 2015 at 08:55, Andrew Wilkins
I think that the danger here is one of backwards incompatibility,
and that's a danger that's possible to alleviate with some tooling
support.
Writing tons of boilerplate code to manually convert between types at different
levels has always seemed like a poor use of developer resources to
me (and
On Tue, Feb 10, 2015 at 5:57 PM, roger peppe roger.pe...@canonical.com
wrote:
On 10 February 2015 at 08:55, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
Hi all,
Ian raised a good point in http://reviews.vapour.ws/r/885/ (caution
advised,
may cause eyebleed) about a change I made
On Tue, Feb 10, 2015 at 5:44 PM, William Reade william.re...@canonical.com
wrote:
So, I think you *do* need conversion code specific to state -- the
methods exported from state should be in terms of the storage types,
because they're the language we've chosen to model storage, so there
needs
On 10 February 2015 at 08:55, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
Hi all,
Ian raised a good point in http://reviews.vapour.ws/r/885/ (caution advised,
may cause eyebleed) about a change I made to errors:
https://github.com/juju/errors/pull/17
The NotAssigned error, which
I think that NotAssigned is *too* generic. UnitNotAssignedToMachineErr
is one thing, and VolumeNotAssignedToStorageInstance is another; if we
use the same error type to represent those distinct situations, we
really ought to include a bunch more mechanism for finding out
*precisely* what should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10.02.2015 11:57, roger peppe wrote:
On 10 February 2015 at 08:55, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
Hi all,
Ian raised a good point in http://reviews.vapour.ws/r/885/
(caution advised, may cause eyebleed) about a change I
# juju-core 1.21.2
A new stable release of Juju, juju-core 1.21.2, is proposed.
This release may replace 1.21.1 on 2015-02-12 after a period
of evaluation.
## Getting Juju
juju-core 1.21.2 is available for utopic and backported to earlier
series in the following PPA:
Hello,
Can someone direct me to the design documents for the enigmatic
'block' functionality which is showing up in the review queue.
Thanks
Dave
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
12 matches
Mail list logo
