Is it possible to a charm to ask juju to start another machine, add instances of a service or destroy instances? For instance, by doing something simular to the juju gui: how juju gui performs the creation of machines, for instance? I´d to have a service that monitors other services and add instances to scale out, for instance.
Ubuntu – What’s the best way to have a charm control Juju
juju
Related Solutions
Tha it's work! I again install ubuntu server and this time everything goes well but one thing. Now when I juju status I see this:
2012-10-04 13:32:21,110 INFO Connected to environment.
machines:
0:
agent-state: running
dns-name: node-00127968a7be.local
instance-id: /MAAS/api/1.0/nodes/node-ab7c5eb6-0e08-11e2-bb37-001185e67955/
instance-state: unknown
1:
agent-state: running
dns-name: node-001185e677fe
instance-id: /MAAS/api/1.0/nodes/node-82beae92-0e09-11e2-a134-001185e67955/
instance-state: unknown
2:
agent-state: running
dns-name: node-001185e6772b.local
instance-id: /MAAS/api/1.0/nodes/node-5c21dc18-0e0a-11e2-a134-001185e67955/
instance-state: unknown
services:
mysql:
charm: cs:precise/mysql-8
relations:
db:
- wordpress
units:
mysql/0:
agent-state: started
machine: 1
public-address: node-001185e677fe.localdomain
wordpress:
charm: cs:precise/wordpress-9
exposed: true
relations:
db:
- mysql
loadbalancer:
- wordpress
units:
wordpress/0:
agent-state: started
machine: 2
open-ports:
- 80/tcp
public-address: node-001185e6772b.local
public adress seems be strange because it's name of my nodes. I check on my router adress of node where is wordpress and type on webbrowser but I get
502 Bad Gateway nginx/1.1.19
I don't know what to do. Please help me.
awesome questions!
the tl;dr
I'd like to break your question(s) down over a couple of comments... first off, here're a couple of general approaches to integrating chef and juju:
charms hooks can use existing chef recipes that run solo-style on service units (recommended)
juju service units register with an existing chef-server using a chef-node subordinate service
These ideas haven't been implemented/tested yet for chef, but the puppet equivalents exist.
the... um.. not-so-short answer
Here's a little more of a breakdown of two approaches to integrating chef and juju:
Juju as top-dog
Here juju runs the show. The biggest value juju provides is event coordination during distributed configuration management... hence the "service orchestration" moniker. Juju charms consist of hooks which are called by juju at "the right time" when coordinating service management. The implementation of these hooks is pretty much open. They're shell scripts, source code, puppet manifests, or... chef recipes.
Juju breaks bits of any service config up into:
"installation".. the bits that're specific to installing a particular service onto a node
"relation".. the bits of config that're needed to relate that service to some other service
The key to using chef recipes as hook implementations is exactly this... you have to make sure that the recipes you're using respect this separation of concerns. Otherwise, there's nothing that prevents using off-the-shelf cookbooks. You can leverage existing recipes you've spent time/money to develop.... You just need to make sure you can call the relation-specific stuff separately from the installation-specific stuff.
We need some examples of this, but I think it'll be popular b/c chef has a great dsl, a great templating tool, and is much more pleasant to use than bash when writing complex config. For simple config, chef recipes are a little overkill imo, so this method of integration is pretty much the best of both worlds... and has serious legs going forward.
Chef as top-dog
The idea here is to integrate juju services into an existing chef-server managed infrastructure. To do this, you'd need to write a chef-node subordinate charm. This subordinate service would be attached to primary juju services and would effectively register these services as nodes (in particular roles) with the chef server. Subs can be attached during juju service startup, or anytime later throughout each service's lifecycle.
I'm thinking this'd be quite similar to the puppet-node sub. All necessary keys, roles, etc would be specified via config to the chef-node subordinate charm. I'd start there. A more sophisticated approach would be for the chef-node sub to interrogate both the primary service it's attached to and its chef-server to dynamically determine roles, but that'd be quite a bit harder than just specifying them in config for the sub.
Opinions
I'd definitely recommend method 1 above, if possible. Having the coordination layer on top of the configuration tools will probably work well long-term. Needless to say, real-world infrastructures might be some combo or variation of both approaches for a period of time... especially during migration. Planned coexistance using method 2 would probably only work if the components managed by both tools were somewhat orthogonal to each other. Not sure exactly what that would look like. Perhaps juju and chef manage separate relatively decoupled services? I suspect it might work well to let juju manage primary services and have chef manage more infrastructure aspects. Dunno. That's a bit of a longer discussion though :)
Side note... you can also use juju to manage chef-server itself... even large complex multi-tier chef-server installations. I haven't looked at the chef-server charm lately, but if it doesn't currently handle tiering and separation of services, then it can certainly be made to.
I'd love to see more examples of both types of chef integration mentioned above... it's been on my wish / todo list for a while, but has yet to bubble up high enough in priority to get done... please help if you're interested!
ok, that's a decent chunk of rambling :)... let's start there, then we can go into more detail in subsequent comment blocks.
Best Answer
There are a few ways this is possible.
Installing and calling Juju binaries
The charms.reactive layer at https://github.com/galgalesh/juju-client does this. The basic process is to first bootstrap the environment, then deploy a charm passing in all the configuration, state and secrets files necessary to control the environment. The charm installs the juju client, rebuilds ~/.juju, and can now control the environment from the inside.
This layer is still experimental. If you encounter any issues, file a bug report in the github repo.
Using the Python Juju client
There is a Python client to manage Juju environments. This client calls the Juju api. You could put this in a Charm.
Using the Go API
You can find the go api here: https://godoc.org/github.com/juju/juju/api
Using Perl bindings
If you're into that sort of stuff: https://metacpan.org/release/Juju
Calling the api directly
For more information on that, see this question: Is there a Juju REST API?