Re: HAL subsystem

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: HAL subsystem

Harald Pehl
I agree that some of this data might not fit in standalone.xml or domain.xml, 
but I'd like to get away from storing all kind of HAL related settings and data 
in the browser local storage. 

In the meantime there's another RFE coming up to customise the browser 
title for the console. 

What I'm looking for is an way to store these kind of data in the management 
model in a way that is extendable and future proof. 

I don't have any cloud specific use cases in mind, but I suppose that having a
place for HAL to store settings will also be a plus for HAL running in an OpenShift
environment. 

I mentioned RBAC, because I'd like to protect macros which is not possible atm.
Macros should only be visible and executable for specific roles.

On 4. Apr 2019, at 23:17, Brian Stansberry <[hidden email]> wrote:

I can't see storing this kind of thing in standalone.xml or host.xml, so this means some other form of persistent store. The use cases around managing that store would have to be gone through carefully.

The content repository can be used for that kind of thing, but it's not meant to be directly managed. So no supported copying of your content from one instance to another, etc, at least not without specific tooling we'd have to provide. 

People would also expect to be able to migrate this content when upgrading. Which is just a variant of copying your content from one instance to another.

For a domain the content repository is a domain-wide store (which is actually a pro, since it means any host that is in sync with the domain can become master and know it will have the needed data.)

How would this relate to possible uses of HAL in cloud environments?

On Thu, Apr 4, 2019 at 6:05 AM Harald Pehl <[hidden email]> wrote:
The management console uses various settings which need to survive a browser 
restart. Currently these settings are stored client side only either as cookie or 
in the browser local storage:

# Cookie

- Google Analytics on/off
- Page size
- Poll on/off
- Poll time

# Local Storage

- Management endpoints (for HAL standalone mode)
- Pinned items in the finder
- JavaScript extensions
- Macros

Using the browser to store settings has the advantage of being very flexible. 
The settings are also not bound to a specific WildFly instance. For some 
settings like the management endpoints this is a requirement and won't change. 

However other settings make more sense if they are stored on the server side. 
That's why I'd like to propose a dedicated subsystem for HAL. It should hold 
the current settings (except the management endpoints). It should be extendable
to store additional settings (currently there's an RFE to customize the 
visibility of notifications in HAL). 

Another advantage is that settings and data like macros could be properly 
secured using RBAC. 

How so?

I assume content would be per user so access to parts of the content would be restricted based on userid.

Perhaps some kind of administrative operations that give access to other users content, use of which would be limited based on the WildFly RBAC roles?

I would like to hear your opinion about a dedicated subsystem for HAL. 
Does it makes sense? How should it look like? Any feedback and comments are 
welcome!

// Harald
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HAL subsystem

Brian Stansberry


On Fri, Apr 5, 2019 at 5:40 AM Harald Pehl <[hidden email]> wrote:
I agree that some of this data might not fit in standalone.xml or domain.xml, 
but I'd like to get away from storing all kind of HAL related settings and data 
in the browser local storage. 

In the meantime there's another RFE coming up to customise the browser 
title for the console. 

What I'm looking for is an way to store these kind of data in the management 
model in a way that is extendable and future proof. 

I don't have any cloud specific use cases in mind, but I suppose that having a
place for HAL to store settings will also be a plus for HAL running in an OpenShift
environment. 

Me too. 

I mention OpenShift because that kind of use case helps clarify that things that have to be worked through re: the management of persistent data.


I mentioned RBAC, because I'd like to protect macros which is not possible atm.
Macros should only be visible and executable for specific roles.

Shared macros? Or user-specific ones? I suppose all the things you listed could have some concept of shared settings, as well as user-specific ones.

My question is kind of a tangent from the RBAC point. :) I can certainly see why you'd want RBAC to control shared resources.

On 4. Apr 2019, at 23:17, Brian Stansberry <[hidden email]> wrote:

I can't see storing this kind of thing in standalone.xml or host.xml, so this means some other form of persistent store. The use cases around managing that store would have to be gone through carefully.

The content repository can be used for that kind of thing, but it's not meant to be directly managed. So no supported copying of your content from one instance to another, etc, at least not without specific tooling we'd have to provide. 

People would also expect to be able to migrate this content when upgrading. Which is just a variant of copying your content from one instance to another.

For a domain the content repository is a domain-wide store (which is actually a pro, since it means any host that is in sync with the domain can become master and know it will have the needed data.)

How would this relate to possible uses of HAL in cloud environments?

On Thu, Apr 4, 2019 at 6:05 AM Harald Pehl <[hidden email]> wrote:
The management console uses various settings which need to survive a browser 
restart. Currently these settings are stored client side only either as cookie or 
in the browser local storage:

# Cookie

- Google Analytics on/off
- Page size
- Poll on/off
- Poll time

# Local Storage

- Management endpoints (for HAL standalone mode)
- Pinned items in the finder
- JavaScript extensions
- Macros

Using the browser to store settings has the advantage of being very flexible. 
The settings are also not bound to a specific WildFly instance. For some 
settings like the management endpoints this is a requirement and won't change. 

However other settings make more sense if they are stored on the server side. 
That's why I'd like to propose a dedicated subsystem for HAL. It should hold 
the current settings (except the management endpoints). It should be extendable
to store additional settings (currently there's an RFE to customize the 
visibility of notifications in HAL). 

Another advantage is that settings and data like macros could be properly 
secured using RBAC. 

How so?

I assume content would be per user so access to parts of the content would be restricted based on userid.

Perhaps some kind of administrative operations that give access to other users content, use of which would be limited based on the WildFly RBAC roles?

I would like to hear your opinion about a dedicated subsystem for HAL. 
Does it makes sense? How should it look like? Any feedback and comments are 
welcome!

// Harald
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat



--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev