ipset_enabled = True default is not upgrade friendly

Fix proposed to branch: master
Review: https://review.openstack.org/121434

I disagree. I believe wider early testing on this feature will help making sure it works as expected.
Iptables-only-based security groups don't scale well.

I'd like to see a patch for TripleO-CI to install ipset, as it only takes to install a package.

I second Miguel's opinion. It's the job of the distros to tweak the Juno packages to have ipset as a new dependency

FWIW I pushed this TripleO patch to install ipset in parallel:

https://review.openstack.org/#/c/121435/

I still disagree that this should be enabled by default for the reasons I previously mentioned. If this broke us in TripleO it'll likely cause someone else pain too. You could easily increase the testing footprint via other means... without just automatically enabling it like this.

A few points:

1) Dropping a new dependency on distros at the very end of the cycle like this is rather unfriendly.
2) Why is this even configurable? Why not just use ipset if it's there, and don't if it's not?
3) This change is going to cause grief to every CD user out there who is installing from source, and thus can't depend on a distro to just make the dependencies magically work. This is the situation we hit in TripleO. IMHO there should have been a deprecation period before a breaking change like this was made, so there was at least a _chance_ of it not being an unpleasant surprise.

I note that timing concerns were raised on the original review, and I disagree with the idea that there is going to be any "wider early testing" of this right now. There's nothing "early" about Juno at this point. It's late enough in the cycle that the chances of finding and fixing anything but blatantly obvious bugs with this new feature before release are slim to none.

Change abandoned by Dan Prince (<email address hidden>) on branch: master
Review: https://review.openstack.org/121434

I agree with all these points, but similar decisions were made in the past, so I am not sure why this one should be treated any differently.

For instance, at the end of the Icehouse cycle, Neutron got a new dependency on novaclient and yet we enabled notification by default. This led to a similar unfriendly upgrade path the reason where Neutron needed novaclient installed when previously it didn't.

As far this is concerned, I think this issue raised enough awareness that we can fix the actual problem where it belongs, like TripleO, package specs, puppet/chef cookbooks, rather than churning more changes than are strictly required. Even deploying from source does not prevent you from incurring from issues like these from time to time. Another example is DVR: that requires L3 and Firewall agents to run on the compute boxes now. This may lead to new dependencies that need to be solved. We chose to keep DVR disabled by default, and that clearly gives more time to people to catch up, but that's not why we did it.

Status changed to 'Confirmed' because the bug affects multiple users.

Last update into Ubuntu devel added the new dependency and installed the rootwrap.d rules; this was a late change, but we can deal with it - it would be nice if there was a good way to identify new external dependencies such as this earlier in cycle, so potential impact points can be identified and dealt with earlier by distro's etc...