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
_
s.
I 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 w
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)
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
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?
quot;""
We have a guide that sort 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
_
te-openstack-ansible-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...
can 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
ob/8740b6075b53e3c9bfda76d022fcc53904594e9c/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
_
le.
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 ques
es we added 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
guration strategy 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.o
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
o get that 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
ng memory) in VBox 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
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
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 q
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.
--
/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
so
far
[2]:
http://codesearch.openstack.org/?q=ml2_config.cfg.CONF.set_override&i=nope&files=&repos=
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsub
3openstack-trove.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:/
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 reaso
08-30_18_56_58_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
ect suffers 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
> 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 u
+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...@list
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
y I'm 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: ope
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)
Unsubs
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
n code 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/conf
e manual configuration?
--
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
3.html
http://lists.openstack.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/co
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 wrote:
> >
> > I agree, it would be convenient to have something similar to what Nova
> > has:
> >
> > https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/versions
aths 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?subje
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/#/
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
ke we 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
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 ques
st 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
h 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
and say, "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://li
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
is to take 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/12e5bb646a4e0b43ef4c73bb627480a2dbb3e31
7;t have been accepted into Nova, 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)
Unsu
n fixing the existing 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
__
reverting https://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://list
--
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://r
tack.
http://lists.openstack.org/pipermail/openstack-dev/2016-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
_
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 Ma
ggering it for a . rather 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
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.
--
an all-night coding
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
__
_plugins.
For the OVS and LB agents, 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: openst
d to pick
mechanism_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
://github.com/openstack-dev/devstack/blob/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:un
stack/blob/1195a5b7394fc5b7a1cb1415978e9997701f5af1/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
_
cket 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
hink 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.o
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
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
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...
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
__
O
making it
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?sub
ing 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
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 Mailing Lis
t'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://list
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 fin
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 firewalls directl
oting 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:
everything, and 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
dev eth0
> 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:u
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 pr
02-18T01:18:32
[4]:
http://logs.openstack.org/78/279378/9/experimental/gate-grenade-dsvm-neutron-multinode/40a5659/console.html#_2016-02-17_22_37_33_277
[5]: https://review.openstack.org/#/c/279721/
--
Sean M. Collins
__
OpenStack
eally!
Yes, it'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
_
point it 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.open
on that will be used to flesh 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)
Unsubscri
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
butor-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
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
> 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
_
4] Connection 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-A
ebug 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
about turning them
on by default.
It's not cut and dry, but maybe taking a stab at it will help us clarify
which really options really are a toss up between on/off and which
should be defaults.
--
Sean M. Collins
___
s.launchpad.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
___
w.openstack.org/#/c/276411/
[2]: 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 questio
1 - 100 of 301 matches
Mail list logo
