[wildfly-dev] HAL subsystem

[Brian Stansberry]

On Fri, Apr 5, 2019 at 5:40 AM Harald Pehl <hpehl at redhat.com> 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 <brian.stansberry at redhat.com>
> 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 <hpehl at redhat.com> 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
>> wildfly-dev at lists.jboss.org
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190405/9ec1431b/attachment-0001.html