Re: [openstack-dev] [charms] Re-licensing OpenStack charms under Apache 2.0

2016-06-10 Thread Cory Benfield
> On 8 Jun 2016, at 11:20, James Page wrote: > > The majority of contributors are from Canonical (from whom I have permission > to make this switch) with a further 18 contributors from outside of Canonical > who I will be directly contacting for approval in gerrit as

Re: [openstack-dev] [all] Maintaining httplib2 python library

2016-03-19 Thread Cory Benfield
> On 18 Mar 2016, at 17:05, Doug Wiegley <doug...@parksidesoftware.com> wrote: >> On Mar 18, 2016, at 8:31 AM, Cory Benfield <c...@lukasa.co.uk> wrote: >> >> Getting requests to talk over a Unix domain socket is not particularly >> tricky, and th

Re: [openstack-dev] [all] Maintaining httplib2 python library

2016-03-19 Thread Cory Benfield
from usage in Glance IIRC >>>> (and dealing with chunked encoding). >>>> >>>> Neutron seems to use it for a couple of proxies, but that seems like >>>> requests/urllib3 might be sufficient. >>> >>> The Neutron team should talk to Cory

Re: [openstack-dev] Documentation containing external resource links & privacy breaches

2015-12-07 Thread Cory Benfield
> On 7 Dec 2015, at 16:10, Thomas Goirand wrote: > > Cory, > > Thanks a lot for this patch. > > If I understand well, in Debian, I'd have to remove the: > > [options] > analytics_tracking_code = UA-17511903-1 > > from the default theme.conf to make the GA code go away.

Re: [openstack-dev] Documentation containing external resource links & privacy breaches

2015-12-07 Thread Cory Benfield
> On 7 Dec 2015, at 18:37, Thomas Goirand wrote: > > > The reason why I'd like an env var, is that I could simply modify > openstack-pkg-tools (which is included in every debian/rules) to set > that variable once and for all. For example, just adding in > openstack-pkt-tools's

Re: [openstack-dev] Documentation containing external resource links & privacy breaches

2015-12-04 Thread Cory Benfield
> On 4 Dec 2015, at 10:06, Thomas Goirand wrote: > > That's actually a very good idea, I didn't think it was possible. Could > you explain a bit more how this kind of patch would look like? Sure. Rather than explain and take the credit, I’ll point you directly at the code in

Re: [openstack-dev] Documentation containing external resource links & privacy breaches

2015-12-04 Thread Cory Benfield
> On 4 Dec 2015, at 13:20, Anne Gentle wrote: > > Great, thanks! This would work well for both oslosphinx and > openstackdocstheme: > > http://git.openstack.org/cgit/openstack/openstackdocstheme/ > >

Re: [openstack-dev] Documentation containing external resource links & privacy breaches

2015-12-03 Thread Cory Benfield
> On 3 Dec 2015, at 13:37, Thomas Goirand wrote: > I've filed a bug against our docs theme, but it was marked as wontfix, > and the patch which I started, was reviewed negatively. I've been told > that we use Google Analytics for the openstack.org site, which I don't > think is

Re: [openstack-dev] [All] Use of self signed certs in endpoints

2015-11-17 Thread Cory Benfield
> On 16 Nov 2015, at 11:54, Sean Dague wrote: > That sounds pretty reasonable to me. I definitely support the idea that > we should be using system CA by default, even if that means overriding > requests in our tools. Setting REQUESTS_CA_BUNDLE is absolutely the way to go about

Re: [openstack-dev] [api][nova] Handling lots of GET query string parameters?

2015-11-04 Thread Cory Benfield
> On 4 Nov 2015, at 13:13, Salvatore Orlando wrote: > > Regarding Jay's proposal, this would be tantamount to defining an API action > for retrieving instances, something currently being discussed here [1]. > The only comment I have is that I am not entirely surely

Re: [openstack-dev] Requests + urllib3 + distro packages

2015-10-15 Thread Cory Benfield
> On 14 Oct 2015, at 23:23, Thomas Goirand wrote: > I do understand that you don't like being called this way, though this > is still the reality. Vendorizing still inflicting some major pain to a > lot of your users: > - This thread one of the demonstration of it. > - You

Re: [openstack-dev] Requests + urllib3 + distro packages

2015-10-13 Thread Cory Benfield
> On 13 Oct 2015, at 07:42, Thomas Goirand wrote: > In this particular case (ie: a difficult upstream which makes it > impossible to have the same result with pip and system packages) I don’t know how carefully you’ve followed this email trail, but the “difficult upstream” has

Re: [openstack-dev] Requests + urllib3 + distro packages

2015-10-12 Thread Cory Benfield
> On 12 Oct 2015, at 01:16, Robert Collins wrote: > To sum up the thread, it sounds to me like a viable way-forward is: > > - get distros to fixup their requests Python dependencies (and > hopefully they can update that in stable releases). > - fix the existing known

Re: [openstack-dev] Requests + urllib3 + distro packages

2015-10-09 Thread Cory Benfield
Robert Collins writes: > The problem that occurs is the result of a few interacting things: > - requests has very very specific versions of urllib3 it works with. > So specific they aren't always released yet. This should no longer be true. Our downstream redistributors pointed out

Re: [openstack-dev] Requests + urllib3 + distro packages

2015-10-09 Thread Cory Benfield
> On 9 Oct 2015, at 14:40, William M Edmonds <edmon...@us.ibm.com> wrote: > > Cory Benfield <cory@...> writes: > > > The problem that occurs is the result of a few interacting things: > > > - requests has very very specific versions of urllib3 it works wit

Re: [openstack-dev] Requests + urllib3 + distro packages

2015-10-09 Thread Cory Benfield
> On 9 Oct 2015, at 15:18, Jeremy Stanley <fu...@yuggoth.org> wrote: > > On 2015-10-09 14:58:36 +0100 (+0100), Cory Benfield wrote: > [...] >> IMO, what OpenStack needs is a decision about where it’s getting >> its packages from, and then to refuse to mix th

Re: [openstack-dev] [neutron] Generic question about synchronizing neutron agent on compute node with DB

2015-03-16 Thread Cory Benfield
On Sun, Mar 15, 2015 at 22:37:59, Sławek Kapłoński wrote: Maybe good idea for the beginning could be to implement some periodic task called from agent to check db config and compare it with real state on host? What do You think? Or maybe I'm competly wrong with such idea and it should be

Re: [openstack-dev] [neutron] high dhcp lease times in neutron deployments considered harmful (or not???)

2015-02-04 Thread Cory Benfield
On Wed, Feb 04, 2015 at 08:59:54, Kevin Benton wrote: I proposed an alternative to adjusting the lease time early on the in the thread. By specifying the renewal time (DHCP option 58), we can have the benefits of a long lease time (resiliency to long DHCP server outages) while having a

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

2014-12-12 Thread Cory Benfield
On Thu, Dec 11, 2014 at 23:05:01, Mathieu Gagné wrote: When no security group is provided, Nova will default to the default security group. However due to the fact 2 security groups had the same name, nova-compute got confused, put the instance in ERROR state and logged this traceback [1]:

Re: [openstack-dev] [neutron][nova] New specs on routed networking

2014-10-30 Thread Cory Benfield
On Tue, Oct 28, 2014 at 21:50:09, Carl Baldwin wrote: Many API users won't care about the L2 details. This could be a compelling alternative for them. However, some do. The L2 details seem to matter an awful lot to many NFV use cases. It might be that this alternative is just not

Re: [openstack-dev] [neutron][nova] New specs on routed networking

2014-10-29 Thread Cory Benfield
On Tue, Oct 28, 2014 at 20:01:40, Kevin Benton wrote: I think the simplest use case is just that a provider doesn't want to deal with extending L2 domains all over their datacenter. This is the core motivation. As mentioned in Fred Baker's internet draft[0], extending layer 2 domains can be

Re: [openstack-dev] [neutron][nova] New specs on routed networking

2014-10-29 Thread Cory Benfield
Some of us are looking at a different model. I’d be interested in your thoughts. Fred, Thanks for the link to the drafts. They look extremely similar to the approach we've been pursuing for Project Calico, and it's good to see that we're not the only people thinking in this direction. It

Re: [openstack-dev] [neutron] vm can not transport large file under neutron ml2 + linux bridge + vxlan

2014-10-28 Thread Cory Benfield
On Tue, Oct 28, 2014 at 08:32:11, Li Tianqing wrote: One more question. Vxlan use udp, how can vxlan promise reliability. It can't, but that doesn't matter. VXLAN emulates a single layer 2 broadcast domain: conceptually, a series of machines all plugged into the same Ethernet switch. This

Re: [openstack-dev] [neutron][nova] New specs on routed networking

2014-10-28 Thread Cory Benfield
On Tue, Oct 28, 2014 at 07:44:48, A, Keshava wrote: Hi, Current Open-stack was built as flat network. With the introduction of the L3 lookup (by inserting the routing table in forwarding path) and separate 'VIF Route Type' interface: At what point of time in the packet processing

Re: [openstack-dev] [neutron][nova] New specs on routed networking

2014-10-27 Thread Cory Benfield
On Fri, Oct 24, 2014 at 20:51:36, Kevin Benton wrote: Hi, Thanks for posting this. I am interested in this use case as well. I didn't find a link to a review for the ML2 driver. Do you have any more details for that available? Sure. The ML2 driver itself isn't submitted for review yet

Re: [openstack-dev] [neutron][nova] New specs on routed networking

2014-10-27 Thread Cory Benfield
On Sun, Oct 26, 2014 at 19:05:43, Rohit Agarwalla (roagarwa) wrote: Hi I'm interested as well in this model. Curious to understand the routing filters and their implementation that will enable isolation between tenant networks. Also, having a BoF session on Virtual Networking using L3 may

[openstack-dev] [neutron][nova] New specs on routed networking

2014-10-24 Thread Cory Benfield
on these proposals from the community. We'll be around at the Paris summit in a couple of weeks and would love to discuss with anyone else who is interested in this direction. Regards, Cory Benfield (on behalf of the entire Project Calico team) [1] http://www.projectcalico.org [2] https