Weaver runtime
Hi, I'm trying to understand the automation behavior of SmartCloud Continuous Delivery(SCD).
I have some questions on weaver runtime,could anyone help me?
Here are the questions:
1.We can import system patterns from IWD (or SCP,Pure) into SCD(RTC) client.
Does this mean weaver runtime exits in SCD client?
2.When we execute a build by using SCD(RTC) client, who sends a request to cloud host to deploy patterns?
I think "build engine" does, and this means build engine also contains weaver runtime. Is this correct?
I have some questions on weaver runtime,could anyone help me?
Here are the questions:
1.We can import system patterns from IWD (or SCP,Pure) into SCD(RTC) client.
Does this mean weaver runtime exits in SCD client?
2.When we execute a build by using SCD(RTC) client, who sends a request to cloud host to deploy patterns?
I think "build engine" does, and this means build engine also contains weaver runtime. Is this correct?
4 answers
Hi Yohko Tanaka,
We do have access to weaver from the RTC client. We expose some behavior like the creation of new topologies. You can read more about it here:
http://pic.dhe.ibm.com/infocenter/sccdhelp/v1r0/index.jsp?topic=%2Fcom.ibm.devops.doc%2Ftopics%2Fapp_add_plan_env_tsk.html
We also expose validation in the rich client editors so that you'll get feedback from weaver on the readiness of your topologies.
To answer your second question, the Build Engine does contain the weaver runtime (which is shipped as a gem). If you take a look at the rakefile or build.xml, you'll find a reference to the environment.deploy() call, which is what generates the request into the cloud.
//rakefile example:
environment = environment.deploy(properties, deploy_parameters)
// build.xml example:
<weaver:deploy environment="environment" iwdPropertiesPrefix="iwd_properties" logLevel="${LOG_LEVEL}" />
In both of these examples, the Weaver runtime is generating the request to the cloud under the covers. All information about the parameters is being processed by weaver and transmitted to the right target. Then, a new Environment object is created and returned. The new object is populated with all of the information from the live system, so you can access information about the running system:
// rakefile example
# TODO: Reference your Weaver application definition
# For example: application = environment.jke if your application has the id :jke
application = environment.jke
# TODO: Reference your application node from the Weaver application definition that
# will be the main entry point for your application
application_node = application.app_srv
# TODO: Reference your pattern from the Weaver infrastructure definition
# For example: infrastructure = environment.my_pattern if your cloud_pattern has the id :my_pattern)
infrastructure = environment.pattern
virtual_system_id = infrastructure.vsys_instance_id
instance_ip = application_node.ip_address
// build.xml
<weaver:environment
repositoryAddress="${repositoryAddress}"
userId="${rtc_properties.user}"
passwordFile="${rtc_properties.password_file}"
refid="environment">
<weaver:assign valueOf="infrastructure.vsys_instance_id" toProperty="iwdInstanceId" />
<weaver:assign valueOf="application_node.ip_address" toProperty="iwdInstanceIpAddress" />
<weaver:assign valueOf="infrastructure.cloud_status_internal['currentstatus']" toProperty="currentstatus" />
<weaver:assign valueOf="infrastructure.cloud_status_internal['currentstatus_text']" toProperty="currentstatus_text" />
</weaver:environment>
Hope this helps!
-M
Hi Michael,
Thank you so much for the detailed explanation.
Could you elaborate on the behavior about generating environment object?
You wrote "The new object is populated with all of the information from the live system, so you can access information about the running system", does this mean the generated new environment object receive any kind of information from IWD?
My understanding was: All of the *.weaver files are processed by weaver runtime and passed to IWD, then, IWD take over the following process. ( I was thinking it's a one way process from weaver runtime to IWD)
But it sounds like IWD push information into environment object, so could you expand on what's happening in this phase?
Thank you so much for the detailed explanation.
Could you elaborate on the behavior about generating environment object?
You wrote "The new object is populated with all of the information from the live system, so you can access information about the running system", does this mean the generated new environment object receive any kind of information from IWD?
My understanding was: All of the *.weaver files are processed by weaver runtime and passed to IWD, then, IWD take over the following process. ( I was thinking it's a one way process from weaver runtime to IWD)
But it sounds like IWD push information into environment object, so could you expand on what's happening in this phase?
Hi Yohko Tanaka,
You've got it -- the environment object contains information about the running system after the call to deploy(). So IP addresses, hostnames, etc are all available. In the latest milestones, we also expose information about the status of the deployment as well.
I would adjust your understanding as follows:
Weaver provides a runtime. The runtime includes a set of Ruby objects and Command Line utilities for working with weaver documents.
IBM Workload Deployer (IWD) exposes a REST API which enables clients to cause change (like deploying a pattern) and to read information (like details about a running instance).
Weaver is using the REST API under the covers to talk to IWD. It's through this API that we cause change and read information.
Hence, IWD has no understanding of weaver topologies. Instead, Weaver is acting as a client of the REST APIs and providing a simple way to work with the information returned from the REST APIs.
Does that make more sense?