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: How should we change default config values in charms?
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. In future, we might designate whole environments as dev, test or production, so that charms could auto-tune differently. Mark -- 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?
+1 for different default configs by environment. I consider this issue a big block for new charmers Em 16/08/2015 19:03, Mark Shuttleworth m...@ubuntu.com escreveu: 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. In future, we might designate whole environments as dev, test or production, so that charms could auto-tune differently. Mark -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- 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?
I believe there is work being done so that you can do juju get and send that output directly into juju set or even juju deploy --config. And I think that's a much better story around repeatable deployments than trying to make sure the defaults never change. If they really care about repeatable they're probably going to pin the version of the charm anyway. So I'd bias clearly on the fix something that isn't working well rather than fear change because someone might depend on the current sketchy behaviour. Obviously the call is somewhat situational. John =:- On Aug 13, 2015 10:03 AM, Jorge O. Castro jo...@ubuntu.com wrote: Hi everyone, See: https://bugs.launchpad.net/bugs/1373862 This morning Marco proposed that we change the default dataset-size from 80% of the memory to 128M. Ryan thinks that before we make a default change like this that we should discuss the implications, for example, if you have an existing Juju MySQL deployment, and say you want to replicate that in another environment, the default change is an unexpected surprise to the user. I am of the opinion that MySQL is one of the first services people play with when trying Juju and that the charm not working ootb with the local provider is a big papercut we'd like to fix. -- 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 -- 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?
Actually: the example bundle I listed is moot. It uses the percona-cluster charm. And it's pinned to a specific charm revision like a good little bundle. On Thu, Aug 13, 2015 at 10:57 AM, Ryan Beisner ryan.beis...@canonical.com wrote: Greetings, I'm all for sensible defaults and eliminating or mitigating paper cut risk. Those are all good things. I do think we need to take a hard look at the potential impact of a default charm config option value change, any time that is considered. My main concern is that, in changing a default value, we risk breaking existing users. But as long as we give advanced notice, eta, updated docs, release notes, etc., I think it could be completely reasonable to pursue a default value change. As I understand the original motivation behind this proposed default value change, when deploying the mysql charm into lxc, it may fail unless the dataset-size option value is set to something like 128MB instead of the default 80%. So, a user may not be able to just drop the mysql charm into lxc with the defaults and experience success. They need to set the config option value to something workable for their environment. That impacts adoption. ie. It doesn't just work. If we do make the default value change, we need to take a look at the bundles in the charm store to identify and adjust any which rely on the established default value. For example... ;-) and I'm not at all biased: https://jujucharms.com/openstack-base/36 ( https://api.jujucharms.com/charmstore/v4/bundle/openstack-base-36/archive/bundle.yaml ) That one is easy enough to identify and fix, but it underscores the need to take the time to identify, evaluate and discuss the risks, then define the things-to-do, and proceed if that is the consensus. Cheers, Ryan On Thu, Aug 13, 2015 at 10:15 AM, John Meinel j...@arbash-meinel.com wrote: I believe there is work being done so that you can do juju get and send that output directly into juju set or even juju deploy --config. And I think that's a much better story around repeatable deployments than trying to make sure the defaults never change. If they really care about repeatable they're probably going to pin the version of the charm anyway. So I'd bias clearly on the fix something that isn't working well rather than fear change because someone might depend on the current sketchy behaviour. Obviously the call is somewhat situational. John =:- On Aug 13, 2015 10:03 AM, Jorge O. Castro jo...@ubuntu.com wrote: Hi everyone, See: https://bugs.launchpad.net/bugs/1373862 This morning Marco proposed that we change the default dataset-size from 80% of the memory to 128M. Ryan thinks that before we make a default change like this that we should discuss the implications, for example, if you have an existing Juju MySQL deployment, and say you want to replicate that in another environment, the default change is an unexpected surprise to the user. I am of the opinion that MySQL is one of the first services people play with when trying Juju and that the charm not working ootb with the local provider is a big papercut we'd like to fix. -- 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 -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- 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?
Greetings, I'm all for sensible defaults and eliminating or mitigating paper cut risk. Those are all good things. I do think we need to take a hard look at the potential impact of a default charm config option value change, any time that is considered. My main concern is that, in changing a default value, we risk breaking existing users. But as long as we give advanced notice, eta, updated docs, release notes, etc., I think it could be completely reasonable to pursue a default value change. As I understand the original motivation behind this proposed default value change, when deploying the mysql charm into lxc, it may fail unless the dataset-size option value is set to something like 128MB instead of the default 80%. So, a user may not be able to just drop the mysql charm into lxc with the defaults and experience success. They need to set the config option value to something workable for their environment. That impacts adoption. ie. It doesn't just work. If we do make the default value change, we need to take a look at the bundles in the charm store to identify and adjust any which rely on the established default value. For example... ;-) and I'm not at all biased: https://jujucharms.com/openstack-base/36 ( https://api.jujucharms.com/charmstore/v4/bundle/openstack-base-36/archive/bundle.yaml ) That one is easy enough to identify and fix, but it underscores the need to take the time to identify, evaluate and discuss the risks, then define the things-to-do, and proceed if that is the consensus. Cheers, Ryan On Thu, Aug 13, 2015 at 10:15 AM, John Meinel j...@arbash-meinel.com wrote: I believe there is work being done so that you can do juju get and send that output directly into juju set or even juju deploy --config. And I think that's a much better story around repeatable deployments than trying to make sure the defaults never change. If they really care about repeatable they're probably going to pin the version of the charm anyway. So I'd bias clearly on the fix something that isn't working well rather than fear change because someone might depend on the current sketchy behaviour. Obviously the call is somewhat situational. John =:- On Aug 13, 2015 10:03 AM, Jorge O. Castro jo...@ubuntu.com wrote: Hi everyone, See: https://bugs.launchpad.net/bugs/1373862 This morning Marco proposed that we change the default dataset-size from 80% of the memory to 128M. Ryan thinks that before we make a default change like this that we should discuss the implications, for example, if you have an existing Juju MySQL deployment, and say you want to replicate that in another environment, the default change is an unexpected surprise to the user. I am of the opinion that MySQL is one of the first services people play with when trying Juju and that the charm not working ootb with the local provider is a big papercut we'd like to fix. -- 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 -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
