remove local version of metadata after `snet service publish` command?

[astroseger]

We should choose between two ideology: we keep local version of service_metadata and we rely on it or we rely exclusively on the metadata in registry. The current version of snet-cli was written taking into account the second ideology.

See discussing #174

I would propose to enforce the obsolescence of the local version of metadata by actually removing it after snet service publish. It would remove a lot of confusion...

@ferrouswheel

[ferrouswheel]

If we keep a temporary version locally and modify it with snet-cli commands it means we still have a local version at some point and it is up to the developer to remember to push the metadata after making changes.

If we want the second ideology, we should make changes to metadata atomic: download file to temp file, make change, then reupload.

Alternatively, tools like kubernetes provide simple tools to "get" and "push" service descriptions, and I think we should remove the methods on snet-cli that make changes to the local file. Instead we should "get" the metadata file locally, let the developer edit it, then when they "push" it we should validate the content is correct.

I find it more awkward running separate commands than just editing a config file that has good documentation. I think most developers would feel the same way unless these commands are shortcuts for the entire process of download->modify->upload->delete local file.

[ferrouswheel]

I have another use case where the second ideology you mention is awkward for a developer.

For face-services I have a 4 independent services I am running from the same repo. While debugging, I noticed a problem with the metadata on ipfs. I had fixed this locally... and so in order to update the metadata, I wanted to easily update ipfs and the registry.

I wanted to do:

for fn in service_metadata_*.json; do snet service update-metadata --yes --metadata-file $fn; done

But I can't, because I need to specify the the organisation and service name for each.

If we had #173 - storing a canonical local state for each service, I wouldn't have to remember the mapping to org and service name. I could just set up my project, and when I notice something needs to be fixed I can do snet push from that directory (#174)

For anyone running more than a couple of services, trying to keep track of everything gets really confusing! This is why I want a local directory with all the project and service settings. I don't want to have to remember what name I used to register my service. All the details should be stored with the developer environment.

[astroseger]

@ferrouswheel Yes... It makes sense... We need to think how to incorporate your idea with snet push....