Two step deployment

[Gustavo Sanchez]

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="192.168.122.28"
SSP_URL="http://$SSP_IP"

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_bundle=@registration_bundle

----
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/v2/auth/store/assertions | sudo snap ack /dev/stdin
STORE_ID=$(curl -s $SSP_URL/v2/auth/store/assertions | grep store: | awk '{print $2}')
sudo snap set core proxy.store=$STORE_ID

sudo snap install microk8s --channel=1.23/stable --classic
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)]

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.