The future of the management console

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

The future of the management console

Harald Pehl
We're currently working on the next major version of HAL [1]. HAL.next will
include all features of the current management console plus many new features
such as macro recording, topology overview, better keyboard support and
PatternFly [2] compliance. See [3] for more details.

We're making good progress and have migrated all of the configuration and
half of the runtime screens to HAL.next. What's missing is the support for
patching and the remaining runtime UI. Our goal is to ship HAL.next with
WildFly asap. If you don't want to wait, I encourage you to try out HAL.next
today [4] and give us feedback!

I'd like to use this post to give you the chance to participate in the
future of the management console. We already have some basic ideas what
we would like to add to HAL.next, but we also want you to give us additional
input.

# Runtime Extensions / JavaScript API

As most of you will know both HAL and HAL.next are implemented in GWT.
For the current version there's a way to write extensions as GWT modules [5].
This is based on the concept of having compile time extensions provided as
maven dependencies. While this gives you full access to the HAL API, it's
often hard to get started for none GWT developers.

New features in GWT 2.8 like JsInterop [6] make it very easy to export parts
of your Java code to JavaScript. We've used this feature to provide a basic
JavaScript API. This can be used in the future to write runtime extensions
in JavaScript. A first draft is available at [7].

# Monitoring

The current management console has some limited monitoring capabilities.
We could improve and enhance these capabilities if this is something which
you want to have out of the box. However we don't want to turn HAL into
another monitoring tool. There are plenty of other tools and frameworks
which focus on monitoring.

# Macro Recording

We've built basic support to record macros in HAL.next. Behind the scenes the
DMR operations are collected and made available for replay. We could extend
this feature to be more dynamic if requested (variables, iterations, el al).

# What else?

It's your turn! What else do you want to see in HAL.next?


[1] https://github.com/hal/hal.next
[2] https://www.patternfly.org/
[3] https://github.com/hal/hal.next/#motivation
[4] https://github.com/hal/hal.next/#running
[5] https://hal.gitbooks.io/dev/content/building-blocks/extensions.html
[6] https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/view
[7] https://github.com/hal/hal.next/wiki/JavaScript-API


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

Re: The future of the management console

Brian Stansberry
Hi Harald,

Thanks for the update; it’s great that this keeps moving along!

Re: macro recording, how is the recorded data made useful for the user?

I think this is one where we need to think through the use cases carefully so we make sure we cover all the necessary ones or at least don’t do something that blocks covering them.

One thing I know that’s been requested is taking the output of this kind of recording and being able to execute it from the CLI. But that implies CLI syntax instead of raw DMR. And then if we start getting into variable etc it’s important that it be done in a consistent and compatible way.

Cheers,
Brian

> On Apr 24, 2017, at 6:53 AM, Harald Pehl <[hidden email]> wrote:
>
> We're currently working on the next major version of HAL [1]. HAL.next will
> include all features of the current management console plus many new features
> such as macro recording, topology overview, better keyboard support and
> PatternFly [2] compliance. See [3] for more details.
>
> We're making good progress and have migrated all of the configuration and
> half of the runtime screens to HAL.next. What's missing is the support for
> patching and the remaining runtime UI. Our goal is to ship HAL.next with
> WildFly asap. If you don't want to wait, I encourage you to try out HAL.next
> today [4] and give us feedback!
>
> I'd like to use this post to give you the chance to participate in the
> future of the management console. We already have some basic ideas what
> we would like to add to HAL.next, but we also want you to give us additional
> input.
>
> # Runtime Extensions / JavaScript API
>
> As most of you will know both HAL and HAL.next are implemented in GWT.
> For the current version there's a way to write extensions as GWT modules [5].
> This is based on the concept of having compile time extensions provided as
> maven dependencies. While this gives you full access to the HAL API, it's
> often hard to get started for none GWT developers.
>
> New features in GWT 2.8 like JsInterop [6] make it very easy to export parts
> of your Java code to JavaScript. We've used this feature to provide a basic
> JavaScript API. This can be used in the future to write runtime extensions
> in JavaScript. A first draft is available at [7].
>
> # Monitoring
>
> The current management console has some limited monitoring capabilities.
> We could improve and enhance these capabilities if this is something which
> you want to have out of the box. However we don't want to turn HAL into
> another monitoring tool. There are plenty of other tools and frameworks
> which focus on monitoring.
>
> # Macro Recording
>
> We've built basic support to record macros in HAL.next. Behind the scenes the
> DMR operations are collected and made available for replay. We could extend
> this feature to be more dynamic if requested (variables, iterations, el al).
>
> # What else?
>
> It's your turn! What else do you want to see in HAL.next?
>
>
> [1] https://github.com/hal/hal.next
> [2] https://www.patternfly.org/
> [3] https://github.com/hal/hal.next/#motivation
> [4] https://github.com/hal/hal.next/#running
> [5] https://hal.gitbooks.io/dev/content/building-blocks/extensions.html
> [6] https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/view
> [7] https://github.com/hal/hal.next/wiki/JavaScript-API
>
>
> --
> Harald Pehl
> [hidden email]
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by 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: The future of the management console

Harald Pehl
On Mon, Apr 24, 2017 at 4:20 PM, Brian Stansberry
<[hidden email]> wrote:
> Hi Harald,
>
> Thanks for the update; it’s great that this keeps moving along!
>
> Re: macro recording, how is the recorded data made useful for the user?

The recorded DMR operations are presented in a read-only editor.
They're already shown in CLI syntax. There's also a
"copy-to-clipboard" button for easy CLI execution.

>
> I think this is one where we need to think through the use cases carefully so we make sure we cover all the necessary ones or at least don’t do something that blocks covering them.
>
> One thing I know that’s been requested is taking the output of this kind of recording and being able to execute it from the CLI. But that implies CLI syntax instead of raw DMR. And then if we start getting into variable etc it’s important that it be done in a consistent and compatible way.
>

Right, adding advanced features like variables and iterations needs
more research and a consistent exchange with the CLI.

> Cheers,
> Brian
>
>> On Apr 24, 2017, at 6:53 AM, Harald Pehl <[hidden email]> wrote:
>>
>> We're currently working on the next major version of HAL [1]. HAL.next will
>> include all features of the current management console plus many new features
>> such as macro recording, topology overview, better keyboard support and
>> PatternFly [2] compliance. See [3] for more details.
>>
>> We're making good progress and have migrated all of the configuration and
>> half of the runtime screens to HAL.next. What's missing is the support for
>> patching and the remaining runtime UI. Our goal is to ship HAL.next with
>> WildFly asap. If you don't want to wait, I encourage you to try out HAL.next
>> today [4] and give us feedback!
>>
>> I'd like to use this post to give you the chance to participate in the
>> future of the management console. We already have some basic ideas what
>> we would like to add to HAL.next, but we also want you to give us additional
>> input.
>>
>> # Runtime Extensions / JavaScript API
>>
>> As most of you will know both HAL and HAL.next are implemented in GWT.
>> For the current version there's a way to write extensions as GWT modules [5].
>> This is based on the concept of having compile time extensions provided as
>> maven dependencies. While this gives you full access to the HAL API, it's
>> often hard to get started for none GWT developers.
>>
>> New features in GWT 2.8 like JsInterop [6] make it very easy to export parts
>> of your Java code to JavaScript. We've used this feature to provide a basic
>> JavaScript API. This can be used in the future to write runtime extensions
>> in JavaScript. A first draft is available at [7].
>>
>> # Monitoring
>>
>> The current management console has some limited monitoring capabilities.
>> We could improve and enhance these capabilities if this is something which
>> you want to have out of the box. However we don't want to turn HAL into
>> another monitoring tool. There are plenty of other tools and frameworks
>> which focus on monitoring.
>>
>> # Macro Recording
>>
>> We've built basic support to record macros in HAL.next. Behind the scenes the
>> DMR operations are collected and made available for replay. We could extend
>> this feature to be more dynamic if requested (variables, iterations, el al).
>>
>> # What else?
>>
>> It's your turn! What else do you want to see in HAL.next?
>>
>>
>> [1] https://github.com/hal/hal.next
>> [2] https://www.patternfly.org/
>> [3] https://github.com/hal/hal.next/#motivation
>> [4] https://github.com/hal/hal.next/#running
>> [5] https://hal.gitbooks.io/dev/content/building-blocks/extensions.html
>> [6] https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/view
>> [7] https://github.com/hal/hal.next/wiki/JavaScript-API
>>
>>
>> --
>> Harald Pehl
>> [hidden email]
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
>
>
>



--
Harald Pehl
Senior Software Engineer
Red Hat
[hidden email]
Twitter: @redhatway | Instagram: @redhatinc | Snapchat: @redhatsnaps

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

Re: The future of the management console

Romain PELISSE
About Monitoring, I think we discussed such feature a couple of years ago, but I think it would be nice to have "live" picture / overview of the server, showing the following basics value (ideally in a graphical way):
  • nb incoming http requests
  • memory usage
  • database connection pool consomption

As you said, not turning HAL into a full blown monitoring solution, but give a quick and simple widget showing "how the wildfly" instance is faring.


On Mon, Apr 24, 2017 at 4:44 PM, Harald Pehl <[hidden email]> wrote:
On Mon, Apr 24, 2017 at 4:20 PM, Brian Stansberry
<[hidden email]> wrote:
> Hi Harald,
>
> Thanks for the update; it’s great that this keeps moving along!
>
> Re: macro recording, how is the recorded data made useful for the user?

The recorded DMR operations are presented in a read-only editor.
They're already shown in CLI syntax. There's also a
"copy-to-clipboard" button for easy CLI execution.

>
> I think this is one where we need to think through the use cases carefully so we make sure we cover all the necessary ones or at least don’t do something that blocks covering them.
>
> One thing I know that’s been requested is taking the output of this kind of recording and being able to execute it from the CLI. But that implies CLI syntax instead of raw DMR. And then if we start getting into variable etc it’s important that it be done in a consistent and compatible way.
>

Right, adding advanced features like variables and iterations needs
more research and a consistent exchange with the CLI.

> Cheers,
> Brian
>
>> On Apr 24, 2017, at 6:53 AM, Harald Pehl <[hidden email]> wrote:
>>
>> We're currently working on the next major version of HAL [1]. HAL.next will
>> include all features of the current management console plus many new features
>> such as macro recording, topology overview, better keyboard support and
>> PatternFly [2] compliance. See [3] for more details.
>>
>> We're making good progress and have migrated all of the configuration and
>> half of the runtime screens to HAL.next. What's missing is the support for
>> patching and the remaining runtime UI. Our goal is to ship HAL.next with
>> WildFly asap. If you don't want to wait, I encourage you to try out HAL.next
>> today [4] and give us feedback!
>>
>> I'd like to use this post to give you the chance to participate in the
>> future of the management console. We already have some basic ideas what
>> we would like to add to HAL.next, but we also want you to give us additional
>> input.
>>
>> # Runtime Extensions / JavaScript API
>>
>> As most of you will know both HAL and HAL.next are implemented in GWT.
>> For the current version there's a way to write extensions as GWT modules [5].
>> This is based on the concept of having compile time extensions provided as
>> maven dependencies. While this gives you full access to the HAL API, it's
>> often hard to get started for none GWT developers.
>>
>> New features in GWT 2.8 like JsInterop [6] make it very easy to export parts
>> of your Java code to JavaScript. We've used this feature to provide a basic
>> JavaScript API. This can be used in the future to write runtime extensions
>> in JavaScript. A first draft is available at [7].
>>
>> # Monitoring
>>
>> The current management console has some limited monitoring capabilities.
>> We could improve and enhance these capabilities if this is something which
>> you want to have out of the box. However we don't want to turn HAL into
>> another monitoring tool. There are plenty of other tools and frameworks
>> which focus on monitoring.
>>
>> # Macro Recording
>>
>> We've built basic support to record macros in HAL.next. Behind the scenes the
>> DMR operations are collected and made available for replay. We could extend
>> this feature to be more dynamic if requested (variables, iterations, el al).
>>
>> # What else?
>>
>> It's your turn! What else do you want to see in HAL.next?
>>
>>
>> [1] https://github.com/hal/hal.next
>> [2] https://www.patternfly.org/
>> [3] https://github.com/hal/hal.next/#motivation
>> [4] https://github.com/hal/hal.next/#running
>> [5] https://hal.gitbooks.io/dev/content/building-blocks/extensions.html
>> [6] https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/view
>> [7] https://github.com/hal/hal.next/wiki/JavaScript-API
>>
>>
>> --
>> Harald Pehl
>> [hidden email]
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
>
>
>



--
Harald Pehl
Senior Software Engineer
Red Hat
[hidden email]
Twitter: @redhatway | Instagram: @redhatinc | Snapchat: @redhatsnaps

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


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