Moving to openstack-dev for more visibility and discussion.
We currently have signal API for heat resources(not for standalone software
config/deployment). However, you can probably use a workaround with swift
temp_url like tripleo[1] to achieve your use case.
We do have rpc api[2] for signalling
Hello Operators,
For reasons not yet amenable to persuasion otherwise, a customer of our
ML2+OVS classic implemented OpenStack would like to map two floating IPs
pulled from two separate external network floating IP pools, to two
different vNICs on his instances.
The floating IP pools corres
Thank you Rami,so, if I got it, looking at the code, the suggested process for a sw deployment in our case is a task series (maybe realized using python-celery) like this:1) Create a swift temp_url for the signaling dedicated to the deployment2) Pass this url, and all the necessary parameters, to
Hello,
while the problem is in place, you should share the output of
ip rule show
ip route show table 1
It could be just a problem in your ruleset
and, which one is your webserver ? can you tcpdump to make sure reply
packets get out on the NIC with src address 10.0.16.11 ?
Saverio
2016-12-01
Hello Saverio,
Many thanks for the reply, I'll answer your queries below;
On 01/12/16 12:49, Saverio Proto wrote:
Hello,
while the problem is in place, you should share the output of
ip rule show
ip route show table 1
It could be just a problem in your ruleset
Of course, these are those ou
Your policy routing looks good.
The problem must be somewhere else, where you do the nat maybe ?
Go in the network namespace where there is the neutron router with
address 10.0.16.1
If you tcpdump there what do you see ?
to be 100% sure about the policy routing just go in the network node
where
Thanks a lot George
It looks like this indeed helps !
Cheers, Massimo
2016-11-30 16:04 GMT+01:00 George Mihaiescu :
> Try changing the following in nova.conf and restart the nova-scheduler:
>
> scheduler_host_subset_size = 10
> scheduler_max_attempts = 10
>
> Cheers,
> George
>
> On Wed, Nov 30
On 01/12/16 14:35, Saverio Proto wrote:
Your policy routing looks good.
The problem must be somewhere else, where you do the nat maybe ?
Go in the network namespace where there is the neutron router with
address 10.0.16.1
If you tcpdump there what do you see ?
to be 100% sure about the policy
On Thu, Dec 1, 2016 at 8:23 AM, Paul Browne wrote:
> On 01/12/16 14:35, Saverio Proto wrote:
>
> Your policy routing looks good.
> The problem must be somewhere else, where you do the nat maybe ?
>
> Go in the network namespace where there is the neutron router with
> address 10.0.16.1
>
> If you
