Re: [openstack-dev] [kuryr] Spec and devref placement
+1 on b) too. On 12 September 2016 at 13:38, Antoni Segura Puimedon wrote: > Hi Kuryrs! > > On September 5th's weekly IRC meeting Irena Berezovsky suggested that > we should take a decision regarding the location of specs and devrefs. > > Currently we default to putting all the specs and devrefs for: > - Kuryr > - Kuryr-libnetwork > - Kuryr-kubernetes > > to openstack/kuryr. Fuxi is still being integrated and keeps its own doc. > > The three proposals that came up where: > a) All specs and devrefs to openstack/kuryr > b) Specs in openstack/kuryr but devrefs in each specific project, > i.e., the one that will end up with the implementation code. > c) Both specs and devrefs in each separate Kuryr project. > > I would like to advocate for option (b). It makes things easy for when > specs involve multiple kuryr pieces and, at the same time, it keeps > development information in the place where you'd expect, close to the > code. > > Please, weigh on this issue here in the ML or in the weekly IRC > meeting today. The idea is to reach a decision by next week's weekly > IRC meeting and then write it in each subproject's "how to contribute" > > See you later in the weekly IRC, > > Toni > > __ > 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 > -- Jaume Devesa Software Engineer at Midokura __ 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] [kuryr] Python 3 usage and kuryr-kubernetes
Hi Toni, I am +1 on a). Kuryr-kubernetes is an asynchronous service. We are not talking about some binary/unicode mismatch or list/generators return type that can be solved with 'six' library or some 'utils' module. If we go to python2 that will force us to re-do all the core part of the project when we'll move to python3. Is there a policy that prevents to run some services on python2 and some on python3 in distros? What's the reason behind? Regards, Jaume Devesa Software Engineer @ Midokura  On Aug 30 2016, at 4:44 pm, Antoni Segura Puimedon wrote: > Hi fellow kuryrs! > > This email is gonna be a bit long, so I'll put it in parts. > > Kubernetes integration components == > > > > As you know, we are now in the process of upstreaming the Kuryr Kubernetes PoC that the Kuryr team at Midokura did. This PoC upstreaming effort has two main parts: Kuryr watcher: Based on Python3 asyncio, it connects to the ?watch=true Kubernetes resource endpoints, then passes the seen events to translators that end up calling Neutron. With the Neutron resource information returned by the translators, the watching coroutines update the resource that originated the event. > > Kuryr CNI: Py2 and Py3 compatible. It is called by Kubernetes' Kubelet with the noop container so that the CNI driver does the network plumbing for it. Basically we use openstack/kuryr binding code to bind Pod veths to Neutron ports. > > Upstream Deployment design == > > > > In the Kuryr-Kubernetes integration vision, Kuryr CNI is installed wherever Kubelet is and the Kuryr watcher (or watchers once we support HA) runs in a container somewhere that can access the Kubernetes, Neutron and Keystone APIs (which does not need to be able to access the watcher host on anything else that established connections). The idea behind allowing it to be in a non- privileged container somewhere is that in this way you do not need to make Neutron/Keystone accessible from the Kubernetes worker nodes, just like for a lot of Nova compute deployments (obviously, depending on you networking vendor, you have rabbitmq agent access to Neutron). If one does not need the extra isolation for the Kuryr Watcher, the Watcher containers could even be started by Kubernetes and the CNI driver would just let the watcher container in the Host networking instead of on the Overlay, so Kubernetes would manage the integration deployment. > > OpenStack distributions: when the rubber meets the road == > > > > If the OpenStack distros, however, would prefer not to run Kuryr Watcher containerized or they want to, as they probably should, build their own container (rather than the upstream kuryr/kubernetes one in dockerhub that is based on alpine linux), they would need to have Python3.5 support. I understand that at the moment from the most popular OpenStack distros, only one has Python 3.5 supported. > > You can imagine where this is heading... These are the options that I can see: > > a) Work with the OpenStack distributions to ensure python3.5 support is reached soon for Kuryr and its dependencies (some listed below): > > * babel > * oslo.concurrency > * oslo.config > * oslo.log > * oslo.utils > * pbr > * pyroute2 > * python-neutronclient > * python-keystoneclient > > This also implies that distros should adopt a policy about having OpenStack services running in Python2, some in Python3, as I think the best is to have each project move at its own speed (within reason). > > b) As Ilya Chukhnakov from Mirantis proposed, drop Python3 for now and reimplement it with python-requests and eventlet. He'll work on a PoC to see its feasibility and how it compares to the asyncio based one. > > Personal position = > > I see this as a good opportunity for the OpenStack community at wide to start having Python3-first (and even python3 only) services and allow OpenStack projects to take full advantage of all the good things Python3 has to offer and move forward with the rest of the Python community. > > There's been some efforts in the part in some projects [1][2] but it seems implementation was deferred indefinitely probably to the same distribution issue that we face now. > > > > In light of the recent discussions in this mailing list and the decision taken by the Technical Committee [3] about alternative languages. I think it would be very good for the community to set an official plan and incentivize the
[openstack-dev] [kuryr][magnum]Installing kuryr for mutlinode openstack setup
Hello Akshay, responses inline: On Wed, 25 May 2016 10:48, Akshay Kumar Sanghai wrote: > Hi, > I have a 4 node openstack setup (1 controller, 1 network, 2 compute nodes). > I want to install kuryr in liberty version. I cannot find a package in > ubuntu repo. There is not yet official version of Kuryr. You'll need to install using the current master branch of the repo[1] (by cloning it, install dependencies and `python setup.py install` > -How do i install kuryr? If the README.rst file of the repository is not enough for you in terms of installation and configuration, please let us know what's not clear. > - what are the components that need to be installed on the respective > nodes? You need to run the kuryr libnetwork's service in all the nodes that you use as docker 'workers' > - Do i need to install magnum for docker swarm? Not familiar with Magnum.. Can not help you here. > - Can i use docker swarm, kubernetes, mesos in openstack without using > kuryr? What will be the disadvantages? Only docker swarm right now. The kubernetes one will be addressed soon. > > Thanks > Akshay > __ > 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 There are a bunch of people much more experienced than me in Kuryr. I hope I haven't said anything stupid. Best regards, [1]: http://github.com/openstack/kuryr -- Jaume Devesa Software Engineer at Midokura PGP key: 35C2D6B2 @ keyserver.ubuntu.com signature.asc Description: PGP signature __ 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] [tripleo] enabling third party CI
This is something I would love to enable as well. One of the requirements we have with Midonet is to be able to parametrize the image build, since we need to add extra packages on it. For the deployment options, I also think that it should not be hard either. If you want to discuss it in any TripleO meeting, let me know. Count on us, Emilien. On Thu, 10 Mar 2016 09:50, Emilien Macchi wrote: > Something I like in TripleO is third party drivers enablement, thanks to > the plug-able interface in Puppet modules & Heat Templates. > Though I don't see any testing regarding these drivers, it sounds like we > add a lot of parameters and Puppet code that is supposed to deploy the > drivers, but we never verify it actually works. > > OpenStack Infra provides an easy way to plug CI systems and some CIs (Nova, > Neutron, Cinder, etc) already gate on some third party systems. > I was wondering if we would not be interested to investigate this area and > maybe ask to our third party drivers contributors (Bigswitch, Nuage, > Midonet, Cisco, Netapp, etc) to run on their own hardware TripleO CI jobs > running their specific environment to enable the drivers. > This CI would be plugged to TripleO CI, and would provide awesome feedback. > > We need to know from these vendors if they are interested in such a thing, > which could improve the quality of TripleO, something we both want. > If they agree, we could help them to setup this environment (we already > have the framework, I don't think it would require a lot of work). > > I see an opportunity to involve our vendors in the quality of TripleO, and > eventually increase the number of contributors by this result. > > Any feedback is welcome here. > -- > Emilien Macchi > __ > 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 -- Jaume Devesa Software Engineer at Midokura __ 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] [Kuryr] IRC Meeting - Tuesday (1/26) 0300 UTC (#openstack-meeting-4)
Hi Gal, I missed the mail and the meeting... I imported the ics file[1] from eavesdrop site before Christmas and since January it seems the schedule and the reality are switched. Can it be that the calendar has to be updated, or it is because I am completely unable to deal with organization tools? Regards, [1]: http://eavesdrop.openstack.org/calendars/kuryr-team-meeting.ics On Mon, 25 Jan 2016 13:51, Gal Sagie wrote: > Hello All, > > We are going to have an IRC meeting tomorrow. > > I have updated the agenda for the upcoming meeting [1] > Please review and add any additional topics you might want to cover. > > Last meeting action items can be seen here [2] > > Thanks and see you there! > > [1] https://wiki.openstack.org/wiki/Meetings/Kuryr > [2] > *http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-01-18-15.02.html > <http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-01-18-15.02.html>* > __ > 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 -- Jaume Devesa Software Engineer at Midokura __ 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] How to make deb and rpm packages for a networking-* project?
Hi, To create a deb, you can look at the debian repositories as example: http://anonscm.debian.org/cgit/openstack?q=networking For rpm, there is the Red Hat maintained `openstack-packages` organization in GitHub: https://github.com/openstack-packages/?utf8=%E2%9C%93&query=networking Take a look as well at the delorean documentation if you want your package to be part of the RDO repos: https://www.rdoproject.org/packaging/rdo-packaging.html Best regards, On 22 December 2015 at 07:22, Fawad Khaliq wrote: > There is one example [1] in review and may be incomplete but might help. > It only adds the scripts to build. Publishing part is different. > > [1] https://review.openstack.org/#/c/248239/ > > Fawad Khaliq > > > On Tue, Dec 22, 2015 at 11:15 AM, P. Ramanjaneya Reddy < > ramanji...@gmail.com> wrote: > >> >> Hi All, >> >> Can someone help on.. >> How to make rpm and deb packages for a networking-* project? >> >> Thanks & Regards, >> Ramanji. >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Jaume Devesa Software Engineer at Midokura __ 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] [tripleo] Pin some puppet dependencies on git clone
My bet is first solve the problem, and then discuss how to improve the solution. Specifying the DIB_REPOREF variables by hand on the puppet-module element in t-p-e will be an immediate improvement in stability terms. Then, it is fair to discuss how to automate the process to syncrhonise with puppet-openstack dependencies. Regards, On 16 December 2015 at 16:40, Jiří Stránský wrote: > On 15.12.2015 19:12, Emilien Macchi wrote: > >> >> >> On 12/15/2015 12:23 PM, Jiří Stránský wrote: >> >>> On 15.12.2015 17:46, Emilien Macchi wrote: >>> >>>> For information, Puppet OpenStack CI is consistent for unit & functional >>>> tests, we use a single (versionned) Puppetfile: >>>> >>>> https://github.com/openstack/puppet-openstack-integration/blob/master/Puppetfile >>>> >>>> >>>> TripleO folks might want to have a look at this to follow the >>>> dependencies actually supported by upstream OR if you prefer surfing on >>>> the edge and risk to break CI every morning. >>>> >>>> Let me know if you're interested to support that in TripleO Puppet >>>> elements, I can help with that. >>>> >>> >>> Syncing tripleo-puppet-elements with puppet-openstack-integration is a >>> good idea i think, to prevent breakages like the puppet-mysql one >>> mentioned before. >>> >>> One thing to keep in mind is that the module sets in t-p-e and p-o-i are >>> not the same. E.g. recently we added the timezone module to t-p-e, and >>> it's not in the p-o-i Puppetfile. >>> >>> Also, sometimes we do have to go to non-openstack puppet modules to fix >>> things for TripleO (i don't recall a particular example but i think we >>> did a couple of fixes in non-openstack modules to allow us to deploy HA >>> with Pacemaker). In cases like this it would be helpful if we still had >>> the possibility to pin to something different than what's in >>> puppet-openstack-integration perhaps. >>> >>> >>> Considering the above, if we could figure out a way to have t-p-e behave >>> like this: >>> >>> * install the module set listed in t-p-e, not p-o-i. >>> >>> * if there's a ref/branch specified directly in t-p-e, use that >>> >>> * if t-p-e doesn't have a ref/branch specified, use ref/branch from p-o-i >>> >>> * if t-p-e doesn't have a ref/branch specified, and the module is not >>> present in p-o-i, use master >>> >>> * still honor DIB_REPOREF_* variables to pin individual puppet modules >>> to whatever wanted at time of building the image -- very useful for >>> temporary workarounds done either manually or in tripleo.sh. >>> >>> ...then i think this would be very useful. Not sure at the moment what >>> would be the best way to meet these points though, these are just some >>> immediate thoughts on the matter. >>> >> >> I think we shout not use puppet-openstack-integration per-se, it was >> just an example. >> >> Though we can take this project as reference to build a tool that >> prepare Puppet modules in TripleO CI. >> >> If you look at puppet-openstack-integration, we have some scripts that >> allow or not to use zuul-cloner with r10k, that's nice because it allows >> us to: >> * use depends-on puppet patches >> * if the end-user does not have zuul, it will git-clone, in tripleo case >> I think if DIB_REPOREF_* is set, let's use it >> * otherwise use git clone master. >> >> I would suggest also TripleO CI having a Puppetfile that would be gated >> (maybe in tripleo-ci repo?). >> > > We should probably put the pins somewhere else than tripleo-ci, because > we'd want dev environments to use the pinned versions too. Perhaps t-p-e is > the right place. > > The more i think about this the more i like the approach in Dan's patch -- > an extra element which will pin modules the DIB way. What we're lacking > here is a tool which could take a Puppetfile (specifically the Puppetfile > from puppet-openstack-integration) and produce the DIB_REPOREF variables > (perhaps ignoring all :ref => 'master' ones), so that we don't have to > track and update them by hand. > > I'm not sure if we absolutely need a Puppetfile for TripleO. The value > added is more in the pins themselves, not so much in syntax (Puppetfile vs. > DIB-style-file). We could use Puppetfile format too, but since we'll not be > able
Re: [openstack-dev] [tripleo] Pin some puppet dependencies on git clone
I suggest then to pin the dependencies from [1] to below. Couldn't be posible to just clone the openstack/puppet-* ones and then use some tool to install the dependencies from them, some kind of pip install -r requirements.txt but adapted for Puppet? Does this tool exist? [1]: https://github.com/openstack/puppet-openstack-integration/blob/master/Puppetfile#L111 On 15 December 2015 at 17:46, Emilien Macchi wrote: > For information, Puppet OpenStack CI is consistent for unit & functional > tests, we use a single (versionned) Puppetfile: > > https://github.com/openstack/puppet-openstack-integration/blob/master/Puppetfile > > TripleO folks might want to have a look at this to follow the > dependencies actually supported by upstream OR if you prefer surfing on > the edge and risk to break CI every morning. > > Let me know if you're interested to support that in TripleO Puppet > elements, I can help with that. > > On 12/14/2015 02:25 PM, Dan Prince wrote: > > On Fri, 2015-12-11 at 21:50 +0100, Jaume Devesa wrote: > >> Hi all, > >> > >> Today TripleO CI jobs failed because a new commit introduced on > >> puppetlabs-mysql[1]. > >> Mr. Jiri Stransky solved it as a temporally fix by pinning the puppet > >> module clone to a previous > >> commit in the tripleo-common project[2]. > >> > >> source-repositories puppet element[3] allows you to pin the puppet > >> module clone as well by > >> adding a reference commit in the source-repository- > >> file. In this case, > >> I am talking about the source-repository-puppet-modules[4]. > >> > >> I know you TripleO guys are brave people that live dangerously in the > >> cutting edge, but I think > >> the dependencies to puppet modules not managed by the OpenStack > >> community should be > >> pinned to last repo tag for the sake of stability. > >> > >> What do you think? > > > > I've previously considered added a stable puppet modules element for > > just this case: > > > > https://review.openstack.org/#/c/184844/ > > > > Using stable branches of things like MySQL, Rabbit, etc might make > > sense. However I would want to consider following what the upstream > > Puppet community does as well specifically because we do want to > > continue using upstream openstack/puppet-* modules as well. At least > > for our upstream CI. > > > > We also want to make sure our stable TripleO jobs use the stable > > branches of openstack/puppet-* so we might need to be careful about > > pinning those things too. > > > > Dan > > > > > >> I can take care of this. > >> > >> [1]: https://github.com/puppetlabs/puppetlabs-mysql/commit/bdf4d0f52d > >> fc244d10bbd5b67efb791a39520ed2 > >> [2]: https://review.openstack.org/#/c/256572/ > >> [3]: https://github.com/openstack/diskimage-builder/tree/master/eleme > >> nts/source-repositories > >> [4]: https://github.com/openstack/tripleo-puppet-elements/blob/master > >> /elements/puppet-modules/source-repository-puppet-modules > >> > >> -- > >> Jaume Devesa > >> Software Engineer at Midokura > >> _ > >> _ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs > >> cribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > ______ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Emilien Macchi > > > __ > 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 > > -- Jaume Devesa Software Engineer at Midokura __ 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] [midonet] Split up python-midonetclient
No. I'm saying that I prefer python-os-midonetclient to be a project by its own instead of being merged inside the neutron plugin repo. On 14 December 2015 at 18:43, Antoni Segura Puimedon < toni+openstac...@midokura.com> wrote: > > > On Mon, Dec 14, 2015 at 6:07 PM, Jaume Devesa wrote: > >> +1 >> >> I think it is good compromise. Thanks Ryu! >> >> I understand the CLI will belong to the external part. I much prefer to >> have >> it in a separate project rather than into the plugin. Even if the code is >> tiny. >> > > Let me summarize it: > > python-midonetclient: Low level API that lives and breathes in > midonet/midonet. > Has the current cli. > python-os-midonetclient: High level API that is in > openstack/python-midonetclient > (can be packaged with a different > name). > > Are you asking for python-os-midonetclient not to include the cli tool? > > I would prefer to keep with the OpenStack practice [1] of having it > together. I don't > think developing a python cli client for the new python-os-midonetclient > that is > on par with the neutron cli tool would be that big of a task and I think > it would > make operation nicer. It could even find the midonet-api from the zookeeper > registry like the other tools do. > > [1] > https://github.com/openstack/python-neutronclient/blob/master/setup.cfg > >> >> If you will want to just do midonet calls for debugging or check the >> MidoNet >> virtual infrastructure, it will be cleaner to install it without >> dependencies than >> dragging the whole neutron project (networking-midonet depends on >> neutron). >> >> Regards, >> >> On 14 December 2015 at 17:32, Ryu Ishimoto wrote: >> >>> On Tue, Dec 15, 2015 at 1:00 AM, Sandro Mathys >>> wrote: >>> > On Tue, Dec 15, 2015 at 12:02 AM, Ryu Ishimoto >>> wrote: >>> > >>> > So if I understand you correctly, you suggest: >>> > 1) the (midonet/internal) low level API stays where it is and will >>> > still be called python-midonetclient. >>> > 2) the (neutron/external) high level API is moved into it's own >>> > project and will be called something like python-os-midonetclient. >>> > >>> > Sounds like a good compromise which addresses the most important >>> > points, thanks Ryu! I wasn't aware that these parts of the >>> > python-midonetclient are so clearly distinguishable/separable but if >>> > so, this makes perfect sense. Not perfectly happy with the naming, but >>> > I figure it's the way to go. >>> >>> Thanks for the endorsement. Yes, it is trivial to separate them (less >>> than a day of work) because they are pretty much already separated. >>> >>> As for the naming, I think it's better to take a non-disruptive >>> approach so that it's transparent to those currently developing the >>> low level midonet client. To your question, however, I have another >>> suggestion, which is that for the high level client code, it may also >>> make sense to just include that as part of the plugin. It's such >>> small code that it might not make sense to separate, and also likely >>> to be used only by the plugin in the future. Which basically means >>> that the plugin need not depend on any python client library at all. >>> I think this will simplify even further. It should also be ok to be >>> tied to the plugin release cycles as well assuming that's the only >>> place the client is needed. >>> >>> Cheers, >>> Ryu >>> >>> >>> >>> > >>> > -- Sandro >>> >>> >>> __ >>> 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 >>> >> >> >> >> -- >> Jaume Devesa >> Software Engineer at Midokura >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Jaume Devesa Software Engineer at Midokura __ 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] [midonet] Split up python-midonetclient
+1 I think it is good compromise. Thanks Ryu! I understand the CLI will belong to the external part. I much prefer to have it in a separate project rather than into the plugin. Even if the code is tiny. If you will want to just do midonet calls for debugging or check the MidoNet virtual infrastructure, it will be cleaner to install it without dependencies than dragging the whole neutron project (networking-midonet depends on neutron). Regards, On 14 December 2015 at 17:32, Ryu Ishimoto wrote: > On Tue, Dec 15, 2015 at 1:00 AM, Sandro Mathys > wrote: > > On Tue, Dec 15, 2015 at 12:02 AM, Ryu Ishimoto wrote: > > > > So if I understand you correctly, you suggest: > > 1) the (midonet/internal) low level API stays where it is and will > > still be called python-midonetclient. > > 2) the (neutron/external) high level API is moved into it's own > > project and will be called something like python-os-midonetclient. > > > > Sounds like a good compromise which addresses the most important > > points, thanks Ryu! I wasn't aware that these parts of the > > python-midonetclient are so clearly distinguishable/separable but if > > so, this makes perfect sense. Not perfectly happy with the naming, but > > I figure it's the way to go. > > Thanks for the endorsement. Yes, it is trivial to separate them (less > than a day of work) because they are pretty much already separated. > > As for the naming, I think it's better to take a non-disruptive > approach so that it's transparent to those currently developing the > low level midonet client. To your question, however, I have another > suggestion, which is that for the high level client code, it may also > make sense to just include that as part of the plugin. It's such > small code that it might not make sense to separate, and also likely > to be used only by the plugin in the future. Which basically means > that the plugin need not depend on any python client library at all. > I think this will simplify even further. It should also be ok to be > tied to the plugin release cycles as well assuming that's the only > place the client is needed. > > Cheers, > Ryu > > > > > > > -- Sandro > > __ > 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 > -- Jaume Devesa Software Engineer at Midokura __ 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] [tripleo] Pin some puppet dependencies on git clone
Hi all, Today TripleO CI jobs failed because a new commit introduced on puppetlabs-mysql[1]. Mr. Jiri Stransky solved it as a temporally fix by pinning the puppet module clone to a previous commit in the tripleo-common project[2]. source-repositories puppet element[3] allows you to pin the puppet module clone as well by adding a reference commit in the source-repository- file. In this case, I am talking about the source-repository-puppet-modules[4]. I know you TripleO guys are brave people that live dangerously in the cutting edge, but I think the dependencies to puppet modules not managed by the OpenStack community should be pinned to last repo tag for the sake of stability. What do you think? I can take care of this. [1]: https://github.com/puppetlabs/puppetlabs-mysql/commit/bdf4d0f52dfc244d10bbd5b67efb791a39520ed2 [2]: https://review.openstack.org/#/c/256572/ [3]: https://github.com/openstack/diskimage-builder/tree/master/elements/source-repositories [4]: https://github.com/openstack/tripleo-puppet-elements/blob/master/elements/puppet-modules/source-repository-puppet-modules -- Jaume Devesa Software Engineer at Midokura __ 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] [midonet] Split up python-midonetclient
Hi Galo, I think the goal of this split is well explained by Sandro in the first mails of the chain: 1. Downstream packaging 2. Tagging the delivery properly as a library 3. Adding as a project on pypi OpenStack provide us a tarballs web page[1] for each branch of each project of the infrastructure. Then, projects like Delorean can allow us to download theses tarball master branches, create the packages and host them in a target repository for each one of the rpm-like distributions[2]. I am pretty sure that there is something similar for Ubuntu. Everything is done in a very straightforward and standarized way, because every repo has its own deliverable. You can look how they are packaged and you won't see too many differences between them. Packaging a python-midonetclient it will be trivial if it is separated in a single repo. It will be complicated and we'll have to do tricky things if it is a directory inside the midonet repo. And I am not sure if Ubuntu and RDO community will allow us to have weird packaging metadata repos. So to me the main reason is 4. Leverage all the infrastructure and procedures that OpenStack offers to integrate MidoNet as best as possible with the release process and delivery. Regards, [1]: http://tarballs.openstack.org/ [2]: http://trunk.rdoproject.org On 9 December 2015 at 15:52, Antoni Segura Puimedon wrote: > > -- Forwarded message -- > From: Galo Navarro > Date: Wed, Dec 9, 2015 at 2:48 PM > Subject: Re: [openstack-dev] [midonet] Split up python-midonetclient > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Cc: Jaume Devesa > > > >> Ditto. We already have a mirror repo of pyc for this purpose > >> https://github.com/midonet/python-midonetclient, synced daily. > > > > Some of the problems with that is that it does not have any git log > history > > nor does it feel like a coding project at all. > > Of course, because the goal of this repo is not to provide a > changelog. It's to provide an independent repo. If you want git log, > you should do a git log python-midonetclient in the source repo > (/midonet/midonet). > > > Allow me to put forward a solution that will allow you keep the > development > > in the midonet tree while, at the same time, having a proper repository > > with identifiable patches in github.com/midonet/python-midonetclient > > Thanks, but I insist: can we please clarify *what* are we trying to > achieve, before we jump into solutions? > > g > > __ > 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 > > -- Jaume Devesa Software Engineer at Midokura __ 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] [TripleO][Tuskar] Steps to follow to provide MidoNet as Neutron backend in TripleO's overcloud
Sorry, I meant "Tuesday". On 19 August 2015 at 10:51, Jaume Devesa wrote: > Thanks Steven. > > I've registered the blueprint: > > https://blueprints.launchpad.net/tripleo/+spec/midonet-deployment-support > > We'll start preparing the pseudo-thirdparty job, develop the feature and > bother you guys in the IRC > channel as soon as you approve the blueprint. > > Can we discuss it next Thursday on the IRC meeting? > > On 18 August 2015 at 18:14, Steven Hardy wrote: > >> On Tue, Aug 18, 2015 at 05:59:44PM +0200, Jaume Devesa wrote: >> > Hi Steven/Emilien, >> > >> > Thanks for the quick responses. >> > >> > On Tue, 18 Aug 2015 16:10, Steven Hardy wrote: >> > > On Tue, Aug 18, 2015 at 04:19:08PM +0200, Jaume Devesa wrote: >> > > >> > > I think the pattern for the templates will be similar to the Cisco ML2 >> > > plugins which are currently being integrated: >> > > >> > > https://review.openstack.org/#/c/198754/ >> > > >> > > The plug-points for third-party configuration is still undergoing some >> > > refinement, but the basic steps are: >> > > >> > > 1. Ensure you have support in the upstream puppet modules (as >> mentioned by >> > > Emilien), and figure out the hieradata required to drive puppet as >> > > required. >> > >> > Yes, we would like to be fully upstream on this. MidoNet plugin >> support for >> > Puppet Neutron is already done since Kilo (and backported to Juno). We >> do have >> > in mind Emilien's request. So I think that won't be a problem. >> > >> > > 2. Create a heat template which creates the hieradata, and defines >> > > parameters for all configurable values, e.g like: >> > > >> > > >> https://review.openstack.org/#/c/198754/10/puppet/extraconfig/pre_deploy/controller/network-cisco.yaml >> > > >> > > 3. Define a heat environment file, which wires in the template from >> (2) via >> > > the OS::TripleO::ControllerExtraConfigPre interface: >> > > >> > > >> https://review.openstack.org/#/c/198754/10/environments/cisco-nexus-ucsm-plugin.yaml >> > > >> > > 4. Add the hieradata file deployed via (2) to the controller >> hierarchy: >> > > >> > > >> https://review.openstack.org/#/c/198754/10/puppet/controller-puppet.yaml >> > > >> > > 5. Add conditional logic to the manifiests so the appropriate modules >> from >> > > (1) are included when your backend is enabled: >> > > >> > > >> https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller.pp >> > > >> https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller_pacemaker.pp >> > > >> > > Basically the way this works is the hieradata is deployed via (2) >> before >> > > puppet runs, and the manifiest changes in (5) consumes that data when >> we >> > > apply it during deployment. >> > >> > The links and the steps to follow are so helpful! Thanks again. Couple >> of >> > questions here: >> > >> > * There is no need of `tripleo-puppet-elements`? >> >> It depends, if your additions require additional packages to be installed, >> then you may need to either add them to an existing element, or create a >> new element which may be specified by those building images with >> diskimage-builder, e.g so their images contain what you require. >> >> >> https://github.com/openstack/tripleo-puppet-elements/blob/master/elements/overcloud-controller/install.d/package-installs-overcloud-controller >> >> If your integration purely requires configuration changes (and the puppet >> module already exists in the image), you may not need to do anything. >> >> > * Since the integration seems feasible, does it make sense to start >> opening a >> > blueprint and start working on it? >> >> Absolutely, a blueprint is probably a good idea (although tbh these >> haven't >> been strictly required lately..) summarising the required changes, then >> you >> can use the examples I linked to work on the template changes. >> >> > > No, we're moving away from tuskar and it's not required for >> third-party >> > > integration such as described above (it's also not covered in CI). >> > > >> > > Speaking of CI, it&#
Re: [openstack-dev] [TripleO][Tuskar] Steps to follow to provide MidoNet as Neutron backend in TripleO's overcloud
Thanks Steven. I've registered the blueprint: https://blueprints.launchpad.net/tripleo/+spec/midonet-deployment-support We'll start preparing the pseudo-thirdparty job, develop the feature and bother you guys in the IRC channel as soon as you approve the blueprint. Can we discuss it next Thursday on the IRC meeting? On 18 August 2015 at 18:14, Steven Hardy wrote: > On Tue, Aug 18, 2015 at 05:59:44PM +0200, Jaume Devesa wrote: > > Hi Steven/Emilien, > > > > Thanks for the quick responses. > > > > On Tue, 18 Aug 2015 16:10, Steven Hardy wrote: > > > On Tue, Aug 18, 2015 at 04:19:08PM +0200, Jaume Devesa wrote: > > > > > > I think the pattern for the templates will be similar to the Cisco ML2 > > > plugins which are currently being integrated: > > > > > > https://review.openstack.org/#/c/198754/ > > > > > > The plug-points for third-party configuration is still undergoing some > > > refinement, but the basic steps are: > > > > > > 1. Ensure you have support in the upstream puppet modules (as > mentioned by > > > Emilien), and figure out the hieradata required to drive puppet as > > > required. > > > > Yes, we would like to be fully upstream on this. MidoNet plugin support > for > > Puppet Neutron is already done since Kilo (and backported to Juno). We > do have > > in mind Emilien's request. So I think that won't be a problem. > > > > > 2. Create a heat template which creates the hieradata, and defines > > > parameters for all configurable values, e.g like: > > > > > > > https://review.openstack.org/#/c/198754/10/puppet/extraconfig/pre_deploy/controller/network-cisco.yaml > > > > > > 3. Define a heat environment file, which wires in the template from > (2) via > > > the OS::TripleO::ControllerExtraConfigPre interface: > > > > > > > https://review.openstack.org/#/c/198754/10/environments/cisco-nexus-ucsm-plugin.yaml > > > > > > 4. Add the hieradata file deployed via (2) to the controller hierarchy: > > > > > > > https://review.openstack.org/#/c/198754/10/puppet/controller-puppet.yaml > > > > > > 5. Add conditional logic to the manifiests so the appropriate modules > from > > > (1) are included when your backend is enabled: > > > > > > > https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller.pp > > > > https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller_pacemaker.pp > > > > > > Basically the way this works is the hieradata is deployed via (2) > before > > > puppet runs, and the manifiest changes in (5) consumes that data when > we > > > apply it during deployment. > > > > The links and the steps to follow are so helpful! Thanks again. Couple of > > questions here: > > > > * There is no need of `tripleo-puppet-elements`? > > It depends, if your additions require additional packages to be installed, > then you may need to either add them to an existing element, or create a > new element which may be specified by those building images with > diskimage-builder, e.g so their images contain what you require. > > > https://github.com/openstack/tripleo-puppet-elements/blob/master/elements/overcloud-controller/install.d/package-installs-overcloud-controller > > If your integration purely requires configuration changes (and the puppet > module already exists in the image), you may not need to do anything. > > > * Since the integration seems feasible, does it make sense to start > opening a > > blueprint and start working on it? > > Absolutely, a blueprint is probably a good idea (although tbh these haven't > been strictly required lately..) summarising the required changes, then you > can use the examples I linked to work on the template changes. > > > > No, we're moving away from tuskar and it's not required for third-party > > > integration such as described above (it's also not covered in CI). > > > > > > Speaking of CI, it'd be good to discuss how you plan to ensure your > stuff > > > stays working, as clearly we don't have the resources in upstream CI to > > > test it, having third-party CI jobs vote on TripleO changes would be > one > > > way to solve this, but AFAIK we don't yet have a process in place to > enable > > > this. > > > > Even if there is not an official Third Party methodology, it wouldn't be > so hard > > to add a Jenkins job on our infrastructure to listen upstream
Re: [openstack-dev] [TripleO][Tuskar] Steps to follow to provide MidoNet as Neutron backend in TripleO's overcloud
Hi Steven/Emilien, Thanks for the quick responses. On Tue, 18 Aug 2015 16:10, Steven Hardy wrote: > On Tue, Aug 18, 2015 at 04:19:08PM +0200, Jaume Devesa wrote: > > I think the pattern for the templates will be similar to the Cisco ML2 > plugins which are currently being integrated: > > https://review.openstack.org/#/c/198754/ > > The plug-points for third-party configuration is still undergoing some > refinement, but the basic steps are: > > 1. Ensure you have support in the upstream puppet modules (as mentioned by > Emilien), and figure out the hieradata required to drive puppet as > required. Yes, we would like to be fully upstream on this. MidoNet plugin support for Puppet Neutron is already done since Kilo (and backported to Juno). We do have in mind Emilien's request. So I think that won't be a problem. > 2. Create a heat template which creates the hieradata, and defines > parameters for all configurable values, e.g like: > > https://review.openstack.org/#/c/198754/10/puppet/extraconfig/pre_deploy/controller/network-cisco.yaml > > 3. Define a heat environment file, which wires in the template from (2) via > the OS::TripleO::ControllerExtraConfigPre interface: > > https://review.openstack.org/#/c/198754/10/environments/cisco-nexus-ucsm-plugin.yaml > > 4. Add the hieradata file deployed via (2) to the controller hierarchy: > > https://review.openstack.org/#/c/198754/10/puppet/controller-puppet.yaml > > 5. Add conditional logic to the manifiests so the appropriate modules from > (1) are included when your backend is enabled: > > https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller.pp > https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller_pacemaker.pp > > Basically the way this works is the hieradata is deployed via (2) before > puppet runs, and the manifiest changes in (5) consumes that data when we > apply it during deployment. The links and the steps to follow are so helpful! Thanks again. Couple of questions here: * There is no need of `tripleo-puppet-elements`? * Since the integration seems feasible, does it make sense to start opening a blueprint and start working on it? > > No, we're moving away from tuskar and it's not required for third-party > integration such as described above (it's also not covered in CI). > > Speaking of CI, it'd be good to discuss how you plan to ensure your stuff > stays working, as clearly we don't have the resources in upstream CI to > test it, having third-party CI jobs vote on TripleO changes would be one > way to solve this, but AFAIK we don't yet have a process in place to enable > this. Even if there is not an official Third Party methodology, it wouldn't be so hard to add a Jenkins job on our infrastructure to listen upstream gerrit events and make comments instead of voting, right? (maybe I am speaking so quickly, I can not image right now how a TripleO Jenkins job look like...) > > Let us know if you need any further help - you can drop in to #tripleo on > Freenode to discuss :) I'm already there :) > > Steve > > __ > 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 Regards! -- Jaume Devesa Software Engineer at Midokura __ 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] [TripleO][Tuskar] Steps to follow to provide MidoNet as Neutron backend in TripleO's overcloud
Hi all, We in Midokura are considering to collaborate on TripleO to provide MidoNet as a backend technology for Neutron in the overcloud. We haven't found any vendor plugin image defined on the `tripleo-puppet-elements` nor heat template in the `tripleo-heat-templates`... So my first question is: Is there willingness from the TripleO folks to accept code to deploy third-party vendors? Alternatively (although not desirable): is there any plugin system to work out of the tree? I'm a noob on TripleO, so I would need some guidance for next steps to follow to achieve our goal. I understand that work should be done on these three projects: * `tripleo-puppet-elements`: we do have a puppet module to configure MidoNet, I understand an image to install the packages will be needed. * `tripleo-heat-templates`: MidoNet and Neutron specific templates. * `tuskar`?: will we need tuskar as well? Am I right? Cheers, -- Jaume Devesa Software Engineer at Midokura __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Proposing Assaf Muller for the Neutron Core Reviewer Team
Congratulations Assaf!! On 4 June 2015 at 17:45, Paul Michali wrote: > +100 Great addition! Congratulations Assaf! > > On Thu, Jun 4, 2015 at 11:41 AM Miguel Lavalle > wrote: > >> Congrats! Well deserved >> >> On Thu, Jun 4, 2015 at 8:50 AM, Assaf Muller wrote: >> >>> Thank you. >>> >>> We have a lot of work ahead of us :) >>> >>> >>> - Original Message - >>> > It's a been a week since I proposed this, with no objections. Welcome >>> to the >>> > Neutron core reviewer team as the new QA Lieutenant Assaf! >>> > >>> > On Tue, Jun 2, 2015 at 12:35 PM, Maru Newby < ma...@redhat.com > >>> wrote: >>> > >>> > >>> > +1 from me, long overdue! >>> > >>> > >>> > > On May 28, 2015, at 9:42 AM, Kyle Mestery < mest...@mestery.com > >>> wrote: >>> > > >>> > > Folks, I'd like to propose Assaf Muller to be a member of the >>> Neutron core >>> > > reviewer team. Assaf has been a long time contributor in Neutron, >>> and he's >>> > > also recently become my testing Lieutenant. His influence and >>> knowledge in >>> > > testing will be critical to the team in Liberty and beyond. In >>> addition to >>> > > that, he's done some fabulous work for Neutron around L3 HA and DVR. >>> Assaf >>> > > has become a trusted member of our community. His review stats place >>> him >>> > > in the pack with the rest of the Neutron core reviewers. >>> > > >>> > > I'd also like to take this time to remind everyone that reviewing >>> code is a >>> > > responsibility, in Neutron the same as other projects. And core >>> reviewers >>> > > are especially beholden to this responsibility. I'd also like to >>> point out >>> > > that +1/-1 reviews are very useful, and I encourage everyone to >>> continue >>> > > reviewing code even if you are not a core reviewer. >>> > > >>> > > Existing Neutron cores, please vote +1/-1 for the addition of Assaf >>> to the >>> > > core reviewer team. >>> > > >>> > > Thanks! >>> > > Kyle >>> > > >>> > > [1] http://stackalytics.com/report/contribution/neutron-group/180 >>> > > >>> __ >>> > > OpenStack Development Mailing List (not for usage questions) >>> > > Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> > >>> > >>> __ >>> > OpenStack Development Mailing List (not for usage questions) >>> > Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> > >>> > >>> __ >>> > OpenStack Development Mailing List (not for usage questions) >>> > Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Jaume Devesa Software Engineer at Midokura __ 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] [packaging] Adding packaging as an OpenStack project
Hi Thomas, Delorean is a tool to build rpm packages from master branches (maybe any branch?) of OpenStack projects. Check out here: https://www.rdoproject.org/packaging/rdo-packaging.html#master-pkg-guide Regards, On Thu, 28 May 2015 10:40, Thomas Goirand wrote: > Derek, > > Thanks for what you wrote. > > On 05/27/2015 11:26 PM, Derek Higgins wrote: > >> 4. For deb packages you can create new repositories along side the > >> rdorpm-* repositories > > My intention is to use deb-* as prefix, if Canonical team agrees. > > >> 5. Add deb support to delorean, I know of at least one person who has > >> already explored this (steve cc'd), if delorean is too far off the path > >> of what we want to achieve and there is a better tool then I'm open to > >> change. > > I don't know delorean at all, but what should be kept in mind is that, > for Debian and Ubuntu, we *must* use sbuild, which is what is used on > the buildd networks. > > I also started working on openstack-pkg-tools to provide such sbuild > based build env, so I'm not sure if we need to switch to Delorean. Could > you point me to some documentation about it, so I can see by myself what > Delorean is about? > > Cheers, > > Thomas > > __ > 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 -- Jaume Devesa Software Engineer at Midokura __ 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] install custom middleware via devstack
Hi Ali, I don't know the details of what you want to achieve, but (not so) recently, devstack allows you to add Externally Hosted Plugins[1], from which Devstack loads an external repository and run any arbitrary code. This code will be sourced in each one of the Devstack's phases, so you can control what code run in each phase. Check out the script we use in MidoNet plugin as an example[2] Hope that helps. [1]: http://docs.openstack.org/developer/devstack/plugins.html#externally-hosted-plugins [2]: https://github.com/stackforge/networking-midonet/blob/master/devstack/plugin.sh On Tue, 28 Apr 2015 08:55, AliReza Taleghani wrote: > Hi > I'm working on a custom middleware which will place on swift-proxy > pipeline, just before the latest proxy-logging. > > how can I force devstack to install my middleware just as I run ./stack.sh? > #The point is that I'm looking for a mature and standard to do it, so I'm > not going to just edit the stack.sh and Embed some scripts to manually > handle the case! but as I mentioned I would like the learn the best case... > > > > Sincerely, > Ali R. Taleghani > @linkedIn <http://ir.linkedin.com/in/taleghani> > __ > 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 -- Jaume Devesa Software Engineer at Midokura __ 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] [third-party][infra] Third-Party CI Operators: Let's use a common CI Solution!
Hi Ramy, Soon I'll be the responsible of the Midokura's third-party CI, which has been mute for a while because a flaky physical resources that our sys admins couldn't take care because they are overloaded of work... Count on me! On Mon, 20 Apr 2015 05:17, Asselin, Ramy wrote: > All Third-Party CI operators: > > We’ve got 85 Third Party CI systems registered in the wiki[1], all of them > running a variety of closed & open-source solutions. > Instead of individually maintaining all those similar solutions, let’s join > together and collectively maintain a single solution. > > If that sounds good to you, there’s an Infra-spec that’s been approved [2] to > refactor much of what the Infrastructure team uses for the upstream “Jenkins” > CI to be more easily reusable by many of us. > > We’ve got stories defined [3], and a few patches submitted. We’re using the > gerrit-topic “downstream-puppet” [4]. > > For example, we’ve got the first part under review for the “Log Server”, > which creates your own version of http://logs.openstack.org/ > > If anyone is interested in migrating towards a common solution, reply, or > ping me IRC (asselin) on Freenode #openstack-infra, or join some of the third > party ci meetings [5]. > > Thanks! > Ramy > > [1] https://wiki.openstack.org/wiki/ThirdPartySystems > [2] > http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html > [3] https://storyboard.openstack.org/#!/story/2000101 > [4] https://review.openstack.org/#/q/topic:downstream-puppet,n,z > [5] > https://wiki.openstack.org/wiki/Meetings/ThirdParty#Weekly_Third_Party_meetings > > > __ > 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 -- Jaume Devesa Software Engineer at Midokura __ 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] - Joining the team - interested in a Debian Developer and experienced Python and Network programmer?
Hi all, I'll attend the next L3 meeting this Thurdsay so we can revive the BGP work for Liberty. Sorry for being absent for many weeks. Thanks for your interest on it. Regards, On Mon, 13 Apr 2015 11:32, Carl Baldwin wrote: > Hi, I'm getting back from a little time off over the weekend. > > Artem Dmytrenko and Jaume Devesa have done great work [1] with me over > the last year figuring out how to integrate routing protocols with > Neutron. We have had to exhibit some patience as this work has not > yet bubbled to the top of the team's overall priority list. However, > I think it is an important part of Neutron's future. I've started > putting up some blueprints to get this back on track. The first one > here [2] lays some ground work. > > I invite you to come discuss more at our L3 meeeting on Thurdays at > 1500 UTC [3]. There is a bit more information about BGP/dynamic > routing on the team page. > > Carl > > [1] https://review.openstack.org/#/c/125401/ > [2] https://review.openstack.org/#/c/172244/ > [3] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam > > On Thu, Apr 9, 2015 at 8:26 AM, Mathieu Rohon wrote: > > Hi Matt, > > > > Jaume did an awesome work at proposing and implementing a framework for > > announcing public IP with a BGP speaker [1]. > > Unfortunately, the spec hasn't been merged in kilo. Hope it will be > > resubmitted in L. > > Your proposal seems to be a mix of Jaume proposal and HA router design? > > > > We also play with a BGP speaker (BagPipe[3], derived from ExaBGP, written in > > python) for IPVPN attachment [2]. > > > > [1]https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing > > [2]https://launchpad.net/bgpvpn > > [3]https://github.com/Orange-OpenSource/bagpipe-bgp > > > > On Thu, Apr 9, 2015 at 3:54 PM, Kyle Mestery wrote: > >> > >> On Thu, Apr 9, 2015 at 2:13 AM, Matt Grant wrote: > >>> > >>> Hi! > >>> > >>> I am just wondering what the story is about joining the neutron team. > >>> Could you tell me if you are looking for new contributors? > >>> > >> We're always looking for someone new to participate! Thanks for reaching > >> out! > >> > >>> > >>> Previously I have programmed OSPFv2 in Zebra/Quagga, and worked as a > >>> router developer for Allied Telesyn. I also have extensive Python > >>> programming experience, having worked on the DNS Management System. > >>> > >> Sounds like you have extensive experience programming network elements. :) > >> > >>> > >>> I have been experimenting with IPv6 since 2008 on my own home network, > >>> and I am currently installing a Juno Openstack cluster to learn ho > >>> things tick. > >>> > >> Great, this will give you an overview of things. > >> > >>> > >>> Have you guys ever figured out how to do a hybrid L3 North/South Neutron > >>> router that propagates tenant routes and networks into OSPF/BGP via a > >>> routing daemon, and uses floating MAC addresses/costed flow rules via > >>> OVS to fail over to a hot standby router? There are practical use cases > >>> for such a thing in smaller deployments. > >>> > >> BGP integration with L3 is something we'll look at again for Liberty. Carl > >> Baldwin leads the L3 work in Neutron, and would be a good person to sync > >> with on this work item. I suspect he may be looking for people to help > >> integrate the BGP work in Liberty, this may be a good place for you to jump > >> in. > >> > >>> I have a single stand alone example working by turning off > >>> neutron-l3-agent network name space support, and importing the connected > >>> interface and static routes into Bird and Birdv6. The AMPQ connection > >>> back to the neutron-server is via the upstream interface and is secured > >>> via transport mode IPSEC (just easier than bothering with https/SSL). > >>> Bird looks easier to run from neutron as they are single process than a > >>> multi process Quagga implementation. Incidentally, I am running this in > >>> an LXC container. > >>> > >> Nice! > >> > >>> > >>> Could some one please point me in the right direction. I would love to > >>> be in Vancouver :-) > >>> > >> If you're not already on #openstack-neutron on Freenode, jump in there. > >> Plenty of helpf
Re: [openstack-dev] [devstack] [third-party] how to use a devstack external plugin in gate testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Following the conversation... We have seen that glusterfs[1] and ec2api[2] use different approach when it comes to repository managing: whereas glusterfs is a single 'devstack' directory repository, ec2api is a whole project with a 'devstack' directory on it. We plan to migrate 'python-neutron-plugin-midonet'[3] project to Stackforge too. It makes sense to add the 'devstack' directory on it? Or do you recommend us to have two different repositories in Stackforge: one for the neutron plugin and the other one for the devstack plugin? We can not see any big advantage or disadvantage in any of them... so we have decided to ask to the community if someone is able see what we can not see. Regards, [1]: https://github.com/stackforge/devstack-plugin-glusterfs [2]: https://github.com/stackforge/ec2-api [3]: https://github.com/midonet/python-neutron-plugin-midonet El 11/02/15 a las 17:43, Jaume Devesa escribió: > Hello, > > I'm working in the same job as Kyle for the midonet plugin, but > first I need to do some changes in devstack. (Sean's review on my > patch[1] has lead me to this conversation). > > After talking with Lucas, (Midokura's responsible of Third-party > testing), we have a question about this that involve the > third-party folks: if we get our own Jenkins job that tests > devstack with midonet and we include this job in the Neutron's gate > (as non-voting, of course), that would be considered Neutron > Third-party testing? > > Can we chat about this on next Monday's third party meeting? > > Regards, > > [1]: https://review.openstack.org/#/c/152876 > > El 06/02/15 a las 22:54, Kyle Mestery escribió: >> On Fri, Feb 6, 2015 at 1:36 PM, Sean Dague >> wrote: > >>> For those that didn't notice, on the Devstack team we've >>> started to push back on new in-tree support for all the >>> features. That's intentional. We've got an external plugin >>> interface now - >>> >>> http://docs.openstack.org/developer/devstack/plugins.html#externally-hosted-plugins >>> >>> >>> > >>> , >>> and have a few projects like the ec2api and glusterfs that are >>> successfully using it. Our Future direction is to do more of >>> this - https://review.openstack.org/#/c/150789/ >>> >>> The question people ask a lot is 'but, how do I do a gate job >>> with the external plugin?'. >>> >>> Starting with the stackforge/ec2api we have an example up on >>> how to do that: https://review.openstack.org/#/c/153659/ >>> >>> The important bits are as follows: >>> >>> 1. the git repo that you have your external plugin in *must* be >>> in gerrit. stackforge is fine, but it has to be hosted in the >>> OpenStack infrastructure. >>> >>> 2. The job needs to add your PROJECT to the projects list, >>> i.e.: >>> >>> export PROJECTS="stackforge/ec2-api $PROJECTS" >>> >>> 3. The job needs to add a DEVSTACK_LOCAL_CONFIG line for the >>> plugin enablement: >>> >>> export DEVSTACK_LOCAL_CONFIG="enable_plugin ec2-api >>> git://git.openstack.org/stackforge/ec2-api" >>> >>> Beyond that you can define your devstack job however you like. >>> It can test with Tempest. It can instead use a post_test_hook >>> for functional testing. Whatever is appropriate for your >>> project. >>> >>> This is awesome Sean! Thanks for the inspiration here. In >>> fact, I just >> pushed a series of patches [1] [2] which do the same for the >> networking-odl stackforge project. > >> Thanks, Kyle > >> [1] https://review.openstack.org/#/c/153704/ [2] >> https://review.openstack.org/#/c/153705/ > >> -Sean >>> >>> -- Sean Dague http://dague.net >>> >>> ______ >>> >>> >>> > >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> >>> >>> > > >> __ > >> > > > OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?s
Re: [openstack-dev] [devstack] [third-party] how to use a devstack external plugin in gate testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, I'm working in the same job as Kyle for the midonet plugin, but first I need to do some changes in devstack. (Sean's review on my patch[1] has lead me to this conversation). After talking with Lucas, (Midokura's responsible of Third-party testing), we have a question about this that involve the third-party folks: if we get our own Jenkins job that tests devstack with midonet and we include this job in the Neutron's gate (as non-voting, of course), that would be considered Neutron Third-party testing? Can we chat about this on next Monday's third party meeting? Regards, [1]: https://review.openstack.org/#/c/152876 El 06/02/15 a las 22:54, Kyle Mestery escribió: , OpenStack Development Mailing List (not for usage questions) OpenStack Development Mailing List (not for usage questions) - -- Jaume Devesa Software Engineer, Midokura -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU24bCAAoJEPvO/ogkgqHBFvMQAJAQM83wgOr6WIcRr3hOZthd d82JVjXRdY282hvu2Eid+n47RdEfwBTbRkJnnKyWW9IcxsO8HX3oEjPct4H33CCB c8kjQUile7WVQZt2obAT+PMwbub9u1/WTxnzUIUujg6NhKoXmM+f5lEawCh6k1HZ UqiTIb+8P08m+IhOIAjG95lTENSAX9P4YJA48vTDLtyODYo6kuWYh1TVx5IxvpnU Min1xMcxYr2mPNZv1P9Hu+cOx9g1ZDPvUEXe03lzR4HqFkisXe2Xi8OK+J778KyT xCSGoJ19x3pcuDIqUy2LQ5wgv41vuQtd5ASJLx7oaXk/Bsr1CRv6NSK1zYb7zA/C As4bTwpZQqKCnRfYVrys8cDWS2ZVGH1APQT7AhVL8CnluLPTMwjrbNRzv3gYi5kU CPh0aGTdt9hsi061k7Th/A2Op7Zz6MAT3fWjscJYSftdX0g+l/UYGpUHCoagynew KKkNS2BfM1AIvTpyC2zKeV/u53Oup1+htkV+rc8TMHXIztpbvxWVdG/BP9sao2xC iIFPjkyaL4ZyG20O0R5NzR0gYxjZMutRbxl2iyC8fpLOJRY1DosOg7he3htgAM45 J7VPZp41cW8CmR//2G8hinBC+cW6SZzhNeOogzT89KEn/a0KV5SoMxCy0oLfaDR7 upfUpAWAO1vIgl53ftFj =yUo7 -END PGP SIGNATURE- __ 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] [third-party] how to use a devstack external plugin in gate testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, I'm working in the same job as Kyle for the midonet plugin, but first I need to do some changes in devstack. (Sean's review on my patch[1] has lead me to this conversation). After talking with Lucas, (Midokura's responsible of Third-party testing), we have a question about this that involve the third-party folks: if we get our own Jenkins job that tests devstack with midonet and we include this job in the Neutron's gate (as non-voting, of course), that would be considered Neutron Third-party testing? Can we chat about this on next Monday's third party meeting? Regards, [1]: https://review.openstack.org/#/c/152876 El 06/02/15 a las 22:54, Kyle Mestery escribió: > On Fri, Feb 6, 2015 at 1:36 PM, Sean Dague wrote: > >> For those that didn't notice, on the Devstack team we've started >> to push back on new in-tree support for all the features. That's >> intentional. We've got an external plugin interface now - >> >> http://docs.openstack.org/developer/devstack/plugins.html#externally-hosted-plugins >> >> >> , >> and have a few projects like the ec2api and glusterfs that are >> successfully using it. Our Future direction is to do more of >> this - https://review.openstack.org/#/c/150789/ >> >> The question people ask a lot is 'but, how do I do a gate job >> with the external plugin?'. >> >> Starting with the stackforge/ec2api we have an example up on how >> to do that: https://review.openstack.org/#/c/153659/ >> >> The important bits are as follows: >> >> 1. the git repo that you have your external plugin in *must* be >> in gerrit. stackforge is fine, but it has to be hosted in the >> OpenStack infrastructure. >> >> 2. The job needs to add your PROJECT to the projects list, i.e.: >> >> export PROJECTS="stackforge/ec2-api $PROJECTS" >> >> 3. The job needs to add a DEVSTACK_LOCAL_CONFIG line for the >> plugin enablement: >> >> export DEVSTACK_LOCAL_CONFIG="enable_plugin ec2-api >> git://git.openstack.org/stackforge/ec2-api" >> >> Beyond that you can define your devstack job however you like. >> It can test with Tempest. It can instead use a post_test_hook >> for functional testing. Whatever is appropriate for your >> project. >> >> This is awesome Sean! Thanks for the inspiration here. In fact, >> I just > pushed a series of patches [1] [2] which do the same for the > networking-odl stackforge project. > > Thanks, Kyle > > [1] https://review.openstack.org/#/c/153704/ [2] > https://review.openstack.org/#/c/153705/ > > -Sean >> >> -- Sean Dague http://dague.net >> >> __ >> >> >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> > > > __ > > > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > - -- Jaume Devesa Software Engineer, Midokura -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU24bCAAoJEPvO/ogkgqHBpKMP/0aQoCNgQs/8w8gDjmUxlzI4 BE3e3+bGPKKwBNusc6N1i7ptoqz9WU+Atl38uOvxYabFYig94l639tJxTUQGOGQ8 mSYdq+MNMqr/ExKp2M5SQr4QNeMlB8TqqBTdzwH+HIhNu4Het8aybwlLo4O2XBFQ zFPVtLCxd9d3LlTyTztHg0oQ2U4vZDwdSLyVytFFrq9orjXFKAl6JRIssR9Kf4t4 Raxm2KTjbukxmo/4jwhJl9c1Cm/y+RmRinyXIrh0ppglP80xaIp0RljqhY3UEQRu ifgcxEod7HZNTHeTksg7QFMiiT1PO/32fOQPgJbZhX2siAQan3xajcC5g0sDZtoM 3OrhDf9mk6WH/6QkKs235z3HqjWJGEsE5TLGeTHsFA4Je2z45Jn9tT7WJWmvMZiK wiSHd1NxpIKc+PY7STlcvzZZKmEDg8wyXL+VFdGg5RF1SV9Dmp3PeDcQ8RqyrNLL myWPC2ZGpWxueD12hQay8WJ8WOLWn/ei0NVmHXhkxZqG+X2s3Ya/cfp1CpIVigpJ WcqlHtqPHvD4sISATY/qqT4ZPi4NY06fh0IxJ+qfXyn8pOJcpcwjiygS85iWRgEK 4rq/FNYymtpJdDJjpA0eL3DVfffYocCMKos6QIg7aIOvNY9QMzpakRe4BCRzXviA 4Vkp7Dze/fQjdDovnIec =gbvT -END PGP SIGNATURE- __ 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] Provider Router topology
Hello Salvatore, thanks for the response. Rest of the responses inline: El 12/11/14 a las 10:49, Salvatore Orlando escribió: > Hi Jaume, > > The concept of provider router is useful as it maps what actually already > happens in several infrastructures. I am not entirely sure that this > however implies we need to expose new API constructs and change the > topology API. Our first mistake was to use the word 'Provider Router' for the spec. Maybe the 'edge' concept was better. We don't mean to add or substitute functionality for the current Provider Router, but offer a different topology without the need to define an External Network to provide a public floating range, or even a public routable for IPv6 use cases. > > The provider router perhaps can exist in a concealed way, where tenants > still put gateways on an external network, but that would be implemented > with a provider router. > > Anyway, I am sure you are aware of the technical debt repayment activities > scheduled for Kilo. Some of them pertain the l3 agent [1], and I'd say > those have the highest priority. If this spec will bring non-negligible > changes in the l3 agent, perhaps it's the case of doing that after the > agent restructuring to avoid conflicts which will slow down everything. I am. Actually I'm willing to collaborate on it. > > Finally, can you post the specification for this work in gerrit? It seems > it is not the one under the 'edge router' name [2] I changed the blueprint URL and I forgot to update this spec. I'll update it in a few days. > > Salvatore > > [1] https://review.openstack.org/#/c/131535/ > [2] https://review.openstack.org/128272 > > On 31 October 2014 10:01, Jaume Devesa wrote: > >> Hi all, >> >> in Midokura we are working on a blueprint to define a new kind of topology >> for floating ranges, as alternative to external network topology. It is >> based on the idea of a Provider Router that links directly with Tenant >> Routers using /30 networks. It aims to be more pure-floating, helping the >> deployment of floating ranges across different physical L2 Networks. (We >> know there is some interest in this[1]) We think that also it might help in >> add Firewall specific policies at the edge of the cloud and define >> per-tenant or per-network QoS definitions. >> >> Document[2] is still WIP, with high level ideas and just some API details. >> But we would love to hear Neutron community feedback to go further in a >> steady way. In the implementation level, we are concerned in being >> compatible with current DVR and don't add a new SPOF in Neutron OVS plugin. >> So DVR developers feedback would be highly appreciated. >> >> We are also interested in chat about it during the summit, maybe during >> the Kilo L3 refractor BoF? [3] >> >> Thanks in advance! >> >> PD: Blueprint is here[4] >> >> [1]: https://blueprints.launchpad.net/neutron/+spec/pluggable-ext-net >> [2]: >> https://docs.google.com/a/midokura.com/document/d/1fUPhpBWpiUvBe_c55lkokDIls--4dKVSFmGVtjxjg0w/edit# >> [3]: https://etherpad.openstack.org/p/kilo-l3-refactoring >> [4]: >> https://blueprints.launchpad.net/neutron/+spec/neutron-provider-router >> >> >> -- >> Jaume Devesa >> Software Engineer at Midokura >> >> _______ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Jaume Devesa Software Engineer, Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Let's fix all neutron bugs! (NOT)
Hello Eugene, I'm in. I'm more familiar with L3 and I'm willing to get introduced in IPv6, feel free to assign or subscribe me to any bug. This is my launchpad: https://launchpad.net/~devvesa Cheers, On 10 November 2014 08:57, marios wrote: > On 07/11/14 11:17, Eugene Nikanorov wrote: > > Hi folks, > > > > I have been supervising bug list for neutron during the last release > > cycle, trying > > to do some "housekeeping", prioritizing issues and fixing some of them. > > > > As you might see, amount of bugs (even staying in "New" state) doesn't > > go down. > > Bugs appear at quite fast pace, and some of them hang for quite a long > > time, especially if someone has assigned the bug on himself and then > > abandoned working on it. > > One of the other reasons for that is that we lack volunteers willing to > > fix those bugs. > > > > So, > > Hi Eugene, > > I started looking into various bugs a couple weeks before summit as a > way to learn more about the codebase - I can continue to do this into > this cycle and am happy to try anything, > > thanks! marios > > > > > If you're willing to help, have some knowledge of neutron and its > > codebase or you have a lab where you can reproduce (and hence, confirm) > > the bug and provide more additional debugging info, that would be great! > > My plan is to get your contact, knowing what "part" of neutron project > > you familiar with, and then assign bugs directly to you if I feel that > > the issue matches your experience. > > > > I just want to make bug triaging/fixing process a bit more iterative and > > efficient, with a help of community. > > So please reach directly to me and let me know what you are > > interested/experienced with. > > > > Thanks, > > Eugene. > > > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] BGP - VPN BoF session in Kilo design summit
Hello, BoF will be Wednesday 5 at 15:00 pm at Design Summit building. We will have the chance to talk about it into the Kilo L3 refactoring BoF https://etherpad.openstack.org/p/kilo-l3-refactoring Cheers, On 30 October 2014 07:28, Carl Baldwin wrote: > Yes, let's discuss this in the meeting on Thursday. > > Carl > On Oct 29, 2014 5:27 AM, "Jaume Devesa" wrote: > >> Hello, >> >> it seems like the BGP dynamic routing it is in a good shape to be >> included in Neutron during Kilo[1]. There is quite interest in offer >> BGP-VPN too. Mathieu Rohon's spec[2] goes in this direction. Of course it >> makes sense that his development leverages the BGP one. >> >> I would like to have a BoF session and invite anyone interested on these >> blueprints to join us or even add a new related one. I've created an >> etherpad[3] to share ideas and agree with session schedule. I propose >> Wednesday afternoon. >> >> If Carl Baldwin is agree, we can talk about it also during the open >> discussion of today's L3 subteam meeting. >> >> [1]: https://review.openstack.org/#/c/125401/ >> [ >> 2]: https://review.openstack.org/#/c/125401/ >> [3]: https://etherpad.openstack.org/p/bgp-vpn-dynamic-routing >> >> Cheers, >> >> -- >> Jaume Devesa >> Software Engineer at Midokura >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Provider Router topology
Hi all, in Midokura we are working on a blueprint to define a new kind of topology for floating ranges, as alternative to external network topology. It is based on the idea of a Provider Router that links directly with Tenant Routers using /30 networks. It aims to be more pure-floating, helping the deployment of floating ranges across different physical L2 Networks. (We know there is some interest in this[1]) We think that also it might help in add Firewall specific policies at the edge of the cloud and define per-tenant or per-network QoS definitions. Document[2] is still WIP, with high level ideas and just some API details. But we would love to hear Neutron community feedback to go further in a steady way. In the implementation level, we are concerned in being compatible with current DVR and don't add a new SPOF in Neutron OVS plugin. So DVR developers feedback would be highly appreciated. We are also interested in chat about it during the summit, maybe during the Kilo L3 refractor BoF? [3] Thanks in advance! PD: Blueprint is here[4] [1]: https://blueprints.launchpad.net/neutron/+spec/pluggable-ext-net [2]: https://docs.google.com/a/midokura.com/document/d/1fUPhpBWpiUvBe_c55lkokDIls--4dKVSFmGVtjxjg0w/edit# [3]: https://etherpad.openstack.org/p/kilo-l3-refactoring [4]: https://blueprints.launchpad.net/neutron/+spec/neutron-provider-router -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] BGP - VPN BoF session in Kilo design summit
Hello, it seems like the BGP dynamic routing it is in a good shape to be included in Neutron during Kilo[1]. There is quite interest in offer BGP-VPN too. Mathieu Rohon's spec[2] goes in this direction. Of course it makes sense that his development leverages the BGP one. I would like to have a BoF session and invite anyone interested on these blueprints to join us or even add a new related one. I've created an etherpad[3] to share ideas and agree with session schedule. I propose Wednesday afternoon. If Carl Baldwin is agree, we can talk about it also during the open discussion of today's L3 subteam meeting. [1]: https://review.openstack.org/#/c/125401/ [ 2]: https://review.openstack.org/#/c/125401/ [3]: https://etherpad.openstack.org/p/bgp-vpn-dynamic-routing Cheers, -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Raising priority for Dynamic Routing
Sorry, I forgot to tag the subject. On 28 August 2014 16:24, Jaume Devesa wrote: > I would like to ask you consider to raise priority from low to medium (I > completely > understand this is not a high priority feature) the BGP Dynamic Routing > feature > (https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing). > > The feature has just 3 patches. > > * https://review.openstack.org/#/c/115554/ > * https://review.openstack.org/#/c/115667/ > * https://review.openstack.org/#/c/115938/ > > ready since last week. > > It has been proposed as one of the extensions to include in the Neutron > Incubator > project. I'm sorry but I ignore the status of the rest proposed > extensions, but I would > be happy to collaborate in anything to include it there as first > experimental extension. > > Cheers, > -- > Jaume Devesa > Software Engineer at Midokura > -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Raising priority for Dynamic Routing
I would like to ask you consider to raise priority from low to medium (I completely understand this is not a high priority feature) the BGP Dynamic Routing feature (https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing). The feature has just 3 patches. * https://review.openstack.org/#/c/115554/ * https://review.openstack.org/#/c/115667/ * https://review.openstack.org/#/c/115938/ ready since last week. It has been proposed as one of the extensions to include in the Neutron Incubator project. I'm sorry but I ignore the status of the rest proposed extensions, but I would be happy to collaborate in anything to include it there as first experimental extension. Cheers, -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] static IP & DHCP
Hello Sanjivini, How are trying to do it? Creating a port with static ip: $ neutron port-create --fixed-ip subnet_id=,ip_address=10.0.0.100 and then deploy a vm with this port, should work: $ nova boot --flavor 1 --image --nic port-id= test_vm Please note that this is an usage question and this is the development list. Can you please send the mail to *openst...@lists.openstack.org * next time? On 27 August 2014 15:49, Sanjivini Naikar wrote: > Hi, > > I want to assign static IP to my instance. However, when trying to do so, > the IP doesnt get associated with the VM. My VM boot logs show: > > Sending discover... > Sending discover... > Sending discover... > No lease, failing > > WARN: /etc/rc3.d/S40-network failed > > How do I assign a static IP to my VM? > > > Regards, > Sanjivini Naikar > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][third-party] Midokura Third-Party CI Status
Hello, today we realised that the Midokura third party jenkins was down and didn't vote for new patches. Apologies. Lucas (who is in charge of this) is in vacations and I'm fighting another wars... Now it should work again as expected, although we have cleaned the queue to don't overload our server. Cheers, -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] BGP dynamic routing testing.
Hi! In the last L3 subteam meeting I was asked to write a document in the wiki to explain how to test the Dynamic Routing feature while is under review. The wiki page is here[1]. I've also moved the DynamicRoutingUseCases wiki page as a child of the DynamicRouting topic. I plan to add more documentation in the next days and I like to have it hierarchically sorted... Just let me know if something is not clear enough. Regards, jaume [1]: https://wiki.openstack.org/wiki/Neutron/DynamicRouting/TestingDynamicRouting -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Problems with new Neutron service plugin
Maciej: have you loaded the service plugin in the neutron.conf? service_plugins = neutron.services.l3_router.l3_router_plugin.L3RouterPlugin,neutron.services.loadbalancer.plugin.LoadBalancerPlugin,neutron.services.floatingports.FloatingPort Neutron needs to know what plugins to load at start up time to expose the extensions... RESOURCE_ATTRIBUTE_MAP key is called 'redirections', it should be called 'floatingports'. And when you call resource_helper.build_resource_info you are using constants.FIREWALL. Should be 'floatingport' (the plugin type or the plugin name you defined in 'FloatingPortPluginBase', not sure which one. In your case it does not matter because is the same value). You have to add also the value 'floatingport' in the neutron.plugins.common.constants.COMMON_PREFIXES dictionary. The definition of the method get_floatingports should use the 'filters' attribute instead of the 'id' one: def get_floatingports(self, context, filters=None, fields=None) And the rest is up to you! Hope this helps. On 29 July 2014 11:51, Kashyap Chamarthy wrote: > On Tue, Jul 29, 2014 at 11:15:45AM +0200, Maciej Nabożny wrote: > > [Just a generic comment, not related to the extension code in question.] > > > Yes, here is extension code: > > http://pastebin.com/btYQjwnr > > service plugin code: > > http://pastebin.com/ikKf80Fr > > Pastebins expire, it's useful to provide URLs that are accessible for > much longer times, so that anyone who refers to this email months later > will still be able to access the code in question. > > -- > /kashyap > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Problems with new Neutron service plugin
Hello Maciej,
can I see your code somewhere? I have written an extension recently and I
might can help you. The blog post is quite similar of what I've done, so
you should be close to get it work.
Regards,
jaume
On 29 July 2014 08:28, Maciej Nabożny wrote:
> Hello!
> This is my first mail on this mailing list, so - hello everybody :)
>
> I'm trying to write extension and service plugin for Neutron, which adds
> support for something like "floating port". This should be dnat/snat
> service for virtual machines. I was following this tutorial:
>
> http://control-that-vm.blogspot.in/2014/05/writing-
> api-extensions-in-neutron.html?view=flipcard
>
> I have created extension with some resources (RESOURCE_ATTRIBUTE_MAP) and
> service plugin for it. In logs, neutron says, that extension is working and
> it has backend (service plugin). It is also listed in extension list
> through neutron api. The only problem, which I have is how to access my
> functions. As far as I understand, it should work in this way:
> - GET /v2.0/floatingport/ calls function get_floatingport(...)
> - GET /v2.0/floatingports/id/ calls function get_floatingports(...)
> and so on for all CRUD methods. Could you tell me how should I register
> this functions to be available in neutron's api? Each time when I call GET
> /v2.0/gloatingport/ i got 404. The same is through neutronclient python
> module with:
> c.do_request('GET', '/floatingip')
> I have also tried to paste all my methods to ml2 plugin, but also they are
> not accessible through api.
>
> I will be grateful for your help
> Regards!
> Maciek
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Jaume Devesa
Software Engineer at Midokura
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Neutron IPv6 in Icehouse and further
Hello Maksym, last week I had more or less the same questions than you and I investigate a little bit... Currently we have the *ipv6_ra_mode *and *ipv6_address_mode *in the subnet entity. The way you combine these two values will determine how and who will configure your VM´s IPv6 addresses. Not all the combinations are possible. This document[1] and the *upstream-slaac-support* *spec*[2] provide the possible combinations. Not sure which one is more updated... If you want to try IPv6 current support, you can use the Baodong Li's devstack patch [3], although is still in development. Follow the message commit instructions to provide a radvd daemon. That means that there is no RA advertiser in Neutron currently. There is a *spec* in review[4] to fill this gap. The changes for allow DHCPv6 in dnsmasq are in review in this patch[5]. This is what I found... I hope some IPv6 folks can correct me if this information is not accurate enough (or wrong) [1]: https://www.dropbox.com/s/9bojvv9vywsz8sd/IPv6%20Two%20Modes%20v3.0.pdf [2]: http://docs-draft.openstack.org/43/88043/9/gate/gate-neutron-specs-docs/82c251a/doc/build/html/specs/juno/ipv6-provider-nets-slaac.html [3]: https://review.openstack.org/#/c/87987 [4]: https://review.openstack.org/#/c/101306/ [5]: https://review.openstack.org/#/c/70649/ On 27 June 2014 00:51, Martinx - ジェームズ wrote: > Hi! I'm waiting for that too... > > Currently, I'm running IceHouse with static IPv6 address, with the > topology "VLAN Provider Networks" and, to make it easier, I'm counting on > the following blueprint: > > https://blueprints.launchpad.net/neutron/+spec/ipv6-provider-nets-slaac > > ...but, I'm not sure if it will be enough to enable basic IPv6 support > (without using Neutron as Instance's default gateway)... > > Cheers! > Thiago > > > On 26 June 2014 19:35, Maksym Lobur wrote: > >> Hi Folks, >> >> Could you please tell what is the current state of IPv6 in Neutron? Does >> it have DHCPv6 working? >> >> What is the best point to start hacking from? Devstack stable/icehouse or >> maybe some tag? Are there any docs / raw deployment guides? >> I see some patches not landed yet [1] ... I assume it won't work without >> them, right? >> >> Somehow I can't open any of the code reviews from the [2] (Not Found) >> >> [1] >> https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:%255E.*%255Cipv6.*,n,z >> [2] https://wiki.openstack.org/wiki/Neutron/IPv6 >> >> Best regards, >> Max Lobur, >> Python Developer, Mirantis, Inc. >> >> Mobile: +38 (093) 665 14 28 >> Skype: max_lobur >> >> 38, Lenina ave. Kharkov, Ukraine >> www.mirantis.com >> www.mirantis.ru >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Change in openstack/neutron-specs[master]: BGP dynamic routing
Hi Keshava, I'm afraid that your use case is out of the scope of this bp. We have thought only to provide admin API to share external/provider network routes. Due IP ranges overlapping, share tenant networks won't be able with my approach. However, I find that after BGP will be implemented, with a few changes (as let the user create RoutingInstance entities, add tenant_id field in that entity and use underlaying VPN technology), your use case would be feasible. Take a look at Nachi Ueno's spec: https://review.openstack.org/#/c/93329/ I think is so close to your proposal. Regards, jaume On 25 June 2014 19:51, A, Keshava wrote: > Hi, > > > > If BGP can export its private-IP to upstream they can be placed in the > corresponding VRF table w.r.t that VPN. > > In the below example Geographically separated Data-center hosts same > Customers (Red, Blue Customer). > > If BGP from virtual Network exports its IP to upstream BGP VRF table (of > that VPN), then from there using carrier’s carrier mechanism , BGP will > carry respective VRF route entries to remote site BGP Routing table. > > During packet forwarding from remote-site , the remote router will look > into its corresponding VRF table entries to check where is the destination > for that IP. > > Based on the packet will be forwarded on respective VPN tunnel . > > > > *So private-IP should be advertised by BGP from the cloud under that > respective VRF (VPN).* > > > > Thanks ®ards, > > Keshava > > > > -Original Message- > From: Jaume Devesa (Code Review) [mailto:rev...@openstack.org] > Sent: Wednesday, June 25, 2014 3:06 PM > To: Artem Dmytrenko > Cc: Baldwin, Carl (OpenStack Neutron); mark mcclain; Sean M. Collins; > Anthony Veiga; Pedro Marques; Nachi Ueno; YAMAMOTO Takashi; Itsuro Oda; > fumihiko kakuma; A, Keshava > Subject: Change in openstack/neutron-specs[master]: BGP dynamic routing > > > > Jaume Devesa has posted comments on this change. > > > > Change subject: BGP dynamic routing > > .. > > > > > > Patch Set 8: > > > > (3 comments) > > > > Hi keshava, > > > > I've tried to answer your questions, but I am not confident about your use > case. Can you explain me, please? Or ping me anytime at irc (my nickname is > devvesa) > > > > https://review.openstack.org/#/c/90833/8/specs/juno/bgp-dynamic-routing.rst > > File specs/juno/bgp-dynamic-routing.rst: > > > > Line 120: namespace in the compute node. > > > Please make it clear: If DVR is turned-on BGP can be enabled or not ? > > BGP can be enabled. However, I think this paragraph crosses concepts that > may confuse people. I will delete in the next patch. > > > > > > Line 123: to an upstream router. It does not require learning routes from > the upstream > > > Is it possible how to block learning from upstream peer router ? > > Yes, is absolutely configurable. If you see the RoutingInstance entity > down below, you will see that you can choose either you want to learn or > advertise the routes . > > > > > > Line 159: Overview > > > Is it possible to enabled BGP only on private IP address ? > > With the RoutingInstance entity, you put together: > > > > 1. Which peers you want to connect > > 2. Which networks are involved > > 3. Whether to enable/disable discovery AND advertise of routes. > > > > Also, you will be able to add advertise routes manually. > > > > So theoretically, you will be able to advertise a private IP address, > although I can not see the use case of this. > > > > > > -- > > To view, visit https://review.openstack.org/90833 > > To unsubscribe, visit https://review.openstack.org/settings > > > > Gerrit-MessageType: comment > > Gerrit-Change-Id: I41b66c1c3083d7c8205368353302fafdb7a110c8 > > Gerrit-PatchSet: 8 > > Gerrit-Project: openstack/neutron-specs > > Gerrit-Branch: master > > Gerrit-Owner: Artem Dmytrenko > > Gerrit-Reviewer: Anthony Veiga > > Gerrit-Reviewer: Artem Dmytrenko > > Gerrit-Reviewer: Carl Baldwin > > Gerrit-Reviewer: Itsuro Oda > > Gerrit-Reviewer: Jaume Devesa > > Gerrit-Reviewer: Jenkins > > Gerrit-Reviewer: Nachi Ueno > > Gerrit-Reviewer: Pedro Marques > > Gerrit-Reviewer: Sean M. Collins > > Gerrit-Reviewer: YAMAMOTO Takashi > > Gerrit-Reviewer: fumihiko kakuma > > Gerrit-Reviewer: keshava > > Gerrit-Reviewer: mark mcclain > > Gerrit-HasComments: Yes > -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][Third-Party][Infra] Optimize third party resources
Anita, thanks for the response. My comments inline: > Well then we are in a situation where development ceases until the third > party systems respond. Which is not a situation we want to put ourselves > in. We actually are actively avoiding that situation. > > I don't mean to run after the change is merged, but after is verified, which is the first step. And I don't mean neither that they should vote. So I don't see that means the development ceases until the third party respond... The failure on the '.' at the end of the commit title is a style test, > not something the third party tests would run anyway. > Absolutely agree. My point is that third party have had to run two times: one before the '.' patch and the other one after. And third party opinion is worthless if Jenkins says -1. Just want to avoid the first run. > Thanks, > Anita. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > Regards, -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][Third-Party][Infra] Optimize third party resources
Hello all, I've just submitted a patch[1] to solve a bug in Neutron. All the third-party plugins has voted as +1 but Jenkins has refused the patch because of the '.' dot at the end of the commit summary line. I know that is my fault, because I should run the ./run_tests.sh -p after modify the commit message, but: since the official Jenkins runs more gates, tests and checks than the rest of third-party Jenkins, wouldn't be better to run third party jobs after official Jenkins has verified the patch? I think that would relax the load on the third party infrastructures and maybe they can be more reactive in the 'good' patches. [1]: https://review.openstack.org/#/c/99679/2 -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
After watch the documentation and the code of *exabgp* and *Ryu*, I find the *Ryu* speaker much more easy to integrate and pythonic than *exabgp*. I will use it as well as reference implementation in the Dynamic Routing bp. Regards, On 5 June 2014 18:23, Nachi Ueno wrote: > > Yamamoto > Cool! OK, I'll make ryu based bgpspeaker as ref impl for my bp. > > >Yong > Ya, we have already decided to have the driver architecture. > IMO, this discussion is for reference impl. > > 2014-06-05 0:24 GMT-07:00 Yongsheng Gong : > > I think maybe we can device a kind of framework so that we can plugin > > different BGP speakers. > > > > > > On Thu, Jun 5, 2014 at 2:59 PM, YAMAMOTO Takashi > > > wrote: > >> > >> hi, > >> > >> > ExaBgp was our first choice because we thought that run something in > >> > library mode would be much more easy to deal with (especially the > >> > exceptions and corner cases) and the code would be much cleaner. But > >> > seems > >> > that Ryu BGP also can fit in this requirement. And having the help > from > >> > a > >> > Ryu developer like you turns it into a promising candidate! > >> > > >> > I'll start working now in a proof of concept to run the agent with > these > >> > implementations and see if we need more requirements to compare > between > >> > the > >> > speakers. > >> > >> we (ryu team) love to hear any suggestions and/or requests. > >> we are currently working on our bgp api refinement and documentation. > >> hopefully they will be available early next week. > >> > >> for both of bgp blueprints, it would be possible, and might be > desirable, > >> to create reference implementations in python using ryu or exabgp. > >> (i prefer ryu. :-) > >> > >> YAMAMOTO Takashi > >> > >> ___ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
Hello Takashi, thanks for doing this! As we have proposed ExaBgp[1] in the Dynamic Routing blueprint[2], I've added a new column for this speaker in the wiki page. I plan to fill it soon. ExaBgp was our first choice because we thought that run something in library mode would be much more easy to deal with (especially the exceptions and corner cases) and the code would be much cleaner. But seems that Ryu BGP also can fit in this requirement. And having the help from a Ryu developer like you turns it into a promising candidate! I'll start working now in a proof of concept to run the agent with these implementations and see if we need more requirements to compare between the speakers. [1]: https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison [2]: https://review.openstack.org/#/c/90833/ Regards, On 29 May 2014 18:42, YAMAMOTO Takashi wrote: > as per discussions on l3 subteem meeting today, i started > a bgp speakers comparison wiki page for this bp. > > https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison > > Artem, can you add other requirements as columns? > > as one of ryu developers, i'm naturally biased to ryu bgp. > i appreciate if someone provides more info for other bgp speakers. > > YAMAMOTO Takashi > > > Good afternoon Neutron developers! > > > > There has been a discussion about dynamic routing in Neutron for the > past few weeks in the L3 subteam weekly meetings. I've submitted a review > request of the blueprint documenting the proposal of this feature: > https://review.openstack.org/#/c/90833/. If you have any feedback or > suggestions for improvement, I would love to hear your comments and include > your thoughts in the document. > > > > Thank you. > > > > Sincerely, > > Artem Dmytrenko > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Introducing task oriented workflows
presented? The main options are to either >> have >> > a new attribute describing the resource sync state, or to extend the >> > semantics of the current status attribute to include also resource sync >> > state. I've put some rumblings on the subjects in the etherpad [3]. >> > Still, it has been correctly pointed out that it might not be enough to >> know >> > that a resource is out of sync, but it is good to know which operation >> > exactly failed; this is where exposing somehow tasks through the API >> might >> > come handy. >> > >> > For instance one could do something like: >> > >> > GET /tasks?resource_id=&task_state=FAILED >> > >> > to get failure details for a given resource. >> > >> > --> How to proceed >> > >> > This is where I really don't know... and I will therefore be brief. >> > We'll probably need some more brainstorming to flush out all the >> details. >> > Once that is done, it might the case of evaluating what needs to be >> done and >> > whether it is better to target this work onto existing plugins, or >> moving it >> > out to v3 plugins (and hence do the actual work once the "core >> refactoring" >> > activities are complete). >> > >> > Regards, >> > Salvatore >> > >> > >> > [1] https://etherpad.openstack.org/p/integrating-task-into-neutron >> > [2] http://paste.openstack.org/show/81184/ >> > [3] https://etherpad.openstack.org/p/sillythings >> > >> > >> > >> > >> > ___ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Updates to the template for Neutron BPs
Great! Thanks Anne! On 22 April 2014 16:44, Anne Gentle wrote: > > > > On Tue, Apr 22, 2014 at 4:42 AM, Jaume Devesa wrote: > >> Another question about this, Kyle: >> >> once merged, will there be a place where to read these approved specs, or >> should we run it locally? I tried to find the approved *nova-specs *in >> docs.openstack.org, but I couldn't find them. >> >> > Hi Jaume, > Since these are specifications and not created features (yet), they will > not be published on docs.openstack.org but on specs.openstack.org/$project > . > > See http://markmail.org/message/du6djpz3unbdgzpm for more details. I > don't believe the site is set up quite yet. > > Thanks, > Anne > > > >> Regards, >> jaume >> >> >> On 21 April 2014 09:02, Mandeep Dhami wrote: >> >>> >>> Got it. Thanks. >>> >>> Regards, >>> Mandeep >>> >>> >>> On Sun, Apr 20, 2014 at 11:49 PM, Mike Scherbakov < >>> mscherba...@mirantis.com> wrote: >>> >>>> That's because spec was proposed to the juno/ folder. Look at >>>> https://raw.githubusercontent.com/openstack/neutron-specs/master/doc/source/index.rst, >>>> if spec is in juno/ folder, then contents shows it as approved one. >>>> >>>> Once merged, it means approved, right? So it is going to be Ok after >>>> merge. Though a better reminding than just "draft" in the url could be >>>> required if many start to mess it up... >>>> >>>> >>>> On Mon, Apr 21, 2014 at 10:43 AM, Kevin Benton wrote: >>>> >>>>> Yes. It shows up in the approved section since it's just a build of >>>>> the patch as-is. >>>>> >>>>> The link is titled gate-neutron-specs-docs in the message from Jenkins. >>>>> >>>>> -- >>>>> Kevin Benton >>>>> >>>>> >>>>> On Sun, Apr 20, 2014 at 11:37 PM, Mandeep Dhami < >>>>> dh...@noironetworks.com> wrote: >>>>> >>>>>> Just for clarification. Jenkins link in the description puts the >>>>>> generated HTML in the section "Juno approved specs" even tho' the >>>>>> blueprint is still being reviewed. Am I looking at the right link? >>>>>> >>>>>> Regards, >>>>>> Mandeep >>>>>> >>>>>> >>>>>> On Sun, Apr 20, 2014 at 10:54 PM, Mike Scherbakov < >>>>>> mscherba...@mirantis.com> wrote: >>>>>> >>>>>>> Yes, thanks, that's exactly what I was looking for! >>>>>>> >>>>>>> >>>>>>> On Mon, Apr 21, 2014 at 12:03 AM, Kyle Mestery < >>>>>>> mest...@noironetworks.com> wrote: >>>>>>> >>>>>>>> On Sat, Apr 19, 2014 at 5:11 PM, Mike Scherbakov >>>>>>>> wrote: >>>>>>>> > Hi Kyle, >>>>>>>> > I built template and it looks awesome. We are considering to use >>>>>>>> same >>>>>>>> > approach for Fuel. >>>>>>>> > >>>>>>>> > My assumption is that spec will be on review for a negotiation >>>>>>>> time, which >>>>>>>> > is going to be quite a while. In my opinion, it is not always very >>>>>>>> > convenient to read spec in gerrit. >>>>>>>> > >>>>>>>> Agreed, though for some specs, this is actually an ok way to do >>>>>>>> reviews. >>>>>>>> >>>>>>>> > Did you guys have any thoughts on auto-build these specs into >>>>>>>> html on every >>>>>>>> > patch upload? So we could go somewhere and see built results, >>>>>>>> without a >>>>>>>> > requirement to fetch neutron-specs, and run tox? The possible >>>>>>>> drawback is >>>>>>>> > that reader won't see gerrit comments.. >>>>>>>> > >>>>>>>> I followed what Nova was going and committed code into >>>>>>>> openstack-infra/config which allows for some jenkins jobs to run >>>>>>>> when >>>>>&g
Re: [openstack-dev] [neutron] Updates to the template for Neutron BPs
Another question about this, Kyle: once merged, will there be a place where to read these approved specs, or should we run it locally? I tried to find the approved *nova-specs *in docs.openstack.org, but I couldn't find them. Regards, jaume On 21 April 2014 09:02, Mandeep Dhami wrote: > > Got it. Thanks. > > Regards, > Mandeep > > > On Sun, Apr 20, 2014 at 11:49 PM, Mike Scherbakov < > mscherba...@mirantis.com> wrote: > >> That's because spec was proposed to the juno/ folder. Look at >> https://raw.githubusercontent.com/openstack/neutron-specs/master/doc/source/index.rst, >> if spec is in juno/ folder, then contents shows it as approved one. >> >> Once merged, it means approved, right? So it is going to be Ok after >> merge. Though a better reminding than just "draft" in the url could be >> required if many start to mess it up... >> >> >> On Mon, Apr 21, 2014 at 10:43 AM, Kevin Benton wrote: >> >>> Yes. It shows up in the approved section since it's just a build of the >>> patch as-is. >>> >>> The link is titled gate-neutron-specs-docs in the message from Jenkins. >>> >>> -- >>> Kevin Benton >>> >>> >>> On Sun, Apr 20, 2014 at 11:37 PM, Mandeep Dhami >> > wrote: >>> Just for clarification. Jenkins link in the description puts the generated HTML in the section "Juno approved specs" even tho' the blueprint is still being reviewed. Am I looking at the right link? Regards, Mandeep On Sun, Apr 20, 2014 at 10:54 PM, Mike Scherbakov < mscherba...@mirantis.com> wrote: > Yes, thanks, that's exactly what I was looking for! > > > On Mon, Apr 21, 2014 at 12:03 AM, Kyle Mestery < > mest...@noironetworks.com> wrote: > >> On Sat, Apr 19, 2014 at 5:11 PM, Mike Scherbakov >> wrote: >> > Hi Kyle, >> > I built template and it looks awesome. We are considering to use >> same >> > approach for Fuel. >> > >> > My assumption is that spec will be on review for a negotiation >> time, which >> > is going to be quite a while. In my opinion, it is not always very >> > convenient to read spec in gerrit. >> > >> Agreed, though for some specs, this is actually an ok way to do >> reviews. >> >> > Did you guys have any thoughts on auto-build these specs into html >> on every >> > patch upload? So we could go somewhere and see built results, >> without a >> > requirement to fetch neutron-specs, and run tox? The possible >> drawback is >> > that reader won't see gerrit comments.. >> > >> I followed what Nova was going and committed code into >> openstack-infra/config which allows for some jenkins jobs to run when >> we commit to the neutron-specs gerrit. [1]. As an example, look at >> this commit here [2]. If you look at the latest Jenkins run, you'll >> see a link which takes you to an HTML generated document [3] which you >> can review in lieu of the raw restructured text in gerrit. That will >> actually generate all the specs in the repository, so you'll see the >> "Example Spec" along with the Nuage one I used for reference here. >> >> Hope that helps! >> Kyle >> >> [1] https://review.openstack.org/#/c/88069/ >> [2] https://review.openstack.org/#/c/88690/ >> [3] >> http://docs-draft.openstack.org/90/88690/3/check/gate-neutron-specs-docs/fe4282a/doc/build/html/ >> >> > Thanks, >> > >> > >> > On Sat, Apr 19, 2014 at 12:08 AM, Kyle Mestery < >> mest...@noironetworks.com> >> > wrote: >> >> >> >> Hi folks: >> >> >> >> I just wanted to let people know that we've merged a few patches >> [1] >> >> to the neutron-specs repository over the past week which have >> updated >> >> the template.rst file. Specifically, Nachi has provided some >> >> instructions for using Sphinx diagram tools in lieu of >> asciiflow.com. >> >> Either approach is fine for any Neutron BP submissions, but Nachi's >> >> patch has some examples of using both approaches. Bob merged a >> patch >> >> which shows an example of defining REST APIs with attribute tables. >> >> >> >> Just an update for anyone proposing BPs for Juno at the moment. >> >> >> >> Thanks! >> >> Kyle >> >> >> >> [1] >> >> >> https://review.openstack.org/#/q/status:merged+project:openstack/neutron-specs,n,z >> >> >> >> ___ >> >> OpenStack-dev mailing list >> >> OpenStack-dev@lists.openstack.org >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > >> > >> > -- >> > Mike Scherbakov >> > #mihgen >> > >> > ___ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >>>
Re: [openstack-dev] [all] Branchless Tempest QA Spec - final draft
I thought that OpenStack just support one release backwards, if we have to support three versions, this is not useful. There are already ways to enable/disable modules in tempest to adapt to each deployment needs. Just wanted to avoid more configuration options. On 16 April 2014 21:14, David Kranz wrote: > On 04/16/2014 11:48 AM, Jaume Devesa wrote: > > Hi Sean, > > for what I understood, we will need a new feature flag for each new > feature, and a feature flag (default to false) for each deprecated one. My > concern is: since the goal is make tempest a confident tool to test any > installation and not and 'tempest.conf' will not be auto-generated from any > tool as devstack does, wouldn't be too hard to prepare a tempest.conf file > with so many feature flags to enable and disable? > > If we go down this route, and I think we should, we probably need to > accept that it will be hard for users to manually configure tempest.conf. > Tempest configuration would have to be done by whatever installation > technology was used, as devstack does, or by auto-discovery. That implies > that the presence of new features should be discoverable through the api > which is a good idea anyway. Of course some one could configure it manually > but IMO that is not desirable even with where we are now. > > > Maybe I am simplifying too much, but wouldn't be enough with a pair of > functions decorators like > > @new > @deprecated > > Then, in tempest.conf it could be a flag to say which OpenStack > installation are you testing: > > installation = [icehouse|juno] > > if you choose Juno, tests with @new decorator will be executed and tests > with @deprecated will be skipped. > If you choose Icehouse, tests with @new decorator will be skipped, and > tests with @deprecated will be executed > > I am missing some obvious case that make this approach a nonsense? > > There are two problems with this. First, some folks are chasing master for > their deployments and some do not deploy all the features that are set up > by devstack. In both cases, it is not possible to identify what can be > tested with a simple name that corresponds to a stable release. Second, > what happens when we move on to K? The meaning of "new" would have to > change while retaining its old meaning as well which won't work. I think > Sean spelled out the important scenarios. > > -David > > > Regards, > jaume > > > On 14 April 2014 15:21, Sean Dague wrote: > >> As we're coming up on the stable/icehouse release the QA team is looking >> pretty positive at no longer branching Tempest. The QA Spec draft for >> this is here - >> >> http://docs-draft.openstack.org/77/86577/2/check/gate-qa-specs-docs/3f84796/doc/build/html/specs/branchless-tempest.html >> and hopefully address a lot of the questions we've seen so far. >> >> Additional comments are welcome on the review - >> https://review.openstack.org/#/c/86577/ >> or as responses on this ML thread. >> >> -Sean >> >> -- >> Sean Dague >> Samsung Research America >> s...@dague.net / sean.da...@samsung.com >> http://dague.net >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > ___ > OpenStack-dev mailing > listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Branchless Tempest QA Spec - final draft
Hi Sean, for what I understood, we will need a new feature flag for each new feature, and a feature flag (default to false) for each deprecated one. My concern is: since the goal is make tempest a confident tool to test any installation and not and 'tempest.conf' will not be auto-generated from any tool as devstack does, wouldn't be too hard to prepare a tempest.conf file with so many feature flags to enable and disable? Maybe I am simplifying too much, but wouldn't be enough with a pair of functions decorators like @new @deprecated Then, in tempest.conf it could be a flag to say which OpenStack installation are you testing: installation = [icehouse|juno] if you choose Juno, tests with @new decorator will be executed and tests with @deprecated will be skipped. If you choose Icehouse, tests with @new decorator will be skipped, and tests with @deprecated will be executed I am missing some obvious case that make this approach a nonsense? Regards, jaume On 14 April 2014 15:21, Sean Dague wrote: > As we're coming up on the stable/icehouse release the QA team is looking > pretty positive at no longer branching Tempest. The QA Spec draft for > this is here - > > http://docs-draft.openstack.org/77/86577/2/check/gate-qa-specs-docs/3f84796/doc/build/html/specs/branchless-tempest.html > and hopefully address a lot of the questions we've seen so far. > > Additional comments are welcome on the review - > https://review.openstack.org/#/c/86577/ > or as responses on this ML thread. > > -Sean > > -- > Sean Dague > Samsung Research America > s...@dague.net / sean.da...@samsung.com > http://dague.net > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] "Auto-created ports count against port quota" bug status
Hello all, I have the following bug assigned for icehouse~3 milestone: https://bugs.launchpad.net/neutron/+bug/1212338 I proposed a (maybe too much) trivial solution in the launchpad comments, but I haven't received a confirmation that solution would solve the issue. Could a more experienced neutron developer confirm me that is the path to follow or propose another one, please? Thanks! -- Jaume Devesa ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Blueprint -- Floating IP Auto Association
Hi all, I see it has been passed two weeks since first mail in this thread and that blueprint still without assignee. I also think this is a good option for my first blueprint. However, I can not assign blueprints to myself, only bugs. Can anybody assign to me? Steven: if you still interested in it, please tell us. You asked for it first and it will be yours. Regards On 5 November 2013 07:21, Salvatore Orlando wrote: > I don't think there has been any development in the past 6 months. > A few people have shown interest in it in the past, but the blueprint has > currently no assignee. > So If you want to work on it, feel free to assign to yourself. > > To quickly sum up the discussion around this blueprint, it could be > implemented in two ways: > - providing automation in the neutron API (creating the floating IP > together with the port) > - automating the operation on the orchestration side (nova-api in this > case). > > There are pro and cons in both solutions. In my humble opinion, the only > thing I would care of is that the existing operation in the Neutron API > stay "atomic" as they are. > > Regards, > Salvatore > > > On 30 October 2013 08:46, Steven Weston wrote: > >> Does anybody know what the status of this Blueprint is? >> https://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ip >> >> >> >> I am new to the neutron developer community and I am looking for a first >> project – this might be a good place to start. But the last update was in >> March of this year, so I don’t know if the specifications have been locked >> down yet. >> >> >> >> Anybody? >> >> >> >> Thanks! >> >> Steven Weston >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] New Nova hypervisor: Docker
Hi Sam, that's a great work and it will be for sure my default driver for my development environment. I have a question: once the review will be approved and the code merged into master, do you plan to create a driver nova subteam as Xen, HyperV and others do? I would be glad to cooperate on it. On 29 August 2013 07:54, Sam Alba wrote: > On Wed, Aug 28, 2013 at 9:12 AM, Sam Alba wrote: > > Thanks a lot everyone for the nice feedback. I am going to work hard > > to get all those new comments addressed to be able to re-submit a new > > patchset today or tomorrow (the later). > > > > On Wed, Aug 28, 2013 at 7:02 AM, Russell Bryant > wrote: > >> On 08/28/2013 05:18 AM, Daniel P. Berrange wrote: > >>> On Wed, Aug 28, 2013 at 06:00:50PM +1000, Michael Still wrote: > On Wed, Aug 28, 2013 at 4:18 AM, Sam Alba wrote: > > Hi all, > > > > We've been working hard during the last couple of weeks with some > > people. Brian Waldon helped a lot designing the Glance integration > and > > driver testing. Dean Troyer helped a lot on bringing Docker support > in > > Devstack[1]. On top of that, we got several feedback on the Nova code > > review which definitely helped to improve the code. > > > > The blueprint[2] explains what Docker brings to Nova and how to use > it. > > I have to say that this blueprint is a fantastic example of how we > should be writing design documents. It addressed almost all of my > questions about the integration. > >>> > >>> Yes, Sam (& any of the other Docker guys involved) have been great at > >>> responding to reviewers' requests to expand their design document. The > >>> latest update has really helped in understanding how this driver works > >>> in the context of openstack from an architectural and functional POV. > >> > >> They've been great in responding to my requests, as well. The biggest > >> thing was that I wanted to see devstack support so that it's easily > >> testable, both by developers and by CI. They delivered. > >> > >> So, in general, I'm good with this going in. It's just a matter of > >> getting the code review completed in the next week before feature > >> freeze. I'm going to try to help with it this week. > >> > > If someone wants to take another look at > https://review.openstack.org/#/c/32960/, we answered/fixed all > previous comments. > > > -- > @sam_alba > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
