2:59 a.m.
taken form the jboss_7_0.xsd :
<xs:complexType name="deploymentType">
<xs:annotation>
<xs:documentation>Deployment represents anything that can be deployed
(e.g. an application such as EJB-JAR,
WAR, EAR,
any kind of standard archive such as RAR or JBoss-specific deployment),
which can be enabled or disabled on a domain level.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="mapped-deploymentType">
<xs:attribute name="allowed" use="optional"
type="xs:boolean" default="true">
<xs:annotation>
<xs:documentation>Whether the mapping the deployment to a
server group is allowed.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Can somebody explain the attribute "allowed" to me? What does it mean, if a
deployment is not "allowed" to be mapped
to a server group? Is this an equivalent to "disabled"?
Ike
10:04 a.m.
Yes, the intent was equivalent to "disabled".
There are really two similar notions in the xsd and I'd like to clean
them up, so I'll semi-hijack this thread to discuss that:
1) This "allowed" flag which if false says that mapping the deployment
to a server-group is forbidden. If the deployment can't be mapped it
will never be deployed. If "false" the deployment is present in the
central deployment content repo maintained by the domain controller but
wouldn't get pushed to any other hosts.
2) A "start" flag that indicates whether deployment content that is
available on the host is actually deployed (and should be deployed at
server start). If "false" the content is available for use on the host
but isn't actually deployed. This applies to both domain mode and
standalone mode.
I don't see much point to "allowed". And "start" is a poor name.
So I'd
like to:
a) get rid of "allowed".
b) change "start" to "disabled"
Thoughts?
On 2/18/11 2:59 AM, Heiko Braun wrote:
taken form the jboss_7_0.xsd :
<xs:complexType name="deploymentType">
<xs:annotation>
<xs:documentation>Deployment represents anything that can be deployed
(e.g. an application such as EJB-JAR,
WAR, EAR,
any kind of standard archive such as RAR or JBoss-specific deployment),
which can be enabled or disabled on a domain level.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="mapped-deploymentType">
*<xs:attribute name="allowed" use="optional"
type="xs:boolean"
default="true">*
<xs:annotation>
<xs:documentation>W*hether the mapping the deployment to a server group
is allowed.*
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Can somebody explain the attribute "allowed" to me? What does it mean,
if a deployment is not "allowed" to be mapped
to a server group? Is this an equivalent to "disabled"?
Ike
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
11:02 a.m.
+1
I was thinking along the same lines.
A domain deployment either disabled or not. But If it's enabled,
it still needs to be referenced from a server group. Otherwise it just sits
in the domain controller repo.
IMO, the "disabled" attribute would be sufficient.
But what happens when a previously enabled and referenced deployment (deployed to host)
is disabled? Will it be removed from the host?
Ike
On Feb 18, 2011, at 5:04 PM, Brian Stansberry wrote:
a) get rid of "allowed".
b) change "start" to "disabled"
Thoughts?
12:29 p.m.
On 2/18/11 11:02 AM, Heiko Braun wrote:
+1
I was thinking along the same lines.
A domain deployment either disabled or not. But If it's enabled,
it still needs to be referenced from a server group. Otherwise it just sits
in the domain controller repo.
IMO, the "disabled" attribute would be sufficient.
But what happens when a previously enabled and referenced deployment (deployed to host)
is disabled?
I was thinking the "disabled" flag would not exist in domain.xml on:
<domain>
<deployments>
<deployments name="xxx" runtime-name="xxx"
sha1="asfs"/>
</deployments>
</domain>
That element simply records what's available in the central deployment repo.
The "disabled" only exists on
<domain><server-groups><server-group name="agroup">
<deployments>
<deployments name="xxx" runtime-name="xxx"
sha1="asfs"
disabled="true"/>
</deployments>
</server-group><server-groups></domain>
and in standalone.xml:
<server>
<deployments>
<deployments name="xxx" runtime-name="xxx"
sha1="asfs"
disabled="true"/>
</deployments>
</server>
Basically whether a deployment is actually installed into the runtime or
not is a server-group/standalone-server level configuration, it's not
global across the domain. Different server groups can have different
configurations.
Will it be removed from the host?
For the content to be physically removed from a host it would need to be
unmapped from all server-groups associated with the host; once that
happens the contents is garbage eligible for collection. I want to do
the actual removal with a background task, something like the way git gc
works.
Ike
On Feb 18, 2011, at 5:04 PM, Brian Stansberry wrote:
> a) get rid of "allowed".
> b) change "start" to "disabled"
>
> Thoughts?
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
12:34 p.m.
On 02/18/2011 12:29 PM, Brian Stansberry wrote:
On 2/18/11 11:02 AM, Heiko Braun wrote:
>
> +1
>
> I was thinking along the same lines.
> A domain deployment either disabled or not. But If it's enabled,
> it still needs to be referenced from a server group. Otherwise it just sits
> in the domain controller repo.
>
> IMO, the "disabled" attribute would be sufficient.
> But what happens when a previously enabled and referenced deployment (deployed to
host)
> is disabled?
I was thinking the "disabled" flag would not exist in domain.xml on:
<domain>
<deployments>
<deployments name="xxx" runtime-name="xxx"
sha1="asfs"/>
</deployments>
</domain>
That element simply records what's available in the central deployment repo.
Indeed. My research is indicating that this may not even make sense to
do any more - we don't get any value from it other than validation. And
there will come a time in the near future when content items do not
correspond to deployments on a 1:1 basis; so this will merely be a
declaration of what's in the content repository.
I'm starting to think that this information (domain-level deployment
element data) is completely superfluous.
--
- DML
1:46 p.m.
On 2/18/11 12:34 PM, David M. Lloyd wrote:
On 02/18/2011 12:29 PM, Brian Stansberry wrote:
> On 2/18/11 11:02 AM, Heiko Braun wrote:
>>
>> +1
>>
>> I was thinking along the same lines.
>> A domain deployment either disabled or not. But If it's enabled,
>> it still needs to be referenced from a server group. Otherwise it just sits
>> in the domain controller repo.
>>
>> IMO, the "disabled" attribute would be sufficient.
>> But what happens when a previously enabled and referenced deployment (deployed to
host)
>> is disabled?
>
> I was thinking the "disabled" flag would not exist in domain.xml on:
>
> <domain>
> <deployments>
> <deployments name="xxx" runtime-name="xxx"
sha1="asfs"/>
> </deployments>
> </domain>
>
> That element simply records what's available in the central deployment repo.
Indeed. My research is indicating that this may not even make sense to
do any more - we don't get any value from it other than validation. And
there will come a time in the near future when content items do not
correspond to deployments on a 1:1 basis; so this will merely be a
declaration of what's in the content repository.
I'm starting to think that this information (domain-level deployment
element data) is completely superfluous.
It's also the authoritative mapping between the name and the hash. (If
it becomes 1:n then it would become a mapping between name and hashes).
Besides being for validation, it allows the user to access the mapping
info, e.g. if they add some content today and then want to actually push
it to server groups tomorrow. A bit contrived, I admit.
I'd love to make the whole hash thing go away, or at least make it
invisible to the end user. Right now there's a few things driving the
need for the hash:
1) The process of adding content in the past involved two steps (which
the deployment manager convenience API hid from users):
uploading/storing content and then assigning a name to the content. The
hash got returned to the client after the first, and then passed back to
the server when the user assigned the name.
When we implement the idea of being able to associate streams with an
operation request, that will eliminate the need for doing things in 2 steps.
2) If you do a "full replace" operation, where you have version 2 of
foo.war replacing version 1, the two distinct hashes are used to
discriminate the two sets of content as the operation is carried out.
3) The hashes are useful in ensuring that a host's copy of content is
consistent with the central repo.
I'll think a bit about whether how 2) and 3) work can be changed such
that the hashes are purely internal details that don't need to be
exposed to the end user.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
2:07 p.m.
On 02/18/2011 01:46 PM, Brian Stansberry wrote:
On 2/18/11 12:34 PM, David M. Lloyd wrote:
> On 02/18/2011 12:29 PM, Brian Stansberry wrote:
>> On 2/18/11 11:02 AM, Heiko Braun wrote:
>>>
>>> +1
>>>
>>> I was thinking along the same lines.
>>> A domain deployment either disabled or not. But If it's enabled,
>>> it still needs to be referenced from a server group. Otherwise it just sits
>>> in the domain controller repo.
>>>
>>> IMO, the "disabled" attribute would be sufficient.
>>> But what happens when a previously enabled and referenced deployment
(deployed to host)
>>> is disabled?
>>
>> I was thinking the "disabled" flag would not exist in domain.xml on:
>>
>> <domain>
>> <deployments>
>> <deployments name="xxx" runtime-name="xxx"
sha1="asfs"/>
>> </deployments>
>> </domain>
>>
>> That element simply records what's available in the central deployment repo.
>
> Indeed. My research is indicating that this may not even make sense to
> do any more - we don't get any value from it other than validation. And
> there will come a time in the near future when content items do not
> correspond to deployments on a 1:1 basis; so this will merely be a
> declaration of what's in the content repository.
>
> I'm starting to think that this information (domain-level deployment
> element data) is completely superfluous.
It's also the authoritative mapping between the name and the hash. (If
it becomes 1:n then it would become a mapping between name and hashes).
Besides being for validation, it allows the user to access the mapping
info, e.g. if they add some content today and then want to actually push
it to server groups tomorrow. A bit contrived, I admit.
Yeah in the future there probably won't be a (technical) need for such a
mapping because the hash will be associated purely with content and not
a deployment, so you'd be able to have:
<deployment name="foo.war">
<content id="000001"/>
<content id="000002"/>
</deployment>
<deployment name="bar.war">
<content id="000001"/>
<content id="000003"/>
</deployment>
or even mixed content specs like this:
<deployment name="foo.war">
<content id="000001"/>
<filesystem-content relative-to="jboss.deploy.dir"
name="my-content.jar"/>
</deployment>
If we drop the notion of attaching names to content then this is the end
of it. If not then it probably makes more sense to have <content>
declarations in the domain (and standalone) config where names are stuck
on to different content bits. But at this point it's not clear what the
benefit would be (well, except for the possibly major benefit that we
would not be forcing the users to pick a domain-wide unique name for
every blob that they deploy into a domain).
I'd love to make the whole hash thing go away, or at least make
it
invisible to the end user. Right now there's a few things driving the
need for the hash:
1) The process of adding content in the past involved two steps (which
the deployment manager convenience API hid from users):
uploading/storing content and then assigning a name to the content. The
hash got returned to the client after the first, and then passed back to
the server when the user assigned the name.
Yeah I guess this wouldn't change much, at least superficially.
When we implement the idea of being able to associate streams with
an
operation request, that will eliminate the need for doing things in 2 steps.
2) If you do a "full replace" operation, where you have version 2 of
foo.war replacing version 1, the two distinct hashes are used to
discriminate the two sets of content as the operation is carried out.
3) The hashes are useful in ensuring that a host's copy of
content is
consistent with the central repo.
I'll think a bit about whether how 2) and 3) work can be changed such
that the hashes are purely internal details that don't need to be
exposed to the end user.
Yeah that'll be tricky.
--
- DML
2:15 p.m.
On 02/18/2011 02:07 PM, David M. Lloyd wrote:
Train-of-thought-derailment error:
on to different content bits. But at this point it's not clear
what the
benefit would be (well, except for the possibly major benefit that we
would not be forcing the users to pick a domain-wide unique name for
every blob that they deploy into a domain).
Rather: "But at this point it's not clear what the benefit would be -
in fact by doing this, we would no longer be forcing the users to pick a
domain-wide unique name for every blob that they deploy into a domain".
--
- DML
4842
days inactive
4842
days old
7 comments
3 participants
participants (3)
-
Brian Stansberry -
David M. Lloyd -
Heiko Braun