Pack UI

[enykeev]

[enykeev]

[lakshmi-kannan]

I must admit, UI for pack install is such a great feature! I am really digging it. Overall, nice initial work! I captured my comments in this skitch https://www.evernote.com/l/ANFJke2F89VKx7HVxbh8fyYAzPFXOoywNXg.

Apart from those, when I click INSTALL or REMOVE, I'd like to see the execution in the right side frame at the bottom. It's a UX eye sore to switch to history page to see the installation progress.

Somehow I am not liking the fonts at all. They are way too light.

[bigmstone]

What's your plan long-term here as we use redux in more and more components? We will eventually need to think through how to centrally locate store and have scenes contain their own reducers and join them in the central store. Can we start to implement some of that in this PR? I think it would make sense to leverage redux for the TZ stuff we discussed this morning.

Thoughts?

[enykeev]

There is a need in that sort of moves, but I'd rather keep them out of this particular PR. As soon as we start an active phase of transitioning from Angular to React, I see us moving lots of components (including store) to higher levels, but I'm afraid it might create additional clutter so I'd prefer we do it in one sweep.

[enykeev]

@lakshmi-kannan I agree on a need for additional visual feedback for installation and uninstallation. I'll also see what can be done in regards to displaying and installing other versions. At the same time, I don't think we should mess with visuals at that point. I'd rather us stick to brocade guidelines for now.

[LindsayHill]

Overall this is a really good start. I think this is going to be a feature that non-HA users will really like HA pack install is a whole 'nother kettle of fish, but if we figure out the underlying bits of that, then this feature should be able to take advantage of it.

Agreed with @enykeev above re: visual guidelines. I think that we'll be doing some overhaul work on the visual style in the near future, once the Extreme deal closes. So can look at it then.

A few random comments:

• I've known it for a while, but this is a good reason to update our pack metadata to use name: field better, and to have better descriptions. Too much pointless, repeated text "st2 content pack containing..."
• When I select a pack, on the right-hand side, make the link go direct to the actions for that pack? And/or have links to Actions and/or Rules for that pack?
• Can we highlight packs that have updates available? (This is actually a more general thing, where I'd love to be able to do equivalent of yum list updates, but for packs)
• Low priority: add ability to select & install specific pack version
• Wonder if we should display the pack README on the right-hand pane? Since it often has more interesting info, configuration information, etc.
• The display for numbers of rules/actions/sensors has text labels evenly distributed, which can lead to slightly odd balance where there is a big disparity in numbers - e.g. for the examples pack, there's 1 rule & 67 actions. That has a very wide bar for actions, and a narrow one for rules. That then leads to the 'rules' label being a long way away from the rules bar, which is a little confusing.
• Pack config: nested configs suck...
• I wonder if we should have a link from Actions & Rules tabs going back to the pack - e.g. so you can link back to the pack configuration?

Any ideas what happens if the ST2 server does not have Internet access? Some users don't have access. Hopefully it gracefully fails, and just shows installed packs, with none available.

[enykeev]

HA pack install is a whole 'nother kettle of fish

Indeed it is, though, ideally, it should not matter for UI and that's what Pack Management part two is intended to solve.

When I select a pack, on the right-hand side, make the link go direct to the actions for that pack? And/or have links to Actions and/or Rules for that pack?

I wonder if we should have a link from Actions & Rules tabs going back to the pack - e.g. so you can link back to the pack configuration?

👍 good ideas

Can we highlight packs that have updates available?

Sure we can. Problem is that we don't really solve the whole bunch of problems related to pack updates at the moment (dependencies and stuff) so it might be not a good idea to make this feature front and center until we have some sort of the answer for the questions that will immediately arise.

Low priority: add ability to select & install specific pack version

Wonder if we should display the pack README on the right-hand pane? Since it often has more interesting info, configuration information, etc.

No metadata we currently have holds a list of available versions or a readme content\excerpt . Index changes and reindexing are required.

The display for numbers of rules/actions/sensors has text labels evenly distributed, which can lead to slightly odd balance where there is a big disparity in numbers - e.g. for the examples pack, there's 1 rule & 67 actions. That has a very wide bar for actions, and a narrow one for rules. That then leads to the 'rules' label being a long way away from the rules bar, which is a little confusing.

This is intentional and I don't really see a way for us to solve that more consistently. Take AWS pack for example. There's no amount of fiddling that can offset 3500 to 11 ratio between actions and the rest of the content combined. Evenly distributed labels are a single consistent way.

Pack config: nested configs suck...

Amen.

Any ideas what happens if the ST2 server does not have Internet access? Some users don't have access. Hopefully it gracefully fails, and just shows installed packs, with none available.

I think that ideally we should not fetch index from UI instead make st2 do this for us on an interval and from the indexes defined in st2.conf. I'm focusing on frontend stuff for now and would really like some help so I would not have to switch context.

[LindsayHill]

Low priority: add ability to select & install specific pack version

Wonder if we should display the pack README on the right-hand pane? Since it often has more interesting info, configuration information, etc.

No metadata we currently have holds a list of available versions or a readme content\excerpt . Index changes and reindexing are required.

We don't enforce README at the moment, or any particular structure to it. Probably have to do that first, then update index.

The display for numbers of rules/actions/sensors has text labels evenly distributed, which can lead to slightly odd balance where there is a big disparity in numbers - e.g. for the examples pack, there's 1 rule & 67 actions. That has a very wide bar for actions, and a narrow one for rules. That then leads to the 'rules' label being a long way away from the rules bar, which is a little confusing.

This is intentional and I don't really see a way for us to solve that more consistently. Take AWS pack for example. There's no amount of fiddling that can offset 3500 to 11 ratio between actions and the rest of the content combined. Evenly distributed labels are a single consistent way.

Fair enough.

Any ideas what happens if the ST2 server does not have Internet access? Some users don't have access. Hopefully it gracefully fails, and just shows installed packs, with none available.

I think that ideally we should not fetch index from UI instead make st2 do this for us on an interval and from the indexes defined in st2.conf. I'm focusing on frontend stuff for now and would really like some help so I would not have to switch context.

Yes, I think that is the correct approach - make st2 do the fetching, and it must use whatever indexes are in st2.conf. Makes it work as expected for those companies using internal indexes.