[Juju] Multiple sub service with a relation
Cory Johns
cory.johns at canonical.com
Thu Aug 20 14:15:28 UTC 2015
I'd just like to chime in with a comment about the benefits and trade-offs
of each approach. I don't think either approach is inherently more or less
"Juju-ish". I think it just depends on your use-case.
Using a structured data value for the config has the benefit that the
current configuration is easily inspectable using "juju get". It also has
the benefit that you don't need write one or more actions, or manage the
state of the connections in a charm-side data store. It's also inherently
service-spanning, in that all units of the service (if scaled) would see
the same values. You would however, have to write code to parse and act
upon the JSON data from the config value, as Sam mentioned. You also have
reconstruct the entire configuration when making a change, meaning that
doing incremental updates are more difficult.
Using actions makes the update process easily incremental, as you can have
an action for adding an individual connection. It also nicely
encapsulates the code to pertaining managing the connections into the
discrete actions, instead of as part of the larger config-changed code.
However, it means that you have to maintain a copy of the current state (or
discover it by inspecting the environment) and that may need to be
replicated across units. It also makes it harder to inspect the state from
outside of Juju, so you may need to create another action to report the
current state.
For me personally, I think the solution using actions seems a bit cleaner
on the whole, but either one would certainly work.
On Thu, Aug 20, 2015 at 9:04 AM, Samuel Cozannet <
samuel.cozannet at canonical.com> wrote:
> Hi Ana,
>
> If you have multiple servers, you'll have multiple relations.
>
> The administrator running the environment will have a knowledge of all the
> relations, thus of the servers and names.
>
> Your charm shall be able to match relation counterparts and config options
> and log the potential errors without exiting, so that in case of mistake
> the admin can observe what's wrong and fix it.
>
> Now I guess what John was saying would be that the settings in the config
> would be a json string such as
> juju set charmname datasources=[
> { "name": "mysql",
> "server": "server.domain",
> "datasets": [ "ds1", "ds2", ... ],
> },
> { "name": "mongodb",
> "server": "mongo.domain",
> "datasets": [ "ds3", "ds4", ... ],
> },
> ...
> ]
>
> Or another format... But basically putting the unknown in something that
> you manipulate as an object in your code.
>
> Hope it's clearer.
> ++
> Samuel
>
> Best,
> Samuel
>
> --
> Samuel Cozannet
> Cloud, Big Data and IoT Strategy Team
> Business Development - Cloud and ISV Ecosystem
> Changing the Future of Cloud
> Ubuntu <http://ubuntu.com> / Canonical UK LTD <http://canonical.com> /
> Juju <https://jujucharms.com>
> samuel.cozannet at canonical.com
> mob: +33 616 702 389
> skype: samnco
> Twitter: @SaMnCo_23
> [image: View Samuel Cozannet's profile on LinkedIn]
> <https://es.linkedin.com/in/scozannet>
>
> On Thu, Aug 20, 2015 at 1:54 PM, Ana Tomic <Ana.Tomic at mht.net> wrote:
>
>> Hi everyone,
>>
>>
>>
>> Thank you for your suggestion.
>> If I have understood well, if we use config options the user should be
>> able to use something like:
>>
>> juju set <charmname> database-server=<server_name>
>>
>> We want to connect to various numbers of servers at the same time, so we
>> need an option for every server.
>>
>> Like database_server1, database_server2... but the problem is that we can
>> not specify the exact number of servers.
>> Is there a way to have variate number of options?
>>
>>
>>
>> Thanks in advance,
>>
>> Ana
>>
>>
>>
>> *From:* Samuel Cozannet [mailto:samuel.cozannet at canonical.com]
>> *Sent:* Thursday, August 20, 2015 11:06 AM
>> *To:* John Meinel
>> *Cc:* Amir Sanjar; Ana Tomic; Juju email list; Alberto Ghedin
>> *Subject:* Re: [Juju] Multiple sub service with a relation
>>
>>
>>
>> Thanks John!
>>
>> Allow me to rephrase as I am not sure I am following. Are saying we could
>> have a declarative format in the configuration of the charm that would
>> apply to relations created like:
>>
>> "datasources" : [
>>
>> { "name": "mysql",
>>
>> "datasets": [ "ds1", "ds2", ... ],
>> },
>>
>> { "name": "mongodb",
>>
>> "datasets": [ "ds3", "ds4", ... ],
>> },
>>
>> ...
>> ]
>>
>>
>>
>> and then config-changed hook would replay the creation of relations for
>> any new datasets?
>>
>> @Alberto, Ana: if my understanding is correct, this would be a way to
>> expose the configuration of the datasets / schemas from the charm config.
>> Some code to generate to manage errors (absence of dataset, absence of
>> relation to datasource, wrong datasource definition...) but it seems closer
>> to Juju's philosophy than using actions.
>>
>> ++
>>
>> Sam
>>
>>
>>
>> On Thu, Aug 20, 2015 at 1:30 AM, John Meinel <john at arbash-meinel.com>
>> wrote:
>>
>> Would this just be config on the charm that would eventually become
>> config on the relation?
>>
>>
>>
>>
>> Best,
>>
>> Samuel
>>
>>
>>
>> --
>>
>> Samuel Cozannet
>>
>> Cloud, Big Data and IoT Strategy Team
>>
>> Business Development - Cloud and ISV Ecosystem
>>
>> Changing the Future of Cloud
>> Ubuntu <http://ubuntu.com> / Canonical UK LTD <http://canonical.com> /
>> Juju <https://jujucharms.com>
>>
>> samuel.cozannet at canonical.com
>>
>> mob: +33 616 702 389
>>
>> skype: samnco
>>
>> Twitter: @SaMnCo_23
>> [image: Image removed by sender. View Samuel Cozannet's profile on
>> LinkedIn] <https://es.linkedin.com/in/scozannet>
>>
>
>
> --
> 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/20150820/5bffc607/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~WRD000.jpg
Type: image/jpeg
Size: 823 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/juju/attachments/20150820/5bffc607/attachment.jpg>
More information about the Juju
mailing list