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

> 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 reviews are > raised for

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

> On 18 Mar 2016, at 17:05, Doug Wiegley wrote: >> On Mar 18, 2016, at 8:31 AM, Cory Benfield wrote: >> >> Getting requests to talk over a Unix domain socket is not particularly >> tricky, and there are third-party libraries that hook into requests >> appro

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

>>>> (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 Benfield (CC'd) an

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

> 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 pkgos.make: > >

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

> 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. Right? Would > there b

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

> 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/ > > > Anne Ok, so to begin with I

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

> 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 the Alabaster[0] r

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

> 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 the right answer.

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

> 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 this. In requests

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

> 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 whether using the > POST ver

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

> 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 having to contact downs

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

> 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 had a policy in p

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

> 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 bugs in pip where such accur

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

> On 9 Oct 2015, at 15:18, Jeremy Stanley 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 the two. > > I have yet to

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

> On 9 Oct 2015, at 14:40, William M Edmonds wrote: > > Cory Benfield 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

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

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 to us that th

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

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 b

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

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 fr

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

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

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 compel

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

> 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][nova] New specs on routed networking

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 e

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

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] vm can not transport large file under neutron ml2 + linux bridge + vxlan

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

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

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

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 ye

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

l feedback 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