Re: [openstack-dev] Developer's deepdive of SRIOV Passthrough for Neutron
pranab boruah wrote: > Hi Folks, > We are trying to understand what happens when we launch an instance on > a compute running SRIOV agent. By "what happens" I mean, > 1) how the request from the Neutron-server ends up on the targeted > Compute node that runs the SRIOV agent? > 2) What all steps does the sriov agent in the compute node undertakes? > 3) how an instance(vf-direct-attach) is launched ? > 4) Does it work along with OVS ? > Can anyone point to some developer deep-dive guide that answers those > questions? Please help. > Pranab 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 __ 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] Large Contributing OpenStack Operators working group?
Jay Pipes wrote: > 4) I see a lot of agenda items around projects like Gluon, Craton, Watcher, > and Blazar. I don't see any concrete ideas about talking with the developers > of the key infrastructure services that OpenStack is built around. How does > the LCOO plan on reaching out to the developers of the long-standing > OpenStack projects like Nova, Neutron, Cinder, and Keystone to drive their > shared agenda? To expand on this point: How effective are these teams at actually communicating with the developers of OpenStack components? My concern is that all these working teams collect a lot of information, then it is left in these silos and never makes their way back to projects like Neutron, Nova, etc... I suppose I am also philosophically opposed to having all these special snowflake working groups. If you want to get things done in OpenStack the best thing to do is roll up your sleeves and start participating directly in the project where you need work done. I know for a fact that in the Neutron community, we had RFE bugs and other processes so that operators could submit requirements, and they weren't expected to do all the work by themselves. 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 why have these groups? -- 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
Re: [openstack-dev] [devstack] issues with requiring python3 only tool?
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) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack-ansible] Ocata deployed on CentOS 7!
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/mailman/listinfo/openstack-dev
Re: [openstack-dev] [os-ansible-deployment] Periodic job in infra to test upgrades?
Jesse Pretorius wrote: > Hi Sean, > > Great to see you taking the initiative on this. > > I think the starting point we’d have to work from with the way the builds are > executed now would be to have the upgrade job execute in a periodic pipeline > that has a longer timeout. While it would be ideal to do on-commit tests it’s > just untenable right now as it would severely slow down the workflow. OK - I pushed the following patch to project-config to reflect this change https://review.openstack.org/419517 It depends on https://review.openstack.org/418521 - 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?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Confusion around the complexity
Joshua Harlow wrote: > So I don't want to start to much of a flame-war and am really just trying to > understand things that may be beyond me (so treat me nicely, ha). > > The basic question that I've been wondering revolves around the following > kind of 'thought experiment' that asks something along the lines of: > > """ > If I am a user of openstack, say I'm an iphone developer, trying to get my > 'game' and associated 'game APIs' setup in a manner that is HA (say fronted > by a load-balancer), using my custom image, secure and visible to either an > intranet or to the large internet then what is the steps I would have to do > when interacting with openstack to accomplish this and what would the > provider of openstack have to give to me as endpoints to make this possible. > """ 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 __ 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] [os-ansible-deployment] Periodic job in infra to test upgrades?
OK - with https://review.openstack.org/#/c/418521/ we have at least a working POC of what we can do. The issue is that we're running into the Zuul timeout. Depending on how quickly the AIO is built, we can get to the point where we run the upgrade script[2]. However in some runs we don't get to the end of the AIO build[3]. So, the question is, how do we proceed? I'm not a real LXC expert but if we could somehow cache stable builds of the LXC containers, so that bootstrapping the AIO just means downloading and launching them, so that we can use the majority of the Zuul runtime to execute the upgrade script, that'd be great. I know he have diskimage builder that does something sort of like this, maybe we can do something similar for the LXC containers? [1]: http://logs.openstack.org/21/418521/7/experimental/gate-openstack-ansible-openstack-ansible-upgrade-ubuntu-xenial-nv/6704087/console.html#_2017-01-11_05_13_16_114022 [2]: http://logs.openstack.org/21/418521/7/experimental/gate-openstack-ansible-openstack-ansible-upgrade-ubuntu-xenial-nv/6704087/console.html#_2017-01-11_05_13_24_895056 [3]: http://logs.openstack.org/21/418521/8/experimental/gate-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...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [os-ansible-deployment] Periodic job in infra to test upgrades?
Andy McCrae wrote: > The work we can do now, which if you're able to help with would be really > great, is: > > Plan how we execute the actual job - at the moment the aio is run through a > script (scripts/gate-check-commit.sh) - the upgrade test would have to hook > into this (using the SCENARIO=upgrade) var, or we'd need to look into > changing this method up entirely (role gates all use tox for example). > > If the current method is sufficient we need to set the job up. Once we have > a working scenario (regardless of time taken for the test), we 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 node, then do the upgrade. -- 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
Re: [openstack-dev] [infra][devstack-gate][all]support multi-region gate environment
joehuang wrote: > In multi-region environment(for example, two regions RegionOne and > RegionTwo), KeyStone will be shared in RegionOne and RegionTwo, so the > primary node and subnode should use different role, one role to enable the > keystone, while another role is to use the keystone in another node, only one > role to support multi-region setup seems to be not possible. The flag > "MULTI_REGION" is to make the subnode play with the role where no keystone > will run. If we don't use the flag, or maybe use DEVSTACK_GATE_MULTI_REGION? > > This is the first patch in devstack-gate for me, any help or guide will be > appreciated. Basically, it's more of a note for myself at this point. We don't directly expose a way to define a role in devstack-gate[1][2][3][4]. We do a lot of heuristics to detect whether or not the node is a primary node or a subnode. Ideally, we should really have an environment variable ($ROLE ?) that can be set by projects in project-config, and just call the test matrix script[5] with the role that is being set in the environment variable. Because otherwise we end up with more if/else checks on random variables like your patch and the MULTI_KEYSTONE[6] patch, and eventually it becomes very difficult to maintain and add to. Does this make sense? [1]: https://github.com/openstack-infra/devstack-gate/blob/8740b6075b53e3c9bfda76d022fcc53904594e9c/devstack-vm-gate.sh#L230 [2]: https://github.com/openstack-infra/devstack-gate/blob/8740b6075b53e3c9bfda76d022fcc53904594e9c/devstack-vm-gate.sh#L259 [3]: https://github.com/openstack-infra/devstack-gate/blob/8740b6075b53e3c9bfda76d022fcc53904594e9c/devstack-vm-gate.sh#L642 [4]: https://github.com/openstack-infra/devstack-gate/blob/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 __ 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] [os-ansible-deployment] Periodic job in infra to test upgrades?
Andy McCrae wrote: > Completely agree, the end goal is to have the full end-to-end testing in > the openstack-ansible repository, along with the individual repo tests. > We have an experimental job setup in > project-config: > (gate-openstack-ansible-openstack-ansible-upgrade-ubuntu-xenial-nv) > although no concrete work has gone into adding this to the repo - so that > one is pending. > > The idea would be to run the upgrade scripts against an AIO built with > stable/newton, and run tests after the upgrade - I'm hoping to see that > land this cycle. 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) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [os-ansible-deployment] Periodic job in infra to test upgrades?
Andy McCrae wrote: > Hi Sean, > > > > OK - is this a job in Zuul ? Where can I find more information? > > > The test is essentially: > > Deploy infra for testing > Deploy other required services > Deploy "stable/newton" version of project_name > Run "master" version of project_name > Run tests for project_name. > > I'm not too sure what further detail you're looking for - but the tests are > run from the "test.yml" play in the "tests" directory of each repository - > and for upgrades 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 manual testing start getting uncovered by automation? [1]: https://review.openstack.org/#/c/400847/ -- 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
Re: [openstack-dev] [infra][devstack-gate][all]support multi-region gate environment
Jay Pipes wrote: > I think it's a good idea to have multi-region testing in the gate, yes. How > does the existing federated Keystone functionality get tested in the gate? > Perhaps that might be an approach to copy? Just throwing out an idea here; > I'm actually not familiar with this part of the gate at all. We have some docs for running multiple regions - http://docs.openstack.org/developer/devstack/configuration.html#multi-region-setup I don't know how stale they are, but work was done. So, really I would like to see some work/research done into that configuration 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.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra][devstack-gate][all]support multi-region gate environment
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 questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [os-ansible-deployment] Periodic job in infra to test upgrades?
Andy McCrae wrote: > Hi Sean, > > I assume you're talking about OpenStack-Ansible (was OS-A-D before moving > to the OpenStack namespace), if not, feel free to ignore my response! Right. > This is actually something we're working on - we have in role testing for > some key OpenStack services (Nova, Neutron, Swift, Keystone, Cinder, > Glance), and upgrade testing for the rabbitmq_server and galera_server > roles. > > This is a first pass effort, the testing right now deploys the Newton > version of the service and then upgrades it and runs a functional test. > This isn't perfect but should help ensure individual services can upgrade > successfully - and can be built upon. OK - is this a job in Zuul ? Where can I find more information? > > The next step is to add an integrated build upgrade test, and we have plans > to 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 __ 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] [os-ansible-deployment] Periodic job in infra to test upgrades?
Hi, A couple weeks ago I did some manual testing of upgrades from Liberty -> Mitaka and Mitaka -> Newton using OSAD and a AIO node. Whenever I hit an issue, I'd report it. I'd be great if we could automate this work. The only challenge I can think of is the fact that building up an AIO node, installing the base version, then doing the upgrade takes quite a bit of time. I don't know if periodic jobs have the same time constraints as jobs in the check and gate queue though. At least on my local machine, I sped up the process by snapshotting the AIO box (disk and running 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 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] [docs] Stepping down from core
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 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] broken linuxbridge gate
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 (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] [devstack] Specify OpenvSwitch version in local.conf
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 > > it? > > > The DevStack plugin for Neutron has a way to build a specific OVS > version from source > > https://github.com/openstack/neutron/blob/master/devstack/lib/ovs > > However there is not a lot of documentation for how it can be used > (which really should be fixed). > > I believe it would be something like this in your local.conf: > > > enable_plugin neutron https://git.openstack.org/openstack/neutron > OVS_BRANCH="v2.6.0" > > I haven't tried it locally, but I think that's the idea. > Sorry, you will also need to set: Q_BUILD_OVS_FROM_GIT=True -- 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
Re: [openstack-dev] [devstack] Specify OpenvSwitch version in local.conf
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 > it? The DevStack plugin for Neutron has a way to build a specific OVS version from source https://github.com/openstack/neutron/blob/master/devstack/lib/ovs However there is not a lot of documentation for how it can be used (which really should be fixed). I believe it would be something like this in your local.conf: enable_plugin neutron https://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) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?
Great idea, I just ran into a similar issue when investigating the following Kubernetes issue[1], and the OpenStack provider. They are running into similar issues around networking and what a "public" network address is, which is exactly what Shade had to deal with, in the public clouds 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 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
[openstack-dev] [infra][gate][all] Changes to the devstack-gate feature matrix
I have been working on a patch to devstack-gate[1], to implement a long standing TODO, where the feature grid will be used to determine the MY_ENABLED_SERVICES that are set[2]. Prior to this patch, there was a lot of manipulation being done to MY_ENABLED_SERVICES based on environment variables, and a lot of conditional checks. If your job configuration uses the OVERRIDE_ENABLED_SERVICES environment variable, you are not affected. However, you may wish to examine this patchset, since it is supposed to make things easier to maintain, going forward. The motivation for this patch is to solve the issue of setting the services that would run on the primary node and the subnode (when running Grenade jobs), without creating more logic checks in Bash. For projects like Neutron[3], there is work that needs to be done to move some services from the primary node (where they are currently upgraded) to the subnode, to match how they will most likely be upgraded in a production environment, where the control plane is upgraded first and data plane components are upgraded later. Introducing roles to devstack-gate in the feature matrix allows us to define roles, and also set the enabled services, based on the role, more easily. For example, this patch will make the movement of certain Neutron agents (L3 agent, dhcp, metadata, etc) from the primary node over to the subnode when running a Grenade test, easier. Please take a look at the patch, a lot of work was done to ensure that the emitted services when running test-matrix.py matches the logic that was originally baked directly into devstack-gate, but more eyes on it is always nice. [1]: https://review.openstack.org/386072 [2]: https://review.openstack.org/#/c/386072/16/devstack-vm-gate.sh [3]: https://etherpad.openstack.org/p/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/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Centralizing some config options will break many stadium projects
It appears though that from the code search that it's all just based on unit tests, and overriding some configuration stuff. Since a lot of these unit test classes inherit from Ml2PluginV2TestCase, and it looks like there is a lot of copy & paste / cargo-cult that occurred where the same line was copied across the stadium[1] to just change some configuration before running unit tests, maybe we should provide an attribute in Ml2PluginV2TestCase to get the oslo.config instance so that overrides can be called? This is assuming I grok the problem, I've only had one cup of coffee so far [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.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Multinode testing with devstack and neutron broken
Armando M. wrote: > At this point I feel that changing the pool range is even less justified. > If I had seen bug [4], I would have been against its fix, because you're > absolutely right as the change being not backward compatible. https://review.openstack.org/#/c/356026 was written by someone on the Trove team to help them with their CI jobs IIRC. CC'ing Matthew since he has more context. I went into the Trove channel and asked them about reverting 356026. It doesn't seem like an option at this point. http://eavesdrop.openstack.org/irclogs/%23openstack-trove/%23openstack-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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ptl] code churn and questionable changes
Sean Dague wrote: > If this is the bug that triggered this discussion, yes, please never do > anything like that - > https://bugs.launchpad.net/python-openstacksdk/+bug/1475722 > Here was another fun one. https://bugs.launchpad.net/python-cinderclient/+bug/1586268 I commented as 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 -- 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
[openstack-dev] [neutron][devstack][all] Deprecation of external_network_bridge and CI impact
Hi, This probably should have been advertised more widely, before the merge happened. I would like to apologize for an after-the-fact e-mail explaining what may be going on for some jobs that are broken. I recently merged a change to DevStack - https://review.openstack.org/346282 It's a little cryptic since it's a revert-of-a-revert. However, if you take a look at the original commit[1], you can get an idea of what is going on. Basically, we were relying on a deprecated setting in Neutron that has been deprecated since liberty[2]. Post 346282, we no longer use that deprecated setting and instead are creating networks the "correct" way. Some jobs that were relying on provider attributes for their networking may be seeing some errors similar to what has happened to Shade[3]. Basically Shade was trying to create a public network using the same provider attributes, that post 346282, we now create during a DevStack run[4]. I know jroll is currently also trying to figure out how to unblock Ironic's CI, since they too were using the provider networking API extension. I imagine there may be some other jobs that are broken (networking-generic-switch seems to be very sensitive), so please take a look at the links and hopefully that will help. [1]: https://review.openstack.org/#/c/343072/ [2]: https://bugs.launchpad.net/neutron/+bug/1511578 [3]: http://logs.openstack.org/01/362901/1/check/gate-shade-dsvm-functional-neutron/9698d83/console.html#_2016-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 (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] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects
Personally I had very bad experiences with stored procedures and triggers in previous jobs, where the amount of side effects that occurred and the overall lack of maintainability of triggers and stored procedures scared me off. We handed off changes to stored procedures and triggers to the DBAs, who had a tendency to not apply them correctly or forget to apply them at a site. Then it was a total nightmare to try and figure out why things wouldn't work, until we discovered that the changes to an SP or Trigger wasn't actually applied. Now, I don't think OpenStack as a project 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 (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] Intermittent gate failures
Armando M. wrote: > One more update: > > We're not quite out of the woods, yet so approve/recheck gently please. > > Things have become slightly better but we still have a pending fix for > Neutron [1]. Recently we also observed zuul nodes dying unexpectedly on the > 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 us. :) -- 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
Re: [openstack-dev] [all] devstack changing to neutron by default RSN - current issues with OVH
+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?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Announcing Gertty 1.4.0
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack][neutron] - neutron gate blocked by devstack change
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...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack][neutron] - neutron gate blocked by devstack change
I just approved the revert. I think we need to step back and re-evaluate the work that we are doing in neutron-legacy. It's very fragile - and really any change to that piece of logic ends up breaking networking-generic-switch, ironic-multitenant-network, midonet, or the gate. Which is why 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Add an extension "btree_gist" to Postgresql
Ihar Hrachyshka wrote: > That’s an interesting precedent. I understand that since we gate on > postgresql and mysql only, the solution is good enough to pass in the gate. > But are we ok fixing a bug just for those two backends, knowing that it’s > left exposed for other backends? Could you think of a solution that would be > backend agnostic? This is why during the review phase, I objected to using a stored procedure for this logic, since it is tied very tightly to the database implementation. I also have a lot of scars and recurring nightmares about an old job where 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Neutron and MTU advertisements -- post newton
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. 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
Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask
Sean Dague wrote: > If we look at the iaas base layer: > > Keystone - custom WSGI with Routes / Paste > Glance - WSME + Routes / Paste > Cinder - custom WSGI with Routes / Paste > Neutron - pecan + Routes / Paste > Nova - custom WSGI with Routes / Paste Neutron's pecan 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/config.py#L174 -- 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
Re: [openstack-dev] [Neutron][IPAM] Anyone using builtin pluggable IPAM driver?
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. 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
[openstack-dev] [Neutron] Enabling/Disabling specific API extensions
The patch that switches DevStack over to using the Neutron API to discover what features are available has landed. https://review.openstack.org/#/c/318145/7 The quick summary is that things like Q_L3_ENABLED[1] and if certain services are running/enabled has been replaced with checks for if an API extension is available. The point being, the Networking API should be discoverable and features should be determined based on what extensions are available, instead of some DevStack-y bits. Neutron controls what API extensions are loaded via the `api_extensions_path`[2] https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L46 So by default Neutron loads up every extension that is included in tree. But what if a deployment doesn't want to support an API extension? With third party CI, prior to https://review.openstack.org/#/c/318145 - systems could get away with it by not enabling services - like q-l3 - and that would stop subnets and routers being created. After that patch, well that's not the case. So is there a way to configure what API extensions are available, so that if a CI system doesn't want to provide the ability to create Neutron routers, they can disable the router API extension in some manner more graceful than rm'ing the extension file? I know at least in one deployment I was involved with, we didn't deploy the L3 agent, but I don't believe we disabled or deleted the router API extension, so users would try and create routers and other resources then wonder why nothing would ever work. >From a discoverability standpoint - do we provide fine-grained a way for deployers to enable/disable specific API extensions? Further reading: http://lists.openstack.org/pipermail/openstack-dev/2016-May/095323.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/config.py#L46 -- 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
Re: [openstack-dev] Openstack support for bump-in-the-wire functions
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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Getting project version from API
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/nova/api/openstack/compute/versions.py#L59-L60 > > > > We should put some resources behind implementing micro versioning and we > > could end up with something similar. > > > > It would also be nice to have the agents report their version, so it > > bubbles up into the agent-list REST API calls. > > Agents already report a list of object versions known to them: > > https://github.com/openstack/neutron/blob/master/neutron/db/agents_db.py#L258 > > In theory, we can deduce the version from there. The versions are reported > through state reports. Not sure if it’s exposed in API. > Right - I was looking at your commit that implemented that - and perhaps using that information to return something similar to the nova min_version and max_versions - in the agent-list output. -- 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
Re: [openstack-dev] [neutron][devstack] Does the openvswitch-agent need to be run along side the neutron-l3-agent?
Armando M. wrote: > The short answer to your question in the question is yes. For OVS, wherever > you run network services (l3 or dhcp), you need an l2 agent that in charge > of port wiring. OK - I'm going senile then. For some reason I thought the L3 agent called the same code paths 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:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][devstack] Does the openvswitch-agent need to be run along side the neutron-l3-agent?
While reviewing https://review.openstack.org/#/c/292778/5 I think I might have found a bit of coupling between the neutron l2 agent and the l3 agent when it comes to DevStack. In the DevStack neutron guide - the "control node" currently does double duty as both an API server and also as a compute host. https://github.com/openstack-dev/devstack/blob/master/doc/source/guides/neutron.rst#devstack-configuration Extra compute nodes have a pretty short configuration https://github.com/openstack-dev/devstack/blob/master/doc/source/guides/neutron.rst#devstack-compute-configuration So, recently I poked at having a pure control node on the "devstack-1" host, by removing the q-agt and n-cpu entries from ENABLED_SERVICES, while leaving q-l3. It appears that the code in DevStack, relies on the presence of q-agt in order to create the integration bridge (br-int), so when the 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/ -- 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
Re: [openstack-dev] [Neutron] Getting project version from API
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.py#L59-L60 We should put some resources behind implementing micro versioning and we could end up with something similar. It would also 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...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [linuxbridge] Multiple VXLAN multicast groups
Kevin Benton wrote: > Just to be clear, it's not random. It follows a masking pattern so it is > possible to know which address a given VNI will use. And if you use a /8 > prefix the VNIs will have a straightforward 1:1 mapping to multicast > addresses. So, it sounds like 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:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [PTLs][all][mentoring] Mentors needed in specific technical areas
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?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic][neutron] bonding?
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) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][DevStack] Do we still need the neutron-debug command?
Assaf Muller wrote: > As far as I know Devstack is/was the only user. From my perspective, > I've never heard anyone using neutron-debug, reporting a bug against > it or asking any questions about it. I think it's reasonable to remove > it. OK - I pushed a patch that just 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/ -- 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
[openstack-dev] [Neutron][DevStack] Do we still need the neutron-debug command?
Ryan Moats and I chatted a week or so ago about neutron-debug in the context of DevStack. Ryan pushed a patch to see what it actually does[1]. Currently, it's not clear what it is used for, and in some instances it seems to be more trouble than it is really worth. Instead of going through 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 questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L2GW][Tricircle]Border Gateway support
joehuang wrote: > And one session[3] in Austin summit called for action in the community to > prioritize and accelerate Tricircle development. > > [1]https://review.openstack.org/#/c/270786/ > [2]https://review.openstack.org/#/c/304540/ > [3]https://www.openstack.org/videos/video/distributed-nfv-and-openstack-challenges-and-potential-solutions Having a summit session where you call on the community to do something for you is not going to get you very far. If this feature is important to you, you need to dedicate resources to get this done. You can't just sit back 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Neutron plugins that do not have L3 agents
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 __ 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][devstack] Third party CI breakage around Q_L3_ENABLED
Gary Kotton wrote: > Hi, > Actually the breakage is not sue to Q_L3_ENABLED. It is due to > https://review.openstack.org/#q,d894221457efa3a2a0bf3db76a4c5e8ffba36e29,n, > z > The Q_L3_ENABLED is something that each CI can configure depending on what > their supported mode is. > 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/1581519 -- 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
[openstack-dev] [neutron][devstack] Third party CI breakage around Q_L3_ENABLED
Hi, During the neutron refactor of DevStack, I made a conscious decision to take the Q_L3_ENABLED variable and change the default from False to True. Most DevStack installations will want to have L3 services enabled, so my thinking was, let's make it the default. That broke some people last week, since they were relying on Q_L3_ENABLED to be False for their CI systems. My thinking was, really we should just be checking if the q-l3 service is enabled or not. https://review.openstack.org/#/c/315995/ That, in turn ended up breaking other people in a different way. So, the networking-generic-switch people were fixed, and the networking-midonet people became broken. As Yamamoto notes: >Actually, Q_L3_ENABLED=True and is_service_enabled q-l3 have quite >different meaning. The former means the plugin provides L3 >functionalities. The latter means Neutron L3 agent is enabled. MidoNet >provides L3 functionalities without using Neutron L3 agent. https://review.openstack.org/#/c/316660/1 I think this shows that the status-quo in neutron-legacy was untenable. Neutron-legacy is extremely brittle and things are very tightly coupled, with the slightest mistake or oversight breaking people. I think it's time to start pushing people in the direction that I pushed the OVN project - although I wish that I had planned things better instead of breaking everyone and causing a scramble. For that, I apologize. My suggestion for anyone who is broken right now - 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/12e5bb646a4e0b43ef4c73bb627480a2dbb3e31c -- 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
Re: [openstack-dev] [nova][neutron] Is it still valid/supported to create a network with a br- id?
Matt Riedemann wrote: > The nova create-server API allows passing a network id that's prefixed with > br- [1]. That was added due to this bug from Folsom [2]. > > I'm wondering if that's still valid? Looking at the network.id data model in > Neutron it doesn't look like it would be [3]. Wow. That bug is awful. Network IDs should be UUIDs and ONLY UUIDs. Just because some vendor plugin decides that their going to break the Networking API contract and define their own ID scheme, doesn't mean that we should fix it to help them. That commit shouldn'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) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Ansible inventory - Would you need another inventory system for your openstack cloud and how would you like it to be?
Monty Taylor wrote: > On 05/09/2016 09:27 AM, Jean-Philippe Evrard wrote: > > Hello everyone, > > > > I am using ansible for some time now, and I think the current default > > Ansible inventory system is lacking a few features, at least when > > working on an OpenStack cloud - whether it's for its deployment, its > > support or its usage. > > I'm thinking of developing a new inventory, based on (openstack-)ansible > > experience. > > Before we talk about making a new OpenStack Inventory for ansible, let's > work on 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 __ 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][devstack] State of the refactor
More updates: https://review.openstack.org/#/q/status:open+project:openstack-dev/devstack+branch:master+topic:neutron-refactor Has the fixes for things I screwed up. Basically it looks like just the _configure_neutron_l3_agent got clobbered which could have broken people using neutron-legacy. 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 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][devstack] State of the refactor
I'm seeing some mistakes I made when moving over the contents of neutron-legacy that were l3 related into the new file. It didn't trigger any failures in the gate, but it might impact some developer machines or third party systems. I'm putting together patches, but also considering 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][devstack] State of the refactor
A quick update, https://review.openstack.org/168438 has landed. There is a lot of work that needs to be done, Armando and I spoke yesterday about some of the hooks that are present in neutron-legacy that both in-tree and out-of-tree consumers rely on being called. Doing a quick git grep - we have the following: * neutron_plugin_install_agent_packages * neutron_plugin_configure_dhcp_agent neutron_plugin_configure_l3_agent * neutron_plugin_configure_plugin_agent neutron_plugin_configure_service * neutron_plugin_setup_interface_driver * neutron_plugin_create_initial_networks I think that many of these entrypoints most likely need to be formalized in our plugin.sh[1] contract. Perhaps not exactly as they are today, but we do need a phase in the plugin contract where these kinds of things should exist. [1]: http://docs.openstack.org/developer/devstack/plugins.html#plugin-sh-contract -- 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
Re: [openstack-dev] [tc] supporting Go
Hayes, Graham wrote: > Sure - the Designate team could maintain 2 copies of our DNS server, > one in python as a reference, and one externally in Golang / C / C++ / > Rust / $language, which would in reality need to be used by anything > over a medium size deployment. > > That 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
Re: [openstack-dev] [neutron][devstack] State of the refactor
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.org/#/c/313049/ Good news everyone! I didn't break neutron-legacy! Hooray! -- 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
[openstack-dev] [neutron][devstack] State of the refactor
During the Austin summit, there was a discussion in the QA meetings about the future of Neutron's support in DevStack. It's been an ongoing effort, and I'd like to step back and give everyone a view of the Big Picture. https://etherpad.openstack.org/p/newton-qa-devstack-roadmap A year ago at the NYC QA midcycle, consensus was reached that in order to get Neutron to become the default deployment model for Devstack and finally deprecate Nova-Network, some grunt work would need to be done to clean up the DevStack code. Dean wrote about the experience in his blog: http://hackstack.org/x/blog/2015/03/30/qa-code-sprint >DevStack's Neutron code is in bad shape. It has been continually >updated by many people who do not understand the Big Picture. I blame >myself for not staying on top of this code and allowing it to diverge >from the rest of DevStack's style and implementation. Other Sean found >a number of inconsistencies in variable names and uses as he tried to >get the single interface work done and we came to the inevitable >conclusion that it was time to start over. So we did. https://review.openstack.org/168438 The new lib/neutron is an attempt to only have the *bare minimum* configured for either an OVS or Linux Bridge deployment of Neutron. My strategy was - start from scratch and build up enough Neutron configuration to get everything to launch, and have the network plumbed correctly. Everything else was left on the cutting room floor. There are still some things that I did for the sake of expediency, that I am sure will need to be improved in the future. However, the code is very close to completion - there's still some work that needs to be done, but I see the light at the end of the tunnel. For anything that isn't ML2 based, or the LB or OVS agent, Dean and I share this view: > But what about the plugins? What about the advanced services? What > about the vendors? I can't do it all at once. The first priority is to > get a 'minimum viable Neutron' configuration to use as the default. > The old code was renamed not removed, and exactly zero of the > configuration variables and service names have changed. Nothing should > be directly importing lib/neutron* so that change is handled in > DevStack and Grenade already. After we have working linuxbridge and > ovs configurations we can look at what else needs to be included. Sean Dague and I have also been kicking around some ideas about adding another hook to the DevStack plugin contract so that DevStack plugins that do network things have a chance to create networks and wire everything during installation and configuration, as part of a DevStack plugin call. The basic reasoning for this is, the current lib/neutron-legacy has tons of knobs for plugging veths into things, creating provider networks, etc.. - those things are very specific to a deployment or networking type, so they should be moved into a plugin so they don't gunk up the main code path and also avoid trampling one another (like they do today). The current lib/neutron weighs in around 500 lines of code, and the l3 setup code (which was the nastiest) is 300 lines, split out into a separate file. Partially to allow other plugins to call this code, and partially because of a divide-and-conquer strategy I am employing for the refactor. If you haven't read my post about eliminating the DevStack layer, this is also part of my thought process for the refactor, and how to support other configurations in DevStack. 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 __ 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][devstack] State of the refactor
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 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] [devstack][neutron] VMWare NSX CI - voting on devstack changes long after plugin decomposition
When the VMWare plugin was decomposed from the main Neutron tree
(https://review.openstack.org/#/c/160463/) it appears that the CI system was
left turned on.
http://208.91.1.172/logs/neutron/168438/48/423669-large-ops/logs/q-svc.log.2016-05-03-085740
2016-05-03 09:21:00.577 21706 ERROR neutron plugin_class =
self.load_class_for_provider(namespace, plugin_provider)
2016-05-03 09:21:00.577 21706 ERROR neutron File
"/opt/stack/neutron/neutron/manager.py", line 145, in load_class_for_provider
2016-05-03 09:21:00.577 21706 ERROR neutron raise ImportError(_("Plugin
'%s' not found.") % plugin_provider)
2016-05-03 09:21:00.577 21706 ERROR neutron ImportError: Plugin
'neutron.plugins.vmware.plugin.NsxPlugin' not found.
I don't know the criteria for when this specific CI job is run, I appear
to be the only one triggering 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 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] [all] [devstack] Adding example "local.conf" files for testing?
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. -- 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
Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
Vikram Choudhary wrote: > Hi Cathy, > > A project called "neutron-classifier [1]" is also there addressing the same > use case. Let's sync up and avoid work duplicity. > > [1] https://github.com/openstack/neutron-classifier Agree with Vikram - we have a small git repo that we're using to futz around with ideas around how to store classifiers in a way that is re-usable by other projects, and create a decent object model. It's very very rough, and the API is ... kind of ugly right now. That's what you get when I steal like 4 Red Bulls and do 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 __ 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] [devstack][neutron] Eliminating the DevStack layer
Armando M. wrote: > My understanding of the plan to overhaul the neutron (bloated) layer > present in DevStack being tackled in [1] has always been that this was > about trimming the layer rather than eliminating it altogether. Is this > email a reflection of a desire to change direction? If so, SeanC please > clarify because I am slightly confused. As part of the DevStack refactor, I am trying to shrink the amount of DevStack configuration variables that are carried around for Neutron. That is the part I am trying to eliminate. There must be support for Neutron in DevStack, if we ever wish to become the default networking project in OpenStack and successfully deprecate nova-network. > To the very minimum we'd need to find the right blend of config variables > which (in conjunction with some other *optional* local.conf extra juice) > produce the Neutron configuration files that we have in the gate, namely > OVS, LB and OVS+DVR, with their multi-node variants, and thus allow us to > get happy pass with Grenade/Tempest (if that means skipping some tests so > be it) across all the branches we currently gate against. The rest of the > layer can be stripped to the bare bone, but without it we're basically > gonna have to deal with long local.conf files with entire chunks of agent > files etc. thus making Neutron support for repos like devstack-gate and > project-config rather more painful (I am assuming we're gonna have to use > the new layer/approach at some point?). Bear in mind that the complexity > bubble needs to move/split, it's not just gonna burst and vanish :) It is my hope that we can start looking at some of these configurations, take a look at what puppet or ansible set, and realize that a lot of these options could just be defaults instead of making it the job of deployment tools to explicitly configure. > On another note, we'd have to keep in mind neutron_plugins that currently > have a place in the devstack tree and/or that rely on the existing > neutron_legacy bits. What's the plan for those (e.g. networking-[ovn, odl, > ...] et al)? Finally, what's the plan for switching in the gate? I think neutron_plugins will eventually be removed. Third party plugins like ovn, odl, et al most likely have DevStack plugins that supersede the code in neutron_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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack][neutron] Eliminating the DevStack layer
Assaf Muller wrote: > I do want to say that ML2's "mechanism_drivers" option probably does > not have a default for the same reason we do not have a default for > the core_plugin value, we don't want to play favorites. From Neutron's > point of view, ignoring the existence of Devstack and upstream CI, I > think that makes sense. > True, I do see your point. I do however think, that if you do pick the ML2 plugin as your core_plugin, it should have some mechanism drivers enabled by default. You shouldn't have to pick core_plugin, then be forced 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 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] [devstack][neutron] Eliminating the DevStack layer
Edgar Magana wrote: > This is a very solid plan. Maybe to fair on the current state of the devstack > with neutron functionality, what will be the disadvantage(s) of this change > from your perspective? > A user's local.conf will probably get a little bigger - and I think a lot of the issues about Neutron's inability to run out of the box will be exposed. I mean let's face it - Neutron, installed from source, with no configuration Does Not Work™. There are not enough settings that have defaults set, for it to actually run. This was made painfully obvious to me when I had to make new revisions to the Neutron DevStack refactor, where I had to add more inisets, in order for Neutron to finish stacking correctly. Did you know, for example, that we rely on DevStack[1] to set the list of mechanism_drivers? Without this, you'll get an empty mechanism_driver list and nothing will ever be wired up. I'm sure there is an argument that can be made about why there is no default for mechanism_drivers in ML2, since there are lots of options. But, I think that we can at least enable the ones that we have in Neutron's main tree. Packagers who make packages for each mechanism driver (LB, OVS, etc..) already had to handle things like mechanism_drivers in the Ml2 configuration already, so it shouldn't really impact them since we're only setting a default if nothing is set, and their packages should explicitly set it. [1]: https://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:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [devstack][neutron] Eliminating the DevStack layer
Prior to the introduction of local.conf, the only way to configure OpenStack components was to introduce code directly into DevStack, so that DevStack would pick it up then inject it into the configuration file. This was because DevStack writes out new configuration files on each run, so it wasn't possible for you to make changes to any configuration file (nova.conf, neutron.conf, ml2_plugin.ini, etc..). So, someone who wanted to set the Linux Bridge Agent's physical_interface_mappings setting for Neutron would have to use $LB_INTERFACE_MAPPINGS in DevStack, which would then be invoked by DevStack[1]. The local.conf functionality was introduced quite a while back, and I think it's time to have a conversation about why we should start moving away from the previous practice of declaring variables in DevStack, and then having them injected into the configuration files. The biggest issue is: There is a disconnect between the developers using DevStack and someone who is an operator or who has been editing OpenStack conf files directly. So, for example I can tell you all about how DevStack has a bunch of variables for configuring Neutron (which is Not a Good Thing™), and how those go into DevStack and then end up coming out the other side in a Neutron configuration file. Really, I would like to get rid of the intermediate layer (DevStack) and get both Devs and Deployers to be able to just say: Here's my neutron.conf - let's diff mine and yours and see what we need to sync. Matt Kassawara and I have had this issue, since he's coming from the OSAD side, and I'm coming from the DevStack side. We both know what the Neutron configuration should end up as, but DevStack having its own set of variables and how those variables are handled and eventually rendered as a Neutron config file makes things more difficult than it needs to be, since Matt has to now go and learn about how DevStack handles all these Neutron specific variables. The Neutron refactor[2] that I am working on, I am trying to configure as little as possible in DevStack. Neutron should be able to, out of the box, Just Work™. If it can't, then that needs to be fixed in Neutron. Secondly, the Neutron refactor will be getting rid of all the things like $LB_INTERFACE_MAPPINGS - I would *much* prefer that someone using DevStack actually set the apropriate line in their local.conf Such as: [[post-config|/$Q_PLUGIN_CONF_FILE]] [linux_bridge] physical_interface_mappings = foo:bar The advantage of this is, when someone is working with DevStack, the things they are configuring are the same as all the other OpenStack documentation. For example, someone could read the Networking Guide, read the example configuration[3] and the only thing they'd need to learn is our syntax for specifying what file the contents go in (the "[[post-config|/$Q_PLUGIN_CONF_FILE]]" piece). Thoughts? [1]: https://github.com/openstack-dev/devstack/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 __ 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] Newton blueprints call for action
Armando M. wrote: > I would like to understand if these need new owners (both assignees and > approvers). Code submitted [5,6] has not been touched in a while, and > whilst I appreciate people have been busy focussing on Mitaka (myself > included), the Newton master branch has been open for a while. > > With this email I would like to appeal to the people in CC to report back > their interest in continuing working on these items in their respective > capacities, and/or the wider community, in case new owners need to be > identified. My involvement in the FwaaS project has been reduced significantly over the past couple of months, and I think because of this, someone should probably step in and replace me. I would like to apologize for my failure, because I advocated publicly for using the FwaaS API as the vehicle for more granular and more advanced 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 __ 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] OVSDB native interface as default in gate jobs
Russell Bryant wrote: > because they are related to two different command line utilities > (ovs-vsctl vs ovs-ofctl) that speak two different protocols (OVSDB vs > OpenFlow) that talk to two different daemons on the system (ovsdb-server vs > ovs-vswitchd) ? True, they influence two different daemons - but it's really two options that both have two settings: * "talk to it via the CLI tool" * "talk to it via a native interface" How likely is it to have one talking via native interface and the other via CLI? Also, if the native interface is faster, I 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.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] OVSDB native interface as default in gate jobs
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. 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
Re: [openstack-dev] [neutron]: Neutron naming legal issues
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.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][novaclient] host-evacuate-live command is broken in 3.3.0
Hi, 3.3.0 of python-novaclient has a serious bug, which prevents host-evacuate-live from working correctly. https://github.com/openstack/python-novaclient/commit/ae598280acc46dd4ee20af78a5780a450f96b084 appears to have changed a number of function signatures and arguments, and resulted 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 __ 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] [new-project][gate] devstack-plugin-additional-pkg-repos
Tony Breeds wrote: > Longer term TODO list: > 1) find a home in the big tent > 2) test all the things > 3) Use this for Neutron to test OVS > - Is there and existing package repo we can test on trusty? Fantastic work Tony, thank you for doing this. I look forward to seeing 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...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] report from Brno code sprint, Mar 14-16
Ihar Hrachyshka wrote: > + to that. There is some general info on upgrade planning at: > > http://docs.openstack.org/openstack-ops/content/ch_ops_upgrades.html > > We probably want to expand it with service specific details. Agreed. However take note that URL is the product of 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 __ 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] CI jobs take pretty long, can we improve that?
Rossella Sblendido wrote: > 2) multi-node jobs run for every patch set. Is that really what we want? > They take pretty long. We could move them to a periodic job. I would rather remove all the single-node jobs. Nova has been moving to multinode jobs for their gate (if I recall correctly my conversation with Dan Smith) and we should be moving in this direction too. We should test Neutron the way it is deployed in production. Also, who is really monitoring the periodic jobs? Truthfully? I know there are some IPv6 jobs that are periodic and I'll be the first to admit that I am not following them *at all*. So, my thinking is, unless it's running at the gate and inflicting pain on people, it's not going to be a treated as a priority. Look at Linux Bridge - serious race conditions that existed for years only got fixed once I inflicted pain on all the Neutron devs by 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?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] report from Brno code sprint, Mar 14-16
Ihar Hrachyshka wrote: > > One thing that we discussed on the event is updating networking-guide with > detailed description of the upgrade process for neutron. We already have > some pieces scattered there [f.e. we have some coverage for > neutron-db-manage tool] but it’s nothing 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/291785 -- 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
Re: [openstack-dev] [Neutron] Ihar as *-aas core reviewer
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 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] - Changing the Neutron default security group rules
Mathieu Gagné wrote: > We had issue with GRE but unrelated to the one mentioned above. > > Although security group is configured to allow GRE, > nf_conntrack_proto_gre module is not loaded by iptables/Neutron and > traffic is dropped. We had to load the module manually. > 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.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] - Changing the Neutron default security group rules
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. Thanks Sri! -- 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
Re: [openstack-dev] [neutron] - Changing the Neutron default security group rules
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 directly on their > > > instances. > > > > This one really rubs me the wrong way. Can we please get a better > > description of the bug - instead of someone just saying that Neutron > > doesn't work, therefore we don't want any filtering or security for our > > instances using an API? > > Sure. There are two ways this manifests. The first is that there have > been bugs in security groups where traffic is passed despite being told > not to pass that traffic. This has been treated as a bug in the past and > corrected which is great so this particular instance of the issue is > less worrysome. So as Kevin stated, there does not appear to be any known bugs where traffic is passed despite being disallowed. If this were the case, I assure you, this would be treated as a serious issue and fixed quickly. If you are experiencing this issue, please open a bug and help us address it. We can't make serious policy decisions based on rumors and hearsay about how Neutron doesn't work correctly. > The second is that I will explicitly tell neutron to > pass traffic but for whatever reason that traffic ends up being blocked > anyways. One concrete example of this is the infra team has had to stop > using GRE because at least two of our clouds do not pass GRE traffic > despite having explicit "pass all ipv4 and all ipv6 between all possible > addresses rules". Are we certain that Neutron is the culprit? If so, please, open a bug and help us track this down. -- 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
Re: [openstack-dev] [neutron] - Changing the Neutron default security group rules
Jeremy Stanley wrote: > On 2016-03-03 07:49:03 +1300 (+1300), Xav Paice wrote: > [...] > > In my mind, the default security group is there so that as people > > are developing their security policy they can at least start with > > a default that offers a small amount of protection. > > Well, not a small amount of protection. The instances boot > completely unreachable from the global Internet, so this is pretty > significant protection if you consider the most secure system is one > which isn't connected to anything. This is only if you are booting 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 __ 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] - Changing the Neutron default security group rules
Mike Spreitzer wrote: > Could we at least make it less difficult to figure out which security > group is attached to a Nova instance? Right now `nova show` says only > that the security group is named "default" and guess what --- they are > *all* named default! An admin looking at this is lost. Meaning your users are creating new security groups and naming them "default" - so you have the "default" default (heh) and then the one that they created named default? Are security group names in Nova-Net unqiue? I seem to recall that being a difference 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] - Changing the Neutron default security group rules
Kevin Benton wrote: > * Instances without ingress are useless so a bunch of API calls are > required to make them useful. This is not true in all cases. There are plenty of workloads that only require outbound connectivity. Workloads where data is fetched, computed, then transmitted elsewhere for storage. > * It violates the end-to-end principle of the Internet to have a middle-box > meddling with traffic (the compute node in this case). Again, this is someone's *opinion* - but it is not an opinion universally shared. > * Neutron cannot be trusted to do what it says it's doing with the security > groups API so users want to orchestrate firewalls directly on their > instances. This one really rubs me the wrong way. Can we please get a better description of the bug - instead of someone just saying that Neutron doesn't work, therefore we don't want any filtering or security for our instances using an API? > Second, would it be acceptable to make this operator configurable? This > would mean users could receive different default filtering as they moved > between clouds. It is my belief that an application that is going to be run in a cloud environment, it is not enough to just upload your disk image and expect that to be the only thing that is needed to run an app in the cloud. You will also need to bring your security policy into the cloud as well - Who can access? How can they access? Which parts of the app can talk to sensitive parts of the app like the database servers? I think that the default security group should be left as is - and users should be trained that they should bring/create security groups with the appropriate rules for their need. If infra wants to opt out of the security group API and allow 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 __ 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] [devstack] stack.sh keeps failing with RTNETLINK answers: Network is unreachable
Paul Carlton wrote: > Sean > > Don't think unstack failed, when I manually create the device ( sudo > ovs-vsctl --no-wait -- --may-exist add-br br-ex) unstack.sh removes it. > > sudo ip route show > default via 172.18.20.1 dev eth0 > 169.254.169.254 via 172.18.20.2 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 __ 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] [devstack] stack.sh keeps failing with RTNETLINK answers: Network is unreachable
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 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] [nova][neutron][upgrade] Grenade multinode partial upgrade - Nova metadata failure
Ihar Hrachyshka wrote: > I guess the next steps are: > - monitoring the job for a week, making sure it’s stable enough (comparing > failure rate to non-partial grenade job?); > - if everything goes fine, propose project-config change to make it voting; > - propose governance patch to enable rolling-upgrade tag for neutron repo (I > believe not for *aas repos though?). Agree - I believe this is our next steps. > I guess with that we would be able to claim victory for the basic 'server > vs. agent’ part of rolling scenario. Right? Correct - it also tests "new agent vs. old agent" since the primary node runs the neutron agent, upgrades it, while the subnode runs the neutron agent that is not upgraded. I think there could be some work done to ensure that instances are scheduled on both the primary node and the subnode so we get more coverage. > Follow up steps would probably be: > - look at enabling partial job for DVR flavour; Agree - I guess we can resurrect https://review.openstack.org/#/c/250215 ? > - proceed on objectification of neutron db layer to open doors for later > mixed server versions in the same cluster. Sounds good. > Anything I missed? I think that's a good starting point. If we think of of other things we can add them. > Also, what do we do with non-partial flavour of the job? Is it staying? Is it useful? I think operators are more likely to upgrade components of a cluster incrementally - 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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade - Nova metadata failure
Armando M. wrote: > Now that the blocking issue has been identified, I filed project-config > change [1] to enable us to test the Neutron Grenade multinode more > thoroughly. > > [1] https://review.openstack.org/#/c/282428/ Indeed - I want to profusely thank everyone that 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron] Update on os-vif progress (port binding negotiation)
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. -- 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
Re: [openstack-dev] [all] [tc] "No Open Core" in 2016
Doug Hellmann wrote: > Is there? I thought the point was OpenCDN isn't actually usable. Maybe > someone from the Poppy team can provide more details about that. That is certainly a problem. However I think I would lean on Sean Dague's argument about how Neutron had an open source solution that needed a lot of TLC. The point being that at least they had 1 option. Not zero options. And Dean's point about gce and aws API translation into OpenStack Compute is also very relevant. We have precedence for doing API translation layers that take some foreign API and translate it into "openstackanese" I think Poppy would have a lot easier time getting into OpenStack were it to take the steps to build a back-end that would do the required operations to create a CDN - using a multi-region OpenStack cloud. Or even adopting an open source CDN. Something! Anything really! 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 __ 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] [all] [tc] "No Open Core" in 2016
Thomas Goirand wrote: > s/I dislike/is not free software/ [*] > > It's not a mater of taste. Having Poppy requiring a non-free component, > even indirectly (ie: the Oracle JVM that CassandraDB needs), makes it > non-free. Your definition of non-free versus free, if I am not mistaken, is based on GPLv3. OpenStack is not GPL licensed I understand and respect the point of view of the Debian project on this, however OpenStack is an Apache licensed project. So, this is entirely your bikeshed. > Ensuring we really only accept free software is not a bikeshed color > discussion, it is really important. And that's the same topic as using > non-free CDN solution (see below). It is a bikeshed, because you are injecting a debate over the freedoms of Apache license vs. GPLv3 into this discussion. Which you do, on many occasions. I respect this, but at some 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.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] "No Open Core" in 2016
Thomas Goirand wrote: > Oh, that, and ... not using CassandraDB. And yes, this thread is a good > place to have this topic. I'm not sure who replied to me this thread > wasn't the place to discuss it: I respectfully disagree, since it's > another major blocker, IMO as important, if not more, as using a free > software CDN solution. Let's handle the policy implications discussed in this thread before we dive into the "don't use this component that I dislike" bikeshed. Reading the thread, it appears that we've made good progress on building consensus towards having Poppy consider an open source CDN as the "reference implementation" (to use some Neutron parlance). Then we can bikeshed about how good/bad the components used in the reference implementation are. Later. The point being, there is an open source solution 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) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Postgres support in (fwaas) tests
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) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Multiple delete of network through CLI is not available as of now
Welcome! Please check out Neutron's developer docs, specifically how we handle new features or work, to get started. http://docs.openstack.org/developer/neutron/policies/blueprints.html Please also check out our onboarding docs. http://docs.openstack.org/developer/neutron/policies/contributor-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...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade
Ihar Hrachyshka wrote: > UPD: seems like enforcing instance mtu to 1400 indeed makes us pass forward > into tempest: > > http://logs.openstack.org/59/265759/3/experimental/gate-grenade-dsvm-neutron-multinode/a167a59/console.html > > And there are only three failures there: > > http://logs.openstack.org/59/265759/3/experimental/gate-grenade-dsvm-neutron-multinode/a167a59/console.html#_2016-01-11_11_58_47_945 > > I also don’t see any RPC versioning related traces in service logs, which is > a good sign. > Just an update - we are still stuck on those three tempest tests. I was able to dig a bit and it looks like it's still an MTU issue. http://logs.openstack.org/35/187235/14/experimental/gate-grenade-dsvm-neutron-multinode/c5eda62/logs/tempest.txt.gz#_2016-02-09_20_37_40_044 "SSHException: Error reading SSH protocol banner[Errno 104] 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-Am) has already made note of in his research. -- 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
Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade
Ihar Hrachyshka wrote: > Actually, we already have 1450 for network_device_mtu for the job since: > > https://review.openstack.org/#/c/267847/4/devstack-vm-gate.sh > Ah! Forgot about that one. Cool. > Also, I added some interface state dump for worlddump, and here is how the > main node networking setup looks like: > > http://logs.openstack.org/59/265759/20/experimental/gate-grenade-dsvm-neutron-multinode/d64a6e6/logs/worlddump-2016-01-30-164508.txt.gz > > br-ex: mtu = 1450 > inside router: qg mtu = 1450, qr = 1450 > > So should be fine in this regard. I also set devstack locally enforcing > network_device_mtu, and it seems to pass packets of 1450 size through. So > it’s probably something tunneling packets to the subnode that fails for us, > not local router-to-tap bits. Yeah! That's right. So is it the case that we need to do 1500 less the GRE overhead less the VXLAN overhead? So 1446? Since the traffic gets enacpsulated in VXLAN then encapsulated in GRE (yo dawg, I heard u like tunneling). http://baturin.org/tools/encapcalc/ > > I also see br-tun having 1500. Is it a problem? Probably not, but I admit I > 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 __ 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] [Neutron] [FwaaS] Meeting occurred early today by accident
Hi, I accidentally ran the meeting early, due to not having re-downloaded a fresh iCal export. So I had the wrong time. For background: https://github.com/openstack-infra/yaml2ical/commit/4def663a8d5259962d5c2239266ebfaa19082bf6 So anyway, please ensure that your calendar is updated 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 questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] - please review the neutron security guide
Kevin Benton wrote: > Hello all, > > This was briefly mentioned in the "What's up doc?" thread[1], but I wanted > to highlight it with the neutron tag to get some more eyes on it. The > security guide for Neutron has been around for a while and the security > team would like to know if everything is still up to date and relevant. > > The guide is here: http://docs.openstack.org/security-guide/networking.html > > If you see any issues, either propose a patch directly or file a bug > against https://bugs.launchpad.net/openstack-manuals/+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) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Being more aggressive with our defaults
Hi, With the path_mtu issue - our default was to set path_mtu to zero, and do no calculation against the physical segment MTU and the overhead for the tunneling protocol that was selected for a tenant network. Which means the network would break. I am working on patches to change our behavior to set the MTU to 1500 by default[1], so that at least our out of the box experience is more sensible. This brings me to the csum feature of recent linux kernel versions and related network components. Patches: https://review.openstack.org/#/c/220744/ https://review.openstack.org/#/c/261409/ Bugs/RFEs: https://bugs.launchpad.net/neutron/+bug/1515069 https://bugs.launchpad.net/neutron/+bug/1492111 Basically, we see that enabling the csum feature creates the conditions where 10gig link were able to be fully utilized[2] in one instance[3]. My thinking is - yes I too would like to fully utilize the links that I paid good money for. Someone with more knowledge can correct me , but is there any reason not to enable this feature? If your hardware supports it, we should utilize it. If your hardware doesn't support it, then we shouldn't. tl;dr - why do we keep merging features that create more knobs that deployers and deployment tools need to keep turning? The fact that we merge features that are disabled by default means that they are not as thoroughly tested as features that are enabled by default. Neutron should have a lot of things enabled by default that improve performance (l2pop? path_mtu? dvr?), and by itself, try and enable these features. If for some reason the hardware doesn't support it, log that it wasn't successful and then disable. OK - that's it for me. Thanks for reading. I'll put on my asbestos undies now. [1]: https://review.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 questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM
Salvatore Orlando wrote: > Agreed. Operators love to automate things, but they generally don't like > when components automatically do things they maybe do not expect to do (I > don't think we should assume all operators fully read release notes). So > the manual step is preferable, and not that painful after all. From an > historical perspective, a manual switch was the same approach adopted for > migration from OVS/LB plugins to ML2. Honestly the migration from OVS/LB was not very well done. https://bugs.launchpad.net/neutron/+bug/1424378 https://bugs.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 __ 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] Evolving the stadium concept
On Thu, Feb 04, 2016 at 04:20:50AM EST, Assaf Muller wrote: > I understand you see 'Dragonflow being part of the Neutron stadium' > and 'Dragonflow having high visibility' as tied together. I'm curious, > from a practical perspective, how does being a part of the stadium > give Dragonflow visibility? If it were not a part of the stadium and > you had your own PTL etc, what specifically would change so that > Dragonflow would be less visible. > Currently I don't understand why > being a part of the stadium is good or bad for a networking project, > or why does it matter. I think the issue is of public perception. As others have stated, the issue is the "in" vs. "out" problem. We had a similar situation with 3rd party CI, where we had a list of drivers that were "nice" and had CI running vs drivers that were "naughty" 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 have been the intention, but that's what I think happened. -- 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
Re: [openstack-dev] Any chances to backport port_security_enabled support into Heat for Kilo 2015.1.3?
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 for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
