As I know Cloudify's Chef Plugin allow to define operation in keyword:
runlists:
with default prefixs are:
cloudify.interfaces.lifecycle,
cloudify.interfaces.relationship_lifecycle
So now I want to run relationship's operations such as
cloudify.interfaces.relationship_lifecycle.preconfigure
as below
runlists:
----preconfigure: scripts/pre.sh
then I don't know which interface will be run? Source interface or target?
And if I want to specify to run target interface, how can i do that?
In the chef plugin all relationship operations use the source interface.
If you want to specify to run on the target interface, you would need to add a new relationship type to the plugin with the target interface defined. However, that would only work if the target interface represents a node that is contained on a VM that has chef.
Related
I am going through this documentation and I have several uncertainties.
Performing explicit contract and state upgrades
Preserve the existing state and contract definitions
Write the new state and contract definitions
Create the new CorDapp JAR
Distribute the new CorDapp JAR
Stop the nodes
Re-run the network bootstrapper (only if you want to whitelist the
new contract)
Restart the nodes
Authorise the upgrade
Perform the upgrade
Migrate the new upgraded state to the Signature Constraint from the
zone constraint
Questions:
1. Preserve the existing state and contract definitions
2. Write the new state and contract definitions
3. Create the new CorDapp JAR
How do I do that? is it meant only to preserve jars with contracts and states on nodes, not preserving them in source code? If I do not preserve them in source code then how can I create the upgrade method?
interface UpgradedContract<in OldState : ContractState, out NewState : ContractState> : Contract {
val legacyContract: ContractClassName
fun upgrade(state: OldState): NewState
}
If I do not preserve old state in source code, then shoud I name the jar differently each time I need to do an upgrade?
Can old jars be reoved from the node when the upgrade was completed?
6. Re-run the network bootstrapper (only if you want to whitelist the
new contract)
8. Authorise the upgrade
Am I right that only those 2 steps are related to Explicit contact upgrades? And If I use implicit flow with signature, then I need to skip only those two steps, while the others are still aplicable and must be performed?
9. Perform the upgrade
Should this be done for each state separately by the owner of the state? In that case should I run it on each node for specific contrcats where the node is the participant of the state? (In doc it is mentioned to be run on single node - but what id=f a single node is not participant of some state)
Other questions
This section describes explicit contracts and states update.
https://docs.corda.net/upgrading-cordapps.html#performing-explicit-contract-and-state-upgrades while signature constraint section (https://docs.corda.net/api-contract-constraints.html#signature-constraints) does not describe an update process for states.
is it the same as for explicit upgrades with the difference only in steps 6,8 or it is somewhat completely different?
Do I need to create the function transforming old states to new states in that case? if not , then how the old states will be handled by new flows?
I see you have many some great questions about contract upgrades. Here is an article that is written by one of our dev-relation engineers. https://medium.com/corda/contract-upgrades-and-constraints-in-corda-425055a9a47f
Feel free to follow up any additional questions that you have.
If you are new to Corda, feel free to join the Corda community channels #http://slack.corda.net/
While performing legacy contract upgrades, you need both the old and new contract jars installed on your node. (present in the cordapps folder).
You can create a new Gradle module say v2-contract and write the new contract in this. This is where you will write your UpgradedContract. You will need to refer to the old v1-conract jar as well as it needs to know what the old state was. To do this add a gradle dependency in v2-contract like below.
dependencies {
// Corda dependencies.
cordapp project(v1_contract)
}
The old jar can be removed from the cordapps folder, once all the states have been upgraded to new v2-contract.
a. For HashConstraints there is no need to run the bootstrapper again. You will write the new contract by implementing UpgradedContractWithLegacyConstraint,run the jar task to build this new jar, add it to the cordapps folder, run the Authorise Flow from all nodes, run the Initiate flow from one of he node's terminal. This is the explicit way of upgrading.
b. However if you are using Whitelistzoneconstraint, you want to make sure to add the new v2-contract jar's hash to whitelist param in network param. You will need to run the network Bootstrapper to whitelist this new v2-contracts jar hash. https://docs.corda.net/network-bootstrapper.html#whitelisting-contracts.
Once you do that you can either go for an explicit upgrade by implementing UpgradedContract, or you can use implicit upgrade.
c. If you are using Signature Constraints, no need to run the network Bootstrapper for the new jar, write the new v2-contract, build it using gradle jar task, replace old jar with new jar. This is the implicit way of upgrading.
You should run the Authorise Flow for all the participants only.
Other questions
There is no explicit upgrade in Signature constraints. You need to make sure you write your state in a backward compatible way, build new jar, replace old jar with new jar. The states will refer to the new contract then.
Hope that helps. Feel free to post more questions on the above answer or ping on Slack.
In cloudera is there a way to update list of configurations at a time using CM-API or CURL?
Currently I am updating one by one one using below CM API.
services_api_instance.update_service_config()
How can we update all configurations stored in json/config file at a time.
The CM API endpoint you're looking for is PUT /cm/deployment. From the CM API documentation:
Apply the supplied deployment description to the system. This will create the clusters, services, hosts and other objects specified in the argument. This call does not allow for any merge conflicts. If an entity already exists in the system, this call will fail. You can request, however, that all entities in the system are deleted before instantiating the new ones.
This basically allows you to configure all your services with one call rather than doing them one at a time.
If you are using services that require a database (Hive, Hue, Oozie ...) then make sure you set them up before you call the API. It expects all the parameters you pass in to work so external dependencies must be resolved first.
Is it possible to scope Openstack CLI output for listing networks only for a single project. I have tried multiple options like --os-project-id, --os-project-name etc but it seems to list down all networks across multiple projects/tenants.
Currently, the command I am using is:
openstack network list --os-username XXX --os-password YYY --os-project-id ZZZ
Note: The credentials that I am using here are of an 'admin' account
Parameters set in the environment are :
OS_PROJECT_ID=XXX
OS_REGION_NAME=XXX
OS_TENANT_ID=XXX
OS_USER_DOMAIN_NAME=XXX
OS_PROJECT_NAME=XXX
OS_AUTH_VERSION=XXX
OS_IDENTITY_API_VERSION=XXX
OS_PASSWORD=XXX
OS_AUTH_URL=XXX
OS_USERNAME=XXX
OS_TENANT_NAME=XXX
OS_INTERFACE=XXX
OS_PROJECT_DOMAIN_NAME=XXX
May be your networks are shared by all tenants. If you only have a few networks you can verify with neutron net-show Network-Name and review the shared attribute
BTW I use the env variable OS_PROJECT_NAME to switch between projects
Without any explicit filter specified in the parameters, Neutron's network API returns all networks that the user accessing the API has privileges to list. The recommended way to scope down the list of networks to a specific project is to explicitly specify that filter.
Via CLI, you can scope the list to a specific project "demo" using the following example:
openstack network list --project demo
You can see more filtering options via the help text:
openstack help network list
Issues were caused by an older version of Openstack CLI v3.7.0
Using Openstack CLI version v3.13.0, I was able to solve my requirement. By default, with the domain admin account, the CLI still dumped the entire network list but with the --long flag, the 'project' field this time was populated and I could filter out the results for the specific project.
This was not the case with the previous CLI versions. Usage of '--long' flag had all the values of 'Project' as none.
Currently, all parameters passed to a template are hardcoded (for instance, Windows Vm Version: 2012-Datacenter, 2016 Datacenter and so on). is their a way to dynamically update these values based on the type of subscription or the location?
As I known, there is no in-build feature for you to dynamically update parameter values based on the type of subscription or the location. You could add your feedback here. In order to achieve this purpose, I assume that you need to add your code logic to generate the TemplateParameterFile based on the type of subscription or the location of your resource group, then leverage New-AzureRmResourceGroupDeployment command to deploy your Azure resources. Moreover, here are some common ARM templates, you could refer to them.
I'm dealing right now with following problem:
My Selenium Grid instance should connect few nodes which are in different locations and I would like to run each test in every location. How can I point to Selenium Grid that it should choose one node from each location and send test there? I tried manipulating browser name or platforms (ex. naming it firefox-pl/firefox-fr or windows-pl/windows-fr) but I received always following exception:
Selenium::WebDriver::Error::UnknownError:
Error forwarding the new session cannot find
and I found out that those values are not changeable.
Is there any other method to do it? I would not like to change browser or its version, because nature of those tests is to compare network responses on different locations and different browsers can change it.
I also come across same situation and I just think of the node and did as follows.
In one folder
1.place the selenium-server-standalone-2.44.0.jar file and set the environment variable as well.
2.create the hub: Type "java -jar selenium-server-standalone-2.44.0.jar -role hub -port 4444" in the text file and save it as Hub.bat and run it
3.Create the node: Type "java -jar selenium-server-standalone-2.44.0.jar -role node -hub http://(IP Address of the parent machine which has above two files):4444/grid/register -port 8882 -browser "browserName=firefox,maxInstances=1,applicationName=two"" and put this file in another machine and run this. Now this node will be connected with the hub.
4.If you want particular test should run in one node(client machine) then you can just specify the applicationName in the node as like in above point(3) and in setting the capabilities in the test class file as "desiredCapability.setCapability("applicationName", nodeName);".
setting the application name in the node is hidden features in selenium. Now just test and enjoy.
Sounds like you're looking to run tests in parallel, testng is a great tool to help you setup. Take a look at the following link
http://www.deepshiftlabs.com/sel_blog/?p=1932&lang=en-us
When you start the node and you are specifying the capabilities, you might consider setting maxInstances. This value controls the number of concurrent instances of that browser which can be opened on that node. If you set this to 1 - you can run tests in parallel against the Grid but only one browser will open at a time on each node.
java.exe -jar selenium-server.jar -role node -browser
"browserName=firefox,maxInstances=1,platform=ANY,seleniumProtocol=WebDriver"