Re: [openstack-dev] [Tacker] Proposing changes in Tacker Core Team
+1. Thanks Tacker community for providing the opportunity to server as committer/active contributor. On Wed, Aug 22, 2018 at 9:52 AM Dharmendra Kushwaha < dharmendra.kushw...@india.nec.com> wrote: > Hi Tacker members, > > > > To keep our Tacker project growing with new active members, I would like > > to propose to prune +2 ability of our farmer member Kanagaraj Manickam, > > and propose Cong Phuoc Hoang (IRC: phuoc) to join the tacker core team. > > > > Kanagaraj is not been involved since last couple of cycle. You had a great > > Contribution in Tacker project like VNF scaling features which are > milestone > > for project. Thanks for your contribution, and wish to see you again. > > > > Phuoc is contributing actively in Tacker from Pike cycle, and > > he has grown into a key member of this project [1]. He delivered multiple > > features in each cycle. Additionally tons of other activities like bug > fixes, > > answering actively on bugs. He is also actively contributing in cross > project > > like tosca-parser and heat-translator which is much helpful for Tacker. > > > > Please vote your +1/-1. > > > > [1]: > http://stackalytics.com/?project_type=openstack&release=all&metric=commits&module=tacker-group&user_id=hoangphuoc > > > > Thanks & Regards > > Dharmendra Kushwaha > __ > 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
Re: [openstack-dev] [tacker] December 28th weekly meeting cancelled
Happy christmas & new year 2017. Thanks & Regards Kanagaraj M On Dec 21, 2016 1:18 PM, "Sridhar Ramaswamy" wrote: We are skipping next week's Tacker meeting, on Dec 28th [1]. We will resume on Jan 4th. Happy Holidays!! [1] http://eavesdrop.openstack.org/meetings/tacker/ 2016/tacker.2016-12-21-05.30.log.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 __ 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] [tacker] Proposing Yong Sheng Gong for Tacker core team
+1. Congrats yong. Thanks & Regards Kanagaraj M On Aug 27, 2016 2:12 AM, "Sridhar Ramaswamy" wrote: We have enough votes to proceed. Yong - welcome to the Tacker core team! - Sridhar On Tue, Aug 23, 2016 at 12:06 PM, Stephen Wong wrote: > +1 > > On Tue, Aug 23, 2016 at 8:55 AM, Sridhar Ramaswamy > wrote: > >> Tackers, >> >> I'd like to propose Yong Sheng Gong to join the Tacker core team. Yong is >> a seasoned OpenStacker and has been contributing to Tacker project since >> Nov 2015 (early Mitaka). He has been the major force in helping Tacker to >> shed its *Neutronisms*. He has low tolerance on unevenness in the code >> base and he fixes them as he goes. Yong also participated in the Enhanced >> Placement Awareness (EPA) blueprint in the Mitaka cycle. For Newton he took >> up himself cleaning up the DB schema and in numerous reviews to keep the >> project going. He has been a dependable member of the Tacker community [1]. >> >> Please chime in with your +1 / -1 votes. >> >> thanks, >> Sridhar >> >> [1] http://stackalytics.com/report/contribution/tacker/90 >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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
Re: [openstack-dev] [tacker] Proposing Kanagaraj Manickam to Tacker core team
Sridhar, Thank you for nominating me as tacker core-reviewer. Tacker Core team, Thanks for appreciating my contributions in tacker and It's my pleasure to be part of the core-team. Regards Kanagaraj M On Mon, Jun 20, 2016 at 4:51 PM, Sridhar Ramaswamy wrote: > Thanks for the responses, I'm closing the vote. > > Kanagaraj - welcome to the Tacker core team! > > On Sun, Jun 19, 2016 at 7:25 PM, bharath thiruveedula < > bharath_...@hotmail.com> wrote: > >> +1 >> -- >> To: openstack-dev@lists.openstack.org >> From: bob.haddle...@nokia.com >> Date: Fri, 17 Jun 2016 12:12:13 -0500 >> >> Subject: Re: [openstack-dev] [tacker] Proposing Kanagaraj Manickam to >> Tacker core team >> >> +1. Kanagaraj will be a great addition to the team. >> >> Bob >> >> On 6/16/2016 1:45 PM, Karthik Natarajan wrote: >> >> +1. Thanks Kanagaraj for making such a great impact during the Newton >> cycle. >> >> >> >> *From:* Sripriya Seetharam [mailto:ssee...@brocade.com >> ] >> *Sent:* Thursday, June 16, 2016 10:35 AM >> *To:* OpenStack Development Mailing List (not for usage questions) >> >> *Subject:* Re: [openstack-dev] [tacker] Proposing Kanagaraj Manickam to >> Tacker core team >> >> >> >> +1 >> >> >> >> >> >> -Sripriya >> >> >> >> >> >> *From:* Sridhar Ramaswamy [mailto:sric...@gmail.com ] >> *Sent:* Wednesday, June 15, 2016 6:32 PM >> *To:* OpenStack Development Mailing List (not for usage questions) < >> openstack-dev@lists.openstack.org> >> *Subject:* [openstack-dev] [tacker] Proposing Kanagaraj Manickam to >> Tacker core team >> >> >> >> Tackers, >> >> It gives me great pleasure to propose Kanagaraj Manickam to join the >> Tacker core team. In a short time, Kanagaraj has grown into a key member of >> the Tacker team. His enthusiasm and dedication to get Tacker code base on >> par with other leading OpenStack projects is very much appreciated. He is >> already working on two important specs in Newton cycle and many more fixes >> and RFEs [1]. Kanagaraj is also a core member in the Heat project and this >> lends well as we heavily use Heat for many Tacker features. >> >> Please provide your +1/-1 votes. >> >> - Sridhar >> >> [1] >> http://stackalytics.com/?module=tacker-group&user_id=kanagaraj-manickam&metric=marks >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__stackalytics.com_-3Fmodule-3Dtacker-2Dgroup-26user-5Fid-3Dkanagaraj-2Dmanickam-26metric-3Dmarks&d=CwMFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=hROKXYYshyJWhFmsb7PFSLyhefOI0B-5pQmhOlAcwa8&m=XTvfSkjsPDJfmRDZdSXZNY1d_bJ74wj1NZaZ5zCOP6o&s=iQMBtQTzCUXg0nRKd1FiB3wC3ChTtDySmzqnoTSDQjU&e=> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
Re: [openstack-dev] [oslo.service] Lifecycle Hooks
ture to oslo.service. > [KanagarajM] we already doing the in-band service deployment discovery for nova, cinder, neutron and heat, which are reported in horizon panel as well under 'system information' panel. When we look at the impl of service discovery in each of these projects, all rpeats the same implementation in each of their repository. Once this is in place, we could enable the auto-discovery of each service deployment without repeating the impl, and those projects also could start to levarage it which releaves a considerable maintenance effort from each of the projects for its deployment discovery. >> >> On Wed, May 11, 2016 at 7:05 PM, Davanum Srinivas >> wrote: >> >> >> >> > Kanagaraj, >> > > >> >> > Who is the first consumer? for what specific purpose? >> >> > >> >> > Thanks, >> >> > Dims >> >> > >> >> > On Wed, May 11, 2016 at 9:27 AM, Kanagaraj Manickam < mkr1...@gmail.com> >> >> > wrote: >> >> > > Hi, >> >> > > >> >> > > When OpenStack service components are started/stooped, >> >> > > operators or OpenStack Services want to execute some actives >> >> > > before and/or after component is started/stopped. >> >> > > Most of the time, operator needs to depends >> >> > > on the start-up scripts to do it, which is an installer >> >> > > dependent, while OpenStack service can't use this approach. >> >> >Can you elaborate on this? I think you're saying that having a start-up >> >script take action before a service is started won't work because it >> >would require the operator to customize that script. Is that right? >> >Aren't there already tools for doing this, though? >> >> [KanagarajM] when we use start-up script, we can't do any pre/post >> actions in every worker process, instead we can only do pre/post once >> before/after launcher and all worker process started. > >Can you describe some of the sorts of things you expect to need to do >for each process? [KanagarajM] one of the use case i was thinking of is, while upgrading, we need to put the service components to maintenance state, so that it would stop taking further request and once it finishes it current on going request processing, it can exist. to do that, each worker process to be notified to go to maintenance mode, by providing an maintenance-hook, any service it wants to support the maintenance cycle, could leverage it. On Wed, May 18, 2016 at 8:10 PM, Doug Hellmann wrote: > Excerpts from Kanagaraj Manickam's message of 2016-05-18 19:48:13 +0530: > > > DIms, > > >> > > >> Use case could be anything, which would needed by either > > >> operator/community, who wants to perform an required task before and > > after > > >> service is started. This requirement is very generic by nature, and I > > >> believe it will be very useful. > > >> > > >> Would like to give the sample use cases from from Operator & OpenStack > > >> community side as below. > > >> Operator side, any pre/post actions could be hooked which is the > > >> requirement for them. Simple example would be, one who wants to > create an > > >> journal of start/stop details like time, number of worker, > > configurations, > > >> etc in a common portal, this life-cycle hook would help. > > > > > Is that information not available in the logs? > > > > [Kanagaraj M] its available in log, but one who wants to collect these > info > > in centralized portal, > > it would help. > > > > > > > > OpenStack community side, sample use cases would be: > > > 1. Most of the OpenStack components starts TextGuruMeditation, logging > > > while those components are get started. These tasks could be provided > as > > > life cycle hooks and all OpenStack components could start to leverage > it. > > > > >All of those are things that need to be built into the app in a way that > > >they are started at the right time, rather than at an arbitrary point > > >defined by the plugin order a deployer has specified. > > > > [Kanagaraj M] while i investigated the OpenStack service cmd, mostly > > it follows the similar pattern on use these utils, so i thought, it > would be > > good to provide an plugin, which take care of it instead every service > > code does take care of it. helps to reduces maintenance effort. > > Except that we don't w
Re: [openstack-dev] [oslo.service] Lifecycle Hooks
> DIms, >> >> Use case could be anything, which would needed by either >> operator/community, who wants to perform an required task before and after >> service is started. This requirement is very generic by nature, and I >> believe it will be very useful. >> >> Would like to give the sample use cases from from Operator & OpenStack >> community side as below. >> Operator side, any pre/post actions could be hooked which is the >> requirement for them. Simple example would be, one who wants to create an >> journal of start/stop details like time, number of worker, configurations, >> etc in a common portal, this life-cycle hook would help. > Is that information not available in the logs? [Kanagaraj M] its available in log, but one who wants to collect these info in centralized portal, it would help. > > OpenStack community side, sample use cases would be: > 1. Most of the OpenStack components starts TextGuruMeditation, logging > while those components are get started. These tasks could be provided as > life cycle hooks and all OpenStack components could start to leverage it. >All of those are things that need to be built into the app in a way that >they are started at the right time, rather than at an arbitrary point >defined by the plugin order a deployer has specified. [Kanagaraj M] while i investigated the OpenStack service cmd, mostly it follows the similar pattern on use these utils, so i thought, it would be good to provide an plugin, which take care of it instead every service code does take care of it. helps to reduces maintenance effort. >> 2. For automatically discovering the OpenStack deployment, this hooks will >> be very useful. Auto-discover-hook would report to pre-defined destinations >> while starting/stopping the service. >Doing that usefully is going to require passing information to the hook >so it knows where it is running (what service, what port, etc.). None of >the APIs for doing this have been described yet. Do you have any plans >put together? [Kanagaraj M] I am trying to get all of these information from oslo.confg global config variable. As we discussed about namos during austin summit, namos does collect these details https://github.com/openstack/os-namos/blob/master/os_namos/sync.py#L124 >It feels very much like you're advocating that we create a thing like >paste-deploy for non-WSGI apps: allow anyone to insert anything into >the executing process for any purpose and with little control on the >application authors' part. That introduces potential stability issues, >and a lot of questions that haven't been answered. For example: >Does service startup block until all of the plugins are done? If not, >do we need to have a timeout management system built in or do we run >the plugins in their own thread/subprocess so they can run in the >background? >Can a plugin change the execution of the service in some way (you >mentioned having a plugin download config files when we spoke at the >summit, is that still something you want to slip in this way instead of >putting it into oslo.config)? >Can a plugin cause the service to not start at all by exiting? >What happens if one plugin fails but others succeed? Do we keep running? >What information about the service can a plugin see? It's running in the >same process, so it could see the configuration object, for example. >It would only be able to see configuration options it adds (yes, that >would work) or that were registered by the application before the plugin >is run. So, not necessarily all options but potentially many, with more >and more as apps shift to pre-registering all of their options in one >place. Assuming these are things the deployer has selectively installed, >maybe that's OK. OTOH, it does open another security surface. >What happens when a service is told to restart its workers? Do the >plugins run again? >Can a plugin start listening for network connections on its own? Connect >to the message bus? Provide an RPC endpoint? Start processes? Threads? [KanagarajM] It gives me a lots insight on what are different problems would come and i really thank you. Hooks will be provided by community and/or deployers. while community provides, those hooks will be well documented, tested and configuration would be provided. so all of the above mentioned aspects would be taken care well by community based on the hooks functionality. And deployer also would take care of similar safety measurement before using their hooks similar to how would they take care when using startup scripts. >> Regards >> Kanagaraj M >> >> On Wed, May 11, 2016 at 7:05 PM, Davanum Srinivas wrote: >> >> > Kanagaraj, > > >> > Who is the first consumer?
Re: [openstack-dev] [oslo.service] Lifecycle Hooks
DIms, Use case could be anything, which would needed by either operator/community, who wants to perform an required task before and after service is started. This requirement is very generic by nature, and I believe it will be very useful. Would like to give the sample use cases from from Operator & OpenStack community side as below. Operator side, any pre/post actions could be hooked which is the requirement for them. Simple example would be, one who wants to create an journal of start/stop details like time, number of worker, configurations, etc in a common portal, this life-cycle hook would help. OpenStack community side, sample use cases would be: 1. Most of the OpenStack components starts TextGuruMeditation, logging while those components are get started. These tasks could be provided as life cycle hooks and all OpenStack components could start to leverage it. 2. For automatically discovering the OpenStack deployment, this hooks will be very useful. Auto-discover-hook would report to pre-defined destinations while starting/stopping the service. Regards Kanagaraj M On Wed, May 11, 2016 at 7:05 PM, Davanum Srinivas wrote: > Kanagaraj, > > Who is the first consumer? for what specific purpose? > > Thanks, > Dims > > On Wed, May 11, 2016 at 9:27 AM, Kanagaraj Manickam > wrote: > > Hi, > > > > When OpenStack service components are started/stooped, > > operators or OpenStack Services want to execute some actives > > before and/or after component is started/stopped. > > Most of the time, operator needs to depends > > on the start-up scripts to do it, which is an installer > > dependent, while OpenStack service can't use this approach. > > > > Also using start-up script does not suite for below situations: > > oslo.service spawns component in more than one processes > > when workers count is more than 1. In this case, if we want > > to execute some activities before/after on each process, start-up > > script does not help. > > > > So to support these scenarios, thinking of below enhancement > > in oslo.service as mentioned in blueprint [1] > > > > Most of the projects in OpenStack does make use of oslo.service > > library to create/start/stop the service api and back-end components. > > And by providing an configurable python hooks as below, and > > enhance oslo.service to execute them appropriately. > > > > [oslo_service] > > List of of pre-hook executed in sequence > > pre-hook= > > List of of pre-hook executed in sequence > > post-hook= > > > > And to make sure the hooks does not break the running process, > > try to execute them in try block. > > > > Kindly provide your comments/inputs. Thanks > > > > [1]: https://blueprints.launchpad.net/oslo.service/+spec/service-hook > > > > Regards, > > Kanagaraj M > > > > > __ > > 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 > > > > > > -- > Davanum Srinivas :: https://twitter.com/dims > > __ > 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-dev] [oslo.service] Lifecycle Hooks
Hi, When OpenStack service components are started/stooped, operators or OpenStack Services want to execute some actives before and/or after component is started/stopped. Most of the time, operator needs to depends on the start-up scripts to do it, which is an installer dependent, while OpenStack service can't use this approach. Also using start-up script does not suite for below situations: oslo.service spawns component in more than one processes when workers count is more than 1. In this case, if we want to execute some activities before/after on each process, start-up script does not help. So to support these scenarios, thinking of below enhancement in oslo.service as mentioned in blueprint [1] Most of the projects in OpenStack does make use of oslo.service library to create/start/stop the service api and back-end components. And by providing an configurable python hooks as below, and enhance oslo.service to execute them appropriately. [oslo_service] List of of pre-hook executed in sequence pre-hook= List of of pre-hook executed in sequence post-hook= And to make sure the hooks does not break the running process, try to execute them in try block. Kindly provide your comments/inputs. Thanks [1]: https://blueprints.launchpad.net/oslo.service/+spec/service-hook Regards, Kanagaraj M __ 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] [Heat] Nomination Oleksii Chuprykov to Heat core reviewer
+1 On Wed, Mar 16, 2016 at 4:27 PM, Sergey Kraynev wrote: > Hi Heaters, > > The Mitaka release is close to finish, so it's good time for reviewing > results of work. > One of this results is analyze contribution results for the last release > cycle. > According to the data [1] we have one good candidate for nomination to > core-review team: > Oleksii Chuprykov. > During this release he showed significant value of review metric. > His review were valuable and useful. Also He has enough level of > expertise in Heat code. > So I think he is worthy to join to core-reviewers team. > > I ask you to vote and decide his destiny. > +1 - if you agree with his candidature > -1 - if you disagree with his candidature > > [1] http://stackalytics.com/report/contribution/heat-group/120 > > -- > Regards, > Sergey. > > __ > 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-dev] [Heat] PTL candidacy
Dear all, I am announcing my candidacy for PTL role in heat for Newton release. I started to work in heat from Juno release and got opportunities to work on various features in Heat services and it's echo-system like CI, documentation. It helped me to get confident with heat service and community. Based on this, I would like to announce my candidacy and will assure to continue the team success formula "consensus building". My goal is to increase the existing user and developer experiences in heat to the next height, by working with us on following aspects in Newton release: Features: * Work with Product WG to understand their road-map and bring the required features in heat. It helps to align with big-tent's over-all road-map. * Complete the Convergence initiative and bring greater value out-of it. It helps for greater scalability. * Heat is being consumed in OpenStack by TripleO, Tacker, Magnum, Murano, etc. Provide best support to these project communities for their needs in heat project. It helps to expand the foot-print of heat and enhance these services. * Implement existing and new blue-prints. It helps to strengthen heat's muscular power. * Implement hot-parser in similar line with XML parser, YAML parser, etc. It helps those open-source and closed-source solutions use the HOT template. (Once python flavor is established, other language such as java-script could be aimed.) * Over the releases, heat-templates git repo is grown up with many templates and some of them might be absolute as well. Investigate templates in this repo and make them organized based on heat features, use-cases, etc. Also make sure all are *valid* templates. It helps to make it better manageable and usable. CI: == * Continue the test-case improvements and identify the gaps/improvements in build jobs and test automations and fix them. It helps to reduce the turn-around time of authors and improves the existing heat quality further. Documentations: === * Make Orchestration api-refs, developer and user guides to be in sync with heat master code base. It helps to easy/enhance the heat user's life. Thanks for your considerations, Kanagaraj Manickam IRC: KanagarajM Launchpad: kanagaraj-manickam __ 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
