Re: [openstack-dev] [neutron] Clear all flows when ovs agent start? why and how avoid?
I find our current design is remove all flows then add flow by entry, this will cause every network node will break off all tunnels between other network node and all compute node. Perhaps a way around this would be to add a flag on agent startup which would have it skip reprogramming flows. This could be used for the upgrade case. I hit the same issue last week and filed a bug here: https://bugs.launchpad.net/neutron/+bug/1383674 From an operators perspective this is VERY annoying since you also cannot push any config changes that requires/triggers a restart of the agent. e.g. something simple like changing a log setting becomes a hassle. I would prefer the default behaviour to be to not clear the flows or at the least an config option to disable it. Cheers, Robert van Leeuwen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements
I,d like to start a conversation on usage requirements and have a few suggestions. I advocate that, since we will be using TCP and HTTP/HTTPS based protocols, we inherently enable connection logging for load balancers for several reasons: Just request from the operator side of things: Please think about the scalability when storing all logs. e.g. we are currently logging http requests to one load balanced application (that would be a fit for LBAAS) It is about 500 requests per second, which adds up to 40GB per day (in elasticsearch.) Please make sure whatever solution is chosen it can cope with machines doing 1000s of requests per second... Cheers, Robert van Leeuwen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Quota management and enforcement across projects
I recall that in the past there have been several calls for unifying quota management. The blueprint [1] for instance, hints at the possibility of storing quotas in keystone. As an end-user: +1 For me it totally makes sense to put the quotas and access together. On the other hand, the blazar project [2, 3] seems to aim at solving this problem for good enabling resource reservation and therefore potentially freeing openstack projects from managing and enforcing quotas. While Blazar is definetely a good thing to have, I'm not entirely sure we want to make it a required component for every deployment. Totally agree, I'd rather not run more components running then strictly necessary. It is already quite a lot of work to test all components each time we do upgrade's. Adding complexity / more moving parts is not on the top of my list unless strictly necessary. Cheers, Robert van Leeuwen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
