Accessing files between conatiners.
Hi, I have a scenario where my application is connecting to Remote DB. Example: If my DB is running in container 1 and my application is running in container 2 , Is it possible to access the files of container 1(where my DB is installed) from container 2(where my application is installed).? Can you please provide any solution for these kind of scenarios? Thanks, Sunitha.-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
juju supported 1.22.8 is released
# juju-core 1.22.8 A new supported release of Juju, juju-core 1.22.8, is now available. This release replaces version 1.22.6. ## Getting Juju juju-core 1.22.8 is available for Wily and backported to earlier series in the following PPA: https://launchpad.net/~juju/+archive/1.22 Windows and OS X users will find installers at: https://launchpad.net/juju-core/+milestone/1.22.8 ## Notable Changes This releases addresses stability and performance issues. ## Resolved issues * Juju uses proxy to access bootstrap node Lp 1478660 * Juju environment not usable after the upgrade Lp 1473517 Finally We encourage everyone to subscribe the mailing list at juju-...@lists.canonical.com, or join us on #juju-dev on freenode. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
juju supported 1.22.8 is released
# juju-core 1.22.8 A new supported release of Juju, juju-core 1.22.8, is now available. This release replaces version 1.22.6. ## Getting Juju juju-core 1.22.8 is available for Wily and backported to earlier series in the following PPA: https://launchpad.net/~juju/+archive/1.22 Windows and OS X users will find installers at: https://launchpad.net/juju-core/+milestone/1.22.8 ## Notable Changes This releases addresses stability and performance issues. ## Resolved issues * Juju uses proxy to access bootstrap node Lp 1478660 * Juju environment not usable after the upgrade Lp 1473517 Finally We encourage everyone to subscribe the mailing list at juju-...@lists.canonical.com, or join us on #juju-dev on freenode. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
How should we change default config values in charms?
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
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: [Ecosystem-engineering] The future of Charm Helpers
On Wed, Aug 12, 2015 at 7:38 AM, Marco Ceppi marco.ce...@canonical.com wrote: I can see how this helps for discoverability for those already pretty intimate with the code base, but a lot of the key complaints we've gotten around new authors getting started is there is just an overwhelming amount of code. I honestly can't understand the argument that the current situation lends itself to discoverability in any fashion. I contribute to charmhelpers and work on many charms, and I have pretty much never looked at contrib because it's a giant mess. However, I don't actually think that splitting it will help discoverability in and of itself, because that just takes one big mess and breaks it in to many smaller messes. But I do think it's a step in the right direction, because it gives the owners of each piece far more freedom to iterate on their part to make it better. Then we'd want to have a central location where we collect and list the individual packages (namespace packages could help here, but an easy registration process, built in to the tooling, would work, as well). This list would link to those packages' documentation (encouraging them to improve their docs; I'm looking at you, http://pythonhosted.org/charmhelpers/api/charmhelpers.contrib.ssl.html) and could even have call-outs for particularly useful packages. And your test harnesses are already setup for you. It is easy to add new cool stuff, and its tests. And those tests get run under both Python 2 and Python 3 with the same versions of dependencies and your cool stuff is much more likely to work with other peoples cool stuff. I know for a fact if things get spit out they will have less rigorous testing, and we will end up with tech debt Py2 only modules for example, or conflicting dependencies. If we provide similar scaffolding as we have now for those projects I don't see why they wouldn't continue this way, if people don't take pride in their projects they either don't get used or get forked and made better Agreed. We could create a charm-tools createlib or similar command that provides you with a skeleton with all the scaffolding set up for you. As long as the individual libraries are discoverable (namespaced) or registered (via a make target in the scaffolding, perhaps), then we could (semi-)automatically add them to our testing infrastructure. On Wed, Aug 12, 2015 at 6:11 AM Stuart Bishop stuart.bis...@canonical.com wrote: But I don't see the large tree as a problem. Its not unwieldy. And you don't have to worry about anything dumped into contrib, except from the perspective of if it is worth migrating it to the core area and how much work it would be (documentation, ensuring consistency, maintainability etc.). I don't see the large tree as a problem because you next talk about packaging. The large tree isn't a problem from the user's perspective, it's a problem for the people trying to maintain their specific bits of contrib. It creates a barrier to entry that encourages long-lived forks of charm-helpers and perpetuates the charm-helpers-sync terribleness. The main reason I will not be using your proposed packages for quite some time is that I like to add things to charm-helpers and fix bugs while working on my charms. I can't do that if I need to wait for a release cycle, even if you could get it down to 24 hours. I will remain using charm-helpers-sync.py, until I can switch to nested git branches, but that is fine. Packages will still make lots of other people's lives easier. Right. This is exactly *why* we want to split charm-helpers. charm-helpers-sync is just about the worst way to solve the dev cycle problem that there is. You mentioned git submodules as an alternative, which would be better, as is jujuresources, make sdist and moving a tarball, composer, and any number of other options. But the point is that if we can pare down the number of things in charmhelpers, it makes it much easier for any given component to be iterated on. The number of changes to charm-helpers would settle down drastically once it was pared down, making the dev cycle and packaging issues much more tractable. I tend to think charmhelpers.core should provide wrappers around the juju hook environment, matching the documented juju hook environment behavior, and required low level primitives you need for writing charms. It is the foundation for the rest of charm-helpers, which can provide higher level and friendlier interfaces. I believe that these higher level tools should be Pythonic. So your cli wrappers can publish charmhelpers.core for people insane or uneducated enough to write Bash charms, and the trivial charmhelpers.core would be trivially ported to other high level languages. But porting the Python decorators provided by charmhelpers.coordinator or the Pythonic datastructures provided by charmhelpers.context would not be helpful. Nor would porting charmhelpers.core.templating,
Re: Accessing files between conatiners.
Hi Sunitha, We intend to support shared filesystems in the core of Juju, but this is not currently available. You could use NFS if a shared filesystem is appropriate. Can you describe the problem you're trying to solve by sharing files? There may be a better approach that will work today. Cheers, Andrew On Thu, Aug 13, 2015 at 7:52 PM Sunitha Radharapu sradh...@in.ibm.com wrote: Hi, I have a scenario where my application is connecting to Remote DB. Example: If my DB is running in container 1 and my application is running in container 2 , Is it possible to access the files of container 1(where my DB is installed) from container 2(where my application is installed).? Can you please provide any solution for these kind of scenarios? Thanks, Sunitha. -- 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
