10:28 a.m.
Hey,
while the All In One zip works well for demoing, using Hawkular in a
more serious scenario requires a lot of options and settings
* External C*: $CASSANDRA_NODES and -Dhawkular.backend=remote
* Binding to non-localhost: -b a.b.c.d and
-Dkeycloak.server.url=http://a.b.c.d:8080/auth
* Adding jdoe to a dist build:
-Dkeycloak.import=./standalone/configuration/hawkular-realm-for-dev.json
* Using an external RDBMS for keycloack users: "before the server first
boots, the `KeycloakDS` on `standalone.xml` should be changed to point
to an external database." (this applies when using the embedded KC and
not a separate standalone one)
* If not using jdoe above: setting user/password for the internal agent
after a user was created
* Dorking around with standalone.xml to chose up a mail server
* Setting other java opts
all the above involve a huge amount of manual steps and configuration
changes.
I think it is thus time to introduce some sort of installer or config
script that is able to make the changes. I think there is meanwhile even
a cli mode that can apply the changes (to standalone.xml) on a
non-running server. Some options could be set in env variables or
directly applied to the standalone.xml.
If we still need to supply env-variables we may potentially also create
a start script from the installer, which sets the variabls and then
calls standalone.sh
2:25 p.m.
Is ansible a viable technology for this?
On Tue, Jan 26, 2016 at 4:28 AM, Heiko W.Rupp <hrupp(a)redhat.com> wrote:
Hey,
while the All In One zip works well for demoing, using Hawkular in a
more serious scenario requires a lot of options and settings
* External C*: $CASSANDRA_NODES and -Dhawkular.backend=remote
* Binding to non-localhost: -b a.b.c.d and
-Dkeycloak.server.url=http://a.b.c.d:8080/auth
* Adding jdoe to a dist build:
-Dkeycloak.import=./standalone/configuration/hawkular-realm-for-dev.json
* Using an external RDBMS for keycloack users: "before the server first
boots, the `KeycloakDS` on `standalone.xml` should be changed to point
to an external database." (this applies when using the embedded KC and
not a separate standalone one)
* If not using jdoe above: setting user/password for the internal agent
after a user was created
* Dorking around with standalone.xml to chose up a mail server
* Setting other java opts
all the above involve a huge amount of manual steps and configuration
changes.
I think it is thus time to introduce some sort of installer or config
script that is able to make the changes. I think there is meanwhile even
a cli mode that can apply the changes (to standalone.xml) on a
non-running server. Some options could be set in env variables or
directly applied to the standalone.xml.
If we still need to supply env-variables we may potentially also create
a start script from the installer, which sets the variabls and then
calls standalone.sh
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
9:59 p.m.
New subject: Installer
On 26 Jan 2016, at 14:25, John Doyle wrote:
Is ansible a viable technology for this?
I am sure that we can supply playbooks for
users that already use Ansible.
I am not sure though that "requiring" Ansible
to get a decent install / start experience is
the way forward.
10:47 p.m.
New subject: Installer
After seeing the work involved in prior products' installers, it is my recommendation
we do everything in our power to avoid writing a custom installer and to not worry about
covering all customization/configuration possibilities.
Perhaps we write a simple bash script that takes a few parameters and does a bunch of
simple file manipulations to change standalone.xml, push files from here to there, that
kind of thing. But unless we want to devote alot of time and resources to do it
"right" let's try avoid writing an installer. That is a rabbit hole I
don't think we should commit to going down right now.
Just my $0.02 based on past experience.
----- Original Message -----
On 26 Jan 2016, at 14:25, John Doyle wrote:
> Is ansible a viable technology for this?
I am sure that we can supply playbooks for
users that already use Ansible.
I am not sure though that "requiring" Ansible
to get a decent install / start experience is
the way forward.
9:04 a.m.
New subject: Installer
On 26.01.2016 22:47, John Mazzitelli wrote:
After seeing the work involved in prior products' installers, it
is my recommendation we do everything in our power to avoid writing a custom installer and
to not worry about covering all customization/configuration possibilities.
+1, I'd rather see more documentation for our configuration
flags/switches/values than an installer. I don't have data to back this,
but I believe that most environments Hawkular will be used for real are
being handled by sysadmins managing their systems with tools like
Ansible/Puppet/Chef. So, the installation/configuration process for
Hawkular should be friendly to those tools, but nothing else.
*At most*, we could provide a sample configuration files for
development/trial/demo environments, as we have with the "for-dev"
Keycloak realm (which ships with jdoe/password).
- Juca.
12:48 p.m.
New subject: Installer
Totally agree with Mazz (with respect to the rabbit hole).
Simple scripts for common install tasks (add-user/etc...) should be
enough. And they should not require the server to be half-started but
simply operate on files.
Le 26/01/2016 22:47, John Mazzitelli a écrit :
After seeing the work involved in prior products' installers, it
is my recommendation we do everything in our power to avoid writing a custom installer and
to not worry about covering all customization/configuration possibilities.
Perhaps we write a simple bash script that takes a few parameters and does a bunch of
simple file manipulations to change standalone.xml, push files from here to there, that
kind of thing. But unless we want to devote alot of time and resources to do it
"right" let's try avoid writing an installer. That is a rabbit hole I
don't think we should commit to going down right now.
Just my $0.02 based on past experience.
----- Original Message -----
> On 26 Jan 2016, at 14:25, John Doyle wrote:
>
>> Is ansible a viable technology for this?
>
> I am sure that we can supply playbooks for
> users that already use Ansible.
> I am not sure though that "requiring" Ansible
> to get a decent install / start experience is
> the way forward.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
1:19 p.m.
New subject: Installer
On 27 Jan 2016, at 12:48, Thomas Segismont wrote:
Simple scripts for common install tasks (add-user/etc...) should be
enough. And they should not require the server to be half-started but
I am talking about this:
http://www.mastertheboss.com/jbossas/wildfly9/configuring-wildfly-9-from-...
Not what we had in RHQ.
simply operate on files.
I don't think this is good for handling xml configs.
3:33 p.m.
New subject: Installer
Le 27/01/2016 13:19, Heiko W.Rupp a écrit :
On 27 Jan 2016, at 12:48, Thomas Segismont wrote:
> Simple scripts for common install tasks (add-user/etc...) should be
> enough. And they should not require the server to be half-started but
I am talking about this:
http://www.mastertheboss.com/jbossas/wildfly9/configuring-wildfly-9-from-...
Simple scripts could use the offline-cli, yes. AFAIU, The offline-cli
does not bind any port or deploy any component.
Not what we had in RHQ.
> simply operate on files.
I don't think this is good for handling xml configs.
Do we have our own XML on top of what we already put inside standalone.xml?
11:25 a.m.
New subject: Installer
I definitely agree that:
- we need to make it easy to install
- an installer needs to be easy to maintain (reduce options in
particular)
We should also (re)consider our delivery options:
- zip vs docker vs VM vs RPMs
We also can't do all, and it has an impact on how the various parts work
together.
For the server, I think it would be extremely helpful to have a dedicated
property file for all the typical configuration. By typical, I mean, the IP
to the cassandra cluster, the IP to the Keycloak server, enable/disable the
internal agent with username/password...
Does anyone know how we can keep the configuration.xml files but point to
properties in a different file ? I think it would be extremely helpful for
a user and an installer to just have to edit a simpe and documented
property file rather than messing around with the standalone.xml file that
change over time.
Thomas
On Wed, Jan 27, 2016 at 3:33 PM, Thomas Segismont <tsegismo(a)redhat.com>
wrote:
Le 27/01/2016 13:19, Heiko W.Rupp a écrit :
> On 27 Jan 2016, at 12:48, Thomas Segismont wrote:
>
>> Simple scripts for common install tasks (add-user/etc...) should be
>> enough. And they should not require the server to be half-started but
>
> I am talking about this:
>
http://www.mastertheboss.com/jbossas/wildfly9/configuring-wildfly-9-from-...
Simple scripts could use the offline-cli, yes. AFAIU, The offline-cli
does not bind any port or deploy any component.
>
> Not what we had in RHQ.
>
>> simply operate on files.
>
> I don't think this is good for handling xml configs.
Do we have our own XML on top of what we already put inside standalone.xml?
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
12:06 p.m.
New subject: Installer
For the server, I think it would be extremely helpful to have a
dedicated
property file for all the typical configuration. By typical, I mean, the IP
to the cassandra cluster, the IP to the Keycloak server, enable/disable the
internal agent with username/password...
Does anyone know how we can keep the configuration.xml files but point to
properties in a different file ? I think it would be extremely helpful for a
user and an installer to just have to edit a simpe and documented property
file rather than messing around with the standalone.xml file that change
over time.
This is actually how RHQ started out. We have one single rhq-server.properties file with
ALL the custom configuration settings in there. You start the server by passing in
"-P rhq-server.properties". Of course RHQ has a custom "rhq-server.sh"
that called standalone.sh with that parameter passed in :) But I agree it would be nice to
have a single .properties file with everything in there. It's a one-stop-shop where
the user only has to remember one file to edit to configure the server. Just have to
remember to pass it in via -P. We could edit standalone.conf during the build phase so it
passes that -P in by default.
2:56 p.m.
New subject: Installer
----- Original Message -----
From: "John Mazzitelli" <mazz(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Friday, January 29, 2016 12:06:08 PM
Subject: Re: [Hawkular-dev] Installer
> For the server, I think it would be extremely helpful to have a dedicated
> property file for all the typical configuration. By typical, I mean, the IP
> to the cassandra cluster, the IP to the Keycloak server, enable/disable the
> internal agent with username/password...
> Does anyone know how we can keep the configuration.xml files but point to
> properties in a different file ? I think it would be extremely helpful for
> a
> user and an installer to just have to edit a simpe and documented property
> file rather than messing around with the standalone.xml file that change
> over time.
This is actually how RHQ started out. We have one single
rhq-server.properties file with ALL the custom configuration settings in
there. You start the server by passing in "-P rhq-server.properties". Of
course RHQ has a custom "rhq-server.sh" that called standalone.sh with that
parameter passed in :) But I agree it would be nice to have a single
.properties file with everything in there. It's a one-stop-shop where the
user only has to remember one file to edit to configure the server. Just
have to remember to pass it in via -P. We could edit standalone.conf during
the build phase so it passes that -P in by default.
+1 to have a single hawkular.properties files used by all components to load its
properties.
Today components have their specific .properties file. I think is not a big deal to use
the same, in that way, we simplify if we are in hawkular or standalone deployments.
3:06 p.m.
New subject: Installer
The advantage I see in managing the properties inside standalone.xml is
that it can be managed via Wildfly CLI and compatible tools. Perhaps
even with future versions of Hawkular.
Unless there's a way to tell Wildfly to load the system properties from
a separate file. This would be the best of two worlds.
- Juca.
3:16 p.m.
New subject: Installer
Yes, it's what I hoped for (but really have no idea if that can work).
On Fri, Jan 29, 2016 at 3:06 PM, Juraci Paixão Kröhling <
jpkroehling(a)redhat.com> wrote:
The advantage I see in managing the properties inside standalone.xml
is
that it can be managed via Wildfly CLI and compatible tools. Perhaps
even with future versions of Hawkular.
Unless there's a way to tell Wildfly to load the system properties from
a separate file. This would be the best of two worlds.
- Juca.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3:39 p.m.
New subject: Installer
You can do this:
$JBOSS_HOME/bin/standalone.sh --properties=$JBOSS_HOME/my-jboss.properties
Maybe I'm oversimplifying?
On Fri, Jan 29, 2016 at 9:16 AM, Thomas Heute <theute(a)redhat.com> wrote:
Yes, it's what I hoped for (but really have no idea if that can
work).
On Fri, Jan 29, 2016 at 3:06 PM, Juraci Paixão Kröhling <
jpkroehling(a)redhat.com> wrote:
> The advantage I see in managing the properties inside standalone.xml is
> that it can be managed via Wildfly CLI and compatible tools. Perhaps
> even with future versions of Hawkular.
>
> Unless there's a way to tell Wildfly to load the system properties from
> a separate file. This would be the best of two worlds.
>
> - Juca.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3:47 p.m.
New subject: Installer
I think you nailed it...
On Fri, Jan 29, 2016 at 3:39 PM, John Doyle <jdoyle(a)redhat.com> wrote:
You can do this:
$JBOSS_HOME/bin/standalone.sh --properties=$JBOSS_HOME/my-jboss.properties
Maybe I'm oversimplifying?
On Fri, Jan 29, 2016 at 9:16 AM, Thomas Heute <theute(a)redhat.com> wrote:
> Yes, it's what I hoped for (but really have no idea if that can work).
>
> On Fri, Jan 29, 2016 at 3:06 PM, Juraci Paixão Kröhling <
> jpkroehling(a)redhat.com> wrote:
>
>> The advantage I see in managing the properties inside standalone.xml is
>> that it can be managed via Wildfly CLI and compatible tools. Perhaps
>> even with future versions of Hawkular.
>>
>> Unless there's a way to tell Wildfly to load the system properties from
>> a separate file. This would be the best of two worlds.
>>
>> - Juca.
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
>>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3:54 p.m.
New subject: Installer
Right, that's the -P option I mentioned :)
But you have to either:
1) Remember to pass in -P (aka --properties) on the cmdline when running standalone.sh
2) You have to edit standalone.conf so -P is passed in by default (we can edit this during
build time)
or
3) You have a custom "hawkular.sh" script that runs "standalone.sh -P
hawkular.properties"
My initial gut feeling is to do 2.
----- Original Message -----
I think you nailed it...
On Fri, Jan 29, 2016 at 3:39 PM, John Doyle < jdoyle(a)redhat.com > wrote:
You can do this:
$JBOSS_HOME/bin/standalone.sh --properties=$JBOSS_HOME/my-jboss.properties
Maybe I'm oversimplifying?
On Fri, Jan 29, 2016 at 9:16 AM, Thomas Heute < theute(a)redhat.com > wrote:
Yes, it's what I hoped for (but really have no idea if that can work).
On Fri, Jan 29, 2016 at 3:06 PM, Juraci Paixão Kröhling <
jpkroehling(a)redhat.com > wrote:
The advantage I see in managing the properties inside standalone.xml is
that it can be managed via Wildfly CLI and compatible tools. Perhaps
even with future versions of Hawkular.
Unless there's a way to tell Wildfly to load the system properties from
a separate file. This would be the best of two worlds.
3:55 p.m.
New subject: Installer
I did not know about this :) Do you know if the file is then managed by
Wildfly, or is it read-only?
- Juca.
On 29.01.2016 15:39, John Doyle wrote:
You can do this:
$JBOSS_HOME/bin/standalone.sh --properties=$JBOSS_HOME/my-jboss.properties
Maybe I'm oversimplifying?
On Fri, Jan 29, 2016 at 9:16 AM, Thomas Heute <theute(a)redhat.com
<mailto:theute@redhat.com>> wrote:
Yes, it's what I hoped for (but really have no idea if that can work).
On Fri, Jan 29, 2016 at 3:06 PM, Juraci Paixão Kröhling
<jpkroehling(a)redhat.com <mailto:jpkroehling@redhat.com>> wrote:
The advantage I see in managing the properties inside
standalone.xml is
that it can be managed via Wildfly CLI and compatible tools. Perhaps
even with future versions of Hawkular.
Unless there's a way to tell Wildfly to load the system
properties from
a separate file. This would be the best of two worlds.
- Juca.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3:57 p.m.
New subject: Installer
The file is NOT managed by WildFly, it can be whatever file you want, read-only,
read-write, doesn't matter. The way RHQ did it, we shipped rhq-server.properties in a
directory that was familiar with customers so they knew where it was and could edit it
easily.
----- Original Message -----
I did not know about this :) Do you know if the file is then managed
by
Wildfly, or is it read-only?
- Juca.
On 29.01.2016 15:39, John Doyle wrote:
> You can do this:
>
> $JBOSS_HOME/bin/standalone.sh --properties=$JBOSS_HOME/my-jboss.properties
>
> Maybe I'm oversimplifying?
>
> On Fri, Jan 29, 2016 at 9:16 AM, Thomas Heute <theute(a)redhat.com
> <mailto:theute@redhat.com>> wrote:
>
> Yes, it's what I hoped for (but really have no idea if that can work).
>
> On Fri, Jan 29, 2016 at 3:06 PM, Juraci Paixão Kröhling
> <jpkroehling(a)redhat.com <mailto:jpkroehling@redhat.com>> wrote:
>
> The advantage I see in managing the properties inside
> standalone.xml is
> that it can be managed via Wildfly CLI and compatible tools.
> Perhaps
> even with future versions of Hawkular.
>
> Unless there's a way to tell Wildfly to load the system
> properties from
> a separate file. This would be the best of two worlds.
>
> - Juca.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
5:45 p.m.
New subject: Installer
Then it's still treated as "external" and cannot be managed by tools
that are Wildfly CLI-aware ?
- Juca.
On 29.01.2016 15:57, John Mazzitelli wrote:
The file is NOT managed by WildFly, it can be whatever file you want,
read-only, read-write, doesn't matter. The way RHQ did it, we shipped
rhq-server.properties in a directory that was familiar with customers so they knew where
it was and could edit it easily.
----- Original Message -----
> I did not know about this :) Do you know if the file is then managed by
> Wildfly, or is it read-only?
>
> - Juca.
>
> On 29.01.2016 15:39, John Doyle wrote:
>> You can do this:
>>
>> $JBOSS_HOME/bin/standalone.sh --properties=$JBOSS_HOME/my-jboss.properties
>>
>> Maybe I'm oversimplifying?
>>
>> On Fri, Jan 29, 2016 at 9:16 AM, Thomas Heute <theute(a)redhat.com
>> <mailto:theute@redhat.com>> wrote:
>>
>> Yes, it's what I hoped for (but really have no idea if that can work).
>>
>> On Fri, Jan 29, 2016 at 3:06 PM, Juraci Paixão Kröhling
>> <jpkroehling(a)redhat.com <mailto:jpkroehling@redhat.com>> wrote:
>>
>> The advantage I see in managing the properties inside
>> standalone.xml is
>> that it can be managed via Wildfly CLI and compatible tools.
>> Perhaps
>> even with future versions of Hawkular.
>>
>> Unless there's a way to tell Wildfly to load the system
>> properties from
>> a separate file. This would be the best of two worlds.
>>
>> - Juca.
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org
<mailto:hawkular-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
5:52 p.m.
New subject: Installer
Correct. Which is a downside to this mechanism. The properties you define here are not
manageable like they are in the <system-properties> settings in standalone.xml.
----- Original Message -----
Then it's still treated as "external" and cannot be
managed by tools
that are Wildfly CLI-aware ?
- Juca.
On 29.01.2016 15:57, John Mazzitelli wrote:
> The file is NOT managed by WildFly, it can be whatever file you want,
> read-only, read-write, doesn't matter. The way RHQ did it, we shipped
> rhq-server.properties in a directory that was familiar with customers so
> they knew where it was and could edit it easily.
>
> ----- Original Message -----
>> I did not know about this :) Do you know if the file is then managed by
>> Wildfly, or is it read-only?
>>
>> - Juca.
>>
>> On 29.01.2016 15:39, John Doyle wrote:
>>> You can do this:
>>>
>>> $JBOSS_HOME/bin/standalone.sh
>>> --properties=$JBOSS_HOME/my-jboss.properties
>>>
>>> Maybe I'm oversimplifying?
>>>
>>> On Fri, Jan 29, 2016 at 9:16 AM, Thomas Heute <theute(a)redhat.com
>>> <mailto:theute@redhat.com>> wrote:
>>>
>>> Yes, it's what I hoped for (but really have no idea if that can
>>> work).
>>>
>>> On Fri, Jan 29, 2016 at 3:06 PM, Juraci Paixão Kröhling
>>> <jpkroehling(a)redhat.com <mailto:jpkroehling@redhat.com>>
wrote:
>>>
>>> The advantage I see in managing the properties inside
>>> standalone.xml is
>>> that it can be managed via Wildfly CLI and compatible tools.
>>> Perhaps
>>> even with future versions of Hawkular.
>>>
>>> Unless there's a way to tell Wildfly to load the system
>>> properties from
>>> a separate file. This would be the best of two worlds.
>>>
>>> - Juca.
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev(a)lists.jboss.org
>>> <mailto:hawkular-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev(a)lists.jboss.org
<mailto:hawkular-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
10:25 p.m.
New subject: Installer
So how about a dedicated property file that contains the things the user
needs to set for Hawkular, and then a script that takes the values for the
property file and uses offline-cli commands to put the values into the
standalone.xml? From then on they are manageable. The user would not have
reason to go back to the property file. It would essentially be one time
use.
~jd
On Fri, Jan 29, 2016 at 11:45 AM, Juraci Paixão Kröhling <
jpkroehling(a)redhat.com> wrote:
Then it's still treated as "external" and cannot be
managed by tools
that are Wildfly CLI-aware ?
- Juca.
On 29.01.2016 15:57, John Mazzitelli wrote:
> The file is NOT managed by WildFly, it can be whatever file you want,
read-only, read-write, doesn't matter. The way RHQ did it, we shipped
rhq-server.properties in a directory that was familiar with customers so
they knew where it was and could edit it easily.
>
> ----- Original Message -----
>> I did not know about this :) Do you know if the file is then managed by
>> Wildfly, or is it read-only?
>>
>> - Juca.
>>
>> On 29.01.2016 15:39, John Doyle wrote:
>>> You can do this:
>>>
>>> $JBOSS_HOME/bin/standalone.sh
--properties=$JBOSS_HOME/my-jboss.properties
>>>
>>> Maybe I'm oversimplifying?
>>>
>>> On Fri, Jan 29, 2016 at 9:16 AM, Thomas Heute <theute(a)redhat.com
>>> <mailto:theute@redhat.com>> wrote:
>>>
>>> Yes, it's what I hoped for (but really have no idea if that can
work).
>>>
>>> On Fri, Jan 29, 2016 at 3:06 PM, Juraci Paixão Kröhling
>>> <jpkroehling(a)redhat.com <mailto:jpkroehling@redhat.com>>
wrote:
>>>
>>> The advantage I see in managing the properties inside
>>> standalone.xml is
>>> that it can be managed via Wildfly CLI and compatible tools.
>>> Perhaps
>>> even with future versions of Hawkular.
>>>
>>> Unless there's a way to tell Wildfly to load the system
>>> properties from
>>> a separate file. This would be the best of two worlds.
>>>
>>> - Juca.
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev(a)lists.jboss.org <mailto:
hawkular-dev(a)lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org
>
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
9:11 a.m.
New subject: Installer
I like this idea. Instead of a script, we could have a "first boot"
service that would perform this operation.
- Juca.
On 29.01.2016 22:25, John Doyle wrote:
So how about a dedicated property file that contains the things the
user
needs to set for Hawkular, and then a script that takes the values for
the property file and uses offline-cli commands to put the values into
the standalone.xml? From then on they are manageable. The user would
not have reason to go back to the property file. It would essentially be
one time use.
~jd
On Fri, Jan 29, 2016 at 11:45 AM, Juraci Paixão Kröhling
<jpkroehling(a)redhat.com <mailto:jpkroehling@redhat.com>> wrote:
Then it's still treated as "external" and cannot be managed by tools
that are Wildfly CLI-aware ?
- Juca.
On 29.01.2016 15:57, John Mazzitelli wrote:
> The file is NOT managed by WildFly, it can be whatever file you
want, read-only, read-write, doesn't matter. The way RHQ did it, we
shipped rhq-server.properties in a directory that was familiar with
customers so they knew where it was and could edit it easily.
>
> ----- Original Message -----
>> I did not know about this :) Do you know if the file is then
managed by
>> Wildfly, or is it read-only?
>>
>> - Juca.
>>
>> On 29.01.2016 15:39, John Doyle wrote:
>>> You can do this:
>>>
>>> $JBOSS_HOME/bin/standalone.sh
--properties=$JBOSS_HOME/my-jboss.properties
>>>
>>> Maybe I'm oversimplifying?
>>>
>>> On Fri, Jan 29, 2016 at 9:16 AM, Thomas Heute
<theute(a)redhat.com <mailto:theute@redhat.com>
>>> <mailto:theute@redhat.com <mailto:theute@redhat.com>>>
wrote:
>>>
>>> Yes, it's what I hoped for (but really have no idea if
that can work).
>>>
>>> On Fri, Jan 29, 2016 at 3:06 PM, Juraci Paixão Kröhling
>>> <jpkroehling(a)redhat.com <mailto:jpkroehling@redhat.com>
<mailto:jpkroehling@redhat.com <mailto:jpkroehling@redhat.com>>>
wrote:
>>>
>>> The advantage I see in managing the properties inside
>>> standalone.xml is
>>> that it can be managed via Wildfly CLI and compatible
tools.
>>> Perhaps
>>> even with future versions of Hawkular.
>>>
>>> Unless there's a way to tell Wildfly to load the system
>>> properties from
>>> a separate file. This would be the best of two worlds.
>>>
>>> - Juca.
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev(a)lists.jboss.org
<mailto:hawkular-dev@lists.jboss.org>
<mailto:hawkular-dev@lists.jboss.org
<mailto:hawkular-dev@lists.jboss.org>>
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev(a)lists.jboss.org
<mailto:hawkular-dev@lists.jboss.org>
<mailto:hawkular-dev@lists.jboss.org
<mailto:hawkular-dev@lists.jboss.org>>
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
11:44 a.m.
New subject: Installer
i still don't get why it needs to be so complicated
If we do:
<subsystem xmlns="urn:org.hawkular.agent:agent:1.0"
autoDiscoveryScanPeriodSecs="600"
enabled="{hawkular.embedded-agent.enabled}">
<diagnostics enabled="true" interval="1"
reportTo="LOG"
timeUnits="minutes"/>
<storage-adapter
password="${hawkular.embedded-agent.password}""
serverOutboundSocketBindingRef="hawkular" type="HAWKULAR"
username="${hawkular.embedded-agent.username}"/>
instead of putting the values directly (and we can even still default the
values).
Then we just need to provide a file such as:
hawkular.properties
with
hawkular.embedded-agent.enabled=true
hawkular.embedded-agent.username=jdoe
hawkular.embedded-agent.password=password
and start with:
sh standalone.sh -P hawkular.properties
IMO it's much easier for a user to read/modify the property files for the
things that are expected to be changed by the user rather than messing with
standalone.xml (it's still an option for die-hard users).
What am I missing ?
Thomas.
On Mon, Feb 1, 2016 at 9:11 AM, Juraci Paixão Kröhling <
jpkroehling(a)redhat.com> wrote:
I like this idea. Instead of a script, we could have a "first
boot"
service that would perform this operation.
- Juca.
On 29.01.2016 22:25, John Doyle wrote:
> So how about a dedicated property file that contains the things the user
> needs to set for Hawkular, and then a script that takes the values for
> the property file and uses offline-cli commands to put the values into
> the standalone.xml? From then on they are manageable. The user would
> not have reason to go back to the property file. It would essentially be
> one time use.
>
> ~jd
>
> On Fri, Jan 29, 2016 at 11:45 AM, Juraci Paixão Kröhling
> <jpkroehling(a)redhat.com <mailto:jpkroehling@redhat.com>> wrote:
>
> Then it's still treated as "external" and cannot be managed by
tools
> that are Wildfly CLI-aware ?
>
> - Juca.
>
> On 29.01.2016 15:57, John Mazzitelli wrote:
> > The file is NOT managed by WildFly, it can be whatever file you
> want, read-only, read-write, doesn't matter. The way RHQ did it, we
> shipped rhq-server.properties in a directory that was familiar with
> customers so they knew where it was and could edit it easily.
> >
> > ----- Original Message -----
> >> I did not know about this :) Do you know if the file is then
> managed by
> >> Wildfly, or is it read-only?
> >>
> >> - Juca.
> >>
> >> On 29.01.2016 15:39, John Doyle wrote:
> >>> You can do this:
> >>>
> >>> $JBOSS_HOME/bin/standalone.sh
> --properties=$JBOSS_HOME/my-jboss.properties
> >>>
> >>> Maybe I'm oversimplifying?
> >>>
> >>> On Fri, Jan 29, 2016 at 9:16 AM, Thomas Heute
> <theute(a)redhat.com <mailto:theute@redhat.com>
> >>> <mailto:theute@redhat.com
<mailto:theute@redhat.com>>> wrote:
> >>>
> >>> Yes, it's what I hoped for (but really have no idea if
> that can work).
> >>>
> >>> On Fri, Jan 29, 2016 at 3:06 PM, Juraci Paixão Kröhling
> >>> <jpkroehling(a)redhat.com
<mailto:jpkroehling@redhat.com>
> <mailto:jpkroehling@redhat.com <mailto:jpkroehling@redhat.com>>>
wrote:
> >>>
> >>> The advantage I see in managing the properties inside
> >>> standalone.xml is
> >>> that it can be managed via Wildfly CLI and compatible
> tools.
> >>> Perhaps
> >>> even with future versions of Hawkular.
> >>>
> >>> Unless there's a way to tell Wildfly to load the
system
> >>> properties from
> >>> a separate file. This would be the best of two worlds.
> >>>
> >>> - Juca.
> >>> _______________________________________________
> >>> hawkular-dev mailing list
> >>> hawkular-dev(a)lists.jboss.org
> <mailto:hawkular-dev@lists.jboss.org>
> <mailto:hawkular-dev@lists.jboss.org
> <mailto:hawkular-dev@lists.jboss.org>>
> >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> hawkular-dev mailing list
> >>> hawkular-dev(a)lists.jboss.org
> <mailto:hawkular-dev@lists.jboss.org>
> <mailto:hawkular-dev@lists.jboss.org
> <mailto:hawkular-dev@lists.jboss.org>>
> >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >>>
> >>>
> >> _______________________________________________
> >> hawkular-dev mailing list
> >> hawkular-dev(a)lists.jboss.org <mailto:
hawkular-dev(a)lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >>
> >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org
>
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
11:58 a.m.
New subject: Installer
On 03.02.2016 11:44, Thomas Heute wrote:
What am I missing ?
Tooling support. Using an external properties file would require tools
that are already compatible with Wildfly to make adaptations to support
Hawkular.
I'm not sure which one is better, though: to allow admins to change
Hawkular properties via tools they use for managing Wildfly (via CLI?
Admin console?), or to externalize it all in a "hawkular.properties"
file, which can also be easily managed via ansible/puppet/chef.
- Juca.
12:25 p.m.
New subject: Installer
On Wed, Feb 3, 2016 at 11:58 AM, Juraci Paixão Kröhling <
jpkroehling(a)redhat.com> wrote:
On 03.02.2016 11:44, Thomas Heute wrote:
> What am I missing ?
Tooling support. Using an external properties file would require tools
that are already compatible with Wildfly to make adaptations to support
Hawkular.
I'm not sure which one is better, though: to allow admins to change
Hawkular properties via tools they use for managing Wildfly (via CLI? Admin
console?), or to externalize it all in a "hawkular.properties" file, which
can also be easily managed via ansible/puppet/chef.
IMO going to Wildfly management tools to configure Hawkular is IMO not a
great experience.
IMO for Hawkular users, Wildfly is an internal detail and its complexity
should be relatively hidden.
Thomas
- Juca.
12:27 p.m.
New subject: Installer
On 03.02.2016 12:25, Thomas Heute wrote:
IMO going to Wildfly management tools to configure Hawkular is IMO
not a
great experience.
IMO for Hawkular users, Wildfly is an internal detail and its complexity
should be relatively hidden.
That's a valid point. The counter point, to me, is that if/when Hawkular
adds the possibility to manage this aspect of Wildfly (properties), we
get Hawkular support for free :) Hawkular managing itself!
- Juca.
12:31 p.m.
New subject: Installer
On Wed, Feb 3, 2016 at 12:27 PM, Juraci Paixão Kröhling <
jpkroehling(a)redhat.com> wrote:
On 03.02.2016 12:25, Thomas Heute wrote:
> IMO going to Wildfly management tools to configure Hawkular is IMO not a
> great experience.
>
> IMO for Hawkular users, Wildfly is an internal detail and its complexity
> should be relatively hidden.
>
That's a valid point. The counter point, to me, is that if/when Hawkular
adds the possibility to manage this aspect of Wildfly (properties), we get
Hawkular support for free :) Hawkular managing itself!
If needed, yes but I don't see how one exclude the other one.
Thomas
- Juca.
10:19 p.m.
New subject: Installer
EAP 7/WildFly 10 CLI can now modify the configuration w/o running the
server at all. Maybe that fits the bill.
~jd
On Wed, Jan 27, 2016 at 6:48 AM, Thomas Segismont <tsegismo(a)redhat.com>
wrote:
Totally agree with Mazz (with respect to the rabbit hole).
Simple scripts for common install tasks (add-user/etc...) should be
enough. And they should not require the server to be half-started but
simply operate on files.
Le 26/01/2016 22:47, John Mazzitelli a écrit :
> After seeing the work involved in prior products' installers, it is my
recommendation we do everything in our power to avoid writing a custom
installer and to not worry about covering all customization/configuration
possibilities.
>
> Perhaps we write a simple bash script that takes a few parameters and
does a bunch of simple file manipulations to change standalone.xml, push
files from here to there, that kind of thing. But unless we want to devote
alot of time and resources to do it "right" let's try avoid writing an
installer. That is a rabbit hole I don't think we should commit to going
down right now.
>
> Just my $0.02 based on past experience.
>
> ----- Original Message -----
>> On 26 Jan 2016, at 14:25, John Doyle wrote:
>>
>>> Is ansible a viable technology for this?
>>
>> I am sure that we can supply playbooks for
>> users that already use Ansible.
>> I am not sure though that "requiring" Ansible
>> to get a decent install / start experience is
>> the way forward.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
10:20 p.m.
New subject: Installer
Nevermind, see that was suggested in a later response.
On Fri, Jan 29, 2016 at 4:19 PM, John Doyle <jdoyle(a)redhat.com> wrote:
EAP 7/WildFly 10 CLI can now modify the configuration w/o running
the
server at all. Maybe that fits the bill.
~jd
On Wed, Jan 27, 2016 at 6:48 AM, Thomas Segismont <tsegismo(a)redhat.com>
wrote:
> Totally agree with Mazz (with respect to the rabbit hole).
>
> Simple scripts for common install tasks (add-user/etc...) should be
> enough. And they should not require the server to be half-started but
> simply operate on files.
>
> Le 26/01/2016 22:47, John Mazzitelli a écrit :
> > After seeing the work involved in prior products' installers, it is my
> recommendation we do everything in our power to avoid writing a custom
> installer and to not worry about covering all customization/configuration
> possibilities.
> >
> > Perhaps we write a simple bash script that takes a few parameters and
> does a bunch of simple file manipulations to change standalone.xml, push
> files from here to there, that kind of thing. But unless we want to devote
> alot of time and resources to do it "right" let's try avoid writing an
> installer. That is a rabbit hole I don't think we should commit to going
> down right now.
> >
> > Just my $0.02 based on past experience.
> >
> > ----- Original Message -----
> >> On 26 Jan 2016, at 14:25, John Doyle wrote:
> >>
> >>> Is ansible a viable technology for this?
> >>
> >> I am sure that we can supply playbooks for
> >> users that already use Ansible.
> >> I am not sure though that "requiring" Ansible
> >> to get a decent install / start experience is
> >> the way forward.
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
1:49 p.m.
* Dorking around with standalone.xml to chose up a mail server
About the mail server configuration, today we are using the Session managed by the server
and configured via standalone.xml (accounts and alerts).
In case of the email plugin on alerts, the name of the session is configurable via system
env properties, so it could be valid to use a different one in the future (thinking on
scenarios of different mail servers per tenant).
How do we want to proceed ? I have several questions related to this and the installer
that may affect in how to implement it:
- Do we want to configure the mail servers on standalone.xml or externally ?
- There is a comment in one of the JIRA that it could be good to use a UI for configure
mail servers. So this makes me wonder where this configuration should be stored.
(Perhaps this is just a problem for mail servers but not for other configuration, as I
don't think in runtime we are going to change the C* server or the KeycloakDS
database).
Lucas
2998
days inactive
3006
days old
29 comments
7 participants
participants (7)
-
Heiko W.Rupp -
John Doyle -
John Mazzitelli -
Juraci Paixão Kröhling -
Lucas Ponce -
Thomas Heute -
Thomas Segismont