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 < [email protected]> 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> > [email protected] > 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 <[email protected]> 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:[email protected]] >> *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 <[email protected]> >> 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> >> >> [email protected] >> >> 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
