[openstack-dev] [watcher] Nominating Hidekazu Nakamura as Watcher Core
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Team, Hidekazu Nakamura has made many contributions[1] to Watcher since the Barcelona summit when we first met. I would like to nominate him to be part of the Watcher Core Team. I really think he will provide many valuable contributions to the project and his inputs (such as [2]) will most certainly help us substantially improve Watcher as a whole. It's now time to vote :) [1] http://stackalytics.com/report/contribution/watcher/120 [2] https://wiki.openstack.org/wiki/Zone_migration -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJYqqgNAAoJEEb+XENQ/jVSf+kH/1+BLL907SrocIM87AlOdMAn IuB0Xk+y7fAijrs4X7FqknEb2f8Ns4EN3f97SQGFF6WUqSxTMoyMkCZNBEaTWi0P 0D+g2KLTgOhOG8UGdV26CQD0qj455Q+GsQztatcip3zBRalO3QYcF8WUNkCs3GY3 yMDoCnK9L3JE+aihGf93UklAeYij856LlY4zj1Nxnm5MCdUNLnYpz+VpyjOtpE2w QX3AH0jPs6b2coYC7O0CggpbMF0xFJzpaLiiRaabSzvuLT8vh1ICaCyUpH9IgXIv M8i1b7aIvLRyxo1ZylFdBNu3J74Ayv5BZKudEtA5yqGn0bExL+yPiSJgv20WcrY= =4frW -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] [Watcher] Nominating licanwei to Watcher Core
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 On 14/02/2017 11:27, ? ? wrote: > His activity will help Watcher Team to make this project better. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJYot3aAAoJEEb+XENQ/jVSvIEH/RsqFZZ7hZyA7ExieF7K4GmN d1f1vnPbOR3MgqQTbezixIPIwzrDw9dtpU6q8BRPARP6ja2tOPNoYHc1CZmxgwz9 Mc5iVhvAaKuzL7KKpeROVkLkVUJ9bZnxNM/pkgiq0qXYoBaitgVdPVTIE6nBLdpV yHRkUG24pkojogIJGIbB2cJeKganJ+PrCB59buAof1NqEhujt00akfjHCKbc7Wc/ oSmx2VD3aRn8OcfAhQ1pQgRYpa6MRFBRbDUPejVyiGzFWTDreWA3cLVq2xpGEcCW ahcq2MNsZCiFegD4u9jYroULOALhdGBUctONbluaqbfZ7PhPPqQxSJGQq96hTCg= =WsCi -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
[openstack-dev] [Watcher] Nominating Prudhvi Rao Shedimbi to Watcher Core
Team, I would like to promote Prudhvi Rao Shedimbi to the core team. He's done a great work in reviewing many patchsets[1] and I believe that he has a good vision of Watcher as a whole. I think he would make an excellent addition to the team. Please vote [1] http://stackalytics.com/report/contribution/watcher/90 Vincent FRANCOISE B<>COM __ 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] [watcher] Nominate Prashanth Hari as core for watcher-specs
+1
On 16/08/2016 17:56, Joe Cropper wrote:
> +1
>
>> On Aug 16, 2016, at 11:59 AM, Jean-Émile DARTOIS
>> wrote:
>>
>> +1
>>
>> Jean-Emile
>> DARTOIS
>>
>> {P} Software Engineer
>> Cloud Computing
>>
>> {T} +33 (0) 2 56 35 8260
>> {W} www.b-com.com
>>
>>
>> De : Antoine Cabot
>> Envoyé : mardi 16 août 2016 16:57
>> À : OpenStack Development Mailing List (not for usage questions)
>> Objet : [openstack-dev] [watcher] Nominate Prashanth Hari as core for
>> watcher-specs
>>
>> Hi Watcher team,
>>
>> I'd like to nominate Prashanth Hari as core contributor for watcher-specs.
>> As a potential end-user for Watcher, Prashanth gave us a lot of good
>> feedback since the Mitaka release.
>> Please vote for his candidacy.
>>
>> Antoine
>>
>> __
>> 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] [Watcher] Promote Alexchadin to the core team.
Alexander Chadin did prove he knew the various moving parts of Watcher by participating the numerous design discussions and blueprints during the last months which makes him a precious asset for our team. So that's a definite +1 for me as well. On 04/08/2016 09:11, Jean-Émile DARTOIS wrote: > Hi all, > > alexchadin has consistently contributed to Watcher for a while. He is > also very active on IRC. Based on his contribution (e.g: > continuously-optimization blueprint) and expertise which adds concrete > value to Watcher, I’d like to promote alexchadin to the core team. > > According to the OpenStack Governance process [1], Please vote +1 or -1 > to the nomination. > > [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess > > Best regards, > > jed56 > > > Jean-Emile > DARTOIS > > > > > > > > > > > __ > 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] [watcher] Api and Decision Engine integration - design question
Hi Tomasz, Overall, I don't really have any strong opinion on this. I just think that if we do it with option 1, it may become quite hard to make Watcher more scalable in the long run if we need to. That's why I would tend to choose option 2. Also, it's not so easy for me to evaluate how much work the DB sync would require compared to what I did for the strategies and goals (see https://review.openstack.org/#/c/305965/2/watcher/decision_engine/sync.py), so take my answer with a grain of salt :) On 15/04/2016 10:10, Kaczynski, Tomasz wrote: > Hi guys, > > I’m implementing the Watcher Scoring Module. As part of that, I need to > expose the information about Scoring Engines through the API/Python CLI. > > > > The scoring engine list might be quite dynamic. Although the scoring > engines will be pluggable through the stevedore plug-in model, a single > plug-in might contain one or more scoring engines. In some scenarios > this list will be static – a plug-in developer will just expose few > algorithms and that’s it. But in some other scenarios, the scoring > engines might be implemented as external web services for example and > there might be an on-going development process on data models, which > will result in multiple scoring engines in multiple versions, which > might change quite frequently (e.g. few times a day). > > > > Of course, the responsibility for handling all of that is entirely on > the scoring engine plug-in developer. But it would be good to keep the > scoring engine abstraction layer clean and simple, hiding all of these > details. > > > > And here comes the problem: > > Somehow the dynamic list of scoring engines has to be passed from > Decision Engine (where the Scoring Engine abstraction layer will be > sitting) to the Api / CLI. There are currently 2 options on the table > how this could be done: > > > > Option 1: > > Allow Api to call Decision Engine directly through existing RPC Api > (currently using messaging transport). > > > > Option 2: > > Let Decision Engine keep Scoring Engine information synced in the DB so > that Watcher Api can simply query for this information as required. > > > > Pros and cons of each option: > > Option 1: > > - Good: Simpler implementation and no need for keeping DB in sync. > > - Good: No risk of data inconsistency. Nothing is being cached, > data is always accurate. Decision Engine is a single source of truth. > > - Good: Scoring Engine Plug-in creates a simple stevedore > plug-in, implements scoring engine classes, implements a factory class > returning scoring engines and that’s all. > > - Good: Supports also more complicated scenarios with dynamic > scoring engine list – encapsulated in the factory class. > > - Bad: Dependency on Decision Engine – it needs to be up and > running. Can be mitigated by caching the last response from Decision > Engine – if DE RCP Api is not responding, the last known data could be > returned. > > - Bad: Not sure how reliable/performant RPC over messaging > transport is. Need to test. > > - Bad: Might have scalability issues (I believe there is only > one Decision Engine instance, please confirm!). But this might be at > least partially mitigated by caching on the Watcher Api level (e.g. if > the last data was retrieved less than X minutes ago, no need to query > Decision Engine). In the context that this information is only used by > Strategy developers to actually implement strategies using some Scoring > Engines, it might be perfectly fine to cache data for longer periods of > time (1 hour or more). I confirm there is only one DE process whereas the API can have as many workers as you want (configurable). > > Option 2: > > - Good: Watcher Api decoupled from Decision Engine. Can work > even if DE is not working or busy. > > - Good: In case of Watcher this option should scale better. > Decision Engine typically has only one instance and is not subject to > horizontal scalability (please confirm my understanding!). > > - Bad: More complicated implementation. For dynamic scenarios > (adding scoring engines on the fly) requires some sort of notification > mechanism, so that the DB will stay in sync. Can be done by exposing > event handling in scoring engine abstraction layer, but it’s unnecessary > complication for simple cases with static data. But can be mitigated by > using helper classes enforcing DB sync without actually exposing any > events in the abstract classes (so if plug-in needs to sync DB, it calls > some helper method, all others just do nothing). > I agree on the difficulty here, but we can do implement this incrementally so we wouldn't have to handle all these cases straight away. > - Bad: Potential issues with data consistency. If there is a > problem or a bug in the sync code, it might be hard to recover from the > problem without Watcher redeployment. > > -
