On Thursday, May 22, 2014 11:17:48 AM UTC-5, Ritesh Nanda wrote:
>
> Hello John,
>
> Thanks for your reply , sorry for providing less information .
> I am working on developing websphere multi-node deployment module
>
>From the (little) code you provided, I infer that you are using the term
"module" in a generic sense, rather than with the more specific meaning
that word has in Puppet jargon. You really should organize your code into
a *bona fide* Puppet module. That won't address the problem you are
currently trying to solve, but it is likely to be to your advantage in a
more general way.
> , in that i have two roles one is deploymanager another is appserver.
>
> I have a type and provider already created for it which run on the
> deploymanager , which needs certain values like hostname , which would be
> dynamically generated when the machine is provisioned .
>
So I think you're saying the hostname etc. are not Puppet's responsibility;
you are simply dealing with the fact that you don't know them in advance.
>
> @@websphere_profile { $servertype:
> ensure => $ensure_profile,
> hostname => $fqdn,
> profilename => $ndm_profilename,
> profilepath => $profilepath,
> templatepath => $templatepath,
> cellname => $cellname,
> nodename => $nodename,
> port => $start_port,
> enableadminsecurity => $enableadminsecurity,
> adminusername => $adminusername,
> adminpassword => $adminpassword,
> appservernodename => $appservernodename,
> tag => websphere,
> }
>
>
> this resource type first runs on the deploymanager machine which gets
> provisioned , making it exported resource will store its attributes value
> in puppetdb .
>
"Runs on" is a somewhat confusing description, especially when you're
talking about an exported resource. Resource declarations are not
executable, so they do not "run". Most do cause a resource to be recorded
in the node's catalog, to which the agent (or 'apply') will respond by
taking some sort of action, but even that does not happen as a direct
consequence of the declaration of an exported resource.
In part for that reason I remain uncertain whether you are running Puppet
in agent / master mode or whether you are using "puppet apply" with local
manifests and data. It may make a difference.
Furthermore, I think it important that you understand that having exported
resource data recorded in PuppetDB is a means to an end, not an end in
itself. The point of an exported resource is for information specific to
one node to be used to configure a resource that can be applied to other
nodes.
>
> Once this machine is completed , a new machine would be provisioned which
> would be appserver , then appserver will also run this resource type
> providing fqdn from the puppetdb of the deploymanager which is stored by
> the exported resource.
>
>
Do you mean that the deploymanager's websphere_profile resource is to be
collected (imported) into the appserver's catalog, so that it will be
applied to the appserver? That would be the normal usage pattern for
exported resources, but it is unclear whether that's what you mean. It
sounds more like you're saying the appserver will export its own
websphere_profile resource. But if that's so, then to what machine are
these exported resources ever applied?
> Now this whole piece would be run by a end-user who will just see a
> catalog , saying multi-node websphere.
>
>
That totally does not make sense. I'm not sure exactly how you would apply
a pre-compiled catalog to a random machine, but certainly that scenario
won't get you additional websphere_profile resources exported, since
exported resources are enrolled in the storeconfigs backend (e.g. puppetdb)
during catalog *compilation*, not during catalog application.
> *Another scenerio in case simultaneously two users runs that module ,
>> first machine save its hostname , same time again that module is intiated
>> by another user , now the latest machine would overwrite the entry in
>> puppetdb.*
>>
>>
>
> *Why would you suppose that one machine's data would overwrite a different
> one's? Puppet distinguishes one machine from another by their certs,
> unless you intentionally confuse it by manually assigning the same cert to
> multiple machines. Puppetdb associates node data with node identity, so
> one node's data will not overwrite a different one's.*
>
> Now if this catalog is ran by two users at the same time , as the exported
> resource will save information with the tag websphere. As there would be
> two multinode websphere deployment at the same time , how will puppet know
> how appserver gets the hostname of its correct deploymanager.
>
>
If you intend to be able to manage multiple distinct websphere clusters in
the same Puppet context (as defined by sharing a puppetdb instance),
whether concurrently or serially, then you are right that you need a means
to distinguish the members of each one from the members of the others. One
way would be to assign cluster identifiers of your choosing (e.g. cluster1,
cluster2, cluster20140523-rnanda-1) by which to associate members of the
same cluster. Your machines can feed that to Puppet via a custom fact. Do
note, however, that using a fact for this purpose implies that you trust
the clients to correctly self-declare to which cluster they belong.
Given a cluster identifier, you could tag resources with something like
"websphere-${::clusterid}" instead of with plain "websphere".
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/d79007c9-e313-4a77-829e-34cc90911700%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
