Provision 2 node-type Service Fabric ARM - azure-resource-manager

I've been trying to provision a 2-node-type service fabric cluster using ARM. The secondary node type (backend) should not be exposed to the internet. For that I've created a loadbalancer with an internal IP-Address.
Everything gets provisioned correctly but I cannot get the nodes added to the cluster. From the Azure portal when I open the cluster it says it has no nodes in it even though it has the node types configured.
I have even tried downloading the template produced by the azure portal after creating a service fabric cluster. I have also executed one of the templates provided on github and I cannot still see any nodes in the cluster.
Any suggestion what I could be missing?
Thanks

Glad to hear you got that sorted. Regarding your follow-up question on deploying to the backend node-types, that's where you'd use placement constraints. When you create clusters in Azure through ARM, it automatically sets up a placement property on each node using the node type name you defined. So on your back-end nodes, assuming your node type is called "backendnode" you'll have the following placement policy defined:
NodeTypeName: backendnode
When you deploy your services, just use that as your placement constraint:
New-ServiceFabricService -ApplicationName "fabric:/myapp" -ServiceName "fabric:/myapp/myservice" -ServiceTypeName "myservicetype" -Stateful -MinReplicaSetSize 2 -TargetReplicaSetSize 3 -PartitionSchemeSingleton -PlacementConstraint "NodeTypeName == backendnode"

Related

Monitoring NebulaGraph K8s resources

We want to extend our existing monitoring to include Nebula resources such as node, service and space.
How can we do this, can you please point me to any documentation
For node, I take it as the OS/Machine level, the vanilla node exporter(and Prometheus)[0] will do the job.
For Service/Space level monitoring, we could leverage the nebula-stats-operator[1]
And actually, there is an all-in-one solution out there in the NebulaGraph community called NebulaGraph Dashboard[2], in which it wired everything together already, even if you are connecting things from scratch on your own, you could still refer to it(on how it leveraged the exporters).
For documentation, you could check the following chapters:
dashboard https://docs.nebula-graph.io/3.3.0/nebula-dashboard/1.what-is-dashboard/
metrics https://docs.nebula-graph.io/3.3.0/6.monitor-and-metrics/1.query-performance-metrics/
ref:
[0] https://github.com/prometheus/node_exporter
[1] https://github.com/vesoft-inc/nebula-stats-exporter
[2] https://github.com/vesoft-inc/nebula-dashboard

Corda, TestNet: Is it allowed to modify the X.500 name of a pre-configured Corda node downloaded from https://testnet.corda.network

We have downloaded 4 pre-configured Corda nodes from https://testnet.corda.network.
These nodes have X.500 distinguished names containing subparts - Organization, Location and Country.
Question 1: Can we replace the values in the above subparts of the X.500 distinguished name with our definitions?
Question 2: Can we add "organizationUnit" in the above X.500 name?
The Testnet was built for the community to experience the Corda network.
It is a pathway to the Corda Network (TCN) run by the Corda Foundation, an independent council which runs the TCN.
I will log your requests with the testnet team as a function enhancement request, but they will probably need more information from you & your team to make any further changes to the testnet.
You can reach me at http://slack.corda.net. We can resume the conversation there.
Yes, every node specifies its own X500 name. This is done in the node.conf using the myLegalName field: https://docs.corda.net/corda-configuration-file.html#configuration-file-fields This field is used during initial registration on the node's first startup to register with the network's identity service https://docs.corda.r3.com/node-commandline.html#sub-commands
The X500 name for a name of a node is extremely important as it represents the identity that a node uses when signing transaction. Because of this the X500 identity rules vary by network.
Testnet
The onboarding tool pre-generates an X500 for you based on your marketplace account. Your account is automatically built into a generated node.conf whichinstall.sh downloads for your node.
In Testnet there are no restrictions on identity and all registration requests are automatically approved. Therefore anyone can specify any identity they would like which is why Testnet must never be used for real financial transactions.
UAT
X500 names must followed a specific set of rules to be approved. Guidelines on how to select an X500 are here: https://corda.network/participation/distinguishedname.html
Examples of real world identity selection is here: https://corda.network/participation/legalentity.html
In UAT registration requests are all manually approved by the Corda Network Foundation. Follows the steps outlined here to onboard your node: https://uat.network.r3.com/pages/joining/joining.html
The Corda Network (tCN)
The production Corda Network follows the same guidelines for X500 names.
The onboarding process for nodes is also the same with different urls: https://corda.network/participation/index.html

How to deploy multiple nodes in Corda Testnet network?

We are building a POC using Corda and Springboot web server.
Following are the versions of Corda platform, Springboot server, and other essential dependencies used for building the POC-
cordaReleaseGroup=net.corda
cordaVersion=4.0
gradlePluginsVersion=4.0.45
kotlinVersion=1.2.71
junitVersion=4.12
quasarVersion=0.7.10
spring_version = '4.3.11.RELEASE'
spring_boot_version = '2.0.2.RELEASE'
spring_boot_gradle_plugin_version = '2.1.1.RELEASE'
jvmTarget = "1.8"
log4jVersion =2.11.2
platformVersion=4
slf4jVersion=1.7.25
nettyVersion=4.1.22.Final
The CorDapp developed for POC has four nodes -
Notary Node
Provider Company Node
Consumer Company 1 Node
Consumer Company 1 Sub Contact Node
The POC is running in dev mode in our local network.
We require to test the POC in the Corda Testnet.
We went through the following documentation on Corda Testnet -
1: Join Corda TestNet
URL : https://docs.corda.net/releases/release-V4.0/corda-testnet-intro.html?highlight=joining%20corda%20testnet
2: Deploying Corda to Corda Testnet from your local environment
https://docs.corda.net/releases/release-V4.0/deploy-locally.html?highlight=deploying%20corda%20corda%20testnet%20from%20your%20local%20environment
We understood from the above documentation that we can download only one "Corda node" using one registration. Will we have to join the Corda Testnet using four different accounts in order to download four Corda nodes?
Is our understanding correct?
As per my understanding you can spin up multiple nodes with a refresh of the Testnet node installation page, or by creating a node and then clicking 'next', which should take you back to the node list and present a button to allow creation of another node.
It should provide you with a unique ONE_TIME_DOWNLOAD_KEY each time, and automatically assign you a randomised alphanumeric O (organisation) value to use within the nodes configuration file, helping the network map (and thus other nodes on the network) to distinguish your nodes individually.
Make sure you don't unintentionally run copies of the same node with the same identity, otherwise the network map will just assume there has been a change in the address of the original node and route P2P traffic to the newest instance.
Take a look at the node.conf docs to understand node configuration further:
https://docs.corda.net/corda-configuration-file.html

Openstack CLI does not honour project scope

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.

AWS API Create instance in non default VPC

I am using .NET SDK for AWS and and trying to create a service that can create/mange instances. As part of this I want to create an EC2 instance in a specific VPC (non-default). There may have more then one VPC in a zone and I want to programatically be able to create/manage instances in any of the VPC rather than just the default VPC.
Is this possible? If yes how? I looked through the API docs and could not find a way to specify the VPC at the time of creation of EC2 isntance.
The VPC appears to be implied by the subnet-id that you specify. If this doesn't get you there, it might at least get you an error message explaining what you've missed.
http://docs.aws.amazon.com/sdkfornet/latest/apidocs/items/PEC2Instance_SubnetId_NET4_5.html
http://docs.aws.amazon.com/sdkfornet/latest/apidocs/items/TEC2RunInstancesRequest_NET4_5.html
http://docs.aws.amazon.com/AWSSdkDocsNET/latest/DeveloperGuide/run-instance.html
From the underlying REST API:
SubnetId
[EC2-VPC] The ID of the subnet to launch the instance into.
Type: String
Default: None
Required: No
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-RunInstances.html

Resources