[Openstack-operators] [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-operators/attachments/20180920/3ee5cb3c/attachment-0001.html>
More information about the OpenStack-operators
mailing list