no documentation for deploying an existing spec

[Thomi Richards]

I can't find any mojo documentation for how to take a mojo spec that someone else has written and deploy it. As a new user to mojo, the questions I find myself asking while following your existing documentation (such as https://mojo.canonical.com/mojo-insights-article-example-deployment.html are):

 - Do I need to set up a new 'project' if I'm using an existing spec?
  - what's the difference between a spec and a project?
 - Do I need to create a new 'workspace' if I'm using an existing spec?

The docs say to run:

~~~
mojo workspace-new --project mojo-how-to --stage=mojo-how-to/devel --series trusty lp:~mojo-maintainers/mojo/mojo-specs mojo-how-to
~~~

...but I'm not sure:

 - the --stage parameter looks like a path on disk. Where is that supposed to be? do I have to be in a particular directory for this to work?
 - what's the bzr branch for? does it need to exist first? Should I change it to something I own?
 - What's the final argument for?

Similar issues exist for the other commands in the document.

This is probably obvious to the seasoned mojo user, but it's opaque to a beginner like me. It would be great if there was a document that explains "what you need to know to deploy an existing mojo spec".

Thanks,

[Tom Haddon (mthaddon)]

I'm not sure if this is the best place to discuss this, but it'll do for now, and we can figure out some other way if appropriate. To answer each question in turn:

1) The --stage parameter looks like a path on disk because it can (and does in this case) refer to a directory location within the branch for the specification. So in this case, lp:~mojo-maintainers/mojo/mojo-specs has a stage of "mojo-how-to/devel".

2) The bzr branch is the location of the specification you want to use. This has to be (currently) a bzr branch, but can be a remote branch (as in this case) or you could create a local copy of that branch and use it instead. Let's say you do this:

cd /home/ubuntu
bzr branch lp:~mojo-maintainers/mojo/mojo-specs

Now your workspace-new command could be this instead:

mojo workspace-new --project mojo-how-to --stage=mojo-how-to/devel --series trusty /home/ubuntu/mojo-specs/ mojo-how-to

It doesn't have to be a branch you own, only a branch you have access to. If you want to make changes to a service via making changes to the specification, you would obviously need it to be a branch you own (or can write to).

3) The final argument is the name of the workspace.

If these answers have been helpful, feel free to propose changes to the documentation to make them clearer. The docs themselves are generated from the source tree - see "docs/mojo/" within lp:mojo.

[Tom Haddon (mthaddon)]

Oh, and to answer the previous questions that I missed:

 - Do I need to set up a new 'project' if I'm using an existing spec?

Yes, you always need a project for a mojo run.

 - What's the difference between a spec and a project?

A spec is the definition of what will be done, and a project is where it will be done. A project has an LXC container for doing builds, and typically you'd have a juju environment for each project you're working with.

 - Do I need to create a new 'workspace' if I'm using an existing spec?

Yes, you always need a workspace for a mojo run. A workspace is just the place on disk where resources needed for a particular mojo run are collected. You may want to have multiple workspaces for a given project if you want to be able to refer to differences over time. Typically speaking when you're working with Mojo locally though, you'd have one workspace per project, and one project for each service you want to deploy.

[Launchpad Janitor (janitor)]

[Expired for mojo because there has been no activity for 60 days.]