Open Stack

Thanks Eric!

Initial thoughts - it would be helpful to have somewhere central to
collaboratively track all actions associated with the SIG.

My personal recommendation would be Trello, since I know for sure that
that would do the job very nicely.  But if Storyboard is considered
ready for this kind of use and is the preferred route, I'm happy to
give that a try instead.

Any opinions?

Eric Kao <ekcs.openstack at gmail.com> wrote:
>Many thanks, Adam, for laying the ground work for the SIG!
>
>Looking forward to working with everyone to drive the self-healing vision
>forward in OS!
>
>On 11/27/17, 6:19 AM, "Adam Spiers" <aspiers at suse.com> wrote:
>
>>TL;DR: the self-healing SIG is officially formed!  Watch the
>>openstack-sigs
>>mailing list for future developments.
>>
>>A longer version of this announcement can be found at
>>
>>
>>https://blog.adamspiers.org/2017/11/24/announcing-openstacks-self-healing-
>>sig/
>>
>>
>>A SIG is born!
>>--------------
>>
>>After an unofficial kick-off meeting at the last PTG in Denver, I
>>proposed the creation of a new self-healing SIG:
>>
>>
>>http://lists.openstack.org/pipermail/openstack-sigs/2017-September/000054.
>>html
>>
>>At the recent Summit in Sydney, we had a Forum session around 30
>>people attend the Sydney Forum session, which was extremely
>>encouraging! You can read more details in the etherpad, but here is
>>the quick summary ...
>>
>>Most importantly, we resolved the naming and scoping issues,
>>concluding that to avoid biting off too much in one go, it was better
>>to be pragmatic and start small:
>>
>>  - Initially focus on cloud infrastructure, and not worry too much
>>    about the user-facing impact of failures yet; we can add that
>>    concern whenever it makes sense (which is particularly relevant
>>    for telcos / NFV).
>>
>>  - Not worry too much about optimization initially; Watcher is
>>    possibly the only project focusing on this right now, and again we
>>    can expand to include optimization any time we want.
>>
>>Now that the naming and scoping issues are resolved, I am excited to
>>announce that the Self-healing SIG is officially formed!
>>
>>Discussion went beyond mere administravia, however:
>>
>>  - We collected a few initial use cases.
>>
>>  - We informally decided the governance of the SIG. I asked if anyone
>>    else would like to assume leadership, but noone seemed keen,
>>    dashing my hopes of avoiding extra work ;-)  But Eric Kao, PTL of
>>    Congress, generously offered to act as co-chair.
>>
>>  - We discussed health check APIs, which were mentioned in at least 2
>>    or 3 other Forum sessions this time round.
>>
>>  - We agreed that we wanted an IRC channel, and that it could host
>>    bi-weekly meetings. However as usual there was no clean solution
>>    to choosing a time which would suit everyone ;-/  I'll try to
>>    figure out what to do about this!
>>
>>
>>Get involved
>>------------
>>
>>You are warmly invited to join, if this topic interests you:
>>
>>  - Ensure you are subscribed to the openstack-sigs mailing list:
>>
>>      http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>>
>>    and watch out watch out for posts tagged =[self-healing]=.
>>
>>  - Bookmark https://wiki.openstack.org/wiki/Self_healing_SIG
>>    which is the SIG's official home.
>>
>>
>>Next steps
>>----------
>>
>>I will set up the IRC channel, and see if we can make progress on
>>agreeing times for regular IRC meetings.
>>
>>Other than this administravia, it is of course up to the community to
>>decide in which direction the SIG should go, but my suggestions are:
>>
>>  - Continue to collect use cases.  It makes sense to have a very
>>    lightweight process for this (at least, initially), so Eric has
>>    created a Google Doc and populated it with a suggested template and
>>    a first example:
>>
>>
>>https://docs.google.com/document/d/13N36g2RlUYs8mw7hbfRXw6y2Jc-V2XGrXgfPXP
>>pUvuU/edit?usp=sharing
>>
>>    Feel free to add your own based on this template.
>>
>>  - Collect links to any existing documentation or other resources which
>>    describe how existing services can be combined.  This awesome talk
>>    on Advanced Fault Management with Vitrage and Mistral is a perfect
>>    example:
>>
>>
>>https://www.openstack.org/videos/sydney-2017/advanced-fault-management-wit
>>h-vitrage-and-mistral
>>
>>    and here is another:
>>
>>
>>https://www.openstack.org/videos/barcelona-2016/building-self-healing-appl
>>ications-with-aodh-zaqar-and-mistral
>>
>>    but we need to make it easier for operators to understand which
>>    combinations like this are possible, and easier for them to be set
>>    up.
>>
>>  - Finish the architecture diagram drafted in Denver:
>>
>>
>>https://docs.google.com/drawings/d/1kEFtVpQ4c8HipSp34EVAkcSGmwyg1MzWf_H5oG
>>Ttl-Y/edit?usp=sharing
>>
>>  - At a higher level, we could document reference stacks which address
>>    multiple self-healing cases.
>>
>>  - Talk more with the OPNFV community to find out what capabilities
>>    they have which could be reused within non-NFV OpenStack clouds.
>>
>>  - Perform gaps analysis on the use cases, and liase with specific
>>    projects to drive development in directions which can address those
>>    gaps.
>>
>>_______________________________________________
>>openstack-sigs mailing list
>>openstack-sigs at lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>
>
>
>_______________________________________________
>openstack-sigs mailing list
>openstack-sigs at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs