[openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

Hi there. I've been looking into a tricky point, and hope I can succeed in expressing it clearly here... I believe it is the case, even when using a committedly Neutron-based networking implementation, that Nova is still involved a little bit in the networking setup logic. Specifically I mean th

Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

Kevin Benton writes: > What you are proposing sounds very reasonable. If I understand > correctly, the idea is to make Nova just create the TAP device and get > it attached to the VM and leave it 'unplugged'. This would work well > and might eliminate the need for some drivers. I see no reason to

Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

Ian Wells writes: > On 4 December 2014 at 08:00, Neil Jerram > wrote: > > Kevin Benton writes: > I was actually floating a slightly more radical option than that: > the > idea that there is a VIF type (VIF_TYPE_NOOP) for which Nova does > absolu

Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

Kevin Benton writes: > I see the difference now. > The main concern I see with the NOOP type is that creating the virtual > interface could require different logic for certain hypervisors. In > that case Neutron would now have to know things about nova and to me > it seems like that's slightly t

Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

AP. > > Best Regards > Wu > ____ > From: Neil Jerram [neil.jer...@metaswitch.com] > Sent: Saturday, December 06, 2014 10:51 AM > To: Kevin Benton > Cc: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [open

Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver

"Daniel P. Berrange" writes: > Failing that though, I could see a way to accomplish a similar thing > without a Neutron launched agent. If one of the VIF type binding > parameters were the name of a script, we could run that script on > plug & unplug. So we'd have a finite number of VIF types, an

Re: [openstack-dev] [nova] Kilo specs review day

Hi Joe, Joe Gordon writes: > In preparation, I put together a nova-specs dashboard: > > https://review.openstack.org/141137 > > https://review.openstack.org/#/dashboard/?foreach=project%3A%5Eopenstack%2Fnova-specs+status%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D-1+label%3AVerified%3E%3D

Re: [openstack-dev] [nova] Kilo specs review day

Joe Gordon writes: > On Mon, Dec 15, 2014 at 8:46 AM, Radoslav Gerganov > wrote: > > On 12/15/2014 12:54 PM, Neil Jerram wrote: > > My Nova spec (https://review.openstack.org/#/c/130732/) does not > appear > on this dashboard, even thoug

[openstack-dev] Minimal ML2 mechanism driver after Neutron decomposition change

Hi all, Following the approval for Neutron vendor code decomposition (https://review.openstack.org/#/c/134680/), I just wanted to comment that it appears to work fine to have an ML2 mechanism driver _entirely_ out of tree, so long as the vendor repository that provides the ML2 mechanism driver doe

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

Stefano Maffulli writes: > On 12/09/2014 04:11 PM, by wrote: [vad] how about the documentation in this case?... bcos it needs some >> place to document (a short desc and a link to vendor page) or list these >> kind of out-of-tree plugins/drivers... just to make the user aware of >> the avai

Re: [openstack-dev] [Nova] Kilo Release Status - just passed spec freeze

John Garbutt writes: > Hi all, > > With the release of kilo-1 we have frozen the approval of new specs for kilo. > > This is to make sure we can focus on our agreed kilo priorities: > http://specs.openstack.org/openstack/nova-specs/priorities/kilo-priorities.html > > As always, there are exceptio

[openstack-dev] [nova] Request Spec Freeze Exception for VIF_TYPE_TAP (https://review.openstack.org/#/c/130732/)

Hi all, I'd like to request an exception for my Nova spec adding VIF_TYPE_TAP: https://review.openstack.org/#/c/130732/ (Some history: This spec was previously approved as of Patch Set 7, but with some requests for minor clarifications to the text. When I uploaded Patch Sets 8 and 9, to make th

Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver

Maxime Leroy writes: > Ok, thank you for the details. I will look how to implement this feature. Hi Maxime, Did you have time yet to start looking at this? My team now has a use case that could be met by using vif_plug_script, so I would be happy to help with writing the spec for that. Would

Re: [openstack-dev] [Neutron] Neutron Social Meetup in Tokyo

Lovely, thanks for organizing! Looking forward to it! Neil Original Message From: Akihiro Motoki Sent: Friday, 23 October 2015 17:27 To: OpenStack Development Mailing List Reply To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron] Neutron Soci

Re: [openstack-dev] DevStack errors...

On 02/11/15 23:56, Thales wrote: I'm trying to get DevStack to work, but am getting errors. Is this a good list to ask questions for this? I can't seem to get answers anywhere I look. I tried the openstack list, but it kind of moves slow. Thanks for any help. Regards, John In case it helps

Re: [openstack-dev] [Neutron][dns]What the meaning of "dns_assignment" and "dns_name"?

Hi Miguel, I’ve just been looking at this, and have deduced the following summary of the new dns_name and dns_assignment fields: - dns_name is a simple name, like 'vm17'. It is a writable port field, and gets combined with a dns_domain that is specified elsewhere. - dns_assignment is a server

Re: [openstack-dev] DevStack errors...

Thanks for following up with these details. Good news! Neil From: Thales [mailto:thale...@yahoo.com] Sent: 05 November 2015 20:16 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] DevStack errors... Neil Jerram wrote: "When you sa

Re: [openstack-dev] [release] Release countdown for week R-21, Nov 9-13

On 05/11/15 14:22, Doug Hellmann wrote: > All deliverables should have reno configured before Mitaka 1. See > http://lists.openstack.org/pipermail/openstack-dev/2015-November/078301.html > for details, and follow up on that thread with questions. I guess that 'deliverables' do not include projects

[openstack-dev] [neutron][stable] Understanding stable/branch process for Neutron subprojects

Prompted by the thread about maybe allowing subproject teams to do their own stable maint, I have some questions about what I should be doing in networking-calico; and I guess the answers may apply generally to subprojects. Let's start from the text at http://docs.openstack.org/developer/neutron/d

Re: [openstack-dev] [neutron][stable] Understanding stable/branch process for Neutron subprojects

On 06/11/15 13:46, Ihar Hrachyshka wrote: > Neil Jerram wrote: > >> Prompted by the thread about maybe allowing subproject teams to do their >> own stable maint, I have some questions about what I should be doing in >> networking-calico; and I guess the answer

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

Yes, maybe. I'm interested in a pluggable IPAM module that will allocate an IP address for a VM that depends on where that VM's host is‎ in the physical data center network. Is that similar to your requirement? I don't yet know whether that might lead me to want to store additional data in the

Re: [openstack-dev] [neutron][tap-as-a-service] weekly meeting

Sounds interesting! I'd like to look at some past meeting logs (including from today), but the 'past meetings' link at http://eavesdrop.openstack.org/#Tap_as_a_Service_Meeting does not work for me. Neil -Original Message- From: Takashi Yamamoto [mailto:yamam...@midokura.com] S

Re: [openstack-dev] Linux kernel IPv4 configuration during the neutron installation

On 11/11/15 10:30, JinXing F wrote: > > Hi, guys: > > during the neutron installation guide, I found that we need to > config the linux kernel as bellow: > > net.ipv4.ip_forward=1 > > net.ipv4.conf.all.rp_filter=0 > > net.ipv4.conf.default.rp_filter=0 > > > the first one is the ip address tran

[openstack-dev] REST API collation and visualization

Hi there, I'm interested in collating all the REST API exchanges to and between OpenStack components, and presenting / visualizing all those in an easily comprehensible way. Is there already some tool to do that? Many thanks, Neil ___

Re: [openstack-dev] REST API collation and visualization

On 16/11/15 16:37, Neil Jerram wrote: > Hi there, > > I'm interested in collating all the REST API exchanges to and between > OpenStack components, and presenting / visualizing all those in an > easily comprehensible way. Is there already some tool to do that? > > Man

Re: [openstack-dev] REST API collation and visualization

On 16/11/15 17:54, Neil Jerram wrote: > On 16/11/15 16:37, Neil Jerram wrote: >> Hi there, >> >> I'm interested in collating all the REST API exchanges to and between >> OpenStack components, and presenting / visualizing all those in an >> easily comprehensib

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

Thanks to Thomas for continuing this discussion about networking-* projects, and to Thierry for his responses below, and Ihar for his earlier guidance. I have a couple further points that I hope may contribute... On 19/11/15 09:46, Thierry Carrez wrote: > Thomas Morin wrote: >> The starting point

Re: [openstack-dev] [all] how to add/list drivers @ https://www.openstack.org/marketplace/drivers/

That reminds me of a follow-on question, as I added my driver's data to the driverlog project a few weeks ago [1]: when does the content at https://www.openstack.org/marketplace/drivers/ get rebuilt? Thanks, Neil [1] https://review.openstack.org/#/c/240830/ On 25/11/15 09:42, Ilya Shakhat w

Re: [openstack-dev] [Neutron] Evolving the stadium concept

On 01/12/15 04:13, Russell Bryant wrote: > On 11/30/2015 07:56 PM, Armando M. wrote: >> As a result, there is quite an effort imposed on the PTL, the various >> liaisons (release, infra, docs, testing, etc) and the core team to >> help manage the existing relationships and to ensure that the pictur

Re: [openstack-dev] [Neutron] Evolving the stadium concept

On 01/12/15 05:16, Doug Wiegley wrote: > Part of the issue is that in a year, we added all the repos above. And > all of said repos were all heading over to infra with the same newbie > questions/mistakes. Not a bad thing in and of itself, but the sheer > volume was causing a lot of infra load. So

Re: [openstack-dev] [Neutron] Evolving the stadium concept

On 01/12/15 10:42, Thierry Carrez wrote: > Armando M. wrote: >> [...] >> So my question is: would revisiting/clarifying the concept be due after >> some time we have seen it in action? I would like to think so. > I also think it's time to revisit this experience now that it's been > around for some

[openstack-dev] [neutron] Purpose and documentation of the API

Sometimes when I'm discussing or reviewing proposed specs, I feel as though I may have incorrect assumptions about what the Neutron API is _for_. And certainly I feel that we lack good unified documentation of it - or at least, that I haven't yet found that documentation, if it exists. So I'd lik

Re: [openstack-dev] [Fuel] Patch size limit

On 01/12/15 12:45, Maciej Kwiek wrote: > Hi, > > I recently noticed the influx of big patches hitting Gerrit > (especially in fuel-web, but I also heard that there was a couple of > big ones in library). I think that patches that have 1000 LOC are > simply too big to review thoroughly and reliably.

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

I'm new to this discussion, but you did ask for any feedback, so ... On 03/12/15 18:29, Smigiel, Dariusz wrote: > Hey Neutrinos (thanks armax for this word :), > Keystone is planning to deprecate V2 API (again :). This time in Mitaka [6], > and probably forever. It will stay at least four release

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

On 04/12/15 18:03, Kevin Benton wrote: > >The whole world says 'tenant' for the 'tenant' concept, particularly > in the context of networking. Changing to a different term is just > silly. > > Except for the rest of OpenStack. Do you mean OpenStack developers, OpenStack customers, or OpenStack co

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

asked later "why did no one say anything?" Neil From: Armando M. Sent: 04 December 2015 21:01 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Rename tenant to project: discussion On 4 De

Re: [openstack-dev] [neutron] Multiple locations for documentation of features

On 04/12/15 19:24, Henry Gessau wrote: > Sean M. Collins wrote: >> I've noticed that a lot of features are now being documented as RSTs >> inside of devref. Like the following: >> >> https://review.openstack.org/#/c/251859/ >> >> But there are lots already present. Can someone point out to me what

Re: [openstack-dev] [client][all][neutron] client option removal policy

On 07/12/15 12:01, Akihiro Motoki wrote: > Hi, > > neutronclient is now dropping XML support and as a result > "--request-format" option is no longer needed as JSON is the only format now. > > What is the recommended way for options no longer needed? > Does bumping major version of CLI allow us to

Re: [openstack-dev] [neutron] Multiple locations for documentation of features

On 07/12/15 17:42, Sean M. Collins wrote: > On Mon, Dec 07, 2015 at 12:18:29PM EST, Carl Baldwin wrote: >> On Fri, Dec 4, 2015 at 12:22 PM, Henry Gessau wrote: >>> 1. RFE: "I want X" >>> 2. Spec: "I plan to implement X like this" >>> 3. devref: "How X is implemented and how to extend it" >>> 4. OS

Re: [openstack-dev] [neutron] Multiple locations for documentation of features

On 08/12/15 10:04, Mathieu Rohon wrote: Hi all, thanks for the explanation. Can you also explain how does neutron team use blueprints? how it overlaps with RFE bugs? Hi Mathieu, This is all documented, in principle, at http://docs.openstack.org/developer/neutron/policies/blueprints.html.

Re: [openstack-dev] [charms] Juju Charms for OpenStack

+1 from me (as an OpenStack contributor, and one of those 'developers at SDN and storage vendors' :-) ). Neil On Thu, May 19, 2016 at 11:38 AM James Page wrote: > Hi All > > tl;dr Juju is a great way of deploying OpenStack, and we'd like the > OpenStack Charms for Juju to become a official O

Re: [openstack-dev] [nova-lxd]Nova-lxd with Linuxbridge

FWIW, the networking-calico team plans soon to make nova-lxd work with Calico networking, i.e. where data from/to the veth is routed on the compute host. That should land in July or August. Neil On Fri, May 20, 2016 at 3:30 PM Chuck Short wrote: > Hi, > > Currently it only works with OVS

Re: [openstack-dev] [Fuel] Correct wrong nomenclature in the Networks section of Fuel-ui

As I just commented in the review, I think the wording was clearer as it was before. So would prefer if you do not use this as a model for further similar changes. Neil On Wed, Jun 1, 2016 at 2:06 PM Giuseppe Cossu wrote: > Hi folks, > I submitted a bug and the related fix about a wrong no

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

Me too. On Fri, Jun 10, 2016 at 10:32 AM Cory Benfield wrote: > > > 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 dir

Re: [openstack-dev] [Kuryr] [Neutron] Waiting until Neutron Port is Active

Hi Mohammad, Why is the blocking needed? Is it to report some kind of status back to Docker/Kubernetes, or to allow some follow-on action to happen? When using networking-calico as the driver, I think that only option (1) would work, out of the options you've suggested below. (3) doesn't work,

Re: [openstack-dev] [Kuryr] [Neutron] Waiting until Neutron Port isActive

that be reasonable? > > Best, > > Mohammad > > [image: Inactive hide details for Neil Jerram ---06/10/2016 09:25:59 > AM---Hi Mohammad, Why is the blocking needed? Is it to report som]Neil > Jerram ---06/10/2016 09:25:59 AM---Hi Mohammad, Why is the blocking needed? > Is it t

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

On Wed, Jun 15, 2016 at 9:52 AM Thierry Carrez wrote: > [...] > Those are good points. Note that I do not advocate for those projects to > be kept closed/private: I'm simply saying that those (open source) > projects should not be blessed as "official" and be put under the > Technical Committee o

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

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 happy to be finally proposing a regular IRC meeting slot for it: [1]. A strawma

Re: [openstack-dev] [packaging-deb] Status of the project

Is there a higher-level overview somewhere of what packaging-deb does? Should it be useful to me as the packager of a Neutron driver project (networking-calico)? (Currently I've rolled my own processes for generating Debian packages for Ubuntu Trusty and Xenial.) Thanks, Neil On Wed, Jun 22

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

Thanks, Carl. I had the same observation, so would also be interested in the answer. Neil On Thu, Jun 30, 2016 at 9:15 PM Carl Baldwin wrote: > On Mon, Jun 20, 2016 at 8:42 AM, Neil Jerram wrote: > > Calling everyone interested in networking-calico ...! networking-calico >

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

The first networking-calico IRC meeting was planned for 28th June, but I'm afraid I was unwell - so it will now be 12th July. I've updated the agenda [2] accordingly. Neil On Mon, Jun 20, 2016 at 3:42 PM Neil Jerram wrote: > Calling everyone interested in netw

Re: [openstack-dev] [Neutron] Neutron-lib and Stadium evolution

Hi Armando, Who exactly are you addressing here? AFAICS, [1] on its own doesn't give me (or anyone) any new rights for neutron-lib changes. It appears to be preparatory to a planned expansion of neutron-lib-core - but looking at [5], the membership doesn't include me, or folk from many stadium p

Re: [openstack-dev] [Neutron] Neutron-lib and Stadium evolution

Cool - thanks for clarifying that! Neil On Fri, Jul 8, 2016 at 5:20 PM Armando M. wrote: > On 8 July 2016 at 08:22, Neil Jerram wrote: > >> Hi Armando, >> >> Who exactly are you addressing here? AFAICS, [1] on its own doesn't give >> me (or anyone) any

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

Hi all, Just a quick reminder: the first networking-calico IRC meeting will be tomorrow (12th July) at 1600 UTC. Neil On Fri, Jul 1, 2016 at 12:31 PM Neil Jerram wrote: > The first networking-calico IRC meeting was planned for 28th June, but I'm > afraid I was unwell - so it

[openstack-dev] Singing in Barcelona

I know it's crazy, but I've talked with a few people in Vancouver, Tokyo and Austin about the idea of getting a singing group together during a summit, and they've all encouraged me to go for it - so I'll start to look silly if I don't even try this... :-)So this is a call for anyone who wants to

Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

On 29/03/16 09:38, Thomas Goirand wrote: > On 03/23/2016 04:06 PM, Mike Perez wrote: >> Hey all, >> >> I've been talking to a variety of projects about lack of install guides. This >> came from me not having a great experience with trying out projects in the >> big >> tent. >> >> [...] > > Sorry t

Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

On 29/03/16 12:40, Thomas Goirand wrote: > > The documentation people decided to *not* publish the Debian > install-guide (and remove the link to it) even though it can be > generated and (to my opinion, which is probably biased) works well. > > I'd like to know the steps needed to restore a workin

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

On 29/03/16 15:17, Jay Pipes wrote: > Hi! > > Once Shotgun is pulled out of Fuel, may I suggest renaming it to > something different? I know in the past that Anita and a few others > thought the name was not something we should really be encouraging in > the OpenStack ecosystem. > > Just something

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

FWIW, as a naive bystander: On 30/03/16 11:06, Igor Kalnitsky wrote: > Hey Fuelers, > > I know that you probably wouldn't like to hear that, but in my opinion > Fuel has to stop using Shotgun. It's nothing more but a command runner > over SSH. Besides, it has well known issues such as retrieving

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

On 30/03/16 13:35, Igor Kalnitsky wrote: > Neil Jerram wrote: >> But isn't Ansible also over-complicated for just running commands over SSH? > > It may be not so "simple" to ignore that. Ansible has a lot of modules > which might be very helpful. For instance, Sh

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

On 29/03/16 20:42, Miguel Lavalle wrote: > Hi, Hi Miguel, > 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 that if a host A

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

On 11/03/16 23:20, Carl Baldwin wrote: > Hi, Hi Carl, and sorry for the lateness of this reply. > 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 need

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

On 29/03/16 19:16, Carl Baldwin 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 group subnets to allow for aggregation of routes. (a) In > r

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

On 29/03/16 21:55, Carl Baldwin wrote: > > I thought of another type of grouping which could benefit pluggable > IPAM today. It occurred to me as I was refreshing my memory on how > pluggable IPAM works when there are multiple subnets on a network. > Currently, Neutron's backend pulls the subnets

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

On 30/03/16 16:08, Pavel Bondar wrote: > We are now in early Newton, so it is good time to discuss plan for > pluggable ipam for this release cycle. > > Kevin Benton commented on review page for current migration to pluggable > approach [1]: >> >> IMO this cannot be optional. It's going to be a ni

Re: [openstack-dev] [Nova] No rejoin-stack.sh script in my setup

On 31/03/16 12:10, Ouadï Belmokhtar wrote: > Hi everyone, > > Could you give any help to my question here, please. > > http://stackoverflow.com/questions/36268822/no-rejoin-stack-sh-script-in-my-setup > > I'm blocked with the same problem since 10 days. Any help is considered. I think the recommen

Re: [openstack-dev] [All][Neutron] Improving development and review velocity - Is it time for a drastic change?

On 01/04/16 02:16, Assaf Muller wrote: > Have you been negatively impacted by slow development and review > velocity? Read on. > > OpenStack has had a slow review velocity for as long as I can > remember. This has a cascading effect where people take up multiple > tasks, so that they can work on so

Re: [openstack-dev] [nova] [all] FYI: Removing default flavors from nova

I hesitate to write this, even now, but I do think that OpenStack has a problem with casual incompatibilities, such as this appears to be. But, frankly, I've been slapped down for expressing my opinion in the past (on the pointless 'tenant' to 'project' change), so I just quietly despaired whe

Re: [openstack-dev] [all] [devstack] Adding example "local.conf" files for testing?

On 14/04/16 08:35, Markus Zoeller wrote: > Sometimes (especially when I try to reproduce bugs) I have the need > to set up a local environment with devstack. Everytime I have to look > at my notes to check which option in the "local.conf" have to be set > for my needs. I'd like to add a folder in d

[openstack-dev] summit tools

A couple of questions about our Austin-related planning tools... - Can one's calendar at https://www.openstack.org/summit/austin-2016/summit-schedule/#day=2016-04-25 be exported as .ics, or otherwise integrated into a wider calendaring system? - Is the app working for anyone else? All I get i

Re: [openstack-dev] [Fuel][Plugins] One plugin - one Launchpad project

On 19/04/16 16:52, Irina Povolotskaya wrote: > Hi to everyone, > > as you possibly know (at least, those dev. teams working on their Fuel > plugins) we have a fuel-plugins Launchpad project [1] which serves as > all-in-one entry point for filing bugs, related > to plugin-specific problems. > > neve

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

On 25/04/16 10:58, 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. That sounds good to me - thanks for thinking of it! Neil ___

Re: [openstack-dev] Easing contributions to central documentation

On 09/05/16 22:57, Matt Kassawara wrote: > At each summit, I speak with a variety of developers from different > projects about the apparent lack of contributions to the central > documentation. At previous summits, the most common complaint involved > using DocBook. After converting most of the do

[openstack-dev] [kuryr] Port binding query

I'm trying Kuryr with networking-calico and think I've hit an unhelpful inconsistency. A Neutron port has 'id' and 'device_id' fields that are usually different. When Nova does VIF binding for a Neutron port, it generates the Linux device name from 'tap' + port['id']. But when Kuryr does VIF bin

[openstack-dev] [kuryr] Port binding query

I'm trying Kuryr with networking-calico and think I've hit an unhelpful inconsistency. A Neutron port has 'id' and 'device_id' fields that are usually different. When Nova does VIF binding for a Neutron port, it generates the Linux device name from 'tap' + port['id']. But when Kuryr does VIF bindin

Re: [openstack-dev] Easing contributions to central documentation

On 09/05/16 22:57, Matt Kassawara wrote: > At each summit, I speak with a variety of developers from different > projects about the apparent lack of contributions to the central > documentation. At previous summits, the most common complaint involved > using DocBook. After converting most of the do

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

On 14/12/15 20:37, Armando M. wrote: > Hi neutrinos, > > A kind reminder for this week's meeting. > > For this week we'll continue with the post-milestone format: we'll > continue talking about blueprints/specs and RFEs. We'll be brief on > announcements and bugs, and skip the other sections, docs

Re: [openstack-dev] [neutron] Query about re-directing incoming traffic.

On 28/12/15 16:16, Vikram Choudhary wrote: > Hi All, > > We want to redirect all / some specific incoming traffic to a > particular neutron port, where a network function is deployed. > [Network function could be DPI, IDS, Firewall, Classifier, etc]. In > this regard, we have few queries: Isn't th

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

On 13/01/16 19:27, Carl Baldwin wrote: > 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. > >

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

and your statement. Thanks, Neil > > -- Dims > > > > On Thu, Jan 14, 2016 at 6:51 AM, Neil Jerram > wrote: >> On 13/01/16 19:27, Carl Baldwin wrote: >>> Hi, >>> >>> I was looking at the most recent gate breakage in Neutron [1], fixed >&

Re: [openstack-dev] [Openstack] [Neutron] [Docs] Definition of a provider Network

On 19/01/16 07:36, Andreas Scheuring wrote: > Hi everybody, > > I stumbled over a definition that explains the difference between a > Provider network and a self service network. [1] I've also spent time trying to understand this, so am happy to offer that understanding here (for checking?)...

[openstack-dev] [neutron][networking-calico] To be or not to be an ML2 mechanism driver?

networking-calico [1] is currently implemented as an ML2 mechanism driver, but I'm wondering if it might be better as its own core plugin, and I'm looking for input about the implications of that, or for experience with that kind of change; and also for experience and understanding of hybrid ML2 ne

[openstack-dev] [neutron] https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers

Is there any part of the cited wiki page that is still relevant?I've just been asked whether networking-calico (a backend project that I work on) should be listed there, and I think the answer is no because that page is out of date now. If that's right, could/should it be deleted? Thanks,

Re: [openstack-dev] [neutron] https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers

Thanks! On 28/01/16 00:23, Armando M. wrote: > I'll kill it, as this should be superseded by the in-tree devref version. > > Thanks for pointing my attention to it. > > On 27 January 2016 at 23:40, Neil Jerram <mailto:neil.jer...@metaswitch.com>> wrote: > >

Re: [openstack-dev] [all] the trouble with names

On 04/02/16 11:40, Sean Dague wrote: > What options do we have? > > 1) Use the names we already have: nova, glance, swift, etc. > > Upside, collision problem is solved. Downside, you need a secret decoder > ring to figure out what project does what. This is my preference. Yes, it means that there

Re: [openstack-dev] [Neutron] Evolving the stadium concept

On 04/02/16 22:39, Assaf Muller wrote: > On Thu, Feb 4, 2016 at 5:55 PM, Sean M. Collins wrote: >> On Thu, Feb 04, 2016 at 04:20:50AM EST, Assaf Muller wrote: >> >>> Currently I don't understand why >>> being a part of the stadium is good or bad for a networking project, >>> or why does it matter.

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 05/02/16 10:59, Thierry Carrez wrote: > Hi everyone, > > Even before OpenStack had a name, our "Four Opens" principles were > created to define how we would operate as a community. The first open, > "Open Source", added the following precision: "We do not produce 'open > core' software". What

Re: [openstack-dev] [all] the trouble with names

On 05/02/16 13:50, Dean Troyer wrote: > On Fri, Feb 5, 2016 at 7:13 AM, Neil Jerram <mailto:neil.jer...@metaswitch.com>> wrote: > > On 04/02/16 11:40, Sean Dague wrote: > > What options do we have? > > > > 1) Use the names we al

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

On 05/02/16 16:31, Pavel Bondar wrote: > On 05.02.2016 12:28, Salvatore Orlando wrote: >> >> >> On 5 February 2016 at 04:12, Armando M. > > wrote: >> >> >> >> On 4 February 2016 at 08:22, John Belamaric >> <jbelama...@infoblox.com> w

Re: [openstack-dev] [neutron] - L3 flavors and issues with use cases for multiple L3 backends

On 01/02/16 14:11, Kevin Benton wrote: > Hi all, > > I've been working on an implementation of the multiple L3 backends > RFE[1] using the flavor framework and I've run into some snags with the > use-cases.[2] Is there any good documentation for flavors yet? I recall looking unsuccessfully, a fe

[openstack-dev] [neutron] Reading an updated port's fixed IPs in mech driver update_port_postcommit

I think there's something I'm not understanding about how Neutron's DB tables are related, and when one can safely read believed-to-be-committed information from them... My project's mechanism driver is handling a port update in which the fixed IPs are changing; specifically, a second fixed IP

Re: [openstack-dev] [neutron] Reading an updated port's fixed IPs in mech driver update_port_postcommit

e sure you are using the same DB session from the context that was passed into update_port_postcommit and that will make sure you always have access to the current state even if the transaction isn't closed. On Tue, Jul 7, 2015 at 5:35 AM, Neil Jerram mailto:neil.jer...@metaswitch.com>>

Re: [openstack-dev] [Openstack] Rescinding the M name decision

In the hope of forestalling an unnecessary sub-thread... Mita was #1 in the vote, so has presumably already been ruled out by OpenStack's legal review. On 09/07/15 13:14, Mark Carlson wrote: Isn't Mita a trademark of Kyocera they use for their copier business? Folks should read up on Musashi

Re: [openstack-dev] [Openstack-operators] [Openstack] Rescinding the M name decision

On 10/07/15 10:19, Thierry Carrez wrote: Part of the confusion here is that we are not naming "releases". We are naming release *cycles*. We are giving a name to a period of time, basically. In that period of time, various version numbers for various components will be released. Saying "Glance 1

Re: [openstack-dev] [neutron] Reading an updated port's fixed IPs in mech driver update_port_postcommit

ssing up the DB handle when it's invoked? One way to make sure there aren't open transactions for testing is to just remove the "subtransactions=True" statement from update_port in the ML2 plugin. On Jul 7, 2015 8:33 AM, "Neil Jerram" mailto:neil.jer...@metaswitch.com

Re: [openstack-dev] How to get the Physical switch data at the openstack neutron

Hi there! On 15/07/15 14:02, Ram Mallagundla wrote: Hi All, I am working on to display the physical switch topology at the Horizon , i mean the if there are four switches are interconnected . need display same topology at the openstack Horizon. is there any way to get the physical switch

[openstack-dev] [neutron] What does flavor mean for a network?

I've been reading available docs about the forthcoming Neutron flavors framework, and am not yet sure I understand what it means for a network. Is it a way for an admin to provide a particular kind of network, and then for a tenant to know what they're attaching their VMs to? How does it diff

Re: [openstack-dev] [neutron] What does flavor mean for a network?

t location in principle for a value identifying this kind of network, according to the intention of the flavors enhancement. On Wed, Jul 15, 2015 at 10:40 AM, Madhusudhan Kandadai <mailto:madhusudhan.openst...@gmail.com>> wrote: On Wed, Jul 15, 2015 at 9:2

[openstack-dev] [neutron] 'routed' network type, DHCP agent + devstack support - review requested

Hi Neutron folk! I'd like to give an update on and encourage wide review of my work on a type of network that connects VMs through IP routing instead of through bridging and tunneling at L2. I believe the core Neutron pieces of this are now complete and ready for detailed review and potential me

Re: [openstack-dev] [Neutron] HELP CONFIRM OR DISCUSS:create a port when network contain ipv4 subnets and ipv6 subnets, allocate ipv6 address to the port.

I am not completely sure, but I believe that the primary associations are that: - a port is attached to a particular network - a network may have an IPv4 subnet and/or an IPv6 subnet - therefore, when a port is created, it gets an IPv4 address, and/or an IPv6 address, according to the subnets

  1   2   3   4   >