[openstack-dev] [heat] Heat sessions & forum in Berlin Summit

[Rico Lin]

Dear all
Here are some Heat relative sessions in OpenStack summit for you this week.
Welcome everyone to join us and check it out!

*Orchestration Ops/Users feedback session*
Wed 14, 1:40pm - 2:20pm
CityCube Berlin - Level 3 - M-Räume 6
https://etherpad.openstack.org/p/heat-user-berlin

*Heat - Project Update*
Wed 14, 3:45pm - 4:05pm
CityCube Berlin - Level 3 - M-Räume 3
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22739/heat-project-update

*Autoscaling Integration, improvement, and feedback*
Thu 15, 9:00am - 9:40am
CityCube Berlin - Level 3 - M-Räume 8
https://etherpad.openstack.org/p/autoscaling-integration-and-feedback

*Heat - Project Onboarding*
Thu 15, 10:50am - 11:30am
CityCube Berlin - Level 3 - M-Räume 1
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22733/heat-project-onboarding


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-sigs][all] Berlin Forum for `expose SIGs and WGs`

[Rico Lin]

Hi all

To continue our discussion in Denver, we will have a forum [1] in Berlin on
*Wednesday, November 14, 11:50am-12:30pm CityCube Berlin - Level 3 -
M-Räume 8*
We will host the forum in an open discussion format, and try to get actions
from forum to make sure we can keep push what people need. So if you have
any feedback or idea, please join us.
I created an etherpad for this forum so we can collect information, get
feedback, and mark actions.
*https://etherpad.openstack.org/p/expose-sigs-and-wgs
<https://etherpad.openstack.org/p/expose-sigs-and-wgs> *

*For who don't know what is `expose SIGs and WGs`*
There is some started discussion in ML [2] , and in PTG session [3]. The
basic concept for this is to allow users/ops get a single window for
important scenario/user cases or issues into traceable tasks in single
story/place and ask developers be responsible (by changing the mission of
government policy) to co-work on that task. SIGs/WGs are so desired to get
feedbacks or use cases, so as for project teams (not gonna speak for all
projects/SIGs/WGs but we like to collect for more idea for sure). And
project teams got a central place to develop for specific user
requirements, or give document for more general OpenStack information. So
would like to have more discussion on how can we reach the goal by actions?
How can we change in TC, UC, Projects, SIGs, WGs's policy to bridge up from
user/ops to developers.


[1]
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22750/expose-sigs-and-wgs
[2]
http://lists.openstack.org/pipermail/openstack-sigs/2018-August/000453.html
[3]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134689.html
-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration

[Rico Lin]

Hi all, I'm glad to notify you all that our forum session has been accepted
[1] and that forum time schedule (Thursday, November 15, 9:50am-10:30am)
should be stable by now. So please save your schedule for it!!
Any feedback are welcome!



[1]
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22753/autoscaling-integration-improvement-and-feedback

On Tue, Oct 9, 2018 at 3:07 PM Rico Lin  wrote:

> a reminder for all, please put your ideas/thoughts/suggest actions in our
> etherpad [1],
> which we gonna use for further discussion in Forum, or in PTG if we got no
> forum for it.
> So we won't be missing anything.
>
>
>
> [1] https://etherpad.openstack.org/p/autoscaling-integration-and-feedback
>
> On Tue, Oct 9, 2018 at 2:22 PM Qiming Teng  wrote:
>
>> > >One approach would be to switch the underlying Heat AutoScalingGroup
>> > >implementation to use Senlin and then deprecate the AutoScalingGroup
>> > >resource type in favor of the Senlin resource type over several
>> > >cycles.
>> >
>> > The hard part (or one hard part, at least) of that is migrating the
>> existing
>> > data.
>>
>> Agreed. In an ideal world, we can transparently transplant the "scaling
>> group" resource implementation onto something (e.g. a library or an
>> interface). This sounds like an option for both teams to brainstorm
>> together.
>>
>> - Qiming
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration

[Rico Lin]

a reminder for all, please put your ideas/thoughts/suggest actions in our
etherpad [1],
which we gonna use for further discussion in Forum, or in PTG if we got no
forum for it.
So we won't be missing anything.



[1] https://etherpad.openstack.org/p/autoscaling-integration-and-feedback

On Tue, Oct 9, 2018 at 2:22 PM Qiming Teng  wrote:

> > >One approach would be to switch the underlying Heat AutoScalingGroup
> > >implementation to use Senlin and then deprecate the AutoScalingGroup
> > >resource type in favor of the Senlin resource type over several
> > >cycles.
> >
> > The hard part (or one hard part, at least) of that is migrating the
> existing
> > data.
>
> Agreed. In an ideal world, we can transparently transplant the "scaling
> group" resource implementation onto something (e.g. a library or an
> interface). This sounds like an option for both teams to brainstorm
> together.
>
> - Qiming
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-sigs] [First Contact] SIG PTG Summary

[Rico Lin]

On Thu, Sep 20, 2018 at 1:23 PM Kendall Nelson 
wrote:

Organization Guide
>
> ===
>
> Back in Sydney, we started discussing creating a guide for organizations
> to educate them on what their contributors need to be effective and
> successful members of the community. There is a patch out for review right
> now[7] that we want to get merged as soon as possible so that we can
> publicize it in Berlin and start introducing it when new companies join the
> foundation. It was concluded that we needed to add more rationalizations to
> the requirements and we delegated those out to ricolin, jungleboyj, and
> spotz to help mattoliverau with content. As soon as this patch gets merged,
> I volunteered to work to get it onto the soonest board meeting possible.
>
 Dear all,
As an action, I just post some suggest changes for `Technical` section
(with comments) in [7], please take a look.

>
> [7] https://review.openstack.org/#/c/578676
>
-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-sigs] [all][tc] We're combining the lists! (was: Bringing the community together...)

[Rico Lin]

On Fri, Sep 21, 2018 at 5:59 AM Melvin Hillsman 
wrote:
>
>  I agree all lists should be merged as discussed otherwise why not just
leave all things as they are :P
Yeah, if we merged all lists, it's much easier for all to know exactly
where they can go for trigger discussions.
I doubt all experienced developers and ops are subscribe all list that
relative to them.
>From this point, and combine with global reach out, we can easily give
correct information for newcomers.

I'm tired to put `[openstack-dev][Openstack-operators][Openstack-sigs]` in
front of my mail title, that just pure madness
--
May The Force of OpenStack Be With You,
Rico Lin
irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Rico Lin]

urce 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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration

[Rico Lin]

cool Duc, and it's nicely started:
https://etherpad.openstack.org/p/autoscaling-integration-and-feedback
I also submit the etherpad, will add you as moderator once it's selected
(don't know why, but can't add any more now from the web).

Please add whatever you like to that etherpad, I will try to input more
information ASAP.
all information will continue to be used with or without that forum.

On Wed, Sep 19, 2018 at 12:51 AM Duc Truong  wrote:

> Hi Rico,
>
> I'm the Senlin PTL and would be happy to have a forum discussion in
> Berlin about the future of autoscaling.
>
> Can you go ahead and start an etherpad to capture the proposed agenda
> and discussion items?  Also, feel free to submit the forum submission
> so that we can get it on the schedule.
>
> Thanks,
>
> Duc (dtruong)
>
> On Mon, Sep 17, 2018 at 8:28 PM Rico Lin 
> wrote:
>
>> *TL;DR*
>> *How about a forum in Berlin for discussing autoscaling integration (as a
>> long-term goal) in OpenStack?*
>>
>>
>> Hi all, as we start to discuss how can we join develop from Heat and
>> Senlin as we originally planned when we decided to fork Senlin from Heat
>> long time ago.
>>
>> IMO the biggest issues we got now are we got users using autoscaling in
>> both services, appears there is a lot of duplicated effort, and some great
>> enhancement didn't exist in another service.
>> As a long-term goal (from the beginning), we should try to join
>> development to sync functionality, and move users to use Senlin for
>> autoscaling. So we should start to review this goal, or at least we should
>> try to discuss how can we help users without break or enforce anything.
>>
>> What will be great if we can build common library cross projects, and use
>> that common library in both projects, make sure we have all improvement
>> implemented in that library, finally to use Senlin from that from that
>> library call in Heat autoscaling group. And in long-term, we gonna let all
>> user use more general way instead of multiple ways but generate huge
>> confusing for users.
>>
>> *As an action, I propose we have a forum in Berlin and sync up all effort
>> from both teams to plan for idea scenario design. The forum submission [1]
>> ended at 9/26.*
>> Also would benefit from both teams to start to think about how they can
>> modulize those functionalities for easier integration in the future.
>>
>> From some Heat PTG sessions, we keep bring out ideas on how can we
>> improve current solutions for Autoscaling. We should start to talk about
>> will it make sense if we combine all group resources into one, and inherit
>> from it for other resources (ideally gonna deprecate rest resource types).
>> Like we can do Batch create/delete in Resource Group, but not in ASG. We
>> definitely got some unsynchronized works inner Heat, and cross Heat and
>> Senlin.
>>
>> Please let me know who is interesting in this idea, so we can work
>> together and reach our goal step by step.
>> Also please provide though if you got any concerns about this proposal.
>>
>> [1] https://www.openstack.org/summit/berlin-2018/call-for-presentations
>> --
>> May The Force of OpenStack Be With You,
>>
>> *Rico Lin*irc: ricolin
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration

[Rico Lin]

*TL;DR*
*How about a forum in Berlin for discussing autoscaling integration (as a
long-term goal) in OpenStack?*


Hi all, as we start to discuss how can we join develop from Heat and Senlin
as we originally planned when we decided to fork Senlin from Heat long time
ago.

IMO the biggest issues we got now are we got users using autoscaling in
both services, appears there is a lot of duplicated effort, and some great
enhancement didn't exist in another service.
As a long-term goal (from the beginning), we should try to join development
to sync functionality, and move users to use Senlin for autoscaling. So we
should start to review this goal, or at least we should try to discuss how
can we help users without break or enforce anything.

What will be great if we can build common library cross projects, and use
that common library in both projects, make sure we have all improvement
implemented in that library, finally to use Senlin from that from that
library call in Heat autoscaling group. And in long-term, we gonna let all
user use more general way instead of multiple ways but generate huge
confusing for users.

*As an action, I propose we have a forum in Berlin and sync up all effort
from both teams to plan for idea scenario design. The forum submission [1]
ended at 9/26.*
Also would benefit from both teams to start to think about how they can
modulize those functionalities for easier integration in the future.

>From some Heat PTG sessions, we keep bring out ideas on how can we improve
current solutions for Autoscaling. We should start to talk about will it
make sense if we combine all group resources into one, and inherit from it
for other resources (ideally gonna deprecate rest resource types). Like we
can do Batch create/delete in Resource Group, but not in ASG. We definitely
got some unsynchronized works inner Heat, and cross Heat and Senlin.

Please let me know who is interesting in this idea, so we can work together
and reach our goal step by step.
Also please provide though if you got any concerns about this proposal.

[1] https://www.openstack.org/summit/berlin-2018/call-for-presentations
-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)

[Rico Lin]

Hope you all safely travel back to home now.

Here is the summarize from some discussions (as much as I can trigger or
attend) in PTG for SIGs/WGs expose and some idea for action,
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134689.html

I also like the idea to at least expose the information of SIGs/WGs right
away. Feel free to give your feedback.

And not like the following message matters to anyone, but just in case. I
believe this is a goal for all group in the community so just don't let who
your duty, position, or full hand of good tasks to limit what you think
about the relative of this goal with you. Give your positive or negative
opinions to help us get a better shape.


On Wed, Sep 12, 2018 at 11:47 PM Matt Riedemann  wrote:

> Rather than take a tangent on Kristi's candidacy thread [1], I'll bring
> this up separately.
>
> Kristi said:
>
> "Ultimately, this list isn’t exclusive and I’d love to hear your and
> other people's opinions about what you think the I should focus on."
>
> Well since you asked...
>
> Some feedback I gave to the public cloud work group yesterday was to get
> their RFE/bug list ranked from the operator community (because some of
> the requests are not exclusive to public cloud), and then put pressure
> on the TC to help project manage the delivery of the top issue. I would
> like all of the SIGs to do this. The upgrades SIG should rank and
> socialize their #1 issue that needs attention from the developer
> community - maybe that's better upgrade CI testing for deployment
> projects, maybe it's getting the pre-upgrade checks goal done for Stein.
> The UC should also be doing this; maybe that's the UC saying, "we need
> help on closing feature gaps in openstack client and/or the SDK". I
> don't want SIGs to bombard the developers with *all* of their
> requirements, but I want to get past *talking* about the *same* issues
> *every* time we get together. I want each group to say, "this is our top
> issue and we want developers to focus on it." For example, the extended
> maintenance resolution [2] was purely birthed from frustration about
> talking about LTS and stable branch EOL every time we get together. It's
> also the responsibility of the operator and user communities to weigh in
> on proposed release goals, but the TC should be actively trying to get
> feedback from those communities about proposed goals, because I bet
> operators and users don't care about mox removal [3].
>
> I want to see the TC be more of a cross-project project management
> group, like a group of Ildikos and what she did between nova and cinder
> to get volume multi-attach done, which took persistent supervision to
> herd the cats and get it delivered. Lance is already trying to do this
> with unified limits. Doug is doing this with the python3 goal. I want my
> elected TC members to be pushing tangible technical deliverables forward.
>
> I don't find any value in the TC debating ad nauseam about visions and
> constellations and "what is openstack?". Scope will change over time
> depending on who is contributing to openstack, we should just accept
> this. And we need to realize that if we are failing to deliver value to
> operators and users, they aren't going to use openstack and then "what
> is openstack?" won't matter because no one will care.
>
> So I encourage all elected TC members to work directly with the various
> SIGs to figure out their top issue and then work on managing those
> deliverables across the community because the TC is particularly well
> suited to do so given the elected position. I realize political and
> bureaucratic "how should openstack deal with x?" things will come up,
> but those should not be the priority of the TC. So instead of
> philosophizing about things like, "should all compute agents be in a
> single service with a REST API" for hours and hours, every few months -
> immediately ask, "would doing that get us any closer to achieving top
> technical priority x?" Because if not, or it's so fuzzy in scope that no
> one sees the way forward, document a decision and then drop it.
>
> [1]
>
> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134490.html
> [2]
>
> https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html
> [3] https://governance.openstack.org/tc/goals/rocky/mox_removal.html
>
> --
>
> Thanks,
>
> Matt
>
> ___
> openstack-sigs mailing list
> openstack-s...@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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [election][tc]Question for candidates about global reachout

[Rico Lin]

>
>
> For the candidates who are running for tc seats, please reply to this
> email to indicate if you are open to use certain social media app in
> certain region (like Wechat in China, Line in Japan, etc.), in order to
> reach out to the OpenStack developers in that region and help them to
> connect to the upstream community as well as answering questions or other
> activities that will help. (sorry for the long sentence ... )
>

We definitely need to reach to developers from each location in global. And
a way to expose technical community to some place more close to developer
and not creating to much burden to all. For me, if we can have channels for
broadcast our key information cross entire community (like what's next
TC/PTL election, what mission is been proposed, who people can talk to when
certain issue happens, who you can talk to when you got great idea, and
most importantly where are the right place you should go to) expose to all
and maybe encourge community leaders to join. A list of channels is not
hard to setup, but it will bring big different IMO and we can always adjust
what channel we have. What we can limit here is make sure always help the
new joiner to find the right place to engage.

Once we got connected to local developers and community, it's easier for TC
to guide all IMO. Will this work? Not sure! So why not we try and find
out!:)

>
>
Rico and I already sign up for Wechat communication for sure :)
>
Good to have you! Let's do it!!

BTW nice dicsussion today, thanks all who is there in TC room to share.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Openstack-sigs][Openstack-operators][all]Expose SIGs/WGs as single window for Users/Ops scenario

[Rico Lin]

 story/issue in a format that is useful, or how to trigger
   the attention from other projects to join this.


These are what I got from PTG, but let's start from here together and
scratch what's done shall we!!

P.S. Sorry about the bad writing, but have to catch a flight.

[1] https://storyboard.openstack.org/#!/story/2002684
[2]
http://lists.openstack.org/pipermail/openstack-sigs/2018-July/000432.html

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][glance] Heat image resource support issue

[Rico Lin]

Thanks Abhishek

I already add that to Glance PTG etherpad. Since we got schedule conflict
so just let me know if we should be there as well, otherwise hope you guys
can help to resolve that issue. Thx!

btw, if you do require us to be there, might better schedule in the
afternoon on Wed. or Thu.

On Thu, Sep 6, 2018 at 4:45 AM Abhishek Kekane  wrote:

> Hi Rico,
>
> Session times are not decided yet, could you please add your topic on [1]
> so that it will be on discussion list.
> Also glance sessions are scheduled from Wednesday to Friday between 9 to 5
> PM, so you can drop by as per your convenience.
>
> [] https://etherpad.openstack.org/p/stein-ptg-glance-planning
>
>
> Thanks & Best Regards,
>
> Abhishek Kekane
>
> On Thu, Sep 6, 2018 at 3:48 PM, Rico Lin 
> wrote:
>
>>
>> On Thu, Sep 6, 2018 at 12:52 PM Abhishek Kekane 
>> wrote:
>>
>>> Hi Rico,
>>>
>>> We will discuss this during PTG, however meantime you can add
>>> WSGI_MODE=mod_wsgi in local.conf for testing purpose.
>>>
>>
>> Cool, If you can let me know which session it's, I will try to be there
>> if no conflict
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [election][tc] Opinion about 'PTL' tooling

[Rico Lin]

On Mon, Sep 10, 2018 at 5:31 AM Doug Hellmann  wrote:

> Excerpts from jean-phili...@evrard.me's message of 2018-09-10 13:15:02
> +0200:
> > Hello everyone,
> >
> > In my candidacy [1], I mentioned that the TC should provide more tools
> to help the PTLs at their duties, for example to track community health.
> >
> > I have questions for the TC candidates:
> > - What is your opinion about said toolkit? Do you see a purpose for it?
> > - Do you think said toolkit should fall under the TC umbrella?
> >
> > After my discussion with Rico Lin (PTL of the Heat project, and TC
> candidate) yesterday, I am personally convinced that it would be a good
> idea, and that we should have those tools: As a PTL (but also any person
> interested to see health of projects) I wanted it and I am not alone. PTLs
> are focusing on their duties and, as a day is only composed of so few
> hours, it is possible they won't have the focus to work on said tools to
> track, in the longer term, the community.
> >
> > For me, tracking community health (and therefore a toolkit for the
> PTLs/community) is something TC should cover for good governance, and I am
> not aware of any tooling extracting metrics that can be easily visible and
> used by anyone. If each project started to have their own implementation of
> tools, it would be opposite to one of my other goals, which is the
> simplification of OpenStack.
> >
> > Thanks for reading me, and do not hesitate to ask me questions on the
> mailing lists, or in real life during the PTG!
> >
> > Regards,
> > Jean-Philippe Evrard (evrardjp)
> >
> > [1]:
> https://git.openstack.org/cgit/openstack/election/plain/candidates/stein/TC/jean-phili...@evrard.me
> >
>
> We've had several different sets of scripts at different times to
> extract review statistics from gerrit. Is that the sort of thing you
> mean?
>
> What information would you find useful?
>

First of all, I know I'm awake because jet lag, but it's surprise to see
you all are too! Are you guys really in Denver!? or just some cardboard
cut-out I saw!

Okay, let's back to the mail.
As a PTL (not like a good one, but try to do what I can and learn from
others), I do see the benifit to have tool kit
to properly alarm (or show to) PTL about how people been in projects. As
checking the health of projects been a big task for TCs for last cycle, I
believe this might be something we can further discussion in that TCs task.

Right now we're asking TCs to asisit team to get a health report. But if we
can provide a list of tools that mgith help PTLs (or cores) to generate
some information to see the health situation. so PTLs can see how's things
going after they adjust their strategies. For toolkits, I believe there're
already something we can collect for PTLs? So we can use what already there
and make sure we don't over taken everyone's time for this task.
I aware there are challenges when we talk about how to make nwe-join people
feel good and how can we help PTLs (with experiences or not) to adjust
their way or to get better communications cross projects so PTLs will get a
chances to share and learn from others if they see any improvement also
applied to their team as well.


Also I agree with Doug that it's improtant to bring this idea on table and
discuss about what exactly information we want to get from data. And what
information TCs feel helpful to track health condition.


Now this bring me some idea of suggestion for all that I think it's time to
renew some documentation in
https://docs.openstack.org/project-team-guide/ptl.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [election][tc] Announcing candidacy

[Rico Lin]

On Fri, Sep 7, 2018 at 9:21 PM Matt Riedemann  wrote:

> On 9/6/2018 1:49 PM, Rico Lin wrote:
> > * Cross-community integrations (K8s, CloudFoundry, Ceph, OPNFV)
>
> Are there some specific initiatives or deliverables you have in mind
> here, or just general open communication channels? It's very hard to
> gauge any kind of progress/success on the latter.
>

I'm refering on clear communication channels and go from Use cases to real
development tasks (As I try to explain in the last section of my candidacy).
And here's some specific initiatives or deliverables sample I got in mind.
* From StarlingX, some great improvement for Edge cases are delivered to
projects. And there're also communications cross StarlingX and TCs on how
to make it integrated with rest OpenStack projects (currently StarlingX
still using it's own forks of OpenStack projects). And there're other
projects that other organizations contribute to OpenStack or form another
communities that depend on OpenStack.
* We recently create a new repo `openstack-service-broker` [1]. Use Service
Broker (A project from CloudFoundry) expose external resources to
applications running in a PaaS. Which is exactly a integration cross
CloudFoundry and OpenStack (protentially with K8s too) base on specific
scenario.
* K8s as one of the most popular case here, I believe we already can see
some nice integration cross OpenStack and K8s. Include Manila, Keystone
support in K8s, Magnum become one of official deployment tool in K8s
community. Also I'm currently working on Integrate Heat AutoScaling to K8s
cluster autoscaler as well [2].
* OPNFV integrated with OpenStack as it's cluster provider.

So the goal here IMO is `how can we properly set up cross communication and
improve scenarios with use cases or help these scenarios to become
deliverable for user?`.
SIGs are one of the format that I believe can help to accelerate this goal.
As I mentioned in [3] and in goal `Strong the structure of SIGs`. We should
consider to allow SIGs to become that platform from use cases and scenario
to a trackable development tasks. I know there's nothing block a SIG to do
so, but there's also no guideline, structure format, or other resources to
make the path easier for SIG.

Hope these explains wht the goal is in my mind.

[1] https://github.com/openstack/openstack-service-broker
[2] https://github.com/kubernetes/autoscaler/pull/1226
[3]
http://lists.openstack.org/pipermail/openstack-sigs/2018-August/000453.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [election][tc] Announcing candidacy

[Rico Lin]

Dear all,

I'm announcing my candidacy for a position on the OpenStack Technical
Committee.

I'm Rico Lin. I have been in this community since 2014. And been

deeply involved with technical contributions [1], I start from working

with heat, which allows me to work on integration and management resources

from multiple projects.

I have served as Heat PTL for two years. Which allows me to learn

better on how we can join users and operators' experiences and requirements

and integrated with development workflow and technical decision processes.

Here are my major goals with this seat in TC:

* Cross-community integrations (K8s, CloudFoundry, Ceph, OPNFV)

* Provide guidelines

* Strong the structure of SIGs

* Application Infra

* Cross-cooperation between Users, Operators, and Developers

* Diversity

I'm already trying to put my goals to actions, still would really hope to
join

Technical Committee to bring more attention to those domains

Thank you for your consideration.

Best Regards,

Rico Lin

IRC: ricolin

Twitter: @ricolintw

https://www.openstack.org/community/members/profile/33346/rico-lin

http://stackalytics.com/?release=all_id=rico-lin=person-day


Here I put some explanations for my goals:

- Cross-community integrations (K8s, CloudFoundry, Ceph, OPNFV):

This is a long-term goal for our community, but would really like to see
this

getting more scenario for use cases, and a more clear target for
development.

As we talk about Edge, AI, etc. It's essential to bring real use cases

into this integration( like StarlingX bring some requirements cross-projects

to real use cases).

On the other hand, K8s-SIG, Self-healing sig, FEMDC SIG are all some nice

place for this kind of interacting and integrating to happen.


- Provide guidelines:

There is one WIP guideline from First Contact SIG I particular interesting

on. The `Guidelines for Organisations Contributing to OpenStack` [4]. This
is

something I believe is quite important for showing how can organizations

interacting with OpenStack community correctly. I try to work on the same

goal from event to event as well (give presentations like [5]). There are
some

other guidelines that need to update/renew as well (most of us, who already

reading ML and work in the community for long, might no longer require to
read

guidelines, but remember, whoever try to join now a day, still require an

up-to-date guideline to give them hints).


- Strong the structure of SIGs:

As I show in above two goals, SIGs plays some important roles. I do like to

trigger discussions on how can we strengthen the structure of SIGs. Make
them more

efficient and become someplace for users and ops can directly interact with

developers. For real use cases like an Edge computing use case issue, or

self-healing service issues. I can't think of a better place than FEMDC SIG

and Self-healing SIG to record and target these issues. We might be able to

allow Opts to feedback issues on SIG's StoryBoard and ask project teams to

connect and review with it. There might be multiple ways to do this. So

would really like to trigger this discussion.

- Application Infra:

We've updated our resolution with [3] and saying we care about what

applications needs on top of OpenStack. As for jobs from few projects are

taking the role and thinking about what application needs, we should provide

help with setting up community goals, making resolutions, or define what are

top priority applications (can be a short-term definition) we need to focus
on

and taking action items/guidelines and finding weaknesses, so others from

the community can follow (if they agree with the goals, but got no idea on
what

they can help, IMO this will be a good stuff).

- Cross-cooperation between Users, Operators, and Developers:

We have been losing some communication cross Users, Operators, and
Developers.

And it's never a good thing when users can share use cases, ops shares

experiences, developers shares code, but they won't make it to one another
not

if a user provides developers by them self. In this case, works like
StoryBoard

should be in our first priority. We need a more solid way to bring user
feedback

to developers, so we can actually learn what's working or not for each

feature. And maybe it's considerable, to strengthen the communication
between

TCs and UCs (User Committee). We take some steps (like merge PTG and

Ops-meetup) to this goal, but I believe we can make the interacting more
active.

- Diversity:

The math is easy. [2] shows we got around one-third of users from Asia (with

75% of users in China). Also IIRC, around the same percentage of developers.

But we got 0 in TC. The actual works are hard. We need forwards our

technical guideline to developers in Asia and provide chances to get more

feedback from them, so we can provide better technical resolutions which

should be able to tight developers all together. Which I think I'm a good

candidate for this.

[1] http

Re: [openstack-dev] [heat][glance] Heat image resource support issue

[Rico Lin]

On Thu, Sep 6, 2018 at 12:52 PM Abhishek Kekane  wrote:

> Hi Rico,
>
> We will discuss this during PTG, however meantime you can add
> WSGI_MODE=mod_wsgi in local.conf for testing purpose.
>

Cool, If you can let me know which session it's, I will try to be there if
no conflict
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][glance] Heat image resource support issue

[Rico Lin]

Since we all use devstack as the test environment, I can see it's required
that we allow this scenario works for devstack in the gateway. Do you got
any plan to fix [1] in short future?:)

[1]  https://review.openstack.org/#/c/545483/

On Thu, Sep 6, 2018 at 11:00 AM Brian Rosmaita 
wrote:

>
>
> On Wed, Sep 5, 2018 at 11:12 AM Rico Lin 
> wrote:
>
>>
>> On Wed, Sep 5, 2018 at 8:47 PM Brian Rosmaita 
>> wrote:
>>
>> Since Queens, Glance has had a 'web-download' import method that takes a
>>> URL [0].  It's enabled by default, but operators do have the ability to
>>> turn it off.  (There's an API call to see what methods are enabled in a
>>> particular cloud.)  Operators also have the ability to restrict what URLs
>>> are acceptable [1], but that's probably a good thing.
>>>
>>> In short, Glance does have the ability to do what you need since Queens,
>>> but there's no guarantee that it will be available in all clouds and for
>>> all URLs.  If you foresee that as a problem, it would be a good idea to get
>>> together with the Glance team at the PTG to discuss this issue.  Please add
>>> it as a topic to the Glance PTG planning etherpad [3] as soon as you can.
>>>
>> Cool! Thank Brian.
>> Sounds like something we can use, just one small question in my mind. In
>> order to use `web-download` in image resource, we need to create an empty
>> image than use import to upload that imge. I have try that scenrio by
>> myself now (I'm not really diving into detail yet) by:
>> 1. create an empty image(like `openstack image create --container-format
>> bare --disk-format qcow2 img_name`)
>> 2. and than import image  (like `glance image-import --import-method
>> web-download --uri
>> https://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img `)
>> But that image stuck in queued after first step.
>> dose this scenario supported by glance? Or where did I do wrong?
>>
>
> That scenario should work, unless you are running glance under uwsgi, in
> which case the task engine (used to import the image) does not run.  You
> can tell that's the problem if as an admin user you use the command 'glance
> task-list'.  You should see a task of type 'api_image_import' with status
> 'pending'.  (You can do 'glance task-show ' to see the details of
> the task.)
>
> If you are using devstack, you can apply this patch before you call
> stack.sh: https://review.openstack.org/#/c/545483/  .  It will allow
> everything except Glance to run under uwsgi.
>
>
>>
>>
>>>
>>> [0]
>>> https://developer.openstack.org/api-ref/image/v2/index.html#interoperable-image-import
>>> [1]
>>> https://docs.openstack.org/glance/latest/admin/interoperable-image-import.html#configuring-the-web-download-method
>>> [3] https://etherpad.openstack.org/p/stein-ptg-glance-planning
>>>
>>
>> --
>> May The Force of OpenStack Be With You,
>>
>> *Rico Lin*irc: ricolin
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][glance] Heat image resource support issue

[Rico Lin]

On Wed, Sep 5, 2018 at 8:47 PM Brian Rosmaita 
wrote:

Since Queens, Glance has had a 'web-download' import method that takes a
> URL [0].  It's enabled by default, but operators do have the ability to
> turn it off.  (There's an API call to see what methods are enabled in a
> particular cloud.)  Operators also have the ability to restrict what URLs
> are acceptable [1], but that's probably a good thing.
>
> In short, Glance does have the ability to do what you need since Queens,
> but there's no guarantee that it will be available in all clouds and for
> all URLs.  If you foresee that as a problem, it would be a good idea to get
> together with the Glance team at the PTG to discuss this issue.  Please add
> it as a topic to the Glance PTG planning etherpad [3] as soon as you can.
>
Cool! Thank Brian.
Sounds like something we can use, just one small question in my mind. In
order to use `web-download` in image resource, we need to create an empty
image than use import to upload that imge. I have try that scenrio by
myself now (I'm not really diving into detail yet) by:
1. create an empty image(like `openstack image create --container-format
bare --disk-format qcow2 img_name`)
2. and than import image  (like `glance image-import --import-method
web-download --uri
https://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img `)
But that image stuck in queued after first step.
dose this scenario supported by glance? Or where did I do wrong?


>
> [0]
> https://developer.openstack.org/api-ref/image/v2/index.html#interoperable-image-import
> [1]
> https://docs.openstack.org/glance/latest/admin/interoperable-image-import.html#configuring-the-web-download-method
> [3] https://etherpad.openstack.org/p/stein-ptg-glance-planning
>

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] Heat PTG

[Rico Lin]

Dear all

As PTG is near.
It's time to settle down the PTG format for Heat.

Here is the *PTG etherpad*:
https://etherpad.openstack.org/p/2018-Denver-PTG-Heat

This time we will run with *physical + online for all sessions*.
The online link for sessions will post on etherpad before the session
begins.

*We will only use Wednesday and Thursday, and our discussion will try to be
Asia friendly*, which means any sessions require the entire team effort
needs to happen in the morning.

Also* feel free to add topic suggestion* if you would like to raise any
discussion.
Otherwise, I see you at PTG(physical/online).

I'm *welcome any User/Ops feedbacks* as well, so feel free to leave any
message for us.



-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-sigs] [all] Bringing the community together (combine the lists!)

[Rico Lin]

+1 on this idea, people been posting around for the exactly same topic and
got feedback from ops or devs, but never together, this will help people do
discussion on the same table.

What needs to be done for this is full topic categories support under
`options` page so people get to filter emails properly.


On Fri, Aug 31, 2018 at 1:04 AM Jeremy Stanley  wrote:

> The openstack, openstack-dev, openstack-sigs and openstack-operators
> mailing lists on lists.openstack.org see an increasing amount of
> cross-posting and thread fragmentation as conversants attempt to
> reach various corners of our community with topics of interest to
> one or more (and sometimes all) of those overlapping groups of
> subscribers. For some time we've been discussing and trying ways to
> bring our developers, distributors, operators and end users together
> into a less isolated, more cohesive community. An option which keeps
> coming up is to combine these different but overlapping mailing
> lists into one single discussion list. As we covered[1] in Vancouver
> at the last Forum there are a lot of potential up-sides:
>
> 1. People with questions are no longer asking them in a different
> place than many of the people who have the answers to those
> questions (the "not for usage questions" in the openstack-dev ML
> title only serves to drive the wedge between developers and users
> deeper).
>
> 2. The openstack-sigs mailing list hasn't seem much uptake (an order
> of magnitude fewer subscribers and posts) compared to the other
> three lists, yet it was intended to bridge the communication gap
> between them; combining those lists would have been a better
> solution to the problem than adding yet another turned out to be.
>
> 3. At least one out of every ten messages to any of these lists is
> cross-posted to one or more of the others, because we have topics
> that span across these divided groups yet nobody is quite sure which
> one is the best venue for them; combining would eliminate the
> fragmented/duplicative/divergent discussion which results from
> participants following up on the different subsets of lists to which
> they're subscribed,
>
> 4. Half of the people who are actively posting to at least one of
> the four lists subscribe to two or more, and a quarter to three if
> not all four; they would no longer be receiving multiple copies of
> the various cross-posts if these lists were combined.
>
> The proposal is simple: create a new openstack-discuss mailing list
> to cover all the above sorts of discussion and stop using the other
> four. As the OpenStack ecosystem continues to mature and its
> software and services stabilize, the nature of our discourse is
> changing (becoming increasingly focused with fewer heated debates,
> distilling to a more manageable volume), so this option is looking
> much more attractive than in the past. That's not to say it's quiet
> (we're looking at roughly 40 messages a day across them on average,
> after deduplicating the cross-posts), but we've grown accustomed to
> tagging the subjects of these messages to make it easier for other
> participants to quickly filter topics which are relevant to them and
> so would want a good set of guidelines on how to do so for the
> combined list (a suggested set is already being brainstormed[2]).
> None of this is set in stone of course, and I expect a lot of
> continued discussion across these lists (oh, the irony) while we try
> to settle on a plan, so definitely please follow up with your
> questions, concerns, ideas, et cetera.
>
> As an aside, some of you have probably also seen me talking about
> experiments I've been doing with Mailman 3... I'm hoping new
> features in its Hyperkitty and Postorius WebUIs make some of this
> easier or more accessible to casual participants (particularly in
> light of the combined list scenario), but none of the plan above
> hinges on MM3 and should be entirely doable with the MM2 version
> we're currently using.
>
> Also, in case you were wondering, no the irony of cross-posting this
> message to four mailing lists is not lost on me. ;)
>
> [1] https://etherpad.openstack.org/p/YVR-ops-devs-one-community
> [2] https://etherpad.openstack.org/p/common-openstack-ml-topics
> --
> Jeremy Stanley
> _______
> openstack-sigs mailing list
> openstack-s...@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>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat][glance] Heat image resource support issue

[Rico Lin]

Hi Glance team

Glance V1 image API been deprecated for a long while, and V2 has been used
widely. Heat image resource would like to change to use V2 as well, but
there is an unsolved issue, which blocks us from adopting V2. Right now, to
image create require Heat to download the image to Heat service and
re-upload it to Glance. This behavior causes heat service a great burden
which in a heat team discussion (years ago), we decide to deprecated V1
Image resource in Heat and will add V2  image resource once this is
resolved.
So I have been wondering if there's some workaround for this issue? Or if
glance can support accept URL as image import (and then reuse client lib
to download to glance side)? Or if anyone got a better solution for this?

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OpenStack-dev][heat][keystone][security sig][all] SSL option for keystone session

[Rico Lin]

Hi all
I would like to trigger a discussion on providing directly SSL content for
KeyStone session. Since all team using SSL, I believe this maybe concerns
to other projects as well.

As we consider to implement customize SSL option for Heat remote stack [3]
(and multicloud support [1]), I'm trying to figure out what is the best
solution for this. Current SSL option in KeyStone session didn't allow us
to provide directly CERT/Key string, instead only allow us to provide
CERT/Key file path. Which is actually a limitation of python with the
version less than 3.7 ([2]). As we not gonna easily get ride of previous
python versions, we try to figure out what is the best solution we can
approach here.

Some way, we can think about, like using pipeline, or create a file,
encrypted it and send the file path out to KeyStone session.

Would like to hear more from all for any advice or suggestion on how can we
approach this.

[1] https://etherpad.openstack.org/p/ptg-rocky-multi-cloud
[2] https://www.python.org/dev/peps/pep-0543/
[3] https://review.openstack.org/#/c/480923/
 --
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Openstack-sigs][self-healing][heat][vitrage][mistral] Self-Healing with Vitrage, Heat, and Mistral

[Rico Lin]

Dear all

Back to Vancouver Summit, Ifat brings out the idea of integrating Heat,
Vitrage, and Mistral to bring better self-healing scenario.
For previous works, There already works cross Heat, Mistral, and Zaqar for
self-healing [1].
And there is works cross Vitrage, and Mistral [2].
Now we plan to start working on integrating two works (as much as it
can/should be) and to make sure the scenario works and keep it working.
The integrated scenario flow will look something like this:
An existing monitor detect host/network failure and send an alarm to
Vitrage -> Vitrage deduces that the instance is down (based on the topology
and based on Vitrage templates [2]) -> Vitrage triggers Mistral to fix the
instance -> application is recovered
We created an Etherpad [3] to document all discussion/feedbacks/plans (and
will add more detail through time)
Also, create a story in self-healing SIG to track all task.

The current plans are:

   - A spec for Vitrage resources in Heat [5]
   - Create Vitrage resources in Heat
   - Write Heat Template and Vitrage Template for this scenario
   - A tempest task for above scenario
   - Add periodic job for this scenario (with above task). The best place
   to host this job (IMO) is under self-healing SIG

To create a periodic job for self-healing sig means we might also need a
place to manage those self-healing tempest test. For this scenario, I think
it will make sense if we use heat-tempest-plugin to store that scenario
test (since it will wrap as a Heat template) or use vitrage-tempest-plugin
(since most of the test scenario are actually already there).
Not sure what will happen if we create a new tempest plugin for
self-healing and no manager for it.
We still got some uncertainty to clear during working on it, but the big
picture looks like all will works(if we doing all well on above tasks).
Please provide your feedback or question if you have any.
We do needs feedbacks and reviews on patches or any works.
If you're interested in this, please join us (we need users/ops/devs!).

[1] https://github.com/openstack/heat-templates/tree/master/hot/autohealing
[2]
https://github.com/openstack/self-healing-sig/blob/master/specs/vitrage-mistral-integration.rst
[3] https://etherpad.openstack.org/p/self-healing-with-vitrage-mistral-heat
[4] https://storyboard.openstack.org/#!/story/2002684
[5] https://review.openstack.org/#/c/578786

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [barbican][heat] Identifying secrets in Barbican

[Rico Lin]

For now we found two ways to get a secret, with secret href or with secret
URI(which is `secrets/UUID`).
We will turn to use  secret URI for now for Heat multi cloud support, but is
there any reason for Barbican client not to
accept only secrets UUID (Secret incorrectly specified error will shows up
when only provide UUID)?



On Thu, Jun 28, 2018 at 4:40 AM Zane Bitter  wrote:

> We're looking at using Barbican to implement a feature in Heat[1] and
> ran into some questions about how secrets are identified in the client.
>
> With most openstack clients, resources are identified by a UUID. You
> pass the UUID on the command line (or via the Python API or whatever)
> and the client combines that with the endpoint of the service obtained
> from the service catalog and a path to the resource type to generate the
> URL used to access the resource.
>
> While there appears to be no technical reason that barbicanclient
> couldn't also do this, instead of just the UUID it uses the full URL as
> the identifier for the resource. This is extremely cumbersome for the
> user, and invites confused-deputy attacks where if the attacker can
> control the URL, they can get barbicanclient to send a token to an
> arbitrary URL. What is the rationale for doing it this way?
>
>
> In a tangentially related question, since secrets are immutable once
> they've been uploaded, what's the best way to handle a case where you
> need to rotate a secret without causing a temporary condition where
> there is no version of the secret available? (The fact that there's no
> way to do this for Nova keypairs is a perpetual problem for people, and
> I'd anticipate similar use cases for Barbican.) I'm going to guess it's:
>
> * Create a new secret with the same name
> * GET /v1/secrets/?name==created:desc=1 to find out the
> URL for the newest secret with that name
> * Use that URL when accessing the secret
> * Once the new secret is created, delete the old one
>
> Should this, or whatever the actual recommended way of doing it is, be
> baked in to the client somehow so that not every user needs to
> reimplement it?
>
>
> Bottom line: how should Heat expect/require a user to refer to a
> Barbican secret in a property of a Heat resource, given that:
> - We don't want Heat to become the deputy in "confused deputy attack".
> - We shouldn't do things radically differently to the way Barbican does
> them, because users will need to interact with Barbican first to store
> the secret.
> - Many services will likely end up implementing integration with
> Barbican and we'd like them all to have similar user interfaces.
> - Users will need to rotate credentials without downtime.
>
> cheers,
> Zane.
>
> BTW the user documentation for Barbican is really hard to find. Y'all
> might want to look in to cross-linking all of the docs you have
> together. e.g. there is no link from the Barbican docs to the
> python-barbicanclient docs or vice-versa.
>
> [1] https://storyboard.openstack.org/#!/story/2002126
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat][tacker][heat-translator] deliverables of heat-translator library

[Rico Lin]

To continue the discussion in
http://lists.openstack.org/pipermail/openstack-dev/2018-June/131681.html

Add Tacker and heat-translator to make sure all aware this discussion

On Thu, Jun 21, 2018 at 12:28 AM Doug Hellmann 
wrote:

> Excerpts from Zane Bitter's message of 2018-06-20 12:07:49 -0400:
> > On 20/06/18 11:40, Rico Lin wrote:
> > > I send a release patch now https://review.openstack.org/#/c/576895/
> > > Also, add Bob Haddleton to this ML who is considering as PTL for
> > > heat-translator team
> >
> > Is it time to consider moving the heat-translator and tosca-parser repos
> > from being deliverables of Heat to deliverables of Tacker? The current
> > weird structure dates from the days of the experiment with OpenStack
> > 'Programs' (vs. Projects).
> >
> > Heat cores don't really have time to be engaging with heat-translator,
> > and Tacker is clearly the major user and the thing that keeps getting
> > blocked on needing patches merged and releases made.
>
> It sounds like it. I had no idea there was any reason to look to anyone
> other than the Heat PTL or liaison for approval of that release. A WIP
> on the patch would have been OK, too, but if the Tacker team is really
> the one responsible we should update the repo governance.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] Need new release of heat-translator library

[Rico Lin]

I send a release patch now https://review.openstack.org/#/c/576895/
Also, add Bob Haddleton to this ML who is considering as PTL for
heat-translator team

Ben Nemec  於 2018年6月20日 週三 下午10:26寫道：

>
>
> On 06/20/2018 02:58 AM, Patil, Tushar wrote:
> > Hi,
> >
> > Few weeks back, we had proposed a patch [1] to add support for
> translation of placement policies and that patch got merged.
> >
> > This feature will be consumed by tacker specs [2] which we are planning
> to implement in Rocky release and it's implementation is uploaded in patch
> [3]. Presently, the tests are failing on patch [3] becoz it requires newer
> version of heat-translator library.
> >
> > Could you please release a new version of heat-translator library so
> that we can complete specs[2] in Rocky timeframe.
>
> Note that you can propose a release to the releases repo[1] and then you
> just need the PTL or release liaison to sign off on it.
>
> 1: http://git.openstack.org/cgit/openstack/releases/tree/README.rst
>
> -Ben
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] Not available for meeting this week

[Rico Lin]

Hi team

As I'm not available to host our meeting this week, would like to ask if
there Are any issues we should target or discuss this week?
If there is none I suggest we skip meeting this week.

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][sdk][heat] Integrating OpenStack and k8s with a service broker

[Rico Lin]

Zane Bitter  於 2018年6月9日 週六 上午9:20寫道：
>
> IIUC you're talking about a Heat resource that calls out to a service
> broker using the Open Service Broker API? (Basically acting like the
> Kubernetes Service Catalog.) That would be cool, as it would allow us to
> orchestrate services written for Kubernetes/CloudFoundry using Heat.
> Although probably not as easy as it sounds at first glance ;)
In my previous glance, I was thought about our new service will also wrap
up API with Ansible playbooks. A playbook to create a resource, and another
playbook to control Service Broker API. So we can directly use that
playbook instead
of calling Service broker APIs. No?:)

I think we can start trying to build playbooks before we start planning on
crazy ideas:)
>
> It wouldn't rely on _this_ set of playbook bundles though, because this
> one is only going to expose OpenStack resources, which are already
> exposed in Heat. (Unless you're suggesting we replace all of the current
> resource plugins in Heat with Ansible playbooks via the service broker?
> In which case... that's not gonna happen ;)
Right, we should use OS::Heat::Stack to expose resources from other
OpenStack, not with this.
>
> So Heat could adopt this at any time to add support for resources
> exposed by _other_ service brokers, such as the AWS/Azure/GCE service
> brokers or other playbooks exposed through Automation Broker.
>

I like the idea to add support for resources exposed by other service
borkers

--
May The Force of OpenStack Be With You,

Rico Lin 林冠宇
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] Organizational diversity tag

[Rico Lin]

IMO, the goal is that we try to encourage the good, not to get in the way
to those who can't reach that goal.

A tag is a good way to encourage, but it also not a fair way for those
projects who barely got enough core member to review (Think about those
projects got less than four active cores). Wondering if anyone got ideas on
how we can reach that goal (tag can be a way, just IMO need to provide a
fair condition to all).

How about we set policy and document to encourage people to join core
reviewer (this can join forces with the Enterprise guideline we plan in
Forum) if they wish to provide diversity to project.

On the second idea, I think TC (or people who powered by TC) should provide
(or guidance project to provide) a health check report for projects. TCs
have been looking for Liaisons with projects ([1]). This definitely is a
good report as a feedback from projects to TC. (also a good way to
understand what each project been doing and is that project need any help).
So to provide a guideline for projects to understand how they can do
better. Guideline means both -1 and  +1 (for who running projects for long
enough to be a core/PTL, should at least understand that -1 only means
since this project is under TC's guidance, we just try to help.). Therefore
a -1 is important.

As an alternative, we can also try to target problem when it occurred, but
personally wonder who as a single core reviewer in team dear to speak out
in this case.

I think this is a hard issue to do, but we have to pick one action from all
actions and try to run and see. And it's better than keep things the way
they are and ignore things.


[1] https://wiki.openstack.org/wiki/Technical_Committee_Tracker#Liaisons

Michael Johnson  於 2018年6月7日 週四 上午2:48寫道：

> Octavia also has an informal rule about two cores from the same
> company merging patches. I support this because it makes sure we have
> a diverse perspective on the patches. Specifically it has worked well
> for us as all of the cores have different cloud designs, so it catches
> anything that would limit/conflict with the different OpenStack
> topologies.
>
> That said, we don't hard enforce this or police it, it is just an
> informal policy to make sure we get input from the wider team.
> Currently we only have one company with two cores.
>
> That said, my issue with the current diversity calculations is they
> tend to be skewed by the PTL role. People have a tendency to defer to
> the PTL to review/comment/merge patches, so if the PTL shares a
> company with another core the diversity numbers get skewed heavily
> towards that company.
>
> Michael
>
> On Wed, Jun 6, 2018 at 5:06 AM,   wrote:
> >> -Original Message-
> >> From: Doug Hellmann 
> >> Sent: Monday, June 4, 2018 5:52 PM
> >> To: openstack-dev 
> >> Subject: Re: [openstack-dev] [tc] Organizational diversity tag
> >>
> >> Excerpts from Zane Bitter's message of 2018-06-04 17:41:10 -0400:
> >> > On 02/06/18 13:23, Doug Hellmann wrote:
> >> > > Excerpts from Zane Bitter's message of 2018-06-01 15:19:46 -0400:
> >> > >> On 01/06/18 12:18, Doug Hellmann wrote:
> >> > >
> >> > > [snip]
> >> > Apparently enough people see it the way you described that this is
> >> > probably not something we want to actively spread to other projects at
> >> > the moment.
> >>
> >> I am still curious to know which teams have the policy. If it is more
> >> widespread than I realized, maybe it's reasonable to extend it and use
> it as
> >> the basis for a health check after all.
> >>
> >
> > A while back, Trove had this policy. When Rackspace, HP, and Tesora had
> core reviewers, (at various times, eBay, IBM and Red Hat also had cores),
> the agreement was that multiple cores from any one company would not merge
> a change unless it was an emergency. It was not formally written down (to
> my knowledge).
> >
> > It worked well, and ensured that the operators didn't get surprised by
> some unexpected thing that took down their service.
> >
> > -amrith
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TC] Stein Goal Selection

[Rico Lin]

Sean McGinnis  於 2018年6月5日 週二 上午2:07寫道：
>
> Python 3 First
> ==
>
> One of the things brought up in the session was picking things that bring
> excitement and are obvious benefits to deployers and users of OpenStack
> services. While this one is maybe not as immediately obvious, I think this
> is something that will end up helping deployers and also falls into the
tech
> debt reduction category that will help us move quicker long term.
>
> Python 2 is going away soon, so I think we need something to help compel
folks
> to work on making sure we are ready to transition. This will also be a
good
> point to help switch the mindset over to Python 3 being the default used
> everywhere, with our Python 2 compatibility being just to continue legacy
> support.
>
+1 on Python3 first goal
I think it's great if we can start investigating how projects been doing
with py3.5+. And to have a check job for py3.6 will be a nice start for
this goal. If it's possible, our goal should match with what most users are
facing. Mention 3.6  because of Ubuntu Artful and Fedora 26 use it by
default (see [1] for more info).

[1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131193.html


--
May The Force of OpenStack Be With You,
Rico Lin
irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TC] Stein Goal Selection

[Rico Lin]

Matt Riedemann  於 2018年6月8日 週五 上午6:49寫道：

> I haven't used it much, but it would be really nice if someone could
> record a modern 'how to storyboard' video for just basic usage/flows
> since most people are used to launchpad by now so dealing with an
> entirely new task tracker is not trivial (or at least, not something I
> want to spend a lot of time figuring out).
>
> I found:
>
> https://www.youtube.com/watch?v=b2vJ9G5pNb4
>
> https://www.youtube.com/watch?v=n_PaKuN4Skk
>
> But those are a bit old.
>
I create an Etherpad to collect Q on Migrate from Launchpad to StoryBoard
for Heat (most information were general). Hope this helps
https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
May The Force of OpenStack Be With You,
Rico Lin
irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TC] Stein Goal Selection

[Rico Lin]

Kendall Nelson  於 2018年6月8日 週五 上午4:26寫道：
>
> I think that these two goals definitely fit the criteria we discussed in
Vancouver during the S Release Goal Forum Session. I know Storyboard
Migration was also mentioned after I had to dip out to another session so I
wanted to follow up on that.
>
+1. To migrate to StoryBoard do seems like a good way to go.
Heat just moved to StoryBoard, so there is no much long-term running
experiences to share about, but it does look like a good way to target the
piece which we been missing of. A workflow to connect users, ops, and
developers (within Launchpad, we only care about bugs, and what generate
that bug? well...we don't care). With Story + Task-oriented things can
change (To me this is shiny).

For migrate experience, the migration is quick, so if there is no project
really really only can survive with Launchpad, I think there is no blocker
for this goal.

Also, it's quite convenient to target your story with your old bug, since
your story id is your bug id.

Since it might be difficult for all project directly migrated to it, IMO we
should at least have a potential goal for T release (or a long-term goal
for Stein?). Or we can directly set this as a Stein goal as well. Why?
Because of the very first Story ID actually started from 200(and as I
mentioned, after migrating, your story id is exactly your bug id ). So once
we generate bug with ID 200, things will become interesting (and hard
to migrate). Current is 1775759, so one or two years I guess?

To interpreted `might be difficult` above, The overall experience is great,
some small things should get improve:

   - I can't tell if current story is already reported or not. There is no
   way to filter stories and checking conflict if there is.
   - Things going slow if we try to use Board in StoryBoard to filter out a
   great number of stories (like when I need to see all `High Priority` tagged
   stories)
   - Needs better documentation, In Heat we create an Etherpad to describe
   and collect Q on how people can better adopt StoryBoard. It will be great
   if teams can directly get this information.

Overall, I think this is a nice goal, and it's actually painless to migrate.


--
May The Force of OpenStack Be With You,
Rico Lin
irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][sdk] Integrating OpenStack and k8s with a service broker

[Rico Lin]

Thanks, Zane for putting this up.
It's a great service to expose infrastructure to application, and a
potential cross-community works as well.
>
> Would you be interested in working on a new project to implement this
> integration? Reply to this thread and let's collect a list of volunteers
> to form the initial core review team.
>
Glad to help

> I'd prefer to go with the pure-Ansible autogenerated way so we can have
> support for everything, but looking at the GCP[5]/Azure[4]/AWS[3]
> brokers they have 10, 11 and 17 services respectively, so arguably we
> could get a comparable number of features exposed without investing
> crazy amounts of time if we had to write templates explicitly.
>
If we going to generate another project to provide this service, I believe
to use pure-Ansible will be a better option indeed.

Once service gets stable, it's actually quite easy(at first glance) for
Heat to adopt this (just create a service broker with our new service while
creating a resource I believe?).
Sounds like the use case of service broker might be when application
request for a single resource exposed with Broker. And the resource
dependency will be relatively simple. And we should just keep it simple and
don't start thinking about who and how that application was created and
keep the application out of dependency (I mean if the user likes to manage
the total dependency, they can consider using heat with service broker once
we integrated).

--
May The Force of OpenStack Be With You,

Rico Lin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Openstack-operators][heat] Heat Summit summary and project status

[Rico Lin]

Hi all
Summit is over for weeks.
Would like to share with team on what we got in Summit

*Heat Onboarding Session*
We didn't get many people shows up in Onboarding session this time, but we
do get much more view in our video.
Slide:
https://www.slideshare.net/GuanYuLin1/openinfra-summit-2018-vancouver-heat-onboarding
Video: https://www.youtube.com/watch?v=8rMkxdx5YKE
(You can find videos from previous Summits in Slide)

*Project Update Session*
Slide:
https://www.slideshare.net/GuanYuLin1/openinfra-summit-2018-vancouver-heat-project-update
Video: https://www.youtube.com/watch?v=h4UXBRo948k
(You can find videos from previous Summits in Slide)

*User feedback Session*
Etherpad:
https://etherpad.openstack.org/p/2018-Vancouver-Summit-heat-ops-and-users-feedback
(You can find Etherpad from the last Summit in Etherpad)

Apparently, we got a lot of users which includes a lot of different domains
(at least that's what I felt during summit). And according to feedbacks, I
think our plans mostly match with what requirements from users.(if not, it
still not too late to provide us feedbacks
https://etherpad.openstack.org/p/2018-Vancouver-Summit-heat-ops-and-users-feedback
)


*Project Status*
Also, we're about to release Rocky-2, so would like to share current
project status:
We got less bug reported than the last cycle. For features, we seem got
less implemented or WIP. We do get few WIP or under planned features:
Blazar resource support(review in progress)
Etcd support(work in progress)
Multi-Cloud support (work in progress)
Swift store for heat template (can input heat template from Swift)
We do need more reviewer and people willing to help with features.

For rocky release(about to release rocky-2)
we got around 700 reviews
Commits: 216
Filed Bugs: 56
Resolved Bugs: 34
(For reference. Here's Queens cycle number:
around 1700 reviews, Commits: 417, Filed Bugs: 166, Resolved Bugs: 122 )


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] : Query regarding bug 1769089

[Rico Lin]

Hi

As Kaz mentioned,
Since we moved to StoryBoard (instead of Launchapd) please maintain your
bug here: https://storyboard.openstack.org/#!/story/1769089

Also, I try to use the same template [1] as you did to create a stack in
master version and it works (I can't reproduce it)

If possible, can you trace log to find where that error is from, is it from
heat-eng.log, heat-api.log, or other where?

Also, Heat IRC is at #heat not  #openstack-heat  :)



[1] TEMPLATE

description: Template for router create
heat_template_version: '2013-05-23'
resources:
  router:
type: OS::Neutron::Router
properties:
  name: resourceRouter


2018-05-30 21:26 GMT+08:00 Kaz Shinohara :

> Hi,
>
>
> First off, sorry for being late to response.
>
> Looking at your comment,
> your environment is Newton & AFAIK Newton is EOL, even if you will wait
> for the fix, it will not be delivered to Newton.
> https://releases.openstack.org/
>
> Current my concern is that your raised issue may happen in Queens code too
> (latest maintained)
> Note: dashboard for heat is split out from Horizon since Queens.
>
> Let me check if I could reproduce your issue at my environment(Queens)
> first.
> I will update my result at https://storyboard.
> openstack.org/#!/story/1769089
>
> Cheers,
> Kaz
>
>
>
> 2018-05-30 21:56 GMT+09:00 Ashika Meher Majety :
>
>> Hello,
>>
>> We have raised a bug in launchpad and the bug link is as follows:
>> https://bugs.launchpad.net/heat-dashboard/+bug/1769089 .
>> Can anyone please provide a solution or fix for this issue since it's
>> been 20 days since we have created this bug.
>>
>> Thanks,
>> Ashika Meher
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat]no meeting is week

[Rico Lin]

Hi all

As OpenStack summit  happening this week, let’s skip Heat meeting today.
-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Openstack-operators][heat] Heat sessions in Vancouver summit!! And they're all in Tuesday!

[Rico Lin]

Dear all

As Summit is about to start, looking forward to meet all of you here.
Don't miss out sessions from Heat team. They're all on Tuesday!
Feel free to let me know if you hope to see anything or learn anything
from sessions.
Will try my best to prepare it for you.




*Tuesday 229:00am - 9:40am Users & Ops feedback for Heat *
Vancouver Convention Centre West - Level Two - Room 220
https://www.openstack.org/summit/vancouver-2018/summit-
schedule/events/21713/users-and-ops-feedback-for-heat


*11:00am - 11:20am Heat - Project Update*
Vancouver Convention Centre West - Level Two - Room 212
https://www.openstack.org/summit/vancouver-2018/summit-
schedule/events/21595/heat-project-update


*1:50pm - 2:30pm Heat - Project Onboarding*
Vancouver Convention Centre West - Level Two - Room 223
https://www.openstack.org/summit/vancouver-2018/summit-
schedule/events/21629/heat-project-onboarding


See you all on Tuesday!!

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators][heat][all] Heat now migrated to StoryBoard!!

[Rico Lin]

Bump the last time

Hi all,
As we keep adding more info to the migration guideline [1], you might like
to take a look again.
And do hope it will make things easier for you. If not, please find me in
irc or mail.

[1] https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info


2018-05-10 18:42 GMT+08:00 Rico Lin <rico.lin.gua...@gmail.com>:

> Hi all,
> As we keep adding more info to the migration guideline [1], you might like
> to take a look again.
> And do hope it will make things easier for you. If not, please find me in
> irc or mail.
>
> [1] https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info
>
> Here's the quick hint for you, your bug id is exactly your story id.
>
> 2018-05-07 18:27 GMT+08:00 Rico Lin <rico.lin.gua...@gmail.com>:
>
>> Hi all,
>>
>> I updated more information to this guideline in [1].
>> Please must take a view on [1] to see what's been updated.
>> will likely to keep update on that etherpad if new Q or issue found.
>>
>> Will keep trying to make this process as painless for you as possible,
>> so please endure with us for now, and sorry for any inconvenience
>>
>> *[1] https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info
>> <https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info>*
>>
>> 2018-05-05 12:15 GMT+08:00 Rico Lin <rico.lin.gua...@gmail.com>:
>>
>>> looping heat-dashboard team
>>>
>>> 2018-05-05 12:02 GMT+08:00 Rico Lin <rico.lin.gua...@gmail.com>:
>>>
>>>> Dear all Heat members and friends
>>>>
>>>> As you might award, OpenStack projects are scheduled to migrating ([5])
>>>> from Launchpad to StoryBoard [1].
>>>> For whom who like to know where to file a bug/blueprint, here are some
>>>> heads up for you.
>>>>
>>>> *What's StoryBoard?*
>>>> StoryBoard is a cross-project task-tracker, contains numbers of
>>>> ``project``, each project contains numbers of ``story`` which you can think
>>>> it as an issue or blueprint. Within each story, contains one or multiple
>>>> ``task`` (task separate stories into the tasks to resolve/implement). To
>>>> learn more about StoryBoard or how to make a good story, you can reference
>>>> [6].
>>>>
>>>> *How to file a bug?*
>>>> This is actually simple, use your current ubuntu-one id to access to
>>>> storyboard. Then find the corresponding project in [2] and create a story
>>>> to it with a description of your issue. We should try to create tasks which
>>>> to reference with patches in Gerrit.
>>>>
>>>> *How to work on a spec (blueprint)?*
>>>> File a story like you used to file a Blueprint. Create tasks for your
>>>> plan. Also you might want to create a task for adding spec( in heat-spec
>>>> repo) if your blueprint needs documents to explain.
>>>> I still leave current blueprint page open, so if you like to create a
>>>> story from BP, you can still get information. Right now we will start work
>>>> as task-driven workflow, so BPs should act no big difference with a bug in
>>>> StoryBoard (which is a story with many tasks).
>>>>
>>>> *Where should I put my story?*
>>>> We migrate all heat sub-projects to StoryBoard to try to keep the
>>>> impact to whatever you're doing as small as possible. However, if you plan
>>>> to create a new story, *please create it under heat project [4]* and
>>>> tag it with what it might affect with (like python-heatclint,
>>>> heat-dashboard, heat-agents). We do hope to let users focus their stories
>>>> in one place so all stories will get better attention and project
>>>> maintainers don't need to go around separate places to find it.
>>>>
>>>> *How to connect from Gerrit to StoryBoard?*
>>>> We usually use following key to reference Launchpad
>>>> Closes-Bug: ###
>>>> Partial-Bug: ###
>>>> Related-Bug: ###
>>>>
>>>> Now in StoryBoard, you can use following key.
>>>> Task: ##
>>>> Story: ##
>>>> you can find more info in [3].
>>>>
>>>> *What I need to do for my exists bug/bps?*
>>>> Your bug is automatically migrated to StoryBoard, however, the
>>>> reference in your patches ware not, so you need to change your commit
>>>> message to replace the old link to launchpad to new links to StoryBoard.
>>>>
>>>> *Do w

Re: [openstack-dev] [Openstack-operators][heat][all] Heat now migrated to StoryBoard!!

[Rico Lin]

Hi all,
As we keep adding more info to the migration guideline [1], you might like
to take a look again.
And do hope it will make things easier for you. If not, please find me in
irc or mail.

[1] https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info

Here's the quick hint for you, your bug id is exactly your story id.

2018-05-07 18:27 GMT+08:00 Rico Lin <rico.lin.gua...@gmail.com>:

> Hi all,
>
> I updated more information to this guideline in [1].
> Please must take a view on [1] to see what's been updated.
> will likely to keep update on that etherpad if new Q or issue found.
>
> Will keep trying to make this process as painless for you as possible,
> so please endure with us for now, and sorry for any inconvenience
>
> *[1] https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info
> <https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info>*
>
> 2018-05-05 12:15 GMT+08:00 Rico Lin <rico.lin.gua...@gmail.com>:
>
>> looping heat-dashboard team
>>
>> 2018-05-05 12:02 GMT+08:00 Rico Lin <rico.lin.gua...@gmail.com>:
>>
>>> Dear all Heat members and friends
>>>
>>> As you might award, OpenStack projects are scheduled to migrating ([5])
>>> from Launchpad to StoryBoard [1].
>>> For whom who like to know where to file a bug/blueprint, here are some
>>> heads up for you.
>>>
>>> *What's StoryBoard?*
>>> StoryBoard is a cross-project task-tracker, contains numbers of
>>> ``project``, each project contains numbers of ``story`` which you can think
>>> it as an issue or blueprint. Within each story, contains one or multiple
>>> ``task`` (task separate stories into the tasks to resolve/implement). To
>>> learn more about StoryBoard or how to make a good story, you can reference
>>> [6].
>>>
>>> *How to file a bug?*
>>> This is actually simple, use your current ubuntu-one id to access to
>>> storyboard. Then find the corresponding project in [2] and create a story
>>> to it with a description of your issue. We should try to create tasks which
>>> to reference with patches in Gerrit.
>>>
>>> *How to work on a spec (blueprint)?*
>>> File a story like you used to file a Blueprint. Create tasks for your
>>> plan. Also you might want to create a task for adding spec( in heat-spec
>>> repo) if your blueprint needs documents to explain.
>>> I still leave current blueprint page open, so if you like to create a
>>> story from BP, you can still get information. Right now we will start work
>>> as task-driven workflow, so BPs should act no big difference with a bug in
>>> StoryBoard (which is a story with many tasks).
>>>
>>> *Where should I put my story?*
>>> We migrate all heat sub-projects to StoryBoard to try to keep the impact
>>> to whatever you're doing as small as possible. However, if you plan to
>>> create a new story, *please create it under heat project [4]* and tag
>>> it with what it might affect with (like python-heatclint, heat-dashboard,
>>> heat-agents). We do hope to let users focus their stories in one place so
>>> all stories will get better attention and project maintainers don't need to
>>> go around separate places to find it.
>>>
>>> *How to connect from Gerrit to StoryBoard?*
>>> We usually use following key to reference Launchpad
>>> Closes-Bug: ###
>>> Partial-Bug: ###
>>> Related-Bug: ###
>>>
>>> Now in StoryBoard, you can use following key.
>>> Task: ##
>>> Story: ##
>>> you can find more info in [3].
>>>
>>> *What I need to do for my exists bug/bps?*
>>> Your bug is automatically migrated to StoryBoard, however, the reference
>>> in your patches ware not, so you need to change your commit message to
>>> replace the old link to launchpad to new links to StoryBoard.
>>>
>>> *Do we still need Launchpad after all this migration are done?*
>>> As the plan, we won't need Launchpad for heat anymore once we have done
>>> with migrating. Will forbid new bugs/bps filed in Launchpad. Also, try to
>>> provide new information as many as possible. Hopefully, we can make
>>> everyone happy. For those newly created bugs during/after migration, don't
>>> worry we will disallow further create new bugs/bps and do a second migrate
>>> so we won't missed yours.
>>>
>>> [1] https://storyboard.openstack.org/
>>> [2] https://storyboard.openstack.org/#!

Re: [openstack-dev] [Openstack-operators][heat][all] Heat now migrated to StoryBoard!!

[Rico Lin]

Hi all,

I updated more information to this guideline in [1].
Please must take a view on [1] to see what's been updated.
will likely to keep update on that etherpad if new Q or issue found.

Will keep trying to make this process as painless for you as possible,
so please endure with us for now, and sorry for any inconvenience

*[1] https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info
<https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info>*

2018-05-05 12:15 GMT+08:00 Rico Lin <rico.lin.gua...@gmail.com>:

> looping heat-dashboard team
>
> 2018-05-05 12:02 GMT+08:00 Rico Lin <rico.lin.gua...@gmail.com>:
>
>> Dear all Heat members and friends
>>
>> As you might award, OpenStack projects are scheduled to migrating ([5])
>> from Launchpad to StoryBoard [1].
>> For whom who like to know where to file a bug/blueprint, here are some
>> heads up for you.
>>
>> *What's StoryBoard?*
>> StoryBoard is a cross-project task-tracker, contains numbers of
>> ``project``, each project contains numbers of ``story`` which you can think
>> it as an issue or blueprint. Within each story, contains one or multiple
>> ``task`` (task separate stories into the tasks to resolve/implement). To
>> learn more about StoryBoard or how to make a good story, you can reference
>> [6].
>>
>> *How to file a bug?*
>> This is actually simple, use your current ubuntu-one id to access to
>> storyboard. Then find the corresponding project in [2] and create a story
>> to it with a description of your issue. We should try to create tasks which
>> to reference with patches in Gerrit.
>>
>> *How to work on a spec (blueprint)?*
>> File a story like you used to file a Blueprint. Create tasks for your
>> plan. Also you might want to create a task for adding spec( in heat-spec
>> repo) if your blueprint needs documents to explain.
>> I still leave current blueprint page open, so if you like to create a
>> story from BP, you can still get information. Right now we will start work
>> as task-driven workflow, so BPs should act no big difference with a bug in
>> StoryBoard (which is a story with many tasks).
>>
>> *Where should I put my story?*
>> We migrate all heat sub-projects to StoryBoard to try to keep the impact
>> to whatever you're doing as small as possible. However, if you plan to
>> create a new story, *please create it under heat project [4]* and tag it
>> with what it might affect with (like python-heatclint, heat-dashboard,
>> heat-agents). We do hope to let users focus their stories in one place so
>> all stories will get better attention and project maintainers don't need to
>> go around separate places to find it.
>>
>> *How to connect from Gerrit to StoryBoard?*
>> We usually use following key to reference Launchpad
>> Closes-Bug: ###
>> Partial-Bug: ###
>> Related-Bug: ###
>>
>> Now in StoryBoard, you can use following key.
>> Task: ##
>> Story: ##
>> you can find more info in [3].
>>
>> *What I need to do for my exists bug/bps?*
>> Your bug is automatically migrated to StoryBoard, however, the reference
>> in your patches ware not, so you need to change your commit message to
>> replace the old link to launchpad to new links to StoryBoard.
>>
>> *Do we still need Launchpad after all this migration are done?*
>> As the plan, we won't need Launchpad for heat anymore once we have done
>> with migrating. Will forbid new bugs/bps filed in Launchpad. Also, try to
>> provide new information as many as possible. Hopefully, we can make
>> everyone happy. For those newly created bugs during/after migration, don't
>> worry we will disallow further create new bugs/bps and do a second migrate
>> so we won't missed yours.
>>
>> [1] https://storyboard.openstack.org/
>> [2] https://storyboard.openstack.org/#!/project_group/82
>> [3] https://docs.openstack.org/infra/manual/developers.html#
>> development-workflow
>> [4] https://storyboard.openstack.org/#!/project/989
>> [5] https://docs.openstack.org/infra/storyboard/migration.html
>> [6] https://docs.openstack.org/infra/storyboard/gui/tasks_
>> stories_tags.html#what-is-a-story
>>
>>
>>
>> --
>> May The Force of OpenStack Be With You,
>>
>> *Rico Lin*irc: ricolin
>>
>>
>
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators][heat][all] Heat now migrated to StoryBoard!!

[Rico Lin]

looping heat-dashboard team

2018-05-05 12:02 GMT+08:00 Rico Lin <rico.lin.gua...@gmail.com>:

> Dear all Heat members and friends
>
> As you might award, OpenStack projects are scheduled to migrating ([5])
> from Launchpad to StoryBoard [1].
> For whom who like to know where to file a bug/blueprint, here are some
> heads up for you.
>
> *What's StoryBoard?*
> StoryBoard is a cross-project task-tracker, contains numbers of
> ``project``, each project contains numbers of ``story`` which you can think
> it as an issue or blueprint. Within each story, contains one or multiple
> ``task`` (task separate stories into the tasks to resolve/implement). To
> learn more about StoryBoard or how to make a good story, you can reference
> [6].
>
> *How to file a bug?*
> This is actually simple, use your current ubuntu-one id to access to
> storyboard. Then find the corresponding project in [2] and create a story
> to it with a description of your issue. We should try to create tasks which
> to reference with patches in Gerrit.
>
> *How to work on a spec (blueprint)?*
> File a story like you used to file a Blueprint. Create tasks for your
> plan. Also you might want to create a task for adding spec( in heat-spec
> repo) if your blueprint needs documents to explain.
> I still leave current blueprint page open, so if you like to create a
> story from BP, you can still get information. Right now we will start work
> as task-driven workflow, so BPs should act no big difference with a bug in
> StoryBoard (which is a story with many tasks).
>
> *Where should I put my story?*
> We migrate all heat sub-projects to StoryBoard to try to keep the impact
> to whatever you're doing as small as possible. However, if you plan to
> create a new story, *please create it under heat project [4]* and tag it
> with what it might affect with (like python-heatclint, heat-dashboard,
> heat-agents). We do hope to let users focus their stories in one place so
> all stories will get better attention and project maintainers don't need to
> go around separate places to find it.
>
> *How to connect from Gerrit to StoryBoard?*
> We usually use following key to reference Launchpad
> Closes-Bug: ###
> Partial-Bug: ###
> Related-Bug: ###
>
> Now in StoryBoard, you can use following key.
> Task: ##
> Story: ##
> you can find more info in [3].
>
> *What I need to do for my exists bug/bps?*
> Your bug is automatically migrated to StoryBoard, however, the reference
> in your patches ware not, so you need to change your commit message to
> replace the old link to launchpad to new links to StoryBoard.
>
> *Do we still need Launchpad after all this migration are done?*
> As the plan, we won't need Launchpad for heat anymore once we have done
> with migrating. Will forbid new bugs/bps filed in Launchpad. Also, try to
> provide new information as many as possible. Hopefully, we can make
> everyone happy. For those newly created bugs during/after migration, don't
> worry we will disallow further create new bugs/bps and do a second migrate
> so we won't missed yours.
>
> [1] https://storyboard.openstack.org/
> [2] https://storyboard.openstack.org/#!/project_group/82
> [3] https://docs.openstack.org/infra/manual/developers.
> html#development-workflow
> [4] https://storyboard.openstack.org/#!/project/989
> [5] https://docs.openstack.org/infra/storyboard/migration.html
> [6] https://docs.openstack.org/infra/storyboard/gui/
> tasks_stories_tags.html#what-is-a-story
>
>
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Openstack-operators][heat][all] Heat now migrated to StoryBoard!!

[Rico Lin]

Dear all Heat members and friends

As you might award, OpenStack projects are scheduled to migrating ([5])
from Launchpad to StoryBoard [1].
For whom who like to know where to file a bug/blueprint, here are some
heads up for you.

*What's StoryBoard?*
StoryBoard is a cross-project task-tracker, contains numbers of
``project``, each project contains numbers of ``story`` which you can think
it as an issue or blueprint. Within each story, contains one or multiple
``task`` (task separate stories into the tasks to resolve/implement). To
learn more about StoryBoard or how to make a good story, you can reference
[6].

*How to file a bug?*
This is actually simple, use your current ubuntu-one id to access to
storyboard. Then find the corresponding project in [2] and create a story
to it with a description of your issue. We should try to create tasks which
to reference with patches in Gerrit.

*How to work on a spec (blueprint)?*
File a story like you used to file a Blueprint. Create tasks for your plan.
Also you might want to create a task for adding spec( in heat-spec repo) if
your blueprint needs documents to explain.
I still leave current blueprint page open, so if you like to create a story
from BP, you can still get information. Right now we will start work as
task-driven workflow, so BPs should act no big difference with a bug in
StoryBoard (which is a story with many tasks).

*Where should I put my story?*
We migrate all heat sub-projects to StoryBoard to try to keep the impact to
whatever you're doing as small as possible. However, if you plan to create
a new story, *please create it under heat project [4]* and tag it with what
it might affect with (like python-heatclint, heat-dashboard, heat-agents).
We do hope to let users focus their stories in one place so all stories
will get better attention and project maintainers don't need to go around
separate places to find it.

*How to connect from Gerrit to StoryBoard?*
We usually use following key to reference Launchpad
Closes-Bug: ###
Partial-Bug: ###
Related-Bug: ###

Now in StoryBoard, you can use following key.
Task: ##
Story: ##
you can find more info in [3].

*What I need to do for my exists bug/bps?*
Your bug is automatically migrated to StoryBoard, however, the reference in
your patches ware not, so you need to change your commit message to replace
the old link to launchpad to new links to StoryBoard.

*Do we still need Launchpad after all this migration are done?*
As the plan, we won't need Launchpad for heat anymore once we have done
with migrating. Will forbid new bugs/bps filed in Launchpad. Also, try to
provide new information as many as possible. Hopefully, we can make
everyone happy. For those newly created bugs during/after migration, don't
worry we will disallow further create new bugs/bps and do a second migrate
so we won't missed yours.

[1] https://storyboard.openstack.org/
[2] https://storyboard.openstack.org/#!/project_group/82
[3]
https://docs.openstack.org/infra/manual/developers.html#development-workflow
[4] https://storyboard.openstack.org/#!/project/989
[5] https://docs.openstack.org/infra/storyboard/migration.html
[6]
https://docs.openstack.org/infra/storyboard/gui/tasks_stories_tags.html#what-is-a-story



-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Rico Lin]

2018-04-25 22:13 GMT+08:00 Jeremy Stanley <fu...@yuggoth.org>:
>
> On 2018-04-25 14:12:00 +0800 (+0800), Rico Lin wrote:
> [...]
> > I believe to combine API services into one service will be able to
> > scale much easier. As we already starting from providing multiple
> > services and binding with Apache(Also concern about Zane's
> > comment), we can start this goal by saying providing unified API
> > service architecture (or start with new oslo api service). If we
> > reduce the difference between implementation from API service in
> > each OpenStack services first, maybe will make it easier to manage
> > or upgrade (since we unfied the package requirements) and even
> > possible to accelerate APIs.
> [...]
>
> How do you see this as being either similar to or different from the
> https://git.openstack.org/cgit/openstack/oaktree/tree/README.rst
> effort which is currently underway?

I think it's different from oaktree, since oaktree is an upper layer which
depends on API Services (allow shade to connected with), And what I'm
saying is to unify all API Servers. An example will be like what tempest do
for tests, tempest provide cmd and tools to help you generate and run test
cases, each service only required to provide a plugin. So if first step (to
unified) is complete, we can even focus on enhancing API service for all,
and the cool part is, we only need to do it in a single place for all
projects. Think about what happens when Tempest trying to enhance test
performance (just do it and check the gate is green).
Also, what kevin's idea is to have a API service to replace all API
service, which IIUC will be a API server directly use RPC to reach
backend for each services in OpenStack. So it's also different too.

> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



--
May The Force of OpenStack Be With You,
Rico Lin
irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Rico Lin]

2018-04-25 0:04 GMT+08:00 Fox, Kevin M <kevin@pnnl.gov>:
>
> Yeah, I agree k8s seems to have hit on a good model where interests are
separately grouped from the code bases. This has allowed architecture to
not to be too heavily influenced by the logical groups interest.
>
> I'll go ahead and propose it again since its been a little while. In
order to start breaking down the barriers between Projects and start
working more towards integration, should the TC come up with an
architecture group? Get folks from all the major projects involved in it
and sharing common infrastructure.
>
> One possible pie in the sky goal of that group could be the following:
>
> k8s has many controllers. But they compile almost all of them into one
service. the kube-apiserver. Architecturally they could break them out at
any point, but so far they have been able to scale just fine without doing
so. Having them combined has allowed much easier upgrade paths for users
though. This has spurred adoption and contribution. Adding a new controller
isn't a huge lift to an operator. they just upgrade to the newest version
which has the new controller built in.
>

I believe to combine API services into one service will be able to scale
much easier. As we already starting from providing multiple services and
binding with Apache(Also concern about Zane's comment), we can start this
goal by saying providing unified API service architecture (or start with
new oslo api service). If we reduce the difference between implementation
from API service in each OpenStack services first, maybe will make it
easier to manage or upgrade (since we unfied the package requirements) and
even possible to accelerate APIs.

> Could the major components, nova-api, neutron-server, glance-apiserver,
etc be built in a way to have 1 process for all of them, and combine the
upgrade steps such that there is also, one db-sync for the entire
constellation?
>

I like Zane's idea of combining services in Compute Node.

> The idea would be to take Constellations idea one step farther. That the
Projects would deliver python libraries(and a binary for stand alone
operation). Constilations would actually provide a code deliverable, not
just reference architecture, combining the libraries together into a single
usable entity. Operators most likely would consume the Constilations
version rather then the individual Project versions.
>
> What do you think?

It won't hurt when we providing unified OpenStack command (and it's
actually a great stuff), and it should not break anything for API. Maybe
just one more API service call OpenStack API service and it base on teams
to said providing plugin or not. I think we will eventually reach the goal
in this way.

>
> Thanks,
> Kevin--
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Rico Lin]

2018-04-24 1:26 GMT+08:00 Doug Hellmann <d...@doughellmann.com>:
>
> Excerpts from Rico Lin's message of 2018-04-24 00:54:14 +0800:
> > ** What aspects of our policies or culture make contributing to
> > OpenStackmore difficult than contributing to other open source
projects?To
> > fully understand the map of OpenStack services is a huge challenge,
> > especially for new join developers. And for project teams, might not
>
> This is an interesting point that I haven't heard raised before.
> Typically the number of projects is used as an example of something
> that is confusing to users or deployers, but can you elaborate on
> how it is confusing to contributors?
Because in some cases, users provide contributors and when a user feature
jump in,
to clarify which projects to might be part of that feature will cause time
when they weren't in
OpenStack for long (as a contributor working on cross communities).
And usually,  when he/she send out an ML for such a cross-projects
usecase won't get much replied (really depends on teams).
For other cases, user rely on what developers' report to decides where they
should put resource on,
but developers just provides the first match (and seems usable) project he
can find in repositories.

>
> > provide new contributors guidelines to be quicker to become part of the
> > team. Finally, the format or WG/SIG/Team might confuse contributors.*
Which
>
> Do you mean because it isn't clear what sort of group to start in order
> to accomplish something?
exactly
>
> > of those would you change, and how?IMO to provides clear landscape will
> > help on give people better view on the whole map and might get the
better
> > idea on how to fit in their plan without spending too much time on
finding
> > where to contribute. Also, we need provides better ways to communicate
to
> > new contributors to at least make them feel welcome. Which maybe we can
try
> > to add in PTL/TC's (or other possible position) duty and to provide
better
> > guidelines to new join contributors who seems got no clue on what's the
> > project been working on or where the project needs help. Only people we
>
> What role do you think the First Contact SIG might play in that?

I think in this specific scenario, First Contact SIG can help define the
scope and suggest
the guideline. Because new developers always reach to SIG/project team
directly, and if it's
not working,  they might just try to work around issues and skip the
chances to join
OpenStack community.
>
> > really understand that project can provide such judgment, and it seems
like
> > a duty to provide guidelines to others (Aka help people working with
you).
> > Finally, I personally think it's a good idea to have SIG in OpenStack,
but
> > I think we need to provide technical guidelines to SIGs, so they can
make a
> > clear decision on what's their mission, where are the resources they can
> > use, and how they might be able to use it. A clear vision makes clear
> > actions.* Where else should we be looking for contributors?IMO we
actually
> > got a bunch new contributors around OpenStack (mostly for nova and
neutron
> > of course) and trying to figure out what they can/should do. Also
possibly
> > from other projects which might be doing overlapping jobs. Also to form
SIG
> > might be a more productive way to collect contributors.*
> >
> >
> >
> > May The Force of OpenStack Be With You,
> >
> > *Rico Lin*irc: ricolin
> >
> > 2018-04-23 22:06 GMT+08:00 Doug Hellmann <d...@doughellmann.com>:
> >
> > > [This is meant to be one of (I hope) several conversation-provoking
> > > questions directed at prospective TC members to help the community
> > > understand their positions before considering how to vote in the
> > > ongoing election.]
> > >
> > > Over the last year we have seen some contraction in the number of
> > > companies and individuals contributing to OpenStack. At the same
> > > time we have started seeing contributions from other companies and
> > > individuals. To some degree this contraction and shift in contributor
> > > base is a natural outcome of changes in OpenStack itself along with
> > > the rest of the technology industry, but as with any change it
> > > raises questions about how and whether we can ensure a smooth
> > > transition to a new steady state.
> > >
> > > What aspects of our policies or culture make contributing to OpenStack
> > > more difficult than contributing to other open source projects?
> > >
> > > Which of those would you change, and how?
> > >
> > > Where else should we be looking f

Re: [openstack-dev] [tc] campaign question related to new projects

[Rico Lin]

>
> [1]
http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html
>
> >
> > `Can projects provide cross-project gating?`
> >
> > Do think if it's possible, we should consider this when asking if a
service
> > aligns with our mission because not breaking rest of infrastructure is
part
> > of the definition of `to build`. And providing cross-project gate jobs
> > seems like a way to go. To stable the integration between projects and
> > prevent released a failed feature when other services trying to work on
new
> > ways and provide no guideline, ML, or solution, just only leave words
like
> > `this is not part of our function to fix`.
> >
> >
> >
> > And finally,
> >
> > If we can answer all above questions, try to put in with the more
accurate
> > number (like from user survey), and provides communications it needs,
will
> > definitely help in finding next official projects.
> >
> > Also, when the evaluation is done, we should also evaluate the how's
these
> > evaluation processes, how's guideline working for us? and which
questions
> > above doesn't make any sense?.
> >
> >
> > [1]
> >
https://governance.openstack.org/tc/reference/new-projects-requirements.html
> >
> >
> > May The Force of OpenStack Be With You,
> >
> > *Rico Lin*irc: ricolin
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How "active" should the TC be?

[Rico Lin]

*IMO TC should be more active as possible. Since we try to use this
position to make policies, we should also consider hard how we can
broadcast those policies to each developer to provide guidelines and to get
possible feedbacks.To reach out current/potential technical contributors,
to sell this technical community and to communicate with other parts
(UC/Board/other communities/ops/users) and bring ideas/actions to renew our
policies or to the entire technical community. That will need TCs jump into
local/global events, meetings and MLs.I believe it's not just about what TC
defines our own duty, but most of the developers believe in TC's
governance.So I think we should definitely be more active and keep trying
to renew our goals. Here's example, I pretty sure a lot of developers from
our community doesn't know exactly what policy we were made.Which provides
the higher risk for gaps between what TCs think OpenStack and what they try
to present in their local community. I'm pretty sure such gaps exist in the
most local community (which developers learn what's current OpenStack looks
like) in Asia.As for the discussion on how to organize TCs to be more
active. To make a policy for that actually make sense to me since all TCs
should read through and follow policies which they made. Second to try to
reach out to project teams, rest of community, and other communities should
be a good start.*


2018-04-23 21:27 GMT+08:00 Doug Hellmann <d...@doughellmann.com>:

> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
>
> We frequently have discussions about whether the TC is active enough,
> in terms of driving new policies, technology choices, and other
> issues that affect the entire community.
>
> Please describe one case where we were either active or reactive
> and how that was shown to be the right choice over time.
>
> Please describe another case where the choice to be active or
> reactive ended up being the wrong choice.
>
> If you think the TC should tend to be more active in driving change
> than it is today, please describe the changes (policy, culture,
> etc.) you think would need to be made to do that effectively (not
> which policies you want us to be more active on, but *how* to
> organize the TC to be more active and have that work within the
> community culture).
>
> If you think the TC should tend to be less active in driving change
> overall, please describe what policies you think the TC should be
> taking an active role in implementing.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How should we handle projects with overlapping feature sets?

[Rico Lin]

*Thanks, Doug for bringing out this campaign questionI think we have a
start now with providing a decent map to show services in OpenStack and
fill in with projects. What we should have and will be nice is to ask
projects to search through the map (with a brief introduction of services)
when they're registering. To prevent overlapping from the very beginning
seems to be the most ideal, which might also mean it's actually our
responsibility to search through what exactly a project aims to and what
kind of feature it will provide when we allow people to register a project.
We can also discuss about to let projects know that we encourage new ideas
but we not encourage provides overlapping features just because you think
the service is bad and you don't like to fix it (IMO to encourage people to
point out problems and even try to fix it is very important when talking
about continuing efforts). And to give credits instead of warnings might
work better.* How (and whether) the community would be able to replace the
implementationof any given component with a new set of technologies by
"startingfrom scratch".With try to make such action as a long-term
community goal, might be possible to said we're able to do it (if this new
technology does matters, like containerize), and it might be even better
than wait for people to pick up the job and keep asking him `are we there
yet?`. We have to be really careful to prevent changing the behavior of
services or cause a huge burden to developers.* Where do you draw the line
at "gratuitous"?When a project is about more than 80% chances to dead or no
maintainer, and pure overlapping effort.* What benefits and drawbacks do
you see in supporting multiple toolswith similar features?It's good and
allow people from multiple tools to help construct the bridge to us
together. What I concern is we should try to decide a pattern and make it a
success instead of letting parallel jobs works on similar features. So we
can have a preview version of all other paths. And if we can make sure our
success path first, we can even look back and provide features plus bug
fixes to other tools. That brings a question back, `what're users using the
most?`* How would our community be different, in positive and negative
ways,if we were more strict about avoiding such overlap?To allow
concentrate our development energy on features, also to prevent lack of
diversity/ideas/activity for those projects we promise to provide guideline
when we allow them to stay under TC's governance. What we should also try
to prevent it when it's overlap but exists project didn't provide fair
communication or close their mind to new features/fixes. Which we should
strong/change part of our TC resolutions and prevent this because that
might just lead to a negative way that people quitting on providing new
innovation.*



May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin


2018-04-23 21:50 GMT+08:00 Doug Hellmann <d...@doughellmann.com>:

> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
>
> In the course of evaluating new projects that have asked to join
> as official members of the OpenStack community, we often discuss
> whether the feature set of the project overlaps too much with other
> existing projects. This came up within the last year during Glare's
> application, and more recently as part of the Adjutant application.
>
> Our current policy regarding Open Development is that a project
> should cooperate with existing projects "rather than gratuitously
> competing or reinventing the wheel." [1] The flexibility provided
> by the use of the term "gratuitously" has allowed us to support
> multiple solutions in the deployment and telemetry problem spaces.
> At the same time it has left us with questions about how (and
> whether) the community would be able to replace the implementation
> of any given component with a new set of technologies by "starting
> from scratch".
>
> Where do you draw the line at "gratuitous"?
>
> What benefits and drawbacks do you see in supporting multiple tools
> with similar features?
>
> How would our community be different, in positive and negative ways,
> if we were more strict about avoiding such overlap?
>
> Doug
>
> [1] https://governance.openstack.org/tc/reference/new-projects-
> requirements.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



--

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Rico Lin]

** What aspects of our policies or culture make contributing to
OpenStackmore difficult than contributing to other open source projects?To
fully understand the map of OpenStack services is a huge challenge,
especially for new join developers. And for project teams, might not
provide new contributors guidelines to be quicker to become part of the
team. Finally, the format or WG/SIG/Team might confuse contributors.* Which
of those would you change, and how?IMO to provides clear landscape will
help on give people better view on the whole map and might get the better
idea on how to fit in their plan without spending too much time on finding
where to contribute. Also, we need provides better ways to communicate to
new contributors to at least make them feel welcome. Which maybe we can try
to add in PTL/TC's (or other possible position) duty and to provide better
guidelines to new join contributors who seems got no clue on what's the
project been working on or where the project needs help. Only people we
really understand that project can provide such judgment, and it seems like
a duty to provide guidelines to others (Aka help people working with you).
Finally, I personally think it's a good idea to have SIG in OpenStack, but
I think we need to provide technical guidelines to SIGs, so they can make a
clear decision on what's their mission, where are the resources they can
use, and how they might be able to use it. A clear vision makes clear
actions.* Where else should we be looking for contributors?IMO we actually
got a bunch new contributors around OpenStack (mostly for nova and neutron
of course) and trying to figure out what they can/should do. Also possibly
from other projects which might be doing overlapping jobs. Also to form SIG
might be a more productive way to collect contributors.*



May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin



2018-04-23 22:06 GMT+08:00 Doug Hellmann <d...@doughellmann.com>:

> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
>
> Over the last year we have seen some contraction in the number of
> companies and individuals contributing to OpenStack. At the same
> time we have started seeing contributions from other companies and
> individuals. To some degree this contraction and shift in contributor
> base is a natural outcome of changes in OpenStack itself along with
> the rest of the technology industry, but as with any change it
> raises questions about how and whether we can ensure a smooth
> transition to a new steady state.
>
> What aspects of our policies or culture make contributing to OpenStack
> more difficult than contributing to other open source projects?
>
> Which of those would you change, and how?
>
> Where else should we be looking for contributors?
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question related to new projects

[Rico Lin]

Thanks, Doug, for raising this campaign question


Here are my answers:


***How you would evaluate a project's application in general

First I would work through the requirements ([1]) to evaluate projects.
Since most of the requirements are specific enough. And here's more
important part, to leave evaluate logs or comments for projects which we
considered but didn't reach some requirements. It's very important to guide
projects to cross over requirements (and remember, a `-1` only means we
trying to help).

Then, I work on questions, like:

`How many user are interesting to/needs the functionality that service
provided?`

`How active is this project and how's the diversity of contributors?`

`Is this project required cross communities/projects cooperation? If yes,
how's the development workflows  are working between communities/projects?`

And last but is one of the most important questions,

`Is this service aligns with the OpenStack Mission`? (and let's jump to
next question to answer this part)



**What sorts of things do you consider when deciding whether a project
"aligns with the OpenStack Mission," for example?*

I would consider things like:

`Is the project's functionality complete the OpenStack infrastructure map?`

Asking from user requirement and functionality point of view, `how's the
project(services) will make OpenStack better infrastructure for
user/operators?` and `how's this functionality provide a better life for
OpenStack developers?`

`Is the project provides better integration point between communities`

To build a better infrastructure, IMO it's also important to ask if a
project (service) really help on integration with other communities like
Kubernetes, OPNFV, CEPH, etc. I think to keep us as an active
infrastructure to solutions is part of our mission too.

`Is it providing functionality which we can integrate with current projects
or SIG instead?`

In short, we should be gathering our development energy, to really achieve
the jobs which is exactly why we spend times on trying to find official
projects and said this is part of our mission to work on. So when new
projects jump out, it's really important to discuss cross-project `is it
suitable for projects integrated and join force on specific functionality?`
(to do this while evaluating a project instead of when it's creating might
not be the best time to said `please integrate or join forces with other
teams together`(not even with a smiling face), but it's never too late for
a non-official/incubating project to consider about this). I really don't
like to to see any project get higher chances to die just because
developers chance their developing focus. It's happening when projects are
all willing to do the functionality, but no communication between(some
cases, not even now other projects exists), and new/old projects dead, then
TC needs to spend the time to pick those projects out. So IMO, it's worth
to spend times to investigate on whether projects can be joined. Or ideally
to put a resolution said, it's project's obligation to help on this, and
help other join force to be part of the team.

`Can projects provide cross-project gating?`

Do think if it's possible, we should consider this when asking if a service
aligns with our mission because not breaking rest of infrastructure is part
of the definition of `to build`. And providing cross-project gate jobs
seems like a way to go. To stable the integration between projects and
prevent released a failed feature when other services trying to work on new
ways and provide no guideline, ML, or solution, just only leave words like
`this is not part of our function to fix`.



And finally,

If we can answer all above questions, try to put in with the more accurate
number (like from user survey), and provides communications it needs, will
definitely help in finding next official projects.

Also, when the evaluation is done, we should also evaluate the how's these
evaluation processes, how's guideline working for us? and which questions
above doesn't make any sense?.


[1]
https://governance.openstack.org/tc/reference/new-projects-requirements.html


May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Elections][TC] Announcing Rico Lin candidacy for TC

[Rico Lin]

Dear all,

I'd like to announce my candidacy for a seat on the OpenStack Technical
Committee.

I'm Rico Lin, employed by EasyStack, full-time OpenStacker.
I have been in this community since 2014. And been deeply involved with
technical contribution [1], mostly around Orchestration service which allows
me to work on integration and management resources cross-projects. Also, I
have served as PTL for three cycles. Which allows me to learn better on how
we can join users and operators' experiences and requirements and integrated
with development workflow and technical decision processes.


Here are my major goals with this seat in TC:

- Application:
We've updated our resolution with [3] and saying we care about what
applications needs on top of OpenStack. As for jobs from few projects are
taking the role and thinking about what application needs, we should provide
help with setting up community goals, making resolutions, or define what are
top priority applications (can be a short-term definition) we need to focus
on
and taking action items/guidelines and finding weaknesses, so others from
community can follow (if they agree with the goals, but got no idea on what
they can help, IMO this will be a good stuff).

- Cooperate with Users, Operators, and Developers:
We have been losing some communication cross Users, Operators, and
Developers.
And it's never a good thing when users can share use cases, ops shares
experiences, developers shares code, but they won't make it to one another
not
if a user provides developers by them self. In this case, works like
StoryBoard
should be in our first priority. We need a more solid way to get user
feedback
for developers, so we can actually learn what's working or not for each
feature. And maybe it's considerable, to strengthen the communication
between
TCs and UCs (User Committee).

- Diversity:
The math is easy. [2] shows we got around one-third of users from Asia (with
75% of users in China). Also IIRC, around the same percentage of developers.
But we got 0 in TC. The actual works are hard. We need forwards our
technical guideline to developers in Asia and provide chances to get more
feedback from them, so we can provide better technical resolutions which
should be able to tight developers all together. Which I think I'm a good
candidate for this.

- Reach out for new blood:
With cloud getting more mature. It's normal that cloud developers need to
works in multiple communities, and they might comes and goes (mostly based
on their job definition from their enterprise), so we need more new
developers. And most important is to provides more chances for them to stay.
Which I know there are many new join developers struggle with finding ways
to fit in each project. We need ways to shorten their onboarding time, so
they can make good works during they're in our community.

- Paying the debt:
Our community has done a great job on changing our resolutions and
guidelines to adopt new trends and keep ourself sharp. TCs try really hard
to migrate our path and do the magic. IMO, we need more effects on some
specific jobs (like cross-project for Application infra. or Storyboard
migrate), I do like to keep that going and closing our technical debts,
so we can have room for new.


Thank you for your consideration.

Best Regards,
Rico Lin (ricolin)

[1] http://stackalytics.com/?release=all_id=rico-lin=person-day
[2] https://www.openstack.org/assets/survey/OpenStack-User-Survey-Nov17.pdf
[3]
https://review.openstack.org/#/c/447031/5/resolutions/20170317-cloud-applications-mission.rst

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-ops][heat][PTG] Heat PTG Summary

[Rico Lin]

Hi Heat devs and ops

It's a great PTG plus SnowpenStack experience. Now Rocky started. We
really need all kind of input and effort to make sure we're heading toward
the right way.

Here is what we been discussed during PTG:

   - Future strategy for heat-tempest-plugin & functional tests
   - Multi-cloud support
   - Next plan for Heat Dashboard
   - Race conditions for clients updating/deleting stacks
   - Swift Template/file object support
   - heat dashboard needs of clients
   - Resuming after an engine failure
   - Moving SyncPoints from DB to DLM
   - toggle the debug option at runtime
   - remove mox
   - Allow partial success in ASG
   - Client Plugins and OpenStackSDK
   - Global Request Id support
   - Heat KeyStone Credential issue
   - (How we going to survive on the island)

You can find *all Etherpads links* in
*https://etherpad.openstack.org/p/heat-rocky-ptg
<https://etherpad.openstack.org/p/heat-rocky-ptg>*

We try to document down as much as we can(Thanks Zane for picking it up),
including discussion and actions. *Will try to target all actions in Rocky*.
If you do like to input on any topic (or any topic you think we
missing), *please
try to provide inputs to the etherpad* (and be kind to leave messages in ML
or meeting so we won't miss it.)

*Use Cases*
If you have any use case for us (What's your usecase, what's not working/
what's working well),
please help us and input to* https://etherpad.openstack.org/p/heat-usecases
<https://etherpad.openstack.org/p/heat-usecases>*


Here are *Team photos* we took:
*https://www.dropbox.com/sh/dtei3ovfi7z74vo/AADX_s3PXFiC3Fod8Yj_RO4na/Heat?dl=0
<https://www.dropbox.com/sh/dtei3ovfi7z74vo/AADX_s3PXFiC3Fod8Yj_RO4na/Heat?dl=0>*



-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Interop-wg] [QA] [PTG] [Interop] [Designate] [Heat] [TC]: QA PTG Summary- Interop test for adds-on project

[Rico Lin]

>
> Why would the repos be owned by anyone other than the original project
> team?
>
For normal tempest tests, which owned and maintained by original projects.
I think there were discussions in that PTG QA session about interop tests
should be maintained by QA team.

>

In the new resolution, we can make sure QA team and project teams will stay
in their obligation to interop testing structure together (isn't that just
like how current tempest plugin structure works).
And allow interop team to focus on interop structure (ideally not the tests
itself).

I agree with Zane, that we really want all 3 teams to contribute to reviews,
 since they each bring different expertise to format this interop structure.




Rico Lin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] weekly meeting is cancelled

[Rico Lin]

Hi team,

As we just get back from #*SnowpenStack*
<https://twitter.com/hashtag/SnowpenStack?src=hash> (PTG), let's skip
meeting this week.

Here are sessions that we discussed in PTG, so if you would like to add
some input to it, now is the time(try to leave your name, so we might know
who it is). https://etherpad.openstack.org/p/heat-rocky-ptg

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat][ptg] PTG schedule

[Rico Lin]

Dear all

I can’t wait for see you all in Dublin.

I put a draft version of PTG schedule in [1].
We might change schedule after PTG started.

Also we’re capable to set up real time video conference, so if you’re
interested in join, please put your name in etherpad so I will know that I
need to set up for it.

And just for reminding, we will not host meeting next week.

Hope you all have a nice flight

[1] https://etherpad.openstack.org/p/heat-rocky-ptg
-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] No Meeting This week

[Rico Lin]

> Looks heat-dashboard does not have stable/queens branch yet.
> I got an indication about this from Horizon core and they are waiting for
that heat-dashboard will have it.
> (we want to drop django <= 1.10 support along with Horizon for Rocky)
> Cloud you kindly take care of this issue ?

Thanks Kaz Shinohara
I target a release here now, hope it will fix the issue
https://review.openstack.org/543866

I see you try to drop specific django, but send a revert request later. We
can actually target specific commit as release point, so don't actually
need to revert it (unless it break others).
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] No Meeting This week

[Rico Lin]

Hi all
Good news first! We released queens last week, so well done everyone.

This week is Chinese new year, and Wednesday happen to be new year eve, so
I will not hosting the meeting this week.

Let's skip this one if no important stuff to talk about.

See you at next meeting


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][rally] What should we do with legacy-rally-dsvm-fakevirt-heat

[Rico Lin]

Thx Andrey, looking forward to new rally job

At meanwhile,  seems current job is broken [1] and we're expecting for a
new job to replace.
We will remove the old legacy one (see patch [2]) for now if that won't
break rally (in any way).
I'm changing only config for heat (under zuul.d/projects.yaml), won't touch
`legacy-rally-dsvm-fakevirt-heat` itself (I guess that is up to rally team
to remove it later)

[1]
http://logs.openstack.org/29/531929/3/experimental/legacy-rally-dsvm-fakevirt-heat/cd797f4/job-output.txt.gz#_2018-02-08_05_02_37_258609
[2] https://review.openstack.org/542111

2018-02-08 3:39 GMT+08:00 Andrey Kurilin <andr.kuri...@gmail.com>:

> Hi Rico and stackers,
>
> Thanks for raising this topic.
>
> Short answer: please leave it as is for now. Rally team will work on
> ZuulV3 jobs soon.
>
> Detailed: We are planning to make some big changes in our architecture
> which includes splitting the main repo into a separate repository for a
> framework and a separate repository for all OpenStack plugins.
> To minimize work across all projects which have Rally job, we decided to
> pause working on ZuulV3 until the split will be finished.
> As for estimates, I'm planning to make the final release before splitting
> today or tomorrow. As soon as new release will be ready, we will start
> working on splitting and CI as well.
>
> Thanks for the patient and for using Rally!
>
> 2018-02-07 10:13 GMT+02:00 Rico Lin <rico.lin.gua...@gmail.com>:
>
>> Hi heat and rally team
>>
>> Right now, in heat's zuul jobs. We still got one legacy job to change
>> `legacy-rally-dsvm-fakevirt-heat` [1] which I already put a patch out
>> here [2], but after discussion with infra team, it seems best if we can
>> define this in rally, and reference it in heat.
>> So my question to rally team for all these will be, do we still need this
>> job? and how you guys think about if we put that into rally?
>>
>> [1] https://github.com/openstack-infra/project-config/blob/
>> master/zuul.d/projects.yaml#L6979
>> [2] https://review.openstack.org/#/c/509141
>> --
>> May The Force of OpenStack Be With You,
>>
>> *Rico Lin*irc: ricolin
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best regards,
> Andrey Kurilin.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat][rally] What should we do with legacy-rally-dsvm-fakevirt-heat

[Rico Lin]

Hi heat and rally team

Right now, in heat's zuul jobs. We still got one legacy job to change
`legacy-rally-dsvm-fakevirt-heat` [1] which I already put a patch out here
[2], but after discussion with infra team, it seems best if we can define
this in rally, and reference it in heat.
So my question to rally team for all these will be, do we still need this
job? and how you guys think about if we put that into rally?

[1]
https://github.com/openstack-infra/project-config/blob/master/zuul.d/projects.yaml#L6979
[2] https://review.openstack.org/#/c/509141
-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat][ptl] PTL Candidacy for Rocky

[Rico Lin]

Hi All,

I would like to nominate myself to take the role of Heat PTL for Rocky
release.
I'd been involved with the project for two and half years. And it's my
privilege to work and learn from this great team and have the honor to
serve as
Pike and Queens PTL.

With last haft year, team achieves following jobs:

* Policy in code
* Heat dashboard
* Heat tempest plugin
* Zuul migrate in Heat
* New resources/properties
* Gate stable maintenance
* become Interop add-on
* Deprecate/remove few resources

Also done 2 blueprints, 62 bugs fixed (still going) and quite a few non-bug
improvement (like memory improvement, etc.).

I would like to keep trace on above jobs and with some more task that needs
to
be done:

* Needs more reviewers and developers, we got few superman in our team
(thank
  God for that). Still, we need more reviewers and developers than ever.
* goals making and tracing. IMO, it's always a nice thing to make goals at
the
  very first place in a cycle, so all members can jump up and pick it up if
  you somehow fail to keep pushing or got a more critical task to work on.
And
  most important is we can have a way to trace and make sure our team keeps
  been productive(which it already is). We also need to filter and review
  with current community goals to make sure it's not making things worst for
  Heat.
* Cross project co-works. We have some features out within these few
releases
  cycle. Heat team for some reason keeps been tightly co-works with TripleO
  team to sync with what we have (which is super cool). What I also like to
  see if we can get more sync up with other teams who use heat as part of
their
  infra which will potentially give us more feedbacks from multiple
  users/projects.
* Inner team communications. We have faced some communication problem in
this
  cycle, which means as a PTL, I'm responsible to make sure our team have a
  more comfortable workflow to work on. Which means I have to try harder to
  sync up tasks within this team. At least provide team better
communications
  which shouldn't try to take more time for all.

Hope you will consider me for Rocky PTL. Thank you!
Rico Lin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

[Rico Lin]

>
> Fair point. When the "VM/baremetal workgroup" was originally formed,
> the goal was more about building clouds with both types of resources,
> making them behave similarly from a user perspective, etc. Somehow
> we got into talking applications and these other topics came up, which
> seemed more interesting/pressing to fix. :)
>
> Maybe "cross-project identity integration" or something is a better name?

Cloud-Native Application IMO is one of the ways to see the flow for both
VM/Baremetal.
But  It's true if we can have more specific goal coss project to make sure
we're marching to that goal (which `VM/baremetal workgroup` formed for)
will be even better.
Instead of modifying the name, I do prefer if we can spend some time to
trace current flow and come out with specific targets for teams to work on
in rocky to allow building both types of resources and feel like same flow
to user, and which of cause includes what keystone already started. So
other than topics Collen mentioned above (and I think they all great), we
should focus working on what topics we can comes out from here (I think
that's why Collen start this ML). Ideas?




-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] Move meeting time to 14:00 UTC weekly

[Rico Lin]

Hi team

As previously discussed in meeting,  in order to cover as many members as
possible with meeting schedule,
we will move our meeting time one hour later.
We keep looking for a perfect time for members(as much as we can get) to
join, it appears current meeting time isn't that ideal.
So starting this week, our meeting will change to 14:00 UTC weekly on
Wednesday which is exactly one hour later than current meeting schedule
Feel free to gives any feedback, otherwise see you around 14:00 UTC
Wednesday

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat]No meeting this week

[Rico Lin]

Hi all
These few weeks seems to have some amount members on vacation, let's skip
meeting this week (will hold our next meeting in next week)

Feel free to connect to me if any question or needs any help:)
Happy New Year everyone!

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat]Heat error during devstack installation

[Rico Lin]

include Tacker PTL in this ML

2017-12-28 13:57 GMT+08:00 Eyal B <eya...@gmail.com>:

> Hi
> I submitted a patch to fix this
> https://review.openstack.org/#/c/530109/
>
> Eyal
>
>
> On Dec 28, 2017 07:55, "Yatin Karel" <yka...@redhat.com> wrote:
>
>> Both vitrage and tacker are likely to fail as they are modifying
>> heat's policy.json in their devstack plugin.
>> See below:-
>>
>> tacker:- https://github.com/openstack/tacker/blob/master/devstack/lib
>> /tacker#L470-L474
>> vitrage:- https://github.com/openstack/vitrage/blob/master/devstack/pl
>> ugin.sh#L343-L358
>>
>>
>> Since policy.json is removed, they can not modify it, so for
>> overriding  rules they have to create their own policy.json or
>> policy.yaml for overridden rules and update heat.conf to use new
>> policy file.
>>
>>
>> Thanks and Regards
>> Yatin Karel
>>
>> On Thu, Dec 28, 2017 at 11:12 AM, Rico Lin <rico.lin.gua...@gmail.com>
>> wrote:
>> > Hi Minwook
>> >>
>> >> I get an error that can not find ‘/etc/heat/policy.json of heat ‘ while
>> >> installing devstack.
>> >>
>> >> These errors can occur during scripting for projects related to heat,
>> such
>> >> as tacker, vitrage, etc.
>> >>
>> >>
>> >>
>> >> Why do I get this error?
>> > We no longer have policy.json by default since [1].
>> > Can you share more logs from your devstack, will take a deep look.
>> >
>> >
>> >
>> > [1] https://review.openstack.org/#/c/505360/ricolin
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat]Heat error during devstack installation

[Rico Lin]

Hi Minwook
>
> I get an error that can not find ‘/etc/heat/policy.json of heat ‘ while
installing devstack.
>
> These errors can occur during scripting for projects related to heat,
such as tacker, vitrage, etc.
>
>
>
> Why do I get this error?
We no longer have policy.json by default since [1].
Can you share more logs from your devstack, will take a deep look.



[1] https://review.openstack.org/#/c/505360/ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Release-job-failures][heat] Release of openstack/python-heatclient failed

[Rico Lin]

>
> It seems like we need to test this in the gate somehow...

Let's enable the job in python-heatclient [1], so we won't have this issue
later

[1] https://review.openstack.org/#/c/526461/
>
> - ZB
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat]Propose change for core

[Rico Lin]

Dear heat team

I propose to move following members out of core reviewers list:

   - Peter Razumovsky
   - Ethan Lynn
   - Qiming Teng
   - Kanagaraj Manickam


They have provided great reviews and contributes to heat project (which is
remarkable). Since they now have other stuff to focus on and didn't get
much time to review or work on heat for at least in past cycle [1]. We
should move them out of core reviewer list for now. And hope we still have
the honor to add them back once they catch up with current development
status.

Whatever will be, we always thank you all for great contributions you
already provided.

[1] http://stackalytics.com/report/contribution/heat-group/240


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][qa] Split tempest plugin from heat

[Rico Lin]

>
> Does anybody remember what the mechanism for dealing with this that was
agreed at the PTG was?

The etherpad [1] shows actions that we(me and Thomas) agree to do, and
that's all for PTG discussion (the online attendee number is 0 for that
session).
Following with a recap in meeting to share the task and include that
etherpad (which Rabi's agreement on fallow). And with further implement and
research (by Rabi), we face the test separation issue, as we discussed
yesterday, Rabi reaches out for suggestion and opinions,  and I gave mine
with agreeing to move all test to the new repo and giving my +2 review to
those patches.
IMO, that's a question of whether we consider our tests as part of tempest
plugin or we want to consider them as internal Heat CI tests.

Right now what we have is following:
1. A new repo for heat-tempest-plugin with all tests in it.
2. Switch heat's functional and grenade jobs (in master) to use new heat
tempest plugin.
3. a patch to propose to remove integration tests in heat.
4. needs a plan to match branchless for heat-tempest-plugin repo

>
> Basically we need a way to:
>
> * Run a bunch of integration tests in Heat CI jobs
> * against a full OpenStack cloud
> * preferably using tempest as a testrunner, but this is optional
> * without any danger of e.g. breaking tempest test discovery just because
Heat was installed on the same machine as tempest
>
> How do we do it?

We now use tempest for all our integration tests but seems the question now
is how can we let our the CI out of this process, so all developers in heat
will have a better life while users/ops will also have a better life when
testing against their OpenStack environment.

My propose is we separate our tests into two groups:
A group of tests that should only stay in Heat CI jobs, which we still can
use tempest as test runner, but we should mark it(with a description, a
tag, or any way) as for internal CI usage, which will not follow any TC
goals since that's only for heat internal usage.

Another group of tests that make sense for us to expose to users and
operators. These stay in heat tempest plugin which users/ops can use to
test their own environment, and we will meet what the users/ops might
expect when they testing with their own heat environment. Also means we
should keep this repo branchless and fully tested with each branch. So we
stick with that goal. API tests seem to be native in this group, but we
have to keep in mind that it's not covering all cases, so we might need to
consider to add more tests in tempest plugin (in long-term).

In turns of actions:

1. Create a new tempest plugin for internal CI usage (in heat repo) and
mark it as internal(as a declare for we do not consider this as a tempest
plugin for users/ops), so others will know that they should not use it for
any other way(or use at their own risk).
2. Modify the patch which proposes to remove integration tests in heat, and
keeps tests those tests we decided as internal CI tests.
3. Allow heat gate to run tests from both tempest plugin( internal one and
`heat-tempest-plugin`) so we will still run and check both works. Of
course, we can keep the same group of tests on both sides(like a sync job)
but don't see why that's the way we like.

We should have this discussion earlier (when a simple suggestion from any
one of us will do), but since we still under developing cycle that means
it's not too late for anything.
And TBH, as a developer(not a good one but still learning), I see this goal
as pure painful plus useless for developers in heat, but I trust TCs and QA
team when they think this is so important (on how this will help users/ops
when testing their environment) that they decided to make this as a goal
for our community.

I'm fine with whatever the solution we came out from here, and I'm happy to
implement it together, but please keep in mind that we need all to help us
track the progress, so we can have more opinions or suggestions for any
issues we are/will face on these tasks.

Let's do this together and make it right at once!

Would really like to hear more suggestions on how we can deal with this or
how other teams do, so please share with us if you(heat/QA member or not)
see this mail.


[1] https://etherpad.openstack.org/p/heat-queens-ptg-tempest-plugin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-operators][all][heat] Hidden OS::Heat::HARestarter resource

[Rico Lin]

Dear all

As you might know, `OS::Heat::HARestarter` been deprecate for really long
time. It never really restarts servers (only recreate them), and the code
(and logic) looks really old.
Would like to reach out all users to see if this resource still uses by
anyone.
If it's fine for all, I like to propose with [1] to hidden that resource
type and mark it as placeholder resource.
For resources already exists (which not a placeholder resource), still can
be deleted through the client. Any newly created resources will be
considered as placeholder resources like none resource. We will schedule to
delete it from heat resources list.

For users that really need this kind of feature, can also consider using
auto-healing like the sample template in [2]. Which IMO is way better than
HARestarter.

[1] https://review.openstack.org/#/c/511278
[2]
https://git.openstack.org/cgit/openstack/heat-templates/tree/hot/autohealing

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-operators][heat][all] Sydney for all Heat Users, Operators, and Developers

[Rico Lin]

Hi all

Next week is our big week! Hope to see you all there, here are some heat
sessions/forums for you in Sydney Summit.

For any users and operators who use heat directly or indirectly(like people
who use Magnum/Sahara/Tacker) are welcome to join us for ops and users
feedback forum, we really appreciated for any kind of help and feedbacks.
So heat and other projects that relative to heat can know any issues or
required for improvement exists.

For anyone who would like to see if you could help on contributing in any
way, or you're looking for better knowledge of developing heat, please join
us in our Onboarding session.

And last but not least, please join our project update session for some key
information about what we done for pike and what's plan for queens.

All detail information:

Heat - Project Onboarding
Mon 6, 11:35am - 12:15pm Sydney Convention and Exhibition Centre - Level 4
- C4.7 <https://www.openstack.org/summit/sydney-2017/venues/#room=322>

Heat - Project Update
Tue 7, 5:00pm - 5:20pm Sydney Convention and Exhibition Centre - Level 3
Convention Center - C3.2
<https://www.openstack.org/summit/sydney-2017/venues/#room=311>

Heat ops and users feedback
Wed 8, 4:30pm - 5:10pm Sydney Convention and Exhibition Centre - Level 4 -
C4.10 <https://www.openstack.org/summit/sydney-2017/venues/#room=325>


There also a lot of Orchestration relative sessions, so feel free to pick
your favorites.
-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] No meeting for this and next week

[Rico Lin]

Hi team

As I will be on a flight to Sydney on this Wednesday and flight back on
next Wed. I won't be able to run meetings for this two weeks.
Any core feel like to host one (for whatever the issues are) are welcome,
otherwise, see you in the third week.

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptls] Sydney Forum Project Onboarding Rooms

[Rico Lin]

Hi Kendall

Heat would like to have our On-boarding session in Sydney.

For now, only me is confirmed that will be there.
So:
Rico Lin, rico.lin.gua...@gmail.com

Thanks so much for your work, see you in Sydney:)

2017-10-05 23:50 GMT+08:00 Kendall Nelson <kennelso...@gmail.com>:

> Hello :)
>
> We have a little over 40 slots available so we should be able to
> accommodate almost everyone, but it will be a first response first serve
> basis.
>
> Logistics: Slots are 40 min long and will have projection set up in them.
> The rooms have a capacity of about 40 people and will be set up classroom
> style.
>
> If you are interested in reserving a spot, just reply directly to me and I
> will put your project on the list. *Please let me know if you want one
> and also include the names and emails anyone that will be speaking with
> you. *
>
> When slots run out, they run out.
>
> Thanks!
>
> -Kendall Nelson (diablo_rojo)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Openstack-operators][all][heat] Removal of CloudWatch api

[Rico Lin]

Add OpenStack ops ML
-- Forwarded message --
From: Rabi Mishra <ramis...@redhat.com>
Date: 2017-10-04 18:47 GMT+08:00
Subject: [openstack-dev] [heat] Removal of CloudWatch api
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>


Hi All,

As discussed in the last meeting, here is the ML thead to gather more
feedback on this.

Background:

Heat support for AWS CloudWatch compatible API (a very minimalistic
implementation, primarily used for metric data collection for autoscaling,
before the telemetry services in OpenStack), has been deprecated since
Havana cycle (may be before that?).  We now have a global alias[1] for
AWS::CloudWatch::Alarm to use OS::Aodh::Alarm instead.  However, the
ability to push metrics to ceilometer via heat, using a pre-signed url for
CloudWatch api endpoint, is still supported for backward compatibility.
heat-cfntools/cfn-push-stats tool is mainly used from the instances/vms for
this.

What we plan to do?

We think that CloudWatch api  and related code base has been in heat tree
without any change for the sole reason above and possibly it's time to
remove them completely. However, we may not have an alternate way to
continue providing backward compatibility to users.

What would be the impact?

- Users using AWS::CloudWatch::Alarm and pushing metric data from instances
using cfn-push-stats would not be able to do so. Templates with these would
not work any more.

- AWS::ElasticLoadBalancing::LoadBalancer[2] resource which uses
AWS::CloudWatch::Alarm and cfn-push-stats would not work anymore. We
probably have to remove this resource too?

Though it seems like a big change, the general opinion is that there would
not be many users still using them and hence very little risk in removing
CloudWatch support completely this cycle.

If you think otherwise please let us know:)


[1] https://git.openstack.org/cgit/openstack/heat/tree/etc/heat/
environment.d/default.yaml#n6
[2] https://git.openstack.org/cgit/openstack/heat/tree/heat/
engine/resources/aws/lb/loadbalancer.py#n640

Regards,
Rabi Mishra

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Important information for people with in-repo Zuul v3 config

[Rico Lin]

And we find following error in heat's zuulv2 jobs [1]:

x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
-fstack-protector-strong -Wformat -Werror=format-security -fPIC
-DUSE__THREAD -DHAVE_SYNC_SYNCHRONIZE -I/usr/include/ffi
-I/usr/include/libffi -I/usr/include/python2.7 -c c/_cffi_backend.c -o
build/temp.linux-x86_64-2.7/c/_cffi_backend.o

c/_cffi_backend.c:15:17: fatal error: ffi.h: No such file or directory
compilation terminated.
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

[1]
http://logs.openstack.org/27/509227/1/check/gate-heat-dsvm-functional-orig-mysql-lbaasv2-ubuntu-xenial/68905a9/console.html#_2017-10-04_08_53_03_706042

2017-10-04 19:23 GMT+08:00 Boden Russell <boden...@gmail.com>:

>
> On 10/3/17 1:37 PM, Monty Taylor wrote:
> > The partial rollback of Zuulv3 is in place now. Zuulv2 is acting as your
> > gate keeper once again.
>
> Since the rollback, one of the neutron-lib (v2) jobs has been
> consistently failing [1] with:
>
> c/_cffi_backend.c:15:17: fatal error: ffi.h: No such file or directory
>
> Is this a known issue?
>
>
> [1]
> http://logs.openstack.org/01/508901/1/check/gate-tempest-
> dsvm-neutron-src-neutron-lib-ubuntu-xenial/c1d98e2/console.
> html#_2017-10-04_11_06_07_410466
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][heat] Heat meeting time changed to 13:00 Wed. at #heat

[Rico Lin]

Hi all

After discussion.
Heat decided to move our meeting to Wed. 13::00 UTC at #heat
Which is two hours earlier than the previous one.
So our meeting start from this week will be host at 13:00 UTC in #heat
(weekly).
We will keep doing 13:00 and see if that works for all.
Feel free to join us and provide your ideas and works with us:
https://wiki.openstack.org/wiki/Meetings/HeatAgenda

Already propose irc meeting change: https://review.openstack.org/506901


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptg][heat] Heat PTG + Virtual meetup Agenda

[Rico Lin]

In case anyone can't find attached ICS file
ICS calendar:
https://drive.google.com/file/d/0B_UWw7JzTsWYZnIwYVpGR0REdms/view?usp=sharing

2017-09-07 18:44 GMT+08:00 Rico Lin <rico.lin.gua...@gmail.com>:

> Hi heat members
>
> As we're going to have PTG in Denver(and online)
> Here are schedules and Etherpads for it [1].
>
> Encourage all to join us remotely if you can't make it to Denver!, we
> welcome anyone shares their ideas, experiences, efforts, and stories to us
> to help us make our design/implement better.
>
> Attached an ics file, feel free to add it to your calendar
>
> As we discussed in heat meeting, this Heat PTG will be a mixed format,
> Physical PTG room + Virtual Online channel together.
> The virtual link will share in [1], and if anything went wrong(like we
> have to change room URL), we will update to etherpad as well. So keep
> update to date with the etherpad.
>
> Also please notice that we won't host team meeting next week.
>
> [1] https://etherpad.openstack.org/p/heat-queens-ptg
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ptg][heat] Heat PTG + Virtual meetup Agenda

[Rico Lin]

Hi heat members

As we're going to have PTG in Denver(and online)
Here are schedules and Etherpads for it [1].

Encourage all to join us remotely if you can't make it to Denver!, we
welcome anyone shares their ideas, experiences, efforts, and stories to us
to help us make our design/implement better.

Attached an ics file, feel free to add it to your calendar

As we discussed in heat meeting, this Heat PTG will be a mixed format,
Physical PTG room + Virtual Online channel together.
The virtual link will share in [1], and if anything went wrong(like we have
to change room URL), we will update to etherpad as well. So keep update to
date with the etherpad.

Also please notice that we won't host team meeting next week.

[1] https://etherpad.openstack.org/p/heat-queens-ptg

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//www.marudot.com//iCal Event Maker
X-WR-CALNAME:Heat Session in Denver PTG
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:America/Denver
TZURL:http://tzurl.org/zoneinfo-outlook/America/Denver
X-LIC-LOCATION:America/Denver
BEGIN:DAYLIGHT
TZOFFSETFROM:-0700
TZOFFSETTO:-0600
TZNAME:MDT
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0600
TZOFFSETTO:-0700
TZNAME:MST
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20170907T101450Z
UID:20170907t101450z-1171862...@marudot.com
DTSTART;TZID="America/Denver":20170913T09
DTEND;TZID="America/Denver":20170913T093000
SUMMARY:Rolling upgrade session(Heat-PTG)
DESCRIPTION:https://etherpad.openstack.org/p/heat-queens-ptg
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:Rolling upgrade session(Heat-PTG)
TRIGGER:-PT5M
END:VALARM
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20170907T101450Z
UID:20170907t101450z-468483...@marudot.com
DTSTART;TZID="America/Denver":20170913T094000
DTEND;TZID="America/Denver":20170913T103000
SUMMARY:tooz integration session(Heat-PTG)
DESCRIPTION:https://etherpad.openstack.org/p/heat-queens-ptg
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:tooz integration session(Heat-PTG)
TRIGGER:-PT5M
END:VALARM
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20170907T101450Z
UID:20170907t101450z-674863...@marudot.com
DTSTART;TZID="America/Denver":20170913T101000
DTEND;TZID="America/Denver":20170913T105000
SUMMARY:Cluster resource improvement session(Heat-PTG)
DESCRIPTION:https://etherpad.openstack.org/p/heat-queens-ptg
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:Cluster resource improvement session(Heat-PTG)
TRIGGER:-PT5M
END:VALARM
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20170907T101450Z
UID:20170907t101450z-2117674...@marudot.com
DTSTART;TZID="America/Denver":20170913T11
DTEND;TZID="America/Denver":20170913T12
SUMMARY:A horizon plugin for HOT creation in drag & drop session(Heat-PTG)
DESCRIPTION:https://etherpad.openstack.org/p/heat-queens-ptg
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:A horizon plugin for HOT creation in drag & drop session(Heat-PTG)
TRIGGER:-PT5M
END:VALARM
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20170907T101450Z
UID:20170907t101450z-1265540...@marudot.com
DTSTART;TZID="America/Denver":20170913T133000
DTEND;TZID="America/Denver":20170913T142500
SUMMARY:Policy in Code session(Heat-PTG)
DESCRIPTION:https://etherpad.openstack.org/p/heat-queens-ptg
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:Policy in Code session(Heat-PTG)
TRIGGER:-PT5M
END:VALARM
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20170907T101450Z
UID:20170907t101450z-657695...@marudot.com
DTSTART;TZID="America/Denver":20170913T143000
DTEND;TZID="America/Denver":20170913T144000
SUMMARY:Team Photo (Heat-PTG)
DESCRIPTION:https://etherpad.openstack.org/p/heat-queens-ptg
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:Team Photo (Heat-PTG)
TRIGGER:-PT5M
END:VALARM
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20170907T101450Z
UID:20170907t101450z-384219...@marudot.com
DTSTART;TZID="America/Denver":20170914T09
DTEND;TZID="America/Denver":20170914T092000
SUMMARY:Federated Keystone and Heat session(Heat-PTG)
DESCRIPTION:https://etherpad.openstack.org/p/heat-queens-ptg
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:Federated Keystone and Heat session(Heat-PTG)
TRIGGER:-PT5M
END:VALARM
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20170907T101450Z
UID:20170907t101450z-772826...@marudot.com
DTSTART;TZID="America/Denver":20170914T093000
DTEND;TZID="America/Denver":20170914T095000
SUMMARY: Cross-stack reference session(Heat-PTG)
DESCRIPTION:https://etherpad.openstack.org/p/heat-queens-ptg
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION: Cross-stack reference session(Heat-PTG)
TRIGGER:-PT5M
END:VALARM
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20170907T101450Z
UID:20170907t101450z-563498...@marudot.com
DTSTART;TZID="America/Denver":20170914T10
DTEND;TZID="America/Denver":20170914T103000
SUMMARY:Breaking the stack barrier session(Heat-PTG)
DESCRIPTION:ht

Re: [openstack-dev] [heat][infra] Help needed! high gate failure rate

[Rico Lin]

> The reality is you're just going to have to triage this and be a *lot*
> more specific with issues.  I find opening an etherpad and going
> through the failures one-by-one helpful (e.g. I keep [2] for centos
> jobs I'm interested in).
>
> Looking at the top of the console.html log you'll have the host and
> provider/region stamped in there.  If it's timeouts or network issues,
> reporting to infra the time, provider and region of failing jobs will
> help.  If it's network issues similar will help.  Finding patterns is
> the first step to understanding what needs fixing.
>
Here [1] I collect some fail records from gate
As we can tell, most of environments set-up becomes really slow and failed
at some point with time out error.
In [1] I collect information for failed node. Hope you can find any clue
from it.


[1] https://etherpad.openstack.org/p/heat-gate-fail-2017-08

> If it's due to issues with remote transfers, we can look at either
> adding specific things to mirrors (containers, images, packages are
> all things we've added recently) or adding a caching reverse-proxy for
> them ([3],[4] some examples).
>
> Questions in #openstack-infra will usually get a helpful response too
>
> Good luck :)
>
> -i
>
> [1] https://bugs.launchpad.net/openstack-gate/+bug/1708707/
> [2] https://etherpad.openstack.org/p/centos7-dsvm-triage
> [3] https://review.openstack.org/491800
> [4] https://review.openstack.org/491466
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat][infra] Help needed! high gate failure rate

[Rico Lin]

Hi all

We're facing a high failure rate in Heat's gates [1], four of our gate
suffering with fail rate from 6 to near 20% in 14 days. which makes most of
our patch stuck with the gate.

gate-heat-dsvm-functional-convg-mysql-lbaasv2-ubuntu-xenial(19.67%)
gate-heat-dsvm-functional-convg-mysql-lbaasv2-non-apache-ubuntu-xenia(9.09%)
gate-heat-dsvm-functional-orig-mysql-lbaasv2-ubuntu-xenial(8.47%)
gate-heat-dsvm-functional-convg-mysql-lbaasv2-py35-ubuntu-xenial(6.00%)

We still try to find out what's the cause but (IMO,) seems it might be some
thing wrong with our infra. We need some help from infra team, to know if
any clue on this failure rate? Maybe some change in heat or infra cause
this? Is this only happen in heat's gate? (Do see some fail from other
teams, but not as bad as heat's gate.)

Thanks for any kind of help


[1]
http://status.openstack.org/openstack-health/#/g/project/openstack~2Fheat?duration=P14D

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ffe][requirements][monasca][heat][watcher][congress] FFE for python-monascaclient minimum version in g-r

[Rico Lin]

Bumping min version to 1.7.0 would not be a problem for Heat.
There might be a few minutes breaking (to merge
https://review.openstack.org/#/c/490016) but won't affect much.

2017-08-04 2:20 GMT+08:00 Eric K <ekcs.openst...@gmail.com>:

> As far as I can tell, bumping min version to 1.7.0 would not be a problem
> for Congress.
>
> Eric Kao
>
> On 8/3/17, 4:39 AM, "witold.be...@est.fujitsu.com"
> <witold.be...@est.fujitsu.com> wrote:
>
> >Hello everyone,
> >
> >I would like to ask for the FFE for python-monascaclient version in
> >global requirements.
> >
> >The current version in Pike (1.7.0) is not fully backward compatible. The
> >monasca exception classes were replaced with keystoneauth exceptions,
> >which affects heat and watcher projects if they use current upper
> >constraints. The fixes for these projects have been submitted [1, 2].
> >
> >Also, monasca projects (monasca-agent, monasca-ui, monasca-api) rely on
> >python-monascaclient 1.7.0 and don't work with older versions.
> >
> >The change for bumping the minimum version of python-monascaclient is
> >here:
> >
> >https://review.openstack.org/489173
> >
> >
> >Best greetings
> >Witek Bedyk
> >
> >
> >[1] https://review.openstack.org/490016
> >[2] https://review.openstack.org/490018
> >
> >___
> ___
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [elections][heat] Candidacy for Heat Project PTL (Queens)

[Rico Lin]

Hi team,

I would like to submit my name for Heat PTL for Queens release.

I'd been involved with the project around two and half years. And it's my
privilege to
work and learn within this great team and have the honor to serve as Pike
PTL.
No doubt, heat already become the engine for other OpenStack services who
try
to deploy and manage a scale services or applications. With some excellent
jobs
from the team, we got great improvements on resources, py35, WSGI, bug
fixes,
infrastructure, agents, and templates which I don't think we can do it
without
anyone in the team. And as what we always open for more ideas to join, it's
essential to embrace following jobs:

- Cross projects integration and improvement
- Welcome any developers/ops/users who work on heat in any format
- Make project goals. Also following community goals and project goals to
make
  sure it will complete.
- Provide as many resources and guidelines for members as possible when they
  need it. To make it more efficient when working on Heat.
- Ensuring that CI jobs are healthy (and we don't break other projects)
- On time releases with effective coordination and collaboration

So these are targets that I think we can work on. We will open to any idea,
and give it full discussion and help.

In past cycle, I do get a lot of help from other experienced members, which
allows me to learn and grow. And I tend to keep learning and growing from
any
opinions and experiences good or bad.
As usual, my goal is to reach all above targets and make sure this team will
be able to keep running well, keep integration to new things, and always
open
to ideas. This means we will keep trying and making mistake on the way, but
the result must be worth.

Hope you will consider me for Queens PTL.

Thank you!
Rico
-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] Online video meet up this week (topic:review)

[Rico Lin]

>
>
> This seems like a game of semantics. In your earlier message (quoted
> above) you said, "we will make our meeting this week as an online
> video meeting," and you've scheduled it for the exact same time as
> your normal IRC meeting. I'm not sure how anyone can come to a
> different conclusion than that you're (at least experimenting with)
> replacing your weekly IRC meetings with teleconferencing.
>

First, please don't worry about that replacing issue, because we never want
to replace
IRC meeting in anyway. And to make this clear, this is not even a
experiment to do so.
The hole point of have this meetup is to help all team member got chances
to join future
face to face discussion and hopefully become a virtual+face-to-face
discussion (I only mean PTG here).
Just like what I said in the ML above "The reason for doing this is because
we're a global team
 which almost impossible for all of us to literally sit in the same room in
PTG/anywhere"

To deal that we got more then half cores missing in last PTG only because
they can't make it?
That the issue we have to solve here.
And thanks for correct my semantics issue, I already send another ML out
for clearfy that.
Will choose my word carefully. We definitely don't want and misstaken of
the reason why we host
the meetup here, so thank you for that.

As for why doing meetup this time, instead of meeting, because we don't
need anything other than to
review BPs and Goals. And would hope to make more patches landing before
freeze.

>
> The point wasn't whether there are open alternatives, just that
> you're expressly choosing convenience over software freedom. I get
> that different people place different priorities on this: for some
> free software is nice to have as long as it doesn't get in their
> way, while for others it's a mandate even if it means not getting to
> use some shiny new feature. The decision doesn't directly impact me
> as I only ever at most lurk in the Heat meeting in case anyone
> requests my input and maybe occasionally read the minutes/log, but
> as an example set by a long-standing team within the community it's
> certainly disappointing.
>
Thanks for share that concern out, I will raise this issue to team(maybe in
meeting next week).
The sad, OpenStack already start to adopt something here(I'm actually agree
with you and we should kill https://openstack.webex.com)
Again this is for one meetup and will seek on any feedback, so feedback
taken.
Thank you for fighting for this.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] No meeting this week(There will be a review meetup this week)

[Rico Lin]

Dear Team
Just to be clear
We will host a meet up for review (as what we pickup topic for just doing
review) this week.
*That means we not going to hold the meeting this week.*
And the purpose of doing meetup with video conference is to find a way for
the team to really able to join together and discuss when face to face
discussion is required (I mean PTG at this point).

We will resume meeting next week. Hope you all understand.

If you would like to join the meetup this week and help to review together,
here is info:

Topic: Review
Time: Wednesdays at 1500 UTC on 07/12 (1 hr)
Location: zoom.us (I will notify the specific room location in heat's irc
channel right before the meetup)
Agenda:

1. pre meetup discuss
2. We shall go with patches for BPs and Goals first
3. then pick out some worth review patch for review and land as many as we
can.
4. post meetup discuss (include feedback and suggestion time)

Host: Rico Lin
*Pre-requirement: Please register a Zoom account (zoom.us
<http://zoom.us/>) which will be the channel that we will use for this
meetup*

With that free account, you should be able to join the meetup. Just
remember to install zoom on your device. And don't worry it's easy to join
and operate.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] Online video meet up this week (topic:review)

[Rico Lin]

2017-07-12 2:10 GMT+08:00 Jeremy Stanley <fu...@yuggoth.org>:
>
> On 2017-07-12 01:47:02 +0800 (+0800), Rico Lin wrote:
> [...]
> > we will make our meeting this week as an online video meeting
> [...]
>
> Friendly reminder: "If the project has meetings [...] they should be
> public and in IRC. They should all be logged and published"
>
https://governance.openstack.org/tc/reference/new-projects-requirements.html
I would rather call this video meet as `meet up` as in title said,
since we will not discuss any other thing but just review and share
thought about each patch.
(Which I will definitely share the information On IRC and WIKI for sure)
>
> Also, while Zoom's service and client software may be "free" in the
> gratis sense, they are not free in the libre sense. Moving your
> meetings to a proprietary system (whether it charges money for you
> to be able to use it or not) isn't in the spirit of an open
> community and necessarily excludes participation by people who value
> software freedom.
That's a great stand of point that we all agree on (or otherwise why we're
here:)),
but through the team meeting, we can't think out for a video channel that's
happened
to be a pure open source one (and stable to use). And of course, if people
can help to provide
such an environment for us to try on, then I'm happy to give it a test :)

> --
> Jeremy Stanley
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] Online video meet up this week (topic:review)

[Rico Lin]

Hi Team

We would like to start doing video online meetup and see if we can all
reach better co-work with that.
The reason for doing this is because we're a global team which almost
impossible for all of us to literally sit in the same room in PTG/anywhere
(it's just not possible to ask all companies to shift all their heat
developers/ops to a single event).
Also, we should not wait till PTG or Summit to deal with all face to face
task (at least not for small tasks).
Anyway, we will make our meeting this week as an online video meeting. And
try to see if that format works for us or not. And if we doing well, we
might also consider making PTG a hybrid mode.

Here are the details:
Topic: Review
Time: Wednesdays at 1500 UTC on 07/12 (1 hr)
Location: zoom.us (I will notify the specific room location in heat's irc
channel right before the meeting)
Agenda:

1. pre meetup discuss
2. We shall go with patches for BPs and Goals first
3. then pick out some worth review patch for review and land as many as we
can.
4. post meetup discuss (include feedback and suggestion time)

Host: Rico Lin
*Pre-requirement: Please register a Zoom account (zoom.us <http://zoom.us>)
which will be the channel that we will use for this meetup*

With that free account, you should be able to join the meeting. Just
remember to install zoom on your device. And don't worry it's easy to join
and operate.

Do hope more people(core or not) to join this meeting, which might also be
a good chance to get a more clear view of what heat's new feature or bug
fix in detail. We need more reviewer together, so see you there!!
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Onboarding rooms postmortem, what did you do, what worked, lessons learned

[Rico Lin]

*Project: * Heat

*Attendees:*  around 10-15

*PPT:* https://www.slideshare.net/GuanYuLin1/heat-project-onboarding

*Videos: *
https://www.youtube.com/playlist?list=PLIKe-Yb1IV6ETK3HKc7mz8kEtawxlvxJh

*Talker:* Rico Lin and Zane Bitter

*Who we targeting:*

We try to make this usable for new user/ops/dev.

*What was done:*

We use slides through the entire session, with some Q and Experiences
talks. The following is our schedule:


   1. Start with recognizing who is helping to contribute to heat project,
and tell all that we desire any kind of help.
   2. Talk about what repo we got and what it does
   3. Talk about Heat Architecture
   4. Talk new structure of heat (convergence) in concept
   5. Share detail from Heat template to actually resource create
   6. Talk how to update that created resource
   7. Talk how to make your own resource type
   8. Talk about software deploy in workflow
   9. Auto healing+ Autoscaling
   10. Some debug guide (more like for user and ops)
   11. And finally, some roadmap, to hope got some interested to any of
   those items.

Also, we use my smartphone to record that video.
So these are pretty much what we were done.


*What worked:*


   1. People showing their interest in help our team (and some of them
   already start to doing amazing jobs, like LanceHaig:) ), so that worked:)
   2. Hardware works
   3. Room works
   4. Mascot sticker works
   5. Zane works
   6. The space of my smartphone almost works (99%)

*Lessons:*

1. Do hope we can have some video record for Onboarding, to train any
others who might be interested in joining. So the next Onboarding can start
from somewhere more detail, and not start from 0 and end with 101.

2. Don't use weird example like OS::Sled::Dog, that never works when you
try to explain how the actual thing works

3. I found a lot of operators and users not even knows about Onboarding,
maybe we can do something to attract some attention. Like give out what
exactually you will befinfit from it and how your works can be so relative
to upstream that you can even move you amazing job to upstream. And what
you will expected to learn from this session


2017-05-25 6:20 GMT+08:00 Kendall Nelson <kennelso...@gmail.com>:

> @Nikhil, we (the organizers of Upstream Institute) sent a few emails
> [1][2] out to the dev mailing list asking for help and representatives from
> various projects to attend and get involved. We are also working on
> building a network of project liaisons to direct newcomers to in each
> project. Would you be interested in being our Glance liaison?
>
> Let me know if you have any other Upstream Institute questions!
>
> - Kendall(diablo_rojo)
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-
> January/110788.html
> [2]  http://lists.openstack.org/pipermail/openstack-dev/2016-
> November/108084.html
>
> On Wed, May 24, 2017 at 4:03 PM Nikhil Komawar <nik.koma...@gmail.com>
> wrote:
>
>> Project:  Glance
>>
>> Attendees: ~15
>>
>> What was done:
>>
>> We started by introducing the core team (or whatever existed then), did a
>> run down of Glance API documentation especially for developers, other
>> references like notes for ops, best practices. We went through the
>> architecture of the project. A few were interested in knowing more details
>> and going in depth so we discussed the design patterns that exist today,
>> scope of improvements and any blackholes therein, auxiliary services and
>> performance tradeoffs etc. A lot of the discussion was free form so people
>> asked questions and session was interactive.
>>
>>
>> What worked:
>>
>> 1. The projector worked!
>>
>> 2. Session was free form, there was good turnout and it was interactive.
>> (all the good things)
>>
>> 3. People were serious about contributing as per their
>> availability/capacity to do upstream and one person showed up asking to do
>> reviews.
>>
>>
>> Lessons:
>>
>> 1. Could have been advertised more at least the session description more
>> customized.
>>
>> 2. A representative from the team could have been officially invited to
>> the upstream institute training.
>>
>> 3. The community building sessions and on-boarding sessions seem to
>> overlap a bit so a representative from the team could be help in those
>> sessions for Q or more interaction. Probably more collaboration/prep
>> before the summit for such things. ($0.02)
>>
>>
>> Cheers
>>
>> On Wed, May 24, 2017 at 1:27 PM, Jay S Bryant <jungleb...@gmail.com>
>> wrote:
>>
>>> Project:  Cinder
>>>
>>> Attendees: Approximately 30
>>>
>>> I was really pleased by the number of people th

Re: [openstack-dev] [Heat] Heat template example repository

[Rico Lin]

Hi Lance and all others who shows interest

IMO, after some feedback from the summit. I think it will be greate to have
efforts on


   - *bug/blueprint: We needs more people doing fix/review/spec. Since we
   still on the way to make heat more handy as Orchestration tools*
   - *template example*: Since we do have some new functions but didn't
   actually give a proper update of it.
   - *tutorial*: We got some reports about the lack of tutorials for for
   for features like software config/ rolling upgrade, so I definitely think
   we require some improvement here.
   - *test*: Our integration test(tempest test) seems not cover
   every scenario (like we just cover some snapshots test these few weeks).
   Also, we do hope to get more reports on how people use heat, and what's the
   test result.

So yes from me, Lance, that will help:)

Also, most of our functions can be directly called by future version, so if
we separate it into versions, how can Pike user find that example? I like
to idea to make all user aware of template version. but not sure to make
version specific directory will help. Maybe a version info in template
description will do? We can discussion this at the meeting (Wednesdays at
1500 UTC in #openstack-meeting-5) :)

2017-05-15 15:21 GMT+08:00 Lance Haig <lnh...@gmail.com>:

> Good to know that there is interest.
>
> I was thinking that we should perhaps create a directory for each
> openstack version.
>
> so we start say with a mitaka directory and then move the files there and
> test them all so that they work with Liberty.
> Then we can copy it over to Mitaka and do the same but add the extra
> functionality.
> and then Newton etc...
>
> That way if someone is on a specific version they only have to go to a
> specific directory to get the examples they need.
>
> What do you think?
>
> Lance
>
>
> On 14 May 2017 at 23:14, Kaz Shinohara <ksnhr.t...@gmail.com> wrote:
>
>> Hi Lance,
>>
>> I like it too.
>> We should keep them updated according to the latest spec and actual use
>> cases.
>>
>> Regards,
>> Kaz Shinohara
>>
>>
>> 2017-05-13 13:00 GMT+09:00 Foss Geek <thefossg...@gmail.com>:
>>
>>> Hi Lance, I am also interested to assisting you on this.
>>>
>>> Thanks
>>> Mohan
>>> On 11-May-2017 2:25 am, "Lance Haig" <lnh...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I would like to introduce myself to the heat team.
>>>>
>>>> My name is Lance Haig I currently work for Mirantis doing workload
>>>> onboarding to openstack.
>>>>
>>>> Part of my job is assisting customers with using the new Openstack
>>>> cloud they have been given.
>>>>
>>>> I recently gave a talk with a colleague Florin Stingaciu on LCM with
>>>> heat at the Boston Summit.
>>>>
>>>> I am interested in assisting the project.
>>>>
>>>> We have noticed that there are some outdated examples in the
>>>> heat-examples repository and I am not sure that they all still function.
>>>>
>>>> I was wondering if it would be valuable for me to take a look at these
>>>> and fix them or perhaps we can rethink how we present the examples.
>>>>
>>>> I am interested in what you guys think.
>>>>
>>>> Thanks
>>>>
>>>> Lance
>>>>
>>>> 
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: openstack-dev-requ...@lists.op
>>>> enstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators][heat]desire your feedback and join! And welcome on board!

[Rico Lin]

.

2017-05-04 12:08 GMT+08:00 Rico Lin <rico.lin.gua...@gmail.com>:

> Hi all,
>
> Boston Summit is near, and we need your help and feedback! We really hope
> to improve your orchestration experiences,
> so *if you're a User, Operator, or Developer,* please join us on
> *`Large Orchestration Stacks
> <https://www.openstack.org/summit/boston-2017/summit-schedule/events/18747/large-orchestration-stacks>`
>  *Forum
> session *(Wednesday, May 10, 5:20pm-6:00pm)*:
> To discuss large stacks works and plan and we welcome any users/ops/devs
> to join and give out your feedback or thoughts to help on improving
> orchestration experiences.
> *Here is the etherpad link so please share your opinions whether you're
> coming to the summit or not.  
> **https://etherpad.openstack.org/p/BOS-forum-Large-Heat-stacks
> <https://etherpad.openstack.org/p/BOS-forum-Large-Heat-stacks>*
>
>
> If you wish to learn more detail on heat from beginner
> welcome join our *`Heat- Project Onboarding
> <https://www.openstack.org/summit/boston-2017/summit-schedule/events/18702/heat-project-onboarding>`
>  *
> Forum session *(Tuesday, May 9, 2:00pm-3:30pm)*
> Feel free to contact me and share what you would like to learn from this
> session, which I will try my best to put something in.
>
>
> And if you're interested in overall project update
> welcome, join our *`Project Update - Heat
> <https://www.openstack.org/summit/boston-2017/summit-schedule/events/18598/project-update-heat>`
> session (Monday, May 8, 5:30pm-6:10pm)*
>
>
>
> Also, there are a lot of heat relative talks
> <https://www.openstack.org/summit/boston-2017/summit-schedule/global-search?t=Heat>,
> so feel free to walk around and discover it out
>
> May The Force of OpenStack Be With You,
> Rico Lin (irc: ricolin)
>
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] postpone our next meeting to 5/17 for Boston summit

[Rico Lin]

Dear team

As Boston summit is next week, we will postpone our next meeting to 5/17.
In another word, we will not have the meeting on next week. Feel free to
raise any discussion in #heat irc channel.

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Openstack-operators][heat]desire your feedback and join! And welcome on board!

[Rico Lin]

Hi all,

Boston Summit is near, and we need your help and feedback! We really hope
to improve your orchestration experiences,
so *if you're a User, Operator, or Developer,* please join us on
*`Large Orchestration Stacks
<https://www.openstack.org/summit/boston-2017/summit-schedule/events/18747/large-orchestration-stacks>`
*Forum
session *(Wednesday, May 10, 5:20pm-6:00pm)*:
To discuss large stacks works and plan and we welcome any users/ops/devs to
join and give out your feedback or thoughts to help on improving
orchestration experiences.
*Here is the etherpad link so please share your opinions whether you're
coming to the summit or not.
**https://etherpad.openstack.org/p/BOS-forum-Large-Heat-stacks
<https://etherpad.openstack.org/p/BOS-forum-Large-Heat-stacks>*


If you wish to learn more detail on heat from beginner
welcome join our *`Heat- Project Onboarding
<https://www.openstack.org/summit/boston-2017/summit-schedule/events/18702/heat-project-onboarding>`
*
Forum session *(Tuesday, May 9, 2:00pm-3:30pm)*
Feel free to contact me and share what you would like to learn from this
session, which I will try my best to put something in.


And if you're interested in overall project update
welcome, join our *`Project Update - Heat
<https://www.openstack.org/summit/boston-2017/summit-schedule/events/18598/project-update-heat>`
session (Monday, May 8, 5:30pm-6:10pm)*



Also, there are a lot of heat relative talks
<https://www.openstack.org/summit/boston-2017/summit-schedule/global-search?t=Heat>,
so feel free to walk around and discover it out

May The Force of OpenStack Be With You,
Rico Lin (irc: ricolin)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][ironic][tripleo] ironic resources in heat

[Rico Lin]

Cool Pavlo
Would very glad to have you work on that together.
The new proposed spec tended to partly reuse Steven's patches (as many as
it can, but apparently not the spec). I try to separate it into two parts,
ironic management resource (this is covered by that spec) and ironic
deployment resource (which required more feedback since it actually trying
to do the same thing that nova resource can provide). And focus on first
part first, but it's totally fine by me to add the second part as another
spec if you can help to convince both heat and ironic team to add the
second part.
The only thing that blocks us from doing the spec right away is what I
think you can bring, `the needs`. If you can help to add that to the spec
(or feel free to rewrite it entirely). I scene that we really required to
know how users/ops/ironic will using it before we dig in. Maybe you can
share some story here?:)

Please add your name to `Primary assignees` and welcome back:)
Cheers,

2017-04-27 14:39 GMT+08:00 Pavlo Shchelokovskyy <
pshchelokovs...@mirantis.com>:

> HI all,
>
> from some conversations I had during Pike PTG and recently in IRC I
> understood that the need for ironic resources in heat has arisen again. I
> remember back when it was proposed for the first time there was some
> opposition from ironic community (although I personally find it reasonable
> to have those) but AFAIU this is no longer the case.
>
> I would gladly revive old Steven Hardy patches [0] (have them starred on
> Gerrit since then :) ) and make it happen if there are no objections.
>
> I also see that the spec itself to this regard has been recently
> re-proposed [1], so if someone is already working on those, I'm
> volunteering to help with it with my both ironic and heat hats on :)
>
> [0] https://review.openstack.org/#/q/project:openstack/
> heat+topic:bp/ironic-resource
> [1] https://review.openstack.org/#/c/393108/
>
> Cheers,
>
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][heat] Nominate huangtianhua for heat-stable-maint

[Rico Lin]

+1 for huangtianhua. She been very active for stable branch and all the
reviews and patches seems all fallowing stable branch rules.

+1 for remove Angus, and thanks very much for his hard works. Hope to have
him join in the future.

2017年3月31日 上午4:48，"Zane Bitter" 寫道：

> We are feeling the pinch on stable-branch reviewers in Heat, so now that I
> understand the process a bit better, let's try this again.
>
> I'd like to nominate Huang Tianhua to join the heat-stable-maint team.
> Tianhua is a heat-core member and one of our most prolific stable branch
> reviewers:
>
> https://review.openstack.org/#/q/reviewer:huangtianhua+-owne
> r:huangtianhua+projects:openstack/heat+branch:%22%255Estable/.*%22
>
> IMHO her track record displays an understanding of the stable branch
> policies appropriate to a stable branch core. e.g.
>
> * https://review.openstack.org/#/c/434030/
> * https://review.openstack.org/#/c/371135/
> * https://review.openstack.org/#/c/244948/
>
> Also, I suggest we take this opportunity to remove Angus Salkeld, since he
> is no longer actively working on OpenStack (http://stackalytics.com/?rele
> ase=all_id=asalkeld)
>
> thanks,
> Zane.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Project Navigator Updates - Feedback Request

[Rico Lin]

 The `API Version History` links in all project seems incorrect to me (For
example, `Version v1.0 (Ocata) - LATEST RELEASE` should link to
https://releases.openstack.org/ocata/index.html#ocata-heat not
https://releases.openstack.org/ ).

Some of the groupings seem a little bit strange. It's weird to see Heat and
> Horizon, which are essentially just two different user interfaces to
> OpenStack, in different groups. Also strange to see Senlin in a different
> group to Heat, since they both do autoscaling. I can't imagine why Mistral
> is listed under "Security, Identity and Compliance". There's quite a few
> more that look odd to me as well, mostly as a result of stuff that I might
> have expected to all land together in a catch-all like "Application
> Services" being split into more specific categories, like Freezer going
> under Storage.

Agree, I suggest we can use a group `Application services` or
`Orchestration Services` for all Mistral, Heat, Senlin, etc. seems we
actually have users use OpenStack with that combinations. And we can also
consider use multi-layer grouping.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptls] Project On-Boarding Rooms

[Rico Lin]

And we're ok to share the slot:)

2017-03-16 23:53 GMT+08:00 Rico Lin <rico.lin.gua...@gmail.com>:

>
>> These are the projects that have requested a slot:
>>
>> Solum
>> Tricircle
>> Karbor
>> Freezer
>> Kuryr
>> Mistral
>> Dragonflow
>> Coudkitty
>> Designate
>> Trove
>> Watcher
>> Magnum
>> Barbican
>> Charms
>> Tacker
>> Zun
>> Swift
>> Watcher
>> Kolla
>> Horizon
>> Keystone
>> Nova
>> Cinder
>> Telemetry
>> Infra/QA/RelMgmt/Regs/Stable
>> Docs/i18n
>>
>
> Heat is missing:)
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptls] Project On-Boarding Rooms

[Rico Lin]

>
>
> These are the projects that have requested a slot:
>
> Solum
> Tricircle
> Karbor
> Freezer
> Kuryr
> Mistral
> Dragonflow
> Coudkitty
> Designate
> Trove
> Watcher
> Magnum
> Barbican
> Charms
> Tacker
> Zun
> Swift
> Watcher
> Kolla
> Horizon
> Keystone
> Nova
> Cinder
> Telemetry
> Infra/QA/RelMgmt/Regs/Stable
> Docs/i18n
>

Heat is missing:)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptls] Project On-Boarding Rooms

[Rico Lin]

I'm interested in having a Heat on-boarding room:)

2017-03-16 8:39 GMT+08:00 Zhipeng Huang <zhipengh...@gmail.com>:

> Hi Kendall,
>
> If this could also apply to the unofficial projects, then Cyborg project
> would also like to have a slot, we could have at least one team member to
> do the on-boarding :)
>
> On Thu, Mar 16, 2017 at 8:16 AM, joehuang <joehu...@huawei.com> wrote:
>
>> Hello, Kendall,
>>
>> Tricircle need a slot too, if it's not too late :).
>>
>> Thanks providing the project on-boarding opportunity.
>>
>> Best Regards
>> Chaoyi Huang (joehuang)
>> --
>> *From:* Kendall Nelson [kennelso...@gmail.com]
>> *Sent:* 16 March 2017 2:20
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* [openstack-dev] [ptls] Project On-Boarding Rooms
>>
>> Hello All!
>>
>> As you may have seen in a previous thread [1] the Forum will offer
>> project on-boarding rooms! This idea is that these rooms will provide a
>> place for new contributors to a given project to find out more about the
>> project, people, and code base. The slots will be spread out throughout the
>> whole Summit and will be 90 min long.
>>
>> We have a very limited slots available for interested projects so it will
>> be a first come first served process. Let me know if you are interested and
>> I will reserve a slot for you if there are spots left.
>>
>> - Kendall Nelson (diablo_rojo)
>>
>> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-Marc
>> h/113459.html
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] heat PTG recap

[Rico Lin]

Hi everyone,

Heat team gathered at the PTG from 2/22-2/24

Here is some discussion that we have targeted during PTG:
https://etherpad.openstack.org/p/heat-pike-ptg-sessions

Targeted tasks or discussions:
* We have reached an agreement with release team about the stable mint list
management for Heat will remain on stable mint cores. Members who give
enough review to stable releases patches will have more chance to be
promoted as Stable mint for heat. All above information is now in the
official policy from release team.

* We need Python 3 support, This is the community width goal. We will have
to make sure all heat's repo has reached this requirement. There already
landed some patches for Python 35 support (see
https://etherpad.openstack.org/p/pike-heat-ptg-python3 ).
* We have to collaborate with Interop team to define tests(API and scenario
tests) for heat for all can define what is heat.

* We agree with heat should have an interface for resources for any
resource plugins. So the resources won't directly use inner methods.
* For Convergence 2.0+ required, we need a notification system for heat
resources. Also, we have talked about if no volunteer for convergence
doc(we decide to do in Ocata release), we will postpone our doc plan for
convergence.
For above two tasks, you can find reference here
https://etherpad.openstack.org/p/pike-heat-ptg-convergence2

* For convergence adoption, we might still require some memory improvement
for the tripleO project to adopt convergence mode.

* Feedback from Sahara and Magnum team, when a lot of resources been
deleted (like stack-delete action), we might throw a huge number of API
calls in a very short period (For example, to Cinder) and course some
service overload situation. This might be one issue we can try to help to
make some more friendly API calling schedule to other services.
* Feedback from user survey,
What's the current/expected load on your Heat deployment?
Few big stacks (>100 resources each) = 6 (9%)
Few small stacks (<100 resources each) = 50 (78%)
Lots of big stacks (>100 resources each) = 1
Lots of small stacks (<100 resources each) = 7 (10%)
( You can find the reference here
https://etherpad.openstack.org/p/pike-cp-ptg-orchestration-feedback )

* Feedback from TripleO team and Magnum team asking the possibility for
Heat to adopt Jinja2. As we do not recommend to use heat for deep layer
resource structure (A flat structure might work better.), we will consider
adding Jinja once more detail from other projects about how they might
using it (make sure we reach the target requirements.)
* Also, we have some interest use case that combining Heat and Mistral
(and/or Jinja) from TripleO team, would like to trace them with the entire
use case, and hope we can get complete use case and share out to any other
projects who might get benefit from it.
(Some reference you can see in
https://etherpad.openstack.org/p/pike-cp-ptg-orchestration-integrate )

* Identity trust and federate still not working for Heat (and some other
services). we have to make an announcement about heat user should not use
federation until keystone fix it. (see
https://etherpad.openstack.org/p/keystone-pike-ptg)

For specs, we're consider fallowing actions:
We have obsolete some very old PB (feel free to raise any discussion if you
have some very important BP been obsoleted).
Also lower the Blueprint priority, for V2 API, we still mark v2(or maybe we
should call v1.1) API as the next thing we need to do, but seems should not
settle down during Pike cycle. For more other actions please reference here
https://etherpad.openstack.org/p/pike-heat-ptg-track-and-design

We also spend some more time with reviewing patches, which all listed in
Etherpads, so I'm not going to list all of it here.
Feel free to raise further discussion for any topics, we can always discuss
anything in detail through the entire cycle.


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][all]Heat evening event on Thrusday this week

[Rico Lin]

We're at second floor

2017年2月23日 下午2:37，"Rico Lin" <rico.lin.gua...@gmail.com>寫道：

.

2017-02-23 2:42 GMT+08:00 Rico Lin <rico.lin.gua...@gmail.com>:

> Dear all
>
> We will have a PTG dinner and beer session on Thursday night 7:00
> Here is the place: http://www.maxlagersrestaurantatlanta.com/
> *location: 320 Peachtree St NE, Atlanta, GA*.
> All teams are welcome to join us.
>
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][all]Heat evening event on Thrusday this week

[Rico Lin]

.

2017-02-23 2:42 GMT+08:00 Rico Lin <rico.lin.gua...@gmail.com>:

> Dear all
>
> We will have a PTG dinner and beer session on Thursday night 7:00
> Here is the place: http://www.maxlagersrestaurantatlanta.com/
> *location: 320 Peachtree St NE, Atlanta, GA*.
> All teams are welcome to join us.
>
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev