Thanks John,
Thanks for help.
Regards,
Ritesh Nanda
On Tue, May 27, 2014 at 7:54 AM, jcbollinger <john.bollin...@stjude.org>wrote:
>
>
> On Friday, May 23, 2014 3:37:33 PM UTC-5, Ritesh Nanda wrote:
>>
>> Hi John,
>>
>> Thanks for reply again .
>>
>> *That totally does not make sense. I'm not sure exactly how you would
>> apply a pre-compiled catalog to a random machine.*
>>
>> This setup would leverage vmware appdirector and integration with puppet
>> master , Where i will create blueprint of first creating a vm and to apply
>> a particular manifest on that node. So vm creation part and puppet run on
>> the node, node defination is not my responsiblity . It will be done by App
>> direct
>>
>> So end user would just the catalog.
>>
>>
>
> "Pay no attention to the man behind the curtain," as the Wizard once
> said. But that doesn't work for us any better than it worked for him.
>
> I don't know details of how App direct works, but I find it highly
> unlikely that it involves applying pre-compiled catalogs. It is far more
> likely to involve applying automatic configuration of Puppet itself, and
> followed be automatically running Puppet, whether in 'agent' mode or
> 'apply' mode, to at that time obtain and apply a catalog for the node.
>
> This does make a difference, especially given that you are planning to use
> exported resources.
>
>
>
>>
>> This setup you can treat it as a multinode or a cluster setup . Where i
>> have these two components deploymanager and appserver in a puppet module. I
>> have them both in separate classes. So that they can be called on
>> respective nodes.
>>
>> a example Now in a setup of 2 vms there would be one deploymanager which
>> would be created and 1 appserver (later i will work on making it user
>> choice on no. of appserver he wants) will be created and this/these
>> appservers would register itself with the deploymanager.
>> That is the case where i want to export fqdn of deploymanager in puppetdb
>> so that it can be used by these appserver nodes to register itself with
>> deploymanager.
>>
>
>
>> Now the custom resource type i pasted .
>>
>> class websphere::deploymanager
>> {
>>
>> *websphere_profile { "Deployment manager":*
>> * ensure => true,*
>> * hostname =>$fqdn*
>> }
>> }
>>
>>
>> It will be ran on the deploymanager , this resource actually makes that
>> node as deploymanager (its a websphere command basically).
>> You are correct if i make this resource as exported it will not be ran on
>> this node. As i only need fqdn of this node to be exported, is there a way
>> to do it.
>>
>>
>> Then this custom resource is also needed to be ran on the two appserver
>> nodes which would be created. Specifying the fqdn of deploymanager so that
>> these appserver nodes can register itself with deploymanger.
>>
>> class websphere::appserver
>> {
>> *websphere_profile { "Appserver1":*
>> * ensure => true,*
>> * hostname => (Hostname of deploymanager)*
>>
>> }
>> }
>> In this way these nodes will register itself with Deploymanager.
>>
>>
>
> Yuck. You might be able to get something along these lines to work, but
> it is not very idiomatic. Also, it's probably a lot more work to build and
> maintain than you need.
>
> In Puppet, the term "resource" refers to some reasonably self-contained
> aspect of target nodes that can be managed by Puppet -- a File, a service,
> etc.. Your "websphere_profile" seems instead to be a blob of loosely
> associated data with a split personality. You are trying to put a whole
> (Puppet) module's worth of functionality into a single custom type.
> Probably you don't actually need a custom type at all, just ordinary
> (Puppet) classes, built-in resource types, and one or two defined types.
>
> Here's a rough sketch of how I could see this working:
>
> class websphere::deploymanager ($clusterid, ...) {
> # Exported for app servers' use:
> @@websphere::deploymanager_registration { $clusterid: }
>
> # ... All the Files, Packages, etc. that a DeployManager needs
> }
>
> class websphere::appserver($clusterid, ...) {
> Websphere::Deploymanager_registration<<| name == $clusterid |>>
> # ... All the Files, Packages, etc. that an app server needs
> }
>
> define websphere::deploymanager_registration (...) {
> # Whatever File, Exec, etc. is necessary for registering
> # an app server with a deploymanager.
> }
>
>
> With that you declare the websphere::deploymanager class on (only) the
> deploymanager, and you declare the websphere::appserver class on all
> appservers (including the deploymanager if it also functions as an app
> server).
>
>
> John
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/NM3vaVmOG1U/unsubscribe.
> To unsubscribe from this group and all its topics, 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/f228f238-c0da-49da-9420-52b224009183%40googlegroups.com<https://groups.google.com/d/msgid/puppet-users/f228f238-c0da-49da-9420-52b224009183%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
* With Regards *
* Ritesh Nanda*
<http://www.ericsson.com/>
--
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/CAO5CbpAhZ_YpKuUE_89foqs%2Bc4sJNBvbTkZxgjj44-WfPZuZoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
