| 2015-10-14 00:15:37 |
Michael Nelson |
bug |
|
|
added bug |
| 2015-10-14 00:18:26 |
Michael Nelson |
description |
Steps to repro:
1) Pull a mojo spec branch (or switch to a different spec) - mojo-u1-project-A
2) `mojo run`
Expected result: mojo runs the main manifest for mojo-u1-project-A
Actual result: A bunch of env vars (at least MOJO_STAGE=ols/mojo-u1-X/devel, MOJO_WORKSPACE and MOJO_SPEC) need to be defined / exported.
3) debug/develop, then destroy juju env and rebootstrap
3) cd/switch to a different spec - mojo-u1-project-B
4) `mojo run`
Expected result: mojo runs the main manifest for mojo-u1-project-B
Actual result: A bunch of env vars need to be redefined / exported, and can result in contamination from mojo-u1-project-A
This isn't an issue for deployments/IS, as a deployment is setup once, env exported, and things don't change (at least, you don't switch to a different spec in that env). But for a typical (?) developer workflow, it isn't great.
In the past, we've worked around this by using a Makefile to define the required variables without needing to export them to the session, so we can switch branches and just run `make run`. But this has then leaked into some deployment commands (ie. currently `make manifests/upgrade-deployment` rather than just using `mojo run --manifest-file manifests/upgrade-deployment` with the correct env vars exported). And so, it's important from IS pov, that at least for all deployment related tasks, we're not using Makefiles. |
A developer should be able to pull (or switch to) a spec branch, and run one command, to run a spec.
Steps to repro:
1) Pull a mojo spec branch (or switch to a different spec) - mojo-u1-project-A
2) `mojo run`
Expected result: mojo runs the main manifest for mojo-u1-project-A
Actual result: A bunch of env vars (at least MOJO_STAGE=ols/mojo-u1-X/devel, MOJO_WORKSPACE and MOJO_SPEC) need to be defined / exported.
3) debug/develop, then destroy juju env and rebootstrap
3) cd/switch to a different spec - mojo-u1-project-B
4) `mojo run`
Expected result: mojo runs the main manifest for mojo-u1-project-B
Actual result: A bunch of env vars need to be redefined / exported, and can result in contamination from mojo-u1-project-A
This isn't an issue for deployments/IS, as a deployment is setup once, env exported, and things don't change (at least, you don't switch to a different spec in that env). But for a typical (?) developer workflow, it isn't great.
In the past, we've worked around this by using a Makefile to define the required variables without needing to export them to the session, so we can switch branches and just run `make run`. But this has then leaked into some deployment commands (ie. currently `make manifests/upgrade-deployment` rather than just using `mojo run --manifest-file manifests/upgrade-deployment` with the correct env vars exported). And so, it's important from IS pov, that at least for all deployment related tasks, we're not using Makefiles. |
|
| 2015-10-14 00:19:49 |
Michael Nelson |
summary |
mojo can't be used without exporting at least 3 env vars |
Can't switch between mojo specs easily |
|
| 2015-10-14 00:21:21 |
Michael Nelson |
description |
A developer should be able to pull (or switch to) a spec branch, and run one command, to run a spec.
Steps to repro:
1) Pull a mojo spec branch (or switch to a different spec) - mojo-u1-project-A
2) `mojo run`
Expected result: mojo runs the main manifest for mojo-u1-project-A
Actual result: A bunch of env vars (at least MOJO_STAGE=ols/mojo-u1-X/devel, MOJO_WORKSPACE and MOJO_SPEC) need to be defined / exported.
3) debug/develop, then destroy juju env and rebootstrap
3) cd/switch to a different spec - mojo-u1-project-B
4) `mojo run`
Expected result: mojo runs the main manifest for mojo-u1-project-B
Actual result: A bunch of env vars need to be redefined / exported, and can result in contamination from mojo-u1-project-A
This isn't an issue for deployments/IS, as a deployment is setup once, env exported, and things don't change (at least, you don't switch to a different spec in that env). But for a typical (?) developer workflow, it isn't great.
In the past, we've worked around this by using a Makefile to define the required variables without needing to export them to the session, so we can switch branches and just run `make run`. But this has then leaked into some deployment commands (ie. currently `make manifests/upgrade-deployment` rather than just using `mojo run --manifest-file manifests/upgrade-deployment` with the correct env vars exported). And so, it's important from IS pov, that at least for all deployment related tasks, we're not using Makefiles. |
A developer should be able to pull (or switch to) a spec branch, and run one command, to run a spec.
Steps to repro:
1) Pull a mojo spec branch (or switch to a different spec) - mojo-u1-project-A
2) `mojo run`
Expected result: mojo runs the main manifest for mojo-u1-project-A
Actual result: A bunch of env vars (at least MOJO_STAGE=ols/mojo-u1-X/devel, MOJO_WORKSPACE and MOJO_SPEC) need to be defined / exported.
3) debug/develop, then destroy juju env and rebootstrap
4) cd/switch to a different spec - mojo-u1-project-B
5) `mojo run`
Expected result: mojo runs the main manifest for mojo-u1-project-B
Actual result: A bunch of env vars need to be redefined / exported, and can result in contamination from mojo-u1-project-A
This isn't an issue for deployments/IS, as a deployment is setup once, env exported, and things don't change (at least, you don't switch to a different spec in that env). But for a typical (?) developer workflow, it isn't great.
In the past, we've worked around this by using a Makefile to define the required variables without needing to export them to the session, so we can switch branches and just run `make run`. But this has then leaked into some deployment commands (ie. currently `make manifests/upgrade-deployment` rather than just using `mojo run --manifest-file manifests/upgrade-deployment` with the correct env vars exported). And so, it's important from IS pov, that at least for all deployment related tasks, we're not using Makefiles. |
|
| 2015-10-14 10:16:16 |
Tom Haddon |
mojo: status |
New |
Confirmed |
|
| 2015-10-14 10:16:19 |
Tom Haddon |
mojo: importance |
Undecided |
Low |
|
