[all] New Automatic SIG (continue discussion)
Dear all To continue the discussion of whether we should have new SIG for autoscaling. I think we already got enough time for this ML [1], and it's time to jump to the next step. As we got a lot of positive feedbacks from ML [1], I think it's definitely considered an action to create a new SIG, do some init works, and finally Here are some things that we can start right now, to come out with the name of SIG, the definition and mission. Here's my draft plan: To create a SIG name `Automatic SIG`, with given initial mission to improve automatic scaling with (but not limited to) OpenStack. As we discussed in forum [2], to have scenario tests and documents will be considered as actions for the initial mission. I gonna assume we will start from scenarios which already provide some basic tests and documents which we can adapt very soon and use them to build a SIG environment. And the long-term mission of this SIG is to make sure we provide good documentation and test coverage for most automatic functionality. I suggest `Automatic SIG` instead of `Autoscaling SIG` to make sure we can provide more value if there are more needs in the future. Just like the example which Adam raised `self-optimizing` from people who are using watcher [3]. Let me know if you got any concerns about this name. And to clarify, there will definitely some cross SIG co-work between this new SIG and Self-Healing SIG (there're some common requirements even across self-healing and autoscaling features.). We also need to make sure we do not provide any duplicated work against self-healing SIG. As a start, let's only focus on autoscaling scenario, and make sure we're doing it right before we move to multiple cases. If no objection, I will create the new SIG before next weekend and plan a short schedule in Denver summit and PTG. [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000284.... [2] https://etherpad.openstack.org/p/autoscaling-integration-and-feedback [3] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000813.... -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin
+1 from me. On Fri, Jan 11, 2019 at 9:32 PM Rico Lin <rico.lin.guanyu@gmail.com> wrote:
Dear all
To continue the discussion of whether we should have new SIG for autoscaling.
I think we already got enough time for this ML [1], and it's time to jump to the next step. As we got a lot of positive feedbacks from ML [1], I think it's definitely considered an action to create a new SIG, do some init works, and finally Here are some things that we can start right now, to come out with the name of SIG, the definition and mission.
Here's my draft plan: To create a SIG name `Automatic SIG`, with given initial mission to improve automatic scaling with (but not limited to) OpenStack. As we discussed in forum [2], to have scenario tests and documents will be considered as actions for the initial mission. I gonna assume we will start from scenarios which already provide some basic tests and documents which we can adapt very soon and use them to build a SIG environment. And the long-term mission of this SIG is to make sure we provide good documentation and test coverage for most automatic functionality.
I suggest `Automatic SIG` instead of `Autoscaling SIG` to make sure we can provide more value if there are more needs in the future. Just like the example which Adam raised `self-optimizing` from people who are using watcher [3]. Let me know if you got any concerns about this name. And to clarify, there will definitely some cross SIG co-work between this new SIG and Self-Healing SIG (there're some common requirements even across self-healing and autoscaling features.). We also need to make sure we do not provide any duplicated work against self-healing SIG. As a start, let's only focus on autoscaling scenario, and make sure we're doing it right before we move to multiple cases.
If no objection, I will create the new SIG before next weekend and plan a short schedule in Denver summit and PTG.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000284....
[2] https://etherpad.openstack.org/p/autoscaling-integration-and-feedback [3] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000813....
-- May The Force of OpenStack Be With You,
*Rico Lin*irc: ricolin
-- Sa Pham Dang Cloud RnD Team - VCCloud Phone/Telegram: 0986.849.582 Skype: great_bn
Rico Lin <rico.lin.guanyu@gmail.com> wrote:
Dear all
To continue the discussion of whether we should have new SIG for autoscaling.
I think we already got enough time for this ML [1], and it's time to jump to the next step. As we got a lot of positive feedbacks from ML [1], I think it's definitely considered an action to create a new SIG, do some init works, and finally Here are some things that we can start right now, to come out with the name of SIG, the definition and mission.
Here's my draft plan: To create a SIG name `Automatic SIG`, with given initial mission to improve automatic scaling with (but not limited to) OpenStack. As we discussed in forum [2], to have scenario tests and documents will be considered as actions for the initial mission. I gonna assume we will start from scenarios which already provide some basic tests and documents which we can adapt very soon and use them to build a SIG environment. And the long-term mission of this SIG is to make sure we provide good documentation and test coverage for most automatic functionality.
I suggest `Automatic SIG` instead of `Autoscaling SIG` to make sure we can provide more value if there are more needs in the future. Just like the example which Adam raised `self-optimizing` from people who are using watcher [3]. Let me know if you got any concerns about this name.
I'm +1 for creating the SIG, although "Automatic SIG" doesn't sound quite right to me, because it's not clear what is being automated. For example from the outside people might think it was a SIG about CI, or about automated testing, or both - or even some kind of automatic creation of new SIGs ;-) Here are some alternative suggestions: - Optimization SIG - Self-optimization SIG - Auto-optimization SIG - Adaptive Cloud SIG - Self-adaption SIG - Auto-adaption SIG - Auto-configuration SIG although I'm not sure these are a huge improvement on "Autoscaling SIG" - maybe some are too broad, or too vague. It depends on how likely it is that the scope will go beyond just auto-scaling. Of course you could also just stick with the original idea of "Auto-scaling" :-)
And to clarify, there will definitely some cross SIG co-work between this new SIG and Self-Healing SIG (there're some common requirements even across self-healing and autoscaling features.). We also need to make sure we do not provide any duplicated work against self-healing SIG. As a start, let's only focus on autoscaling scenario, and make sure we're doing it right before we move to multiple cases.
Sounds good!
If no objection, I will create the new SIG before next weekend and plan a short schedule in Denver summit and PTG.
Thanks for driving this!
On 1/11/19 10:14 AM, Adam Spiers wrote:
Rico Lin <rico.lin.guanyu@gmail.com> wrote:
Dear all
To continue the discussion of whether we should have new SIG for autoscaling. I think we already got enough time for this ML [1], and it's time to jump to the next step. As we got a lot of positive feedbacks from ML [1], I think it's definitely considered an action to create a new SIG, do some init works, and finally Here are some things that we can start right now, to come out with the name of SIG, the definition and mission. Here's my draft plan: To create a SIG name `Automatic SIG`, with given initial mission to improve automatic scaling with (but not limited to) OpenStack. As we discussed in forum [2], to have scenario tests and documents will be considered as actions for the initial mission. I gonna assume we will start from scenarios which already provide some basic tests and documents which we can adapt very soon and use them to build a SIG environment. And the long-term mission of this SIG is to make sure we provide good documentation and test coverage for most automatic functionality. I suggest `Automatic SIG` instead of `Autoscaling SIG` to make sure we can provide more value if there are more needs in the future. Just like the example which Adam raised `self-optimizing` from people who are using watcher [3]. Let me know if you got any concerns about this name.
I'm +1 for creating the SIG, although "Automatic SIG" doesn't sound quite right to me, because it's not clear what is being automated. For example from the outside people might think it was a SIG about CI, or about automated testing, or both - or even some kind of automatic creation of new SIGs ;-) Here are some alternative suggestions: - Optimization SIG - Self-optimization SIG - Auto-optimization SIG - Adaptive Cloud SIG - Self-adaption SIG - Auto-adaption SIG - Auto-configuration SIG
although I'm not sure these are a huge improvement on "Autoscaling SIG" - maybe some are too broad, or too vague. It depends on how likely it is that the scope will go beyond just auto-scaling. Of course you could also just stick with the original idea of "Auto-scaling" :-)
I'm inclined to argue that limiting the scope of this SIG is actually a feature, not a bug. Better to have a tightly focused SIG that has very specific, achievable goals than to try to boil the ocean by solving all of the auto* problems in OpenStack. We all know how "one SIG to rule them all" ends. ;-)
And to clarify, there will definitely some cross SIG co-work between this new SIG and Self-Healing SIG (there're some common requirements even across self-healing and autoscaling features.). We also need to make sure we do not provide any duplicated work against self-healing SIG. As a start, let's only focus on autoscaling scenario, and make sure we're doing it right before we move to multiple cases.
Sounds good!
If no objection, I will create the new SIG before next weekend and plan a short schedule in Denver summit and PTG.
Thanks for driving this!
+1 on limiting the scope to autoscaling at first. I prefer the name autoscaling since the mission is to improve automatic scaling. If the mission is changed later, we can change the name of the SIG to reflect that. On Fri, Jan 11, 2019 at 8:24 AM Ben Nemec <openstack@nemebean.com> wrote:
On 1/11/19 10:14 AM, Adam Spiers wrote:
Rico Lin <rico.lin.guanyu@gmail.com> wrote:
Dear all
To continue the discussion of whether we should have new SIG for autoscaling. I think we already got enough time for this ML [1], and it's time to jump to the next step. As we got a lot of positive feedbacks from ML [1], I think it's definitely considered an action to create a new SIG, do some init works, and finally Here are some things that we can start right now, to come out with the name of SIG, the definition and mission. Here's my draft plan: To create a SIG name `Automatic SIG`, with given initial mission to improve automatic scaling with (but not limited to) OpenStack. As we discussed in forum [2], to have scenario tests and documents will be considered as actions for the initial mission. I gonna assume we will start from scenarios which already provide some basic tests and documents which we can adapt very soon and use them to build a SIG environment. And the long-term mission of this SIG is to make sure we provide good documentation and test coverage for most automatic functionality. I suggest `Automatic SIG` instead of `Autoscaling SIG` to make sure we can provide more value if there are more needs in the future. Just like the example which Adam raised `self-optimizing` from people who are using watcher [3]. Let me know if you got any concerns about this name.
I'm +1 for creating the SIG, although "Automatic SIG" doesn't sound quite right to me, because it's not clear what is being automated. For example from the outside people might think it was a SIG about CI, or about automated testing, or both - or even some kind of automatic creation of new SIGs ;-) Here are some alternative suggestions: - Optimization SIG - Self-optimization SIG - Auto-optimization SIG - Adaptive Cloud SIG - Self-adaption SIG - Auto-adaption SIG - Auto-configuration SIG
although I'm not sure these are a huge improvement on "Autoscaling SIG" - maybe some are too broad, or too vague. It depends on how likely it is that the scope will go beyond just auto-scaling. Of course you could also just stick with the original idea of "Auto-scaling" :-)
I'm inclined to argue that limiting the scope of this SIG is actually a feature, not a bug. Better to have a tightly focused SIG that has very specific, achievable goals than to try to boil the ocean by solving all of the auto* problems in OpenStack. We all know how "one SIG to rule them all" ends. ;-)
And to clarify, there will definitely some cross SIG co-work between this new SIG and Self-Healing SIG (there're some common requirements even across self-healing and autoscaling features.). We also need to make sure we do not provide any duplicated work against self-healing SIG. As a start, let's only focus on autoscaling scenario, and make sure we're doing it right before we move to multiple cases.
Sounds good!
If no objection, I will create the new SIG before next weekend and plan a short schedule in Denver summit and PTG.
Thanks for driving this!
+1 SIGs should have limited scope - shared interest in a particular area - even if that area is something broad like security the mission and work should be specific which could lead to working groups, additional SIGs, projects, etc so I want to be careful how I word it but yes limited scope is the ideal way to start a SIG imo. On Fri, Jan 11, 2019 at 11:14 AM Duc Truong <duc.openstack@gmail.com> wrote:
+1 on limiting the scope to autoscaling at first. I prefer the name autoscaling since the mission is to improve automatic scaling. If the mission is changed later, we can change the name of the SIG to reflect that.
On Fri, Jan 11, 2019 at 8:24 AM Ben Nemec <openstack@nemebean.com> wrote:
On 1/11/19 10:14 AM, Adam Spiers wrote:
Rico Lin <rico.lin.guanyu@gmail.com> wrote:
Dear all
To continue the discussion of whether we should have new SIG for autoscaling. I think we already got enough time for this ML [1], and it's time to jump to the next step. As we got a lot of positive feedbacks from ML [1], I think it's definitely considered an action to create a new SIG, do some init works, and finally Here are some things that we can start right now, to come out with the name of SIG, the definition and
mission.
Here's my draft plan: To create a SIG name `Automatic SIG`, with given initial mission to improve automatic scaling with (but not limited to) OpenStack. As we discussed in forum [2], to have scenario tests and documents will be considered as actions for the initial mission. I gonna assume we will start from scenarios which already provide some basic tests and documents which we can adapt very soon and use them to build a SIG environment. And the long-term mission of this SIG is to make sure we provide good documentation and test coverage for most automatic functionality. I suggest `Automatic SIG` instead of `Autoscaling SIG` to make sure we can provide more value if there are more needs in the future. Just like the example which Adam raised `self-optimizing` from people who are using watcher [3]. Let me know if you got any concerns about this name.
I'm +1 for creating the SIG, although "Automatic SIG" doesn't sound quite right to me, because it's not clear what is being automated. For example from the outside people might think it was a SIG about CI, or about automated testing, or both - or even some kind of automatic creation of new SIGs ;-) Here are some alternative suggestions: - Optimization SIG - Self-optimization SIG - Auto-optimization SIG - Adaptive Cloud SIG - Self-adaption SIG - Auto-adaption SIG - Auto-configuration SIG
although I'm not sure these are a huge improvement on "Autoscaling SIG" - maybe some are too broad, or too vague. It depends on how likely it is that the scope will go beyond just auto-scaling. Of course you could also just stick with the original idea of "Auto-scaling" :-)
I'm inclined to argue that limiting the scope of this SIG is actually a feature, not a bug. Better to have a tightly focused SIG that has very specific, achievable goals than to try to boil the ocean by solving all of the auto* problems in OpenStack. We all know how "one SIG to rule them all" ends. ;-)
And to clarify, there will definitely some cross SIG co-work between this new SIG and Self-Healing SIG (there're some common requirements even across self-healing and autoscaling features.). We also need to make sure we do not provide any duplicated work against self-healing SIG. As a start, let's only focus on autoscaling scenario, and make sure we're doing it right before we move to multiple cases.
Sounds good!
If no objection, I will create the new SIG before next weekend and plan a short schedule in Denver summit and PTG.
Thanks for driving this!
-- Kind regards, Melvin Hillsman mrhillsman@gmail.com mobile: (832) 264-2646
Fine by me - sounds like we have a consensus for autoscaling then? Melvin Hillsman <mrhillsman@gmail.com> wrote:
+1 SIGs should have limited scope - shared interest in a particular area - even if that area is something broad like security the mission and work should be specific which could lead to working groups, additional SIGs, projects, etc so I want to be careful how I word it but yes limited scope is the ideal way to start a SIG imo.
On Fri, Jan 11, 2019 at 11:14 AM Duc Truong <duc.openstack@gmail.com> wrote:
+1 on limiting the scope to autoscaling at first. I prefer the name autoscaling since the mission is to improve automatic scaling. If the mission is changed later, we can change the name of the SIG to reflect that.
On Fri, Jan 11, 2019 at 8:24 AM Ben Nemec <openstack@nemebean.com> wrote:
On 1/11/19 10:14 AM, Adam Spiers wrote:
Rico Lin <rico.lin.guanyu@gmail.com> wrote:
Dear all
To continue the discussion of whether we should have new SIG for autoscaling. I think we already got enough time for this ML [1], and it's time to jump to the next step. As we got a lot of positive feedbacks from ML [1], I think it's definitely considered an action to create a new SIG, do some init works, and finally Here are some things that we can start right now, to come out with the name of SIG, the definition and
mission.
Here's my draft plan: To create a SIG name `Automatic SIG`, with given initial mission to improve automatic scaling with (but not limited to) OpenStack. As we discussed in forum [2], to have scenario tests and documents will be considered as actions for the initial mission. I gonna assume we will start from scenarios which already provide some basic tests and documents which we can adapt very soon and use them to build a SIG environment. And the long-term mission of this SIG is to make sure we provide good documentation and test coverage for most automatic functionality. I suggest `Automatic SIG` instead of `Autoscaling SIG` to make sure we can provide more value if there are more needs in the future. Just like the example which Adam raised `self-optimizing` from people who are using watcher [3]. Let me know if you got any concerns about this name.
I'm +1 for creating the SIG, although "Automatic SIG" doesn't sound quite right to me, because it's not clear what is being automated. For example from the outside people might think it was a SIG about CI, or about automated testing, or both - or even some kind of automatic creation of new SIGs ;-) Here are some alternative suggestions: - Optimization SIG - Self-optimization SIG - Auto-optimization SIG - Adaptive Cloud SIG - Self-adaption SIG - Auto-adaption SIG - Auto-configuration SIG
although I'm not sure these are a huge improvement on "Autoscaling SIG" - maybe some are too broad, or too vague. It depends on how likely it is that the scope will go beyond just auto-scaling. Of course you could also just stick with the original idea of "Auto-scaling" :-)
I'm inclined to argue that limiting the scope of this SIG is actually a feature, not a bug. Better to have a tightly focused SIG that has very specific, achievable goals than to try to boil the ocean by solving all of the auto* problems in OpenStack. We all know how "one SIG to rule them all" ends. ;-)
And to clarify, there will definitely some cross SIG co-work between this new SIG and Self-Healing SIG (there're some common requirements even across self-healing and autoscaling features.). We also need to make sure we do not provide any duplicated work against self-healing SIG. As a start, let's only focus on autoscaling scenario, and make sure we're doing it right before we move to multiple cases.
Sounds good!
If no objection, I will create the new SIG before next weekend and plan a short schedule in Denver summit and PTG.
Thanks for driving this!
-- Kind regards,
Melvin Hillsman mrhillsman@gmail.com mobile: (832) 264-2646
Adam Spiers <aspiers@suse.com>於 2019年1月12日 週六，上午2:59寫道：
Fine by me - sounds like we have a consensus for autoscaling then?
I think “Autoscaling SIG” gets the majority vote. Let’s give it few more days for people in different time zones.
+1 SIGs should have limited scope - shared interest in a particular area - even if that area is something broad like security the mission and work should be specific which could lead to working groups, additional SIGs, projects, etc so I want to be careful how I word it but yes limited scope is the ideal way to start a SIG imo.
On Fri, Jan 11, 2019 at 11:14 AM Duc Truong <duc.openstack@gmail.com> wrote:
+1 on limiting the scope to autoscaling at first. I prefer the name autoscaling since the mission is to improve automatic scaling. If the mission is changed later, we can change the name of the SIG to reflect that.
On Fri, Jan 11, 2019 at 8:24 AM Ben Nemec <openstack@nemebean.com> wrote:
On 1/11/19 10:14 AM, Adam Spiers wrote:
Rico Lin <rico.lin.guanyu@gmail.com> wrote:
Dear all
To continue the discussion of whether we should have new SIG for autoscaling. I think we already got enough time for this ML [1], and it's time
to
jump to the next step. As we got a lot of positive feedbacks from ML [1], I think it's definitely considered an action to create a new SIG, do some init works, and finally Here are some things that we can start right now, to come out with the name of SIG, the definition and mission. Here's my draft plan: To create a SIG name `Automatic SIG`, with given initial mission to improve automatic scaling with (but not limited to) OpenStack. As we discussed in forum [2], to have scenario tests and documents will be considered as actions for the initial mission. I gonna assume we will start from scenarios which already provide some basic tests and documents which we can adapt very soon and use
build a SIG environment. And the long-term mission of this SIG is to make sure we provide good documentation and test coverage for most automatic functionality. I suggest `Automatic SIG` instead of `Autoscaling SIG` to make sure we can provide more value if there are more needs in the future. Just like the example which Adam raised `self-optimizing` from people who are using watcher [3]. Let me know if you got any concerns about
Melvin Hillsman <mrhillsman@gmail.com> wrote: them to this
name.
I'm +1 for creating the SIG, although "Automatic SIG" doesn't sound quite right to me, because it's not clear what is being automated. For example from the outside people might think it was a SIG about CI, or about automated testing, or both - or even some kind of automatic creation of new SIGs ;-) Here are some alternative suggestions: - Optimization SIG - Self-optimization SIG - Auto-optimization SIG - Adaptive Cloud SIG - Self-adaption SIG - Auto-adaption SIG - Auto-configuration SIG
although I'm not sure these are a huge improvement on "Autoscaling SIG" - maybe some are too broad, or too vague. It depends on how likely it is that the scope will go beyond just auto-scaling. Of course you could also just stick with the original idea of "Auto-scaling" :-)
I'm inclined to argue that limiting the scope of this SIG is actually a feature, not a bug. Better to have a tightly focused SIG that has very specific, achievable goals than to try to boil the ocean by solving all of the auto* problems in OpenStack. We all know how "one SIG to rule them all" ends. ;-)
And to clarify, there will definitely some cross SIG co-work between this new SIG and Self-Healing SIG (there're some common requirements even across self-healing and autoscaling features.). We also need to make sure we do not provide any duplicated work against self-healing SIG. As a start, let's only focus on autoscaling scenario, and make sure we're doing it right before we move to multiple cases.
Sounds good!
If no objection, I will create the new SIG before next weekend and plan a short schedule in Denver summit and PTG.
Thanks for driving this!
-- Kind regards,
Melvin Hillsman mrhillsman@gmail.com mobile: (832) 264-2646
--
May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin
New SIG request sent, please help to review it. https://review.openstack.org/632252 On Sat, Jan 12, 2019 at 8:36 AM Rico Lin <rico.lin.guanyu@gmail.com> wrote:
Adam Spiers <aspiers@suse.com>於 2019年1月12日 週六，上午2:59寫道：
Fine by me - sounds like we have a consensus for autoscaling then?
I think “Autoscaling SIG” gets the majority vote. Let’s give it few more days for people in different time zones.
+1 SIGs should have limited scope - shared interest in a particular area
even if that area is something broad like security the mission and work should be specific which could lead to working groups, additional SIGs, projects, etc so I want to be careful how I word it but yes limited scope is the ideal way to start a SIG imo.
On Fri, Jan 11, 2019 at 11:14 AM Duc Truong <duc.openstack@gmail.com> wrote:
+1 on limiting the scope to autoscaling at first. I prefer the name autoscaling since the mission is to improve automatic scaling. If the mission is changed later, we can change the name of the SIG to reflect that.
On Fri, Jan 11, 2019 at 8:24 AM Ben Nemec <openstack@nemebean.com> wrote:
On 1/11/19 10:14 AM, Adam Spiers wrote:
Rico Lin <rico.lin.guanyu@gmail.com> wrote: > Dear all > > To continue the discussion of whether we should have new SIG for > autoscaling. > I think we already got enough time for this ML [1], and it's
time to
> jump to the next step. As we got a lot of positive feedbacks from ML > [1], I think it's definitely considered an action to create a new SIG, > do some init works, and finally Here are some things that we can start > right now, to come out with the name of SIG, the definition and mission. > Here's my draft plan: To create a SIG name `Automatic SIG`, with given > initial mission to improve automatic scaling with (but not
> OpenStack. As we discussed in forum [2], to have scenario tests and > documents will be considered as actions for the initial mission. I > gonna assume we will start from scenarios which already provide some > basic tests and documents which we can adapt very soon and use
> build a SIG environment. And the long-term mission of this SIG is to > make sure we provide good documentation and test coverage for most > automatic functionality. > I suggest `Automatic SIG` instead of `Autoscaling SIG` to make sure we > can provide more value if there are more needs in the future. Just > like the example which Adam raised `self-optimizing` from people who > are using watcher [3]. Let me know if you got any concerns about
> name.
I'm +1 for creating the SIG, although "Automatic SIG" doesn't sound quite right to me, because it's not clear what is being automated. For example from the outside people might think it was a SIG about CI, or about automated testing, or both - or even some kind of automatic creation of new SIGs ;-) Here are some alternative suggestions: - Optimization SIG - Self-optimization SIG - Auto-optimization SIG - Adaptive Cloud SIG - Self-adaption SIG - Auto-adaption SIG - Auto-configuration SIG
although I'm not sure these are a huge improvement on "Autoscaling SIG" - maybe some are too broad, or too vague. It depends on how
Melvin Hillsman <mrhillsman@gmail.com> wrote: - limited to) them to this likely it
is that the scope will go beyond just auto-scaling. Of course you could also just stick with the original idea of "Auto-scaling" :-)
I'm inclined to argue that limiting the scope of this SIG is actually a feature, not a bug. Better to have a tightly focused SIG that has very specific, achievable goals than to try to boil the ocean by solving all of the auto* problems in OpenStack. We all know how "one SIG to rule them all" ends. ;-)
> And to clarify, there will definitely some cross SIG co-work between > this new SIG and Self-Healing SIG (there're some common requirements > even across self-healing and autoscaling features.). We also need to > make sure we do not provide any duplicated work against self-healing > SIG. As a start, let's only focus on autoscaling scenario, and make > sure we're doing it right before we move to multiple cases.
Sounds good! > If no objection, I will create the new SIG before next weekend and > plan a short schedule in Denver summit and PTG.
Thanks for driving this!
-- Kind regards,
Melvin Hillsman mrhillsman@gmail.com mobile: (832) 264-2646
--
May The Force of OpenStack Be With You,
*Rico Lin*irc: ricolin
-- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin
participants (6)
-
Adam Spiers
-
Ben Nemec
-
Duc Truong
-
Melvin Hillsman
-
Rico Lin
-
Sa Pham