Re: Juju devel 2.0-alpha1 is available for testing
On Thursday, January 21, 2016, Marco Ceppi wrote: > Wow! A lot to play with tomorrow. Thanks for the release core team! > +,1 some solid bits to start testing with. Looking forward to exploring. Thanks juju-core folks. -Antonio > On Thu, Jan 21, 2016, 5:06 PM Curtis Hovey-Canonical > wrote: > >> # juju-core 2.0-alpha1 >> >> A new development release of Juju, juju-core 2.0-alpha1, is now available. >> This release replaces version 1.26-alpha3. >> >> >> ## Getting Juju >> >> juju-core 2.0-alpha1 is available for Xenial and backported to earlier >> series in the following PPA: >> >> https://launchpad.net/~juju/+archive/devel >> >> Windows, Centos, and OS X users will find installers at: >> >> https://launchpad.net/juju-core/+milestone/2.0-alpha1 >> >> Development releases use the "devel" simple-streams. You must configure >> the 'agent-stream' option in your environments.yaml to use the matching >> juju agents. >> >> Upgrading from older releases to this development release is not >> supported. >> >> >> ## Notable Changes >> >> * Terminology >> * Testing Advice >> * Command Name Changes >> * Multi-Model Support Active by Default >> * Native Support for Charm Bundles >> * Multi Series Charms >> * Improved Local Charm Deployment >> * LXD Provider >> * Microsoft Azure Resource Manager Provider >> * Bootstrap Constraints, Series >> * Juju Logging Improvements >> * Unit Agent Improvements >> * API Login with Macaroons >> * MAAS 1.8 Compatibility >> >> >> ### Terminology >> >> In Juju 2.0, environments will now be referred to as "models". Commands >> which referenced "environments" will now reference "models". Example: >> >> juju get-environment >> >> will become >> >> juju get-model >> >> >> The "state-server" from Juju 1.x becomes a "controller" in 2.0. The >> change in terminology will be done across several alphas, so messages >> and errors provided by juju may still reference "environments". >> >> >> ### Testing Advice >> >> Juju 2.0's new features and behaviours will confuse older Juju clients. >> It is best to create a new juju home to ensure you can revert to a 1.x >> Juju client. You can move an existing .juju/ directory out of the way or >> create a new directory and export it for Juju to find like so: >> >> export JUJU_HOME=~/new-juju-testing >> >> If you accidentally use Juju 2.0 with a Juju 1.x home, and Juju 1.x >> reports problems with the environment, you can delete ~/.go-cookie and >> the environments/cache.yaml in the Juju home dir to unconfuse Juju 1.x. >> Juju 2.0 will store its data in a new location soon. >> >> It is not possible to test an upgrade from Juju 1.x to 2.0 at this time. >> Juju will support this in future releases. >> >> >> ### Command Name Changes >> >> After a while experimenting with nested command structures, the decision >> was made to go back to a flat command namespace as the nested commands >> always felt clumsy and awkward when being used even though they seemed >> like a good idea. >> >> So, we have the following changes: >> >> 1.25 command 2.0-alpha1 command >> >> juju environment destroy juju destroy-environment * >> juju environment get juju get-environment ** >> juju environment get-constraints juju get-constraints ** >> juju environment retry-provisioningjuju retry-provisioning >> juju environment set juju set-environment ** >> juju environment set-constraints juju set-constraints ** >> juju environment share juju share-environment >> juju environment unset juju unset-environment ** >> juju environment unshare juju unshare-environment >> juju environment users juju list-shares >> juju user add juju add-user >> juju user change-password juju change-user-password >> juju user credentials juju get-user-credentials >> juju user disable juju disable-user >> juju user enable juju enable-user >> juju user info juju show-user >> juju user list juju list-users >> >> * the behaviour of destroy-environment has changed, see the section on >> controllers below >> ** these commands existed at the top level before but become the >> recommended approach again. >> >> And for the extra commands previously under the "jes" feature flag but >> now available out of the box: >> >> juju system create-environment juju create-environment >> juju system destroyjuju destroy-controller >> juju system environments juju list-environments >> juju system kill juju kill-controller >> juju system list juju list-controllers >> juju system list-blocksjuju list-all-blocks >> juju system login juju login >> juju system remove-blocks juju remove-all
Re: Juju devel 2.0-alpha1 is available for testing
Wow! A lot to play with tomorrow. Thanks for the release core team! On Thu, Jan 21, 2016, 5:06 PM Curtis Hovey-Canonical wrote: > # juju-core 2.0-alpha1 > > A new development release of Juju, juju-core 2.0-alpha1, is now available. > This release replaces version 1.26-alpha3. > > > ## Getting Juju > > juju-core 2.0-alpha1 is available for Xenial and backported to earlier > series in the following PPA: > > https://launchpad.net/~juju/+archive/devel > > Windows, Centos, and OS X users will find installers at: > > https://launchpad.net/juju-core/+milestone/2.0-alpha1 > > Development releases use the "devel" simple-streams. You must configure > the 'agent-stream' option in your environments.yaml to use the matching > juju agents. > > Upgrading from older releases to this development release is not > supported. > > > ## Notable Changes > > * Terminology > * Testing Advice > * Command Name Changes > * Multi-Model Support Active by Default > * Native Support for Charm Bundles > * Multi Series Charms > * Improved Local Charm Deployment > * LXD Provider > * Microsoft Azure Resource Manager Provider > * Bootstrap Constraints, Series > * Juju Logging Improvements > * Unit Agent Improvements > * API Login with Macaroons > * MAAS 1.8 Compatibility > > > ### Terminology > > In Juju 2.0, environments will now be referred to as "models". Commands > which referenced "environments" will now reference "models". Example: > > juju get-environment > > will become > > juju get-model > > > The "state-server" from Juju 1.x becomes a "controller" in 2.0. The > change in terminology will be done across several alphas, so messages > and errors provided by juju may still reference "environments". > > > ### Testing Advice > > Juju 2.0's new features and behaviours will confuse older Juju clients. > It is best to create a new juju home to ensure you can revert to a 1.x > Juju client. You can move an existing .juju/ directory out of the way or > create a new directory and export it for Juju to find like so: > > export JUJU_HOME=~/new-juju-testing > > If you accidentally use Juju 2.0 with a Juju 1.x home, and Juju 1.x > reports problems with the environment, you can delete ~/.go-cookie and > the environments/cache.yaml in the Juju home dir to unconfuse Juju 1.x. > Juju 2.0 will store its data in a new location soon. > > It is not possible to test an upgrade from Juju 1.x to 2.0 at this time. > Juju will support this in future releases. > > > ### Command Name Changes > > After a while experimenting with nested command structures, the decision > was made to go back to a flat command namespace as the nested commands > always felt clumsy and awkward when being used even though they seemed > like a good idea. > > So, we have the following changes: > > 1.25 command 2.0-alpha1 command > > juju environment destroy juju destroy-environment * > juju environment get juju get-environment ** > juju environment get-constraints juju get-constraints ** > juju environment retry-provisioningjuju retry-provisioning > juju environment set juju set-environment ** > juju environment set-constraints juju set-constraints ** > juju environment share juju share-environment > juju environment unset juju unset-environment ** > juju environment unshare juju unshare-environment > juju environment users juju list-shares > juju user add juju add-user > juju user change-password juju change-user-password > juju user credentials juju get-user-credentials > juju user disable juju disable-user > juju user enable juju enable-user > juju user info juju show-user > juju user list juju list-users > > * the behaviour of destroy-environment has changed, see the section on > controllers below > ** these commands existed at the top level before but become the > recommended approach again. > > And for the extra commands previously under the "jes" feature flag but > now available out of the box: > > juju system create-environment juju create-environment > juju system destroyjuju destroy-controller > juju system environments juju list-environments > juju system kill juju kill-controller > juju system list juju list-controllers > juju system list-blocksjuju list-all-blocks > juju system login juju login > juju system remove-blocks juju remove-all-blocks > juju system use-environmentjuju use-environment > > Fundamentally, listing things should start with 'list-', and looking at > an individual thing should start with 'show-'. 'remove' is generally > used for things that can be easily added back, whereas 'destroy' is used >
Juju devel 2.0-alpha1 is available for testing
# juju-core 2.0-alpha1 A new development release of Juju, juju-core 2.0-alpha1, is now available. This release replaces version 1.26-alpha3. ## Getting Juju juju-core 2.0-alpha1 is available for Xenial and backported to earlier series in the following PPA: https://launchpad.net/~juju/+archive/devel Windows, Centos, and OS X users will find installers at: https://launchpad.net/juju-core/+milestone/2.0-alpha1 Development releases use the "devel" simple-streams. You must configure the 'agent-stream' option in your environments.yaml to use the matching juju agents. Upgrading from older releases to this development release is not supported. ## Notable Changes * Terminology * Testing Advice * Command Name Changes * Multi-Model Support Active by Default * Native Support for Charm Bundles * Multi Series Charms * Improved Local Charm Deployment * LXD Provider * Microsoft Azure Resource Manager Provider * Bootstrap Constraints, Series * Juju Logging Improvements * Unit Agent Improvements * API Login with Macaroons * MAAS 1.8 Compatibility ### Terminology In Juju 2.0, environments will now be referred to as "models". Commands which referenced "environments" will now reference "models". Example: juju get-environment will become juju get-model The "state-server" from Juju 1.x becomes a "controller" in 2.0. The change in terminology will be done across several alphas, so messages and errors provided by juju may still reference "environments". ### Testing Advice Juju 2.0's new features and behaviours will confuse older Juju clients. It is best to create a new juju home to ensure you can revert to a 1.x Juju client. You can move an existing .juju/ directory out of the way or create a new directory and export it for Juju to find like so: export JUJU_HOME=~/new-juju-testing If you accidentally use Juju 2.0 with a Juju 1.x home, and Juju 1.x reports problems with the environment, you can delete ~/.go-cookie and the environments/cache.yaml in the Juju home dir to unconfuse Juju 1.x. Juju 2.0 will store its data in a new location soon. It is not possible to test an upgrade from Juju 1.x to 2.0 at this time. Juju will support this in future releases. ### Command Name Changes After a while experimenting with nested command structures, the decision was made to go back to a flat command namespace as the nested commands always felt clumsy and awkward when being used even though they seemed like a good idea. So, we have the following changes: 1.25 command 2.0-alpha1 command juju environment destroy juju destroy-environment * juju environment get juju get-environment ** juju environment get-constraints juju get-constraints ** juju environment retry-provisioningjuju retry-provisioning juju environment set juju set-environment ** juju environment set-constraints juju set-constraints ** juju environment share juju share-environment juju environment unset juju unset-environment ** juju environment unshare juju unshare-environment juju environment users juju list-shares juju user add juju add-user juju user change-password juju change-user-password juju user credentials juju get-user-credentials juju user disable juju disable-user juju user enable juju enable-user juju user info juju show-user juju user list juju list-users * the behaviour of destroy-environment has changed, see the section on controllers below ** these commands existed at the top level before but become the recommended approach again. And for the extra commands previously under the "jes" feature flag but now available out of the box: juju system create-environment juju create-environment juju system destroyjuju destroy-controller juju system environments juju list-environments juju system kill juju kill-controller juju system list juju list-controllers juju system list-blocksjuju list-all-blocks juju system login juju login juju system remove-blocks juju remove-all-blocks juju system use-environmentjuju use-environment Fundamentally, listing things should start with 'list-', and looking at an individual thing should start with 'show-'. 'remove' is generally used for things that can be easily added back, whereas 'destroy' is used when it is not so easy to add back. ### Multi-Model Support Active by Default The multiple model support that was previously behind the "jes" developer feature flag is now enabled by default. Along with the enabling there A new concept has been introduced, that of a "controller". A Juju Controller, also sometimes called the "controller model", d
Re: Sending binaries over relations
This use-case lines up almost exactly with how we deal with the Hadoop client libraries in the Hadoop core charms. We handle this using the apache-hadoop-plugin subordinate charm. The subordinate charm provides the Hadoop libraries to the client, with the versions supported being locked in the plugin charm, and it does version matching when the plugin is connected to the Hadoop cluster to ensure that it is compatible with the cluster. Thus, the client doesn't need to worry about the Hadoop library version, and it isn't version-locked to a specific Hadoop library version. As long as the client supports the plugin relation and the plugin charm is connected to a compatible Hadoop cluster, the client knows that the provided libraries will work. The plugin charm also gives us a single charm to update with new library versions, while retaining the ability to test those libraries to ensure they work before updating the charm. There is one case of potential incompatibility that wasn't addressed in your original proposal nor in the plugin charm design as described: the case where the client itself has trouble using certain versions of the libraries. Luckily, this is relatively uncommon, and if it arises, we can address it using the same or similar "spec matching" logic that the plugin (and other Hadoop component charms) use to ensure version compatibility, as long as the plugin charm passes through the Hadoop version on the relation. On Thu, Jan 21, 2016 at 12:15 PM, Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > I'm sorry, I wasn't clear about this. I wasn't consistent enough with my > usage of Charm VS Service. The library is not for the connection between > two charms. The library is for the connection between two services (the two > services that the two Charms deploy). > > I've seen it common for Java services to use a library to connect to > another java service. The actual network protocol is unstable between > versions, but the API of the supplied library is stable. > > 2016-01-21 17:24 GMT+01:00 Nate Finch : > >> I actually don't see why you would ever need to distribute a specific >> library for connecting to an API on another charm. The charm using the >> dynamically determined client would still require a static (i.e. backward >> compatible) API on the client library (otherwise the client charm would >> have no way to know how to use the client library)... so why not just put >> that static API on the server? and then you don't need a different client. >> Obviously, you can distribute new clients with new functionality, but by >> definition, you'd need new code in the client charm to understand how to >> use that functionality. >> >> On Thu, Jan 21, 2016 at 8:55 AM Merlijn Sebrechts < >> merlijn.sebrec...@gmail.com> wrote: >> >>> Hi Mark >>> >>> >>> I understand your concern. Leaking operational details is something that >>> should not be done in Juju. Apache proxy relationship cannot be implemented >>> by Nginx because the relation leaks operational details (apache specific >>> config files). This is not 'the Juju way'. >>> >>> The reason for sharing resources actually is interoperability. Say a >>> client wants to connect to a server, then the client may need libraries to >>> do that. What libraries will be used is dependent on both the client and >>> the server. If you ship the libraries with the client, you are essentially >>> hard-coding the server version. This is also not the Juju way; information >>> like this should be passed over relations. The problem here is that both >>> Charms have to make a joint decision about what libraries, if any, to use >>> and where to get them. No Charm has full knowledge to make that decision. >>> >>> I've seen two common patterns in the wild for these kind of libraries: >>> >>> 1. The client uses its own libraries compiled for that specific version >>> of the server. >>> 2. The client uses libraries bundled with the server. >>> >>> The first case is easy: The client has full knowledge about where to get >>> the libraries. It only needs to know the server version. The server tells >>> the client his version and it's done. The second case is a little bit >>> tougher. The client has knowledge about what libraries it needs, but the >>> server has knowledge about where to get those libraries. In this case, the >>> client should request the libraries from the server, and the server should >>> have a way to send them to the client. >>> >>> If both cases are supported by the server, you can swap any client in >>> and out. This also translates nicely to the idea that a Charm gets created >>> by the person who is an expert in that service. The server experts know >>> where to get the libraries if the server has to provide them. The client >>> expert knows how to compile the libraries if the client has to compile them. >>> >>> What do you think? >>> >>> >>> >>> >>> *PS: I don't think this should be done on stack level, since the shared >>> libraries are
Re: Configuring environments.yaml for lxd
I think LXD is only in 1.26-alpha3 which you can get from ppa:juju/devel On Thu, Jan 21, 2016, 10:30 AM Daniel Bidwell wrote: > I have reinstalled my machine with ubuntu 15.10 to get lxd. I have > juju-1.25.0-wily-amd64. lxc image list images: returns a list of > images and I have created an lxc container with: > lxc launch images:ubuntu/trusty/amd64 lxc-name > > I have an entry in .juju/environments.yaml that looks like: > > lxd-local: > type: lxd > container: lxc > default-series: trusty > admin-secret: local-lxc > > juju status returns > > environment "lxd-local" has an unknown provider type "lxd" > > What am I still missing? What do I need to do to recognize lxd as a > provider? > -- > Daniel Bidwell > > > -- > 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
Configuring environments.yaml for lxd
I have reinstalled my machine with ubuntu 15.10 to get lxd. I have juju-1.25.0-wily-amd64. lxc image list images: returns a list of images and I have created an lxc container with: lxc launch images:ubuntu/trusty/amd64 lxc-name I have an entry in .juju/environments.yaml that looks like: lxd-local: type: lxd container: lxc default-series: trusty admin-secret: local-lxc juju status returns environment "lxd-local" has an unknown provider type "lxd" What am I still missing? What do I need to do to recognize lxd as a provider? -- Daniel Bidwell -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Sending binaries over relations
I'm sorry, I wasn't clear about this. I wasn't consistent enough with my usage of Charm VS Service. The library is not for the connection between two charms. The library is for the connection between two services (the two services that the two Charms deploy). I've seen it common for Java services to use a library to connect to another java service. The actual network protocol is unstable between versions, but the API of the supplied library is stable. 2016-01-21 17:24 GMT+01:00 Nate Finch : > I actually don't see why you would ever need to distribute a specific > library for connecting to an API on another charm. The charm using the > dynamically determined client would still require a static (i.e. backward > compatible) API on the client library (otherwise the client charm would > have no way to know how to use the client library)... so why not just put > that static API on the server? and then you don't need a different client. > Obviously, you can distribute new clients with new functionality, but by > definition, you'd need new code in the client charm to understand how to > use that functionality. > > On Thu, Jan 21, 2016 at 8:55 AM Merlijn Sebrechts < > merlijn.sebrec...@gmail.com> wrote: > >> Hi Mark >> >> >> I understand your concern. Leaking operational details is something that >> should not be done in Juju. Apache proxy relationship cannot be implemented >> by Nginx because the relation leaks operational details (apache specific >> config files). This is not 'the Juju way'. >> >> The reason for sharing resources actually is interoperability. Say a >> client wants to connect to a server, then the client may need libraries to >> do that. What libraries will be used is dependent on both the client and >> the server. If you ship the libraries with the client, you are essentially >> hard-coding the server version. This is also not the Juju way; information >> like this should be passed over relations. The problem here is that both >> Charms have to make a joint decision about what libraries, if any, to use >> and where to get them. No Charm has full knowledge to make that decision. >> >> I've seen two common patterns in the wild for these kind of libraries: >> >> 1. The client uses its own libraries compiled for that specific version >> of the server. >> 2. The client uses libraries bundled with the server. >> >> The first case is easy: The client has full knowledge about where to get >> the libraries. It only needs to know the server version. The server tells >> the client his version and it's done. The second case is a little bit >> tougher. The client has knowledge about what libraries it needs, but the >> server has knowledge about where to get those libraries. In this case, the >> client should request the libraries from the server, and the server should >> have a way to send them to the client. >> >> If both cases are supported by the server, you can swap any client in and >> out. This also translates nicely to the idea that a Charm gets created by >> the person who is an expert in that service. The server experts know where >> to get the libraries if the server has to provide them. The client expert >> knows how to compile the libraries if the client has to compile them. >> >> What do you think? >> >> >> >> >> *PS: I don't think this should be done on stack level, since the shared >> libraries are only relevant to the two related Charms. The relevance of the >> libraries is on relation-level so they should be handled by the relations.* >> >> >> >> >> 2016-01-21 13:58 GMT+01:00 Mark Shuttleworth : >> >>> >>> Two thoughts. >>> >>> First, I think it's interesting that you see resources as such a dynamic >>> thing. I believe the current model accommodates this (we considered >>> user-provided resources, and what you are describing are essentially >>> charm-generated resources, but they would behave the same way). >>> >>> Second, I am sceptical about cross-charm resource coordination. We go to >>> great lengths to keep a service encapsulated. Each service is generally >>> prevented from knowing too much about what is going on in the service >>> next door. This is deliberate because it leads to the development of >>> services which can more naturally be swapped out, because the web of >>> expectations between related services is limited by what they can >>> possibly know about each other. What you are describing suggests too >>> intimate an awareness between two services of their exact operational >>> implementation. >>> >>> That said, we do have an idea in the "futures" department, which is a >>> higher-level charm that would manage a group of charms. While they would >>> remain encapsulated, the higher-level charm would have admin-like >>> visibility across all of the services it is supervising. Imagine an >>> "openstack" charm which can command-and-control events across all the >>> constituent services. In THAT case, yes, it would make sense for the >>> higher level charm, which we call a "st
Re: Sending binaries over relations
I actually don't see why you would ever need to distribute a specific library for connecting to an API on another charm. The charm using the dynamically determined client would still require a static (i.e. backward compatible) API on the client library (otherwise the client charm would have no way to know how to use the client library)... so why not just put that static API on the server? and then you don't need a different client. Obviously, you can distribute new clients with new functionality, but by definition, you'd need new code in the client charm to understand how to use that functionality. On Thu, Jan 21, 2016 at 8:55 AM Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > Hi Mark > > > I understand your concern. Leaking operational details is something that > should not be done in Juju. Apache proxy relationship cannot be implemented > by Nginx because the relation leaks operational details (apache specific > config files). This is not 'the Juju way'. > > The reason for sharing resources actually is interoperability. Say a > client wants to connect to a server, then the client may need libraries to > do that. What libraries will be used is dependent on both the client and > the server. If you ship the libraries with the client, you are essentially > hard-coding the server version. This is also not the Juju way; information > like this should be passed over relations. The problem here is that both > Charms have to make a joint decision about what libraries, if any, to use > and where to get them. No Charm has full knowledge to make that decision. > > I've seen two common patterns in the wild for these kind of libraries: > > 1. The client uses its own libraries compiled for that specific version of > the server. > 2. The client uses libraries bundled with the server. > > The first case is easy: The client has full knowledge about where to get > the libraries. It only needs to know the server version. The server tells > the client his version and it's done. The second case is a little bit > tougher. The client has knowledge about what libraries it needs, but the > server has knowledge about where to get those libraries. In this case, the > client should request the libraries from the server, and the server should > have a way to send them to the client. > > If both cases are supported by the server, you can swap any client in and > out. This also translates nicely to the idea that a Charm gets created by > the person who is an expert in that service. The server experts know where > to get the libraries if the server has to provide them. The client expert > knows how to compile the libraries if the client has to compile them. > > What do you think? > > > > > *PS: I don't think this should be done on stack level, since the shared > libraries are only relevant to the two related Charms. The relevance of the > libraries is on relation-level so they should be handled by the relations.* > > > > > 2016-01-21 13:58 GMT+01:00 Mark Shuttleworth : > >> >> Two thoughts. >> >> First, I think it's interesting that you see resources as such a dynamic >> thing. I believe the current model accommodates this (we considered >> user-provided resources, and what you are describing are essentially >> charm-generated resources, but they would behave the same way). >> >> Second, I am sceptical about cross-charm resource coordination. We go to >> great lengths to keep a service encapsulated. Each service is generally >> prevented from knowing too much about what is going on in the service >> next door. This is deliberate because it leads to the development of >> services which can more naturally be swapped out, because the web of >> expectations between related services is limited by what they can >> possibly know about each other. What you are describing suggests too >> intimate an awareness between two services of their exact operational >> implementation. >> >> That said, we do have an idea in the "futures" department, which is a >> higher-level charm that would manage a group of charms. While they would >> remain encapsulated, the higher-level charm would have admin-like >> visibility across all of the services it is supervising. Imagine an >> "openstack" charm which can command-and-control events across all the >> constituent services. In THAT case, yes, it would make sense for the >> higher level charm, which we call a "stack", to be able to coordinate >> resources across services under its supervision. >> >> How does that sound? >> >> Mark >> >> On 21/01/16 01:21, Merlijn Sebrechts wrote: >> > Hi John, Mark >> > >> > >> > If I understand you correctly, a Charm will be able to decide what >> version >> > of the resource it needs at runtime? This way, a Charm could tell >> related >> > Charms what version of the resource they should get? That would solve my >> > use-case almost completely... >> > >> > The only exception being the case where a Charm compiles a library >> during >> > installation and wants to dis
Re: Sending binaries over relations
Hi Mark I understand your concern. Leaking operational details is something that should not be done in Juju. Apache proxy relationship cannot be implemented by Nginx because the relation leaks operational details (apache specific config files). This is not 'the Juju way'. The reason for sharing resources actually is interoperability. Say a client wants to connect to a server, then the client may need libraries to do that. What libraries will be used is dependent on both the client and the server. If you ship the libraries with the client, you are essentially hard-coding the server version. This is also not the Juju way; information like this should be passed over relations. The problem here is that both Charms have to make a joint decision about what libraries, if any, to use and where to get them. No Charm has full knowledge to make that decision. I've seen two common patterns in the wild for these kind of libraries: 1. The client uses its own libraries compiled for that specific version of the server. 2. The client uses libraries bundled with the server. The first case is easy: The client has full knowledge about where to get the libraries. It only needs to know the server version. The server tells the client his version and it's done. The second case is a little bit tougher. The client has knowledge about what libraries it needs, but the server has knowledge about where to get those libraries. In this case, the client should request the libraries from the server, and the server should have a way to send them to the client. If both cases are supported by the server, you can swap any client in and out. This also translates nicely to the idea that a Charm gets created by the person who is an expert in that service. The server experts know where to get the libraries if the server has to provide them. The client expert knows how to compile the libraries if the client has to compile them. What do you think? *PS: I don't think this should be done on stack level, since the shared libraries are only relevant to the two related Charms. The relevance of the libraries is on relation-level so they should be handled by the relations.* 2016-01-21 13:58 GMT+01:00 Mark Shuttleworth : > > Two thoughts. > > First, I think it's interesting that you see resources as such a dynamic > thing. I believe the current model accommodates this (we considered > user-provided resources, and what you are describing are essentially > charm-generated resources, but they would behave the same way). > > Second, I am sceptical about cross-charm resource coordination. We go to > great lengths to keep a service encapsulated. Each service is generally > prevented from knowing too much about what is going on in the service > next door. This is deliberate because it leads to the development of > services which can more naturally be swapped out, because the web of > expectations between related services is limited by what they can > possibly know about each other. What you are describing suggests too > intimate an awareness between two services of their exact operational > implementation. > > That said, we do have an idea in the "futures" department, which is a > higher-level charm that would manage a group of charms. While they would > remain encapsulated, the higher-level charm would have admin-like > visibility across all of the services it is supervising. Imagine an > "openstack" charm which can command-and-control events across all the > constituent services. In THAT case, yes, it would make sense for the > higher level charm, which we call a "stack", to be able to coordinate > resources across services under its supervision. > > How does that sound? > > Mark > > On 21/01/16 01:21, Merlijn Sebrechts wrote: > > Hi John, Mark > > > > > > If I understand you correctly, a Charm will be able to decide what > version > > of the resource it needs at runtime? This way, a Charm could tell related > > Charms what version of the resource they should get? That would solve my > > use-case almost completely... > > > > The only exception being the case where a Charm compiles a library during > > installation and wants to distribute that binary to its related Charms. > > This would require the Charm to be able to push the resource to the state > > server and then distribute a link to that resource over its relations. > > > > Using the state server instead of rsync would be a lot better long-term, > I > > think. Network spaces and multi-tenancy might make it possible that a > Charm > > cannot ssh to a related Charm... > > > > > > Any thoughts on this? > > > > > > Kind regards > > Merlijn Sebrechts > > > > 2016-01-21 7:42 GMT+01:00 John Meinel : > > > >> It does feel like a good fit for resources, with the one caveat that he > >> wants to maintain a lock-step version of the resource across services. > >> There is slightly more work with the current designs for resources, in > that > >> each charm will think about its version of the resource i
Re: Sending binaries over relations
Two thoughts. First, I think it's interesting that you see resources as such a dynamic thing. I believe the current model accommodates this (we considered user-provided resources, and what you are describing are essentially charm-generated resources, but they would behave the same way). Second, I am sceptical about cross-charm resource coordination. We go to great lengths to keep a service encapsulated. Each service is generally prevented from knowing too much about what is going on in the service next door. This is deliberate because it leads to the development of services which can more naturally be swapped out, because the web of expectations between related services is limited by what they can possibly know about each other. What you are describing suggests too intimate an awareness between two services of their exact operational implementation. That said, we do have an idea in the "futures" department, which is a higher-level charm that would manage a group of charms. While they would remain encapsulated, the higher-level charm would have admin-like visibility across all of the services it is supervising. Imagine an "openstack" charm which can command-and-control events across all the constituent services. In THAT case, yes, it would make sense for the higher level charm, which we call a "stack", to be able to coordinate resources across services under its supervision. How does that sound? Mark On 21/01/16 01:21, Merlijn Sebrechts wrote: > Hi John, Mark > > > If I understand you correctly, a Charm will be able to decide what version > of the resource it needs at runtime? This way, a Charm could tell related > Charms what version of the resource they should get? That would solve my > use-case almost completely... > > The only exception being the case where a Charm compiles a library during > installation and wants to distribute that binary to its related Charms. > This would require the Charm to be able to push the resource to the state > server and then distribute a link to that resource over its relations. > > Using the state server instead of rsync would be a lot better long-term, I > think. Network spaces and multi-tenancy might make it possible that a Charm > cannot ssh to a related Charm... > > > Any thoughts on this? > > > Kind regards > Merlijn Sebrechts > > 2016-01-21 7:42 GMT+01:00 John Meinel : > >> It does feel like a good fit for resources, with the one caveat that he >> wants to maintain a lock-step version of the resource across services. >> There is slightly more work with the current designs for resources, in that >> each charm will think about its version of the resource independently. But >> we will have the fingerprint information to allow for users to compare and >> be confident that both services are using the same resource. >> >> John >> =:-> >> >> On Wed, Jan 20, 2016 at 8:53 PM, Mark Shuttleworth >> wrote: >> >>> On 20/01/16 14:24, Merlijn Sebrechts wrote: So my question is: Is there a way to send large binary files between Charms? Or is this problem better solved by using a subordinate kafka-plugin Charm like the Hadoop Charms do? >>> It sounds like you want the new "Resources" capability coming in Juju 2.0 >>> :) >>> >>> For shared large blobs (like a JVM or a big ball of libraries) the charm >>> can ask the state server to cache the blob and distribute it to all the >>> units. There are mechanisms for users to supply the blob if needed, too. >>> >>> 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: Sending binaries over relations
Hi John, Mark If I understand you correctly, a Charm will be able to decide what version of the resource it needs at runtime? This way, a Charm could tell related Charms what version of the resource they should get? That would solve my use-case almost completely... The only exception being the case where a Charm compiles a library during installation and wants to distribute that binary to its related Charms. This would require the Charm to be able to push the resource to the state server and then distribute a link to that resource over its relations. Using the state server instead of rsync would be a lot better long-term, I think. Network spaces and multi-tenancy might make it possible that a Charm cannot ssh to a related Charm... Any thoughts on this? Kind regards Merlijn Sebrechts 2016-01-21 7:42 GMT+01:00 John Meinel : > It does feel like a good fit for resources, with the one caveat that he > wants to maintain a lock-step version of the resource across services. > There is slightly more work with the current designs for resources, in that > each charm will think about its version of the resource independently. But > we will have the fingerprint information to allow for users to compare and > be confident that both services are using the same resource. > > John > =:-> > > On Wed, Jan 20, 2016 at 8:53 PM, Mark Shuttleworth > wrote: > >> On 20/01/16 14:24, Merlijn Sebrechts wrote: >> > So my question is: Is there a way to send large binary files between >> > Charms? Or is this problem better solved by using a subordinate >> > kafka-plugin Charm like the Hadoop Charms do? >> >> It sounds like you want the new "Resources" capability coming in Juju 2.0 >> :) >> >> For shared large blobs (like a JVM or a big ball of libraries) the charm >> can ask the state server to cache the blob and distribute it to all the >> units. There are mechanisms for users to supply the blob if needed, too. >> >> 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
