Open Stack

Thanks Tim!  And thanks for the reminder - I've just created an
etherpad for brainstorming topics for Vancouver:

    https://etherpad.openstack.org/p/YVR-self-healing-brainstorming

Particularly keen to hear from operators who have interesting problems
which could potentially be solved with self-healing approaches ... and
I can't think of an OpenStack user with more interesting problems than
CERN, hint hint ;-)

Tim Bell <Tim.Bell at cern.ch> wrote:
>Adam,
>
>Happy to come along in Vancouver as soon as you have a slot. Thanks for all the work that's going into this SIG.
>
>Tim
>
>-----Original Message-----
>From: Adam Spiers <aspiers at suse.com>
>Reply-To: "openstack-sigs at lists.openstack.org" <openstack-sigs at lists.openstack.org>
>Date: Wednesday, 14 March 2018 at 16:50
>To: OpenStack SIGs list <openstack-sigs at lists.openstack.org>
>Subject: [Openstack-sigs] [self-healing] Dublin PTG summary
>
>    Hi all,
>
>    Thanks to everyone who made it to the self-healing SIG session at the
>    Dublin PTG!  We had around 30 people in the end, some really
>    productive conversations, and even a group photo!  Although some
>    people preferred to stay in the nice warm meeting room rather than
>    risk the freezing temperatures of the "Beast from the East" ;-)
>
>       https://www.dropbox.com/sh/dtei3ovfi7z74vo/AAB3g-QiXB-TBvvZMltPtpcUa/Self%20Healing%20SIG?dl=0&preview=DSC_4333.JPG
>
>    You can see the notes from the session here:
>
>       https://etherpad.openstack.org/p/self-healing-ptg-rocky
>
>    but below is a summary of the highlights.
>
>    Documentation of capabilities of existing projects
>    ==================================================
>
>        https://storyboard.openstack.org/#!/story/2001430
>
>    Prior to the PTG we started to collect information on all the existing
>    integration points available between different projects:
>
>        https://etherpad.openstack.org/p/self-healing-project-integrations
>
>    I showed my initial attempts at visualisation the relationships, but we
>    concluded that trying to visualise all integrations on a single graph
>    is probably too hard to do in a useful way, so it probably makes more
>    sense to visualise and document architectures use case by use case.
>    Nevertheless, having a complete list of integration points should
>    serve as a useful component in future documentation.
>
>    Documentation repository
>    ========================
>
>    We agreed to start documenting use cases and specs in our self-healing
>    sig repository:
>
>        https://git.openstack.org/cgit/openstack/self-healing-sig
>
>    Formerly this repository was empty and only existed so that we could
>    have StoryBoard project (this is currently a requirement due to the
>    way that StoryBoard projects are set up in OpenStack), but we realised
>    that it was a great place to collaborate on this information which
>    will pretty much always span a few projects, but not as many as
>    OpenStack's traditional cross-project initiatives do.
>
>    As a result I have populated it using the -specs cookiecutter
>    template, but still need to draft a template for use cases and tidy up
>    the index:
>
>        https://storyboard.openstack.org/#!/story/2001628
>
>    Discussions on various use cases
>    ================================
>
>    Some people are already keen to start work on use cases immediately,
>    which is great news.  I don't remember all the details, but one
>    example involved monitoring NICs on compute nodes, moving VMs away
>    from any compute node seen to be in a sub-optimal state (IIRC an
>    extension to Neutron's API might be needed to help with detecting
>    this), and then potentially handing over to an operator for manual
>    remediation after the automated self-healing phase.
>
>    I touched on this briefly during the presentation I gave on the
>    self-healing SIG to the London OpenStack Meetup on Monday night:
>
>        https://aspiers.github.io/openstack-meetup-london-march-2018-self-healing/#/use-case-1
>
>    Stakeholders contact list
>    =========================
>
>    One challenge we might face when working on self-healing use cases
>    involving multiple projects is simply getting stuck with an issue
>    relating to a specific project and not knowing the best person to ask
>    for help.  Of course it is always possible (and indeed advisable) to
>    ask on IRC / mailing lists, but we decided that it would be helpful to
>    know in advance the names of individuals in each project who have
>    already declared an interest in self-healing and volunteered to help
>    out.  So I built this etherpad:
>
>        https://etherpad.openstack.org/p/self-healing-contacts
>
>    Please consider signing up to help answer questions relating to your
>    area of expertise!
>
>    Health-check API
>    ================
>
>        https://storyboard.openstack.org/#!/story/2001439
>
>    Discussion with members of the API SIG on the new health-check API
>    initiative:
>
>        https://review.openstack.org/#/c/531456/
>
>    There seemed to be consensus that the API SIG would own driving of the
>    implementation of the health-check API, whereas the self-healing SIG
>    would own the subsequent work to determine and document the various
>    use cases for effectively consuming the API.  So the self-healing SIG
>    would be the "customer" of the API SIG, which seems to make sense as a
>    nice way of structuring the work organisationally.
>
>    Automated testing
>    =================
>
>    There was broad agreement that any implementations of self-healing use
>    cases (including standard HA functionality) should have corresponding
>    automated tests.  OPNFV has already done a lot of good work in this
>    area, and there were a few folks from the OPNFV world present, so
>    hopefully the connections established will lead to collaboration and
>    reuse of existing work in the future.
>
>    Since the PTG we have had a few more people express a desire to join
>    this initiative, which is great news:
>
>        http://lists.openstack.org/pipermail/openstack-dev/2018-March/128020.html
>        https://etherpad.openstack.org/p/extreme-testing-contacts
>
>    Operator feedback
>    =================
>
>    It's *crucial* that we hear feedback from operators on their
>    real-world experiences and opinions about how self-healing could help
>    them, since ultimately making operators' lives easier is the primary
>    goal of the SIG.
>
>    Unfortunately there were no operators present in Dublin, but since
>    then we have managed to collect some feedback from the Tokyo Ops
>    Meetup and London OpenStack Meetup, and hopefully the Vancouver Forum
>    will be an ideal opportunity to hear more.
>
>    If you are an operator reading this, please don't be shy!  Let us know
>    what problems you would like to see the self-healing SIG focus on!
>
>    On that note, I'll end with a final plea:
>
>    Please join us!
>    ===============
>
>    All participation is very welcome, no matter how small.  At this stage
>    we're especially interested in hearing about people's experiences,
>    opinions and ideas:
>
>      - Are you already implementing any self-healing functionality in
>        your OpenStack clouds?  If so, how are you doing it, and what's
>        working and not working?
>
>      - What self-healing functionality do you miss and would like to
>        see implemented in the future?
>
>    You can find us on:
>
>      - #openstack-self-healing on Freenode IRC
>
>      - this openstack-sigs at lists.openstack.org mailing list
>        (please use the [self-healing] tag)
>
>
>    _______________________________________________
>    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