Re: [openstack-dev] [Neutron] Stable/liberty breakage

[Aaron Rosen]

Sorry I think I gave Gary some bad information here.

After digging into this more, the actually underlying issue that we hit is
that the packaged 'distro' version of stable/liberty that was running with
the vmware-nsx repo included this patch set which is not in upstream
stable/liberty

https://github.com/openstack/neutron/commit/7267d75fdd3f90af759d71e9490cd41d41ba6d98

That's what was causing the issue on our end.  All should be okay upstream.
Sorry about the confusion.

Aaron



On Wed, Jun 15, 2016 at 11:59 AM, Ihar Hrachyshka 
wrote:

>
> > On 15 Jun 2016, at 20:18, Gary Kotton  wrote:
> >
> > Hi,
> > The following patch breaks stable liberty drivers -
> https://review.openstack.org/#/c/238745/
> > This means that plugins will need to be updated to support this.
>
> Would you mind sharing details about the breakage? It was assumed that the
> patch backported includes the relevant compatibility bits to avoid any
> breakage. If that’s not the case, we should definitely come up with a way
> to get existing drivers unbroken again.
>
> > What do we do:
> >   • Revert – which could break people using latest stable/liberty
> >   • Have a requirement that Neutron plugins be updated when they use
> stable/liberty
>
> It may be either revert, or a new patch that would accommodate for your
> broken driver. It depends on breakage details. So please share those.
>
> > This is really bad.
>
> Absolutely. The change was not expected to require any changes for 3party
> drivers. If it happened, that’s our fault, and maybe we should land
> something, or revert. We should not leave it broken for 3party drivers.
>
> > Any suggestions.
> > Thanks
> > Gary
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!

[Aaron Rosen]

+1 to both!  (Sorry missed this email the first go around).

On Fri, Aug 14, 2015 at 10:25 AM, Mark McClain m...@mcclain.xyz wrote:

 +1 to Brandon and Russell.

 mark

 On Aug 13, 2015, at 2:47 PM, Kevin Benton blak...@gmail.com wrote:

 +1

 On Wed, Aug 12, 2015 at 10:43 PM, Akihiro Motoki amot...@gmail.com
 wrote:

 +1 for both.

 2015-08-12 22:45 GMT+09:00 Kyle Mestery mest...@mestery.com:

 It gives me great pleasure to propose Russell Bryant and Brandon Logan
 as core reviewers in the API/DB/RPC area of Neutron. Russell and Brandon
 have both been incredible contributors to Neutron for a while now. Their
 expertise has been particularly helpful in the area they are being proposed
 in. Their review stats [1] place them both comfortably in the range of
 existing Neutron core reviewers. I expect them to continue working with all
 community members to drive Neutron forward for the rest of Liberty and into
 Mitaka.

 Existing DB/API/RPC core reviewers (and other Neutron core reviewers),
 please vote +1/-1 for the addition of Russell and Brandon.

 Thanks!
 Kyle

 [1] http://stackalytics.com/report/contribution/neutron-group/90


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Proposing Cedric Brandily to Neutron Core Reviewer Team

[Aaron Rosen]

+1

On Thu, Jul 16, 2015 at 1:47 AM, Oleg Bondarev obonda...@mirantis.com
wrote:

 +1

 On Thu, Jul 16, 2015 at 2:04 AM, Brian Haley brian.ha...@hp.com wrote:

 +1


 On 07/15/2015 02:47 PM, Carl Baldwin wrote:

 As the Neutron L3 Lieutenant along with Kevin Benton for control
 plane, and Assaf Muller for testing, I would like to propose Cedric
 Brandily as a member of the Neutron core reviewer team under these
 areas of focus.

 Cedric has been a long time contributor to Neutron showing expertise
 particularly in these areas.  His knowledge and involvement will be
 very important to the project.  He is a trusted member of our
 community.  He has been reviewing consistently [1][2] and community
 feedback that I've received indicates that he is a solid reviewer.

 Existing Neutron core reviewers from these areas of focus, please vote
 +1/-1 for the addition of Cedric to the team.

 Thanks!
 Carl Baldwin

 [1] https://review.openstack.org/#/q/reviewer:zzelle%2540gmail.com,n,z
 [2] http://stackalytics.com/report/contribution/neutron-group/90


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [congress] is an openstack project

[Aaron Rosen]

Sure thing!

Thanks Sean.

Aaron


On Tue, Mar 31, 2015 at 1:28 PM, sean roberts seanrobert...@gmail.com
wrote:

 All is left now is to patch infra to copy the three repos from stackforge.
 Aaron can you take that on?

 Congratulations team!

 ~ sean

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Congress]How to add tempest tests for testing murano drive

[Aaron Rosen]

The ci runs: `cp -r contrib/tempest/tempest /opt/stack/tempest`  so all you
need to do is add you're file and it will get copied into tempest.

Aaron

On Tue, Mar 10, 2015 at 10:31 AM, Wong, Hong hong.w...@hp.com wrote:

  Hi Aaron,



 I just want to confirm how CI is running the congress tempest tests in its
 environment as I am about to check in a tempest test for testing murano
 deployment.  If I check in the test script to
 congress/contrib/tempest/tempest/scenario/congress_datasources, the CI will
 take care of running the test by copying it to
 stack/tempest/tempest/scenario/congress_datasources ?  So, I don't need to
 worry about adding python-congerssclient and python-muranoclient in
 stack/tempest/requirements.txt right ?



 Thanks,

 Hong







 *From:* Aaron Rosen [mailto:aaronoro...@gmail.com aaronoro...@gmail.com]

 *Sent:* Monday, March 09, 2015 9:28 PM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [Congress]How to add tempest tests for
 testing murano drive



 Hi Hong,



 I you should be able to run the tempest tests with ./run_tempest.sh -N
 which by default uses site-packages so they should be installed by the
 devstack script. If you want to run tempest via tox and venv you'll need to
 do:



 echo python-congressclient  requirements.txt

 echo python-muranoclient  requirements.txt



 Then have tox build the venv.



 Best,



 Aaron



 On Mon, Mar 9, 2015 at 8:28 PM, Wong, Hong hong.w...@hp.com wrote:

 Hi Tim and Aaron,



 I got the latest changes from r157166 and I see the
 thirdparty-requirements.txt file where you can define the murano client
 (it’s already there), so the unit tests for murano driver can run out from
 the box.  However, this change is only in congress, so the tempest tests
 (tempest/ directory where congress tempest tests need to copy to as
 described from readme file) required murano and congress clients will still
 have issue as it doesn’t have the thirdparty requirement file concept.
 Will r157166 changes also going to be implemented in tempest package ?



 Thanks,

 Hong



 --



 Message: 10

 Date: Mon, 2 Mar 2015 15:39:11 +

 From: Tim Hinrichs thinri...@vmware.com

 To: OpenStack Development Mailing List (not for usage questions)

   openstack-dev@lists.openstack.org

 Subject: Re: [openstack-dev] [Congress]How to add tempest tests for

   testing murano driver

 Message-ID: d6dbf6ed-2207-4e19-9eec-c270bce2f...@vmware.com

 Content-Type: text/plain; charset=utf-8



 Hi Hong,



 Aaron started working on this, but we don?t have anything in place yet, as
 far as I know.  He?s a starting point.



 https://review.openstack.org/#/c/157166/



 Tim



 On Feb 26, 2015, at 2:56 PM, Wong, Hong 
 hong.w...@hp.commailto:hong.w...@hp.com wrote:



 Hi Aaron,



 I am new to congress and trying to write tempest tests for the newly added
 murano datasource driver.  Since the murano datasource tempest tests
 require both murano and python-congress clients as the dependencies.  I was
 told that I can't just simply add the requirements in the
 tempest/requirements.txt file as both packages are in not in the main
 branch, so CI will not be able to pick them up.  Do you know of any
 workaround ?



 Thanks,

 Hong




 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Congress]How to add tempest tests for testing murano drive

[Aaron Rosen]

Hi Hong,

I you should be able to run the tempest tests with ./run_tempest.sh -N
which by default uses site-packages so they should be installed by the
devstack script. If you want to run tempest via tox and venv you'll need to
do:

echo python-congressclient  requirements.txt
echo python-muranoclient  requirements.txt

Then have tox build the venv.

Best,

Aaron

On Mon, Mar 9, 2015 at 8:28 PM, Wong, Hong hong.w...@hp.com wrote:

  Hi Tim and Aaron,



 I got the latest changes from r157166 and I see the
 thirdparty-requirements.txt file where you can define the murano client
 (it’s already there), so the unit tests for murano driver can run out from
 the box.  However, this change is only in congress, so the tempest tests
 (tempest/ directory where congress tempest tests need to copy to as
 described from readme file) required murano and congress clients will still
 have issue as it doesn’t have the thirdparty requirement file concept.
 Will r157166 changes also going to be implemented in tempest package ?



 Thanks,

 Hong



 --



 Message: 10

 Date: Mon, 2 Mar 2015 15:39:11 +

 From: Tim Hinrichs thinri...@vmware.com

 To: OpenStack Development Mailing List (not for usage questions)

   openstack-dev@lists.openstack.org

 Subject: Re: [openstack-dev] [Congress]How to add tempest tests for

   testing murano driver

 Message-ID: d6dbf6ed-2207-4e19-9eec-c270bce2f...@vmware.com

 Content-Type: text/plain; charset=utf-8



 Hi Hong,



 Aaron started working on this, but we don?t have anything in place yet, as
 far as I know.  He?s a starting point.



 https://review.openstack.org/#/c/157166/



 Tim



 On Feb 26, 2015, at 2:56 PM, Wong, Hong 
 hong.w...@hp.commailto:hong.w...@hp.com wrote:



 Hi Aaron,



 I am new to congress and trying to write tempest tests for the newly added
 murano datasource driver.  Since the murano datasource tempest tests
 require both murano and python-congress clients as the dependencies.  I was
 told that I can't just simply add the requirements in the
 tempest/requirements.txt file as both packages are in not in the main
 branch, so CI will not be able to pick them up.  Do you know of any
 workaround ?



 Thanks,

 Hong



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Aaron Rosen]

I believe I was the one who changed the default value of this. When we
upgraded our internal cloud ~6k networks back then from folsom to grizzly
we didn't account that if the dhcp-agents went offline that instances would
give up their lease and unconfigure themselves causing an outage. Setting a
larger value for this helps to avoid this downtime (as Brian pointed out as
well). Personally, I wouldn't really expect my instance to automatically
change it's ip  - I think requiring the user to reboot the instance or use
the console to correct the ip should be good enough. Especially since this
will help buy you shorter down time if an agent fails for a little while
which is probably more important than having the instance change it's ip.

Aaron

On Tue, Feb 3, 2015 at 5:25 PM, Kevin Benton blak...@gmail.com wrote:

 I definitely understand the use-case of having updatable stuff and I don't
 intend to support any proposals to strip away that functionality. Brian was
 suggesting was to block port IP changes since it depended on DHCP to
 deliver that information to the hosts. I was just pointing out that we
 would need to block any API operations that resulted in different
 information being delivered via DHCP for that approach to make sense.

 On Tue, Feb 3, 2015 at 5:01 PM, Robert Collins robe...@robertcollins.net
 wrote:

 On 3 February 2015 at 00:48, Kevin Benton blak...@gmail.com wrote:
 The only thing this discussion has convinced me of is that allowing
 users
  to change the fixed IP address on a neutron port leads to a bad
  user-experience.
 ...

 Documenting a VM reboot is necessary, or even deprecating this (you
 won't
  like that) are sounding better to me by the minute.
 
  If this is an approach you really want to go with, then we should at
 least
  be consistent and deprecate the extra dhcp options extension (or at
 least
  the ability to update ports' dhcp options). Updating subnet attributes
 like
  gateway_ip, dns_nameserves, and host_routes should be thrown out as
 well.
  All of these things depend on the DHCP server to deliver updated
 information
  and are hindered by renewal times. Why discriminate against IP updates
 on a
  port? A failure to receive many of those other types of changes could
 result
  in just as severe of a connection disruption.

 So the reason we added the extra dhcp options extension was to support
 PXE booting physical machines for Nova baremetal, and then Ironic. It
 wasn't added for end users to use on the port, but as a generic way of
 supporting the specific PXE options needed - and that was done that
 way after discussing w/Neutron devs.

 We update ports for two reasons. Primarily, Ironic is HA and will move
 the TFTPd that boots are happening from if an Ironic node has failed.
 Secondly, because a non uncommon operation on physical machines is to
 replace broken NICs, and forcing a redeploy seemed unreasonable. The
 former case doesn't affect running nodes since its only consulted on
 reboot. The second case is by definition only possible when the NIC in
 question is offline (whether hotplug hardware or not).

 -Rob


 --
 Robert Collins rbtcoll...@hp.com
 Distinguished Technologist
 HP Converged Cloud

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] 10Gbe performance issue.

[Aaron Rosen]

If you can get 9Gbps with multiple connections I'm guessing it's because of
latency and the buffer size of your sockets. If you change the sending and
receiving window size you should be able to fully saturate the link with
one connection (though there are several reasons for not doing that).

On Tue, Jan 20, 2015 at 8:14 AM, Piotr Korthals piotr.korth...@intel.com
wrote:

  Hi,

 I am facing issue with performance of 10 Gigabit Ethernet.

 Environment 2 hosts each:
 - 2 * Intel(R) Xeon(R) CPU E5-2690 v2
 - Intel 82599ES 10Gb Ethernet
 - 128GB RAM

 System:
 - Centos 6.5 delivered by fuel 6.0

 iperf during test of network performance over single stream report
 2,5-3Gbps (when using 4+ connection, cumulative transfer can hit over 9Gbps)

 For comparison, same test was run on official Centos 6.5 with result at
 minimum 9,3 Gbps

 In both cases default MTU 1500 was set.

 From my analyses it looks like something is limiting i/o performance per
 stream.

 Are you aware of this issue, and can you comment on it?

 This is critical for our deployment.


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Changes to the core team

[Aaron Rosen]

+1

On Fri, Jan 16, 2015 at 12:03 PM, Carl Baldwin c...@ecbaldwin.net wrote:

 +1

 On Thu, Jan 15, 2015 at 3:31 PM, Kyle Mestery mest...@mestery.com wrote:
  The last time we looked at core reviewer stats was in December [1]. In
  looking at the current stats, I'm going to propose some changes to the
 core
  team. Reviews are the most important part of being a core reviewer, so we
  need to ensure cores are doing reviews. The stats for the 90 day period
 [2]
  indicate some changes are needed for core reviewers who are no longer
  reviewing on pace with the other core reviewers.
 
  First of all, I'm removing Sumit Naiksatam from neutron-core. Sumit has
 been
  a core reviewer for a long time, and his past contributions are very much
  thanked by the entire OpenStack Neutron team. If Sumit jumps back in with
  thoughtful reviews in the future, we can look at getting him back as a
  Neutron core reviewer. But for now, his stats indicate he's not
 reviewing at
  a level consistent with the rest of the Neutron core reviewers.
 
  As part of the change, I'd like to propose Doug Wiegley as a new Neutron
  core reviewer. Doug has been actively reviewing code across not only all
 the
  Neutron projects, but also other projects such as infra. His help and
 work
  in the services split in December were the reason we were so successful
 in
  making that happen. Doug has also been instrumental in the Neutron LBaaS
 V2
  rollout, as well as helping to merge code in the other neutron service
  repositories.
 
  I'd also like to take this time to remind everyone that reviewing code
 is a
  responsibility, in Neutron the same as other projects. And core reviewers
  are especially beholden to this responsibility. I'd also like to point
 out
  that +1/-1 reviews are very useful, and I encourage everyone to continue
  reviewing code even if you are not a core reviewer.
 
  Existing neutron cores, please vote +1/-1 for the addition of Doug to the
  core team.
 
  Thanks!
  Kyle
 
  [1]
 
 http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.html
  [2] http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] python-congressclient 1.0.1 released

[Aaron Rosen]

The congress team is pleased to announce the release of the
python-congressclient 1.0.1.

This release includes several bug fixes as well as many other changes - a
few highlights:

- python34 compatibility
- New CLI command to simulate results of rule
- openstack congress policy simulate  Show the result of simulation.
- Add new CLI command to check the status of a datasource
- openstack congress datasource status list
- Add new CLI for viewing schemas
- openstack congress datasource table schema show  Show schema for
datasource table.
- openstack congress datasource schema show  Show schema for
datasource.
- Add missing CLI command
- openstack congress policy rule show


$ git log --abbrev-commit --pretty=oneline --no-merges 1.0.0..1.0.1
1e31e9d Fix version issue
53dccd7 Workflow documentation is now in infra-manual
bab2c9e Updated from global requirements
9941dd6 Updated from global requirements
7be067e Used schema to compute columns for datasource rows
7a81c74 Added datasource schema
bcb1b90 Added datasource status command
f5fe21a Add news file about what was added in each release
3c4867d Make client work with python34
aa9eb14 Use a more simple policy rule for test
f5e0a70 Adding missing CLI command congress policy rule show
d8d9adc Updated from global requirements
d46cee8 Added command for policy engine's simulation functionality
255d834 Work toward Python 3.4 support and testing

Please report issues through launchpad:
https://launchpad.net/python-congressclient

Thanks!
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Changes to the core team

[Aaron Rosen]

+1 for Kevin and Henry!

On Tue, Dec 2, 2014 at 10:40 AM, Nati Ueno nati.u...@gmail.com wrote:

 Hi folks

 Congrats! Henry and Kevin.
 I'll keep contributing the community, but Thank you for working with
 me as core team :)

 Best
 Nachi

 2014-12-03 2:05 GMT+09:00 Carl Baldwin c...@ecbaldwin.net:
  +1 from me for all the changes.  I appreciate the work from all four
  of these excellent contributors.  I'm happy to welcome Henry and Kevin
  as new core reviewers.  I also look forward to continuing to work with
  Nachi and Bob as important members of the community.
 
  Carl
 
  On Tue, Dec 2, 2014 at 8:59 AM, Kyle Mestery mest...@mestery.com
 wrote:
  Now that we're in the thick of working hard on Kilo deliverables, I'd
  like to make some changes to the neutron core team. Reviews are the
  most important part of being a core reviewer, so we need to ensure
  cores are doing reviews. The stats for the 180 day period [1] indicate
  some changes are needed for cores who are no longer reviewing.
 
  First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
  neutron-core. Bob and Nachi have been core members for a while now.
  They have contributed to Neutron over the years in reviews, code and
  leading sub-teams. I'd like to thank them for all that they have done
  over the years. I'd also like to propose that should they start
  reviewing more going forward the core team looks to fast track them
  back into neutron-core. But for now, their review stats place them
  below the rest of the team for 180 days.
 
  As part of the changes, I'd also like to propose two new members to
  neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have
  been very active in reviews, meetings, and code for a while now. Henry
  lead the DB team which fixed Neutron DB migrations during Juno. Kevin
  has been actively working across all of Neutron, he's done some great
  work on security fixes and stability fixes in particular. Their
  comments in reviews are insightful and they have helped to onboard new
  reviewers and taken the time to work with people on their patches.
 
  Existing neutron cores, please vote +1/-1 for the addition of Henry
  and Kevin to the core team.
 
  Thanks!
  Kyle
 
  [1] http://stackalytics.com/report/contribution/neutron-group/180
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 --
 Nachi Ueno
 email:nati.u...@gmail.com
 twitter:http://twitter.com/nati

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Enabling vlan trunking on neutron port.

[Aaron Rosen]

Neutron doesn't allow you to send tagged traffic from the guest today
https://github.com/openstack/neutron/blob/master/neutron/plugins/openvswitch/agent/ovs_neutron_agent.py#L384


On Fri, Sep 19, 2014 at 7:01 AM, Parikshit Manur parikshit.ma...@citrix.com
 wrote:

  Hi All,

 I have a setup which has VM on flat provider network , and
 I want to reach VM on VLAN provider network. The packets are forwarded till
 veth pair and are getting dropped by br-int.



 Can neutron port be configured to allow vlan  trunking?



 Thanks,

 Parikshit Manur

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] keep old specs

[Aaron Rosen]

I agree as well. I think moving them to an unimplemented folder makes sense
and would be helpful in reviewing if one re-proposes a blueprint.

On Mon, Sep 15, 2014 at 7:20 AM, Russell Bryant rbry...@redhat.com wrote:

 On 09/15/2014 10:01 AM, Kevin Benton wrote:
  Some of the specs had a significant amount of detail and thought put
  into them. It seems like a waste to bury them in a git tree history.
 
  By having them in a place where external parties (e.g. operators) can
  easily find them, they could get more visibility and feedback for any
  future revisions. Just being able to see that a feature was previously
  designed out and approved can prevent a future person from wasting a
  bunch of time typing up a new spec for the same feature. Hardly anyone
  is going to search deleted specs from two cycles ago if it requires
  checking out a commit.
 
  Why just restrict the whole repo to being documentation of what went
  in?  If that's all the specs are for, why don't we just wait to create
  them until after the code merges?

 FWIW, I agree with you that it makes sense to keep them in a directory
 that makes it clear that they were not completed.

 There's a ton of useful info in them.  Even if they get re-proposed,
 it's still useful to see the difference in the proposal as it evolved
 between releases.

 --
 Russell Bryant

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][security-groups] Neutron default security groups

[Aaron Rosen]

Hi,

Inline:

On Tue, Sep 16, 2014 at 1:00 AM, Fawad Khaliq fa...@plumgrid.com wrote:

 Folks,

 I have had discussions with some folks individually about this but I would
 like bring this to a broader audience.

 I have been playing with security groups and I see the notion of 'default'
 security group seems to create some nuisance/issues.

 There are list of things I have noticed so far:

- Tenant for OpenStack services (normally named service/services) also
ends up having default security group.
- Port create operation ends up ensuring default security groups for
all the tenants as this completely seems out of the context of the tenant
the port operation takes place. (bug?)
- Race conditions where if system is stressed and Neutron tries to
ensure the first default security group and in parallel another call comes,
Neutron ends up trying to create multiple default security groups as the
checks for duplicate groups are invalidated as soon as the call make past a
certain point in code.

 Right this is a bug. We should catch this foreign key constraint exception
here and pass as the default security group was already created. We do
something similar here when ports are created as there is a similar race
for ip_allocation.


-
- API performance where orchestration chooses to spawn 1000 tenants
and we see unnecessary overhead


- For plugins that use RESTful proxy backends require the backend
systems to be up at the time neutron starts. [Minor, but affects some
packaging solutions]


This is probably always a requirement for neutron to work so I don't think
it's related.


 To summarize, is there a way to disable default security groups? Expected
 answer is no; can we introduce a way to disable it? If that does not make
 sense, should we go ahead and fix the issues around it?


I think we should fix these bugs you pointed out.


 I am sure some of you must have seen some of these issues and solved them
 already. Please do share how do tackle these issues?

 Thanks,
 Fawad Khaliq


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [congress] Jenkins failure

[Aaron Rosen]

You need to rebase again. The readme file changed before Jenkins got a
chance to test your patch.

On Monday, August 18, 2014, Rajdeep Dua rajdeep@gmail.com wrote:

 my branch already has the latest changes.
 it is not able to merge two rst files hence it failed


 On Tue, Aug 19, 2014 at 10:02 AM, Akash Gangil akashg1...@gmail.com
 javascript:_e(%7B%7D,'cvml','akashg1...@gmail.com'); wrote:

 This change was unable to be automatically merged with the current state
 of the repository. Please rebase your change and upload a new patchset.

 Rebase and commit?


  On Tue, Aug 19, 2014 at 12:10 AM, Rajdeep Dua rajdeep@gmail.com
 javascript:_e(%7B%7D,'cvml','rajdeep@gmail.com'); wrote:

  One of my CL - updation of  README.rst seems to be failing jenkins

 https://review.openstack.org/#/c/114896/1

 Any idea how to get this passed?

 Thanks
 Rajdeep

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 javascript:_e(%7B%7D,'cvml','OpenStack-dev@lists.openstack.org');
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Akash

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 javascript:_e(%7B%7D,'cvml','OpenStack-dev@lists.openstack.org');
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Sent from Gmail Mobile
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Is network ordering of vNICs guaranteed?

[Aaron Rosen]

Most guests generate this on first boot. I haven't looked into how newer
versions of ubuntu handle this though  I noticed in 14.04 this file doesn't
exist anymore but I figure it's doing it somewhere else.

Aaron


On Wed, Aug 13, 2014 at 9:03 PM, Jian Wen wenjia...@gmail.com wrote:

 Ordering of vNICs is not 100% guaranteed for the cloud images which are
 not shipped with
 /etc/udev/rules.d/70-persistent-net.rules.
 e.g. attaching a port and deattaching another port, then reboot the
 instance.


 2014-08-12 15:52 GMT+08:00 Aaron Rosen aaronoro...@gmail.com:

 This bug was true in grizzly and older (and was reintroduced in icehouse
 for a few days but was fixed before the nova icehouse shipped).

 Aaron


 On Mon, Aug 11, 2014 at 7:10 AM, CARVER, PAUL pc2...@att.com wrote:

 Armando M. [mailto:arma...@gmail.com] wrote:



 On 9 August 2014 10:16, Jay Pipes jaypi...@gmail.com wrote:

 Paul, does this friend of a friend have a reproduceable test

 script for this?



 We would also need to know the OpenStack release where this issue
 manifest

 itself. A number of bugs have been raised in the past around this type
 of

 issue, and the last fix I recall is this one:

 

 https://bugs.launchpad.net/nova/+bug/1300325

 

 It's possible that this might have regressed, though.



 The reason I called it friend of a friend is because I think the info

 has filtered through a series of people and is not firsthand observation.

 I'll ask them to track back to who actually observed the behavior, how

 long ago, and with what version.



 It could be a regression, or it could just be old info that people have

 continued to assume is true without realizing it was considered a bug

 all along and has been fixed.



 Thanks! The moment I first heard it my first reaction was that it was

 almost certainly a bug and had probably already been fixed.



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Best,

 Jian

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree

[Aaron Rosen]

Hi,

I've been thinking a good bit on this on the right way to move forward with
this and in general the right way new services should be added. Yesterday I
was working on a bug that was causing some problems in the openstack infra.
We tracked down the issue then I uploaded a patch for it. A little while
later after jenkins voted back a -1 so I started looking through the logs
to see what the source of the failure was (which was actually unrelated to
my patch). The random failure in the fwaas/vpn/l3-agent code which all
outputs to the same log file that contains many traces for every run even
successful ones. In one skim of this log file I was able to spot 4 [1]bugs
which shows  these new experimental services that we've added to neutron
have underlying problems (even though they've been in the tree for 2
releases+ now). This puts a huge strain on the whole openstack development
community as they are always recheck no bug'ing due to neutron failures.

If you look at the fwaas work that was done. This merged over two releases
ago and still does not have a complete API as there is no concept of where
enforcement should be done. Today, enforcement is done across all of a
tenant's routers making it more or less useless imho and we're just
carrying it along in the tree (and it's causing us problems)!

I think Mark's idea of neutron-incubator[2] is a great step forward to
improving neutron.

We can easily move these things out of the neutron source tree and we can
plug these things in here:
https://github.com/openstack/neutron/blob/master/etc/neutron.conf#L52
https://github.com/openstack/neutron/blob/master/etc/neutron.conf#L72
(GASP: We have seen shipped our own API's here to customers before we were
able to upstream them).

This allows us to decouple these experimental things from the neutron core
and allows us to release these components on their own making things more
modular/maintainable and stable (I think these things might even be better
long term living out of the tree).  Most importantly though it doesn't put
a burden on everyone else.


Best,

Aaron


[1]
http://paste.openstack.org/show/94664/
http://paste.openstack.org/show/94670/
http://paste.openstack.org/show/94663/
http://paste.openstack.org/show/94662/

[2] - https://etherpad.openstack.org/p/neutron-incubator






On Mon, Aug 11, 2014 at 9:58 AM, Robert Kukura kuk...@noironetworks.com
wrote:


 On 8/8/14, 6:28 PM, Salvatore Orlando wrote:

  If we want to keep everything the way it is, we have to change
 everything [1]

  This is pretty much how I felt after reading this proposal, and I felt
 that this quote, which Ivar will probably appreciate, was apt to the
 situation.
 Recent events have spurred a discussion about the need for a change in
 process. It is not uncommon indeed to believe that by fixing the process,
 things will inevitably change for better. While no-one argues that flaws in
 processes need to be fixed, no process change will ever change anything, in
 my opinion, unless it is aimed at spurring change in people as well.

  From what I understand, this proposal starts with the assumption that
 any new feature which is committed to Neutron (ie: has a blueprint
 approved), and is not a required neutron component should be considered as
 a preview. This is not different from the process, which, albeit more
 informally, has been adopted so far. Load Balancing, Firewall, VPN, have
 all been explicitly documented as experimental in their first release; I
 would argue that even if not experimental anymore, they may not be
 considered stable until their stability was proven by upstream QA with API
 and scenario tests - but this is not sanctioned anywhere currently, I think.

 Correct, this proposal is not so much a new process or change in process
 as a formalization of what we've already been doing, and a suggested
 adaptation to clarify the current expectations around stability of new APIs.


  According to this proposal, for preview features:
 - all the code would be moved to a preview package

 Yes.

   - Options will be marked as preview

 Yes.

   - URIs should be prefixed with preview

 That's what I suggested, but, as several people have pointed out, this
 does seem like its worth the cost of breaking the API compatibility just at
 the point when it is being declared stable. I'd like to withdraw this item.

   - CLIs will note the features are preview in their help strings

 Yes.

   - Documentation will explicitly state this feature is preview (I
 think we already mark them as experimental, frankly I don't think there are
 a lot of differences in terminology here)

 Yes. Again to me, failure is one likely outcome of an experiment. The
 term preview is intended to imply more of a commitment to quickly reach
 stability.

   - Database migrations will be in the main alembic path as usual

 Right.

   - CLI, Devstack and Heat support will be available

 Right, as appropriate for the feature.

   - Can be used by non-preview neutron 

Re: [openstack-dev] [Neutron] Is network ordering of vNICs guaranteed?

[Aaron Rosen]

This bug was true in grizzly and older (and was reintroduced in icehouse
for a few days but was fixed before the nova icehouse shipped).

Aaron


On Mon, Aug 11, 2014 at 7:10 AM, CARVER, PAUL pc2...@att.com wrote:

Armando M. [mailto:arma...@gmail.com] wrote:



 On 9 August 2014 10:16, Jay Pipes jaypi...@gmail.com wrote:

 Paul, does this friend of a friend have a reproduceable test

 script for this?



 We would also need to know the OpenStack release where this issue manifest

 itself. A number of bugs have been raised in the past around this type of

 issue, and the last fix I recall is this one:

 

 https://bugs.launchpad.net/nova/+bug/1300325

 

 It's possible that this might have regressed, though.



 The reason I called it friend of a friend is because I think the info

 has filtered through a series of people and is not firsthand observation.

 I'll ask them to track back to who actually observed the behavior, how

 long ago, and with what version.



 It could be a regression, or it could just be old info that people have

 continued to assume is true without realizing it was considered a bug

 all along and has been fixed.



 Thanks! The moment I first heard it my first reaction was that it was

 almost certainly a bug and had probably already been fixed.



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Congress] congress-server fails to start

[Aaron Rosen]

Hi Rajdeep,

I think the issue you're facing here is because you have a non-asci char in
your etc/congress.conf.sample file.  Could you try the following commands:

 mv congress/etc/congress.config.sample /tmp
 git checkout congress/etc/config.sample
 ./bin/congress-server --config-file etc/congress.conf.sample

p.s: you shouldn't run congress or probably any openstack component as root
fwiw.



On Mon, Aug 11, 2014 at 7:58 PM, Rajdeep Dua rajdeep@gmail.com wrote:

 Thanks, i was running older version of pip.

 All the requirements were installed successfully.

 Now getting the following error

 sudo ./bin/congress-server --config-file etc/congress.conf.sample
 2014-08-12 08:26:23.417 31129 CRITICAL congress.service [-] 'ascii' codec
 can't decode byte 0xf3 in position 1: ordinal not in range(128)



 On Tue, Aug 12, 2014 at 2:05 AM, Peter Balland pball...@vmware.com
 wrote:

  Hi Rajdeep,

  What version of pip are you running?  Please try installing the latest
 version (https://pip.pypa.io/en/latest/installing.html) and run ‘sudo
 pip install –r requirements.txt’.

  - Peter

   From: Rajdeep Dua rajdeep@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: Monday, August 11, 2014 at 11:27 AM
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [Congress] congress-server fails to start

  Hi All,
  command to start the congress-server fails

 $ ./bin/congress-server --config-file etc/congress.conf.sample

  Error :
 ImportError: No module named keystonemiddleware.auth_token

  Installing keystonemiddleware manually also fails

  $ sudo pip install keystonemiddleware

 Could not find a version that satisfies the requirement
 oslo.config=1.4.0.0a3 (from keystonemiddleware) (from versions: )
 No distributions matching the version for oslo.config=1.4.0.0a3 (from
 keystonemiddleware)

  Thanks
 Rajdeep


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

On Thu, Aug 7, 2014 at 12:08 PM, Kevin Benton blak...@gmail.com wrote:

 I mean't 'side stepping' why GBP allows for the comment you made
 previous, With the latter, a mapping driver could determine that
 communication between these two hosts can be prevented by using an ACL on a
 router or a switch, which doesn't violate the user's intent and buys a
 performance improvement and works with ports that don't support security
 groups..

 Neutron's current API is a logical abstraction and enforcement can be
 done however one chooses to implement it. I'm really trying to understand
 at the network level why GBP allows for these optimizations and performance
 improvements you talked about.

 You absolutely cannot enforce security groups on a firewall/router that
 sits at the boundary between networks. If you try, you are lying to the
 end-user because it's not enforced at the port level. The current neutron
 APIs force you to decide where things like that are implemented.


The current neutron API's are just logical abstractions. Where and how
things are actually enforced are 100% an implementation detail of a vendors
system.  Anyways, moving the discussion to the etherpad...



 The higher level abstractions give you the freedom to move the enforcement
 by allowing the expression of broad connectivity requirements.

Why are you bringing up logging connections?

 This was brought up as a feature proposal to FWaaS because this is a basic
 firewall feature missing from OpenStack. However, this does not preclude a
 FWaaS vendor from logging.

 Personally, I think one could easily write up a very short document
 probably less than one page with examples showing/exampling how the current
 neutron API works even without a much networking background.

 The difficulty of the API for establishing basic connectivity isn't really
 the problem. It's when you have to compose a bunch of requirements and make
 sure nothing is violating auditing and connectivity constraints that it
 becomes a problem. We are arguing about the levels of abstraction. You
 could also write up a short document explaining to novice programmers how
 to use C to read and write database entries to an sqlite database, but that
 doesn't mean it's the best level of abstraction for what the users are
 trying to accomplish.

 I'll let someone else explain the current GBP API because I'm not working
 on that. I'm just trying to convince you of the value of declarative
 network configuration.


 On Thu, Aug 7, 2014 at 12:02 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:




 On Thu, Aug 7, 2014 at 9:54 AM, Kevin Benton blak...@gmail.com wrote:

 You said you had no idea what group based policy was buying us so I
 tried to illustrate what the difference between declarative and imperative
 network configuration looks like. That's the major selling point of GBP so
 I'm not sure how that's 'side stepping' any points. It removes the need for
 the user to pick between implementation details like security
 groups/FWaaS/ACLs.


 I mean't 'side stepping' why GBP allows for the comment you made
 previous, With the latter, a mapping driver could determine that
 communication between these two hosts can be prevented by using an ACL on a
 router or a switch, which doesn't violate the user's intent and buys a
 performance improvement and works with ports that don't support security
 groups..

 Neutron's current API is a logical abstraction and enforcement can be
 done however one chooses to implement it. I'm really trying to understand
 at the network level why GBP allows for these optimizations and performance
 improvements you talked about.



 So are you saying that GBP allows someone to be able to configure an
 application that at the end of the day is equivalent  to
 networks/router/FWaaS rules without understanding networking concepts?

 It's one thing to understand the ports an application leverages and
 another to understand the differences between configuring VM firewalls,
 security groups, FWaaS, and router ACLs.


 Sure, but how does group based policy solve this. Security Groups and
 FWaaS are just different places of enforcement. Say I want different
 security enforcement on my router than on my instances. One still needs to
 know enough to tell group based policy this right?  They need to know
 enough that there are different enforcement points? How is doing this with
 Group based policy make it easier?



  I'm also curious how this GBP is really less error prone than the
 model we have today as it seems the user will basically have to tell
 neutron the same information about how he wants his networking to function.

 With GBP, the user just gives the desired end result (e.g. allow
 connectivity between endpoint groups via TCP port 22 with all connections
 logged). Without it, the user has to do the following:


 Why are you bringing up logging connections? Neutron has no concept of
 this at all today in it's code base. Is logging something related to GBP

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

Hi Kevin,

I feel as your latest response is completely side stepping the points we
have been trying to get to in the last series of emails. At the end of the
day I don't believe we are changing the laws of networking (or perhaps we
are?).  Thus I think it's important to actually get down to the networking
level to actually figure out why optimizations such as this one are enabled
via GBP and not the model we have:

With the latter, a mapping driver could determine that communication
between these two hosts can be prevented by using an ACL on a router or a
switch, which doesn't violate the user's intent and buys a performance
improvement and works with ports that don't support security groups.



On Wed, Aug 6, 2014 at 7:48 PM, Kevin Benton blak...@gmail.com wrote:

 Do you not see a difference between explicitly configuring networks, a
 router and FWaaS rules with logging and just stating that two groups of
 servers can only communicate via one TCP port with all connections logged?
 The first is very prone to errors for someone deploying an application
 without a strong networking background, and the latter is basically just
 stating the requirements and letting Neutron figure out how to implement
 it.

 So are you saying that GBP allows someone to be able to configure an
application that at the end of the day is equivalent  to
networks/router/FWaaS rules without understanding networking concepts? I'm
also curious how this GBP is really less error prone than the model we have
today as it seems the user will basically have to tell neutron the same
information about how he wants his networking to function.



 Just stating requirements becomes even more important when something like
 the logging requirement comes from someone other than the app deployer
 (e.g. a security team). In the above example, someone could set everything
 up using security groups; however, when the logging requirement came in
 from the security team, they would have to undo all of that work and
 replace it with something like FWaaS that can centrally log all of the
 connections.

 It's the difference between using puppet and bash scripts. Sure you can
 write a script that uses awk/sed to ensure that an ini file has a
 particular setting and then restart a service if the setting is changed,
 but it's much easier and less error prone to just write a puppet manifest
 that uses the INI module with a pointer to the file, the section name, the
 key, and the value with a notification to restart the service.



 On Wed, Aug 6, 2014 at 7:40 PM, Aaron Rosen aaronoro...@gmail.com wrote:


 On Wed, Aug 6, 2014 at 5:27 PM, Kevin Benton blak...@gmail.com wrote:

 Web tier can communicate with anything except for the DB.
 App tier can only communicate with Web and DB.
 DB can communicate with App.

 These high-level constraints can then be implemented as security groups
 like you showed, or network hardware ACLs like I had shown.
 But if you start with the security groups API, you are forcing it to be
 implemented there.


 I still have no idea what group based policy is buying us then. It seems
 to me that the key point we've identified going backing and forth here is
 the difference between the current model and the GBP model is that GBP
 constricts topology which allows us to write these types of enforcement
 rules. The reason we want this is because it yields performance
 optimizations (for some reason, which I don't think we've gotten into).
 Would you agree this is accurate?

 Honestly, I know a lot of work has been put into this. I haven't said I'm
 for or against it either. I'm really just trying to understand what is the
 motivation for this and why does it make neutron better.

 Best,

 Aaron




 On Wed, Aug 6, 2014 at 6:06 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:




 On Wed, Aug 6, 2014 at 4:46 PM, Kevin Benton blak...@gmail.com wrote:

 That's the point. By using security groups, you are forcing a certain
 kind of enforcement that must be honored and might not be necessary if the
 original intent was just to isolate between groups. In the example you
 gave, it cannot be implemented on the router without violating the
 constraints of the security group.


 Hi Kevin,

 Mind proposing an alternative example then. The only way I can see this
 claim to be made is because Group Based policy is actually limiting what a
 tenants desired topology can be?

 Thanks,

 Aaron



  On Wed, Aug 6, 2014 at 5:39 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:




 On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton blak...@gmail.com
 wrote:

 Given this information I don't see any reason why the backend
 system couldn't do enforcement at the logical router and if it did so
 neither parties would know.

 With security groups you are specifying that nothing can contact
 these devices on those ports unless they come from the allowed IP
 addresses. If you tried to enforce this at the router you would be
 violating that specification because devices

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

) by defining a Contract Scope which references the target
Contract.
Selector: A Contract Scope can define additional constraints around
choosing the matching provider or consumer EPGs for a Contract via a
Selector.
Policy Labels: These are labels contained within a namespace hierarchy and
used to define Capability and Role tags used in Filters.
Bridge Domain: Used to define a L2 boundary and impose additional
constraints (such as no broadcast) within that L2 boundary.
Routing Domain: Used to define a non-overlapping IP address space.




 IIRC one of the early nova parity requests was an API to automagically
 setup a neutron network and router so no extra work would be required to
 get instances connected to the Internet. That wasn't requested because
 people thought neutron networks were too easy to setup already. :-)


I think the confusion why that comment was made is probably because the
nova-networks model doesn't have a concept of routers. Neutron can operate
in the same way though with flat and provider networks. Either way one
could easily write a nova-binding to the command they used previously to
create a router and uplink it hiding the fact that there is a router there.



 On Thu, Aug 7, 2014 at 9:10 AM, Aaron Rosen aaronoro...@gmail.com wrote:

 Hi Kevin,

 I feel as your latest response is completely side stepping the points we
 have been trying to get to in the last series of emails. At the end of the
 day I don't believe we are changing the laws of networking (or perhaps we
 are?).  Thus I think it's important to actually get down to the networking
 level to actually figure out why optimizations such as this one are enabled
 via GBP and not the model we have:


 With the latter, a mapping driver could determine that communication
 between these two hosts can be prevented by using an ACL on a router or a
 switch, which doesn't violate the user's intent and buys a performance
 improvement and works with ports that don't support security groups.



 On Wed, Aug 6, 2014 at 7:48 PM, Kevin Benton blak...@gmail.com wrote:

 Do you not see a difference between explicitly configuring networks, a
 router and FWaaS rules with logging and just stating that two groups of
 servers can only communicate via one TCP port with all connections logged?
 The first is very prone to errors for someone deploying an application
 without a strong networking background, and the latter is basically just
 stating the requirements and letting Neutron figure out how to implement
 it.

 So are you saying that GBP allows someone to be able to configure an
 application that at the end of the day is equivalent  to
 networks/router/FWaaS rules without understanding networking concepts? I'm
 also curious how this GBP is really less error prone than the model we have
 today as it seems the user will basically have to tell neutron the same
 information about how he wants his networking to function.



 Just stating requirements becomes even more important when something
 like the logging requirement comes from someone other than the app deployer
 (e.g. a security team). In the above example, someone could set everything
 up using security groups; however, when the logging requirement came in
 from the security team, they would have to undo all of that work and
 replace it with something like FWaaS that can centrally log all of the
 connections.

 It's the difference between using puppet and bash scripts. Sure you can
 write a script that uses awk/sed to ensure that an ini file has a
 particular setting and then restart a service if the setting is changed,
 but it's much easier and less error prone to just write a puppet manifest
 that uses the INI module with a pointer to the file, the section name, the
 key, and the value with a notification to restart the service.



 On Wed, Aug 6, 2014 at 7:40 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:


 On Wed, Aug 6, 2014 at 5:27 PM, Kevin Benton blak...@gmail.com wrote:

 Web tier can communicate with anything except for the DB.
 App tier can only communicate with Web and DB.
 DB can communicate with App.

 These high-level constraints can then be implemented as security
 groups like you showed, or network hardware ACLs like I had shown.
 But if you start with the security groups API, you are forcing it to
 be implemented there.


 I still have no idea what group based policy is buying us then. It
 seems to me that the key point we've identified going backing and forth
 here is the difference between the current model and the GBP model is that
 GBP constricts topology which allows us to write these types of enforcement
 rules. The reason we want this is because it yields performance
 optimizations (for some reason, which I don't think we've gotten into).
 Would you agree this is accurate?

 Honestly, I know a lot of work has been put into this. I haven't said
 I'm for or against it either. I'm really just trying to understand what is
 the motivation for this and why does it make neutron better

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

On Tue, Aug 5, 2014 at 11:18 PM, Gary Kotton gkot...@vmware.com wrote:



 On 8/5/14, 8:53 PM, Russell Bryant rbry...@redhat.com wrote:

 On 08/05/2014 01:23 PM, Gary Kotton wrote:
  Ok, thanks for the clarification. This means that it will not be done
  automagically as it is today ­ the tenant will need to create a Neutron
  port and then pass that through.
 
 FWIW, that's the direction we've wanted to move in Nova anyway.  We'd
 like to get rid of automatic port creation, but can't do that in the
 current stable API.

 Can you elaborate on what you mean here? What are the issues with port
 creation?


Having nova-compute create ports for neutron is problematic if timeouts
occur between nova and neutron as you have to garbage collect neutron ports
in nova to cleanup (which was the cause of several bug in the cache handing
allowing ports to leak into the info_cache in nova).  Pushing this out to
the tenant is less orchestration nova has to do.



 --
 Russell Bryant
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton gkot...@vmware.com wrote:



   From: Aaron Rosen aaronoro...@gmail.com
 Reply-To: OpenStack List openstack-dev@lists.openstack.org
 Date: Wednesday, August 6, 2014 at 10:09 AM

 To: OpenStack List openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
 forward


 On Tue, Aug 5, 2014 at 11:18 PM, Gary Kotton gkot...@vmware.com wrote:



 On 8/5/14, 8:53 PM, Russell Bryant rbry...@redhat.com wrote:

 On 08/05/2014 01:23 PM, Gary Kotton wrote:
  Ok, thanks for the clarification. This means that it will not be done
  automagically as it is today ­ the tenant will need to create a Neutron
  port and then pass that through.
 
 FWIW, that's the direction we've wanted to move in Nova anyway.  We'd
 like to get rid of automatic port creation, but can't do that in the
 current stable API.

  Can you elaborate on what you mean here? What are the issues with port
 creation?


 Having nova-compute create ports for neutron is problematic if timeouts
 occur between nova and neutron as you have to garbage collect neutron ports
 in nova to cleanup (which was the cause of several bug in the cache handing
 allowing ports to leak into the info_cache in nova).  Pushing this out to
 the tenant is less orchestration nova has to do.

  [gary] my take on this is that we should allocate this via the n-api and
 not via the nova compute (which is far too late in the process. But that is
 another discussion :)


I agree, I had actually proposed this here:
https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port
 :),   though there are some issues we need to solve in neutron first --
allowing the mac_address on the port to be updated in neutron. This is
required for bare metal support as when the port is created we don't know
which physical mac will need to be mapped to the port.


   
 --
 Russell Bryant
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

As a cloud admin one needs to make sure the endpoints in keystone
publicurl, internalurl and adminurl all map to the right places in the
infrastructure. As a cloud user (for example when using the HP/RAX public
cloud that has multiple regions/endpoints) a user needs to be aware of
which region maps to which endpoint.


On Wed, Aug 6, 2014 at 9:56 AM, Kevin Benton blak...@gmail.com wrote:

 It sounds to me like you are describing how a developer uses Keystone, not
 a user. My reference to 'application deployer' was to someone trying to run
 something like a mail server on an openstack cloud.
 On Aug 6, 2014 7:07 AM, Russell Bryant rbry...@redhat.com wrote:

 On 08/05/2014 06:13 PM, Kevin Benton wrote:
  That makes sense. It's not quite a fair analogy though to compare to
  reintroducing projects or tenants because Keystone endpoints aren't
  'user-facing' so to speak. i.e. a regular user (application deployer,
  instance operator, etc) should never have to see or understand the
  purpose of a Keystone endpoint.

 An end user that is consuming any OpenStack API absolutely must
 understand endpoints in the service catalog.  The entire purpose of the
 catalog is so that an application only needs to know the API endpoint to
 keystone and is then able to discover where the rest of the APIs are
 located.  They are very much user facing, IMO.

 --
 Russell Bryant

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

Hi,

I've made my way through the group based policy code and blueprints and I'd
like ask several questions about it.  My first question really is what is
the advantage that the new proposed group based policy model buys us?


Bobs says, The group-based policy BP approved for Juno addresses the
 critical need for a more usable, declarative, intent-based interface for
 cloud application developers and deployers, that can co-exist with
 Neutron's current networking-hardware-oriented API and work nicely with all
 existing core plugins. Additionally, we believe that this declarative
 approach is what is needed to properly integrate advanced services into
 Neutron, and will go a long way towards resolving the difficulties so far
 trying to integrate LBaaS, FWaaS, and VPNaaS APIs into the current Neutron
 model.

My problem with the current blueprint and that comment above is it does not
provide any evidence or data of where the current neutron abstractions
(ports/networks/subnets/routers) provide difficulties and what benefit this
new model will provide.

In the current proposed implementation of group policy, it's implementation
maps onto the existing neutron primitives and the neutron back end(s)
remains unchanged. Because of this one can map the new abstractions onto
the previous ones so I'm curious why we want to move this complexity into
neutron and not have it done externally similarly to how heat works or a
client that abstracts this complexity on it's own end.

From the group-based policy blueprint that was submitted [1]:


The current Neutron model of networks, ports, subnets, routers, and security
 groups provides the necessary building blocks to build a logical network
 topology for connectivity. However, it does not provide the right level
 of abstraction for an application administrator who understands the
 application's details (like application port numbers), but not the
 infrastructure details likes networks and routes.

It looks to me that application administrators still need to understand
network primitives as the concept of networks/ports/routers are still
present though just carrying a different name. For example, in
ENDPOINT_GROUPS there is an attribute l2_policy_id which maps to something
that you use to describe a l2_network and contains an attribute
l3_policy_id which is used to describe an L3 network. This looks similar to
the abstraction we have today where a l2_policy (network) then can have
multiple l3_policies (subnets) mapping to it.  Because of this I'm curious
how the GBP abstraction really provides a different level of abstraction
for application administrators.


 Not only that, the current
 abstraction puts the burden of maintaining the consistency of the network
 topology on the user. The lack of application developer/administrator
 focussed
 abstractions supported by a declarative model make it hard for those users
 to consume Neutron as a connectivity layer.

What is the problem in the current abstraction that puts a burden of
maintaining the consistency of networking topology on users? It seems to me
that the complexity of having to know about topology should be abstracted
at the client layer if desired (and neutron should expose the basic
building blocks for networking). For example, Horizon/Heat or the CLI could
hide the requirement of topology by automatically creating a GROUP  (which
is a network+subnet on a router uplinked to an external network)
simplifying this need for the tenant to understand topology. In addition,
topology still seems to be present in the group policy model proposed just
in a different way as I see it.

From the proposed change section the following is stated:


This proposal suggests a model that allows application administrators to
 express their networking requirements using group and policy abstractions,
 with
 the specifics of policy enforcement and implementation left to the
 underlying
 policy driver. The main advantage of the extensions described in this
 blueprint
 is that they allow for an application-centric interface to Neutron that
 complements the existing network-centric interface.


How is the Application-centric interface complementary to the
network-centric interface?  Is the intention that one would use both
interfaces at one once?

More specifically the new abstractions will achieve the following:
 * Show clear separation of concerns between application and infrastructure
 administrator.


I'm not quite sure I understand this point, how is this different than what
we have today?


 - The application administrator can then deal with a higher level
 abstraction
 that does not concern itself with networking specifics like
 networks/routers/etc.


It seems like the proposed abstraction still requires one to concern
themselves with networking specifics (l2_policies, l3_policies).  I'd
really like to see more evidence backing this. Now they have to deal with
specifies like: Endpoint, Endpoint Group, Contract, Policy Rule,

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

Hi Ryan,


On Wed, Aug 6, 2014 at 11:55 AM, Ryan Moats rmo...@us.ibm.com wrote:

 Jay Pipes jaypi...@gmail.com wrote on 08/06/2014 01:04:41 PM:

 [snip]


  AFAICT, there is nothing that can be done with the GBP API that cannot
  be done with the low-level regular Neutron API.

 I'll take you up on that, Jay :)

 How exactly do I specify behavior between two collections of ports
 residing in the same IP subnet (an example of this is a bump-in-the-wire
 network appliance).

 Would you mind explaining what behavior you want between the two
collection of ports?


 I've looked around regular Neutron and all I've come up with so far is:
  (1) use security groups on the ports
  (2) set allow_overlapping_ips to true, set up two networks with identical
 CIDR block subnets and disjoint allocation pools and put a vRouter between
 them.

 Now #1 only works for basic allow/deny access and adds the complexity of
 needing to specify per-IP address security rules, which means you need the
 ports to have IP addresses already and then manually add them into the
 security groups, which doesn't seem particularly very orchestration
 friendly.


I believe the referential security group rules solve this problem (unless
I'm not understanding):

neutron security-group-create group1
neutron security-group-create group2

# allow members of group1 to ssh into group2 (but not the other way around):
neutron security-group-rule-create --direction ingress --port-range-min 22
--port-range-max 22 --protocol TCP --remote-group-id group1 group2

# allow members of group2 to be able to access TCP 80 from members of
group1 (but not the other way around):
neutron security-group-rule-create --direction ingress --port-range-min 80
--port-range-max 80 --protocol TCP --remote-group-id group2 group1

# Now when you create ports just place these in the desired security groups
and neutron will automatically handle this orchestration for you (and you
don't have to deal with ip_addresses and updates).

neutron port-create --security-groups group1 network1
neutron port-create --security-groups group2 network1



 Now #2 handles both allow/deny access as well as provides a potential
 attachment point for other behaviors, *but* you have to know to set up the
 disjoint allocation pools, and your depending on your drivers to handle the
 case of a router that isn't really a router (i.e. it's got two interfaces
 in the same subnet, possibly with the same address (unless you thought of
 that when you set things up)).


Are you talking about the firewall as a service stuff here?


 You can say that both of these are *possible*, but they both look more
 complex to me than just having two groups of ports and specifying a policy
 between them.


Would you mind proposing how this is done in the Group policy api? From
what I can tell in the new proposed api you'd need to map both of these
groups to different endpoints i.e networks.



 Ryan Moats


 Best,

Aaron

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

Hi Kevin,

I think we should keep these threads together as we need to understand the
benefit collectively before we move forward with what to do.

Aaron


On Wed, Aug 6, 2014 at 12:03 PM, Kevin Benton blak...@gmail.com wrote:

 Hi Aaron,

 These are good questions, but can we move this to a different thread
 labeled what is the point of group policy?

 I don't want to derail this one again and we should stick to Salvatore's
 options about the way to move forward with these code changes.
 On Aug 6, 2014 12:42 PM, Aaron Rosen aaronoro...@gmail.com wrote:

 Hi,

 I've made my way through the group based policy code and blueprints and
 I'd like ask several questions about it.  My first question really is what
 is the advantage that the new proposed group based policy model buys us?


 Bobs says, The group-based policy BP approved for Juno addresses the
 critical need for a more usable, declarative, intent-based interface for
 cloud application developers and deployers, that can co-exist with
 Neutron's current networking-hardware-oriented API and work nicely with all
 existing core plugins. Additionally, we believe that this declarative
 approach is what is needed to properly integrate advanced services into
 Neutron, and will go a long way towards resolving the difficulties so far
 trying to integrate LBaaS, FWaaS, and VPNaaS APIs into the current Neutron
 model.

 My problem with the current blueprint and that comment above is it does
 not provide any evidence or data of where the current neutron abstractions
 (ports/networks/subnets/routers) provide difficulties and what benefit this
 new model will provide.

 In the current proposed implementation of group policy, it's
 implementation maps onto the existing neutron primitives and the neutron
 back end(s) remains unchanged. Because of this one can map the new
 abstractions onto the previous ones so I'm curious why we want to move this
 complexity into neutron and not have it done externally similarly to how
 heat works or a client that abstracts this complexity on it's own end.

 From the group-based policy blueprint that was submitted [1]:


 The current Neutron model of networks, ports, subnets, routers, and
 security
 groups provides the necessary building blocks to build a logical network
 topology for connectivity. However, it does not provide the right level
 of abstraction for an application administrator who understands the
 application's details (like application port numbers), but not the
 infrastructure details likes networks and routes.

 It looks to me that application administrators still need to understand
 network primitives as the concept of networks/ports/routers are still
 present though just carrying a different name. For example, in
 ENDPOINT_GROUPS there is an attribute l2_policy_id which maps to something
 that you use to describe a l2_network and contains an attribute
 l3_policy_id which is used to describe an L3 network. This looks similar to
 the abstraction we have today where a l2_policy (network) then can have
 multiple l3_policies (subnets) mapping to it.  Because of this I'm curious
 how the GBP abstraction really provides a different level of abstraction
 for application administrators.


  Not only that, the current
 abstraction puts the burden of maintaining the consistency of the network
 topology on the user. The lack of application developer/administrator
 focussed
 abstractions supported by a declarative model make it hard for those
 users
 to consume Neutron as a connectivity layer.

 What is the problem in the current abstraction that puts a burden of
 maintaining the consistency of networking topology on users? It seems to me
 that the complexity of having to know about topology should be abstracted
 at the client layer if desired (and neutron should expose the basic
 building blocks for networking). For example, Horizon/Heat or the CLI could
 hide the requirement of topology by automatically creating a GROUP  (which
 is a network+subnet on a router uplinked to an external network)
 simplifying this need for the tenant to understand topology. In addition,
 topology still seems to be present in the group policy model proposed just
 in a different way as I see it.

 From the proposed change section the following is stated:


 This proposal suggests a model that allows application administrators to
 express their networking requirements using group and policy
 abstractions, with
 the specifics of policy enforcement and implementation left to the
 underlying
 policy driver. The main advantage of the extensions described in this
 blueprint
 is that they allow for an application-centric interface to Neutron that
 complements the existing network-centric interface.


 How is the Application-centric interface complementary to the
 network-centric interface?  Is the intention that one would use both
 interfaces at one once?

  More specifically the new abstractions will achieve the following:
 * Show clear separation

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

On Wed, Aug 6, 2014 at 12:25 PM, Ivar Lazzaro ivarlazz...@gmail.com wrote:

 Hi Aaron,

 Please note that the user using the current reference implementation
 doesn't need to create Networks, Ports, or anything else. As a matter of
 fact, the mapping is done implicitly.



The user still needs to create an endpointgroup. What is being done
implicitly here? I fail to see the difference.



 Also, I agree with Kevin when he says that this is a whole different
 discussion.

 Thanks,
 Ivar.


 On Wed, Aug 6, 2014 at 9:12 PM, Aaron Rosen aaronoro...@gmail.com wrote:

 Hi Ryan,


 On Wed, Aug 6, 2014 at 11:55 AM, Ryan Moats rmo...@us.ibm.com wrote:

 Jay Pipes jaypi...@gmail.com wrote on 08/06/2014 01:04:41 PM:

 [snip]


  AFAICT, there is nothing that can be done with the GBP API that cannot
  be done with the low-level regular Neutron API.

 I'll take you up on that, Jay :)

 How exactly do I specify behavior between two collections of ports
 residing in the same IP subnet (an example of this is a bump-in-the-wire
 network appliance).

 Would you mind explaining what behavior you want between the two
 collection of ports?


  I've looked around regular Neutron and all I've come up with so far is:
  (1) use security groups on the ports
  (2) set allow_overlapping_ips to true, set up two networks with
 identical CIDR block subnets and disjoint allocation pools and put a
 vRouter between them.

 Now #1 only works for basic allow/deny access and adds the complexity of
 needing to specify per-IP address security rules, which means you need the
 ports to have IP addresses already and then manually add them into the
 security groups, which doesn't seem particularly very orchestration
 friendly.


 I believe the referential security group rules solve this problem (unless
 I'm not understanding):

 neutron security-group-create group1
 neutron security-group-create group2

 # allow members of group1 to ssh into group2 (but not the other way
 around):
 neutron security-group-rule-create --direction ingress --port-range-min
 22 --port-range-max 22 --protocol TCP --remote-group-id group1 group2

 # allow members of group2 to be able to access TCP 80 from members of
 group1 (but not the other way around):
 neutron security-group-rule-create --direction ingress --port-range-min
 80 --port-range-max 80 --protocol TCP --remote-group-id group2 group1

 # Now when you create ports just place these in the desired security
 groups and neutron will automatically handle this orchestration for you
 (and you don't have to deal with ip_addresses and updates).

 neutron port-create --security-groups group1 network1
 neutron port-create --security-groups group2 network1



 Now #2 handles both allow/deny access as well as provides a potential
 attachment point for other behaviors, *but* you have to know to set up the
 disjoint allocation pools, and your depending on your drivers to handle the
 case of a router that isn't really a router (i.e. it's got two interfaces
 in the same subnet, possibly with the same address (unless you thought of
 that when you set things up)).


 Are you talking about the firewall as a service stuff here?


  You can say that both of these are *possible*, but they both look more
 complex to me than just having two groups of ports and specifying a policy
 between them.


  Would you mind proposing how this is done in the Group policy api? From
 what I can tell in the new proposed api you'd need to map both of these
 groups to different endpoints i.e networks.



 Ryan Moats


 Best,

 Aaron

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

On Wed, Aug 6, 2014 at 12:45 PM, Ryan Moats rmo...@us.ibm.com wrote:

 Aaron Rosen aaronoro...@gmail.com wrote on 08/06/2014 02:12:05 PM:

  From: Aaron Rosen aaronoro...@gmail.com

  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org
  Date: 08/06/2014 02:12 PM
  Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy
  and the way forward
 
  Hi Ryan,

 
  On Wed, Aug 6, 2014 at 11:55 AM, Ryan Moats rmo...@us.ibm.com wrote:
  Jay Pipes jaypi...@gmail.com wrote on 08/06/2014 01:04:41 PM:
 
  [snip]
 
 
   AFAICT, there is nothing that can be done with the GBP API that cannot
   be done with the low-level regular Neutron API.

  I'll take you up on that, Jay :)
 
  How exactly do I specify behavior between two collections of ports
  residing in the same IP subnet (an example of this is a bump-in-the-
  wire network appliance).

  Would you mind explaining what behavior you want between the two
  collection of ports?

 That's the point - I want a framework that will work regardless of the
 specifics of the behavior later on.


  I've looked around regular Neutron and all I've come up with so far is:
  (1) use security groups on the ports
  (2) set allow_overlapping_ips to true, set up two networks with
  identical CIDR block subnets and disjoint allocation pools and put a
  vRouter between them.
 
  Now #1 only works for basic allow/deny access and adds the
  complexity of needing to specify per-IP address security rules,
  which means you need the ports to have IP addresses already and then
  manually add them into the security groups, which doesn't seem
  particularly very orchestration friendly.
 
  I believe the referential security group rules solve this problem
  (unless I'm not understanding):
 
  neutron security-group-create group1
  neutron security-group-create group2
 
  # allow members of group1 to ssh into group2 (but not the other way
 around):
  neutron security-group-rule-create --direction ingress --port-range-
  min 22 --port-range-max 22 --protocol TCP --remote-group-id group1 group2
 
  # allow members of group2 to be able to access TCP 80 from members
  of group1 (but not the other way around):
  neutron security-group-rule-create --direction ingress --port-range-
  min 80 --port-range-max 80 --protocol TCP --remote-group-id group2 group1
 
  # Now when you create ports just place these in the desired security
  groups and neutron will automatically handle this orchestration for
  you (and you don't have to deal with ip_addresses and updates).
 
  neutron port-create --security-groups group1 network1
  neutron port-create --security-groups group2 network1

 While those rule instances aren't particularly interesting, I concede that
 security groups can handle allow/deny. However, allow/deny is the least
 interesting part of the problem :)


  Now #2 handles both allow/deny access as well as provides a
  potential attachment point for other behaviors, *but* you have to
  know to set up the disjoint allocation pools, and your depending on
  your drivers to handle the case of a router that isn't really a
  router (i.e. it's got two interfaces in the same subnet, possibly
  with the same address (unless you thought of that when you set things
 up)).

  Are you talking about the firewall as a service stuff here?

 No, I'm being more general than any of the curret *aaS items, I'm thinking
 of the general service insertion case.


  You can say that both of these are *possible*, but they both look
  more complex to me than just having two groups of ports and
  specifying a policy between them.
 
  Would you mind proposing how this is done in the Group policy api?
  From what I can tell in the new proposed api you'd need to map both
  of these groups to different endpoints i.e networks.

 Note: I'm not going to use the pure group policy API as I have been a fan
 of the
 2-group approach from day 1, I'm going to use the commands as stated in
 the patch set, and I'm going to assume (dangerous I know) that I can
 specify endpoint-group on port create

 neutron grouppolicy-endpoint-group-create group1
 neutron grouppolicy-endpoint-group-create group2


 neutron port-create --endpoint-group group1 network1
 neutron port-create --endpoint-group group2 network1


Sorry, I don't follow what this port-create command does? Here ---
https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g12c5a79d7_4078
 --- shows that endpoint-groups map to networks so i'm confused why
network1 is coming into play here?



 neutron grouppolicy-policy-action-create action
 neutron grouppolicy-policy-classifier-create classifier
 neutron grouppolicy-policy-rule-create --action action --classifier
 classifer rule
 neutron policy-apply rule group1 group2


Mind mapping this to my example so we can see how to achieve the same thing
in group policy (with protocols and all)?  Looks like you would also need
to specify

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com wrote:

 I believe the referential security group rules solve this problem
 (unless I'm not understanding):

 I think the disconnect is that you are comparing the way to current
 mapping driver implements things for the reference implementation with the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must support
 security groups and there is nowhere except for the firewall rules on that
 port to implement it without violating the user's expectation. With the
 latter, a mapping driver could determine that communication between these
 two hosts can be prevented by using an ACL on a router or a switch, which
 doesn't violate the user's intent and buys a performance improvement and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


Hi Kevin,

Interesting points. Though, let me ask this. Why do we need to move to a
declarative API abstraction in neutron in order to perform this
optimization on the backend? For example, In the current neutron model say
we want to create a port with a security group attached to it called web
that allows TCP:80 in and members who are in a security group called
database. From this mapping I fail to see how it's really any different
from the declarative model? The ports in neutron are logical abstractions
and the backend system could be implemented in order to determine that the
communication between these two hosts could be prevented by using an ACL on
a router or switch as well.

Best,

Aaron



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

On Wed, Aug 6, 2014 at 3:35 PM, Kevin Benton blak...@gmail.com wrote:

 By working at the port level you have already eliminated your ability to
 implement the filtering at different components of the network. They now
 need to be implemented in stateful rules at the port level and the device
 has to support security groups.



Lets take this example where we setup a 2 tier app with web-servers and
db-servers that are connected on two different networks attached to a
router. We add a security group rules such that web-servers can talk to
db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers from
anywhere.

neutron net-create web_net
neutron subnet-create --name web_subnet web_net 10.0.0.0/24

neutron net-create db_net
neutron subnet-create --name db_subnet db_net 10.2.0.0/24

neutron router-create myrouter
neutron router-interface-add myrouter web_subnet
neutron router-interface-add myrouter db_subnet

neutron security-group-create  web-servers;
neutron security-group-create db-servers;

# add rule to allow web members to talk to the db-servers on TCP 3306 for
their db connection;
neutron security-group-rule-create --protocol TCP --port-range-min 3306
--port-range-max 3306 --remote-group-id web-servers db-servers

# add rule to allow TCP 80 into the web-server sg
neutron security-group-rule-create --protocol TCP --port-range-min 80
--port-range-max 80 web-servers db-servers

# create some ports with desired security profiles.
neutron port-create  --security-group web-servers web_net
neutron port-create  --security-group web-servers web_net

neutron port-create  --security-group db-servers db_net
neutron port-create  --security-group db-servers db_net


Now to your point:

By working at the port level you have already eliminated your ability to
 implement the filtering at different components of the network. They now
 need to be implemented in stateful rules at the port level and the device
 has to support security groups.


Given this information I don't see any reason why the backend system
couldn't do enforcement at the logical router and if it did so neither
parties would know. The backend system should have the full graph of
everything and be able to do enforcement optimizations where ever it likes.

btw: I say the enforcement could be done on the logical router though the
backend system could also do this on the physical fabic as well if it
wanted to as it should also know that graph. No?



 On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen aaronoro...@gmail.com wrote:




 On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com wrote:

 I believe the referential security group rules solve this problem
 (unless I'm not understanding):

 I think the disconnect is that you are comparing the way to current
 mapping driver implements things for the reference implementation with the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must support
 security groups and there is nowhere except for the firewall rules on that
 port to implement it without violating the user's expectation. With the
 latter, a mapping driver could determine that communication between these
 two hosts can be prevented by using an ACL on a router or a switch, which
 doesn't violate the user's intent and buys a performance improvement and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


 Hi Kevin,

 Interesting points. Though, let me ask this. Why do we need to move to a
 declarative API abstraction in neutron in order to perform this
 optimization on the backend? For example, In the current neutron model say
 we want to create a port with a security group attached to it called web
 that allows TCP:80 in and members who are in a security group called
 database. From this mapping I fail to see how it's really any different
 from the declarative model? The ports in neutron are logical abstractions
 and the backend system could be implemented in order to determine that the
 communication between these two hosts could be prevented by using an ACL on
 a router or switch as well.

 Best,

 Aaron



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton blak...@gmail.com wrote:

 Given this information I don't see any reason why the backend system
 couldn't do enforcement at the logical router and if it did so neither
 parties would know.

 With security groups you are specifying that nothing can contact these
 devices on those ports unless they come from the allowed IP addresses. If
 you tried to enforce this at the router you would be violating that
 specification because devices in the same subnet would be able to
 communicate on those blocked ports.


Sure, though this is a problem of where you are doing your enforcement. If
the backend system chooses to implement this optimization in this fashion
(which was the example you gave previously [1]). Then, if the topology
changes, i.e adding a port to the same network with conflicting security
group rules, the backend system can no longer optimize in this same fashion
at the router level and a more fine grain filtering will need to be done.
How would this be any different with group based policy?


[1] - With the latter, a mapping driver could determine that communication
between these two hosts can be prevented by using an ACL on a router or a
switch, which doesn't violate the user's intent and buys a performance
improvement and works with ports that don't support security groups.

states





 On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen aaronoro...@gmail.com wrote:


 On Wed, Aug 6, 2014 at 3:35 PM, Kevin Benton blak...@gmail.com wrote:

 By working at the port level you have already eliminated your ability to
 implement the filtering at different components of the network. They now
 need to be implemented in stateful rules at the port level and the device
 has to support security groups.



 Lets take this example where we setup a 2 tier app with web-servers and
 db-servers that are connected on two different networks attached to a
 router. We add a security group rules such that web-servers can talk to
 db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers from
 anywhere.

 neutron net-create web_net
 neutron subnet-create --name web_subnet web_net 10.0.0.0/24

 neutron net-create db_net
 neutron subnet-create --name db_subnet db_net 10.2.0.0/24

 neutron router-create myrouter
 neutron router-interface-add myrouter web_subnet
 neutron router-interface-add myrouter db_subnet

 neutron security-group-create  web-servers;
 neutron security-group-create db-servers;

 # add rule to allow web members to talk to the db-servers on TCP 3306 for
 their db connection;
 neutron security-group-rule-create --protocol TCP --port-range-min 3306
 --port-range-max 3306 --remote-group-id web-servers db-servers

 # add rule to allow TCP 80 into the web-server sg
 neutron security-group-rule-create --protocol TCP --port-range-min 80
 --port-range-max 80 web-servers db-servers

 # create some ports with desired security profiles.
 neutron port-create  --security-group web-servers web_net
 neutron port-create  --security-group web-servers web_net

 neutron port-create  --security-group db-servers db_net
 neutron port-create  --security-group db-servers db_net


 Now to your point:

 By working at the port level you have already eliminated your ability to
 implement the filtering at different components of the network. They now
 need to be implemented in stateful rules at the port level and the device
 has to support security groups.


 Given this information I don't see any reason why the backend system
 couldn't do enforcement at the logical router and if it did so neither
 parties would know. The backend system should have the full graph of
 everything and be able to do enforcement optimizations where ever it likes.

 btw: I say the enforcement could be done on the logical router though the
 backend system could also do this on the physical fabic as well if it
 wanted to as it should also know that graph. No?



 On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:




 On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com
 wrote:

 I believe the referential security group rules solve this problem
 (unless I'm not understanding):

 I think the disconnect is that you are comparing the way to current
 mapping driver implements things for the reference implementation with the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must 
 support
 security groups and there is nowhere except for the firewall rules on that
 port to implement

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

[Moving my reply to the correct thread as someone changed the subject line.]


On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton blak...@gmail.com wrote:

 Given this information I don't see any reason why the backend system
 couldn't do enforcement at the logical router and if it did so neither
 parties would know.

 With security groups you are specifying that nothing can contact these
 devices on those ports unless they come from the allowed IP addresses. If
 you tried to enforce this at the router you would be violating that
 specification because devices in the same subnet would be able to
 communicate on those blocked ports.


Sure, though this is a problem of where you are doing your enforcement. If
the backend system chooses to implement this optimization in this fashion
(which was the example you gave previously [1]). Then, if the topology
changes, i.e adding a port to the same network with conflicting security
group rules, the backend system can no longer optimize in this same fashion
at the router level and a more fine grain filtering will need to be done.
How would this be any different with group based policy?

[1] - With the latter, a mapping driver could determine that communication
between these two hosts can be prevented by using an ACL on a router or a
switch, which doesn't violate the user's intent and buys a performance
improvement and works with ports that don't support security groups.



 On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen aaronoro...@gmail.com wrote:


 On Wed, Aug 6, 2014 at 3:35 PM, Kevin Benton blak...@gmail.com wrote:

 By working at the port level you have already eliminated your ability to
 implement the filtering at different components of the network. They now
 need to be implemented in stateful rules at the port level and the device
 has to support security groups.



 Lets take this example where we setup a 2 tier app with web-servers and
 db-servers that are connected on two different networks attached to a
 router. We add a security group rules such that web-servers can talk to
 db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers from
 anywhere.

 neutron net-create web_net
 neutron subnet-create --name web_subnet web_net 10.0.0.0/24

 neutron net-create db_net
 neutron subnet-create --name db_subnet db_net 10.2.0.0/24

 neutron router-create myrouter
 neutron router-interface-add myrouter web_subnet
 neutron router-interface-add myrouter db_subnet

 neutron security-group-create  web-servers;
 neutron security-group-create db-servers;

 # add rule to allow web members to talk to the db-servers on TCP 3306 for
 their db connection;
 neutron security-group-rule-create --protocol TCP --port-range-min 3306
 --port-range-max 3306 --remote-group-id web-servers db-servers

 # add rule to allow TCP 80 into the web-server sg
 neutron security-group-rule-create --protocol TCP --port-range-min 80
 --port-range-max 80 web-servers db-servers

 # create some ports with desired security profiles.
 neutron port-create  --security-group web-servers web_net
 neutron port-create  --security-group web-servers web_net

 neutron port-create  --security-group db-servers db_net
 neutron port-create  --security-group db-servers db_net


 Now to your point:

 By working at the port level you have already eliminated your ability to
 implement the filtering at different components of the network. They now
 need to be implemented in stateful rules at the port level and the device
 has to support security groups.


 Given this information I don't see any reason why the backend system
 couldn't do enforcement at the logical router and if it did so neither
 parties would know. The backend system should have the full graph of
 everything and be able to do enforcement optimizations where ever it likes.

 btw: I say the enforcement could be done on the logical router though the
 backend system could also do this on the physical fabic as well if it
 wanted to as it should also know that graph. No?



 On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:




 On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com
 wrote:

 I believe the referential security group rules solve this problem
 (unless I'm not understanding):

 I think the disconnect is that you are comparing the way to current
 mapping driver implements things for the reference implementation with the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must 
 support
 security groups

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

[Moving my reply to the correct thread as someone changed the subject line.
Attempt 2 :) ]


On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton blak...@gmail.com wrote:

 Given this information I don't see any reason why the backend system
 couldn't do enforcement at the logical router and if it did so neither
 parties would know.

 With security groups you are specifying that nothing can contact these
 devices on those ports unless they come from the allowed IP addresses. If
 you tried to enforce this at the router you would be violating that
 specification because devices in the same subnet would be able to
 communicate on those blocked ports.


Sure, though this is a problem of where you are doing your enforcement. If
the backend system chooses to implement this optimization in this fashion
(which was the example you gave previously [1]). Then, if the topology
changes, i.e adding a port to the same network with conflicting security
group rules, the backend system can no longer optimize in this same fashion
at the router level and a more fine grain filtering will need to be done.
How would this be any different with group based policy?

[1] - With the latter, a mapping driver could determine that communication
between these two hosts can be prevented by using an ACL on a router or a
switch, which doesn't violate the user's intent and buys a performance
improvement and works with ports that don't support security groups.





 On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen aaronoro...@gmail.com wrote:


 On Wed, Aug 6, 2014 at 3:35 PM, Kevin Benton blak...@gmail.com wrote:

 By working at the port level you have already eliminated your ability to
 implement the filtering at different components of the network. They now
 need to be implemented in stateful rules at the port level and the device
 has to support security groups.



 Lets take this example where we setup a 2 tier app with web-servers and
 db-servers that are connected on two different networks attached to a
 router. We add a security group rules such that web-servers can talk to
 db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers from
 anywhere.

 neutron net-create web_net
 neutron subnet-create --name web_subnet web_net 10.0.0.0/24

 neutron net-create db_net
 neutron subnet-create --name db_subnet db_net 10.2.0.0/24

 neutron router-create myrouter
 neutron router-interface-add myrouter web_subnet
 neutron router-interface-add myrouter db_subnet

 neutron security-group-create  web-servers;
 neutron security-group-create db-servers;

 # add rule to allow web members to talk to the db-servers on TCP 3306 for
 their db connection;
 neutron security-group-rule-create --protocol TCP --port-range-min 3306
 --port-range-max 3306 --remote-group-id web-servers db-servers

 # add rule to allow TCP 80 into the web-server sg
 neutron security-group-rule-create --protocol TCP --port-range-min 80
 --port-range-max 80 web-servers db-servers

 # create some ports with desired security profiles.
 neutron port-create  --security-group web-servers web_net
 neutron port-create  --security-group web-servers web_net

 neutron port-create  --security-group db-servers db_net
 neutron port-create  --security-group db-servers db_net


 Now to your point:

 By working at the port level you have already eliminated your ability to
 implement the filtering at different components of the network. They now
 need to be implemented in stateful rules at the port level and the device
 has to support security groups.


 Given this information I don't see any reason why the backend system
 couldn't do enforcement at the logical router and if it did so neither
 parties would know. The backend system should have the full graph of
 everything and be able to do enforcement optimizations where ever it likes.

 btw: I say the enforcement could be done on the logical router though the
 backend system could also do this on the physical fabic as well if it
 wanted to as it should also know that graph. No?



 On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:




 On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com
 wrote:

 I believe the referential security group rules solve this problem
 (unless I'm not understanding):

 I think the disconnect is that you are comparing the way to current
 mapping driver implements things for the reference implementation with the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must 
 support
 security groups

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

[Moving my reply to the correct thread as someone changed the subject line.
Attempt 3 :'( ]



On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton blak...@gmail.com wrote:

 Given this information I don't see any reason why the backend system
 couldn't do enforcement at the logical router and if it did so neither
 parties would know.

 With security groups you are specifying that nothing can contact these
 devices on those ports unless they come from the allowed IP addresses. If
 you tried to enforce this at the router you would be violating that
 specification because devices in the same subnet would be able to
 communicate on those blocked ports.



Sure, though this is a problem of where you are doing your enforcement. If
the backend system chooses to implement this optimization in this fashion
(which was the example you gave previously [1]). Then, if the topology
changes, i.e adding a port to the same network with conflicting security
group rules, the backend system can no longer optimize in this same fashion
at the router level and a more fine grain filtering will need to be done.
How would this be any different with group based policy?

[1] - With the latter, a mapping driver could determine that communication
between these two hosts can be prevented by using an ACL on a router or a
switch, which doesn't violate the user's intent and buys a performance
improvement and works with ports that don't support security groups.




 On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen aaronoro...@gmail.com wrote:


 On Wed, Aug 6, 2014 at 3:35 PM, Kevin Benton blak...@gmail.com wrote:

 By working at the port level you have already eliminated your ability to
 implement the filtering at different components of the network. They now
 need to be implemented in stateful rules at the port level and the device
 has to support security groups.



 Lets take this example where we setup a 2 tier app with web-servers and
 db-servers that are connected on two different networks attached to a
 router. We add a security group rules such that web-servers can talk to
 db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers from
 anywhere.

 neutron net-create web_net
 neutron subnet-create --name web_subnet web_net 10.0.0.0/24

 neutron net-create db_net
 neutron subnet-create --name db_subnet db_net 10.2.0.0/24

 neutron router-create myrouter
 neutron router-interface-add myrouter web_subnet
 neutron router-interface-add myrouter db_subnet

 neutron security-group-create  web-servers;
 neutron security-group-create db-servers;

 # add rule to allow web members to talk to the db-servers on TCP 3306 for
 their db connection;
 neutron security-group-rule-create --protocol TCP --port-range-min 3306
 --port-range-max 3306 --remote-group-id web-servers db-servers

 # add rule to allow TCP 80 into the web-server sg
 neutron security-group-rule-create --protocol TCP --port-range-min 80
 --port-range-max 80 web-servers db-servers

 # create some ports with desired security profiles.
 neutron port-create  --security-group web-servers web_net
 neutron port-create  --security-group web-servers web_net

 neutron port-create  --security-group db-servers db_net
 neutron port-create  --security-group db-servers db_net


 Now to your point:

 By working at the port level you have already eliminated your ability to
 implement the filtering at different components of the network. They now
 need to be implemented in stateful rules at the port level and the device
 has to support security groups.


 Given this information I don't see any reason why the backend system
 couldn't do enforcement at the logical router and if it did so neither
 parties would know. The backend system should have the full graph of
 everything and be able to do enforcement optimizations where ever it likes.

 btw: I say the enforcement could be done on the logical router though the
 backend system could also do this on the physical fabic as well if it
 wanted to as it should also know that graph. No?



 On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:




 On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com
 wrote:

 I believe the referential security group rules solve this problem
 (unless I'm not understanding):

 I think the disconnect is that you are comparing the way to current
 mapping driver implements things for the reference implementation with the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must 
 support
 security groups

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

Gah, clearly hitting some kind of gmail bug as i replied to the right
thread all 3 times i believe.


On Wed, Aug 6, 2014 at 4:56 PM, Aaron Rosen aaronoro...@gmail.com wrote:

 [Moving my reply to the correct thread as someone changed the subject
 line. Attempt 3 :'( ]



 On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton blak...@gmail.com wrote:

 Given this information I don't see any reason why the backend system
 couldn't do enforcement at the logical router and if it did so neither
 parties would know.

 With security groups you are specifying that nothing can contact these
 devices on those ports unless they come from the allowed IP addresses. If
 you tried to enforce this at the router you would be violating that
 specification because devices in the same subnet would be able to
 communicate on those blocked ports.



 Sure, though this is a problem of where you are doing your enforcement. If
 the backend system chooses to implement this optimization in this fashion
 (which was the example you gave previously [1]). Then, if the topology
 changes, i.e adding a port to the same network with conflicting security
 group rules, the backend system can no longer optimize in this same fashion
 at the router level and a more fine grain filtering will need to be done.
 How would this be any different with group based policy?

 [1] - With the latter, a mapping driver could determine that communication
 between these two hosts can be prevented by using an ACL on a router or a
 switch, which doesn't violate the user's intent and buys a performance
 improvement and works with ports that don't support security groups.




 On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:


 On Wed, Aug 6, 2014 at 3:35 PM, Kevin Benton blak...@gmail.com wrote:

 By working at the port level you have already eliminated your ability
 to implement the filtering at different components of the network. They now
 need to be implemented in stateful rules at the port level and the device
 has to support security groups.



 Lets take this example where we setup a 2 tier app with web-servers and
 db-servers that are connected on two different networks attached to a
 router. We add a security group rules such that web-servers can talk to
 db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers from
 anywhere.

 neutron net-create web_net
 neutron subnet-create --name web_subnet web_net 10.0.0.0/24

 neutron net-create db_net
 neutron subnet-create --name db_subnet db_net 10.2.0.0/24

 neutron router-create myrouter
 neutron router-interface-add myrouter web_subnet
 neutron router-interface-add myrouter db_subnet

 neutron security-group-create  web-servers;
 neutron security-group-create db-servers;

 # add rule to allow web members to talk to the db-servers on TCP 3306
 for their db connection;
 neutron security-group-rule-create --protocol TCP --port-range-min 3306
 --port-range-max 3306 --remote-group-id web-servers db-servers

 # add rule to allow TCP 80 into the web-server sg
 neutron security-group-rule-create --protocol TCP --port-range-min 80
 --port-range-max 80 web-servers db-servers

 # create some ports with desired security profiles.
 neutron port-create  --security-group web-servers web_net
 neutron port-create  --security-group web-servers web_net

 neutron port-create  --security-group db-servers db_net
 neutron port-create  --security-group db-servers db_net


 Now to your point:

 By working at the port level you have already eliminated your ability to
 implement the filtering at different components of the network. They now
 need to be implemented in stateful rules at the port level and the device
 has to support security groups.


 Given this information I don't see any reason why the backend system
 couldn't do enforcement at the logical router and if it did so neither
 parties would know. The backend system should have the full graph of
 everything and be able to do enforcement optimizations where ever it likes.

 btw: I say the enforcement could be done on the logical router though
 the backend system could also do this on the physical fabic as well if it
 wanted to as it should also know that graph. No?



 On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:




 On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com
 wrote:

 I believe the referential security group rules solve this problem
 (unless I'm not understanding):

 I think the disconnect is that you are comparing the way to current
 mapping driver implements things for the reference implementation with 
 the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

On Wed, Aug 6, 2014 at 4:46 PM, Kevin Benton blak...@gmail.com wrote:

 That's the point. By using security groups, you are forcing a certain kind
 of enforcement that must be honored and might not be necessary if the
 original intent was just to isolate between groups. In the example you
 gave, it cannot be implemented on the router without violating the
 constraints of the security group.


 Hi Kevin,

Mind proposing an alternative example then. The only way I can see this
claim to be made is because Group Based policy is actually limiting what a
tenants desired topology can be?

Thanks,

Aaron



 On Wed, Aug 6, 2014 at 5:39 PM, Aaron Rosen aaronoro...@gmail.com wrote:




 On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton blak...@gmail.com wrote:

 Given this information I don't see any reason why the backend system
 couldn't do enforcement at the logical router and if it did so neither
 parties would know.

 With security groups you are specifying that nothing can contact these
 devices on those ports unless they come from the allowed IP addresses. If
 you tried to enforce this at the router you would be violating that
 specification because devices in the same subnet would be able to
 communicate on those blocked ports.


 Sure, though this is a problem of where you are doing your enforcement.
 If the backend system chooses to implement this optimization in this
 fashion (which was the example you gave previously [1]). Then, if the
 topology changes, i.e adding a port to the same network with conflicting
 security group rules, the backend system can no longer optimize in this
 same fashion at the router level and a more fine grain filtering will need
 to be done. How would this be any different with group based policy?


 [1] - With the latter, a mapping driver could determine that
 communication between these two hosts can be prevented by using an ACL on a
 router or a switch, which doesn't violate the user's intent and buys a
 performance improvement and works with ports that don't support security
 groups.

 states





 On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:


 On Wed, Aug 6, 2014 at 3:35 PM, Kevin Benton blak...@gmail.com wrote:

 By working at the port level you have already eliminated your ability
 to implement the filtering at different components of the network. They 
 now
 need to be implemented in stateful rules at the port level and the device
 has to support security groups.



 Lets take this example where we setup a 2 tier app with web-servers and
 db-servers that are connected on two different networks attached to a
 router. We add a security group rules such that web-servers can talk to
 db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers from
 anywhere.

 neutron net-create web_net
 neutron subnet-create --name web_subnet web_net 10.0.0.0/24

 neutron net-create db_net
 neutron subnet-create --name db_subnet db_net 10.2.0.0/24

 neutron router-create myrouter
 neutron router-interface-add myrouter web_subnet
 neutron router-interface-add myrouter db_subnet

 neutron security-group-create  web-servers;
 neutron security-group-create db-servers;

 # add rule to allow web members to talk to the db-servers on TCP 3306
 for their db connection;
 neutron security-group-rule-create --protocol TCP --port-range-min 3306
 --port-range-max 3306 --remote-group-id web-servers db-servers

 # add rule to allow TCP 80 into the web-server sg
 neutron security-group-rule-create --protocol TCP --port-range-min 80
 --port-range-max 80 web-servers db-servers

 # create some ports with desired security profiles.
 neutron port-create  --security-group web-servers web_net
 neutron port-create  --security-group web-servers web_net

 neutron port-create  --security-group db-servers db_net
 neutron port-create  --security-group db-servers db_net


 Now to your point:

 By working at the port level you have already eliminated your ability
 to implement the filtering at different components of the network. They 
 now
 need to be implemented in stateful rules at the port level and the device
 has to support security groups.


 Given this information I don't see any reason why the backend system
 couldn't do enforcement at the logical router and if it did so neither
 parties would know. The backend system should have the full graph of
 everything and be able to do enforcement optimizations where ever it likes.

 btw: I say the enforcement could be done on the logical router though
 the backend system could also do this on the physical fabic as well if it
 wanted to as it should also know that graph. No?



 On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:




 On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com
 wrote:

 I believe the referential security group rules solve this problem
 (unless I'm not understanding):

 I think the disconnect is that you are comparing the way to current
 mapping driver implements things

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

On Wed, Aug 6, 2014 at 5:27 PM, Kevin Benton blak...@gmail.com wrote:

 Web tier can communicate with anything except for the DB.
 App tier can only communicate with Web and DB.
 DB can communicate with App.

 These high-level constraints can then be implemented as security groups
 like you showed, or network hardware ACLs like I had shown.
 But if you start with the security groups API, you are forcing it to be
 implemented there.


I still have no idea what group based policy is buying us then. It seems to
me that the key point we've identified going backing and forth here is the
difference between the current model and the GBP model is that GBP
constricts topology which allows us to write these types of enforcement
rules. The reason we want this is because it yields performance
optimizations (for some reason, which I don't think we've gotten into).
Would you agree this is accurate?

Honestly, I know a lot of work has been put into this. I haven't said I'm
for or against it either. I'm really just trying to understand what is the
motivation for this and why does it make neutron better.

Best,

Aaron




 On Wed, Aug 6, 2014 at 6:06 PM, Aaron Rosen aaronoro...@gmail.com wrote:




 On Wed, Aug 6, 2014 at 4:46 PM, Kevin Benton blak...@gmail.com wrote:

 That's the point. By using security groups, you are forcing a certain
 kind of enforcement that must be honored and might not be necessary if the
 original intent was just to isolate between groups. In the example you
 gave, it cannot be implemented on the router without violating the
 constraints of the security group.


 Hi Kevin,

 Mind proposing an alternative example then. The only way I can see this
 claim to be made is because Group Based policy is actually limiting what a
 tenants desired topology can be?

 Thanks,

 Aaron



  On Wed, Aug 6, 2014 at 5:39 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:




 On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton blak...@gmail.com wrote:

 Given this information I don't see any reason why the backend system
 couldn't do enforcement at the logical router and if it did so neither
 parties would know.

 With security groups you are specifying that nothing can contact these
 devices on those ports unless they come from the allowed IP addresses. If
 you tried to enforce this at the router you would be violating that
 specification because devices in the same subnet would be able to
 communicate on those blocked ports.


 Sure, though this is a problem of where you are doing your enforcement.
 If the backend system chooses to implement this optimization in this
 fashion (which was the example you gave previously [1]). Then, if the
 topology changes, i.e adding a port to the same network with conflicting
 security group rules, the backend system can no longer optimize in this
 same fashion at the router level and a more fine grain filtering will need
 to be done. How would this be any different with group based policy?


 [1] - With the latter, a mapping driver could determine that
 communication between these two hosts can be prevented by using an ACL on a
 router or a switch, which doesn't violate the user's intent and buys a
 performance improvement and works with ports that don't support security
 groups.

 states





 On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:


 On Wed, Aug 6, 2014 at 3:35 PM, Kevin Benton blak...@gmail.com
 wrote:

 By working at the port level you have already eliminated your
 ability to implement the filtering at different components of the 
 network.
 They now need to be implemented in stateful rules at the port level and 
 the
 device has to support security groups.



 Lets take this example where we setup a 2 tier app with web-servers
 and db-servers that are connected on two different networks attached to a
 router. We add a security group rules such that web-servers can talk to
 db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers 
 from
 anywhere.

 neutron net-create web_net
 neutron subnet-create --name web_subnet web_net 10.0.0.0/24

 neutron net-create db_net
 neutron subnet-create --name db_subnet db_net 10.2.0.0/24

 neutron router-create myrouter
 neutron router-interface-add myrouter web_subnet
 neutron router-interface-add myrouter db_subnet

 neutron security-group-create  web-servers;
 neutron security-group-create db-servers;

 # add rule to allow web members to talk to the db-servers on TCP 3306
 for their db connection;
 neutron security-group-rule-create --protocol TCP --port-range-min
 3306 --port-range-max 3306 --remote-group-id web-servers db-servers

 # add rule to allow TCP 80 into the web-server sg
 neutron security-group-rule-create --protocol TCP --port-range-min 80
 --port-range-max 80 web-servers db-servers

 # create some ports with desired security profiles.
 neutron port-create  --security-group web-servers web_net
 neutron port-create  --security-group web-servers web_net

 neutron port-create  --security

Re: [openstack-dev] [Nova] Nominating Jay Pipes for nova-core

[Aaron Rosen]

+1!


On Thu, Jul 31, 2014 at 12:40 AM, Nikola Đipanov ndipa...@redhat.com
wrote:

 On 07/30/2014 11:02 PM, Michael Still wrote:
  Greetings,
 
  I would like to nominate Jay Pipes for the nova-core team.
 
  Jay has been involved with nova for a long time now.  He's previously
  been a nova core, as well as a glance core (and PTL). He's been around
  so long that there are probably other types of core status I have
  missed.
 
  Please respond with +1s or any concerns.
 

 +1

  References:
 
https://review.openstack.org/#/q/owner:%22jay+pipes%22+status:open,n,z
 
https://review.openstack.org/#/q/reviewer:%22jay+pipes%22,n,z
 
http://stackalytics.com/?module=nova-groupuser_id=jaypipes
 
  As a reminder, we use the voting process outlined at
  https://wiki.openstack.org/wiki/Nova/CoreTeam to add members to our
  core team.
 
  Thanks,
  Michael
 


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Creating new python-new_project_nameclient

[Aaron Rosen]

Thanks guys, very helpful.

Aaron


On Wed, Jun 25, 2014 at 11:53 PM, Jamie Lennox jamielen...@redhat.com
wrote:

 On Wed, 2014-06-25 at 22:42 -0500, Dean Troyer wrote:
  On Wed, Jun 25, 2014 at 10:18 PM, Aaron Rosen aaronoro...@gmail.com
  wrote:
  I'm looking at creating a new python-new_project_nameclient
  and I was wondering if there was any on going effort to share
  code between the clients or not? I've looked at the code in
  python-novaclient and python-neutronclient and both of them
  seem to have their own homegrown HTTPClient and keystone
  integration. Figured I'd ping the mailing list here before I
  go on and make my own homegrown HTTPClient as well.
 
 
  For things in the library level of a client please consider using
  keystoneclient's fairly new session layer as the basis of your HTTP
  layer.  That will also give you access to the new style auth plugins,
  assuming you want to do Keystone auth with this client.
 
 
  I'm not sure if Jamie has any examples of using this without leaning
  on the backward-compatibility bits that the existing clients need.
 
 
  The Python SDK is being built on a similar Session layer (without the
  backeard compat bits).
 
 
  dt

 I'd love to suggest following in the footsteps of the SDK, but it's just
 a little early for that.

 Today the best thing i think would be to use the session from
 keystoneclient, and copy and paste the adapter:
 https://review.openstack.org/#/c/86237/ which is approved but not in a
 release yet. A client object takes a session and kwargs and creates an
 adapter with them.

 Then reuse the managers from

 https://github.com/openstack/oslo-incubator/blob/master/openstack/common/apiclient/base.py
 I'm personally not a fan, but most of the other clients use this layout
 and I assume you're more interested in getting things done in a standard
 way than arguing over client design (If you are interested in that the
 SDK project could always use a hand). Pass the adapter to the managers.

 Don't write a CLI, you can extend OSC to handle your new service. There
 are no docs for it (that i'm aware of) but the included services all use
 the plugin interface so you can copy from one of those.

 I don't have a pure example of these things, but if any of the above is
 unclear feel free to find me on IRC and i'll step you through it.

 Jamie

 
 
  --
 
  Dean Troyer
  dtro...@gmail.com
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Creating new python-new_project_nameclient

[Aaron Rosen]

Hi,

I'm looking at creating a new python-new_project_nameclient and I was
wondering if there was any on going effort to share code between the
clients or not? I've looked at the code in python-novaclient and
python-neutronclient and both of them seem to have their own homegrown
HTTPClient and keystone integration. Figured I'd ping the mailing list here
before I go on and make my own homegrown HTTPClient as well.

Thanks!

Aaron
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] default security group rules in neutron

[Aaron Rosen]

Hi Lingxian,

I've definitely experienced this problem first hand when new tenants are
allowed access to our openstack cloud. I understand that nova has an
extension to do this but I'm curious if part of the tenant onboarding
script if the desired security group rules could be set. I'm not opposed to
adding this but it seems like if that's an okay solution that might be the
easiest thing to do as neutron already supports this :)

Best,

Aaron


On Mon, Jun 23, 2014 at 1:54 PM, Mathieu Gagné mga...@iweb.com wrote:

 On 2014-06-22 10:23 PM, Lingxian Kong wrote:


 So, for the functionality parity between nova-network and neutron and
 for our use case, I registered a blueprint[2] about default security
 group rules in Neutron days ago and related neutron spec[3], and I
 want it to be involved in Juno, so we can upgrade our deployment that
 time for this feature. I'm ready for the code implementation[3].

 But I still want to see what's the community's thought about including
 this feature in neutron, any of your feedback and comments are
 appreciated!


 +1

 That's awesome news! Glad to hear someone is working on it.

 I already implemented (for our own cloud) a similar feature which allows
 an operator to override the set of default security group rules using a
 yaml config file. So yea... you can't edit it through the API, I'm not that
 fancy =)

 I'm unfortunately guilty of not proposing it upstream or publishing it
 somewhere. I'll see if I can publish it somewhere this week. Though limited
 in feature, hopefully it will be useful to someone else too.

 --
 Mathieu


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Nominating Ken'ichi Ohmichi for nova-core

[Aaron Rosen]

+1

On Monday, June 16, 2014, Andrew Laski andrew.la...@rackspace.com wrote:

 +1

 On 06/13/2014 06:40 PM, Michael Still wrote:

 Greetings,

 I would like to nominate Ken'ichi Ohmichi for the nova-core team.

 Ken'ichi has been involved with nova for a long time now.  His reviews
 on API changes are excellent, and he's been part of the team that has
 driven the new API work we've seen in recent cycles forward. Ken'ichi
 has also been reviewing other parts of the code base, and I think his
 reviews are detailed and helpful.

 Please respond with +1s or any concerns.

 References:

https://review.openstack.org/#/q/owner:ken1ohmichi%
 2540gmail.com+status:open,n,z

https://review.openstack.org/#/q/reviewer:ken1ohmichi%
 2540gmail.com,n,z

http://www.stackalytics.com/?module=nova-groupuser_id=oomichi

 As a reminder, we use the voting process outlined at
 https://wiki.openstack.org/wiki/Nova/CoreTeam to add members to our
 core team.

 Thanks,
 Michael



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

[Aaron Rosen]

Hi,

I'm curious if other openstack clients implement this type of retry thing.
I think retrying on GET/DELETES/PUT's should probably be okay.

What types of errors do you see in the neutron-server when it fails to
respond? I think it would be better to move the retry logic into the server
around the failures rather than the client (or better yet if we fixed the
server :)). Most of the times I've seen this type of failure is due to
deadlock errors caused between (sqlalchemy and eventlet *i think*) which
cause the client to eventually timeout.

Best,

Aaron


On Wed, May 28, 2014 at 11:51 AM, Paul Ward wpw...@us.ibm.com wrote:

 Would it be feasible to make the retry logic only apply to read-only
 operations?  This would still require a nova change to specify the number
 of retries, but it'd also prevent invokers from shooting themselves in the
 foot if they call for a write operation.



 Aaron Rosen aaronoro...@gmail.com wrote on 05/27/2014 09:40:00 PM:

  From: Aaron Rosen aaronoro...@gmail.com

  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org,
  Date: 05/27/2014 09:44 PM

  Subject: Re: [openstack-dev] [neutron] Supporting retries in
 neutronclient
 
  Hi,

 
  Is it possible to detect when the ssl handshaking error occurs on
  the client side (and only retry for that)? If so I think we should
  do that rather than retrying multiple times. The danger here is
  mostly for POST operations (as Eugene pointed out) where it's
  possible for the response to not make it back to the client and for
  the operation to actually succeed.
 
  Having this retry logic nested in the client also prevents things
  like nova from handling these types of failures individually since
  this retry logic is happening inside of the client. I think it would
  be better not to have this internal mechanism in the client and
  instead make the user of the client implement retry so they are
  aware of failures.
 
  Aaron
 

  On Tue, May 27, 2014 at 10:48 AM, Paul Ward wpw...@us.ibm.com wrote:
  Currently, neutronclient is hardcoded to only try a request once in
  retry_request by virtue of the fact that it uses self.retries as the
  retry count, and that's initialized to 0 and never changed.  We've
  seen an issue where we get an ssl handshaking error intermittently
  (seems like more of an ssl bug) and a retry would probably have
  worked.  Yet, since neutronclient only tries once and gives up, it
  fails the entire operation.  Here is the code in question:
 
  https://github.com/openstack/python-neutronclient/blob/master/
  neutronclient/v2_0/client.py#L1296
 
  Does anybody know if there's some explicit reason we don't currently
  allow configuring the number of retries?  If not, I'm inclined to
  propose a change for just that.
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] [Neutron] heal_instance_info_cache_interval - Can we kill it?

[Aaron Rosen]

On Wed, May 28, 2014 at 7:39 AM, Assaf Muller amul...@redhat.com wrote:



 - Original Message -
  Hi,
 
  Sorry somehow I missed this email. I don't think you want to disable it,
  though we can definitely have it run less often. The issue with
 disabling it
  is if one of the notifications from neutron-nova never gets sent
  successfully to nova (neutron-server is restarted before the event is
 sent
  or some other internal failure). Nova will never update it's cache if the
  heal_instance_info_cache_interval is set to 0.

 The thing is, this periodic healing doesn't imply correctness either.
 In the case where you lose a notification and the compute node hosting
 the VM is hosting a non-trivial amount of VMs it can take (With the default
 of 60 seconds) dozens of minutes to update the cache, since you only
 update a VM a minute. I could understand the use of a sanity check if it
 was performed much more often, but as it is now it seems useless to me
 since you can't really rely on it.


I agree with you. That's why we implemented the event callback so that the
cache would be more up to date. In honesty you can probably safely disable
the  heal_instance_info_cache_interval and things will probably be fine as
we haven't seen many failures where events from neutron fail to send. If we
find out this is the case we can definitely make the event sending
notification logic in neutron much more robust by persisting events to the
db and implementing retry logic on failure there to help ensure nova gets
the notification.


 What I'm trying to say is that with the inefficiency of the implementation,
 coupled with Neutron's default plugin inability to cope with a large
 amount of API calls, I feel like the disadvantages outweigh the
 advantages when it comes to the cache healing.


Right the current heal_instance implementation has scaling issues as every
compute node runs this task querying neutron. The more compute nodes you
have the more querying. Hopefully the nova v3 api should solve this issue
though as the networking information will no longer have to live in nova as
well. So someone interested in this data network data can query neutron
directly and we can avoid these type of caching issues all together :)


 How would you feel about disabling it, optimizing the implementation
 (For example by introducing a new networking_for_instance API verb to
 Neutron?)
 then enabling it again?


I think this is a good idea we should definitely implement something like
this so nova can interface with less api calls.


  The neutron-nova events help
  to ensure that the nova info_cache is up to date sooner by having neutron
  inform nova whenever a port's data has changed (@Joe Gordon - this
 happens
  regardless of virt driver).
 
  If you're using the libvirt virt driver the neutron-nova events will
 also be
  used to ensure that the networking is 'ready' before the instance is
 powered
  on.
 
  Best,
 
  Aaron
 
  P.S: we're working on making the heal_network call to neutron a lot less
  expensive as well in the future.
 
 
 
 
  On Tue, May 27, 2014 at 7:25 PM, Joe Gordon  joe.gord...@gmail.com 
 wrote:
 
 
 
 
 
 
  On Wed, May 21, 2014 at 6:21 AM, Assaf Muller  amul...@redhat.com 
 wrote:
 
 
  Dear Nova aficionados,
 
  Please make sure I understand this correctly:
  Each nova compute instance selects a single VM out of all of the VMs
  that it hosts, and every heal_instance_info_cache_interval seconds
  queries Neutron for all of its networking information, then updates
  Nova's DB.
 
  If the information above is correct, then I fail to see how that
  is in anyway useful. For example, for a compute node hosting 20 VMs,
  it would take 20 minutes to update the last one. Seems unacceptable
  to me.
 
  Considering Icehouse's Neutron to Nova notifications, my question
  is if we can change the default to 0 (Disable the feature), deprecate
  it, then delete it in the K cycle. Is there a good reason not to do this?
 
  Based on the patch that introduced this function [0] you may be on to
  something, but AFAIK unfortunately the neutron to nova notifications only
  work in libvirt right now [1], so I don' think we can fully deprecate
 this
  periodic task. That being said turning it off by default may be an
 option.
  Have you tried disabling this feature and seeing what happens (in the
 gate
  and/or in production)?
 

 We've disabled it in a scale lab and didn't observe any black holes forming
 or other catastrophes.

 
  [0] https://review.openstack.org/#/c/4269/
  [1] https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse
 
 
 
 
  Assaf Muller, Cloud Networking Engineer
  Red Hat
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  

Re: [openstack-dev] [IceHouse][Neutron][Ubuntu 14.04] Error: Failed to delete network

[Aaron Rosen]

Hi,

can you open a bug report on this and provide your setup configuration? I
just tested this with ML2 and wasn't able to reproduce the issue.

arosen@arosen-MacBookPro:~/devstack$ neutron net-create asdf
 --provider:network_type vlan  --provider:segmentation_id 124
--provider:physical_network  asdf
Unable to create the network. The VLAN 124 on physical network asdf is in
use.

arosen@arosen-MacBookPro:~/devstack$ neutron net-delete asdf
Deleted network: asdf

Thanks,

Aaron


On Fri, May 23, 2014 at 10:52 AM, Martinx - ジェームズ thiagocmarti...@gmail.com
 wrote:

 Guys,

 I'm trying to delete a network in Neutron but it is failing, from Horizon
 it triggers the error message above (subject), and from CLI, it shows this:

 ---
 root@psuaa-1:~# neutron net-delete a1654832-8aac-42d5-8837-6d27b7421892
 Request Failed: internal server error while processing your request.
 ---

 The logs shows:

 ---
 == /var/log/neutron/server.log ==
 2014-05-21 11:49:54.242 5797 INFO neutron.wsgi [-] (5797) accepted
 ('2804:290:4:dead::10', 56908, 0, 0)

 2014-05-21 11:49:54.245 5797 INFO urllib3.connectionpool [-] Starting new
 HTTP connection (1): psuaa-1.mng.tcmc.com.br
 2014-05-21 11:49:54.332 5797 INFO neutron.wsgi
 [req-e1c4d6c4-71de-4bfa-a7db-f09fa0571377 None] 2804:290:4:dead::10 - -
 [21/May/2014 11:49:54] GET
 /v2.0/networks.json?fields=idid=a1654832-8aac-42d5-8837-6d27b7421892
 HTTP/1.1 200 251 0.089015

 2014-05-21 11:49:54.334 5797 INFO neutron.wsgi
 [req-e1c4d6c4-71de-4bfa-a7db-f09fa0571377 None] (5797) accepted
 ('2804:290:4:dead::10', 56910, 0, 0)

 2014-05-21 11:49:54.380 5797 ERROR neutron.api.v2.resource
 [req-f216416d-8433-444f-9108-f4a17f5bf49d None] delete failed
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource Traceback (most
 recent call last):
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
 /usr/lib/python2.7/dist-packages/neutron/api/v2/resource.py, line 87, in
 resource
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource result =
 method(request=request, **args)
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
 /usr/lib/python2.7/dist-packages/neutron/api/v2/base.py, line 449, in
 delete
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
 obj_deleter(request.context, id, **kwargs)
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
 /usr/lib/python2.7/dist-packages/neutron/plugins/ml2/plugin.py, line 494,
 in delete_network
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
 self.type_manager.release_segment(session, segment)
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
 /usr/lib/python2.7/dist-packages/neutron/plugins/ml2/managers.py, line
 101, in release_segment
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
 driver.obj.release_segment(session, segment)
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource AttributeError:
 'NoneType' object has no attribute 'obj'
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
 2014-05-21 11:49:54.383 5797 INFO neutron.wsgi
 [req-f216416d-8433-444f-9108-f4a17f5bf49d None] 2804:290:4:dead::10 - -
 [21/May/2014 11:49:54] DELETE
 /v2.0/networks/a1654832-8aac-42d5-8837-6d27b7421892.json HTTP/1.1 500 296
 0.048123
 ---

 What can I do to delete a net that doesn't want to be deleted? Do I
 just need to clean some tables directly on mysql, for example... ?

 NOTE: I'm double posting it here on dev list, because on user list no one
 seems to be able to help me... Sorry BTW...   :)

 Tks!
 Thiago

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [IceHouse][Neutron][Ubuntu 14.04] Error: Failed to delete network

[Aaron Rosen]

I believe this patch should fix the issue, It seems to for me:
https://review.openstack.org/#/c/95938/ (It's in the process of merging
into icehouse and havana now). Thanks for the report.



arosen@arosen-MacBookPro:~/devstack$ neutron net-list
+--+-++
| id   | name| subnets
   |
+--+-++
| 18b00633-2a32-494d-88cf-41c19211597d | private |
556f3c44-01bb-468a-8064-10c833eb3715 10.0.0.0/24   |
|  | |
e8180cc2-e5ea-4892-997e-e9ff96b426f4 2008:129:2bf:cd1::/64 |
| b9869a8e-cc7b-409f-99c9-ae1a2a4a4855 | public  |
9b9f49b2-0297-4528-92d3-b2ca7abd5be4   |
+--+-++
arosen@arosen-MacBookPro:~/devstack$ neutron router-list
+--+-+-+
| id   | name| external_gateway_info
|
+--+-+-+
| 96d4a3cb-4138-41af-b88e-8ebe5405f2bb | router1 | {network_id:
b9869a8e-cc7b-409f-99c9-ae1a2a4a4855, enable_snat: true} |
+--+-+-+
arosen@arosen-MacBookPro:~/devstack$ neutron router-interface-delete
router1 556f3c44-01bb-468a-8064-10c833eb3715
Removed interface from router router1.
arosen@arosen-MacBookPro:~/devstack$ neutron router-interface-delete
router1 e8180cc2-e5ea-4892-997e-e9ff96b426f4
Removed interface from router router1.
arosen@arosen-MacBookPro:~/devstack$ neutron net-delete private
Deleted network: private



On Tue, May 27, 2014 at 3:57 PM, Martinx - ジェームズ
thiagocmarti...@gmail.comwrote:

 Hi Aaron!

 The BUG report https://bugs.launchpad.net/neutron/+bug/1322945 is about
 this problem, I posted there the instructions to reproduce it...

 Basically, after attaching a private IPv6 subnet to your L3 Router, it
 will break the External Network and its Floating IPs, then, it becomes
 impossible to delete that External Network... It enters in a stuck
 state...

 Regards,
 Thiago


 On 27 May 2014 18:34, Aaron Rosen aaronoro...@gmail.com wrote:

 Hi,

 can you open a bug report on this and provide your setup configuration? I
 just tested this with ML2 and wasn't able to reproduce the issue.

 arosen@arosen-MacBookPro:~/devstack$ neutron net-create asdf
  --provider:network_type vlan  --provider:segmentation_id 124
 --provider:physical_network  asdf
 Unable to create the network. The VLAN 124 on physical network asdf is in
 use.

 arosen@arosen-MacBookPro:~/devstack$ neutron net-delete asdf
 Deleted network: asdf

 Thanks,

 Aaron


 On Fri, May 23, 2014 at 10:52 AM, Martinx - ジェームズ 
 thiagocmarti...@gmail.com wrote:

 Guys,

 I'm trying to delete a network in Neutron but it is failing, from
 Horizon it triggers the error message above (subject), and from CLI, it
 shows this:

 ---
 root@psuaa-1:~# neutron net-delete a1654832-8aac-42d5-8837-6d27b7421892
 Request Failed: internal server error while processing your request.
 ---

 The logs shows:

 ---
 == /var/log/neutron/server.log ==
 2014-05-21 11:49:54.242 5797 INFO neutron.wsgi [-] (5797) accepted
 ('2804:290:4:dead::10', 56908, 0, 0)

 2014-05-21 11:49:54.245 5797 INFO urllib3.connectionpool [-] Starting
 new HTTP connection (1): psuaa-1.mng.tcmc.com.br
 2014-05-21 11:49:54.332 5797 INFO neutron.wsgi
 [req-e1c4d6c4-71de-4bfa-a7db-f09fa0571377 None] 2804:290:4:dead::10 - -
 [21/May/2014 11:49:54] GET
 /v2.0/networks.json?fields=idid=a1654832-8aac-42d5-8837-6d27b7421892
 HTTP/1.1 200 251 0.089015

 2014-05-21 11:49:54.334 5797 INFO neutron.wsgi
 [req-e1c4d6c4-71de-4bfa-a7db-f09fa0571377 None] (5797) accepted
 ('2804:290:4:dead::10', 56910, 0, 0)

 2014-05-21 11:49:54.380 5797 ERROR neutron.api.v2.resource
 [req-f216416d-8433-444f-9108-f4a17f5bf49d None] delete failed
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource Traceback
 (most recent call last):
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
 /usr/lib/python2.7/dist-packages/neutron/api/v2/resource.py, line 87, in
 resource
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource result =
 method(request=request, **args)
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
 /usr/lib/python2.7/dist-packages/neutron/api/v2/base.py, line 449, in
 delete
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
 obj_deleter(request.context, id, **kwargs)
 2014-05-21 11:49:54.380 5797 TRACE

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

[Aaron Rosen]

Hi,

Is it possible to detect when the ssl handshaking error occurs on the
client side (and only retry for that)? If so I think we should do that
rather than retrying multiple times. The danger here is mostly for POST
operations (as Eugene pointed out) where it's possible for the response to
not make it back to the client and for the operation to actually succeed.

Having this retry logic nested in the client also prevents things like nova
from handling these types of failures individually since this retry logic
is happening inside of the client. I think it would be better not to have
this internal mechanism in the client and instead make the user of the
client implement retry so they are aware of failures.

Aaron


On Tue, May 27, 2014 at 10:48 AM, Paul Ward wpw...@us.ibm.com wrote:

 Currently, neutronclient is hardcoded to only try a request once in
 retry_request by virtue of the fact that it uses self.retries as the retry
 count, and that's initialized to 0 and never changed.  We've seen an issue
 where we get an ssl handshaking error intermittently (seems like more of an
 ssl bug) and a retry would probably have worked.  Yet, since neutronclient
 only tries once and gives up, it fails the entire operation.  Here is the
 code in question:


 https://github.com/openstack/python-neutronclient/blob/master/neutronclient/v2_0/client.py#L1296

 Does anybody know if there's some explicit reason we don't currently allow
 configuring the number of retries?  If not, I'm inclined to propose a
 change for just that.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] [Neutron] heal_instance_info_cache_interval - Can we kill it?

[Aaron Rosen]

Hi,

Sorry somehow I missed this email. I don't think you want to disable it,
though we can definitely have it run less often. The issue with disabling
it is if one of the notifications from neutron-nova never gets sent
successfully to nova (neutron-server is restarted before the event is sent
or some other internal failure). Nova will never update it's cache if
the heal_instance_info_cache_interval is set to 0.  The neutron-nova
events help to ensure that the nova info_cache is up to date sooner by
having neutron inform nova whenever a port's data has changed (@Joe Gordon
- this happens regardless of virt driver).

If you're using the libvirt virt driver the neutron-nova events will also
be used to ensure that the networking is 'ready' before the instance is
powered on.

Best,

Aaron

P.S: we're working on making the heal_network call to neutron a lot less
expensive as well in the future.




On Tue, May 27, 2014 at 7:25 PM, Joe Gordon joe.gord...@gmail.com wrote:




 On Wed, May 21, 2014 at 6:21 AM, Assaf Muller amul...@redhat.com wrote:

 Dear Nova aficionados,

 Please make sure I understand this correctly:
 Each nova compute instance selects a single VM out of all of the VMs
 that it hosts, and every heal_instance_info_cache_interval seconds
 queries Neutron for all of its networking information, then updates
 Nova's DB.

 If the information above is correct, then I fail to see how that
 is in anyway useful. For example, for a compute node hosting 20 VMs,
 it would take 20 minutes to update the last one. Seems unacceptable
 to me.

 Considering Icehouse's Neutron to Nova notifications, my question
 is if we can change the default to 0 (Disable the feature), deprecate
 it, then delete it in the K cycle. Is there a good reason not to do this?


 Based on the patch that introduced this function [0] you may be on to
 something, but AFAIK unfortunately the neutron to nova notifications only
 work in libvirt right now [1], so I don' think we can fully deprecate this
 periodic task. That being said turning it off by default may be an option.
 Have you tried disabling this feature and seeing what happens (in the gate
 and/or in production)?


 [0] https://review.openstack.org/#/c/4269/
 [1] https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse




 Assaf Muller, Cloud Networking Engineer
 Red Hat

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Glance

[Aaron Rosen]

Do you have a loadbalancer or something that limits the request time in the
path? That would be my guess, you probably need to raise the
 request_termination_timeout.

Best,

Aaron


On Thu, May 22, 2014 at 10:59 PM, Tizy Ninan tizy.e...@gmail.com wrote:

 Hi,

 We have an openstack deployment (Havana on CentOS) in HA mode with
 nova-network service deployed using Mirantis Fuel v4.0 .
 When uploading images with large filesize (more than 1 GB) from dashboard,
 after upload is done the dashboard is showing 504 Gateway Timeout. What
 could be the problem? Can anyone please help me on resolving this issue?

 Thanks,
 Tizy

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Proposed changes to core team

[Aaron Rosen]

+1 I agree. Carl has make a lot of great contributions in both code and
reviews.


On Wed, May 21, 2014 at 3:19 PM, Armando M. arma...@gmail.com wrote:

 +1 from me too: Carl's contributions, code and reviews, have helped raise
 the quality of this project.

 Cheers,
 Armando

 On 21 May 2014 15:05, Maru Newby ma...@redhat.com wrote:
 
  On May 21, 2014, at 1:59 PM, Kyle Mestery mest...@noironetworks.com
 wrote:
 
  Neutron cores, please vote +1/-1 for the proposed addition of Carl
  Baldwin to Neutron core.
 
  +1 from me
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Chalenges with highly available service VMs

[Aaron Rosen]

Hi Praveen,

I think we should fix the update_method instead to properly check for this.
I don't see any advantage to allow the fixed_ips/mac to be in the
allowed_address_pairs since they are explicitly allowed. What's your
motivation for changing this?

Aaron


On Mon, May 19, 2014 at 4:05 PM, Praveen Yalagandula 
yprav...@avinetworks.com wrote:

 Hi Aaron,

 Thanks for the prompt response.

 If the overlap does not have any negative effect, can we please just
 remove this check? It creates confusion as there are certain code paths
 where we do not perform this check. For example, the current code does NOT
 perform this check when we are updating the list of allowed-address-pairs
 -- I can successfully assign an existing fixed IP address to the
 allowed-address-pairs. The check is being performed on only one code path -
 when assigning fixed IPs.

 If it sounds right to you, I can submit my patch removing this check.

 Thanks,
 Praveen



 On Mon, May 19, 2014 at 12:32 PM, Aaron Rosen aaronoro...@gmail.comwrote:

 Hi,

 Sure, if you look at this method:

 def _check_fixed_ips_and_address_pairs_no_overlap(self, context,
 port):
 address_pairs = self.get_allowed_address_pairs(context,
 port['id'])
 for fixed_ip in port['fixed_ips']:

 for address_pair in address_pairs:

 if (fixed_ip['ip_address'] == address_pair['ip_address']

 and port['mac_address'] ==
 address_pair['mac_address']):
 raise addr_pair.AddressPairMatchesPortFixedIPAndMac()




 it checks that the allowed_address_pairs don't overlap with fixed_ips and
 mac_address on the port. The only reason we do this additional check is
 that having the same fixed_ip and mac_address pair as an
 allowed_address_pair would have no effect since the fixed_ip/mac on the
 port inherently allows that traffic through.

 Best,

 Aaron



 On Mon, May 19, 2014 at 12:22 PM, Praveen Yalagandula 
 yprav...@avinetworks.com wrote:

 Hi Aaron,

 In OVS and ML2 plugins, on port-update, there is a check to make sure
 that allowed-address-pairs and fixed-ips don't overlap. Can you please
 explain why that is needed?

 - icehouse final: neutron/plugins/ml2/plugin.py 

 677 elif changed_fixed_ips:

 678 self._check_fixed_ips_and_address_pairs_no_overlap(

 679 context, updated_port)
 ---

 Thanks,
 Praveen


 On Wed, Jul 17, 2013 at 3:45 PM, Aaron Rosen aro...@nicira.com wrote:

 Hi Ian,

 For shared networks if the network is set to port_security_enabled=True
 then the tenant will not be able to remove port_security_enabled from their
 port if they are not the owner of the network. I believe this is the
 correct behavior we want. In addition, only admin's are able to create
 shared networks by default.

 I've created the following blueprint
 https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairsand 
 doc:
 https://docs.google.com/document/d/1hyB3dIkRF623JlUsvtQFo9fCKLsy0gN8Jf6SWnqbWWA/edit?usp=sharingwhich
  will provide us a way to do this. It would be awesome if you could
 check it out and let me know what you think.

 Thanks,

 Aaron


 On Tue, Jul 16, 2013 at 10:34 AM, Ian Wells ijw.ubu...@cack.org.ukwrote:

 On 10 July 2013 21:14, Vishvananda Ishaya vishvana...@gmail.com
 wrote:
  It used to be essential back when we had nova-network and all
 tenants
  ended up on one network.  It became less useful when tenants could
  create their own networks and could use them as they saw fit.
 
  It's still got its uses - for instance, it's nice that the metadata
  server can be sure that a request is really coming from where it
  claims - but I would very much like it to be possible to, as an
  option, explicitly disable antispoof - perhaps on a per-network
 basis
  at network creation time - and I think we could do this without
  breaking the security model beyond all hope of usefulness.
 
  Per network and per port makes sense.
 
  After all, this is conceptually the same as enabling or disabling
  port security on your switch.

 Bit late on the reply to this, but I think we should be specific on
 the network, at least at creation time, on what disabling is allowed
 at port level (default off, may be off, must be on as now).  Yes, it's
 exactly like disabling port security, and you're not always the
 administrator of your own switch; if we extend the analogy you
 probably wouldn't necessarily want people turning antispoof off on an
 explicitly shared-tenant network.
 --
 Ian.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Chalenges with highly available service VMs

[Aaron Rosen]

arosen@arosen-MacBookPro:~/devstack$ neutron port-show
f5117013-ac04-45af-a5d6-e9110213ad6f
+---+--+
| Field | Value
   |
+---+--+
| admin_state_up| True
|
| allowed_address_pairs |
   |
| binding:vnic_type | normal
|
| device_id | 99012a6c-a5ed-41c0-92c9-14d40af0c2df
|
| device_owner  | compute:None
|
| extra_dhcp_opts   |
   |
| fixed_ips | {subnet_id:
505eb39c-32dc-4fe7-a497-f801a0677c54, ip_address: 10.0.0.22} |
| id| f5117013-ac04-45af-a5d6-e9110213ad6f
|
| mac_address   | fa:16:3e:77:4d:2d
   |
| name  |
   |
| network_id| 1b069199-bfa4-4efc-aebd-4a663d447964
|
| security_groups   | 0d5477cf-f63a-417e-be32-a12557fa4098
|
| status| ACTIVE
|
| tenant_id | c71ebe8d1f6e47bab7d44046ec2f6b39
|
+---+--+
arosen@arosen-MacBookPro:~/devstack$ neutron port-update
f5117013-ac04-45af-a5d6-e9110213ad6f --allowed-address-pairs list=true
type=dict ip_address=10.0.0.0/24
Updated port: f5117013-ac04-45af-a5d6-e9110213ad6f
arosen@arosen-MacBookPro:~/devstack$ neutron port-show
f5117013-ac04-45af-a5d6-e9110213ad6f
+---+--+
| Field | Value
   |
+---+--+
| admin_state_up| True
|
| allowed_address_pairs | {ip_address: 10.0.0.0/24, mac_address:
fa:16:3e:77:4d:2d}|
| binding:vnic_type | normal
|
| device_id | 99012a6c-a5ed-41c0-92c9-14d40af0c2df
|
| device_owner  | compute:None
|
| extra_dhcp_opts   |
   |
| fixed_ips | {subnet_id:
505eb39c-32dc-4fe7-a497-f801a0677c54, ip_address: 10.0.0.22} |
| id| f5117013-ac04-45af-a5d6-e9110213ad6f
|
| mac_address   | fa:16:3e:77:4d:2d
   |
| name  |
   |
| network_id| 1b069199-bfa4-4efc-aebd-4a663d447964
|
| security_groups   | 0d5477cf-f63a-417e-be32-a12557fa4098
|
| status| ACTIVE
|
| tenant_id | c71ebe8d1f6e47bab7d44046ec2f6b39
|
+---+--+



On Tue, May 20, 2014 at 7:52 PM, Aaron Rosen aaronoro...@gmail.com wrote:

 Hi Praveen,

 I think there is some confusion here. This function doesn't check if there
 is any overlap that occurs within the cidr block. It only checks that the
 fixed_ips+mac don't overlap with an allowed address pair. In your example
 if the host has an ip_address of 10.10.1.1 and you want to allow any ip in
 10.10.1.0/24 to pass through the port you can just add a rule for
 10.10.1.0/24 directly without having to break it up.

 Aaron


 On Tue, May 20, 2014 at 11:20 AM, Praveen Yalagandula 
 yprav...@avinetworks.com wrote:

 Hi Aaron,

 The main motivation is simplicity. Consider the case where we want to
 allow ip cidr 10.10.1.0/24 to be allowed on a port which has a fixed IP
 of 10.10.1.1. Now if we do not want to allow overlapping, then one needs to
 add 8 cidrs to get around this - (10.10.1.128/25, 10.10.1.64/26,
 10.10.1.32/27, 10.10.1.0/32); which makes it cumbersome.

 In any case, allowed-address-pairs is ADDING on to what is allowed
 because of the fixed IPs. So, there is no possibility of conflict. The
 check will probably make sense if we are maintaining denied addresses
 instead of allowed addresses.

 Cheers,
 Praveen


 On Tue, May 20, 2014 at 9:34 AM, Aaron Rosen aaronoro...@gmail.comwrote:

 Hi Praveen,

 I think we should fix the update_method instead to properly check for
 this. I don't see any advantage to allow the fixed_ips/mac to be in the
 allowed_address_pairs since they are explicitly allowed. What's your
 motivation

Re: [openstack-dev] Chalenges with highly available service VMs

[Aaron Rosen]

Hi Praveen,

I think there is some confusion here. This function doesn't check if there
is any overlap that occurs within the cidr block. It only checks that the
fixed_ips+mac don't overlap with an allowed address pair. In your example
if the host has an ip_address of 10.10.1.1 and you want to allow any ip in
10.10.1.0/24 to pass through the port you can just add a rule for
10.10.1.0/24 directly without having to break it up.

Aaron


On Tue, May 20, 2014 at 11:20 AM, Praveen Yalagandula 
yprav...@avinetworks.com wrote:

 Hi Aaron,

 The main motivation is simplicity. Consider the case where we want to
 allow ip cidr 10.10.1.0/24 to be allowed on a port which has a fixed IP
 of 10.10.1.1. Now if we do not want to allow overlapping, then one needs to
 add 8 cidrs to get around this - (10.10.1.128/25, 10.10.1.64/26,
 10.10.1.32/27, 10.10.1.0/32); which makes it cumbersome.

 In any case, allowed-address-pairs is ADDING on to what is allowed because
 of the fixed IPs. So, there is no possibility of conflict. The check will
 probably make sense if we are maintaining denied addresses instead of
 allowed addresses.

 Cheers,
 Praveen


 On Tue, May 20, 2014 at 9:34 AM, Aaron Rosen aaronoro...@gmail.comwrote:

 Hi Praveen,

 I think we should fix the update_method instead to properly check for
 this. I don't see any advantage to allow the fixed_ips/mac to be in the
 allowed_address_pairs since they are explicitly allowed. What's your
 motivation for changing this?

 Aaron


 On Mon, May 19, 2014 at 4:05 PM, Praveen Yalagandula 
 yprav...@avinetworks.com wrote:

 Hi Aaron,

 Thanks for the prompt response.

 If the overlap does not have any negative effect, can we please just
 remove this check? It creates confusion as there are certain code paths
 where we do not perform this check. For example, the current code does NOT
 perform this check when we are updating the list of allowed-address-pairs
 -- I can successfully assign an existing fixed IP address to the
 allowed-address-pairs. The check is being performed on only one code path -
 when assigning fixed IPs.

 If it sounds right to you, I can submit my patch removing this check.

 Thanks,
 Praveen



 On Mon, May 19, 2014 at 12:32 PM, Aaron Rosen aaronoro...@gmail.comwrote:

 Hi,

 Sure, if you look at this method:

 def _check_fixed_ips_and_address_pairs_no_overlap(self, context,
 port):
 address_pairs = self.get_allowed_address_pairs(context,
 port['id'])
 for fixed_ip in port['fixed_ips']:

 for address_pair in address_pairs:

 if (fixed_ip['ip_address'] ==
 address_pair['ip_address']
 and port['mac_address'] ==
 address_pair['mac_address']):
 raise
 addr_pair.AddressPairMatchesPortFixedIPAndMac()



 it checks that the allowed_address_pairs don't overlap with fixed_ips
 and mac_address on the port. The only reason we do this additional check is
 that having the same fixed_ip and mac_address pair as an
 allowed_address_pair would have no effect since the fixed_ip/mac on the
 port inherently allows that traffic through.

 Best,

 Aaron



 On Mon, May 19, 2014 at 12:22 PM, Praveen Yalagandula 
 yprav...@avinetworks.com wrote:

 Hi Aaron,

 In OVS and ML2 plugins, on port-update, there is a check to make sure
 that allowed-address-pairs and fixed-ips don't overlap. Can you please
 explain why that is needed?

 - icehouse final: neutron/plugins/ml2/plugin.py
 

 677 elif changed_fixed_ips:

 678
 self._check_fixed_ips_and_address_pairs_no_overlap(

 679 context, updated_port)
 ---

 Thanks,
 Praveen


 On Wed, Jul 17, 2013 at 3:45 PM, Aaron Rosen aro...@nicira.comwrote:

 Hi Ian,

 For shared networks if the network is set to
 port_security_enabled=True then the tenant will not be able to remove
 port_security_enabled from their port if they are not the owner of the
 network. I believe this is the correct behavior we want. In addition, 
 only
 admin's are able to create shared networks by default.

 I've created the following blueprint
 https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairsand 
 doc:
 https://docs.google.com/document/d/1hyB3dIkRF623JlUsvtQFo9fCKLsy0gN8Jf6SWnqbWWA/edit?usp=sharingwhich
  will provide us a way to do this. It would be awesome if you could
 check it out and let me know what you think.

 Thanks,

 Aaron


 On Tue, Jul 16, 2013 at 10:34 AM, Ian Wells 
 ijw.ubu...@cack.org.ukwrote:

 On 10 July 2013 21:14, Vishvananda Ishaya vishvana...@gmail.com
 wrote:
  It used to be essential back when we had nova-network and all
 tenants
  ended up on one network.  It became less useful when tenants could
  create their own networks and could use them as they saw fit.
 
  It's still got its uses - for instance, it's nice that the
 metadata
  server can be sure that a request is really coming from where it
  claims - but I would very much like it to be possible

Re: [openstack-dev] Chalenges with highly available service VMs

[Aaron Rosen]

Hi,

Sure, if you look at this method:

def _check_fixed_ips_and_address_pairs_no_overlap(self, context, port):

address_pairs = self.get_allowed_address_pairs(context, port['id'])

for fixed_ip in port['fixed_ips']:

for address_pair in address_pairs:

if (fixed_ip['ip_address'] == address_pair['ip_address']

and port['mac_address'] ==
address_pair['mac_address']):
raise addr_pair.AddressPairMatchesPortFixedIPAndMac()



it checks that the allowed_address_pairs don't overlap with fixed_ips and
mac_address on the port. The only reason we do this additional check is
that having the same fixed_ip and mac_address pair as an
allowed_address_pair would have no effect since the fixed_ip/mac on the
port inherently allows that traffic through.

Best,

Aaron



On Mon, May 19, 2014 at 12:22 PM, Praveen Yalagandula 
yprav...@avinetworks.com wrote:

 Hi Aaron,

 In OVS and ML2 plugins, on port-update, there is a check to make sure that
 allowed-address-pairs and fixed-ips don't overlap. Can you please explain
 why that is needed?

 - icehouse final: neutron/plugins/ml2/plugin.py 

 677 elif changed_fixed_ips:

 678 self._check_fixed_ips_and_address_pairs_no_overlap(

 679 context, updated_port)
 ---

 Thanks,
 Praveen


 On Wed, Jul 17, 2013 at 3:45 PM, Aaron Rosen aro...@nicira.com wrote:

 Hi Ian,

 For shared networks if the network is set to port_security_enabled=True
 then the tenant will not be able to remove port_security_enabled from their
 port if they are not the owner of the network. I believe this is the
 correct behavior we want. In addition, only admin's are able to create
 shared networks by default.

 I've created the following blueprint
 https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairs and
 doc:
 https://docs.google.com/document/d/1hyB3dIkRF623JlUsvtQFo9fCKLsy0gN8Jf6SWnqbWWA/edit?usp=sharingwhich
  will provide us a way to do this. It would be awesome if you could
 check it out and let me know what you think.

 Thanks,

 Aaron


 On Tue, Jul 16, 2013 at 10:34 AM, Ian Wells ijw.ubu...@cack.org.ukwrote:

 On 10 July 2013 21:14, Vishvananda Ishaya vishvana...@gmail.com wrote:
  It used to be essential back when we had nova-network and all tenants
  ended up on one network.  It became less useful when tenants could
  create their own networks and could use them as they saw fit.
 
  It's still got its uses - for instance, it's nice that the metadata
  server can be sure that a request is really coming from where it
  claims - but I would very much like it to be possible to, as an
  option, explicitly disable antispoof - perhaps on a per-network basis
  at network creation time - and I think we could do this without
  breaking the security model beyond all hope of usefulness.
 
  Per network and per port makes sense.
 
  After all, this is conceptually the same as enabling or disabling
  port security on your switch.

 Bit late on the reply to this, but I think we should be specific on
 the network, at least at creation time, on what disabling is allowed
 at port level (default off, may be off, must be on as now).  Yes, it's
 exactly like disabling port security, and you're not always the
 administrator of your own switch; if we extend the analogy you
 probably wouldn't necessarily want people turning antispoof off on an
 explicitly shared-tenant network.
 --
 Ian.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Changing glances default policy on setting image public to admin only

[Aaron Rosen]

Hi,

The current default settings that glance ships with allows any tenant to
upload an image and mark it as public for other tenants to use. I'd like to
change the default  (https://review.openstack.org/#/c/92739/) so that only
a admin user can make an image public by default. Allowing any tenant to
make an image public by default might allow a malicious tenant to trick
other tenants into using their disk image which could do harm to
unsuspecting tenants.

Since this is a default setting impact I wanted to ping the mailing list to
see if anyone had any concerns in changing the default. In addition, to
this change in glance the tempest tests will also need to be updated as
well because currently there are tests that have nonadmin tenants upload
images.

Best,

Aaron
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] q-agt error

[Aaron Rosen]

I don't see any error in the above logs you've pasted. I'd check the
nova-compute logs as well.

Aaron


On Mon, May 5, 2014 at 10:51 PM, sonia verma soniaverma9...@gmail.comwrote:

 Hi all

 I want to boot VM from openstack dashboard onto compute node using
 devstack.When I'm booting VM from opensatck dashboard onto compute node,the
 VM status is stuck at 'SPAWNING' and never changes to 'ACTIVE'.  I'm also
 able to get tap interface of the VM onto compute node.I'm getting following
 error in q-agt service...

 Stdout:
 '{data:[[qvo4b71e52b-d1,[map,[[attached-mac,fa:16:3e:83:6d:7c],[iface-id,4b71e52b-d14d-48cc-bbce-0eb07719e830],[iface-status,active],[vm-uuid,037cbf7a-e3b7-401d-b941-9e0b1c5aaf99,[br-tun,[map,[]]],[br-int,[map,[]]],[qvo2ce34d70-ab,[map,[[attached-mac,fa:16:3e:31:97:c4],[iface-id,2ce34d70-ab92-456a-aa12-8823df2c007f],[iface-status,active],[vm-uuid,370a2bec-7a56-4aa4-87d0-a22470e169fe],headings:[name,external_ids]}\n'

 Stderr: '' execute /opt/stack/neutron/neutron/agent/linux/utils.py:73
 2014-05-05 14:00:50.082 14236 DEBUG neutron.agent.linux.utils [-] Running
 command: ['sudo', '/usr/local/bin/neutron-rootwrap',
 '/etc/neutron/rootwrap.conf', 'ovs-vsctl', '--timeout=2', 'list-ports',
 'br-int'] create_process /opt/stack/neutron/neutron/agent/linux/utils.py:47
 2014-05-05 14:00:50.446 14236 DEBUG neutron.agent.linux.utils [-]
 Command: ['sudo', '/usr/local/bin/neutron-rootwrap',
 '/etc/neutron/rootwrap.conf', 'ovs-vsctl', '--timeout=2', 'list-ports',
 'br-int']
 Exit code: 0
 Stdout: 'qvo2ce34d70-ab\nqvo4b71


 Please help regarding this.

 Thanks
 Sonia

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack][Neutron] 2 NICs on Instance Creation not working

[Aaron Rosen]

Hi,

I'm guessing the scripts inside your guest is only setup to configure dhcp
on the first interface. See  /etc/network/interfaces

Best,

Aaron


On Mon, Apr 21, 2014 at 4:59 PM, Hopper, Justin justin.hop...@hp.comwrote:

 They are on separate Networks.

 Justin Hopper
 Software Engineer - DBaaS
 irc: juice | gpg: EA238CF3 | twt: @justinhopper

 From: Kevin Benton blak...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: Monday, April 21, 2014 at 16:54
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Openstack][Neutron] 2 NICs on Instance
 Creation not working

 Are the two NICs on the same or different networks? Currently there is a
 limitation of Nova that does not permit two NICs to be attached to the same
 Neutron network.

 --
 Kevin Benton


 On Mon, Apr 21, 2014 at 4:44 PM, Hopper, Justin justin.hop...@hp.comwrote:

 So we are trying to create an instance (Precise Cloud Image) via nova
 with two NICs.  It appears that the second Interface does not get
 configured.  Does the Image Itself need to contain the configuration for
 the 2nd Interface or is this something the Neuton/Nova should take care of
 us automatically.  I guess the same issue would arise if you would attach a
 2nd Interface to the Instance after it was created (via nova
 interface-attach).

 Thanks,

 Justin Hopper
 Software Engineer - DBaaS
 irc: juice | gpg: EA238CF3 | twt: @justinhopper

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack][nova][Neutron] Launch VM with multiple Ethernet interfaces with I.P. of single subnet.

[Aaron Rosen]

Sorry not really. It's still not clear to me why multiple nics would be
required on the same L2 domain. Would you mind drawing your use case here:
http://asciiflow.com/ (or maybe google docs) labeling the different
interfaces with ips and the flow of packets you want. Also perhaps their
header values. You say Without modifying packet hearders in your email.
I'm guessing your referring to L2 headers? Though I'm still not really
following. Sorry :/


On Wed, Apr 16, 2014 at 10:23 PM, Vikash Kumar 
vikash.ku...@oneconvergence.com wrote:

 Aaron,

   The idea is to steer packets coming from source S1 ( belong to net1)
 destined to destination D1 (belong to net1)  through bunch of L2 appliances
 (like firewall) without modifying packet headers. The core idea is to keep
 appliances (on net1), source S1 (VM on net1) and destination D1(VM on
 net1)  on same broadcast domain. I hope it wl now make sense.


 On Thu, Apr 17, 2014 at 10:47 AM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 Kevin , this can be one approach but not sure. But certainly won't solve
 all cases. :)




 On Thu, Apr 17, 2014 at 10:33 AM, Kevin Benton blak...@gmail.com wrote:

 Yeah, I was aware of allowed address pairs, but that doesn't help with
 the IP allocation part.

 Is this the tenant workflow for this use case?

 1. Create an instance.
 2. Wait to see what which subnet it gets an allocation from.
 3. Pick an IP from that subnet that doesn't currently appear to be in
 use.
 4. Use the neutron-cli or API to update the port object with the extra
 IP.
 5. Hope that Neutron will never allocate that IP address for something
 else.


 On Wed, Apr 16, 2014 at 9:46 PM, Aaron Rosen aaronoro...@gmail.comwrote:

 Whoops Akihiro beat me to it :)


 On Wed, Apr 16, 2014 at 9:46 PM, Aaron Rosen aaronoro...@gmail.comwrote:

 The allowed-address-pair extension that was added here (
 https://review.openstack.org/#/c/38230/) allows us to add arbitrary
 ips to an interface to allow them. This is useful if you want to run
 something like VRRP between two instances.


 On Wed, Apr 16, 2014 at 9:39 PM, Kevin Benton blak...@gmail.comwrote:

 I was under the impression that the security group rules blocked
 addresses not assigned by neutron[1].

 1.
 https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L188


 On Wed, Apr 16, 2014 at 9:20 PM, Aaron Rosen 
 aaronoro...@gmail.comwrote:

 You can do it with ip aliasing and use one interface:

 ifconfig eth0 10.0.0.22/24
 ifconfig eth0:1 10.0.0.23/24
 ifconfig eth0:2 10.0.0.24/24

 2: eth0: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc mq state
 DOWN qlen 1000
 link/ether 40:6c:8f:1a:a9:31 brd ff:ff:ff:ff:ff:ff
 inet 10.0.0.22/24 brd 10.0.0.255 scope global eth0
valid_lft forever preferred_lft forever
 inet 10.0.0.23/24 brd 10.0.0.255 scope global secondary eth0:1
valid_lft forever preferred_lft forever
 inet 10.0.0.24/24 brd 10.0.0.255 scope global secondary eth0:2
valid_lft forever preferred_lft forever



 On Wed, Apr 16, 2014 at 8:53 PM, Kevin Benton blak...@gmail.comwrote:

 Web server running multiple SSL sites that wants to be compatible
 with clients that don't support the SNI extension. There is no way for 
 a
 server to get multiple IP addresses on the same interface is there?


 On Wed, Apr 16, 2014 at 5:50 PM, Aaron Rosen aaronoro...@gmail.com
  wrote:

 This is true. Several people have asked this same question over
 the years though I've yet to hear a use case why one really need to do
 this. Do you have one?


 On Wed, Apr 16, 2014 at 3:12 PM, Ronak Shah 
 ro...@nuagenetworks.net wrote:

 Hi Vikash,
 Currently this is not supported. the NIC not only needs to be in
 different subnet, they have to be in different network as well 
 (container
 for the subnet)

 Thanks
 Ronak

 On Wed, Apr 16, 2014 at 3:51 AM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 *With 'interfaces' I mean 'nics' of VM*.


 On Wed, Apr 16, 2014 at 4:18 PM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 Hi,

  I want to launch one VM which will have two Ethernet
 interfaces with IP of single subnet. Is this supported now in 
 openstack ?
 Any suggestion ?


 Thanx



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack][nova][Neutron] Launch VM with multiple Ethernet interfaces with I.P. of single subnet.

[Aaron Rosen]

Hi Kevin,

You'd would just create ports that aren't attached to instances and steal
their ip_addresses from those ports and put those in the
allowed-address-pairs on a port OR you could change the allocation range on
the subnet to ensure these ips were never handed out. That's probably the
right approach.

Aaron


On Wed, Apr 16, 2014 at 10:03 PM, Kevin Benton blak...@gmail.com wrote:

 Yeah, I was aware of allowed address pairs, but that doesn't help with the
 IP allocation part.

 Is this the tenant workflow for this use case?

 1. Create an instance.
 2. Wait to see what which subnet it gets an allocation from.
 3. Pick an IP from that subnet that doesn't currently appear to be in use.
 4. Use the neutron-cli or API to update the port object with the extra IP.
 5. Hope that Neutron will never allocate that IP address for something
 else.


 On Wed, Apr 16, 2014 at 9:46 PM, Aaron Rosen aaronoro...@gmail.comwrote:

 Whoops Akihiro beat me to it :)


 On Wed, Apr 16, 2014 at 9:46 PM, Aaron Rosen aaronoro...@gmail.comwrote:

 The allowed-address-pair extension that was added here (
 https://review.openstack.org/#/c/38230/) allows us to add arbitrary ips
 to an interface to allow them. This is useful if you want to run something
 like VRRP between two instances.


 On Wed, Apr 16, 2014 at 9:39 PM, Kevin Benton blak...@gmail.com wrote:

 I was under the impression that the security group rules blocked
 addresses not assigned by neutron[1].

 1.
 https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L188


 On Wed, Apr 16, 2014 at 9:20 PM, Aaron Rosen aaronoro...@gmail.comwrote:

 You can do it with ip aliasing and use one interface:

 ifconfig eth0 10.0.0.22/24
 ifconfig eth0:1 10.0.0.23/24
 ifconfig eth0:2 10.0.0.24/24

 2: eth0: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc mq state
 DOWN qlen 1000
 link/ether 40:6c:8f:1a:a9:31 brd ff:ff:ff:ff:ff:ff
 inet 10.0.0.22/24 brd 10.0.0.255 scope global eth0
valid_lft forever preferred_lft forever
 inet 10.0.0.23/24 brd 10.0.0.255 scope global secondary eth0:1
valid_lft forever preferred_lft forever
 inet 10.0.0.24/24 brd 10.0.0.255 scope global secondary eth0:2
valid_lft forever preferred_lft forever



 On Wed, Apr 16, 2014 at 8:53 PM, Kevin Benton blak...@gmail.comwrote:

 Web server running multiple SSL sites that wants to be compatible
 with clients that don't support the SNI extension. There is no way for a
 server to get multiple IP addresses on the same interface is there?


 On Wed, Apr 16, 2014 at 5:50 PM, Aaron Rosen 
 aaronoro...@gmail.comwrote:

 This is true. Several people have asked this same question over the
 years though I've yet to hear a use case why one really need to do 
 this. Do
 you have one?


 On Wed, Apr 16, 2014 at 3:12 PM, Ronak Shah ro...@nuagenetworks.net
  wrote:

 Hi Vikash,
 Currently this is not supported. the NIC not only needs to be in
 different subnet, they have to be in different network as well 
 (container
 for the subnet)

 Thanks
 Ronak

 On Wed, Apr 16, 2014 at 3:51 AM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 *With 'interfaces' I mean 'nics' of VM*.


 On Wed, Apr 16, 2014 at 4:18 PM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 Hi,

  I want to launch one VM which will have two Ethernet
 interfaces with IP of single subnet. Is this supported now in 
 openstack ?
 Any suggestion ?


 Thanx



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack][nova][Neutron] Launch VM with multiple Ethernet interfaces with I.P. of single subnet.

[Aaron Rosen]

Nova currently is preventing one from attaching multiple nics on the same
L2. That said I don't think we've clearly determined a use case for having
multiple nics on the same L2. One reason why we don't allow this is doing
so would allow a tenant to easily loop the network and cause a bcast storm
and neutron doesn't have any mechanism today to break these loops today.
One could just enable STP on ovs to do so though I think we should come up
with a good use case before allowing this type of thing.


On Wed, Apr 16, 2014 at 11:53 PM, Kevin Benton blak...@gmail.com wrote:

 This seems painful for a tenant workflow to get multiple addresses. I
 would like to improve this during the Juno cycle. What is the limitation
 that is blocking the multi-nic use cases? Is it Nova?


 On Wed, Apr 16, 2014 at 11:27 PM, Aaron Rosen aaronoro...@gmail.comwrote:

 Hi Kevin,

 You'd would just create ports that aren't attached to instances and steal
 their ip_addresses from those ports and put those in the
 allowed-address-pairs on a port OR you could change the allocation range on
 the subnet to ensure these ips were never handed out. That's probably the
 right approach.

 Aaron


 On Wed, Apr 16, 2014 at 10:03 PM, Kevin Benton blak...@gmail.com wrote:

 Yeah, I was aware of allowed address pairs, but that doesn't help with
 the IP allocation part.

 Is this the tenant workflow for this use case?

 1. Create an instance.
 2. Wait to see what which subnet it gets an allocation from.
 3. Pick an IP from that subnet that doesn't currently appear to be in
 use.
 4. Use the neutron-cli or API to update the port object with the extra
 IP.
 5. Hope that Neutron will never allocate that IP address for something
 else.


 On Wed, Apr 16, 2014 at 9:46 PM, Aaron Rosen aaronoro...@gmail.comwrote:

 Whoops Akihiro beat me to it :)


 On Wed, Apr 16, 2014 at 9:46 PM, Aaron Rosen aaronoro...@gmail.comwrote:

 The allowed-address-pair extension that was added here (
 https://review.openstack.org/#/c/38230/) allows us to add arbitrary
 ips to an interface to allow them. This is useful if you want to run
 something like VRRP between two instances.


 On Wed, Apr 16, 2014 at 9:39 PM, Kevin Benton blak...@gmail.comwrote:

 I was under the impression that the security group rules blocked
 addresses not assigned by neutron[1].

 1.
 https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L188


 On Wed, Apr 16, 2014 at 9:20 PM, Aaron Rosen 
 aaronoro...@gmail.comwrote:

 You can do it with ip aliasing and use one interface:

 ifconfig eth0 10.0.0.22/24
 ifconfig eth0:1 10.0.0.23/24
 ifconfig eth0:2 10.0.0.24/24

 2: eth0: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc mq state
 DOWN qlen 1000
 link/ether 40:6c:8f:1a:a9:31 brd ff:ff:ff:ff:ff:ff
 inet 10.0.0.22/24 brd 10.0.0.255 scope global eth0
valid_lft forever preferred_lft forever
 inet 10.0.0.23/24 brd 10.0.0.255 scope global secondary eth0:1
valid_lft forever preferred_lft forever
 inet 10.0.0.24/24 brd 10.0.0.255 scope global secondary eth0:2
valid_lft forever preferred_lft forever



 On Wed, Apr 16, 2014 at 8:53 PM, Kevin Benton blak...@gmail.comwrote:

 Web server running multiple SSL sites that wants to be compatible
 with clients that don't support the SNI extension. There is no way for 
 a
 server to get multiple IP addresses on the same interface is there?


 On Wed, Apr 16, 2014 at 5:50 PM, Aaron Rosen aaronoro...@gmail.com
  wrote:

 This is true. Several people have asked this same question over
 the years though I've yet to hear a use case why one really need to do
 this. Do you have one?


 On Wed, Apr 16, 2014 at 3:12 PM, Ronak Shah 
 ro...@nuagenetworks.net wrote:

 Hi Vikash,
 Currently this is not supported. the NIC not only needs to be in
 different subnet, they have to be in different network as well 
 (container
 for the subnet)

 Thanks
 Ronak

 On Wed, Apr 16, 2014 at 3:51 AM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 *With 'interfaces' I mean 'nics' of VM*.


 On Wed, Apr 16, 2014 at 4:18 PM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 Hi,

  I want to launch one VM which will have two Ethernet
 interfaces with IP of single subnet. Is this supported now in 
 openstack ?
 Any suggestion ?


 Thanx



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org

Re: [openstack-dev] Running neutron in child cells

[Aaron Rosen]

Hi Ramkumar,

Today there is no type of cells integration or cells like logic in neutron.
If using nova cells, each cell must share the same neturon deployment. This
neutron deployment though can be scaled out across several neutron servers
behind a loadbalancer though. Another scaling option could be to
potentially deploy different nova regions and providing a set of neutron
servers for each region. The downside of doing this though would be that
you wouldn't be able to span networks across different regions if done this
way.

Best,

Aaron


On Wed, Apr 16, 2014 at 11:44 AM, Gowrishankar, Ramkumar 
rgowrishan...@extremenetworks.com wrote:

  Hello,



 I am trying to figure out if an instance of neutron can be run on the
 controllers of each child cell and if neutron commands sent to the master
 node would then be routed to the child cell similar to how the nova
 commands get routed. I have searched online and as well as in the
 documentation and I have not found any good resource on this.



 Has this been done? What is the current OpenStack model to scale networks
 in Havana and IceHouse?



 Thanks,



 Ramkumar

 --

 DISCLAIMER:
 This e-mail and any attachments to it may contain confidential and
 proprietary material and is solely for the use of the intended recipient.
 Any review, use, disclosure, distribution or copying of this transmittal is
 prohibited except by or on behalf of the intended recipient. If you have
 received this transmittal in error, please notify the sender and destroy
 this e-mail and any attachments and all copies, whether electronic or
 printed.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack][nova][Neutron] Launch VM with multiple Ethernet interfaces with I.P. of single subnet.

[Aaron Rosen]

This is true. Several people have asked this same question over the years
though I've yet to hear a use case why one really need to do this. Do you
have one?


On Wed, Apr 16, 2014 at 3:12 PM, Ronak Shah ro...@nuagenetworks.net wrote:

 Hi Vikash,
 Currently this is not supported. the NIC not only needs to be in different
 subnet, they have to be in different network as well (container for the
 subnet)

 Thanks
 Ronak

 On Wed, Apr 16, 2014 at 3:51 AM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 *With 'interfaces' I mean 'nics' of VM*.


 On Wed, Apr 16, 2014 at 4:18 PM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 Hi,

  I want to launch one VM which will have two Ethernet interfaces
 with IP of single subnet. Is this supported now in openstack ? Any
 suggestion ?


 Thanx



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] API list operations are not fast as they could because they're dumb

[Aaron Rosen]

Hi,

Comments inline:


On Tue, Apr 8, 2014 at 3:16 PM, Salvatore Orlando sorla...@nicira.comwrote:

 I have been recently investigating reports of slowness for list responses
 in the Neutron API.
 This was first reported in [1], and then recently was observed with both
 the ML2 and the NSX plugins.
 The root cause of this issues is that a policy engine check is performed
 for every attribute of every resource returned in a response.
 When tenant grow to a lot of ports, or when the API is executed with admin
 credentials without filters, this might become a non-negligible scale issue.
 This issue is mostly due to three factors:
 1) A log statement printing a line in the log for every attribute for
 which no policy criterion is defined; this has been treated with [2]
 2) The fact that for every check neutron currently checks whether cached
 policy rules are still valid [3]
 3) The fact that anyway Neutron perform really a lot of policy checks
 whether it should not

 Despite the improvements [2] and [3] (mostly [2]), neutron for a list
 operation still spends for post-plugin operations (ie: policy checks) abotu
 50% of the time it spends in the plugin.
 Solving this problem is not difficult, but it might require changes which
 are worth of a discussion on the mailing list.
 Up to the Havana release policy checks were performed in the plugin; this
 basically made responses dependent on plugin implementation and was
 terrible for API compatibility and portability; we took care of that with
 [4], which moved all policy checks to the API layer. However for one fix
 that we fixed, another thing was broken (*)

 The API layer for list responses puts every item through policy checks to
 see which should not be visible to the user at all, which is fine.
 However it also puts every attribute through a policy check to exclude
 those which should not be visible to the user, such as provider attributes
 for regular users.
 Doing this for every resource might make sense if an attribute should be
 visible or not according to the data in the resource itself.
 For instance a policy that shows port binding attributes could be defined
 for all the ports whose name is ernest.
 This might appear as great flexibility, but does it make any sense at all?
 Does it make sense that an API list operation return a set of attributes
 for some items and  a different one for others?
 I think not.

 For this reason I am thinking we should what technically is a simple
 change: use policy cghecks determine the list of attributes to show only
 once for list response, and then re-use that list for the whole response.
 The limitation here is that we should not have 'attribute-level' policies
 (**) which rely on the resource value.
 I think this limitation is fair. If you like the approach I have some code
 here: http://paste.openstack.org/show/75371/


I think this makes sense. In theory the first element of the list should
have all the same columns as the next set of elements so inspecting the
first one should be fine.


 And this leads me to the second part of the discussion I'd like to start.
 The policy engine currently allows me to start a neutron server where, for
 instance, port binding are visible by admins only, and another neutron
 server where any user can see them.
 This kind of makes the API not really portable, as people programming
 against the neutron API might encounter unexpected behaviours.



This doesn't seem like a neutron specific issue to me. If I understand you
correctly what you're saying is if an admin changes the policy.json file to
exclude some data from the response that now the users of the api might
have to change their code? ..port-binding-extension... X.o



 To this aim, one solution would be to 'hardcode' attributes' access rights
 into extensions definition. This way port bindings will always be
 admin_only regardless of which neutron endpoint one is accessing.
 However, there are two drawbacks in this approach:
 1 - This could break existing deployment which tweaked default policy, so
 the upgrade should be carefully planned
 2 - This will make API definitions dependent on entries in policy.json. If
 a policy definition states that an attribute is admin_only, one will also
 have to ensure such policy is defined in policy.json.

 Thanks for reading this email,
 Salvatore

 [1] https://bugs.launchpad.net/neutron/+bug/1236704
 [2] https://bugs.launchpad.net/neutron/+bug/1302467
 [3] https://bugs.launchpad.net/neutron/+bug/1302611
 [4] https://wiki.openstack.org/wiki/Neutron/Make-authz-orthogonal
 (*) typical behaviour of software 'fixed' by Salvatore
 (**) policies such as get_network:provider:network_type.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [Openstack][nova][Neutron] Launch VM with multiple Ethernet interfaces with I.P. of single subnet.

[Aaron Rosen]

Yes please... I don't see why one would need two interfaces on the same L2
to do that though.


On Wed, Apr 16, 2014 at 8:29 PM, Vikash Kumar 
vikash.ku...@oneconvergence.com wrote:

 Aaron,

One of the use case is to create L2 segments in a network. I can
 elaborate this use case if u want.



 On Thu, Apr 17, 2014 at 6:20 AM, Aaron Rosen aaronoro...@gmail.comwrote:

 This is true. Several people have asked this same question over the years
 though I've yet to hear a use case why one really need to do this. Do you
 have one?


 On Wed, Apr 16, 2014 at 3:12 PM, Ronak Shah ro...@nuagenetworks.netwrote:

 Hi Vikash,
 Currently this is not supported. the NIC not only needs to be in
 different subnet, they have to be in different network as well (container
 for the subnet)

 Thanks
 Ronak

 On Wed, Apr 16, 2014 at 3:51 AM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 *With 'interfaces' I mean 'nics' of VM*.


 On Wed, Apr 16, 2014 at 4:18 PM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 Hi,

  I want to launch one VM which will have two Ethernet interfaces
 with IP of single subnet. Is this supported now in openstack ? Any
 suggestion ?


 Thanx



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack][nova][Neutron] Launch VM with multiple Ethernet interfaces with I.P. of single subnet.

[Aaron Rosen]

You can do it with ip aliasing and use one interface:

ifconfig eth0 10.0.0.22/24
ifconfig eth0:1 10.0.0.23/24
ifconfig eth0:2 10.0.0.24/24

2: eth0: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc mq state DOWN
qlen 1000
link/ether 40:6c:8f:1a:a9:31 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.22/24 brd 10.0.0.255 scope global eth0
   valid_lft forever preferred_lft forever
inet 10.0.0.23/24 brd 10.0.0.255 scope global secondary eth0:1
   valid_lft forever preferred_lft forever
inet 10.0.0.24/24 brd 10.0.0.255 scope global secondary eth0:2
   valid_lft forever preferred_lft forever



On Wed, Apr 16, 2014 at 8:53 PM, Kevin Benton blak...@gmail.com wrote:

 Web server running multiple SSL sites that wants to be compatible with
 clients that don't support the SNI extension. There is no way for a server
 to get multiple IP addresses on the same interface is there?


 On Wed, Apr 16, 2014 at 5:50 PM, Aaron Rosen aaronoro...@gmail.comwrote:

 This is true. Several people have asked this same question over the years
 though I've yet to hear a use case why one really need to do this. Do you
 have one?


 On Wed, Apr 16, 2014 at 3:12 PM, Ronak Shah ro...@nuagenetworks.netwrote:

 Hi Vikash,
 Currently this is not supported. the NIC not only needs to be in
 different subnet, they have to be in different network as well (container
 for the subnet)

 Thanks
 Ronak

 On Wed, Apr 16, 2014 at 3:51 AM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 *With 'interfaces' I mean 'nics' of VM*.


 On Wed, Apr 16, 2014 at 4:18 PM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 Hi,

  I want to launch one VM which will have two Ethernet interfaces
 with IP of single subnet. Is this supported now in openstack ? Any
 suggestion ?


 Thanx



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack][nova][Neutron] Launch VM with multiple Ethernet interfaces with I.P. of single subnet.

[Aaron Rosen]

Hi Vikash,

Sorry I don't really follow your example. You're saying you have have two
hosts S1 and S2 that are connected to the same network. Would you mind
explaining this example in a little more details, what ip's do they have
how many interfaces, etc? I've quite curious to hear.


Best,

Aaron

P.S: Another reason why we don't really want to allow this is it allows a
tenant to easily loop the network by bridging these two interfaces within
their instance.


On Wed, Apr 16, 2014 at 9:35 PM, Vikash Kumar 
vikash.ku...@oneconvergence.com wrote:

 Lets say I have source S1 on n/w net1, destination S2 on net1 and i want
 to firewall traffic coming from S1 destined to S2. I can use L3 firewall
 but in that case the packet headers will have different values, not the
 same source and destination. Instead, we can divide network in L2 segments
 and steer packets to get the necessary processing. Though I didn't covered
 the minute details but hope kept my point. And yes this aliasing thing
 isn't the way to solve it.


 On Thu, Apr 17, 2014 at 9:23 AM, Kevin Benton blak...@gmail.com wrote:

 Web server running multiple SSL sites that wants to be compatible with
 clients that don't support the SNI extension. There is no way for a server
 to get multiple IP addresses on the same interface is there?


 On Wed, Apr 16, 2014 at 5:50 PM, Aaron Rosen aaronoro...@gmail.comwrote:

 This is true. Several people have asked this same question over the
 years though I've yet to hear a use case why one really need to do this. Do
 you have one?


 On Wed, Apr 16, 2014 at 3:12 PM, Ronak Shah ro...@nuagenetworks.netwrote:

 Hi Vikash,
 Currently this is not supported. the NIC not only needs to be in
 different subnet, they have to be in different network as well (container
 for the subnet)

 Thanks
 Ronak

 On Wed, Apr 16, 2014 at 3:51 AM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 *With 'interfaces' I mean 'nics' of VM*.


 On Wed, Apr 16, 2014 at 4:18 PM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 Hi,

  I want to launch one VM which will have two Ethernet interfaces
 with IP of single subnet. Is this supported now in openstack ? Any
 suggestion ?


 Thanx



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack][nova][Neutron] Launch VM with multiple Ethernet interfaces with I.P. of single subnet.

[Aaron Rosen]

The allowed-address-pair extension that was added here (
https://review.openstack.org/#/c/38230/) allows us to add arbitrary ips to
an interface to allow them. This is useful if you want to run something
like VRRP between two instances.


On Wed, Apr 16, 2014 at 9:39 PM, Kevin Benton blak...@gmail.com wrote:

 I was under the impression that the security group rules blocked addresses
 not assigned by neutron[1].

 1.
 https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L188


 On Wed, Apr 16, 2014 at 9:20 PM, Aaron Rosen aaronoro...@gmail.comwrote:

 You can do it with ip aliasing and use one interface:

 ifconfig eth0 10.0.0.22/24
 ifconfig eth0:1 10.0.0.23/24
 ifconfig eth0:2 10.0.0.24/24

 2: eth0: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc mq state DOWN
 qlen 1000
 link/ether 40:6c:8f:1a:a9:31 brd ff:ff:ff:ff:ff:ff
 inet 10.0.0.22/24 brd 10.0.0.255 scope global eth0
valid_lft forever preferred_lft forever
 inet 10.0.0.23/24 brd 10.0.0.255 scope global secondary eth0:1
valid_lft forever preferred_lft forever
 inet 10.0.0.24/24 brd 10.0.0.255 scope global secondary eth0:2
valid_lft forever preferred_lft forever



 On Wed, Apr 16, 2014 at 8:53 PM, Kevin Benton blak...@gmail.com wrote:

 Web server running multiple SSL sites that wants to be compatible with
 clients that don't support the SNI extension. There is no way for a server
 to get multiple IP addresses on the same interface is there?


 On Wed, Apr 16, 2014 at 5:50 PM, Aaron Rosen aaronoro...@gmail.comwrote:

 This is true. Several people have asked this same question over the
 years though I've yet to hear a use case why one really need to do this. Do
 you have one?


 On Wed, Apr 16, 2014 at 3:12 PM, Ronak Shah ro...@nuagenetworks.netwrote:

 Hi Vikash,
 Currently this is not supported. the NIC not only needs to be in
 different subnet, they have to be in different network as well (container
 for the subnet)

 Thanks
 Ronak

 On Wed, Apr 16, 2014 at 3:51 AM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 *With 'interfaces' I mean 'nics' of VM*.


 On Wed, Apr 16, 2014 at 4:18 PM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 Hi,

  I want to launch one VM which will have two Ethernet interfaces
 with IP of single subnet. Is this supported now in openstack ? Any
 suggestion ?


 Thanx



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack][nova][Neutron] Launch VM with multiple Ethernet interfaces with I.P. of single subnet.

[Aaron Rosen]

Whoops Akihiro beat me to it :)


On Wed, Apr 16, 2014 at 9:46 PM, Aaron Rosen aaronoro...@gmail.com wrote:

 The allowed-address-pair extension that was added here (
 https://review.openstack.org/#/c/38230/) allows us to add arbitrary ips
 to an interface to allow them. This is useful if you want to run something
 like VRRP between two instances.


 On Wed, Apr 16, 2014 at 9:39 PM, Kevin Benton blak...@gmail.com wrote:

 I was under the impression that the security group rules blocked
 addresses not assigned by neutron[1].

 1.
 https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L188


 On Wed, Apr 16, 2014 at 9:20 PM, Aaron Rosen aaronoro...@gmail.comwrote:

 You can do it with ip aliasing and use one interface:

 ifconfig eth0 10.0.0.22/24
 ifconfig eth0:1 10.0.0.23/24
 ifconfig eth0:2 10.0.0.24/24

 2: eth0: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc mq state
 DOWN qlen 1000
 link/ether 40:6c:8f:1a:a9:31 brd ff:ff:ff:ff:ff:ff
 inet 10.0.0.22/24 brd 10.0.0.255 scope global eth0
valid_lft forever preferred_lft forever
 inet 10.0.0.23/24 brd 10.0.0.255 scope global secondary eth0:1
valid_lft forever preferred_lft forever
 inet 10.0.0.24/24 brd 10.0.0.255 scope global secondary eth0:2
valid_lft forever preferred_lft forever



 On Wed, Apr 16, 2014 at 8:53 PM, Kevin Benton blak...@gmail.com wrote:

 Web server running multiple SSL sites that wants to be compatible with
 clients that don't support the SNI extension. There is no way for a server
 to get multiple IP addresses on the same interface is there?


 On Wed, Apr 16, 2014 at 5:50 PM, Aaron Rosen aaronoro...@gmail.comwrote:

 This is true. Several people have asked this same question over the
 years though I've yet to hear a use case why one really need to do this. 
 Do
 you have one?


 On Wed, Apr 16, 2014 at 3:12 PM, Ronak Shah 
 ro...@nuagenetworks.netwrote:

 Hi Vikash,
 Currently this is not supported. the NIC not only needs to be in
 different subnet, they have to be in different network as well (container
 for the subnet)

 Thanks
 Ronak

 On Wed, Apr 16, 2014 at 3:51 AM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 *With 'interfaces' I mean 'nics' of VM*.


 On Wed, Apr 16, 2014 at 4:18 PM, Vikash Kumar 
 vikash.ku...@oneconvergence.com wrote:

 Hi,

  I want to launch one VM which will have two Ethernet
 interfaces with IP of single subnet. Is this supported now in 
 openstack ?
 Any suggestion ?


 Thanx



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] [NOVA] Missing network info in nova list

[Aaron Rosen]

Hi Slawek,

Interesting, I haven't seen this issue of network info not showing up on
nova list and the instance being in ACTIVE state. Could you check out the
nova logs and see if there are any TRACE's there?  If you're using icehouse
you should be able to do neutron port-update port_id that maps to the
instance's port and doing that will send a notification to nova  to update
it's cache for the instance.

Best,

Aaron


On Tue, Apr 1, 2014 at 12:10 AM, Sławek Kapłoński sla...@kaplonski.plwrote:

 Hello,

 Maybe the problem is not that missing data in nova's database becasue when
 I
 made:
 nova --debug list
 then I see that it is asking neutron about ports and this missing IP is
 corretly send from neutron.
 Also when I made:
 nova interface-list instance_id
 then there is no problem and IP is displayed. But still this IP is missing
 in
 list of instances and I displaying instance details (also in horizon).

 --
 Best regards
 Sławek Kapłoński

 Dnia poniedziałek, 31 marca 2014 18:17:18 Sławek Kapłoński pisze:
  Hello,
 
  I have openstack installation with neutron. When I made test and create
  many instances in one query (using --num-instances) all was ok but one
  instance (from 80 created) has no IP address when I made nova list or
  nova show . I found that there is missing value in network info in
  nova database in Instance-info-cache table. Everything except that is
  working fine: port with this IP is assigned to instance in neutron,
  binding is ok, instance has got configured this IP and I can ping it.
  Maybe someone know why this informations are missing in nova database
  and how to refresh it?

 ___
 Mailing list:
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
 Post to : openst...@lists.openstack.org
 Unsubscribe :
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron]Success to create securitygroup with invalid tenant_id. Does it need to check the tenant_id?

[Aaron Rosen]

Hi Lee,

No, currently only an admin user can create something with a different
tenant_id by default. The issue with validating the tenant_id is we need to
involve keystone in order to check if the tenant_id is valid (which will
cause things to slow down). I believe this question has already come up on
the list before if you want to search the archive. This issue isn't
specific to just security_groups in neutron its allowed with all neutron
resources.

Aaron



On Tue, Apr 1, 2014 at 1:58 AM, 黎林果 lilinguo8...@gmail.com wrote:

 Hi,
all

Such as the subject, there is no mechanism to check the tenant_id, Do
 you think it is necessary?


Thanks!

Lee Li

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

[Aaron Rosen]

The easiest/quickest thing to do for ice house would probably be to run the
initial sync in parallel like the dhcp-agent does for this exact reason.
See: https://review.openstack.org/#/c/28914/ which did this for thr
dhcp-agent.

Best,

Aaron
On Thu, Mar 13, 2014 at 12:18 PM, Miguel Angel Ajo majop...@redhat.comwrote:

 Yuri, could you elaborate your idea in detail? , I'm lost at some
 points with your unix domain / token authentication.

 Where does the token come from?,

 Who starts rootwrap the first time?

 If you could write a full interaction sequence, on the etherpad, from
 rootwrap daemon start ,to a simple call to system happening, I think that'd
 help my understanding.


Here it is: https://etherpad.openstack.org/p/rootwrap-agent
Please take a look.

-- 

Kind regards, Yuriy.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

[Aaron Rosen]

We had this same issue with the dhcp-agent. Code was added that paralleled
the initial sync here: https://review.openstack.org/#/c/28914/  that made
things a good bit faster if I remember correctly.  Might be worth doing
something similar for the l3-agent.

Best,

Aaron


On Mon, Mar 10, 2014 at 5:07 PM, Joe Gordon joe.gord...@gmail.com wrote:




 On Mon, Mar 10, 2014 at 3:57 PM, Joe Gordon joe.gord...@gmail.com wrote:

 I looked into the python to C options and haven't found anything
 promising yet.


 I tried Cython, and RPython, on a trivial hello world app, but git
 similar startup times to standard python.

 The one thing that did work was adding a '-S' when starting python.

-S Disable the import of the module site and the
 site-dependent manipulations of sys.path that it entails.


 Using 'python -S' didn't appear to help in devstack

 #!/usr/bin/python -S
 # PBR Generated from u'console_scripts'

 import sys
 import site
 site.addsitedir('/mnt/stack/oslo.rootwrap/oslo/rootwrap')





 I am not sure if we can do that for rootwrap.


 jogo@dev:~/tmp/pypy-2.2.1-src$ time ./tmp-c
 hello world

 real0m0.021s
 user0m0.000s
 sys 0m0.020s
 jogo@dev:~/tmp/pypy-2.2.1-src$ time ./tmp-c
 hello world

 real0m0.021s
 user0m0.000s
 sys 0m0.020s
 jogo@dev:~/tmp/pypy-2.2.1-src$ time python -S ./tmp.py
 hello world

 real0m0.010s
 user0m0.000s
 sys 0m0.008s

 jogo@dev:~/tmp/pypy-2.2.1-src$ time python -S ./tmp.py
 hello world

 real0m0.010s
 user0m0.000s
 sys 0m0.008s



 On Mon, Mar 10, 2014 at 3:26 PM, Miguel Angel Ajo Pelayo 
 mangel...@redhat.com wrote:

 Hi Carl, thank you, good idea.

 I started reviewing it, but I will do it more carefully tomorrow morning.



 - Original Message -
  All,
 
  I was writing down a summary of all of this and decided to just do it
  on an etherpad.  Will you help me capture the big picture there?  I'd
  like to come up with some actions this week to try to address at least
  part of the problem before Icehouse releases.
 
  https://etherpad.openstack.org/p/neutron-agent-exec-performance
 
  Carl
 
  On Mon, Mar 10, 2014 at 5:26 AM, Miguel Angel Ajo majop...@redhat.com
 
  wrote:
   Hi Yuri  Stephen, thanks a lot for the clarification.
  
   I'm not familiar with unix domain sockets at low level, but , I
 wonder
   if authentication could be achieved just with permissions (only
 users in
   group neutron or group rootwrap accessing this service.
  
   I find it an interesting alternative, to the other proposed
 solutions, but
   there are some challenges associated with this solution, which could
 make
   it
   more complicated:
  
   1) Access control, file system permission based or token based,
  
   2) stdout/stderr/return encapsulation/forwarding to the caller,
  if we have a simple/fast RPC mechanism we can use, it's a matter
  of serializing a dictionary.
  
   3) client side implementation for 1 + 2.
  
   4) It would need to accept new domain socket connections in green
 threads
   to
   avoid spawning a new process to handle a new connection.
  
   The advantages:
  * we wouldn't need to break the only-python-rule.
  * we don't need to rewrite/translate rootwrap.
  
   The disadvantages:
 * it needs changes on the client side (neutron + other projects),
  
  
   Cheers,
   Miguel Ángel.
  
  
  
   On 03/08/2014 07:09 AM, Yuriy Taraday wrote:
  
   On Fri, Mar 7, 2014 at 5:41 PM, Stephen Gran
   stephen.g...@theguardian.com mailto:stephen.g...@theguardian.com
 
   wrote:
  
   Hi,
  
   Given that Yuriy says explicitly 'unix socket', I dont think he
   means 'MQ' when he says 'RPC'.  I think he just means a daemon
   listening on a unix socket for execution requests.  This seems
 like
   a reasonably sensible idea to me.
  
  
   Yes, you're right.
  
   On 07/03/14 12:52, Miguel Angel Ajo wrote:
  
  
   I thought of this option, but didn't consider it, as It's
 somehow
   risky to expose an RPC end executing priviledged (even
 filtered)
   commands.
  
  
   subprocess module have some means to do RPC securely over UNIX
 sockets.
   I does this by passing some token along with messages. It should be
   secure because with UNIX sockets we don't need anything stronger
 since
   MITM attacks are not possible.
  
   If I'm not wrong, once you have credentials for messaging,
 you can
   send messages to any end, even filtered, I somehow see this
 as a
   higher
   risk option.
  
  
   As Stephen noted, I'm not talking about using MQ for RPC. Just some
   local UNIX socket with very simple RPC over it.
  
   And btw, if we add RPC in the middle, it's possible that
 all those
   system call delays increase, or don't decrease all it'll be
   desirable.
  
  
   Every call to rootwrap would require the following.
  
   Client side:
   - new client socket;
   - one message sent;
   - 

Re: [openstack-dev] No route matched for POST

[Aaron Rosen]

Hi Vijay,

I think you'd have to post you're code for anyone to really help you.
Otherwise we'll just be taking shots in the dark.

Best,

Aaron


On Mon, Mar 10, 2014 at 7:22 PM, Vijay B os.v...@gmail.com wrote:

 Hi,

 I'm trying to implement a new extension API in neutron, but am running
 into a No route matched for POST on the neutron service.

 I have followed the instructions in the link
 https://wiki.openstack.org/wiki/NeutronDevelopment#API_Extensions when
 trying to implement this extension.

 The extension doesn't depend on any plug in per se, akin to security
 groups.

 I have defined a new file in neutron/extensions/, called Tag.py, with a
 class Tag extending class extensions.ExtensionDescriptor, like the
 documentation requires. Much like many of the other extensions already
 implemented, I define my new extension as a dictionary, with fields like
 allow_post/allow_put etc, and then pass this to the controller. I still
 however run into a no route matched for POST error when I attempt to fire
 my CLI to create a tag. I also edited the ml2 plugin file
 neutron/plugins/ml2/plugin.py to add tags to
 _supported_extension_aliases, but that didn't resolve the issue.

 It looks like I'm missing something quite minor, causing the the new
 extension to not get registered, but I'm not sure what.

 I can provide more info/patches if anyone would like to take a look, and
 it would be very much appreciated if someone could help me out with this.

 Thanks!
 Regards,
 Vijay

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Aaron Rosen]

Hi Nader,

Devstack's default plugin is ML2. Usually you wouldn't 'inherit' one plugin
in another. I'm guessing  you probably wire a driver that ML2 can use
though it's hard to tell from the information you've provided what you're
trying to do.

Best,

Aaron


On Wed, Mar 5, 2014 at 10:42 PM, Nader Lahouti nader.laho...@gmail.comwrote:

 Hi All,

 I have a question regarding ML2 plugin in neutron:
 My understanding is that, 'Ml2Plugin' is the default core_plugin for
 neutron ML2. We can use either the default plugin or our own plugin (i.e.
 my_ml2_core_plugin that can be inherited from Ml2Plugin) and use it as
 core_plugin.

 Is my understanding correct?


 Regards,
 Nader.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][neutron][keystone] getting keystone endpoints

[Aaron Rosen]

Hi,

Dan Smith and I have been working on the integration between nova and
neutron to have neutron issue callbacks into nova to trigger certain
events. One of the things I'm trying to figure out is how to support
multiple nova regions with this kind of interaction since neutron would now
needs to know which nova-api endpoint to send an event to. My current train
of thought is that if you're running with multiple regions that we should
require each nova-compute host to set os_region_name in it's nova.conf
(this seems to already be a requirement for cinder with multiple regions).
Then, we'll pass os_region_name in the port so that neutron can be aware of
the region each port lives  (accomplished here [1][2]).

The second part of the problem where the difficulty seems to be is when
neutron needs to notify nova as we'll need to determine the nova endpoint
that we should send to. It looks like one way we can go about this is by
caching the latest X_SERVICE_CATALOG value from the request to neutron
(which contains the list of keystone endpoints). This seems to be provided
by default, though there is a configuration option here to disable it [3].
I just want to make sure if we go this route that is the right decision.

The other options could be to statically configure the endpoints in neutron
which might not be ideal as if they change you'd have to update that value
in multiple places (this would definitely make things simpler though :) and
would be reliable as well. ). Alternatively, have neutron query keystone
for the endpoints periodically with some caching in combination with
using X_SERVICE_CATALOG. This would be helpful in the case were neutron
doesn't see any new requests and has an out dated catalog list until it
sees another request (which could be possible if there isn't much turn in
the system).

I was curious if anyone had any other ideas/thoughts on how to tackle this
or which approach makes the most sense.

Best,

Aaron

[1] - https://review.openstack.org/#/c/76379/

[2] -https://review.openstack.org/#/c/76411/

[3] -
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L296
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] False Positive testing for 3rd party CI

[Aaron Rosen]

Hi,

Yesterday, I pushed a patch to review and was surprised that several of the
third party CI systems reported back that the patch-set worked where it
definitely shouldn't have. Anyways, I tested out my theory a little more
and it turns out a few of the 3rd party CI systems for neutron are just
returning  SUCCESS even if the patch set didn't run successfully (
https://review.openstack.org/#/c/75304/).

Here's a short summery of what I found.

Hyper-V CI -- This seems like an easy fix as it's posting build succeeded
but also puts to the side test run failed. Would probably be a good idea
to remove the build succeeded message to avoid any confusion.


Brocade CI - From the log files it posts it shows that it tries to apply my
patch but fails:

2014-02-20 20:23:48 + cd /opt/stack/neutron
2014-02-20 20:23:48 + git fetch
https://review.openstack.org/openstack/neutron.git
refs/changes/04/75304/1
2014-02-20 20:24:00 From https://review.openstack.org/openstack/neutron
2014-02-20 20:24:00  * branchrefs/changes/04/75304/1 - FETCH_HEAD
2014-02-20 20:24:00 + git checkout FETCH_HEAD
2014-02-20 20:24:00 error: Your local changes to the following files
would be overwritten by checkout:
2014-02-20 20:24:00 etc/neutron/plugins/ml2/ml2_conf_brocade.ini
2014-02-20 20:24:00 neutron/plugins/ml2/drivers/brocade/mechanism_brocade.py
2014-02-20 20:24:00 Please, commit your changes or stash them before
you can switch branches.
2014-02-20 20:24:00 Aborting
2014-02-20 20:24:00 + cd /opt/stack/neutron

but still continues running (without my patchset) and reports success. --
This actually looks like a devstack bug  (i'll check it out).

PLUMgrid CI - Seems to always vote +1 without a failure (
https://review.openstack.org/#/dashboard/10117) though the logs are private
so we can't really tell whats going on.

I was thinking it might be worth while or helpful to have a job that tests
that CI is actually fails when we expect it to.

Best,

Aaron
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] False Positive testing for 3rd party CI

[Aaron Rosen]

This should fix the false positive for brocade:
https://review.openstack.org/#/c/75486/

Aaron


On Fri, Feb 21, 2014 at 10:34 AM, Aaron Rosen aaronoro...@gmail.com wrote:

 Hi,

 Yesterday, I pushed a patch to review and was surprised that several of
 the third party CI systems reported back that the patch-set worked where it
 definitely shouldn't have. Anyways, I tested out my theory a little more
 and it turns out a few of the 3rd party CI systems for neutron are just
 returning  SUCCESS even if the patch set didn't run successfully (
 https://review.openstack.org/#/c/75304/).

 Here's a short summery of what I found.

 Hyper-V CI -- This seems like an easy fix as it's posting build
 succeeded but also puts to the side test run failed. Would probably be a
 good idea to remove the build succeeded message to avoid any confusion.


 Brocade CI - From the log files it posts it shows that it tries to apply
 my patch but fails:

 2014-02-20 20:23:48 + cd /opt/stack/neutron
 2014-02-20 20:23:48 + git fetch 
 https://review.openstack.org/openstack/neutron.git refs/changes/04/75304/1
 2014-02-20 20:24:00 From https://review.openstack.org/openstack/neutron
 2014-02-20 https://review.openstack.org/openstack/neutron2014-02-20 
 20:24:00  * branchrefs/changes/04/75304/1 - FETCH_HEAD
 2014-02-20 20:24:00 + git checkout FETCH_HEAD
 2014-02-20 20:24:00 error: Your local changes to the following files would be 
 overwritten by checkout:
 2014-02-20 20:24:00   etc/neutron/plugins/ml2/ml2_conf_brocade.ini
 2014-02-20 20:24:00   neutron/plugins/ml2/drivers/brocade/mechanism_brocade.py
 2014-02-20 20:24:00 Please, commit your changes or stash them before you can 
 switch branches.
 2014-02-20 20:24:00 Aborting
 2014-02-20 20:24:00 + cd /opt/stack/neutron

 but still continues running (without my patchset) and reports success. --
 This actually looks like a devstack bug  (i'll check it out).

 PLUMgrid CI - Seems to always vote +1 without a failure (
 https://review.openstack.org/#/dashboard/10117) though the logs are
 private so we can't really tell whats going on.

 I was thinking it might be worth while or helpful to have a job that tests
 that CI is actually fails when we expect it to.

 Best,

 Aaron


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][nova] Neutron plugin authors: Does port status indicate liveness?

[Aaron Rosen]

Hi Mathieu,

The current train of thought is to have neutron notify nova via a call back
when ports are ready. This model should hopefully scale better as now
nova-compute won't need to poll on neutron checking on the port status. Dan
Smith already has a patch out that adds an api to nova for it to receive
external events : https://review.openstack.org/#/c/74565/  that neutron can
use for this.

I abandoned that patch as it takes the approach of polling neutron from
nova-compute which we don't want.

Aaron


On Wed, Feb 19, 2014 at 12:58 AM, Mathieu Rohon mathieu.ro...@gmail.comwrote:

 Hi Aaron,

 You seem to have abandonned this patch :
 https://review.openstack.org/#/c/74218/

 You want neutron to update port in nova, can you please tell us how do
 you want to do that?

 I think that we should use such a mechanism for live-migration.
 live-migration should occur once the port is set up on the destination
 host. This could potentially resolve this bug :

 https://bugs.launchpad.net/neutron/+bug/1274160

 Best,

 Mathieu

 On Tue, Feb 18, 2014 at 2:55 AM, Aaron Rosen aaronoro...@gmail.com
 wrote:
  Hi Maru,
 
  Thanks for getting this thread started. I've filed the following
 blueprint
  for this:
 
  https://blueprints.launchpad.net/nova/+spec/check-neutron-port-status
 
  and have a have a prototype of it working here:
 
  https://review.openstack.org/#/c/74197/
  https://review.openstack.org/#/c/74218/
 
  One part that threw me a little while getting this working is that if
 using
  ovs and the new libvirt_vif_driver LibvirtGenericVifDriver, nova no
 longer
  calls ovs-vsctl to set external_ids:iface-id and that libvirt
 automatically
  does that for you. Unfortunately, this data seems to only make it to
 ovsdb
  when the instance is powered on. Because of this I needed to add back
 those
  calls as neutron needs this data to be set in ovsdb before it can start
  wiring the ports.
 
  I'm hoping this change should help out with
  https://bugs.launchpad.net/neutron/+bug/1253896 but we'll see. I'm not
 sure
  if it's to late to merge this in icehouse but it might be worth
 considering
  if we find that it helps reduce gate failures.
 
  Best,
 
  Aaron
 
 
  On Thu, Feb 13, 2014 at 3:31 AM, Mathieu Rohon mathieu.ro...@gmail.com
  wrote:
 
  +1 for this feature which could potentially resolve a race condition
  that could occur after port-binding refactoring in ML2 [1].
  in ML2, the port could be ACTIVE once a MD has bound the port. the
  vif_type could then be known by nova, and nova could create the
  network correctly thanks to vif_type and vif_details ( with
  vif_security embedded [2])
 
 
  [1]
 http://lists.openstack.org/pipermail/openstack-dev/2014-February/026750.html
  [2]https://review.openstack.org/#/c/72452/
 
  On Thu, Feb 13, 2014 at 3:13 AM, Maru Newby ma...@redhat.com wrote:
   Booting a Nova instance when Neutron is enabled is often unreliable
 due
   to the lack of coordination between Nova and Neutron apart from port
   allocation.  Aaron Rosen and I have been talking about fixing this by
 having
   Nova perform a check for port 'liveness' after vif plug and before vm
 boot.
   The idea is to have Nova fail the instance if its ports are not seen
 to be
   'live' within a reasonable timeframe after plug.  Our initial thought
 is
   that the compute node would call Nova's networking subsystem which
 could
   query Neutron for the status of the instance's ports.
  
   The open question is whether the port 'status' field can be relied
 upon
   to become ACTIVE for all the plugins currently in the tree.  If this
 is not
   the case, please reply to this thread with an indication of how one
 would be
   able to tell the 'liveness' of a port managed by the plugin you
 maintain.
  
   In the event that one or more plugins cannot reliably indicate port
   liveness, we'll need to ensure that the port liveness check can be
   optionally disabled so that the existing behavior of racing vm boot is
   maintained for plugins that need it.
  
   Thanks in advance,
  
  
   Maru
  
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Nominate Oleg Bondarev for Core

[Aaron Rosen]

+1
On Feb 16, 2014 8:10 PM, Armando M. arma...@gmail.com wrote:

 +1
 On Feb 13, 2014 5:52 PM, Nachi Ueno na...@ntti3.com wrote:

 +1

 2014年2月12日水曜日、Mayur Patilram.nath241...@gmail.comさんは書きました:

 +1

 *--*
 *Cheers,*
 *Mayur*


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Support for multiple provider networks with same VLAN segmentation id

[Aaron Rosen]

Hi Vinay,


On Tue, Feb 11, 2014 at 4:20 PM, Vinay Bannai vban...@gmail.com wrote:

 One way to look at the VLANs is that it identifies a security zone that
 meets some regulatory compliance standards. The VLANs on each rack are
 separated from other VLANs by using VRF. Tenants in our case map to
 applications. So each application is served by a VIP with a pool of VMs. So
 all applications needing regulatory compliance would map to this VLAN. Make
 sense?


Yes, I understand your desire to do this though I think that networks
should identify a security zone and not a vlan.


 As far your question about keeping mac_addresses unique, isn't that
 achieved by the fact that each VM will have a unique mac since it is the
 same control plane allocating the mac address? Or did I miss something??


If I understand correctly what you want to do is to be able to create two
network sharing the same vlan (i.e):

neutron net-create net1 --provider:network_type=vlan
--provider:segmentation_id=1
neutron net-create net2 --provider:network_type=vlan
--provider:segmentation_id=1

in this case the mac_address uniqueness is not preserved as neutron
enforces those per networks and doesn't look at the segmentation_id part at
all.

It seems to me that you want something that allows you to share a network
between specific tenants only? I understand that sharing the same vlan
between tenants does accomplish this but it would be better if we were able
to do this type of thing regardless of the network_type.


 Vinay


 On Tue, Feb 11, 2014 at 12:32 PM, Aaron Rosen aaronoro...@gmail.comwrote:

 I believe it would need to be like:

  network_vlan_ranges = physnet1:100:300, phynet2:100:300, phynet3:100:300


 Additional comments inline:

 On Mon, Feb 10, 2014 at 8:49 PM, Vinay Bannai vban...@gmail.com wrote:

 Bob and Kyle,

 Thanks for your review.
 We looked at this option and it seems it might meet our needs. Here is
 what we intend to do:

 Let's say we have three racks (each rack supports three VLANs - 100, 200
 and 300).
 We create the following config file for the neutron server




 tenant_network_type = vlan
  network_vlan_ranges = physnet1:100:300
  network_vlan_ranges = phynet2:100:300
  network_vlan_ranges = phynet3:100:300
  integration_bridge = br-int
  bridge_mappings = physnet1:br-eth1, physnet2:br-eth1, physnet3:br-eth1
 Is this what you meant?

 Vinay


 On Sun, Feb 9, 2014 at 6:03 PM, Robert Kukura rkuk...@redhat.comwrote:

 On 02/09/2014 12:56 PM, Kyle Mestery wrote:
  On Feb 6, 2014, at 5:24 PM, Vinay Bannai vban...@gmail.com wrote:
 
  Hello Folks,
 
  We are running into a situation where we are not able to create
 multiple provider networks with the same VLAN id. We would like to propose
 a solution to remove this restriction through a configuration option. This
 approach would not conflict with the present behavior where it is not
 possible to create multiple provider networks with the same VLAN id.
 
  The changes should be minimal and would like to propose it for the
 next summit. The use case for this need is documented in the blueprint
 specification.
  Any feedback or comments are welcome.
 
 
 https://blueprints.launchpad.net/neutron/+spec/duplicate-providernet-vlans
 
  Hi Vinay:
 
  This problem seems straightforward enough, though currently you are
 right
  in that we don't allow multiple Neutron networks to have the same
 segmentation
  ID. I've added myself as approver for this BP and look forward to
 further
  discussions of this before and during the upcoming Summit!


 I kind of feel like allowing a vlan to span multiple networks is kind of
 wonky. I feel like a better abstraction would be if we had better access
 control over shared networks between tenants. This way we could explicitly
 allow two tenants to share a network. Is this the problem you are trying to
 solve though doing it with the same vlan?  How do you plan on enforcing
 that mac_addresses are unique on the same physical network?

  Multiple networks with network_type of 'vlan' are already allowed to
 have the same segmentation ID with the ml2, openvswitch, or linuxbridge
 plugins - the networks just need to have different physical_network
 names.


 This is the same for the NSX plugin as well.


  If they have the same network_type, physical_network, and
 segmentation_id, they are the same network. What else would distinguish
 them from each other?

 Could your use case be addressed by simply using different
 physical_network names for each rack? This would provide independent
 spaces of segmentation_ids for each.

 -Bob

 
  Thanks!
  Kyle
 
  Thanks
  --
  Vinay Bannai
  Email: vban...@gmail.com
  Google Voice: 415 938 7576
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http

Re: [openstack-dev] [Neutron] Support for multiple provider networks with same VLAN segmentation id

[Aaron Rosen]

I believe it would need to be like:

 network_vlan_ranges = physnet1:100:300, phynet2:100:300, phynet3:100:300

Additional comments inline:

On Mon, Feb 10, 2014 at 8:49 PM, Vinay Bannai vban...@gmail.com wrote:

 Bob and Kyle,

 Thanks for your review.
 We looked at this option and it seems it might meet our needs. Here is
 what we intend to do:

 Let's say we have three racks (each rack supports three VLANs - 100, 200
 and 300).
 We create the following config file for the neutron server




 tenant_network_type = vlan
  network_vlan_ranges = physnet1:100:300
  network_vlan_ranges = phynet2:100:300
  network_vlan_ranges = phynet3:100:300
  integration_bridge = br-int
  bridge_mappings = physnet1:br-eth1, physnet2:br-eth1, physnet3:br-eth1
 Is this what you meant?

 Vinay


 On Sun, Feb 9, 2014 at 6:03 PM, Robert Kukura rkuk...@redhat.com wrote:

 On 02/09/2014 12:56 PM, Kyle Mestery wrote:
  On Feb 6, 2014, at 5:24 PM, Vinay Bannai vban...@gmail.com wrote:
 
  Hello Folks,
 
  We are running into a situation where we are not able to create
 multiple provider networks with the same VLAN id. We would like to propose
 a solution to remove this restriction through a configuration option. This
 approach would not conflict with the present behavior where it is not
 possible to create multiple provider networks with the same VLAN id.
 
  The changes should be minimal and would like to propose it for the
 next summit. The use case for this need is documented in the blueprint
 specification.
  Any feedback or comments are welcome.
 
 
 https://blueprints.launchpad.net/neutron/+spec/duplicate-providernet-vlans
 
  Hi Vinay:
 
  This problem seems straightforward enough, though currently you are
 right
  in that we don't allow multiple Neutron networks to have the same
 segmentation
  ID. I've added myself as approver for this BP and look forward to
 further
  discussions of this before and during the upcoming Summit!


I kind of feel like allowing a vlan to span multiple networks is kind of
wonky. I feel like a better abstraction would be if we had better access
control over shared networks between tenants. This way we could explicitly
allow two tenants to share a network. Is this the problem you are trying to
solve though doing it with the same vlan?  How do you plan on enforcing
that mac_addresses are unique on the same physical network?

Multiple networks with network_type of 'vlan' are already allowed to
 have the same segmentation ID with the ml2, openvswitch, or linuxbridge
 plugins - the networks just need to have different physical_network
 names.


This is the same for the NSX plugin as well.


 If they have the same network_type, physical_network, and
 segmentation_id, they are the same network. What else would distinguish
 them from each other?

 Could your use case be addressed by simply using different
 physical_network names for each rack? This would provide independent
 spaces of segmentation_ids for each.

 -Bob

 
  Thanks!
  Kyle
 
  Thanks
  --
  Vinay Bannai
  Email: vban...@gmail.com
  Google Voice: 415 938 7576
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Vinay Bannai
 Email: vban...@gmail.com
 Google Voice: 415 938 7576

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Calling a controller from within a session in the plugin

[Aaron Rosen]

In my experience doing any kind of http request inside a of a db
transaction kills performance vastly (and can lead to situations where
deadlock often occurs due to eventlet+sqlalchemly). This topic also was
recently discussed here:
http://lists.openstack.org/pipermail/openstack-dev/2013-November/019624.html

Best,

Aaron


On Wed, Dec 4, 2013 at 9:15 AM, Mohammad Banikazemi m...@us.ibm.com wrote:

 Have a question regarding calling an external SDN controller in a plugin.
 The ML2 model brings up the fact that it is preferred not to call an
 external controller within a database session by splitting up each call
 into two calls: *_precommit and *_postcommit. Makes sense.

 Looking at the existing monolithic plugins, I see some plugins that do not
 follow this approach and have the call to the controller from within a
 session. The obvious benefit of this approach would be a simpler cleanup
 code segment for cases where the call to controller fails. So my question
 is whether it is still OK to use this simpler approach in monolithic
 plugins. As we move to the ML2 model, we will be using the ML2 approach but
 in the meantime, we leave the option of calling the controller within a
 session as an OK option. Would that be reasonable?

 -Mohammad



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Should the server create API return 404 errors?

[Aaron Rosen]

On Mon, Nov 25, 2013 at 6:00 PM, Christopher Yeoh cbky...@gmail.com wrote:

 On Tue, Nov 26, 2013 at 7:27 AM, Matt Riedemann 
 mrie...@linux.vnet.ibm.com wrote:

 Aaron Rosen is working a patch [1] to handle a NetworkNotFound exception
 in the server create API.  For the V2 API this will return a 400 error.
  For the V3 API this will return a 404 because of a V3-specific patch [2].
  The API docs list 404 as a valid response code, but is it intuitive for a
 POST request like this?


 Yea I think in this case we've just got this wrong for the V3 API here.
 It's validating a parameter, and although the client (glance/neutron etc)
 may return a 404 to us, we should be returning a 400 (with a decent
 message) to our client.


I agree, I think 400 makes more sense than 404.  I'll go a head and make
this change for the v3 API's as well.



 To muddy the waters more, ImageNotFound, FlavorNotFound and
 KeypairNotFound are translated to 400 errors in both the V2 and V3 APIs.

 So why should the network-specific NotFound exceptions be a 404 but the
 others aren't?

 From a programmatic perspective, I should validate that my request
 parameters are valid before calling the API in order to avoid a 404. From a
 user's perspective, a 404 seems strange - does it mean that the server I'm
 trying to create isn't found?  No, that's counter-intuitive.

 Ultimately I think we should be consistent, so if 404 is OK, then I think
 the V3 API should make ImageNotFound, FlavorNotFound and KeypairNotFound
 return a 404 also.


 At the very least we should be consistent across our API.

Chris.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Proposal to add Matt Riedemann to nova-core

[Aaron Rosen]

+1


On Fri, Nov 22, 2013 at 12:53 PM, Russell Bryant rbry...@redhat.com wrote:

 Greetings,

 I would like to propose adding Matt Riedemann to the nova-core review team.

 Matt has been involved with nova for a long time, taking on a wide range
 of tasks.  He writes good code.  He's very engaged with the development
 community.  Most importantly, he provides good code reviews and has
 earned the trust of other members of the review team.

 https://review.openstack.org/#/dashboard/6873
 https://review.openstack.org/#/q/owner:6873,n,z
 https://review.openstack.org/#/q/reviewer:6873,n,z

 Please respond with +1/-1, or any further comments.

 Thanks,

 --
 Russell Bryant

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Find the compute host on which a VM runs

[Aaron Rosen]

On Thu, Nov 21, 2013 at 8:12 AM, Robert Kukura rkuk...@redhat.com wrote:

 On 11/21/2013 04:20 AM, Stefan Apostoaie wrote:
  Hello again,
 
  I studied the portbindings extension (the quantum.db.portbindings_db and
  quantum.extensions.portbindings modules). However it's unclear for me
  who sets the portbindings.HOST_ID attribute. I ran some tests with OVS:
  called quantum port-create command and
  the OVSQuantumPluginV2.create_port method got called and it had
  'binding:host_id': object object at memory_address. If I print out
  the port object I have 'binding:host_id': None.
 
  What other plugins are doing:
  1. extend the quantum.db.portbindings_db.PortBindingMixin class
  2. call the _process_portbindings_create_and_update method in
  create/update port

 Take look at how the ML2 plugin handles port binding and uses
 binding:host_id with its set of registered MechanismDrivers. It does not
 use the mixin class because the values of binding:vif_type and other
 portbinding attributes vary depending on what MechanismDriver binds the
 port.

 Hi Bob,

I don't want to reopen a can of worms here but I'm still wondering why
neutron needs to know the location where ports are (I understand it makes
sense to have some metadata for network ports (i.e dhcp) as to which agent
they are mapped to) but not really for ports that are mapped to instances.

For example, in the ML2 case there are agents running on all the
hypervisors so the agent knows which compute node he is running on and can
determine the ports on that compute node himself by looking in the ovsdb
interface table (i.e: external_ids:
{attached-mac=fa:16:3e:92:2b:53,
iface-id=d7bf8418-e4ad-4dd7-8dda-a3c430ef4d9f, iface-status=active,
vm-id=a9be8cff-87f6-49a0-b355-a53ec1579b56}) . Where the iface-id is the
neutron port-id and the vm-id is the nova-instance id. nova-compute puts
this information in there.

I also wonder about the merrit of having neutron return which vif_type nova
should use. Right now most plugins just return:
{pbin.VIF_TYPE: pbin.VIF_TYPE_OVS} . It seems to me that the
agent/nova-compute host should know what type of vif plugging to use based
on the type of node he is (and how he has been configured). I don't think
neutron should know this information imo.

I think I have been missing the reason why we have the port-binding
extension for a while now . Sorry if I've already brought this up in the
past. Would you mind shedding some light on this again?

Thanks,

Aaron







 In fact, you may want to consider implementing an ML2 MechanismDriver
 rather than a entire new monolithic plugin - it will save you a lot of
 work, initially and in the longer term!

  What I cannot find is where the portbindings.HOST_ID attribute is being
 set.

 Its set by nova, either on port creation, or as an update to an existing
 port. See allocate_for_instance() and
 _populate_neutron_extension_values() in nova/network/neutronv2/api.py.

 -Bob

 
  Regards,
  Stefan
 
 
  On Fri, Nov 15, 2013 at 10:57 PM, Mark McClain
  mark.mccl...@dreamhost.com mailto:mark.mccl...@dreamhost.com wrote:
 
  Stefan-
 
  Your workflow is very similar to many other plugins.  You’ll want to
  look at implementing the port binding extension in your plugin.  The
  port binding extension allows Nova to inform Neutron of the host
  where the VM is running.
 
  mark
 
  On Nov 15, 2013, at 9:55 AM, Stefan Apostoaie ioss...@gmail.com
  mailto:ioss...@gmail.com wrote:
 
   Hello,
  
   I'm creating a Neutron/Quantum plugin to work with a networking
  controller that takes care of the configuration of the virtual
  networks. Basically what we are doing is receive the API calls and
  forward them to our controller to run the required configuration on
  the compute hosts.
   What I need to know when a create_port call is made to my plugin
  is on which compute host the VM is created (so that our controller
  will run the configuration on that host). Is there a way to find out
  this information from the plugin?
  
   Regards,
   Stefan Apostoaie
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
  mailto:OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  mailto:OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 

Re: [openstack-dev] [Openstack-security] Neutron security groups for L2 networks in Havana

[Aaron Rosen]

Hi Kanthi,

The issue is that the nova-api says that by default every instance needs to
be in a default security group that blocks all ingress traffic from outside
and allows all ingress from instances that belong to the same security
group. If an instance does not have an ip address we are unable to enforce
the instance-instance communication of members that are part of the same
security group (or at least the iptables implementation in place doesn't).

There is an extension in neutron that implements port_security that allows
one to disable this so that one can do L2 networking as you want to. Though
unfortunately, this does not work correctly at this time with nova as
currently it's calling into neutron to create the security group and attach
it to the instance anways. See: https://bugs.launchpad.net/nova/+bug/1175464 .
I'm hoping to resolve this issue in the next few weeks.

Best,

Aaron


On Fri, Nov 8, 2013 at 1:45 AM, Kanthi P pavuluri.kan...@gmail.com wrote:

 Hi Aaron,

 Thanks for the reply !
 Yes security groups are mapped to L3/L4 headers, these security rules are
 being converted to iptables.

 If we remove the subnet check, we will be able to launch instances without
 ipaddress, they just have the mac address.
 Users can configure their own ipaddress after they are booted.

 If we use neutron security groups, it provides a default group (on port
 basis) which blocks all ingress and allows all egress traffic.

 Later users can configure security groups based on the ip address what
 they provided to the vnics.

 I mean to say, ports will have subnet but just that this subnet is not
 known to openstack during the instance boot time.




 On Fri, Nov 8, 2013 at 9:42 AM, Aaron Rosen aro...@nicira.com wrote:




 On Thu, Nov 7, 2013 at 12:23 PM, Kanthi P pavuluri.kan...@gmail.comwrote:

 Hi,

 I am trying to boot a VM which has a network without subnet in Havana,
 but it throws an exception saying that subnet is mandatory if quantum
 security groups are enabled.

 Here are the commands I used.

 neutron net-create testNet
 neutron net-show testNet
 +---+--+
 | Field | Value|
 +---+--+
 | admin_state_up| True |
 | id| 47208beb-2801-4729-bc7b-6532717232fc |
 | name  | testNet  |
 | provider:network_type | local|
 | provider:physical_network |  |
 | provider:segmentation_id  |  |
 | router:external   | False|
 | shared| False|
 | status| ACTIVE   |
 | subnets   |  |
 | tenant_id | b5b591dcda2645cd9d15a4fe3eb1b50d |
 +---+--+

 nova boot --flavor 2 --image 30c1984c-8a4f-4e3f-8c9a-7de0b321caa2 --nic
 net-id=47208beb-2801-4729-bc7b-6532717232fc testServer1

 Here is the piece of code which generated this exception

 nova/network/neutronv2/api.py

 if (security_groups and not (
 network['subnets']
 and network.get('port_security_enabled', True))):

 raise exception.SecurityGroupCannotBeApplied()


 Can someone please explain why do we need this check?


 Hi Kanthi,

 We need this check because because in order to enforce security groups
 the port needs to have an ip_address (i.e: network needs a subnet) since
 Security groups only map to L3/4 headers. Today, nova automatically adds a
 default security group to all instances when booted. Hopefully we can punt
 this task off to neutron in this release by moving the port-creation up on
 the stack to nova-api instead of nova-compute though this isn't the case
 right now.

 Aaron


 To my understanding subnet is used for two purposes in terms of security
 groups
 1. To allow dhcp traffic if dhcp is enabled on the subnet, example given
 below
 -A quantum-openvswi-i7bf776d2-b -s 192.168.1.3/32 -p udp -m udp
 --sport 67 --dport 68 -j RETURN
 2. To avoid ip spoof
 -A quantum-openvswi-o7bf776d2-b ! -s 192.168.1.2/32 -j DROP

 Can we remove this so that we can have guests which has nic with just
 MAC address, guest can configure its own ipaddress. Later if needed they
 can enable their own security rules via quantum api.

 ___
 Openstack-security mailing list
 openstack-secur...@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http

Re: [openstack-dev] [Neutron][LBaaS] Loadbalancer instance design.

[Aaron Rosen]

On Fri, Nov 15, 2013 at 5:59 AM, Stephen Gran
stephen.g...@theguardian.comwrote:

 On 15/11/13 13:14, Eugene Nikanorov wrote:

 Hi folks,

 I've created a brief description of this feature.
 You can find it here:
 https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance
 https://blueprints.launchpad.net/neutron/+spec/lbaas-service-instance


 I would appreciate any comments/ideas about this.


 This is great - we're starting to experiment with running an appliance
 load balancer as an openstack instance.  The only quirk so far is that we
 need to add new vips to the allowed_addresses list on the neutron port, and
 the API for doing so doesn't allow for incremental updates, so is a bit
 racy.


Why do you need incremental updates? Doing a PUT with a list of
IP(cidr)/mac is not very expensive to the point were we need to create an
address_pair as a top level resource so you could do what you are doing.
FWIW, the allowed_address_pair attribute works the same way as the
fixed_ips attribute on the port.



 Cheers,
 --
 Stephen Gran
 Senior Systems Integrator - theguardian.com
 Please consider the environment before printing this email.
 --
 Visit theguardian.com
 On your mobile, download the Guardian iPhone app theguardian.com/iphoneand 
 our iPad edition
 theguardian.com/iPad   Save up to 33% by subscribing to the Guardian and
 Observer - choose the papers you want and get full digital access.
 Visit subscribe.theguardian.com

 This e-mail and all attachments are confidential and may also
 be privileged. If you are not the named recipient, please notify
 the sender and delete the e-mail and all attachments immediately.
 Do not disclose the contents to another person. You may not use
 the information for any purpose, or store, or copy, it in any way.

 Guardian News  Media Limited is not liable for any computer
 viruses or other material transmitted with or as part of this
 e-mail. You should employ virus checking software.

 Guardian News  Media Limited

 A member of Guardian Media Group plc
 Registered Office
 PO Box 68164
 Kings Place
 90 York Way
 London
 N1P 2AP

 Registered in England Number 908396

 --


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Race condition between DB layer and plugin back-end implementation

[Aaron Rosen]

This actually doesn't solve the issue because if you run multiple neutron
servers behind a loadbalancer you will still run into the same issue with
the transaction on the database I believe.

We handle this issue in the NVP plugin by removing the transaction and
attempt to manually delete the port if the rest call to nvp failed. In the
case where the port was unable to be deleted from the database (unlikely)
the operational status of the port eventually goes to error state from a
background thread that syncs the operational status from nvp to the neutron
database. Then later we have to garbage collect ports in error state.

On Mon, Nov 18, 2013 at 12:43 PM, Joshua Harlow harlo...@yahoo-inc.comwrote:

  An idea, make the lock more granular.

  Instead of @utils.synchronized('any-name') I wonder if u could do
 something like.

  with utils.synchronized('any-name-$device-id'):
 # Code here

  Then at least u won't be locking at the method level (which means no
 concurrency). Would that work?

   From: Edgar Magana emag...@plumgrid.com
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: Monday, November 18, 2013 12:25 PM
 To: OpenStack List openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [Neutron] Race condition between DB layer and
 plugin back-end implementation

   Developers,

  This topic has been discussed before but I do not remember if we have a
 good solution or not.
 Basically, if concurrent API calls are sent to Neutron, all of them are
 sent to the plug-in level where two actions have to be made:

  1. DB transaction – No just for data persistence but also to collect the
 information needed for the next action
 2. Plug-in back-end implementation – In our case is a call to the python
 library than consequentially calls PLUMgrid REST GW (soon SAL)

  For instance:

  def create_port(self, context, port):
 with context.session.begin(subtransactions=True):
 # Plugin DB - Port Create and Return port
 port_db = super(NeutronPluginPLUMgridV2,
 self).create_port(context,

  port)
 device_id = port_db[device_id]
 if port_db[device_owner] == network:router_gateway:
 router_db = self._get_router(context, device_id)
 else:
 router_db = None
 try:
 LOG.debug(_(PLUMgrid Library: create_port() called))
 # Back-end implementation
 self._plumlib.create_port(port_db, router_db)
 except Exception:
 …

  The way we have implemented at the plugin-level in Havana (even in
 Grizzly) is that both action are wrapped in the same transaction which
 automatically rolls back any operation done to its original state
 protecting mostly the DB of having any inconsistency state or left over
 data if the back-end part fails.=.
 The problem that we are experiencing is when concurrent calls to the same
 API are sent, the number of operation at the plug-in back-end are long
 enough to make the next concurrent API call to get stuck at the DB
 transaction level, which creates a hung state for the Neutron Server to the
 point that all concurrent API calls will fail.

  This can be fixed if we include some locking system such as calling:

  from neutron.common import utile
 …

  @utils.synchronized('any-name', external=True)
 def create_port(self, context, port):
 …

  Obviously, this will create a serialization of all concurrent calls
 which will ends up in having a really bad performance. Does anyone has a
 better solution?

  Thanks,

  Edgar

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] Network topologies

[Aaron Rosen]

Hi Edgar,

I definitely see the usecase for the idea that you propose. In my opinion,
I don't see the reason for moving the management of topology into neutron,
 Heat already provides this functionality (besides for the part of taking
an existing deployment and generating a template file). Also, I wanted to
point out that in a way you will have to do orchestration as you're
topology manager will have to call the neutron api in order to create the
topology and tear it down.

Best,

Aaron


On Tue, Oct 29, 2013 at 11:33 AM, Edgar Magana emag...@plumgrid.com wrote:

 Tim,

 You statement building an api that manages a network topology more than
 one that needs to build out the dependencies between resources to help
 create the network topology
 Is exactly what we are proposing, and this is why we believe this is not
 under Heat domain.

 This is why we are NOT proposing to manage any dependency between network
 elements, that part is what I call intelligence of the orchestration and
 we are not proposing any orchestration system, you are already have that
 in place :-)

 So, we simple want an API that tenats may use to save, retrieve and
 share topologies. For instance, tenant A creates a topology with two
 networks (192.168.0.0/24 and 192.168.1.0/24) both with dhcp enabled and a
 router connecting them. So, we first create it using CLI commands or
 Horizon and then we call the API to save the topology for that tenant,
 that topology can be also share  between tenants if the owner wanted to do
 that, the same concept that we have in Neutron for share networks, So
 Tenant B or any other Tenants, don't need to re-create the whole topology,
 just open the shared topology from tenant A. Obviously, overlapping IPs
 will be a must requirement.

 I am including in this thread to Mark McClain who is the Neutron PTL and
 the main guy expressing concerns in not  having overlapping
 functionalities between Neutron and Heat or any other project.

 I am absolutely, happy to discuss further with you but if you are ok with
 this approach we could start the development in Neutron umbrella, final
 thoughts?

 Thanks,

 Edgar

 On 10/29/13 8:23 AM, Tim Schnell tim.schn...@rackspace.com wrote:

 Hi Edgar,
 
 It seems like this blueprint is related more to building an api that
 manages a network topology more than one that needs to build out the
 dependencies between resources to help create the network topology. If we
 are talking about just an api to save, duplicate, and share these
 network topologies then I would agree that this is not something that Heat
 currently does or should do necessarily.
 
 I have been focusing primarily on front-end work for Heat so I apologize
 if these questions have already been answered. How is this API related to
 the existing network topology in Horizon? The existing network topology
 can already define the relationships and dependencies using Neutron I'm
 assuming so there is no apparent need to use Heat to gather this
 information. I'm a little confused as to the scope of the discussion, is
 that something that you are potentially interested in changing?
 
 Steve, Clint and Zane can better answer whether or not Heat wants to be in
 the business of managing existing network topologies but from my
 perspective I tend to agree with your statement that if you needed Heat to
 help describe the relationships between network resources then that might
 be duplicated effort but if don't need Heat to do that then this blueprint
 belongs in Neutron.
 
 Thanks,
 Tim
 
 
 
 
 
 On 10/29/13 1:32 AM, Steven Hardy sha...@redhat.com wrote:
 
 On Mon, Oct 28, 2013 at 01:19:13PM -0700, Edgar Magana wrote:
  Hello Folks,
 
  Thank you Zane, Steven and Clint for you input.
 
  Our main goal in this BP is to provide networking users such as Heat
 (we
  consider it as a neutron user) a better and consolidated network
 building
  block in terms of an API that you could use for orchestration of
  application-driven requirements. This building block does not add any
  intelligence to the network topology because it does not have it and
  this is why I think this BP is different from the work that you are
 doing
  in Heat.
 
 So how do you propose to handle dependencies between elements in the
 topology, e.g where things need to be created/deleted in a particular
 order, or where one resource must be in a particular state before another
 can be created?
 
  The network topologies BP is not related to the Neutron Network Service
  Insertion BP:
 
 
 https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertio
 n
 -c
  haining-steering
 
 So I wasn't saying they were related, only that they both, arguably, may
 have some scope overlap with what Heat is doing.
 
  I do agree with Steven that the insertion work add intelligence
  (explicit management of dependencies, state and workflow) to the
 network
  orchestration simply because user will need to know the insertion
  mechanism and dependencies between 

Re: [openstack-dev] {opestack-dev][Horizon] Errors while creating networks

[Aaron Rosen]

Just curious what does keystone endpoint-list show?
On Oct 29, 2013 9:36 PM, Somanchi Trinath-B39208 b39...@freescale.com
wrote:

  Hi-

 ** **

 I have got the following error in apache error logs while I try to bring
 up a new instance. 

 ** **

 I have followed Openstack Havana for Ubuntu 12.04 LTS installation manual
 from docs.openstack.org.

 ** **

 I’m going with single node (both controller and compute node on a single
 machine) installation. 

 ** **

 ** **

 [Tue Oct 29 11:17:20 2013] [error] Problem instantiating action class.

 [Tue Oct 29 11:17:20 2013] [error] Traceback (most recent call last):

 [Tue Oct 29 11:17:20 2013] [error]   File
 /usr/lib/python2.7/dist-packages/horizon/workflows/base.py, line 376, in
 action

 [Tue Oct 29 11:17:20 2013] [error] context)

 [Tue Oct 29 11:17:20 2013] [error]   File
 /usr/lib/python2.7/dist-packages/horizon/workflows/base.py, line 141, in
 __init__

 [Tue Oct 29 11:17:20 2013] [error] self._populate_choices(request,
 context)

 [Tue Oct 29 11:17:20 2013] [error]   File
 /usr/lib/python2.7/dist-packages/horizon/workflows/base.py, line 154, in
 _populate_choices

 [Tue Oct 29 11:17:20 2013] [error] bound_field.choices = meth(request,
 context)

 [Tue Oct 29 11:17:20 2013] [error]   File
 /usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/project/instances/workflows/create_instance.py,
 line 510, in populate_network_choices

 [Tue Oct 29 11:17:20 2013] [error] _('Unable to retrieve networks.'))*
 ***

 [Tue Oct 29 11:17:20 2013] [error]   File
 /usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/project/instances/workflows/create_instance.py,
 line 503, in populate_network_choices

 [Tue Oct 29 11:17:20 2013] [error] networks =
 api.neutron.network_list_for_tenant(request, tenant_id)

 [Tue Oct 29 11:17:20 2013] [error]   File
 /usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/api/neutron.py,
 line 456, in network_list_for_tenant

 [Tue Oct 29 11:17:20 2013] [error] shared=False, **params)

 [Tue Oct 29 11:17:20 2013] [error]   File
 /usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/api/neutron.py,
 line 434, in network_list

 [Tue Oct 29 11:17:20 2013] [error] networks =
 neutronclient(request).list_networks(**params).get('networks')

 [Tue Oct 29 11:17:20 2013] [error]   File
 /usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/api/neutron.py,
 line 423, in neutronclient

 [Tue Oct 29 11:17:20 2013] [error] % (request.user.token.id,
 base.url_for(request, 'network')))

 [Tue Oct 29 11:17:20 2013] [error]   File
 /usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/api/base.py,
 line 268, in url_for

 [Tue Oct 29 11:17:20 2013] [error] raise
 exceptions.ServiceCatalogException(service_type)

 [Tue Oct 29 11:17:20 2013] [error] ServiceCatalogException: Invalid
 service catalog service: network

 [Tue Oct 29 11:17:20 2013] [error] Internal Server Error:
 /horizon/project/instances/launch

 [Tue Oct 29 11:17:20 2013] [error] Traceback (most recent call last):

 [Tue Oct 29 11:17:20 2013] [error]   File
 /usr/lib/python2.7/dist-packages/django/core/handlers/base.py, line 140,
 in get_response

 [Tue Oct 29 11:17:20 2013] [error] response = response.render()

 [Tue Oct 29 11:17:20 2013] [error]   File
 /usr/lib/python2.7/dist-packages/django/template/response.py, line 105,
 in render

 [Tue Oct 29 11:17:20 2013] [error] self.content = self.rendered_content
 

 [Tue Oct 29 11:17:20 2013] [error]   File
 /usr/lib/python2.7/dist-packages/django/template/response.py, line 82, in
 rendered_content

 [Tue Oct 29 11:17:20 2013] [error] content = template.render(context)*
 ***

 [Tue Oct 29 11:17:20 2013] [error]   File
 /usr/lib/python2.7/dist-packages/django/template/base.py, line 140, in
 render

 [Tue Oct 29 11:17:20 2013] [error] return self._render(context)

 [Tue Oct 29 11:17:20 2013] [error]   File
 /usr/lib/python2.7/dist-packages/django/template/base.py, line 134, in
 _render

 [Tue Oct 29 11:17:20 2013] [error] return self.nodelist.render(context)
 

 [Tue Oct 29 11:17:20 2013] [error]   File
 /usr/lib/python2.7/dist-packages/django/template/base.py, line 830, in
 render

 [Tue Oct 29 11:17:20 2013] [error] bit = self.render_node(node,
 context)

 [Tue Oct 29 11:17:20 2013] [error]   File
 /usr/lib/python2.7/dist-packages/django/template/base.py, line 844, in
 render_node

 [Tue Oct 29 11:17:20 2013] [error] return node.render(context)

 [Tue Oct 29 11:17:20 2013] [error]   File
 /usr/lib/python2.7/dist-packages/django/template/defaulttags.py, line
 485, in render

 [Tue Oct 29 11:17:20 2013] [error] output =
 

Re: [openstack-dev] Havana neutron security groups config issue

[Aaron Rosen]

Hrm, your config files looks good to me. From your iptables-save output it
looks like you have nova-network running as well. I wonder if that is
overwritting the rules that the agents are installing. Can you try removing
nova-network and see if that changes anything?

Aaron


On Mon, Oct 21, 2013 at 10:45 AM, Leandro Reox leandro.r...@gmail.comwrote:

 Aaron,

 Here you are all the info, all the nova.confs (compute, controller) , all
 the agent logs, iptables output etc ... btw as i said we're testing this
 setup with docker containers , just to be clear regarding your last
 recommedation about libvirt vif driver (that we alreade have on the conf )

 Here it is: http://pastebin.com/RMgQxFyN

 Any clues ?


 Best
 Lean


 On Fri, Oct 18, 2013 at 8:06 PM, Aaron Rosen aro...@nicira.com wrote:

 Is anything showing up in the agents log on the hypervisors? Also, can
 you confirm you have this setting in your nova.conf:


 libvirt_vif_driver = nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver



 On Fri, Oct 18, 2013 at 1:14 PM, Leandro Reox leandro.r...@gmail.comwrote:

 Aaaron, i fixed the config issues moving the neutron opts up to the
 default section. But now im having this issue

 i can launch intances normally, it seems that the rules are not getting
 applied anywhere, i have full access to the docker containers. If i do
 iptable -t nat -L and iptables -L , no rules seems to be applied to any flow

 I see the calls on the nova-api normally ... , but no rule applied


 2013-10-18 16:10:09.873 31548 DEBUG neutronclient.client [-]
 RESP:{'date': 'Fri, 18 Oct 2013 20:10:07 GMT', 'status': '200',
 'content-length': '2331', 'content-type': 'application/json;
 charset=UTF-8', 'content-location': '
 http://172.16.124.16:9696/v2.0/security-groups.json'}
 {security_groups: [{tenant_id: df26f374a7a84eddb06881c669ffd62f,
 name: default, description: default, security_group_rules:
 [{remote_group_id: null, direction: egress, remote_ip_prefix: null,
 protocol: null, ethertype: IPv4, tenant_id:
 df26f374a7a84eddb06881c669ffd62f, port_range_max: null,
 port_range_min: null, id: 131f26d3-6b7b-47ef-9abf-fd664e59a972,
 security_group_id: 2391ac97-447e-45b7-97f2-cd8fbcafb0cb},
 {remote_group_id: null, direction: egress, remote_ip_prefix: null,
 protocol: null, ethertype: IPv6, tenant_id:
 df26f374a7a84eddb06881c669ffd62f, port_range_max: null,
 port_range_min: null, id: 93a8882b-adcd-489a-89e4-694f5955,
 security_group_id: 2391ac97-447e-45b7-97f2-cd8fbcafb0cb},
 {remote_group_id: 2391ac97-447e-45b7-97f2-cd8fbcafb0cb, direction:
 ingress, remote_ip_prefix: null, protocol: null, ethertype: IPv4,
 tenant_id: df26f374a7a84eddb06881c669ffd62f, port_range_max: null,
 port_range_min: null, id: fb15316c-efd0-4a70-ae98-23f260f0d76d,
 security_group_id: 2391ac97-447e-45b7-97f2-cd8fbcafb0cb},
 {remote_group_id: 2391ac97-447e-45b7-97f2-cd8fbcafb0cb, direction:
 ingress, remote_ip_prefix: null, protocol: null, ethertype: IPv6,
 tenant_id: df26f374a7a84eddb06881c669ffd62f, port_range_max: null,
 port_range_min: null, id: fc524bb9-b015-42b0-bdab-cd64db2763a6,
 security_group_id: 2391ac97-447e-45b7-97f2-cd8fbcafb0cb}], id:
 2391ac97-447e-45b7-97f2-cd8fbcafb0cb}, {tenant_id:
 df26f374a7a84eddb06881c669ffd62f, name: culo, description: ,
 security_group_rules: [{remote_group_id: null, direction: egress,
 remote_ip_prefix: null, protocol: null, ethertype: IPv6,
 tenant_id: df26f374a7a84eddb06881c669ffd62f, port_range_max: null,
 port_range_min: null, id: 2c23f70a-691b-4601-87a0-2ec092488746,
 security_group_id: fe569b17-d6e0-4b1e-bae3-1132e748190c},
 {remote_group_id: null, direction: egress, remote_ip_prefix: null,
 protocol: null, ethertype: IPv4, tenant_id:
 df26f374a7a84eddb06881c669ffd62f, port_range_max: null,
 port_range_min: null, id: 7a445e16-81c1-45c1-8efd-39ce3bcd9ca6,
 security_group_id: fe569b17-d6e0-4b1e-bae3-1132e748190c}], id:
 fe569b17-d6e0-4b1e-bae3-1132e748190c}]}
  http_log_resp
 /usr/lib/python2.7/dist-packages/neutronclient/common/utils.py:179
 2013-10-18 16:10:09.959 31548 INFO nova.osapi_compute.wsgi.server
 [req-87c41dc0-d90a-47b9-bfa8-bd7921a26609 223f36a9e1fc44659ac93479cb508902
 df26f374a7a84eddb06881c669ffd62f] 172.16.124.10 GET
 /v2/df26f374a7a84eddb06881c669ffd62f/servers/detail HTTP/1.1 status: 200
 len: 1878 time: 0.6089120




 On Fri, Oct 18, 2013 at 5:07 PM, Aaron Rosen aro...@nicira.com wrote:

 Do you have [default] at the top of your nova.conf? Could you pastebin
 your nova.conf  for us to see.
  On Oct 18, 2013 12:31 PM, Leandro Reox leandro.r...@gmail.com
 wrote:

 Yes it is, but i found that is not reading the parameter from the
 nova.conf , i forced on the code on /network/manager.py and took the
 argument finally but stacks cause says that the neutron_url and if i fix 
 it
 it stacks on the next neutron parameter like timeout :

 File /usr/local/lib/python2.7/dist-packages/oslo/config/cfg.py, line
 1648, in __getattr__
 2013-10-18 15:21:04.397 30931 TRACE nova.api.openstack raise

Re: [openstack-dev] Havana neutron security groups config issue

[Aaron Rosen]

Hi Leandro,


I don't believe the setting of:  security_group_api=neutron in nova.conf
actually doesn't matter at all on the compute nodes (still good to set it
though). But it matters on the nova-api node. can you confirm that your
nova-api node has: security_group_api=neutron in it's nova.conf?

Thanks,

Aaron


On Fri, Oct 18, 2013 at 10:32 AM, Leandro Reox leandro.r...@gmail.comwrote:

 Dear all,

 Im struggling with centralized sec groups on nova, were using OVS, it
 seems like no matter what flag i change on nova conf, the node still
 searchs the segroups on nova region local db

 We added :


 [compute node]

 *nova.conf*

 firewall_driver=neutron.agent.firewall.NoopFirewallDriver
 security_group_api=neutron


 *ovs_neutron_plugin.ini*

 [securitygroup]
 firewall_driver =
 neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver


 Restarted the agent, nova-compute services ... still the same, are we
 missing something ?

 NOTE: we're using dockerIO as virt system

 Best
 Leitan

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Havana neutron security groups config issue

[Aaron Rosen]

Do you have [default] at the top of your nova.conf? Could you pastebin your
nova.conf  for us to see.
On Oct 18, 2013 12:31 PM, Leandro Reox leandro.r...@gmail.com wrote:

 Yes it is, but i found that is not reading the parameter from the
 nova.conf , i forced on the code on /network/manager.py and took the
 argument finally but stacks cause says that the neutron_url and if i fix it
 it stacks on the next neutron parameter like timeout :

 File /usr/local/lib/python2.7/dist-packages/oslo/config/cfg.py, line
 1648, in __getattr__
 2013-10-18 15:21:04.397 30931 TRACE nova.api.openstack raise
 NoSuchOptError(name)
 2013-10-18 15:21:04.397 30931 TRACE nova.api.openstack NoSuchOptError: no
 such option: neutron_url

 and then

 File /usr/local/lib/python2.7/dist-packages/oslo/config/cfg.py, line
 1648, in __getattr__
 2013-10-18 15:25:20.811 31305 TRACE nova.api.openstack raise
 NoSuchOptError(name)
 2013-10-18 15:25:20.811 31305 TRACE nova.api.openstack NoSuchOptError: no
 such option: neutron_url_timeout

 Its really weird, like its not reading the nova.conf neutron parameter at
 all ...

 If i hardcode all the settings on the neutronv2/init.py .. at least it
 works, and bring all the secgroup details from netruon



 On Fri, Oct 18, 2013 at 3:48 PM, Aaron Rosen aro...@nicira.com wrote:

 Hi Leandro,


 I don't believe the setting of:  security_group_api=neutron in nova.conf
 actually doesn't matter at all on the compute nodes (still good to set it
 though). But it matters on the nova-api node. can you confirm that your
 nova-api node has: security_group_api=neutron in it's nova.conf?

 Thanks,

 Aaron


 On Fri, Oct 18, 2013 at 10:32 AM, Leandro Reox leandro.r...@gmail.comwrote:

 Dear all,

 Im struggling with centralized sec groups on nova, were using OVS, it
 seems like no matter what flag i change on nova conf, the node still
 searchs the segroups on nova region local db

 We added :


 [compute node]

 *nova.conf*

 firewall_driver=neutron.agent.firewall.NoopFirewallDriver
 security_group_api=neutron


 *ovs_neutron_plugin.ini*

 [securitygroup]
 firewall_driver =
 neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver


 Restarted the agent, nova-compute services ... still the same, are we
 missing something ?

 NOTE: we're using dockerIO as virt system

 Best
 Leitan

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Havana neutron security groups config issue

[Aaron Rosen]

Is anything showing up in the agents log on the hypervisors? Also, can you
confirm you have this setting in your nova.conf:


libvirt_vif_driver = nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver



On Fri, Oct 18, 2013 at 1:14 PM, Leandro Reox leandro.r...@gmail.comwrote:

 Aaaron, i fixed the config issues moving the neutron opts up to the
 default section. But now im having this issue

 i can launch intances normally, it seems that the rules are not getting
 applied anywhere, i have full access to the docker containers. If i do
 iptable -t nat -L and iptables -L , no rules seems to be applied to any flow

 I see the calls on the nova-api normally ... , but no rule applied


 2013-10-18 16:10:09.873 31548 DEBUG neutronclient.client [-] RESP:{'date':
 'Fri, 18 Oct 2013 20:10:07 GMT', 'status': '200', 'content-length': '2331',
 'content-type': 'application/json; charset=UTF-8', 'content-location': '
 http://172.16.124.16:9696/v2.0/security-groups.json'} {security_groups:
 [{tenant_id: df26f374a7a84eddb06881c669ffd62f, name: default,
 description: default, security_group_rules: [{remote_group_id:
 null, direction: egress, remote_ip_prefix: null, protocol: null,
 ethertype: IPv4, tenant_id: df26f374a7a84eddb06881c669ffd62f,
 port_range_max: null, port_range_min: null, id:
 131f26d3-6b7b-47ef-9abf-fd664e59a972, security_group_id:
 2391ac97-447e-45b7-97f2-cd8fbcafb0cb}, {remote_group_id: null,
 direction: egress, remote_ip_prefix: null, protocol: null,
 ethertype: IPv6, tenant_id: df26f374a7a84eddb06881c669ffd62f,
 port_range_max: null, port_range_min: null, id:
 93a8882b-adcd-489a-89e4-694f5955, security_group_id:
 2391ac97-447e-45b7-97f2-cd8fbcafb0cb}, {remote_group_id:
 2391ac97-447e-45b7-97f2-cd8fbcafb0cb, direction: ingress,
 remote_ip_prefix: null, protocol: null, ethertype: IPv4,
 tenant_id: df26f374a7a84eddb06881c669ffd62f, port_range_max: null,
 port_range_min: null, id: fb15316c-efd0-4a70-ae98-23f260f0d76d,
 security_group_id: 2391ac97-447e-45b7-97f2-cd8fbcafb0cb},
 {remote_group_id: 2391ac97-447e-45b7-97f2-cd8fbcafb0cb, direction:
 ingress, remote_ip_prefix: null, protocol: null, ethertype: IPv6,
 tenant_id: df26f374a7a84eddb06881c669ffd62f, port_range_max: null,
 port_range_min: null, id: fc524bb9-b015-42b0-bdab-cd64db2763a6,
 security_group_id: 2391ac97-447e-45b7-97f2-cd8fbcafb0cb}], id:
 2391ac97-447e-45b7-97f2-cd8fbcafb0cb}, {tenant_id:
 df26f374a7a84eddb06881c669ffd62f, name: culo, description: ,
 security_group_rules: [{remote_group_id: null, direction: egress,
 remote_ip_prefix: null, protocol: null, ethertype: IPv6,
 tenant_id: df26f374a7a84eddb06881c669ffd62f, port_range_max: null,
 port_range_min: null, id: 2c23f70a-691b-4601-87a0-2ec092488746,
 security_group_id: fe569b17-d6e0-4b1e-bae3-1132e748190c},
 {remote_group_id: null, direction: egress, remote_ip_prefix: null,
 protocol: null, ethertype: IPv4, tenant_id:
 df26f374a7a84eddb06881c669ffd62f, port_range_max: null,
 port_range_min: null, id: 7a445e16-81c1-45c1-8efd-39ce3bcd9ca6,
 security_group_id: fe569b17-d6e0-4b1e-bae3-1132e748190c}], id:
 fe569b17-d6e0-4b1e-bae3-1132e748190c}]}
  http_log_resp
 /usr/lib/python2.7/dist-packages/neutronclient/common/utils.py:179
 2013-10-18 16:10:09.959 31548 INFO nova.osapi_compute.wsgi.server
 [req-87c41dc0-d90a-47b9-bfa8-bd7921a26609 223f36a9e1fc44659ac93479cb508902
 df26f374a7a84eddb06881c669ffd62f] 172.16.124.10 GET
 /v2/df26f374a7a84eddb06881c669ffd62f/servers/detail HTTP/1.1 status: 200
 len: 1878 time: 0.6089120




 On Fri, Oct 18, 2013 at 5:07 PM, Aaron Rosen aro...@nicira.com wrote:

 Do you have [default] at the top of your nova.conf? Could you pastebin
 your nova.conf  for us to see.
  On Oct 18, 2013 12:31 PM, Leandro Reox leandro.r...@gmail.com wrote:

 Yes it is, but i found that is not reading the parameter from the
 nova.conf , i forced on the code on /network/manager.py and took the
 argument finally but stacks cause says that the neutron_url and if i fix it
 it stacks on the next neutron parameter like timeout :

 File /usr/local/lib/python2.7/dist-packages/oslo/config/cfg.py, line
 1648, in __getattr__
 2013-10-18 15:21:04.397 30931 TRACE nova.api.openstack raise
 NoSuchOptError(name)
 2013-10-18 15:21:04.397 30931 TRACE nova.api.openstack NoSuchOptError:
 no such option: neutron_url

 and then

 File /usr/local/lib/python2.7/dist-packages/oslo/config/cfg.py, line
 1648, in __getattr__
 2013-10-18 15:25:20.811 31305 TRACE nova.api.openstack raise
 NoSuchOptError(name)
 2013-10-18 15:25:20.811 31305 TRACE nova.api.openstack NoSuchOptError:
 no such option: neutron_url_timeout

 Its really weird, like its not reading the nova.conf neutron parameter
 at all ...

 If i hardcode all the settings on the neutronv2/init.py .. at least it
 works, and bring all the secgroup details from netruon



 On Fri, Oct 18, 2013 at 3:48 PM, Aaron Rosen aro...@nicira.com wrote:

 Hi Leandro,


 I don't believe the setting of:  security_group_api=neutron in
 nova.conf actually doesn't

Re: [openstack-dev] How to enable quantum Nicira NVP plugin in devstack

[Aaron Rosen]

Hi Xin,

In order to use the NVP plugin you need to have NVP which the plugin talks
to. Do you have access to NVP?

Best,

Aaron


On Thu, Sep 26, 2013 at 1:47 PM, openstack learner 
openstacklea...@gmail.com wrote:

 Hi,

 From the link
 http://docs.openstack.org/grizzly/openstack-network/admin/content/flexibility.html
 I can see there is a Nicira NVP plugin for vmware. I am using the devstack
 to install the openstack, do you know how to enable the plugin in the
 localrc file? From the link here
 https://wiki.openstack.org/wiki/NeutronDevstack  i did not find something
 like a q-nvc that I can set in localrc file.  Any info about how to
 enable the quantum Nicira NVP plugin will be helpful.

 Thanks

 xin

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Article on Improving Openstack's Parallel Performance

[Aaron Rosen]

Hi Peter,

Great article. Any interest in pushing your N-work quantum-server patch
upstream?

Thanks,

Aaron


On Mon, Jul 22, 2013 at 8:44 AM, Peter Feiner pe...@gridcentric.ca wrote:

 Hello,

 I've written an article about my ongoing work on improving OpenStack's
 parallel performance:


 http://blog.gridcentric.com/bid/318277/Boosting-OpenStack-s-Parallel-Performance

 The article discusses host configuration changes and patches (upstream
 and in progress) that give a 74% speedup in a parallel macro benchmark
 (boot 40 instances, ping them, ssh into them, delete them).

 This article is a follow up to my presentation at the OpenStack summit
 in Portland.

 Peter

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options.

[Aaron Rosen]

On Wed, Jul 24, 2013 at 12:42 AM, Samuel Bercovici samu...@radware.comwrote:

  Hi,

 ** **

 This might be apparent but not to me.

 Can you point to how broadcast can be turned on a network/port?


There  is currently no way to prevent it so it's on by default.

 

 ** **

 As for the
 https://github.com/openstack/neutron/blob/master/neutron/extensions/portsecurity.py,
 in NVP, does this totally disable port security on a port/network or it
 just disable the MAC/IP checks and still allows the “user defined” port
 security to take effect?


Port security is currently obtained from the fixed_ips and mac_address
field on the port. This removes the filtering done on fixed_ips and
mac_address fields when disabled.


 

 This looks like an extension only implemented by NVP, do you know if there
 are similar implementations for other plugins?

 **


No, the other plugins do not currently have a way to disable spoofing
dynamically (only globally disabled).


  **

 Regards,

 -Sam.

 ** **

 ** **

 *From:* Aaron Rosen [mailto:aro...@nicira.com]
 *Sent:* Tuesday, July 23, 2013 10:52 PM
 *To:* Samuel Bercovici
 *Cc:* OpenStack Development Mailing List; sorla...@nicira.com; Avishay
 Balderman; gary.kot...@gmail.com

 *Subject:* Re: [openstack-dev] [Neutron] Chalenges with highly available
 service VMs - port adn security group options.

 ** **

 I agree too. I've posted a work in progress of this here if you want to
 start looking at it: https://review.openstack.org/#/c/38230/

 ** **

 Thanks, 


 Aaron

 ** **

 On Tue, Jul 23, 2013 at 4:21 AM, Samuel Bercovici samu...@radware.com
 wrote:

 Hi,

  

 I agree that the AutZ should be separated and the service provider should
 be able to control this based on their model.

  

 For Service VMs who might be serving ~100-~1000 IPs and might use multiple
 MACs per port, it would be better to turn this off altogether that to have
 an IPTABLE rules with thousands of entries. 

 This why I prefer to be able to turn-off IP spoofing and turn-off MAC
 spoofing altogether.

  

 Still from a logical model / declarative reasons an IP that can migrate
 between different ports should be declared as such and maybe also from MAC
 perspective.

  

 Regards,

 -Sam.

  

  

  

  

  

  

  

  

 *From:* Salvatore Orlando [mailto:sorla...@nicira.com]
 *Sent:* Sunday, July 21, 2013 9:56 PM


 *To:* OpenStack Development Mailing List

 *Subject:* Re: [openstack-dev] [Neutron] Chalenges with highly available
 service VMs - port adn security group options.

  

  

  

 On 19 July 2013 13:14, Aaron Rosen aro...@nicira.com wrote:

  

  

 On Fri, Jul 19, 2013 at 1:55 AM, Samuel Bercovici samu...@radware.com
 wrote:

 Hi,

  

 I have completely missed this discussion as it does not have
 quantum/Neutron in the subject (modify it now)

 I think that the security group is the right place to control this.

 I think that this might be only allowed to admins.

  

 I think this shouldn't be admin only since tenant's have control of their
 own networks they should be allowed to do this. 

  

 I reiterate my point that the authZ model for a feature should always be
 completely separated by the business logic of the feature itself.

 In my opinion there are grounds both for scoping it as admin only and for
 allowing tenants to use it; it might be better if we just let the policy
 engine deal with this.

  

 Let me explain what we need which is more than just disable spoofing.*
 ***

 1.   Be able to allow MACs which are not defined on the port level to
 transmit packets (for example VRRP MACs)== turn off MAC spoofing

   

 For this it seems you would need to implement the port security extension
 which allows one to enable/disable port spoofing on a port. 

   

 This would be one way of doing it. The other would probably be adding a
 list of allowed VRRP MACs, which should be possible with the blueprint
 pointed by Aaron. 

 2.   Be able to allow IPs which are not defined on the port level
 to transmit packets (for example, IP used for HA service that moves between
 an HA pair) == turn off IP spoofing

   

 It seems like this would fit your use case perfectly:
 https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairs

  3.   Be able to allow broadcast message on the port (for example for
 VRRP broadcast) == allow broadcast.

  

  Quantum does have an abstraction for disabling this so we already allow
 this by default.  

   

 Regards,

 -Sam.

  

  

 *From:* Aaron Rosen [mailto:aro...@nicira.com]
 *Sent:* Friday, July 19, 2013 3:26 AM
 *To:* OpenStack Development Mailing List
 *Subject:* Re: [openstack-dev] Chalenges with highly available

Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options.

[Aaron Rosen]

I agree too. I've posted a work in progress of this here if you want to
start looking at it: https://review.openstack.org/#/c/38230/

Thanks,

Aaron


On Tue, Jul 23, 2013 at 4:21 AM, Samuel Bercovici samu...@radware.comwrote:

  Hi,

 ** **

 I agree that the AutZ should be separated and the service provider should
 be able to control this based on their model.

 ** **

 For Service VMs who might be serving ~100-~1000 IPs and might use multiple
 MACs per port, it would be better to turn this off altogether that to have
 an IPTABLE rules with thousands of entries. 

 This why I prefer to be able to turn-off IP spoofing and turn-off MAC
 spoofing altogether.

 ** **

 Still from a logical model / declarative reasons an IP that can migrate
 between different ports should be declared as such and maybe also from MAC
 perspective.

 ** **

 Regards,

 -Sam.

 ** **

 ** **

 ** **

 ** **

 ** **

 ** **

 ** **

 ** **

 *From:* Salvatore Orlando [mailto:sorla...@nicira.com]
 *Sent:* Sunday, July 21, 2013 9:56 PM

 *To:* OpenStack Development Mailing List
 *Subject:* Re: [openstack-dev] [Neutron] Chalenges with highly available
 service VMs - port adn security group options.

 ** **

 ** **

 ** **

 On 19 July 2013 13:14, Aaron Rosen aro...@nicira.com wrote:

 ** **

 ** **

 On Fri, Jul 19, 2013 at 1:55 AM, Samuel Bercovici samu...@radware.com
 wrote:

 Hi,

  

 I have completely missed this discussion as it does not have
 quantum/Neutron in the subject (modify it now)

 I think that the security group is the right place to control this.

 I think that this might be only allowed to admins.

  

 I think this shouldn't be admin only since tenant's have control of their
 own networks they should be allowed to do this. 

 ** **

 I reiterate my point that the authZ model for a feature should always be
 completely separated by the business logic of the feature itself.

 In my opinion there are grounds both for scoping it as admin only and for
 allowing tenants to use it; it might be better if we just let the policy
 engine deal with this.

  

 Let me explain what we need which is more than just disable spoofing.*
 ***

 1.   Be able to allow MACs which are not defined on the port level to
 transmit packets (for example VRRP MACs)== turn off MAC spoofing

  ** **

 For this it seems you would need to implement the port security extension
 which allows one to enable/disable port spoofing on a port. 

  ** **

 This would be one way of doing it. The other would probably be adding a
 list of allowed VRRP MACs, which should be possible with the blueprint
 pointed by Aaron. 

 2.   Be able to allow IPs which are not defined on the port level
 to transmit packets (for example, IP used for HA service that moves between
 an HA pair) == turn off IP spoofing

  ** **

 It seems like this would fit your use case perfectly:
 https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairs

  3.   Be able to allow broadcast message on the port (for example for
 VRRP broadcast) == allow broadcast.

  

  Quantum does have an abstraction for disabling this so we already allow
 this by default.  

   

 Regards,

 -Sam.

  

  

 *From:* Aaron Rosen [mailto:aro...@nicira.com]
 *Sent:* Friday, July 19, 2013 3:26 AM
 *To:* OpenStack Development Mailing List
 *Subject:* Re: [openstack-dev] Chalenges with highly available service VMs
 

  

 Yup: 

 I'm definitely happy to review and give hints. 

 Blueprint:
 https://docs.google.com/document/d/18trYtq3wb0eJK2CapktN415FRIVasr7UkTpWn9mLq5M/edit

 https://review.openstack.org/#/c/19279/   patch that merged the feature;
 

 Aaron

  

 On Thu, Jul 18, 2013 at 5:15 PM, Ian Wells ijw.ubu...@cack.org.uk wrote:
 

 On 18 July 2013 19:48, Aaron Rosen aro...@nicira.com wrote:
  Is there something this is missing that could be added to cover your use
  case? I'd be curious to hear where this doesn't work for your case.  One
  would need to implement the port_security extension if they want to
  completely allow all ips/macs to pass and they could state which ones are
  explicitly allowed with the allowed-address-pair extension (at least
 that is
  my current thought).

 Yes - have you got docs on the port security extension?  All I've
 found so far are

 http://docs.openstack.org/developer/quantum/api/quantum.extensions.portsecurity.html
 and the fact that it's only the Nicira plugin that implements it.  I
 could implement it for something else, but not without a few hints...
 --
 Ian.


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

  


 ___
 OpenStack-dev mailing list
 OpenStack