Open Stack

>
> On Wed, Aug 15, 2018 at 4:30 AM Eric K <ekcs.openstack at gmail.com> wrote:
> >
> > Hi Rico,
> > Great ideas!
> >
> > For engaging ops, we have an opportunity at the co-located ops meetup in
> denver. I'm not very familiar with the process there, but the planning
> etherpad just went live not long ago:
> >
> > https://etherpad.openstack.org/p/ops-meetup-ptg-denver-2018
>

Thanks Eric, I already put this topic to
https://etherpad.openstack.org/p/ops-meetup-ptg-denver-2018 hope we can get
some discussion on this



> On Wed, Jul 11, 2018 at 5:50 AM, Rico Lin <rico.lin.guanyu at gmail.com>
> wrote:
>
>> Hi all
>>
>> As we went through some discussion form Summit for self-healing sig, To
>> collect Use case is one of our goal in Rocky cycle.
>> Keep thinking how can we expose This SIG to users/ops and make this
>> become a regular thing.
>> 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.
>>
>> ** 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.
>>
>> ** 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.
>>
>>
>> Those are my proposal, please help to give your opinions. Thanks all.
>>
>> --
>> May The Force of OpenStack Be With You,
>>
>> *Rico Lin*irc: ricolin
>>
>>
>>
>> _______________________________________________
>> 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
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-sigs/attachments/20180831/09735937/attachment.html>