Request for interface auto-connection for appspace-app, appspace-app-qa, and appspace-app-dev

Our App is meant for digital signage, runs 24/7, single-application, and we want to provide easy access for the customer/user to use our App through Snap store.

Here are several functionalities of our App:

  • Our App needs to be able to do a daily reboot of the device.
  • Our App needs to view the device information:
    • CPU information
    • Hardware information
    • Storage information
    • Network interface information
    • OS information
    • Memory information
  • It needs to fork a child process and to kill it: This is to invoke a web socket server used for external communications to our App if the user enables it.

Because of that, we need to request auto-connect for these interfaces for our App:

  • Hardware-observe
  • Network-observe
  • System-observe
  • Shutdown
  • Mount-observe
  • Physical-memory-observe
  • Process-control

All these interfaces are mandatory to auto-connect for our App, and our customer users don’t have adequate technical knowledge to use CLI at all. Or at least the connection permission should come out as approval to the user during installation (all-or-nothing approach, and if the user rejects any of them, then the App should not be installed at all).

This request applies to the snaps:

  • appspace-app
  • appspace-app-qa
  • appspace-app-dev

moved it to the correct category (store-requests) … the “snap-requests” category is for asking that someone creates a snap of some upstream sowftware …

Hi All,
Any update on this request?

Appreciate for your response. Thank you.

Not directly ties to the auto-connect requests, but might it be easier to use channels on a single snap name rather than three snap names? That is, publish your appspace-app-dev builds as the edge channel of appspace-app, and appspace-app-qa builds as either the beta or candidate channel.

One benefit of this is that if you decide a particular build has passed your QA process, it can be promoted to the stable channel. With different snap names, you would need to rebuild the snap which might invalidate some of the QA work.

We’ll take it into consideration, but currently it does not fit our release process. Because we don’t want to make our App under development to be accessible by public, and our QA has to test before it goes to production public beta and edge channel. The only way we can use it is to make two snaps for our internal QA and dev only. Is it possible to make those Beta and Edge channel to be private that only our internal QA and developer use it?

I’m not sure there is such a feature. Some things that might work:

  1. don’t publish the private builds at all, and install them locally with snap install --dangerous. You would probably need to manually connect interfaces to do this kind of testing.

  2. upload your snaps to the store, but don’t release them to any channels. If you run sudo snap login and provide credentials for a collaborator on the snap, you can use the --revision argument to snap install or snap refresh to install one of these unpublished revisions. Such an install should benefit from store assertions allowing auto-connect.

Thanks Jamesh, we’ll look into your suggestion.

Hello, can we request the auto-connection for appspace-app only for now?

The interfaces to be auto-connected are:

  • Hardware-observe
  • Network-observe
  • System-observe
  • Shutdown
  • Mount-observe
  • Physical-memory-observe
  • Process-control

Thank you.

+1 for hardware-observe, network-observe, system-observe, mount-observe as these are relatively innocuous.

Can you please explain why shutdown is required?

Also process-control and physical-memory-observe are quite privileged interfaces - again can you please explain why these are required?

Thank you, Alex.

Our customer will always let their signage devices to run 24 hours in other place across office branches and countries for announcement and marketing purposes.

  • shutdown: We need to do a daily reboot of the signage device
  • process-control: We need to spawn a child process to start NodeJS Websocket server and to kill it
  • physical-memory-observe: We need to query memory usage, free and availability

If you have any questions, further enquiry or in case of missing information - just ping us!

You souldn’t need process-control to kill other processes that are part of your snap. If you know the server process’s pid, you should be able to kill it without any extra permission.

It’s possible that you’re running into sandbox restrictions if you are trying to use a tool like killall that enumerates all processes on the system and checks their command line. But if you spawned the server, you should know it’s pid.

I tend to agree, but can you provide more details on why they are needed? Eg, you stated “Our App needs to view the device information: CPU information”. Why does your app need to view cpu information? Please do this for each interface.

This is unusual for a snap in the public store. Are you using Ubuntu Core as the OS for your signage device? If so, have you considered using gadget.yaml to auto-connect the interfaces?

Thanks Jamesh. We don’t need “process-control” interface for now.

Our customer needs to extract those information from geographically-distributed signage devices through a centralized server for inventory and monitoring purpose.

We are using Ubuntu Desktop only.

Thanks for the info - if shutdown and physical-memory-observe are definitely required, these provide quite privileged access and so would likely require publisher vetting (similarly as is done for classic confinement requests).

@cloud-ops @iko.darius what is your relationship to the upstream project?

I’m the developer, and @cloud-ops is the team that manage deployment related stuff to public stores. We belong to the same company.

Usually how long does it take to finish the vetting process?

@iko.darius thanks for responding - ok, then +1 from me for auto-connect of shutdown and physical-memory-observe too assuming more formal publisher vetting is done by the @advocacy team.

Regarding the timeline for vetting, the @advocacy team should be able to clarify but usually this is pretty quick from what I understand.

Could other @reviewers also please vote for these 2 interfaces?