Device Groups

[MarianRaphael]

Epic

#1509

Description

As a FlowForge user, who manages a large number of devices, I want to have the ability to create "Device Groups" and assign "Target Snapshots" to these groups so that I can manage my devices more efficiently.

Which customers would this be availble to

All Users, (CE)

Acceptance Criteria

• option to create a new "Device Group"
• see the list of devices assigned to the group and have the ability to add or remove devices
• Possibility to assign target snapshots to the group
• can be assigned to an application

Have you provided an initial effort estimate for this issue?

I have provided an initial effort estimate

[joepavitt]

Do we expect that a Device can belong to multiple groups?

[MarianRaphael]

No

[joepavitt]

In which case:

Would utilise the new navigation layout from #2474

[Steve-Mcl]

Hi @MarianRaphael

Nick has asked me to look into this from an engineering perspective and try to ascertain the best approach to development with a good amount of consideration to where this is all leading. Having read all of the various linked issues, there are some questions, suggestions, and a need for more detail before work can commence.

Question 1

Is there a flow chart depicting the various operations an interactions a group has with devices, instances and applications?

Question 2

option to create a new "Device Group"

Other than the name of the group what properties do we think will be required for initial offering and, thinking ahead down the road map, what other properties are likely to be required in the group. e.g. Will the group need Env Vars? Should other settings like Theme and Modules be present?

Obviously, many of these can be added later, but knowing up front, the kind of settings a group will eventually need will help understand what is required in the database and may influence decisions made initially.

Question 3

What is a group apart from a collection of devices? For example, we we expect that a group can be standalone OR added to an instance (signifying all devices in the group get updated to snapshots of the associated instance?)

Question 4

When a group is standalone, it is automatically considered to be a collection of devices that will receive the same snapshot?

Question 5

If the group has properties (like security, theme, etc) would we still want to show the device settings? or grey out any settings that have been set in a group? or something else?

Question 6

Will there be a future where groups can be grouped? e.g. "Production Line 1" might contain specific ENV VARS that child groups "Facility 1" and "Facility 2" must inherit. If yes, would this be a freeform hierarchy or a set limit of parent/child relationships?

Suggestion

We may wish to consider TAGGING as opposed to GROUPING. Tags can be applied and removed easily. Tags could have "Override" properties that devices inherit. Multiple tags could provide an array of settings to device e.g. tags like "Database1" and "Broker3" could provide the required Env Vars to devices sporting these TAGS - meaning there is only one place for an admin to edit/update.

Special tags could be used indicate whether a device is standalone or part of an instance or which TAB(s) of the flow get deployed to the device(s).

This may ultimately be simpler to implement, easier to maintain, less technical dept when expanding capabilities and offer the users more flexibility at the same time.

Thanks.

[MarianRaphael]

Hi Steve,

I'll try to address all the points you've raised. If anything remains unclear, please don't hesitate to reach out.

Is there a flow chart depicting the various operations an interactions a group has with devices, instances and applications?

Not yet, @joepavitt I would extent the existing Device workflow in figma

Will the group need Env Vars? Should other settings like Theme and Modules be present?

Yes. To assign snapshots to a group (and thus to all individual devices within that group), we need to include:

• (The flows)
• Credentials
• Environment variables
• NPM packages
• Runtime settings.

we expect that a group can be standalone OR added to an instance

Standalone (in this iteration), with the possibility to be assigned to an application.

When a group is standalone, it is automatically considered to be a collection of devices that will receive the same snapshot?

Yes

If the group has properties (like security, theme, etc) would we still want to show the device settings? or grey out any settings that have been set in a group? or something else?

The goal is to display individual device group settings. However, for this iteration, it's ok to hide them

Will there be a future where groups can be grouped? e.g. "Production Line 1" might contain specific ENV VARS that child groups "Facility 1" and "Facility 2" must inherit. If yes, would this be a freeform hierarchy or a set limit of parent/child relationships?

I really like the idea! But it is not in the scope for this iteration, let's keep it as simple as possible in this iteration.

We may wish to consider TAGGING

Wouldn't multiple devices with the same tag be a group?

[MarianRaphael]

Precision about: Possibility to assign target snapshots to the group

Device Groups have a list of snapshots, (same concept as for instances), which come from Snapshots created from devices within the group. Devices cannot be part of multiple Device Groups and can only be part of either an Instance or a Group.

[knolleary]

Device Groups have a list of snapshots, (same concept as for instances), which come from Snapshots created from devices within the group. Devices cannot be part of multiple Device Groups and can only be part of either an Instance or a Group.

This is not what the original epic describes. Based on reading the description of the Epic and this Issue, I believed this was about better organising devices within an Instance - so you can selectively roll-out a snapshot to some of your devices in a more managed way.

If this is actually about having a way for a device to not be assigned to an instance, but still manage snapshots etc, then that is a very different piece of work and it would help if the descriptions were updated to make it clear.

We need a more complete UX design for this to understand what is required - the screenshot above doesn't give us much to go on. Where do Device Groups sit in the navigation? Are they owned by an Application? Are they owned at the Team level? What are the relationships between Applications, Instances, Devices and Groups?

I have a very long list of questions to understand the requirements of this - but I think it would be easier for us to get together and discuss the high-level concept/design to make sure we are aligned.

[knolleary]

I have increased the sizing to XXL - this is going to require quite a lot of work to fit into our model, including the updates needed in the Device Agent itself to support not being assigned to an Instance but still having a snapshot to run.

[MarianRaphael]

I have a very long list of questions to understand the requirements of this - but I think it would be easier for us to get together and discuss the high-level concept/design to make sure we are aligned.

I'll invite for tomorrow

[Steve-Mcl]

We may wish to consider TAGGING

Wouldn't multiple devices with the same tag be a group?

Yes, but with more flexibility. I see limited (or difficulty) scalability in the concept of a group table whereas tags (with appropriate properties) could be used for more than just "a collection of devices". I see tags as a way of future implementing new related features with little to zero DB changes if engineered correctly (as opposed to constantly adding and updating tables and columns to fit the current iterations` needs.)

Lets discuss tomorrow :)

[joepavitt]

If this is actually about having a way for a device to not be assigned to an instance, but still manage snapshots etc, then that is a very different piece of work and it would help if the descriptions were updated to make it clear.

I think what is happening here is that this issue has been scoped in the assumption that #2334 will be done alongside it, but they are in fact two separate pieces of work, that could be done apart from each other

[MarianRaphael]

See also #2655

[MarianRaphael]

Replaced by #2655