Edinburgh track for edgex-grove-pi-demo

Hi,
As per the new edinburgh tracks granted to the upstream edgexfoundry snap, I’d like to request an edinburgh track for my edgex-grove-pi-demo snap.

Remember tracks are forever and to provide a stable path for people using production-grade software. What’s the rationale for tracks for a demo snap? Could you cover the use case in some other way?

My thinking is that if it’s a demo, it should always use the latest edgexfoundry snap, that would be sufficient for demo/evaluation purposes. People shouldn’t need to restrict edgex-grove-pi-demo to a specific version since, by the time when they need to do this, they should have already moved on from a demo, and should be using the production/real snaps for edgexfoundry (which do have tracks).

  • Daniel

This snap is to build a development kit image, it’s using the upstream repo: https://github.com/edgexfoundry/demo-grove-pi. It’s not a great name, but reflects the upstream repo name.

We want to use an edinburgh track for this so that if there are issues with the development kit image we can release fixes to that track specifically to fix the snap in that image.

Hi, so after discussing with @ijohnson, this snap will be seeded into images that will be made available elsewhere. While as stated, I dislike using tracks to differentiate versions so an image can bake the specific ones in (particularly for software which is meant as a demo/development - naming aside, the fact is that those images are not likely to be used in production, right?), the fact is that we do have precedent for this: IIRC some kernel snaps have tracks for the ubuntu version they’re meant for, and there are others I think.

So +1 from me on granting these tracks, particularly since Ian has used them before and has good understanding of the reasonable use cases.

It being a new snap whose purpose is not entirely analogous to other edgex snaps, I think it’s reasonable to ask for comments from other @reviewers as granting a new track, and do a comments period of 7 days as per process.

  • Daniel

The use case for the snap is actually very analogous to other edgex snaps, such as specifically edgex-influx-proxy. It is a “north-bound” application service (see the diagram on this page), albeit one that is specific to this development kit. The snap has a service which registers other snaps (such as node-red) with the main edgexfoundry snap for a “zero-touch” setup of the device, where everything starts up automatically and a user can just navigate to the node-red dashboard in their browser and start configuring/exploring the software and framework that EdgeX provides.

I’m ok with this track request, +1.

7 days have passed, we have +2 votes, so edinburgh track has been created. Enjoy!

  • Daniel

Thanks for this folks!