ab
Check out the networking guide.
http://docs.openstack.org/newton/networking-guide/
http://docs.openstack.org/newton/networking-guide/deploy-ovs.html
http://docs.openstack.org/newton/networking-guide/config-sriov.html
--
Sean M. Collins
_
didn't emerge from the void, fully formed, as a Neutron developer. I
was part of a team that had pain points in Neutron that we needed to
alleviate, so we jumped into the Neutron community, participated in
the weekly IRC meetings, filed bugs, started contributing patches,
etc...
So why have these g
Sean Dague wrote:
> I'll probably still default this to python3, it is the future direction
> we are headed.
Works for me :)
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsub
That is great news! Congrats!
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin
I will work on
cleaning it up and fixing the errors (it might just need a recheck?)
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?
of fits this usecase:
http://developer.openstack.org/firstapp-libcloud/
The networking section, can always use improvement:
http://developer.openstack.org/firstapp-libcloud/networking.html
--
Sean M. Collins
__
OpenStack D
-openstack-ansible-upgrade-ubuntu-xenial-nv/ac09458/console.html#_2017-01-11_21_13_55_572404
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
look
> into ways we can ensure this gets run, and what options we have.
Excellent. Thanks for all the info. I'm going to start poking around at
the gate-check-commit script and see if I can build up an AIO node, then
do
e3c9bfda76d022fcc53904594e9c/devstack-vm-gate.sh#L121
[5]:
https://github.com/openstack-infra/devstack-gate/blob/8740b6075b53e3c9bfda76d022fcc53904594e9c/devstack-vm-gate.sh#L265
[6]: https://review.openstack.org/#/c/394895/
--
Sean M. Collins
OK - is there any way that I can assist?
What about the challenges I discussed in my initial mail related to
long AIO build times etc..?
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions
dded a "_upgrade" boolean var that is
> set when the upgrade job is run via tox - so feel free to take a look there.
Ah OK I see now.
I guess what I'm driving at, is how do we get automated coverage for the
full end-to-end upgrade, so that issues[1] that I uncovered during manual
testing
gy before we start throwing things into
devstack-gate
My $0.02
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
I don't like how it's adding more conditionals and complexity to an
already fairly complex shell script. I've commented as such on the
review.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage
t done (it's been an action item in our meetings for a few weeks,
> but hasn't landed just yet). If you have any questions or would like to get
> involved feel free to stop by and discuss in the #openstack-ansible channel
> on freenode.
>
Thanks
--
Sean M. Collins
Box so that I could re-run the upgrade
quickly. Worst case perhaps set up a 3rd party CI system that could use
that trick? Just throwing ideas out there.
Thoughts?
--
Sean M. Collins
__
OpenStack Development Mailin
Thanks for all your hard work - I remember the Bad Old Days when there
was little to no documentation on anything in OpenStack. We are in a
much better place, thanks to your work.
--
Sean M. Collins
__
OpenStack
Hey all,
Sorry for screwing up the gate - thankfully with the linuxbridge job
being in the check queue for DevStack we'll prevent me from making any
more oopsies.
--
Sean M. Collins
__
OpenStack Development Mailing List
Sean M. Collins wrote:
> zhi wrote:
> > hi, all.
> >
> > I have a quick question about devstack.
> >
> > Can I specify OpenvSwitch version in local.conf when during the
> > installation of devstack? I want to OVS 2.6.0 in my devstack. Can I specify
> >
s://git.openstack.org/openstack/neutron
OVS_BRANCH="v2.6.0"
I haven't tried it locally, but I think that's the idea.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
ds that we use for our testing infrastructure.
https://github.com/kubernetes/kubernetes/issues/12083
Obviously since k8s is written in Go, they can't really use Shade out of
the box - so this new project you are working on is *exactly* what the
doctor ordered.
--
Sean
/neutron-multinode-jobs-newton
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin
[2]:
http://codesearch.openstack.org/?q=ml2_config.cfg.CONF.set_override=nope==
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack
e.2016-09-30.log.html#t2016-09-30T17:53:08
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstac
such that we don't like these kind of patches, but I
couldn't find the mailing list thread where we last had this discussion.
https://review.openstack.org/#/c/343133/
Anyway, yeah this kind of thing is really annoying and burns a ton of
resources for no good reason
--
Sea
838512
[4]:
http://logs.openstack.org/01/362901/1/check/gate-shade-dsvm-functional-neutron/9698d83/logs/devstacklog.txt.gz#_2016-08-30_18_46_38_671
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage
the same
organizational dysfunction as my previous jobs, but just overall they're
hard to debug and maintain and I don't like to use them.
/rant
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions
OSIC cloud (that runs Neutron on IPv6) and that had an impact on the
> overall sluggishness of the gate [2]. Once all of the fixes are in, we
> should be back in business...until the next fire!
IPv6 only OpenStack installations sort of snuck up on
+1 on this plan too, if the +2's I've been slinging haven't made it
obvious :)
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
For some reason I installed the newer version but still the version
string reports
Gertty version: 1.1.1.dev24
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev
Also I was the one who approved the original patch, so the fault rests
on my shoulders. My apologies.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
really hoping that with the new lib/neutron we can just
move away from this mess that we've got and start fresh.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
re the majority of an application's logic was
embedded in huge stored procedures and database triggers - so I'm a bit
biased.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: ope
Sam Yaple wrote:
> In this situation, since you are mapping real-ips and the real world runs
> on 1500 mtu
Don't be so certain about that assumption. The Internet is a very big
and diverse place
--
Sean M. C
e is still fairly new. Deployments still use the old
code[1]. So, I don't know if Neutron is quite there yet on the pecan
front. :(
[1]:
https://github.com/openstack/neutron/blob/b59bb0fcfa41963c0e2f7bcbf34b7e4f4ff5cd08/neutron/common/config.py#L174
Doesn't look like anyone sets it. I don't see any references to it in
the provisioning tools (puppet, ansible, salt).
http://codesearch.openstack.org/?q=ipam_driver=nope==
So probably only very advanced users have done anything with it since
it would require manual configuration?
--
Sean M
org/pipermail/openstack-dev/2016-May/095349.html
http://lists.openstack.org/pipermail/openstack-dev/2016-May/095361.html
[1]: http://lists.openstack.org/pipermail/openstack-dev/2016-May/095095.html
[2]:
https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L46
--
Sean M. Coll
Take a look at the networking-sfc project.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
Ihar Hrachyshka wrote:
>
> > On 06 Jun 2016, at 16:44, Sean M. Collins <s...@coreitpro.com> wrote:
> >
> > I agree, it would be convenient to have something similar to what Nova
> > has:
> >
> > https://github.com/openstack/nova/blob/master/n
for doing wiring of router ports and didn't
need the L2 agent running.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubsc
he L3 agent
comes up it complains because br-int hasn't been created.
https://github.com/openstack-dev/devstack/blob/master/lib/neutron_plugins/ovs_base#L20
Anyway, here's the fix.
https://review.openstack.org/#/c/326063/
be nice to have the agents report their version, so it
bubbles up into the agent-list REST API calls.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
need better documentation/help text string to help
clear this up.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
I can be one of the mentors for those interested in the Neutron project
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
The only thing I am remotely aware of that is relevant is:
https://bugs.launchpad.net/bugs/1558626
But that's really just in one agent.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions
takes it out of the main stack run[1].
I'll keep the main code in neutron-legacy around if someone wants to
call it from their local.sh or whatever - but it'll eventually be
removed when we remove neutron-legacy.
[1]: https://review.openstack.org/#/c/318746/
--
Sea
and disabling it[2] in every job - can we just delete it?
[1]: https://review.openstack.org/#/c/314079/
[2]: https://review.openstack.org/#/c/318739/
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage
ay, "The community must do this for me"
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.o
We could do a variation on what was done in
https://review.openstack.org/#/c/317754/1/lib/tempest
Something like https://review.openstack.org/#/c/318145/ ?
That way, no more
IS_SOMETHING_ENABLED_THAT_WE_COULD_DISCOVER_VIA_THE_API variables?
--
Sean M. Collins
; Until now this mean that L3 was supported by the plugin.
> Thanks
> Gary
Right, but that patch was because changing Q_L3_ENABLED to true by
default broke other CI systems.
https://bugs.launchpad.net/devstack/+bug/1
a page
from the OVN devstack plugin and start building up your own networking,
rather than relying on any code in neutron-legacy.
https://github.com/openstack/networking-ovn/commit/12e5bb646a4e0b43ef4c73bb627480a2dbb3e31c
--
Sea
va, and I don't think
that we should support anything but a UUID for a network id. Period.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@list
isting one. We just replaced the nova.py dynamic
> inventory plugin in the last year with the new openstack.py system.
Interesting - I'd like to know more. A quick find / grip didn't help me
find anything, can you help?
Thanks
--
Sean M. Collins
__
. I've been watching Zuul all afternoon, but oddly
it didn't trigger any breakage in the gate so far.
So, hopefully we can clean up my boo-boos quickly and pretend this
never happened.
--
Sean M. Collins
__
OpenStack
://review.openstack.org/168438.
Ugh.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org
--
Sean M. Collins
__
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
at seems less than ideal for our users though.
This is exactly what every OpenStack project does. Provide an API
and a way for different implementations to exist under the same API.
So, why does this need to be in the OpenStack namespace?
-
Sean M. Collins wrote:
> Here is the patch I'm using to test the refactor against the Neutron
> CI jobs.
>
> https://review.openstack.org/#/c/278417/
>
Here's the test patch to make sure anything that is using the
neutron-legacy file isn't disrupted:
https://review.openstack
16-April/091764.html
So, take a look at what I've done so far, take it for a spin, and if you
have any thoughts or ideas please share them!
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usa
Here is the patch I'm using to test the refactor against the Neutron
CI jobs.
https://review.openstack.org/#/c/278417/
There is still some work to be done, and it shows.
--
Sean M. Collins
__
OpenStack Development Mailing
ther long time
http://paste.openstack.org/show/495994/
So, it's still voting on DevStack changes but I think we probably should
revoke that.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage qu
Markus Zoeller wrote:
> I guess having an IF-ELSE block in a "local.conf" is
> crazy talk?
Yes, I think it is. local.conf is already a pretty big complex thing for
someone starting out, as it is.
--
session in Tokyo.
So, It'd be great to get other people involved, get an API hashed out
that doesn't expose all the nitty gritty DB details (like it currently
is) and move forward.
--
Sean M. Collins
__
OpenStack Development
ents, I think we need to clean them up, and again,
see what can be configured by default.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
drivers. I'd rather see some mechanism_drivers already
enabled, and if you have a difference in opinion, set mechanism_drivers
in your local.conf.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage quest
b/master/lib/neutron_plugins/ml2#L27
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi
1f5af1/lib/neutron_plugins/linuxbridge_agent#L63
[2]: https://review.openstack.org/168438
[3]:
http://docs.openstack.org/liberty/networking-guide/scenario-classic-lb.html#example-configuration
--
Sean M. Collins
__
OpenStack D
d
packet filtering features, as opposed to extending the security group
API. It is a failure on my part to advocate for a solution,
then not be able to deliver the required work. I am sorry for this,
truly.
--
Sean M. Collins
__
Op
think we should consider
making it the default.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openst
Inessa Vasilevskaya wrote:
> different configurations of of_interface and ovsdb_interface options
> (dsvm-fullstack [2] and rally tests are by now all I can think of).
Wait, we have *two* different configuration options???
WHY WHY WHY
--
Sean M. C
I for one, have grown fond of "Mutnauq" while doing the DevStack neutron
re-write ;)
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.ope
in the breakage.
I have filed a bug with all the details of my findings, but I wanted to
bring it to the attention of a wider audience.
https://bugs.launchpad.net/python-novaclient/+bug/1561938
How do we proceed? Revert ae598280 ?
--
Sean M. Collins
g
the OVS stuff that is currently in Neutron's DevStack plugin
moving over to this plugin.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@list
the old docbook
source - not the RST conversion.
I cheated a bit - I used Ihar's writeup in devref and directly
linked to it in the operations guide.
https://review.openstack.org/#/c/291784/
--
Sean M. Collins
__
OpenSt
voting and running on every patchset (sorry, not sorry).
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
othing complete or deep enough. That’s
> something we will look into improving at the start of the N cycle.
If I can make a suggestion, let's put it in the operations guide. I
think we can add a Neutron specific chapter - and I have a review up as
WIP to remind myself:
https://review.openstack.org/
I probably speak for all FwaaS cores when I say - "Welcome!"
Frankly I had just assumed he had core privileges for our repo anyway
via an inherited ACL.
--
Sean M. Collins
__
OpenStack Development Ma
Let's put together a bug and tackle this in Newton?
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.ope
sridhar basam wrote:
> This doesn't sound like a neutron issue but an issue with how the
> conntrack module for GRE changed in the kernel in 3.18.
>
>
> http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/47705
>
> Sri
Oooh! Wicked nice find. Th
Clark Boylan wrote:
> On Wed, Mar 2, 2016, at 09:38 AM, Sean M. Collins wrote:
> > Kevin Benton wrote:
> > > * Neutron cannot be trusted to do what it says it's doing with the
> > > security
> > > groups API so users want to orchestrate firewal
on a v4 network, which has NAT enabled.
Many public providers, the network you attach to is publicly routed, and
with the move to IPv6 - this will become more common. Remember, NAT is
not a security device.
--
Sean M. Collins
__
erence between Nova-Net and Neutron, where security group names
are not unique in Neutron - hence the problem above.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
nd then filter using the guest - then fine. That's their
prerogative. All they've done is change where their security policies
are implemented. Instead of a REST API they want to do it directly on
their guest.
--
Sean M. Collins
__
th0
> 172.18.20.0/24 dev eth0 proto kernel scope link src 172.18.20.23
> 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
Was this after you did an unstack? Or right after stack.sh fails?
--
Sean M. Collins
__
Can you provide the output of
"ip route show"
Was this after a unstack.sh that failed?
It could be https://bugs.launchpad.net/devstack/+bug/1423020 popping up
again
--
Sean M. Collins
__
OpenStack Developme
so the partial jobs are going to
reflect the reality on the ground better.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
t I reached out to during
these past months when I got stuck on this. Ihar, Matt K, Kevin B,
Armando - this is a huge win.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: ope
Jay Pipes wrote:
> From our Mirantis team, I've asked Sergey Belous to handle any necessary
> changes to devstack and project-config (for a functional test gate check
> job).
I'll keep an eye out in my DevStack review queue for these patches and
will make sure to review them promptly.
-
's a lot of work, but without that, as I think others have
stated - where's the OpenStack part?
Like that Wendy's commercial from way back: "Where's the beef?"
--
Sean M. Collins
__
OpenStack Development Mailing Lis
does hijack the original
intent of the thread. Which is now happening.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?
out a true vendor-neutral API
(as I understand Mike Perez's position, and agree with!).
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.ope
I know historically there were postgres jobs that tested things, but I
think the community moved away from having postgres at the gate?
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions
-onboarding.html
We are also available on Freenode in the IRC channel if you have
questions
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
nnection reset by
peer"
I tried pushing down a patch to cram network_device_mtu down to 1450 in
the hopes that it would do the trick - but sadly that didn't fix. I'm
going to have to keep digging. I am almost certain it's something that
Matt K (Sam-I-Am) has already made
miss a lot in this topic so far.
Dunno. Maybe?
> Also I see some qg-2c68fb65-21 device in the worlddump output from above in
> global namespace. The device has mtu = 1500. Which router does the device
> belong to?..
Good question.
--
Sean M. Collins
__
with a fresh
event from
http://eavesdrop.openstack.org/calendars/firewall-as-a-service-fwaas-team-meeting.ics
We'll get the correct time next week, my apologies.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage
filebug with the tag
> 'seg-guide'
Thanks for the heads up. Let's advertise it during the docs portion of the
Neutron team meeting too. :)
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscr
]: http://openvswitch.org/pipermail/dev/2015-August/059335.html
[3]: Yes, it's only one data point
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
d.net/neutron/+bug/1378732
https://bugs.launchpad.net/neutron/+bug/1332564 (I hit this one
personally)
Please please please please please let's put a lot of effort into making
sure this works. I beg you.
--
Sean M. Collins
__
" and didn't. Prior to the
vendor decomposition effort, We had a multitude of drivers that were
in-tree, with the public perception that drivers that were in Neutron's
tree were "sanctioned" by the Neutron project.
That may not ha
Kilo is in the "security supported" stage of the lifecycle. So no,
that's not going to get backported.
http://docs.openstack.org/releases/index.html
--
Sean M. Collins
__
OpenStack Development Mailing List (not
1 - 100 of 294 matches
Mail list logo
