Open Stack

Hi Rico,

Rico Lin <rico.lin.guanyu at gmail.com> wrote:
>bump this topic again, Would really like to hear from all:)

Again sorry for the slow reply!

>On Wed, Jul 11, 2018 at 8:50 PM Rico Lin <rico.lin.guanyu at gmail.com> wrote:
>> As we went through some discussion form Summit for self-healing sig, To
>> collect Use case is one of our goal in Rocky cycle.

Exactly.

>> Keep thinking how can we expose This SIG to users/ops and make this become
>> a regular thing.

Yes I agree - promoting visibility is really important in order for
the SIG to gain momentum, and we need to keep pushing on a regular
basis to achieve this.

>> Here's some idea that might help, also might be able to help other SIG as
>> well:
>>
>> ** Join user survey:*
>> It's possible for SIG to propose options in User survey.
>> If we going to do so, we should provide questions which can be answered by
>> selecting from options or let's said minimal written is preferred.
>> So what will the question be? Would like to hear from everyone for any
>> idea.

This sounds like a great idea to me!  I've submitted a story for this:

    https://storyboard.openstack.org/#!/story/2003423

and set up an etherpad for brainstorming:

    https://etherpad.openstack.org/p/self-healing-user-survey-questions

>> ** Expose our StoryBoard to user/ops*
>> Another idea is to expose our StoryBoard to user/ops. OpenStack
>> community currently didn't have any effective way to raise issues for
>> self-healing. If we expose StoryBoard to user/ops to allow them to raise
>> issues, users can directly file the entire story, instead of just reporting
>> part of the issue and that usually reply with `Oh, that's XXX
>> project's issue, we got nothing to do with it`.
>> Don't get this wrong, we got nothing to block user to raise story(issues)
>> in any project, including self-healing SIG. But I believe to specific tell
>> user where you can drop that story to trigger cross-project discussions
>> will be the right way instead of telling nothing and user not even know any
>> valid way to deal with issues. Imaging that when you first join a
>> community, there is a line tell you if you have a question about
>> self-healing/k8s/upgrade/etc here is where you can raise the issue, and
>> find help.
>> I will imagine we need to have people from teams to be around to deal with
>> issues and tell users/ops when they come. But for what I know, we actually
>> got attention from most of teams that concerns about self-healing.
>> I think in order to do so (if that's a good idea), we need someplace
>> better than ML to tell users/ops that here is where you can go when you
>> found your self-healing not working or you need any help. Also, I think
>> this might actually apply to other SIGs.

This sounds reasonable.  We already link to the StoryBoard from the
SIG portal wiki page:

    https://wiki.openstack.org/wiki/Self-healing_SIG#Community_Infrastructure_.2F_Resources

but yes we could also proactively announce this in places which would
reach more users and operators, inviting them to submit stories.  Can
you suggest how best to do this?  We could email the openstack and
openstack-operators lists, although TBH I have done this several times
in the past and not gotten much engagement - probably because both
lists are very high traffic.

>> ** Build gate job for self-healing task*
>> We have some use cases that already been demo around self-healing cases,
>> like Vitrage+Mistral, Heat+Mistral+Aodh, etc. Also, some scenarios are
>> under development. I believe there are values to generate a periodic task,
>> or even a cross-project gate to make sure we didn't break the general
>> self-healing use cases. If we can do so, I think users/ops will have the
>> better confidence to say self-healing is absolutely working in OpenStack.
>> Also, we don't need to build separate tempest plugin if we can find any
>> projects willing to host those test. Not speaking for the entire team, but
>> I think Heat might be able to provide something here.

I love this idea, and yes the self-healing-sig git repository could
absolutely be the home for this gating code.  I suspect that a big
part of the challenge will be to simulate failures in order to test
the self-healing functionality.  In fact we already have a story
regarding automated testing:

    https://storyboard.openstack.org/#!/story/2002129

although that is much more ambitious in scope, i.e. building a
complete framework which could support testing of many different
self-healing scenarios.  I have some documentation on the Eris project
which I am planning to upload to the repository on this.

However your proposal sounds less ambitious and more likely to be
achievable in the short-term, so I'd love to learn more about how you
think this might work (unfortunately I don't know much about Tempest
internals yet).

Thanks a lot for your ideas!  They are great - please keep them coming ;-)

Adam