Planning for Juju 2.2 (16.10 timeframe)

Tom Barber tom at analytical-labs.com
Sat Mar 19 23:35:20 UTC 2016


Here's another one, which I can't find in the docs, but apologies if it
exists.

It would be good to be able to specify allowed origin IPs for juju expose
for cloud types that support it.

For example in EC2 instead of allowing 0.0.0.0 allow a specific address or
range. But also expand that further, so each service could be exposed to
different addresses, say different services in the same model for different
clients, or similar.

Tom

--------------

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart
<http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
goal, but you can always help by sponsoring the project
<http://www.meteorite.bi/products/saiku/sponsorship>)

On 19 March 2016 at 03:20, Andrew Wilkins <andrew.wilkins at canonical.com>
wrote:

> On Sat, Mar 19, 2016 at 12:53 AM Jacek Nykis <jacek.nykis at canonical.com>
> wrote:
>
>> On 08/03/16 23:51, Mark Shuttleworth wrote:
>> > *Storage*
>> >
>> >  * shared filesystems (NFS, GlusterFS, CephFS, LXD bind-mounts)
>> >  * object storage abstraction (probably just mapping to S3-compatible
>> APIS)
>> >
>> > I'm interested in feedback on the operations aspects of storage. For
>> > example, whether it would be helpful to provide lifecycle management for
>> > storage being re-assigned (e.g. launch a new database application but
>> > reuse block devices previously bound to an old database  instance).
>> > Also, I think the intersection of storage modelling and MAAS hasn't
>> > really been explored, and since we see a lot of interest in the use of
>> > charms to deploy software-defined storage solutions, this probably will
>> > need thinking and work.
>>
>> Hi Mark,
>>
>> I took juju storage for a spin a few weeks ago. It is a great idea and
>> I'm sure it will simplify our models (no more need for
>> block-storage-broker and storage charms). It will also improve security
>> because block-storage-broker needs nova credentials to work
>>
>> I only played with storage briefly but I hope my feedback and ideas will
>> be useful
>>
>> * IMO it would be incredibly useful to have storage lifecycle
>> management. Deploying a new database using pre-existing block device you
>> mentioned would certainly be nice. Another scenario could be users who
>> deploy to local disk and decide to migrate to block storage later
>> without redeploying and manual data migration
>>
>>
>
>> One day we may even be able to connect storage with actions. I'm
>> thinking "storage snapshot" action followed by juju deploy to create up
>> to date database clone for testing/staging/dev
>>
>> * I found documentation confusing. It's difficult for me to say exactly
>> what is wrong but I had to read it a few times before things became
>> clear. I raised some specific points on github:
>> https://github.com/juju/docs/issues/889
>>
>> * cli for storage is not as nice as other juju commands. For example we
>> have the in the docs:
>>
>> juju deploy cs:~axwalk/postgresql --storage data=ebs-ssd,10G pg-ssd
>>
>> I suspect most charms will use single storage device so it may be
>> possible to optimize for that use case. For example we could have:
>>
>> juju deploy cs:~axwalk/postgresql --storage-type=ebs-ssd
>> --storage-size=10G
>>
>
> It seems like the issues you've noted below are all documentation issues,
> rather than limitations in the implementation. Please correct me if I'm
> wrong.
>
>
>> If we come up with sensible defaults for different providers we could
>> make end users' experience even better by making --storage-type optional
>>
>
> Storage type is already optional. If you omit it, you'll get the provider
> default. e.g. for AWS, that's EBS magnetic disks.
>
>
>> * it would be good to have ability to use single storage stanza in
>> metadata.yaml that supports all types of storage. They way it is done
>> now [0] means I can't test block storage hooks in my local dev
>> environment. It also forces end users to look for storage labels that
>> are supported
>>
>> [0] http://paste.ubuntu.com./15414289/
>
>
> Not quite sure what you mean here. If you have a "filesystem" type, you
> can use any storage provider that supports natively creating filesystems
> (e.g. "tmpfs") or block devices (e.g. "ebs"). If you specify the latter,
> Juju will manage the filesystem on the block device.
>
> * the way things are now hooks are responsible for creating filesystem
>> on block devices. I feel that as a charmer I shouldn't need to know that
>> much about storage internals. I would like to ask juju and get
>> preconfigured path back. Whether it's formatted and mounted block
>> device, GlusterFS or local filesystem it should not matter
>
>
> That is exactly what it does, so again, I think this is an issue of
> documentation clarity. If you're using the "filesystem" type, Juju will
> create the filesystem; if you use "block", it won't.
>
> If you could provide more details on what you're doing (off list, I think
> would be best), I can try and help. We can then feed back into the docs to
> make it clearer.
>
> Cheers,
> Andrew
>
> * finally I hit 2 small bugs:
>>
>> https://bugs.launchpad.net/juju-core/+bug/1539684
>> https://bugs.launchpad.net/juju-core/+bug/1546492
>
>
>
>>
>>
>> If anybody is interested in more details just ask, I'm happy to discuss
>> or try things out just note that I will be off next week so will most
>> likely reply on 29th
>>
>>
>> Regards,
>> Jacek
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160319/5b205ae9/attachment.html>


More information about the Juju mailing list