What are the possible parameters of this value
custom ([ "associateFloatingIpOnBootstrap" : "true" ])
Can i change this value after the bootstrap
Can i associate the floating ip after on recipe
Thanks
The possible values are only true and false, but Cloudify 2.7 supports setting floating IPs from lifecycle events. See here:
http://getcloudify.org/guide/2.7/clouddrivers/network.html
Support for Floating IPs
Cloudify Network Cloud Driver provides API for working with floating
IPs. This means the recipe lifecycle events can use floating IPs
programmatically
Note that this functionality is only available for Openstack based clouds. For other clouds, you may have to implement the network driver functionality yourself.
Related
I am looking for a basic thing yet I have not found not even a single good documentation on getting it done.
I want to allocate a floating IP, then associate it to a network interface of a droplet other than eth0.
The reason is I want to have the ability to very easily switch from one IP to the other with a programming language.
In a few words, I want to be able to do these two commands and both should provide a different response.
curl --interface eth0 https://icanhazip.com
curl --interface eth1 https://icanhazip.com
Also, I want to know what to do once I release the Floating IP, how do I roll back to the starting point.
All documentation I read, rely heavily on "ip route" and "route", most did not even work, some worked but replaced completely the old IP by the floating and that's not what I want, and also they did not show how to rollback the introduced configuration changes.
Please help, I spent 1 whole day now trying to get this to work for a project, and no results so far.
I guess there is no need to know DigitalOcean, how to make this work on other Cloud Providers would apply here too I think.
Update
After asking this on DigitalOcean community forum (https://www.digitalocean.com/community/questions/clear-guide-on-outbound-network-through-floating-ip), they claim that is not supported, although there may be some solutions to this if somebody can provide such a "hacky" solution I would take it too. Thanks
In the cloud (AWS. GCP etc.) ARP is emulated by the virtual network layer, meaning that only IPs assigned to VMs by the cloud platform can be resolved. Most of the L2 failover protocols do break for that reason. Even if ARP worked,the IP allocation process for these IPs (often called “floating IPs”) would not integrate with the virtual network in a standard way, so your OS can't just "grab" the IP using ARP and route the packets to itself.
I have not personally done this on Digital Ocean, but I assume that you can call the cloud's proprietary API to do this functionality if you would like to go this route.
See this link on GCP about floating IPs and their implementation. Hope this is helpful.
Here's an idea that needs to be tested:
Let's say you have Node1(10.1.1.1/24) and Node2(10.1.1.2/24)
Create a loopback interface on both VMs and set the same IP address for both like (10.2.1.1/32)
Start a heartbeat send/receive between them
When NodeA starts it automatically makes an API call to create a route for 10.2.1.1/32 and points to itself with preference 2
When NodeB starts it automatically makes an API call to create a route for 10.2.1.1/32 and points to itself with preference 1
The nodes could monitor each other to withdraw the static routes if the other fails. Ideally you would need a 3rd node to reach quorum and prevent split brain scenarios, but you get the idea right?
I m referring Can corda nodes communicate when run from different networks?
I am looking at 3.3 opensource cordapp example and could see the certificates are generated automatically while deployment with devmode=true.
Can I get information - whether it is configured with network type as business network or compatibility zone ?
Can I get more information on how to configure as a business network? is there any example?
If you use deployNodes to create your nodes, you create a mini-compatibility zone of nodes running in devMode. Unlike a traditional compatibility zone, you need to use the Network Bootstrapper tool to manually add nodes to the network, rather than using the dyanmic joining process available in a compatibility zone with a central network map service.
A business network is a sub-group within a compatibility zone of nodes operating for a specific business purpose. A node can be part of multiple business networks. You can read more about business networks here: https://solutions.corda.net/business-networks/what-is-a-business-network.html.
Is it possible in Openstack to have 2 VMs instantiated on the same host, where:
VM1 is instantiated from the "unpinned" 2-vCPU flavor (hw:cpu_policy not set)
VM2 is instantiated from the "pinned" 2-vCPU flavor (hw:cpu_policy=dedicated)
and be sure that VM2's pinned vCPUs (thus physical CPUs) will not be used by VM1?
When reading the 'CPU topologies' section in the OpenStack docs it says:
Caution: Host aggregates should be used to separate pinned instances
from unpinned instances as the latter will not respect the resourcing
requirements of the former.
so according to above it looks it's not possible. Would like to confirm that.
Cause if you can't mix pinned and unpinned VMs on 1 host it seems to me like a huge limitation, isn't it? Asking in the telecom context where pinning is often a must for some VMs (VNFCs) and for the others not; and sometimes it's desirable to have them on the same host.
At the moment Nova does not support mixed pinned/unpinned on a single VM (at least not out of the box), but it is a feature they are looking at implementing.
You can read about the current suggested implementation here.
Additional reading on work related to this blueprint is available here.
In the pre docker 1.9 days I used to have a vpn provider container which I could use as the network gateway for my other containers by passing the option --net=container:[container-name].
This was very simple but had a major limitation in that the provider container had to exist prior to starting the consumers and it could not be restarted.
The new docker networking stack seems to have dropped this provision in favour of creating networks which does sound better, but I'm struggling to get equivalent behaviour.
Right now I have created an internal network docker network create isolated --internal --subnet=172.32.0.0/16 and brought up 2 containers one of which is attached only to internal network and one which is attached to both the default bridge and the internal network.
Now I need to route all network traffic from the isolated container through the connected one. I've messed around with some iptable rules but tbh this is not my strongest area.
So my questions are simply: Is my approach along the right lines? What rules need to be in place in the two containers to get this working as --net=container?
I create instances with multiple network interfaces. However when I associate an floating ip to the instance as below, floating ip is always get allocated to the first interface of the instance.
api.addToServer(ip, server-id);
How do I get the floating ip assigned to the second or an interface other than the first interface. I could not find a way of specifying a nic when associating an floating ip.
I tried a different approach using Openstack commandline and seems it is working.
neutron floatingip-create ext
neutron floatingip-associate floating_ip-id port-id
However I could not find a way to associate a floating ip to a port also.
Then starting the instance with the port-id.
The floating IP extension for Neutron is not supported as of right now 8/20/14 in jclouds.
Is this feature available in JClouds latest release 1.8.1.
Thanks !