[openstack-dev] [heat] We need more help for actions and review. And some PTG update for Heat

Rico Lin rico.lin.guanyu at gmail.com
Thu Sep 20 05:22:17 UTC 2018


Dear all

As we reach Stein and start to discuss what we should do in the next cycle,
I would like to raise voice for what kind of help we need and what target
we planning.
BTW, If you really can't start your contact with us with any English (we
don't mind any English skill you are)

*First of all, we need more developers, and reviewer. I would very much
like to give Heat core reviewer title to people if anyone provides fare
quality of reviews. So please help us review patches. Let me know if you
would like to be a part but got no clue on how can you started.*

Second, we need more help to achieve actions. Here I make a list of actions
base on what we discuss from PTG [1]. I mark some of them with (*) if it
looks like an easy contribution:

   - (*) Move interop tempest tests to a separate repo
   - Move python3 functional job to python3.6
   - (*) Implement upgrade check
   - (*) Copy templates from Cue project into the heat-templates repo
   - (*) Add Stein template versions
   - (*) Do document improvement or add documents for:
      - (*) Heat Event Notification list
         - Nice to have our own document and  provide a link to [2]
         - default heat service didn't enable notification, so might be
         mention and link to Notify page
      - (*) Autoscaling doc
      - (*) AutoHealing doc
      - (*) heat agent & heat container agent
      - (*) external resource
      - (*) Upgrade guideline
      - (*) Move document from wiki to in repo document
   - (*) Fix live properties (observe reality) feature and make sure all
   resource works
   - remove any legacy pattern from .zuul.yaml
   - Improve autoscaling and self-healing
   - Create Tempest test for self-healing scenario (around Heat integration)
   - (*) Examine all resource type and help to update if they do not sync
   up with physical resource

If you like to learn more of any above tasks, just reach out to me and
other core members, and we're more than happy to give you the background
and guideline to any of above tasks. Also, welcome to join our meeting and
raise topics for any tasks.
We actually got more tasks that need to be achieved (didn't list here maybe
because it's already start implemented or still under planning), so if you
didn't see any interesting task above, you can reach out to me and let me
know which specific area you're interested in. Also, you might want to go
through [1] or talk to other team members to see if any more comments added
in before you start working on any task.

Now here are some targets that we start to discuss or work in progress

   - Multi-cloud support
   - Within [5], we propose the ability to do multi-cloud orchestration,
      and the follow-on discussion is how can we provide the ability to use
      customized SSL options for multi-cloud or multi-region
      orchestration without violating any security concerns. What we plan to do
      now (after discussing with security sig (Barbican team)) is to
only support
      cacert for SSL which is less sensitive. Use a template file to store that
      cacert and give it to keystone session for providing SSL ability to
      connections. If that sounds like a good idea to all without much
concerns,
      I will implement it asap.
   - Autoscaling and self-healing improvement
      - This is a big complex task for sure and kind of relative to
      multiple projects. We got a fair number of users using
Autoscaling feature,
      but not much for self-healing for now. So we will focus on each
feature and
      the integration of two feature separately.
      - First, Heat got the ability to orchestrate autoscaling, but we need
      to improve the stability. Still go around our code base to see how can we
      modulize current implementation, and how can we improve from
here, but will
      update more information for all. We also starting to discuss autoscaling
      integration [3], which hopefully we can get a better solution and combine
      forces from Heat and Senlin as a long-term target. Please give your
      feedback if you also care about this target.
      - For self-healing, we propose some co-work on cross-project gatting
      in Self-healing-sig, which we still not generate tempest test out, but
      assume we can start to set up job and raise discussion for how
can we help
      projects to adopt that job. Also, we got discussions with Octavia team
      ([7], and [8]) and Monasca team about adopting the ability to
support event
      alarm/notification. Which we plan to put into actions. If anyone
also think
      those are important features, please provide your development
resources so
      we can get those feature done in this cycle.
      - For integrating two scenarios, I try to add more tasks into [6] and
      eliminate as many as we can. Also, plan to work on document
these scenarios
      down, so everyone can play with autoscaling+self-healing easily.
   - Glance resource update
      - We deprecate image resource in Heat for very long time, and now
      Glance got the ability to download images by URL, we should be able to
      adopt new image service and renew/add our Image resources. What's missing
      is the support of this feature in Devstack for we can use it to
test on the
      gate. There's already discussion raised in ML [9] and in PTG [10]. So
      hopefully we can help to provide a better test before we adopt
the feature.
   - Non-convergence mode deprecation discussion and User survey update
      - In PTG UC meeting, UC decides to renew User survey for projects.
      And Heat now already prepared a new question  [4] for it. The
reason why we
      raise that question is that we really like to learn from ops/users about
      what's adoption rate of convergence mode before we deprecated the
      non-convergence(legacy) mode. We gonna use that data to decide whether or
      not we're ready for next action.
   - KeyPair Issue in Heat Stack
   - A user-scope resource like KeyPair is a known issue for Heat (because
      all our actions are project-scope). For example, when User A creates
      Keypair+Instance in Stack. That keypair is specific user A
specific. If we
      update that stack by User B, keypair will not be accessible (since user B
      didn't get any authorize to get that keypair). Unless User B can
access the
      same keypair or another Keypair with same name and content.
      - For action and propose solutions, we gonna send a known issue note
      for users. Also will try to propose either of these two possible
solutions,
      to make Barbican integrated with Nova Keypair, or allow Keypair to change
      its scope. I aware there already discussion in Nova team about
changing to
      project-scope, but now we kind of waiting for that discussion to generate
      actions before we can say this issue is covered.
   - And more
      - Again, it's not possible to talk about all feature or plan in a
      single ML. So please take a look at our storyboard [11] if you
like to see
      anything to be improved. Also, it always accelerates tasks when
we got more
      resources to put on. So help us to develop, review, or provide
any feedback
      are very very welcome!

For any feedback added in etherpad but didn't get any comments, I will try
to raise discussion in meeting for them.

And last but not least, we got some sessions in Berlin for a project update
and Onboarding. And potentially also have a ops/users feedback forum, and
an autoscaling integration forum (if we actually been accepted ). So please
let me know how you like to have those sessions to be taken in place, and
what you wish to hear/learn from our sessions?

[1] https://etherpad.openstack.org/p/2018-Denver-PTG-Heat
[2]
https://wiki.openstack.org/wiki/SystemUsageData#orchestration.stack..7Bcreate.2Cupdate.2Cdelete.2Csuspend.2Cresume.7D..7Bstart.2Cerror.2Cend.7D
:
[3] https://etherpad.openstack.org/p/autoscaling-integration-and-feedback
[4] https://etherpad.openstack.org/p/heat-user-survey-brainstrom
[5]
https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bp/multiple-cloud-support
[6] https://storyboard.openstack.org/#!/story/2003690
[7] https://storyboard.openstack.org/#!/story/2003782
[8] https://storyboard.openstack.org/#!/story/2003773
[9]
http://lists.openstack.org/pipermail/openstack-dev/2018-August/134019.html
[10] https://etherpad.openstack.org/p/stein-ptg-glance-planning
[11] storyboard.openstack.org/#!/project/989

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180920/3ee5cb3c/attachment.html>


More information about the OpenStack-dev mailing list