[openstack-dev] [Neutron] Stepping down from core

Neutron (and Openstack), It is with regret that I report that my work situation has changed such that I'm not able to keep up with my duties as a Neutron core reviewer, L3 lieutenant, and drivers team member. My participation has dropped off considerably since Newton was released and I think it

[openstack-dev] [neutron] Ocata End user and operator feedback recap

routers which are backed by hardware resources. There is no such thing yet but Neutron does have a new concept in development called "L3 flavors". This would enable a driver (to be written) which would allow this sort of thing. Carl Baldwin [1] https://etherpad.openstack.org/p/ocata-neutro

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

+2 Carl On Fri, Oct 14, 2016 at 12:30 PM, Miguel Lavalle wrote: > Dear Neutrinos, > > I am organizing a social event for the team on Thursday 27th at 19:30. > After doing some Google research, I am proposing Raco de la Vila, which is > located in Poblenou:

Re: [openstack-dev] Multinode testing with devstack and neutron broken

I found this [1] added here [2]. Since the provider is using 10.0.0.0/8 on the public interface, and the subnet pool is also 10.0.0.0/8 the call to ip route replace eliminates the route through the public interface. Carl [1] https://github.com/openstack-dev/devstack/blob/

Re: [openstack-dev] [Neutron] Adding ihrachys to the neutron-drivers team

Welcome, Ihar! It will be great to have you on the drivers team. Carl On Sat, Sep 17, 2016 at 10:40 AM, Armando M. wrote: > Hi folks, > > I would like to propose Ihar to become a member of the Neutron drivers > team [1]. > > Ihar wide knowledge of the Neutron codebase, and

Re: [openstack-dev] [neutron][dvr][fip] fg device allocated private ip address

On Tue, Aug 16, 2016 at 6:17 PM, huangdenghui wrote: > Hi Carl > Thanks for reply. I was wondering how this works? fg device has one > private ip address, and the interface on upstream router has two ip > address, one is private ip address, and the other one is public ip

Re: [openstack-dev] [Neutron] Team and Driver meetings for the week of Aug 15th

The Neutron L3 meeting will be canceled. We will still hold the routed networks meeting on Tuesday. Carl On Thu, Aug 11, 2016 at 12:19 PM, Henry Gessau wrote: > Armando M. wrote: > > Hi Neutrinos, > > > > The meetings will be cancelled due to the

Re: [openstack-dev] 答复: [neutron][dvr][fip] fg device allocated private ip address

On Wed, Aug 3, 2016 at 1:22 AM, zhuna wrote: > Hi Carl, > > > > IMO, if the upstream router has the route to floating ip subnet, no need > to assign additional IP address to the router. > > > > For example, there are 2 subnets in external network, > > Subnet1: 10.0.0.0/24

Re: [openstack-dev] [Neutron][IPAM] Pluggable IPAM rollback issue

On Tue, Aug 2, 2016 at 6:55 PM, Carl Baldwin <c...@ecbaldwin.net> wrote: > On Aug 2, 2016 6:52 PM, "Kevin Benton" <ke...@benton.pub> wrote: > > If we decide to just fix the exception handler inside of ipam itself for > rollbacks (which would be a quick fix)

Re: [openstack-dev] [Neutron][IPAM] Pluggable IPAM rollback issue

bugs. Carl > On Tue, Aug 2, 2016 at 3:27 PM, Carl Baldwin <c...@ecbaldwin.net> wrote: >> >> On Tue, Aug 2, 2016 at 2:50 AM, Kevin Benton <ke...@benton.pub> wrote: >>> >>> >Given that it shares the session, it wouldn't have to do anything. But, again

Re: [openstack-dev] [neutron][dvr][fip] fg device allocated private ip address

On Tue, Aug 2, 2016 at 6:15 AM, huangdenghui wrote: > hi john and brain >thanks for your information, if we get patch[1],patch[2] merged,then fg > can allocate private ip address. after that, we need consider floating ip > dataplane, in current dvr implementation, fg is

Re: [openstack-dev] [Neutron][IPAM] Pluggable IPAM rollback issue

iew.openstack.org/#/c/348956/1/neutron/tests/unit/extensions/test_segment.py@793 1. > https://github.com/openstack/neutron/blob/master/neutron/db/ipam_pluggable_backend.py > > On Aug 1, 2016 18:11, "Carl Baldwin" <c...@ecbaldwin.net> wrote: > >> >> >>

Re: [openstack-dev] [Neutron][IPAM] Pluggable IPAM rollback issue

On Mon, Aug 1, 2016 at 2:29 PM, Kevin Benton wrote: > >We still want the exception to rollback the entire API operation and > stopping it with a nested operation I think would mess that up. > > Well I think you would want to start a nested transaction, capture the > duplicate,

[openstack-dev] [Neutron][IPAM] Pluggable IPAM rollback issue

Hi all, Last Thursday, I spent the afternoon looking in to a bug with pluggable IPAM [1] which is preventing me from deciding to pull the trigger on finally switching from the old non-pluggable reference implementation. I'd *really* like to get this in shape for Newton but time is running out.

Re: [openstack-dev] [Neutron][oslo.db] Inspecting sqlite db during unit tests

On Fri, Jul 22, 2016 at 8:47 AM, Mike Bayer wrote: > > > On 07/22/2016 04:02 AM, Kevin Benton wrote: > >> Now that we have switched to oslo.db for test provisioning the >> responsibility of choosing a location lands >> here: >>

Re: [openstack-dev] [Neutron][oslo.db] Inspecting sqlite db during unit tests

On Fri, Jul 22, 2016 at 8:45 AM, Mike Bayer wrote: > > On 07/22/2016 04:02 AM, Kevin Benton wrote: > >> Now that we have switched to oslo.db for test provisioning the >> responsibility of choosing a location lands >> here: >>

Re: [openstack-dev] [Neutron] Proposing Jakub Libosvar for testing core

+1 from me On Thu, Jul 21, 2016 at 1:35 PM, Assaf Muller wrote: > As Neutron's so called testing lieutenant I would like to propose > Jakub Libosvar to be a core in the testing area. > > Jakub has demonstrated his inherent interest in the testing area over > the last few

Re: [openstack-dev] [neutron][stable] status update and call for action

I appreciate how you're trying to steer this big ship in a new direction to improve support for our releases. I know it must be frustrating when it doesn't turn as quickly as it should. On Thu, Jun 30, 2016 at 8:56 AM, Ihar Hrachyshka wrote: > > For the start, I produced a

[openstack-dev] [Neutron][oslo.db] Inspecting sqlite db during unit tests

Hi, In Neutron, we run unit tests with an in-memory sqlite instance. It is impossible, as far as I know, to inspect this database using the sqlite3 command line while the unit tests are running. So, we have to resort to python / sqlalchemy to do it. This is inconvenient. Months ago, I was able

Re: [openstack-dev] [oslo.db] [CC neutron] CIDR overlap functionality and constraints

a little bit better in some cases but what I found was that this table made IP allocation very contentious. During the Newton cycle, we've eliminated the need for this table by computing availability on the fly and we avoid contention by randomly selecting from a window of the next available addres

Re: [openstack-dev] [Nova][Neutron][Live-Migration] Cross l2 agent migration and solving Nova-Neutron live migration bugs

On Fri, Jul 1, 2016 at 8:34 AM, Murray, Paul (HP Cloud) <pmur...@hpe.com> wrote: >> -Original Message----- >> From: Carl Baldwin [mailto:c...@ecbaldwin.net] >> Sent: 29 June 2016 22:20 >> To: OpenStack Development Mailing List (not for usage questions) >>

Re: [openstack-dev] [neutron][calico] New networking-calico IRC meeting

Sorry I missed it. I will plan to listen in on the 12th. It will be nice to have the ICS available by then. You should probably check with the @openstack-infra channel to see what the issue is. Carl On Fri, Jul 1, 2016 at 5:31 AM, Neil Jerram wrote: > The first

Re: [openstack-dev] [neutron][calico] New networking-calico IRC meeting

On Mon, Jun 20, 2016 at 8:42 AM, Neil Jerram wrote: > Calling everyone interested in networking-calico ...! networking-calico has > been around in the Neutron stadium for a while now, and it's way past time > that we had a proper forum for discussing and evolving it - so I'm

Re: [openstack-dev] [Nova][Neutron][Live-Migration] Cross l2 agent migration and solving Nova-Neutron live migration bugs

On Tue, Jun 28, 2016 at 9:42 AM, Andreas Scheuring wrote: > I'm currently working on solving Nova-Neutron issues during Live > Migration. This mail is intended to raise awareness cross project and > get things kicked off. Thanks for sending this. > The issues >

Re: [openstack-dev] [Neutron] Elevating context to remove subnets created by admin

On Tue, Jun 21, 2016 at 12:47 AM, Armando M. wrote: > It seems it may potentially limit the ability to describe ownership. > Virtually all Neutron models have it. Not sure I see the value in its > absence. I'm just saying that I don't see value in its presence. The value that

Re: [openstack-dev] [Neutron] Elevating context to remove subnets created by admin

that subnet should also not have a tenant_id and should just inherit it from the network. Carl [1] https://review.openstack.org/#/c/331497/2/neutron/db/segments_db.py On Fri, Jun 3, 2016 at 3:05 PM, Henry Gessau <hen...@gessau.net> wrote: > Carl Baldwin <c...@ecbaldwin.net> wrote: &

[openstack-dev] [Neutron][IPAM] Anyone using builtin pluggable IPAM driver?

Hi, Cross posting to the operators and devs. In Liberty, pluggable IPAM was added to Neutron. With it, a built-in pluggable driver, equivalent to the old non-pluggable IPAM was added as a reference implementation. In a greenfield deployment, you could choose to use this driver by setting the

Re: [openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

I know I've been pretty quiet since I started this thread. Y'all have been doing so well, I've just been reading the thread every day and enjoying it. I thought I'd top post here to kind of summarize. I see wisdom in the strategy suggested by Sean Mooney to make a very minimal change to os-vif

Re: [openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

Here's a link directly to the current design proposal [1] that might be of interest. [1] https://review.openstack.org/#/c/318317/4/doc/source/devref/openvswitch_agent.rst@463 On Thu, Jun 9, 2016 at 5:31 PM, Carl Baldwin <c...@ecbaldwin.net> wrote: > Hi, > > You may or m

Re: [openstack-dev] [Neutron] Random IP address allocations

On Fri, Jun 10, 2016 at 2:40 AM, Gary Kotton wrote: > Hi, > The patch https://review.openstack.org/#/c/292207/ has broken decomposed > plugins. I am not sure if we can classify this as a API change – basically Can you be more specific about how it "has broken decomposed

[openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

to start rounding up the reviewers and other participants we need to see how we can start putting together a plan for nova integration of this feature (via os-vif?). Carl Baldwin [1] https://review.openstack.org/#/q/topic:bp/vlan-aware-vms+-status:abandoned

Re: [openstack-dev] [neutron][upgrades] Bi-weekly upgrades work status. 6/2/2016

On Thu, Jun 2, 2016 at 2:29 PM, Korzeniewski, Artur wrote: > I would like to remind that agreed approach at Design Summit in Austin was, > that every new resource added to neutron should have OVO implemented. Please > comply, and core reviewers please take care of

Re: [openstack-dev] [Neutron] Question about service subnets spec

Thanks, John for your comments. I've added a few comments inline. In summary, I'm inclined to move forward with this as an admin-only operation to begin with. I'll give another day or two for someone new to take notice. Carl On Tue, Jun 7, 2016 at 7:56 AM, John Davidge

Re: [openstack-dev] [Neutron] Elevating context to remove subnets created by admin

On Fri, Jun 3, 2016 at 2:26 PM, Henry Gessau wrote: > Darek Smigiel wrote: >> strange, that owner is not able to just get rid of *his* network and subnets. > > But not all the subnets are his, and consequently the network is partially not > his. To

Re: [openstack-dev] [Neutron] Elevating context to remove subnets created by admin

On Fri, Jun 3, 2016 at 11:16 AM, Darek Smigiel wrote: > Hello, > Doing reviews I noticed, that Liu Yong submitted a bug [1] where we have a > problem with removing subnets. This makes me wonder what the use case that gets in to this situation. > In short: if tenant

Re: [openstack-dev] [neutron][dvr] Wasting so many external network IPs in DVR mode?

On Thu, Jun 2, 2016 at 12:04 AM, zhi wrote: > The reason putting the routers namespaces behind the fip namespace is > saving mac address tables in switches. In Centralized Virtual Router, there > are many "qg" interfaces in the external bridge. Every "qg" interface

Re: [openstack-dev] [neutron][dvr] Wasting so many external network IPs in DVR mode?

On Wed, Jun 1, 2016 at 9:48 AM, zhi wrote: > hi, all > > I have some questions about north/south traffic in DVR mode. > > As we all know, packets will be sent to instance's default gateway (qr > interface) when an instance want to communicate to the external

[openstack-dev] [Neutron] Question about service subnets spec

Hi folks, Some (but not all) of you will remember a discussion we had about service subnets at the last mid-cycle. We've been iterating a little bit on a spec [1] and we have just one issue that we'd like to get a little bit more feedback on. As a summary: To me, the idea of this spec is to

Re: [openstack-dev] [neutron] DHCP Agent Scheduling for Segments

t is a subset of an AZ. So why are we not able to leverage > that logic or make it more generic? > Thanks > Gary > > On 5/22/16, 4:02 AM, "Carl Baldwin" <c...@ecbaldwin.net> wrote: > > >On Fri, May 20, 2016 at 1:44 PM, Brandon Logan > ><brandon.l

Re: [openstack-dev] [neutron] DHCP Agent Scheduling for Segments

On Fri, May 20, 2016 at 1:44 PM, Brandon Logan <brandon.lo...@rackspace.com> wrote: > On Thu, 2016-05-19 at 14:16 -0600, Carl Baldwin wrote: >> On Wed, May 18, 2016 at 1:36 PM, Kevin Benton <ke...@benton.pub> wrote: >> >>I may have wrongly assumed that segments

Re: [openstack-dev] [neutron] Update_port can not remove allocation from auto-addressed subnets

On Fri, May 20, 2016 at 6:06 AM, Pavel Bondar wrote: > Hi, > > Currently using update_port workflow user can not remove ip addresses from > auto-addressed subnets (SLAAC). It prevents me from implementing complete > fix for [1]. > > Typically for removing ip address from

Re: [openstack-dev] [release] Re: [Neutron][L2GW] Mitaka release of L2 Gateway now available

On Thu, May 19, 2016 at 7:09 AM, Doug Hellmann wrote: > We have the same issue with version numbers regressing no matter when we > cut the next release, so it's up to the team. It might be easier to deal > with now while it's fresh in our minds. > > I would like to update

Re: [openstack-dev] [neutron] DHCP Agent Scheduling for Segments

On Wed, May 18, 2016 at 1:36 PM, Kevin Benton wrote: >>I may have wrongly assumed that segments MAY have the possibility of being >> l2 adjacent, even if the entire network they are in is not, which would mean >> that viewing and scheduling these in the context of a segment

Re: [openstack-dev] [Neutron][ML2][Routed Networks]

On Wed, May 18, 2016 at 5:24 AM, Hong Hui Xiao wrote: > I update [1] to auto delete dhcp port if there is no other ports. But > after the dhcp port is deleted, the dhcp service is not usable. I can I think this is what I expect. > resume the dhcp service by adding another

Re: [openstack-dev] [Neutron][ML2][Routed Networks]

On May 17, 2016 2:18 PM, "Kevin Benton" wrote: > > >I kind of think it makes sense to require evacuating a segment of its ports before deleting it. > > Ah, I left out an important assumption I was making. We also need to auto delete the DHCP port as the segment is deleted. I was

Re: [openstack-dev] [Neutron][ML2][Routed Networks]

On Tue, May 17, 2016 at 10:56 AM, Kevin Benton wrote: >>a) Deleting network's last segment will be prevented. Every network should >> have at least one segment to let the port to bind. > > This seems a bit arbitrary to me. If a segment is limited to a small part of > the

Re: [openstack-dev] [release] Re: [Neutron][L2GW] Mitaka release of L2 Gateway now available

tl;dr Merge changes to process documentation before expecting them to be followed! :) On Tue, May 17, 2016 at 4:25 AM, Ihar Hrachyshka wrote: > 2016.1.0 tag is in the repo, and is part of stable/mitaka branch. > > Git tag history suggests that Carl pushed it (manually I

[openstack-dev] [Neutron][ML2][Routed Networks]

about? Carl Baldwin [1] https://review.openstack.org/#/c/296603/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http

Re: [openstack-dev] [Neutron] Stale documentation on docs.o.o

Thank you. Carl On Wed, May 11, 2016 at 11:44 AM, Andreas Jaeger <a...@suse.com> wrote: > On 05/11/2016 07:15 PM, Carl Baldwin wrote: >> Greetings all, >> >> This document [1] was superseded by this one [2] a while ago. It >> looks like the source for [1] no

[openstack-dev] [Neutron] Stale documentation on docs.o.o

something to the docs generation to clean up stale pages? Carl Baldwin [1] http://docs.openstack.org/developer/neutron/devref/sub_project_guidelines.html [2] http://docs.openstack.org/developer/neutron/stadium/sub_project_guidelines.html

Re: [openstack-dev] [nova][newton] Austin summit nova/newton cross-project session recap

On Sun, May 1, 2016 at 7:01 PM, Matt Riedemann <mrie...@linux.vnet.ibm.com> wrote: > On Wednesday morning the Nova and Neutron teams got together for a design > summit session. The full etherpad is here [1]. > > We talked through three major items. > > 1. Neutron routed ne

[openstack-dev] [Neutron] User feedback track: end user and operator pain points - report

release [5] with this fix [6] is in the works. - Consume service plugins queues in RPC workers was merged [8]. If there is something that I missed, please let me know. Carl Baldwin [1] https://www.openstack.org/summit/austin-2016/summit-schedule/events/9103 [2] https://bugs.launchpad.net/neutron

Re: [openstack-dev] [neutron] Social at the summit

+1 On Apr 25, 2016 10:57 AM, "Kyle Mestery" wrote: > Ihar, Henry and I were talking and we thought Thursday night makes sense > for a Neutron social in Austin. If others agree, reply on this thread and > we'll find a place. > > Thanks! > Kyle > >

[openstack-dev] [Neutron] Operator Pain Points

the URL I am looking forward to a well organized and productive discussion at the summit and I'm eager to see you all there. Carl Baldwin [1] https://www.openstack.org/summit/austin-2016/summit-schedule/events/9103 [2] http://docs.openstack.org/developer/neutron/policies/bugs.html#proposing-new

Re: [openstack-dev] [Neutron] Proposing Hirofumi Ichihara to Neutron Core Reviewer Team

+1 (whether my vote counts or note for this area) On Thu, Apr 7, 2016 at 10:34 PM, Akihiro Motoki wrote: > Hi Neutrinos, > > As the API Lieutenant of Neutron team, > I would like to propose Hirofumi Ichihara (irc: hichihara) as a member of > Neutron core reviewer team mainly

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

I think the only thing standing in our way is this bug [1]. Ryan Tidwell and I are working on this. Carl [1] https://bugs.launchpad.net/neutron/+bug/1543094 On Mon, Apr 4, 2016 at 3:48 PM, John Belamaric wrote: > I was on vacation last week so I am just seeing this

Re: [openstack-dev] [neutron] -2'ing all patches on every gate breakage

On Mon, Apr 4, 2016 at 3:22 PM, Doug Wiegley wrote: > I don’t know, -1 really means, “there is something wrong, the submitter > should fix it and clear the slate.” Whereas -2 has two meanings. The first > is “procedural block”, and the second is “f*** you.” > > I

Re: [openstack-dev] [Neutron] Adding amuller to the neutron-drivers team

Welcome, Assaf! On Thu, Mar 31, 2016 at 6:48 PM, Armando M. wrote: > Hi folks, > > Assaf's tenacity is a great asset for the Neutron team at large. I believe > that the drivers team would benefit from that tenacity, and therefore I > would like to announce him to be a new

Re: [openstack-dev] [neutron]: Neutron naming legal issues

On Fri, Apr 1, 2016 at 2:24 AM, Ihar Hrachyshka wrote: > We could play words, like Quantron or Neutrum. Actually, it makes perfect > sense to me, since the change to rename all project name references will be > half the size of the proposed solution, and may even save us some

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On Wed, Mar 30, 2016 at 9:03 AM, Pavel Bondar wrote: > Kevin Benton commented on review page for current migration to pluggable > approach [1]: > > IMO this cannot be optional. It's going to be a nightmare to try to support > two IPAM systems that people may have switched

Re: [openstack-dev] [Neutron]Relationship between physical networks and segment

On Tue, Mar 29, 2016 at 1:38 PM, Miguel Lavalle wrote: > I am writing a patchset to build a mapping between hosts and network > segments. The goal of this mapping is to be able to say whether a host has > access to a given network segment. I am building this mapping assuming

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

On Tue, Mar 29, 2016 at 12:12 PM, Carl Baldwin <c...@ecbaldwin.net> wrote: > I've been playing with this a bit on this patch set [1]. I haven't > gotten very far yet but it has me thinking. > > Calico has a similar use case in mind as I do. Essentially, we both > want to g

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

alternatives? Are there other compelling use cases that I haven't considered yet? Carl [1] https://review.openstack.org/#/c/288774 On Fri, Mar 11, 2016 at 4:15 PM, Carl Baldwin <c...@ecbaldwin.net> wrote: > Hi, > > I have started to get into coding [1] for the Neutron

Re: [openstack-dev] [neutron][dvr]Why keep SNAT centralized and DNAT distributed?

On Mon, Mar 28, 2016 at 7:25 PM, Wang, Yalei wrote: > Someone is working on full distributed SNAT, like this: > > https://www.openstack.org/summit/tokyo-2015/videos/presentation/network-node-is-not-needed-anymore-completed-distributed-virtual-router > > From: Zhi Chang

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

On Mon, Mar 21, 2016 at 12:52 PM, John Belamaric wrote: > Sorry for the slow reply. And, sorry for mine. I was distracted with dotting I's and crossing T's on some other things. I'm now back to playing around with this. > I think that both of these can be solved with

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

On Fri, Mar 11, 2016 at 10:04 PM, Salvatore Orlando <salv.orla...@gmail.com> wrote: > On 11 March 2016 at 23:15, Carl Baldwin <c...@ecbaldwin.net> wrote: > I wonder if we could satisfy this requirement with tags - as it seems these > subnets are anyway operator-owned you shou

[openstack-dev] [Neutron] Segments, subnet types, and IPAM

Hi, I have started to get into coding [1] for the Neutron routed networks specification [2]. This spec proposes a new association between network segments and subnets. This affects how IPAM needs to work because until we know where the port is going to land, we cannot allocate an IP address for

Re: [openstack-dev] [Neutron] Intra-column wrapping in python-neutronclient

On Wed, Feb 24, 2016 at 2:58 PM, Steve Baker wrote: > My intention was that it be a usability improvement rather than merely an > aesthetic one. Yes, it is unfortunate that it affects this specific copy > paste scenario but there are others where it is improved. I've often been

Re: [openstack-dev] [Neutron] Intra-column wrapping in python-neutronclient

, Feb 24, 2016 at 10:23 AM, Carl Baldwin <c...@ecbaldwin.net> wrote: > Hi, > > I've noticed a new behavior from the python-neutronclient which > disturbs me. For me, this just started happening with my latest build > of devstack which I built yesterday. It didn't happen

[openstack-dev] [Neutron] Intra-column wrapping in python-neutronclient

Hi, I've noticed a new behavior from the python-neutronclient which disturbs me. For me, this just started happening with my latest build of devstack which I built yesterday. It didn't happen with another recent but little bit older devstack. The issue is that the client is now wrapping

Re: [openstack-dev] [neutron][dnsmasq]DNS redirection by dnsmasq

On Tue, Feb 16, 2016 at 11:55 PM, Zhi Chang wrote: > DNS redirection is our customer's needs. Customer has their own CDN. They > want to save traffic in CDN so that they can cost less money. > So they let us hijack some domain names. We used dnsmasq "--cname" option to >

Re: [openstack-dev] [infra][neutron] publish and update Gerrit dashboard link automatically

Could this be done by creating a project dashboard [1]? I think the one thing that prevents using such a dashboard is that your script generates a dashboard that crosses multiple projects. So, we'd be stuck with multiple dashboards, one per project. The nature of your script is to create a new

Re: [openstack-dev] [neutron][dnsmasq]DNS redirection by dnsmasq

What would be the motivation for this? Could you give some examples of what you'd use it for? Keep in mind that --cname is limited to target names known by dnsmasq itself. Carl On Mon, Feb 15, 2016 at 2:13 AM, Zhi Chang wrote: > hi, guys. > Most of us know about

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On Mon, Feb 15, 2016 at 9:26 AM, Pavel Bondar wrote: > Your idea sounds workable to me. However I think a simpler way exists. I'll be happy to review your migration for Mitaka which should be totally out-of-band and leave both implementations intact. As for the details of

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On Thu, Feb 11, 2016 at 10:04 AM, Armando M. wrote: > I believe we have more recovery options out a potentially fatal situation. > In fact the offline script can provide a dry-run option that can just > validate that the migration will succeed before it is even actually >

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On Thu, Feb 11, 2016 at 3:32 AM, Ihar Hrachyshka wrote: > Salvatore Orlando wrote: > >> The difference lies in the process in my opinion. >> If the switch is added into the migration path then we will tell operators >> when to switch. >> I was

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On Thu, Feb 11, 2016 at 3:20 AM, Salvatore Orlando wrote: > The difference lies in the process in my opinion. > If the switch is added into the migration path then we will tell operators > when to switch. > I was suggesting doing it manual because we just don't know if

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On Thu, Feb 11, 2016 at 10:04 AM, Armando M. wrote: > On 11 February 2016 at 07:01, John Belamaric > wrote: >> It is only internal implementation changes. > > That's not entirely true, is it? There are config variables to change and it > opens up the

Re: [openstack-dev] [neutron] - please review the neutron security guide

On Tue, Feb 9, 2016 at 1:21 PM, Kevin Benton wrote: > If you see any issues, either propose a patch directly or file a bug against > https://bugs.launchpad.net/openstack-manuals/+filebug with the tag > 'seg-guide' Did you want 'sec-guide'? That would seem more intuitive to me.

Re: [openstack-dev] [Neutron] Being more aggressive with our defaults

On Mon, Feb 8, 2016 at 9:40 AM, Assaf Muller wrote: > As for DVR, I'm searching for someone to pick up the gauntlet and > contribute some L3 fullstack tests. I'd be more than happy to review > it! I even have an abandoned patch that gets the ball rolling (The > idea is to test

Re: [openstack-dev] Announcing a simple new tool: git-restack

Jim, I've had this reply queued up for a week now. Sorry for the delay. The problem that I run in to when I work with multiple dependent changes doesn't seem to be covered by your description. For me, the trouble with this workflow comes when there is more than one contributor working on a

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On Thu, Feb 4, 2016 at 8:12 PM, Armando M. wrote: > as for c) I think it's a little late to make pluggable ipam default in > Mitaka; I'd rather switch defaults early in the cycle (depending on the > entity of the config) and this one seems serious enough that I'd rather have >

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On Thu, Feb 4, 2016 at 8:12 PM, Armando M. wrote: > Technically we can make this as sophisticated and seamless as we want, but > this is a one-off, once it's done the pain goes away, and we won't be doing > another migration like this ever again. So I wouldn't over engineer it.

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar wrote: > I am trying to bring more attention to [1] to make final decision on > approach to use. > There are a few point that are not 100% clear for me at this point. > > 1) Do we plan to switch all current clouds to pluggable

Re: [openstack-dev] [nova] Nova Midcycle Summary (i.e. mid mitaka progress report)

On Tue, Feb 2, 2016 at 4:07 AM, John Garbutt wrote: > Scheduler: > Discussed jay's blueprints. For mitaka we agreed to focus on: > http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/resource-classes.html, >

Re: [openstack-dev] [Neutron] Team meeting this Tuesday at 1400 UTC

I almost missed this because [Neutron] was missing from the subject. I'm replying now to add it in case someone else missed it. On Sat, Jan 30, 2016 at 2:27 PM, Armando M. wrote: > Hi neutrinos, > > According to [1], this is a kind reminder for next week's meeting: please do >

[openstack-dev] [Nova][Neutron] Scheduling with routed networks

this spec and record any thoughts or conclusions that I might have missed or mis-understood. Thanks, Carl Baldwin [1] https://review.openstack.org/#/c/263898/ __ OpenStack Development Mailing List (not for usage questions

Re: [openstack-dev] [Nova] Nova midcycle list of attendees

On Jan 14, 2016 3:43 PM, "Anita Kuno" wrote: > > On 01/14/2016 12:38 PM, Murray, Paul (HP Cloud) wrote: > > I have created a list of attendees for the Nova midcycle here: https://wiki.openstack.org/wiki/Sprints/NovaMitakaSprintAttendees > > > > Obviously I can't put anyone's

[openstack-dev] Further closing the holes that let gate breakage happen

Hi, I was looking at the most recent gate breakage in Neutron [1], fixed by [2]. This gate breakage was held off for some time by the upper-constraints.txt file. This is great progress and I applaud it. I'll continue to cheer on this effort. Now to the next problem. If my assessment of this

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

What do we do? My calendar was set up with the sane bi-weekly thing and it shows the meeting for tomorrow. The last word from our fearless leader is that we'll have it today. So, I'll be there today unless instructed otherwise. The ics file now seems to reset the cadence beginning today at

[openstack-dev] [Neutron][Nova][nova-scheduler] Neutron's Routed Networks and Nova

I attended the Nova scheduler meeting yesterday morning in hopes to set the stage for a discussion about Neutron's routed networks work and how that affects Nova [1]. John suggested that I write up a backlog spec to start the discussion (as he has suggested to me before). I did so today and

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

On Wed, Dec 23, 2015 at 5:54 PM, Clark Boylan wrote: > I got curious and this is an odd situation. I can't find where 212669 > has a patchset with a parent of the commit for 192032,37 (b7151e4). Git > represents the tree as a DAG with each child commit pointing at its >

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

On Wed, Dec 23, 2015 at 1:16 AM, Michał Dulko wrote: > n goes to next occurrence and N (shift+n) to a previous one. These are > same keybindings as in Vim. Actually a lot of Vim-like movements are > functional in new Gerrit and I really like that fact. Thanks. Looking

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

On Wed, Dec 23, 2015 at 1:16 AM, Michał Dulko wrote: > n goes to next occurrence and N (shift+n) to a previous one. These are > same keybindings as in Vim. Actually a lot of Vim-like movements are > functional in new Gerrit and I really like that fact. I'll admit that I

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

On Wed, Dec 23, 2015 at 3:40 PM, Zaro <zaro0...@gmail.com> wrote: > On Tue, Dec 22, 2015 at 4:51 PM, Carl Baldwin <c...@ecbaldwin.net> wrote: >> I noticed another thing. I'm working with a chain of three patches. >> I just updated the patch in the middle [1]

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

On Wed, Dec 23, 2015 at 1:57 PM, Elizabeth K. Joseph <l...@princessleia.com> wrote: > On Wed, Dec 23, 2015 at 10:11 AM, Carl Baldwin <c...@ecbaldwin.net> wrote: >> I do see that a lot of vim movement does work. I was hoping that >> holding down a movement command like

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

On Mon, Dec 21, 2015 at 6:21 PM, Zaro wrote: > Hit '?' and it says '/' is find, give that a try. '/' isn't really much better. It seems to highlight all of the occurrences but I can't find a way to navigate to the next/previous occurence with the keyboard. I see that the

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

gainst gerrit. What should we do? Should we individually go file bugs against gerrit? Or, should we funnel it through someone working on gerrit in openstack? [1] https://review.openstack.org/#/c/192032/37 [2] https://review.openstack.org/#/c/212669/4 On Mon, Dec 21, 2015 at 4:07 PM, Carl Baldwin

Re: [openstack-dev] [Neutron] [IPv6] [radvd] Advertise tenant prefixes from router to outside

On Fri, Dec 18, 2015 at 12:54 PM, Vladimir Eremin wrote: > Hi Carl, > > As far as I understand Address Scopes, end user’s algorithm will be next: > 1. Administrator creates an address scope and associate an IPv6 subnet pool > with it. > 2. Administrator creates Public

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

I noticed a couple of things today while reviewing a largish page [1]. First, when I search for something using the browser's builtin search (Chrome, Mac OSX Yosemite), it doesn't seem to find occurrences that are not in the visible portion of the page. For example, when I search for DNSDOMAIN, I

  1   2   3   4   >