I noticed there's now duplicate openstack floatingip support, both in
nova_fip and quantum_floatingip+quantum_floatingip_associate.
Is this duplication intentional?
This was the result of a recent OpenStack merge and on the development branch.
I think it’s a question are people using floating IPs without going through Quantum anymore.
I’m a little out of the loop with respect to that, but about a year ago not everyone was using Quantum. Not sure of the current status quo.
This was the result of a recent OpenStack merge and on the development
branch.I think it's a question are people using floating IPs without going
through Quantum anymore.
That question isn't quite relevant I think. Quantum is a fork of
nova-network; and is essentially a rename of the daemon, along with a
relocation of the git-repo. The client API hasn't changed fundametally.
The nova-network client can still create and manage floating IPs with
quantum (and even neutron).
As far as i can see, the only diffrence between nova_fip and
quantum_floatingip* is the set of client library dependencies, and the
presence of quirks in quantum_floatingip. I already addressed those
quirks on my openstack-module fork.
I'm a little out of the loop with respect to that, but about a year
ago not everyone was using Quantum. Not sure of the current status quo.
Keeping track of what OpenStack is doing isn't easy. Especially when
you're just using clients, as most of the chatter pertains to the
services. Is there a maintainer for the openstack modules? If not, is
there a demand for such a position?
" Quantum is a fork of
nova-network; "
At the time when I was involved with Folsom, long time ago I was using both. That was clearly a long time ago.
As for the “maintainer” thing, if someone would like to step up, I would welcome it – it’s always going to be a community thing but if there are folks who can step up to be the first to say “yay” or “nay” or “I want this”, or “I’ll fix this up”, that is SUPER welcome. We will also owe you a statue when we build our formal gardens*
Matt Martz has been doing amazing things for Rackspace Cloud, in particular.
- = as some people know, this takes a while and there are various statues promised already
“I was using both” => “people were still using both”.
So, anyone object to removal of nova_fip ?
To make things even more complicated, "quantum" is going away, in place of "neutron". (Tradmark issues was part of this I believe)
Neutron isn't ready for prime time yet though, so that makes things... complicated.
-jlk
Yep, I’m aware of the quantum going away part.
We have been resisting doing a rename as that would break playbooks, though the thought was to have the module work with both and import what it could do “do the right thing”.
–Michael
The entire nova-network vs quantum vs neutron debate is irrelevant in
this context: we're building a client, and all three services speak
(compatible versions of) the same protocol.
The only thing that's relevant for us, is how to name the modules. If I
could start over, I'd choose for 'openstack_[objectname]', to avoid
openstack's (slightly whimsical) daemon naming habits. For now, I'd
prefer to keep things consistent, e.g. vm-stuff in nova_*, network
stuff in quantum_*, volume stuff in cinder_*.
I'll try to pick up openstack requests, and chime in on openstack
related topics.
Ok, so it sounds like we’ll delete the nova_fip merge.
Speak up if you disagree, anyone.