containerless only works for my user, not the service user
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mojo: Continuous Delivery for Juju |
Triaged
|
Low
|
Unassigned |
Bug Description
(mojo-prod-
2020-07-24 16:05:38 [INFO] Using pre-existing container class lxc
2020-07-24 16:05:38 [ERROR] Unknown error
Traceback (most recent call last):
File "/usr/lib/
args.func(args)
File "/usr/lib/
return method(*args, **kwargs)
File "/usr/lib/
create_
File "/usr/lib/
project.
File "/usr/lib/
raise ProjectCreation
mojo.project.
but
[sourcing in the .mojorc variables from the other user's environment]
nick@wekufe:~$ mojo project-new --series focal mojo-prod-
2020-07-24 16:07:14 [INFO] Checking mojo-prod-
2020-07-24 16:07:14 [INFO] Containerless project has no container config
2020-07-24 16:07:14 [INFO] Checking mojo-prod-
2020-07-24 16:07:14 [INFO] Checking mojo-prod-
Related branches
- Tom Haddon: Approve
- Canonical IS Reviewers: Pending requested
-
Diff: 16 lines (+5/-1)1 file modifiedmojo/project.py (+5/-1)
Changed in mojo: | |
status: | New → Triaged |
importance: | Undecided → Low |
> 2020-07-24 16:05:38 [INFO] Using pre-existing container class lxc
This is saying there's a pre-existing container with class "lxc", so it's ignoring your "-c containerless"; not that there's a pre-existing container class "lxc", as I've always read it. (I've created an MP to make this message less ambiguous.)
This is most likely because srv-mojo created the project with a container.
mojo should handle this itself somehow, if only by emitting a diagnostic and halting, but deleting the project first should work around the problem.
Another option might be to hack /srv/mojo/ $MOJO_PROJECT/ $MOJO_SERIES/ .project (no, there's no reason for this file to be so hard to find!) but delete and recreate seems simpler.