Two step deployment
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| snap-store-proxy-charm |
New
|
Undecided
|
Unassigned | ||
| snapstore-client |
New
|
Undecided
|
Unassigned | ||
Bug Description
When deploying the charm I executed the following steps:
1. Create Ubuntu One account
2. Enter into snapcraft.io and accept the terms
3. Deploy bundle
juju deploy ./bundle.yaml
4. Get registration_bundle file
juju status | grep snap-store-proxy
SSP_IP=
SSP_URL="http://
sudo snap install snapcraft --classic # Seems to be required for store-admin
sudo snap install store-admin
store-admin login $SSP_URL
[User interaction]
store-admin register $SSP_URL registration_bundle
[User interaction]
4. Set config registration_bundle to charm
juju config snap-store-proxy registration_
----
This feels kind of a chicken and egg problem or two steps deployment
For the bundle to work it needs the registration_bundle file
And to generate the registration_bundle file it needs the bundle deployed
Could this be automated somehow to have the store-admin steps be run inside the charm?
This with the purpose of having to deploy in a single step having minimal user interaction
Can the store-admin commands be used without user interaction, with a file or parameters?
----
Then to test the client I excecuted the following:
curl -s $SSP_URL/
STORE_ID=$(curl -s $SSP_URL/
sudo snap set core proxy.store=
sudo snap install microk8s --channel=
sudo snap refresh microk8s --channel=1.24/edge
----
We could also add some example steps to the documentation so there is no need to jump between store-admin, snap-store-proxy and snap-store-proxy docs when deploying the charm
| Wouter van Bommel (woutervb) wrote | #1 |
This relates to a few different items, I will try to answer some of the findings and clarify the distinction between them,
1. Documentation, we need a seamless way to link back and forth the documentation, so that for the end user it isn't a difference in experience wetter the documents originate from the proxy, the charm or something else. At the same time, we should ensure that every project is the 'owner' of its own documentation, to prevent that development in one, renders instructions in another useless.
2. The problem you describe relates to registering a proxy on it's ip. There is little that we can do about that, as we don't know what the ip will be on forehand. Unless you first deploy a bare ubuntu unit and then target the proxy to this same one. When domain names are used, this problem doesn't arise, as then the bundle can be create beforehand.
3. Store-admin commands won't be able to be completely without user interaction if 2fa is used. Linked this project here as it should be possible to make most of the user interaction elements a parameter. However there will always be a step where the user needs to be identified.