Re: How should we change default config values in charms?
On 16 August 2015 at 19:41, Mark Shuttleworth m...@ubuntu.com wrote: On 14/08/15 04:56, Stuart Bishop wrote: I've discussed similar things with regard to the PostgreSQL charm and autotuning, with the decision being that charm defaults should be set so things 'just work' in a development environment. Yes, charm defaults should be efficient for rapid iteration and development. Iteration and development scenarios are, as Stub points out, orders of magnitude more common than production scenarios. Interesting. We have been defaulting to production settings, as we don't want to deploy an incorrect/unsafe config in production by omission, especially security related config. I see the motivation of making it easier for people to get going though, but IMO, from an operational standpoint, development defaults are concerning. I think maybe there is a distinction between performance defaults and security defaults, and defaults can be dev on the former, and production on the latter, maybe? In future, we might designate whole environments as dev, test or production, so that charms could auto-tune differently. Sounds good, we do something similar manually. Thanks -- Simon -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: How should we change default config values in charms?
On Mon, Aug 17, 2015 at 6:03 AM, Simon Davy bloodearn...@gmail.com wrote: Interesting. We have been defaulting to production settings, as we don't want to deploy an incorrect/unsafe config in production by omission, especially security related config. Interesting indeed! That's totally opposite of what I was expecting; I was expecting you to be explicit across the board. Also if anyone from Canonical IS can chip in I would be interested as well. -- Jorge Castro Canonical Ltd. http://juju.ubuntu.com/ - Automate your Cloud Infrastructure -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: How should we change default config values in charms?
On 17/08/15 06:03, Simon Davy wrote: I think maybe there is a distinction between performance defaults and security defaults, and defaults can be dev on the former, and production on the latter, maybe? Agreed, defaults should be correct and secure. Mark -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Accessing files between conatiners.
On 14 August 2015 at 15:47, Sunitha Radharapu sradh...@in.ibm.com wrote: Hi Andrew, IBM MobileFirst Server product have an option to connect to Remote database(DB2), But to install MobileFirst Server with remote database I need a to get an IBM db2 jar file form DB2 database which is present in another container. If DB2 and MobileFirst Server are in same container, I am assigning DB2 path as below in MobileFirst server install response file. data key='user.database.db2.driver' value=' */opt/ibm/db2/V10.5/java/db2jcc.jar*'/. But if DB2 is in different container how should I access this *db2jcc.jar* file? Thanks, Sunitha. If it cannot be placed at a public URL, then the DB2 service needs to provide a mechanism to distribute the db2jcc.jar file. If the MobileFirst charm is able to open a database connection to DB2, then you may be able to use the DB2 database connection to retrieve the file from the remote container. Alternatively, the ssh protocol is available on all containers. If you can set up suitable access, then the MobileFirst charm could scp the jar file from the DB2 service. If you don't mind Python code, contrib.unison in the charm-helpers project might be helpful. It sets up ssh authorization in a peer relation, but perhaps could be adapted to set up ssh authorization between your two services. -- Stuart Bishop stuart.bis...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
