Added monitor-address and monitor-port to openstack_lb_member_v2

[luigizhou]

Added missing argument for monitor_address and monitor_port to the lb_member_v2 resource. (different than lb_members_v2)
Replaced the pools library with the one from octavia loadbalancer instead of neutron.

Doesn't seem to break functionality from my test, but happy to review this more in depth to understand the implication of such change

[flashjmp]

Hi @luigizhou ,
I added these parameters to the lb_members_v2 (which is based on octavia, see here: #1363 )
From my understanding the lb_member_v2 was intentionally kept as a neutron "legacy" version of this?

[luigizhou]

Oh I see, I missed the node in the openstack_lb_members_v2 page, thanks @flashjmp
Any ETA in merging #1363 ?

[flashjmp]

I am pretty much done from my end, but there is obviously a review required and the whole project seems to be a little "stale" at the moment. The key issue is that the testing pipeline (#1366) is currently broken... :-(

[luigizhou]

@flashjmp I've taken some time to look at the lb_members_v2 resource which is based on octavia as you mentioned.
One thing I noticed is that, compared to member_v2, there is now only a need for a single resource to manage all members of a pool, which looks less flexible and also more disruptive in cases you want to migrate from the old member_v2 to the new members_v2 (defining a members_v2 removes all members of a pool)

Don't you think it would make sense to upgrade the member_v2 resource instead to support octavia api?
Or alternatively defining a new resource that retain the same behaviour as member_v2, but uses octavia api underneath? Something like a 'lb_octavia_member_v2' ?

I'm happy to work out another PR for it

[luigizhou]

@ozerovandrei what do you think?

[nikParasyr]

@luigizhou first off, there is a ci job now for octavia so rebasing should trigger the ci.

Some notes:

• the lb_v2 resources are typically made to work for both octavia and deprecated LBaaS. For example look here and here This makes introducing new octavia features quite harder than it should be.
• Given the above your current PR makes the resource only work for octavia and not LBaaS, so i dont believe it will be accepted.
• It should be possible, but a bit harder, to introduce the feature in the resource without breaking the LBaaS compatibility. This is an example of such a PR

[luigizhou]

Hey @nikParasyr , I did some work and this should allow to keep backward compatibility with LBaaS

[luigizhou]

Fixed linting @nikParasyr !

[nikParasyr]

Hello.

Thank you for your MR. It looks good but there are a couple things missing:

• please update docs of the resource found here with the new attributes of the resource
• please update the acceptance tests of the resource found here to test the new attributes as well.

[luigizhou]

@nikParasyr I've updated the docs, but I'm not entirely sure what version exactly Octavia started supporting monitor_port and address.

I've laso updated the acceptance tests, let me know if those looks good 👍

[nikParasyr]

Hey, tests are failing and i have some nit fixes as well.

[luigizhou]

@nikParasyr when you have time can you review again?