On Tuesday, 31 de March de 2015 at 7:14, George Shuklin wrote:
On 03/30/2015 11:18 AM, Kevin Benton wrote:
What does fog do? Is it just a client to the Neutron HTTP API? If so,
it should not have broken like that because the API has remained
pretty stable. If it's a deployment
Assaf, can you provide some context on why this option had to be
deprecated? Isn't the no namespace case a degenerate version of all of
stuff scoped to a namespace, or is it not that simple?
I'm less convinced that deprecating is the right move here if it's just to
make the code easier to manage.
What does fog do? Is it just a client to the Neutron HTTP API? If so, it
should not have broken like that because the API has remained pretty
stable. If it's a deployment tool, then I could see that because the
configuration options to tend to suffer quite a bit of churn as tools used
by the
On 03/30/2015 11:18 AM, Kevin Benton wrote:
What does fog do? Is it just a client to the Neutron HTTP API? If so,
it should not have broken like that because the API has remained
pretty stable. If it's a deployment tool, then I could see that
because the configuration options to tend to
On 03/24/2015 09:21 PM, Assaf Muller wrote:
Note that https://review.openstack.org/#/c/166888/ has been merged.
This means that the option has been deprecated for K and will be
removed in L. Anyone using the non-default value of False will be looking
at errors in his logs.
Well, I have
On 3/23/2015 3:56 AM, Miguel Ángel Ajo wrote:
I see you point Van,
In the other hand, removing it, cleans up lot of conditional code parts
(moving parts at the other side),
and also the non-netns case is not tested by upstream CI, AFAIK, so it
could be broken anytime
and we would not notice
Note that https://review.openstack.org/#/c/166888/ has been merged.
This means that the option has been deprecated for K and will be
removed in L. Anyone using the non-default value of False will be looking
at errors in his logs.
- Original Message -
On 3/23/2015 3:56 AM, Miguel
I think there are valid reasons to not use namespaces:
* Fewer moving parts == less can potentialy fail
* Troubleshooting is easier due to less places to look / need no
familiarity with namespaces tools
* If I remember correctly setting up a namespace can get really slow when
you
Are the setups out there *not* using the use_namespaces option? I'm
curious as
to why, and if it would be difficult to migrate such a setup to use
namespaces.
At my previous employer we did not use namespaces.
This was due to a installation a few years ago on SL6 which did not have name
On Monday, 23 de March de 2015 at 8:20, Van Leeuwen, Robert wrote:
Are the setups out there *not* using the use_namespaces option? I'm
curious as
to why, and if it would be difficult to migrate such a setup to use
namespaces.
At my previous employer we did not use
I see you point Van,
In the other hand, removing it, cleans up lot of conditional code parts (moving
parts at the other side),
and also the non-netns case is not tested by upstream CI, AFAIK, so it could be
broken anytime
and we would not notice it.
Miguel Ángel Ajo
On Monday, 23 de March
On 2015-03-21 02:57, Assaf Muller wrote:
Hello everyone,
The use_namespaces option in the L3 and DHCP Neutron agents controls if you
can create multiple routers and DHCP networks managed by a single L3/DHCP agent,
or if the agent manages only a single resource.
Are the setups out there *not*
12 matches
Mail list logo
