Ubuntu – Where does Juju store a log of all commands run and their output for each unit

jujuoutput

Sometimes when deploying a service (and more specifically a new unit) for a Juju charm, an error occurs and there seems to be no way of finding out exactly what it was.

Is there some sort of output log of all commands the unit ran?

Best Answer

It appears that each unit stores a log of the commands run in /var/log/juju/unit/unit-service_name-service_number.log. You can access it by taking advantage of Juju's ssh command like so:

juju ssh service_name/service_number

This will drop you into a shell for that unit. You can then use a text editor or even just cat | less to read the log.

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.

Ubuntu – Juju and problem with subcontainers deployment on LXC

The OpenStack Autopilot will (under the hood) use the MAAS provider for Juju, you can't use the Landscape OpenStack Autopilot with a local Juju environment.

That said, you can use the Ubuntu OpenStack Installer's single installer mode to limit your hardware footprint to one machine. It will install OpenStack in LXC containers on your machine.

Your error from attempting to nest LXCs is solved by following the steps in the Server Guide, note that using nested LXCs this way to deploy OpenStack is unsupported, please follow the single installer path if you can't have enough hardware to deploy OpenStack in the Autopilot.