ersion we were concerned about 12.04 LTS. I think we settled on
2.63 since that was what was available in the main release channel,
or possibly what was being shipped in the cloud-archive repos.
--
Sean M. Collins
___
OpenStack-dev mailing lis
Thanks Doug!
It is a big link but I'd rather see the full URL than trust opening a
URL shortener link. I've been rickrolled too many times to count. :)
--
Sean M. Collins
__
OpenStack Development Mailing Lis
appreciate it.
I plan to study up on the ML2 plugin and add support for the QoS
extension, so we can transition away from the OVS plugin when it is
deprecated.
--
Sean M. Collins
pgpMxoF9m8RkP.pgp
Description: PGP signature
___
OpenStack-dev
ps to the qos_policies table), that stores
implementation specific behavior/configuration.
There is also a wiki page, that has some useful links:
https://wiki.openstack.org/wiki/Neutron/QoS
--
Sean M. Collins
pgpFaQTxkBTIG.pgp
Description: PGP signature
___
imply specifying behavior that was originally undefined.
The motivation is to help Neutron work with IPv6 - which is a must-have
for Comcast.
--
Sean M. Collins
pgpQJV_mcuSwE.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev
I don't see a summit proposal for Neutron, on the
subject of IPv6. Are there plans to have one?
--
Sean M. Collins
pgpFNUoI1OtIP.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.
Nevermind, my neutron repo was stale, didn't pick up the fix. Sorry for
the noise
--
Sean M. Collins
pgpntP9YLx4nR.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cg
empty migration_for_plugins
array,
which means that the migration script is never run, hence the tables are
never created.
The lbaas_add_status_des script, however, has migration_for_plugins
array set to "*" - meaning it is run for all plugins.
Does this sound correct to anyone else?
--
Due to the summit.
--
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
Hi,
The docs right now are a little unclear about if it is possible to stop
logging the output of all the screen sessions to the local filesystem.
It has a tendency to fill up my filesystem on my little NUCs :(
--
Sean M. Collins
ant screen to run, and not
log the output to files, since I have a tiny 16GB ssd card on these NUCs
and it fills it up if I leave it running for a week or so.
--
Sean M. Collins
__
OpenStack Development Mailing Lis
s.
[1]: https://etherpad.openstack.org/p/FWaaS_with_DVR
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.ope
On Mon, Nov 02, 2015 at 10:43:45AM EST, Davanum Srinivas wrote:
> Sean,
>
> ah. so the tip about LOGDIR to /dev/null may work for you
>
That's not going to work. LOGDIR is used in multiple mkdir calls.
--
handle the issue of the log file growing in size.
I mean I guess the real answer is to configure logrotate. ugh.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscr
Cool. I plan on attending, now that I have a config for running DVR in my local
lab.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
more discussion.
--
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/open
r/doc/source/usage.rst
It's very basic, it was just me hacking away at a proof of concept to
demonstrate that what I was proposing was possible, that we didn't need
a single database table with 10+ columns.
--
s it becomes super popular I think it's fine to just discuss on
#openstack-neutron.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.
On Wed, Nov 04, 2015 at 07:25:24AM EST, Sean Dague wrote:
> On 11/02/2015 10:36 AM, Sean M. Collins wrote:
> > On Sun, Nov 01, 2015 at 10:12:10PM EST, Davanum Srinivas wrote:
> >> Sean,
> >>
> >> I typically switch off screen and am able to redirect logs to a
Learn from my mistake, check your calendar for the timezone if you've
created an event for the weekly meetings. Google makes it a hassle to
set things in UTC time, so I was caught by surprise by the FwaaS meeting
due to the DST change in the US of A.
--
Sean M. Co
Take all the time you need, Neutron can wait, family is more important.
Take care.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
even get started.
[1]:
http://specs.openstack.org/openstack/ironic-specs/specs/approved/ironic-ml2-integration.html#assignee-s
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-de
most likely need to be its own endpoint and repo, and have
stakeholders from other projects, not just networking-sfc. That will
take time and quite a bit of wrangling, so I'd like to defer that for a
bit and just work on all the services having the same data model, where
we can make changes qu
ports-upgrade tag
https://review.openstack.org/239778 - Introduce assert:supports-rolling-upgrade
tag
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev
is that if we
start pulling things into Neutron we lose valuable insight from people
who know a lot about Grenade.
Not to mention, Sean and I have had conversations about trying to get
Neutron as the default for DevStack - we can't just take our ball and go
in our own corner.
Monday sounds good to me. 1500 utc sounds good too.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
like iPXE would be a good
investment long term, just based on those three features.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subj
g of working on the following on Monday:
1) capture that somewhere in the upgrade docs we're putting together in
neutron's devref
2) Adding the stanza to project-config to get grenade running for
Neutron
3) Take a look at the patches that Armando linked a couple emails back
in this
On Fri, Nov 13, 2015 at 01:53:49AM EST, Paul Carver wrote:
> On 11/3/2015 1:03 PM, Sean M. Collins wrote:
> >Anyway, the code is currently up on GitHub - I just threw it on there
> >because I wanted to scratch my hacking itch quickly.
> >
> >https://github.com
Attach to the screen session Devstack sets up, and verify that the Nova
compute service is running. It's running in the screen session named
n-api.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for
Chatted with Sean D. on IRC, pushed up a patch
https://review.openstack.org/#/c/245862/
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
On Mon, Nov 16, 2015 at 12:47:13PM EST, Vasyl Saienko wrote:
> [0] https://github.com/jumpojoy/neutron
The way you created the repository in GitHub, it is impossible to diff
it against master to see what you did.
https://github.com/jumpojoy/neutron/compare
--
Sean M. Coll
Networking-sfc is still just a shell - there is no functional code.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
ethods, and then later start
introducing the actual method bodies in small pieces with good unit
tests for each one. Small pieces. Tiny steps.
My $0.02 USD
--
Sean M. Collins
__
OpenStack Development Mailing List (not for
how are we testing all this code we have for
the IPAM feature if you can't install it in DevStack?
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lis
Ignore me, I'm not able to read and comprehend today. Sorry.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
We'll start again next week at the 18:30 UTC time
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
de/011124b/logs/old/screen-q-l3.txt.gz?level=WARNING
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.op
Yeah looks like I read it wrong - the failure occurred during the
initial resource creation phase, based on comparing the logs that Artur
posted.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage
had the same issue as your failed run - we didn't even get to the
upgrade phase - we failed on the initial resource creation phase, since
my new/ directories were totally empty except for localrc.
--
Sean M. Collins
__
O
On Wed, Nov 25, 2015 at 12:53:56PM EST, Armando M. wrote:
> On 25 November 2015 at 09:49, Sean M. Collins wrote:
>
> > Yeah looks like I read it wrong - the failure occurred during the
> > initial resource creation phase, based on comparing the logs that Artur
> > poste
I'll have to run some rechecks - but perhaps the issue is stable/kilo
faceplanting on creating the initial resources (which is what, a 30%
success rate? 1 out of 3 runs?) - the only run where we got far enough
to upgrade we were actually successful?
--
Sean M. Co
think Grenade checks out stable/liberty - so that's probably a version
string generated from the tip of stable/liberty
> I am really confused, I should probably stop asking questions and do some
> homework :)
No please keep asking - I think we're all learning things here. I'm
to use the aliased() function - since
there are some examples that are similar to what you are trying to do -
check out the "Joins to a Target with an ON Clause" section in the first
link.
http://docs.sqlalchemy.org/en/latest/orm/query.html#sqlalchemy.orm.aliased
--
Sean
Documentation_
>
> Whatever is the consensus on the questions raised here, I'd like that to
> be explicitly recorded somewhere, and volunteer to do that. Not sure
> yet whether that should be in the Neutron devref, or in the networking
&
router_intf_qry:
> router_id =router.router_id
>
That looks pretty close. My only suggestion would be to try and see if
you can just alias it once, instead of twice. Basically see if it is
possible to replace al
Was perusing the documentation again this morning and there is another
thing I found - you can call join() with the aliased=True flag to get
similar results.
Check out the "Constructing Aliases Anonymously" section.
http://docs.sqlalchemy.org/en/latest/orm/query.html
--
Sean
on bugs where I think I can contribute productively.
So - I think it has been effective. It's made me pay attention to it. :)
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubs
t the
relationship between neutron-specs, RFE bugs, and some features being
documented in devref. Especially when a review includes the actual code,
then a new RST file in devref - wasn't that what specs were for?
--
Sean
On Thu, Dec 03, 2015 at 10:58:07AM EST, Ihar Hrachyshka wrote:
> The thing I would like us to see enhanced is making sure that tags set to
> bugs are actively tracked by corresponding teams.
Thanks - you just reminded me to tag two bugs that I had just touched.
:)
--
Sean M. C
realize that it didn't require being a core reviewer.
I pushed a patch to our policy docs to help clarify that
https://review.openstack.org/253164
--
Sean M. Collins
__
OpenStack Development Mailing List (not for u
unning swift on wheezy is still
> a thing people care about.
They would also need to backport a more recent version of Open vSwitch.
https://bugs.launchpad.net/devstack/+bug/1520338
I think it might be time to cut support, the list of packages that need
to be backported is only going to grow
-
On Mon, Nov 30, 2015 at 07:00:07AM EST, Sean Dague wrote:
> On 11/25/2015 11:42 AM, Sean M. Collins wrote:
> > The first run for the multinode grenade job completed.
> >
> > http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/log
On Fri, Dec 04, 2015 at 01:15:07PM EST, Sean Dague wrote:
> Is *not* always due to a failure.
Yep - sorry. Friday typos :)
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscr
Thanks for the advance notice. Sounds good to me.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
the implementation may differ in some ways. The devref should
> > be kept current with refactorings, etc. of the implementation.
>
> Henry, I was also impressed by how clearly you communicated this.
> This ought to be included somewhere prominently in our
> doc/source
paying back amotoki for the Tokyo social).
[1]: http://lists.openstack.org/pipermail/openstack-dev/2015-July/068859.html
[2]: https://review.openstack.org/205674
--
Sean M. Collins
__
OpenStack Development Mailing List (not
On Mon, Dec 07, 2015 at 10:26:53PM EST, Sean M. Collins wrote:
> FWaaS for example is v2.0/fw/
Sorry - typo
v2_0/fw/
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscr
listed under v2_0, and do not need
> any separate Parent ID.
Just because "most" are under /v2_0 doesn't mean new ones should.
FWaaS for example is v2.0/fw/
I think it's better to be more explicit.
--
Sean M. Collins
___
t an API. Especially when api-site and
networking API doc needs improvement.
Specs are a good starting point, but my hope would be that perhaps we go
back through the specs and add a note at the top pointing to the
maintained API documentation - once the feature has lan
viors, and that
implementations behind the API is where products and projects can
differentiate.
--
Sean M. Collins
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.open
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
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
; 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
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
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
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
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
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
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
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
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
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/#/
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
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
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
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
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
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
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
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
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
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
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
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
_
://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
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
_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
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
__
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.
--
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
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
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
_
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
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
__
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
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
. 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
__
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
_
n and Nova,
so let us know what we can do to help raise awareness on both sides.
https://wiki.openstack.org/wiki/CrossProjectLiaisons#Inter-project_Liaisons
--
Sean M. Collins
__
OpenStack Development Mailin
1 - 100 of 301 matches
Mail list logo
