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

[Qiming Teng]

> >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

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

[Qiming Teng]

Hi,

Due to many reasons, I cannot join you on this event, but I do like to
leave some comments here for references.

On Tue, Sep 18, 2018 at 11:27:29AM +0800, Rico Lin wrote:
> *TL;DR*
> *How about a forum in Berlin for discussing autoscaling integration (as a
> long-term goal) in OpenStack?*

First of all, there is nothing called "auto-scaling" in my mind and
"auto" is most of the time a scary word to users. It means the service
or tool is hiding some details from the users when it is doing something
without human intervention. There are cases where this can be useful,
there are also many other cases the service or tool is messing up things
to a state difficult to recover from. What matters most is the usage
scenarios we support. I don't think users care that much how project
teams are organized.
 
> 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.

The original plan, iirc, was to make sure Senlin resources are supported
in Heat, and we will gradually fade out the existing 'AutoScalingGroup'
and related resource types in Heat. I have no clue since when Heat is
interested in "auto-scaling" again. 

> 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.

The so called "auto-scaling" is always a solution, built by
orchestrating many moving parts across the infrastructure. In some
cases, you may have to install agents into VMs for workload metering. I
am not convinced this can be done using a library approach.

> *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.

Totally agree with you on this. We should strive to minimize the
technologies users have to master when they have a need.
> 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

Re: [openstack-dev] [senlin][stable] Nominating chenyb4 to Senlin Stable Maintainers Team

[Qiming Teng]

+2 from me.

Thanks.
 - Qiming

On Mon, Sep 10, 2018 at 09:56:10AM -0700, Duc Truong wrote:
> Hi Senlin Stable Team,
> 
> I would like to nominate Yuanbin Chen (chenyb4) to the Senlin stable
> review team. Yuanbin has been doing stable reviews and shown that he
> understands the policy for merging stable patches [1].
> 
> Voting is open for 7 days. Please reply with your +1 vote in favor or
> -1 as a veto vote.
> 
> [1] 
> https://review.openstack.org/#/q/branch:%255Estable/.*+reviewedby:cybing4%2540gmail.com
> 
> Regards,
> 
> Duc (dtruong)
> 
> __
> 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] [senlin] Nominations to Senlin Core Team

[Qiming Teng]

+2 to both changes.

- 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

Re: [openstack-dev] [senlin] Senlin Weekly Meeting Time Change

[Qiming Teng]

Works for me.

-Qiming

On Mon, Aug 20, 2018 at 09:34:46PM -0700, Duc Truong wrote:
> Hi,
> 
> As we are starting the Stein cycle, I would like to start having weekly
> meetings again for Senlin.  I'm proposing to move the weekly meeting
> to the following time:
> 
> Friday 5:30 UTC to 6:30 UTC in #senlin channel
> 
> Please reply if this works for you or reply with an alternative time
> slot.
> 
> Thanks,
> 
> Duc


__
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] [Senlin]??Nominate??changing in Senlin core team

[Qiming Teng]

+1 to both.

- Qiming

On Fri, Mar 09, 2018 at 05:28:06PM +0800, liu.xuefe...@zte.com.cn wrote:
> Hi team,I would like to propose adding chenyb and DucTruong to the Senlin 
> core team.
> 
> 
> Chenyb has been working on Openstack more than 3 years, with the 
> responsibility of intergation Nova, Senlin and Ceilometer cloud production.  
> He has finished many features and bugs for Senlin project, now he is the most 
> active non-core contributor on Senlin group projects.
> 
> 
> DucTruong works for Blizzard Entertainment, Blizzard company is an active 
> user of Senlin project. Duc and his colleagues have  finished some useful 
> features for Senlin, from this feautres they also got a good understand about 
> Senlin. Now Duc is a active code reviewer on Senlin.
> 
> 
> 
> 
> 
> 
> -- ThanksXueFeng


> __
> 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

[openstack-dev] [CI][Keystone][Requirements][Release] What happened to the gate on Feb 4th?

[Qiming Teng]

Starting about 24 hours ago, we have been notified CI gate failure
although we haven't changed anything to our project locally. Before that
we have spent quite some time making the out-of-tree tempest plugins
work on gate.

After checking the log again and again ... we found the following logs
from Keystone:

Feb 05 03:31:12.609492 ubuntu-xenial-ovh-gra1-0002362092
devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
req-dfcbf106-fbf5-41bd-9012-3c65d1de5f9a None admin] Could not find
project: service.: ProjectNotFound: Could not find project: service.

Feb 05 03:31:13.845694 ubuntu-xenial-ovh-gra1-0002362092
devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
req-50feed46-7c15-425d-bec7-1b4a7ccf6859 None admin] Could not find
service: clustering.: ServiceNotFound: Could not find service:
clustering.

Feb 05 03:31:12.552647 ubuntu-xenial-ovh-gra1-0002362092
devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
req-0a5e660f-dad6-4779-aea4-dd6969c728e6 None admin] Could not find
domain: Default.: DomainNotFound: Could not find domain: Default.

Feb 05 03:31:12.441128 ubuntu-xenial-ovh-gra1-0002362092
devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
req-7eb9ed90-28fc-40aa-8a41-d560f7a156c9 None admin] Could not find
user: senlin.: UserNotFound: Could not find user: senlin.

Feb 05 03:31:12.336572 ubuntu-xenial-ovh-gra1-0002362092
devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
req-19e52d02-5471-49a2-8acd-360199d8c6e0 None admin] Could not find
role: admin.: RoleNotFound: Could not find role: admin.

Feb 05 03:28:33.797665 ubuntu-xenial-ovh-gra1-0002362092
devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
req-544cd822-18a4-4f7b-913d-297716418239 None admin] Could not find
user: glance.: UserNotFound: Could not find user: glance.

Feb 05 03:28:29.993214 ubuntu-xenial-ovh-gra1-0002362092
devstack@keystone.service[24845]: WARNING py.warnings [None
req-dc411d9c-6ab9-44e3-9afb-20e5e7034f12 None admin]
/usr/local/lib/python2.7/dist-packages/oslo_policy/policy.py:865:
UserWarning: Policy identity:create_endpoint failed scope check. The
token used to make the request was project scoped but the policy
requires ['system'] scope. This behavior may change in the future where
using the intended scope is required

Feb 05 03:28:29.920892 ubuntu-xenial-ovh-gra1-0002362092
devstack@keystone.service[24845]: WARNING keystone.common.wsgi [None
req-32a4a378-d6d3-411e-9842-2178e577af27 None admin] Could not find
service: compute.: ServiceNotFound: Could not find service: compute.



--

So I'm wondering what the hack happened? Keystone version bump?
Devstack changed? Tempest settings changed? 
Why are we merging these changes near the end of a cycle when people are
focusing on stabilizing things?

Any hints on these are highly appreciated.

- 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

Re: [openstack-dev] Garbage patches for simple typo fixes

[Qiming Teng]

On Fri, Sep 22, 2017 at 04:47:27PM -0700, Michael Johnson wrote:
> A recent extreme example:
> https://review.openstack.org/#/c/494981/1/specs/version0.8/active_passive_loadbalancer.rst

Haha, buddy, let me fix your name! ;)

> I would love to have a boilerplate statement I can use as a template
> for things like this.  I feel bad -1/-2 these as I want to encourage
> involvement, but they are a drain on the system.
> 
> Michael
> 
> 
> On Fri, Sep 22, 2017 at 4:18 PM, Zhipeng Huang  wrote:
> > Hi Doug,
> >
> > Absolutely glad to help on this matter. We could take this offline first via
> > email or irc chat and then comes up with a solution for the broader
> > community to review
> >


__
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] Garbage patches for simple typo fixes

[Qiming Teng]

To some extent, I think Zhipeng is right. There are times we as a
community have to do something beyond mentoring new developers. One of
the reasons behind these patches are from the management chain of those
companies. They need numbers, and they don't care what kind of
contributions were made. They don't bother read these emails.

Another fact is that some companies are doing such things not just in the
OpenStack community. Their developers are producing tons of low-quality
"patches" to play this as a game in other communities as well. If we
don't place a STOP sign, things will never get improved. By not doing
something, we are hurting everyone, including those developers who could
have done more meaningful contributions, though their number of patches
may decrease.

Just my 2 cents.

- Qiming 

On Sat, Sep 23, 2017 at 08:34:18AM +0800, Zhipeng Huang wrote:
> Hi Paul,
> 
> Unfortunately I know better on this matter and it is not the matter of
> topic dispute as many people on this thread who has been disturbed and
> annoyed by the padding/trolling.
> 
> So yes I'm sticking with stupid because it hurts the OpenStack community as
> a whole and hurts the reputation of the dev community from my country which
> in large are great people with good hearts and skills.
> 
> I'm not giving even an inch of the benefit of doubt to these padding
> activities and people behind it.
> 
> 
> On Sat, Sep 23, 2017 at 8:16 AM, Paul Belanger 
> wrote:
> 


__
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] [Senlin] Senlin Queens Meetup

[Qiming Teng]

I'd love to join you on Oct 14th, but I'm out of town.

- Qiming
On Tue, Sep 19, 2017 at 10:04:03PM +0800, YUAN RUIJIE wrote:
> Hi all,
> 
> We are going to have a meetup to discuss the features and some other
> details about Senlin in Oct.
> Tentatively schedule：
> Date: 15th Oct.
> Location: Beijing, CHN
> 
> 
> Please leave your comments if you have any suggestion or the have conflict
> with the date.
> 
> Sincerely,
> ruijie

> __
> 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] 答复: Re: [senlin] How to delete cluster in the state of'DELEING'

[Qiming Teng]

Vote for '--force'. Status update operation smells an overkill in this
case.

- Qiming
On Wed, Sep 13, 2017 at 01:37:44PM +0800, Lee Yi wrote:
> --force will be better, in my opinion.
> 
> On Wed, Sep 13, 2017 at 1:23 PM,  wrote:
> 
> > You killed mysql? Okay ...
> >
> > Seems we need to add a "--force" parameter to the delete operation.
> >
> > - Qiming
> >
> > On Tue, Sep 12, 2017 at 09:14:25PM +0800, Lee Yi wrote:
> > > When deleting a cluster named 'server_cluster', I
> > shutdown mysql service.
> > > And then the status of cluster will be 'DELETING' forever, like follow:
> > >
> > > {0}nbsp;openstack cluster list
> > > +--++--+
> > > --+--+
> > > | id   | name   | status   | created_at
> > | updated_at
> > >   |
> > > +--++--+
> > > --+--+
> > > | 672d043f | server_cluster | DELETING | 2017-09-12T10:52:16Z |
> > > 2017-09-12T11:16:15Z |
> > > +--++--+
> > > --+--+
> > >
> > > I can't  delete it again, because:
> > >
> > > {0}nbsp;openstack cluster delete server_cluster
> > > Are you sure you want to delete this cluster(s) [y/N]?y
> > >  server_cluster: failed due to 'HttpException: The
> > cluster 'server_cluster'
> > > is in status DELETING. (HTTP 409) (Request-ID:
> > > req-42eeda10-9055-40c2-b690-5627ac555922),
> > > The cluster 'server_cluster' is in status DELETING.'
> > >
> > > And the action is in WAITING status:
> > >
> > > {0}nbsp;openstack cluster action show d36fc6b5-ac5e-
> > 460e-85dc-afdb680f3242
> >
> > > +---+--+
> > > | Field | Value|
> > > +---+--+
> > > | action| CLUSTER_DELETE   |
> > > | cause | RPC Request  |
> > > | created_at| 2017-09-12T11:16:15Z |
> > > | depended_by   |  |
> > > | depends_on| d0f6e1c0-491f-4318-9cc2-41ae2028b99f |
> > > | domain_id | None |
> > > | end_at| None |
> > > | id| d36fc6b5-ac5e-460e-85dc-afdb680f3242 |
> > > | inputs| {}   |
> > > | interval  | -1   |
> > > | location  | None |
> > > | name  | cluster_delete_672d043f  |
> > > | outputs   | {}   |
> > > | owner_id  | 9dd42d67-f0c6-4199-8c4f-15f3cd88683b |
> > > | project_id| 3adeed30eb694bdd98257b294120e595 |
> > > | start_at  | 1505214976.0 |
> > > | status| WAITING  |
> > > | status_reason | Waiting for depended actions.|
> > > | target_id | 672d043f-ef7b-4a7a-a41a-176a9929296e |
> > > | timeout   | 3600 |
> > > | updated_at| None |
> > > | user_id   | 4b805d08ec1644ef8f69078ddd59941c |
> > > +---+--+
> > >
> > > What can I do about this cluster, and how to delete it again.
> > >
> > > Obviously, I can modify the code (
> > > https://github.com/openstack/senlin/blob/master/
> > senlin/engine/service.py#L878-L881)
> > > to support to delete the cluster again, but I don't
> > think it's the best way.
> > >
> > > The same problems exist  when do other actions.
> > >
> > > Any suggestion?
> >
> > > __
> > 


__
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] [Zun] Propose change of the core team

[Qiming Teng]

+1 on both.

On Thu, Sep 14, 2017 at 01:58:48PM +, Hongbin Lu wrote:
> Hi all,
> 
> I propose the following change of the Zun core reviewer team.
> 
> + Kien Nguyen (kiennt2609)
> - Aditi Sharma (adi-sky17)
> 
> Kien has been contributing to the Zun project for a few months. His 
> contributions include proposing high-quality codes, providing helpful code 
> reviews, participating team discussion at weekly team meeting and IRC, etc. 
> He is the one who setup the multi-node job in the CI and the job is up and 
> running now. I think his contribution is significant which qualifies him to 
> be a core reviewer. Aditi is a member of the initial core team but becomes 
> inactive for a while.
> 
> Core reviewers, please cast your vote on this proposal.
> 
> Best regards,
> Hongbin


__
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] [senlin] Meeting for Queens Goal

[Qiming Teng]

I'll attend both if time permits.

- Qiming
On Thu, Sep 14, 2017 at 06:58:38PM +0800, YUAN RUIJIE wrote:
> Hi Senlin Core Team,
> 
> We are going to have a meetup to discuss the goal & features we want to
> implement in Queens cycle. As we discussed during the latest weekly
> meeting, we have the follow options:
> 
> 1. Have a virtual meeting by some meeting softwares
> 2. Organize a Meetup in middle Oct, since the National Day is coming.
> 
> Suggestions are welcomed,
> 
> Sincerely,
> ruijie

> __
> 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] [senlin] How to delete cluster in the state of 'DELEING'

[Qiming Teng]

You killed mysql? Okay ...

Seems we need to add a "--force" parameter to the delete operation.

- Qiming

On Tue, Sep 12, 2017 at 09:14:25PM +0800, Lee Yi wrote:
> When deleting a cluster named 'server_cluster', I shutdown mysql service.
> And then the status of cluster will be 'DELETING' forever, like follow:
> 
> $ openstack cluster list
> +--++--+
> --+--+
> | id   | name   | status   | created_at   | updated_at
>   |
> +--++--+
> --+--+
> | 672d043f | server_cluster | DELETING | 2017-09-12T10:52:16Z |
> 2017-09-12T11:16:15Z |
> +--++--+
> --+--+
> 
> I can't  delete it again, because:
> 
> $ openstack cluster delete server_cluster
> Are you sure you want to delete this cluster(s) [y/N]?y
>  server_cluster: failed due to 'HttpException: The cluster 'server_cluster'
> is in status DELETING. (HTTP 409) (Request-ID:
> req-42eeda10-9055-40c2-b690-5627ac555922),
> The cluster 'server_cluster' is in status DELETING.'
> 
> And the action is in WAITING status:
> 
> $ openstack cluster action show d36fc6b5-ac5e-460e-85dc-afdb680f3242
> +---+--+
> | Field | Value|
> +---+--+
> | action| CLUSTER_DELETE   |
> | cause | RPC Request  |
> | created_at| 2017-09-12T11:16:15Z |
> | depended_by   |  |
> | depends_on| d0f6e1c0-491f-4318-9cc2-41ae2028b99f |
> | domain_id | None |
> | end_at| None |
> | id| d36fc6b5-ac5e-460e-85dc-afdb680f3242 |
> | inputs| {}   |
> | interval  | -1   |
> | location  | None |
> | name  | cluster_delete_672d043f  |
> | outputs   | {}   |
> | owner_id  | 9dd42d67-f0c6-4199-8c4f-15f3cd88683b |
> | project_id| 3adeed30eb694bdd98257b294120e595 |
> | start_at  | 1505214976.0 |
> | status| WAITING  |
> | status_reason | Waiting for depended actions.|
> | target_id | 672d043f-ef7b-4a7a-a41a-176a9929296e |
> | timeout   | 3600 |
> | updated_at| None |
> | user_id   | 4b805d08ec1644ef8f69078ddd59941c |
> +---+--+
> 
> What can I do about this cluster, and how to delete it again.
> 
> Obviously, I can modify the code (
> https://github.com/openstack/senlin/blob/master/senlin/engine/service.py#L878-L881)
> to support to delete the cluster again, but I don't think it's the best way.
> 
> The same problems exist  when do other actions.
> 
> Any suggestion?

> __
> 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

[openstack-dev] [Senlin] Proposing Liyi as core reviewer

[Qiming Teng]

Dear Senlin cores,

As you might have witnessed, Liyi has been a solid contributor to Senlin
during Pike cycle. His patches are of high quality, showing that he has
a good grasp of the design and the code. Based on the contribution
record and his agreement to work with the team more closely, I'm
proposing adding him to the core team.

Please reply this email if there are concerns or comments.

Happy coding!

- 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

Re: [openstack-dev] [horizon][api][docs] Feedback requested on proposed formatting change to API docs

[Qiming Teng]

On Tue, May 16, 2017 at 05:13:16PM -0500, Monty Taylor wrote:
> Hey all!
> 
> I read the API docs A LOT. (thank you to all of you who have worked
> on writing them)
> 
> As I do, a gotcha I hit up against a non-zero amount is mapping the
> descriptions of the response parameters to the form of the response
> itself. Most of the time there is a top level parameter under which
> either an object or a list resides, but the description lists list
> the top level and the sub-parameters as siblings.
> 
> So I wrote a patch to os-api-ref taking a stab at providing a way to
> show things a little differently:
> 
> https://review.openstack.org/#/c/464255/
> 
> You can see the output here:
> 
> http://docs-draft.openstack.org/55/464255/5/check/gate-nova-api-ref-src/f02b170//api-ref/build/html/
> 
> If you go expand either the GET / or the GET /servers/details
> sections and go to look at their Response sections, you can see it
> in action.
> 
> We'd like some feedback on impact from humans who read the API docs
> decently regularly...
> 
> The questions:
> 
> - Does this help, hurt, no difference?

It helps.

> - servers[].name - servers is a list, containing objects with a name
> field. Good or bad?

Good.

> - servers[].addresses.$network-name - addresses is an object and the
> keys of the object are the name of the network in question.

This is a little bit confusing but still understandable.

my $0.0002 

Qiming
> Thanks!
> Monty
 


__
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] [senlin] weekly meeting cancelled for next two weeks

[Qiming Teng]

Folks, we the team will be at Boston attending the summit next week, so
we won't be able to hold the meeting on May 9th. We will also skip the
May 16th meeting as well because most of us have just returned home from
the trip.

- 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

Re: [openstack-dev] [Zun] Proposal a change of Zun core team

[Qiming Teng]

+1

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

Re: [openstack-dev] [api-wg] Question about 'OpenStack-API-Version' header

[Qiming Teng]

On Mon, Apr 17, 2017 at 10:22:16AM +0100, Chris Dent wrote:
> On Fri, 14 Apr 2017, Qiming Teng wrote:
> 
> >According to the microversion specification [1], the
> >'OpenStack-API-Version' header is optional. When it is omitted, the
> >server should act as if the minimum supported version was specified.
> 
> That's correct.
> 
> >Recently, we have received some complaints from users that for new APIs
> >added, we should state that the header is required. The new APIs are
> >valid only after a specific microversion. If the 'OpenStack-APi-Version'
> >header is missing, our server returns a 404 resource not found error.
> >It is confusing.
> 
> There's a bit of a circle here. If you're using microversions and you
> add a new feature at, for example, version 2.24 then yes, you must
> include the header with a microversion of 2.24 or beyond in order to
> use that feature. This is aligned with the "opt-in" nature of
> microversions and changes to the service.
> 
> If the new microversion is adding a new URL, then a 404 response is
> correct when that microversion has not been selected.
> 
> So, yes, it is the case that when adding a new URL to a service that
> is already supporting microversions, the header is required. That's
> pretty much how microversions work and the service documentation
> should indicate that.

This answered my question pretty well. Since we are using api-ref to
document the service API, each resource URL is documented separately.
For newly added URL, following micro-version guideline, we are supposed
to state that the micro-version header is required. This was the part
that is missing from the referenced guideline.

Thank you, Chris.

- Qiming
> Is there a different workflow that you (or the people complaining)
> have in mind that could work better? Is there something that could
> or should be clarified to make this more clear?
> 
> -- 
> Chris Dent ¯\_(ツ)_/¯   https://anticdent.org/
> freenode: cdent tw: @anticdent

> __
> 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

[openstack-dev] [api-wg] Question about 'OpenStack-API-Version' header

[Qiming Teng]

According to the microversion specification [1], the
'OpenStack-API-Version' header is optional. When it is omitted, the
server should act as if the minimum supported version was specified.

Recently, we have received some complaints from users that for new APIs
added, we should state that the header is required. The new APIs are
valid only after a specific microversion. If the 'OpenStack-APi-Version'
header is missing, our server returns a 404 resource not found error.
It is confusing.

So ... I'm reaching out to you for some comments and suggestions.
Are there any best practices on this?

- Qiming

[1]
https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.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] [magnum][osc] What name to use for magnum commands in osc?

[Qiming Teng]

On Tue, Mar 21, 2017 at 10:50:13AM -0400, Jay Pipes wrote:
> On 03/20/2017 09:24 PM, Qiming Teng wrote:
> >On Mon, Mar 20, 2017 at 03:35:18PM -0400, Jay Pipes wrote:
> >>On 03/20/2017 03:08 PM, Adrian Otto wrote:
> >>>Team,
> >>>
> >>>Stephen Watson has been working on an magnum feature to add magnum 
> >>>commands to the openstack client by implementing a plugin:
> >>>
> >>>https://review.openstack.org/#/q/status:open+project:openstack/python-magnumclient+osc
> >>>
> >>>In review of this work, a question has resurfaced, as to what the client 
> >>>command name should be for magnum related commands. Naturally, we’d like 
> >>>to have the name “cluster” but that word is already in use by Senlin.
> >>
> >>Unfortunately, the Senlin API uses a whole bunch of generic terms as
> >>top-level REST resources, including "cluster", "event", "action",
> >>"profile", "policy", and "node". :( I've warned before that use of
> >>these generic terms in OpenStack APIs without a central group
> >>responsible for curating the API would lead to problems like this.
> >>This is why, IMHO, we need the API working group to be ultimately
> >>responsible for preventing this type of thing from happening.
> >>Otherwise, there ends up being a whole bunch of duplication and same
> >>terms being used for entirely different things.
> >>
> >
> >Well, I believe the name and namespaces used by Senlin is very clean.
> 
> Note that above I referred to the Senlin *API*:
> 
> https://developer.openstack.org/api-ref/clustering/
> 
> The use of generic terms like "cluster", "node", "policy",
> "profile", "action", and "event" as *top-level resources in the REST
> API* are what I was warning about.
> 
> >Please see the following outputs. All commands are contained in the
> >cluster namespace to avoid any conflicts with any other projects.
> 
> Right, but I was talking about the REST API.
> 
> >On the other hand, is there any document stating that Magnum is about
> >providing clustering service?
> 
> What exactly is a clustering service?
> 
> I mean, Galera has a clustering service. Pacemaker has a clustering
> service. k8s has a clustering service. etcd has a clustering
> service. Zookeeper has a clustering service.
> 
> Senlin is an API that allows a user to group *virtual machines*
> together and expand or shrink that group of VMs. It's basically the
> old Heat autoscaling API done properly. There's a *lot* to like
> about Senlin's API and implementation.

Okay, I see where the confusion comes from. Senlin is designed to be a
*generic clustering service* that can create and manage whatever
resource types. It can create VM groups and manage the scaling of such
groups properly. It can provide VM HA based on the resource redundancy.
It models load-balancing support into a policy that can be attached to
and detached from a VM cluster.

Senlin manages "nodes" created from a "profile". A VM instance is only
one of the profile types supported. Senlin also supports clusters of
Heat stacks, clusters of docker containers today. There are also efforts
on managing bare-metal servers. 

The team also uses "resource pools" and "clusters" interchangeably,
because that IS what the service is about. Calling Senlin a resource
pool service may be more confusing, right?

- Qiming

> However, it would have been more appropriate (and forward-looking)
> to call Senlin's namespace "instance group" or "server group" than
> the generic term "cluster".
> 
> >  Why Magnum cares so much about the top
> >level noun if it is not its business?
> 
> Because Magnum uses the term "cluster" as a top-level resource in
> its own REST API:
> 
> http://git.openstack.org/cgit/openstack/magnum/tree/magnum/api/controllers/v1/cluster.py
> 
> The generic term "cluster" that Magnum uses should really be called
> "coe group" or "container engine group" or "container service group"
> or something like that, to better indicate what exactly is being
> operated on.
> 
> Best,
> -jay
> 
> >$ openstack --help | grep cluster
> >
> >  --os-clustering-api-version 
> >
> >  cluster action list  List actions.
> >  cluster action show  Show detailed info about the specified action.
> >  cluster build info  Retrieve build information.
> >  cluster check  Check the cluster(s).
> >  cluster 

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Qiming Teng]

On Mon, Mar 20, 2017 at 03:35:18PM -0400, Jay Pipes wrote:
> On 03/20/2017 03:08 PM, Adrian Otto wrote:
> >Team,
> >
> >Stephen Watson has been working on an magnum feature to add magnum commands 
> >to the openstack client by implementing a plugin:
> >
> >https://review.openstack.org/#/q/status:open+project:openstack/python-magnumclient+osc
> >
> >In review of this work, a question has resurfaced, as to what the client 
> >command name should be for magnum related commands. Naturally, we’d like to 
> >have the name “cluster” but that word is already in use by Senlin.
> 
> Unfortunately, the Senlin API uses a whole bunch of generic terms as
> top-level REST resources, including "cluster", "event", "action",
> "profile", "policy", and "node". :( I've warned before that use of
> these generic terms in OpenStack APIs without a central group
> responsible for curating the API would lead to problems like this.
> This is why, IMHO, we need the API working group to be ultimately
> responsible for preventing this type of thing from happening.
> Otherwise, there ends up being a whole bunch of duplication and same
> terms being used for entirely different things.
> 

Well, I believe the name and namespaces used by Senlin is very clean.
Please see the following outputs. All commands are contained in the
cluster namespace to avoid any conflicts with any other projects.

On the other hand, is there any document stating that Magnum is about
providing clustering service? Why Magnum cares so much about the top
level noun if it is not its business?


$ openstack --help | grep cluster

  --os-clustering-api-version 

  cluster action list  List actions.
  cluster action show  Show detailed info about the specified action.
  cluster build info  Retrieve build information.
  cluster check  Check the cluster(s).
  cluster collect  Collect attributes across a cluster.
  cluster create  Create the cluster.
  cluster delete  Delete the cluster(s).
  cluster event list  List events.
  cluster event show  Describe the event.
  cluster expand  Scale out a cluster by the specified number of nodes.
  cluster list   List the user's clusters.
  cluster members add  Add specified nodes to cluster.
  cluster members del  Delete specified nodes from cluster.
  cluster members list  List nodes from cluster.
  cluster members replace  Replace the nodes in a cluster with
  specified nodes.
  cluster node check  Check the node(s).
  cluster node create  Create the node.
  cluster node delete  Delete the node(s).
  cluster node list  Show list of nodes.
  cluster node recover  Recover the node(s).
  cluster node show  Show detailed info about the specified node.
  cluster node update  Update the node.
  cluster policy attach  Attach policy to cluster.
  cluster policy binding list  List policies from cluster.
  cluster policy binding show  Show a specific policy that is bound to
  the specified cluster.
  cluster policy binding update  Update a policy's properties on a
  cluster.
  cluster policy create  Create a policy.
  cluster policy delete  Delete policy(s).
  cluster policy detach  Detach policy from cluster.
  cluster policy list  List policies that meet the criteria.
  cluster policy show  Show the policy details.
  cluster policy type list  List the available policy types.
  cluster policy type show  Get the details about a policy type.
  cluster policy update  Update a policy.
  cluster policy validate  Validate a policy.
  cluster profile create  Create a profile.
  cluster profile delete  Delete profile(s).
  cluster profile list  List profiles that meet the criteria.
  cluster profile show  Show profile details.
  cluster profile type list  List the available profile types.
  cluster profile type show  Show the details about a profile type.
  cluster profile update  Update a profile.
  cluster profile validate  Validate a profile.
  cluster receiver create  Create a receiver.
  cluster receiver delete  Delete receiver(s).
  cluster receiver list  List receivers that meet the criteria.
  cluster receiver show  Show the receiver details.
  cluster recover  Recover the cluster(s).
  cluster resize  Resize a cluster.
  cluster runRun scripts on cluster.
  cluster show   Show details of the cluster.
  cluster shrink  Scale in a cluster by the specified number of nodes.
  cluster template list  List Cluster Templates.
  cluster update  Update the cluster.

- Qiming

> >Stephen opened a discussion with Dean Troyer about this, and found
> that “infra” might be a suitable name and began using that, and
> multiple team members are not satisfied with it.
> 
> Yeah, not sure about "infra". That is both too generic and not an
> actual "thing" that Magnum provides.
> 
> > The name “magnum” was excluded from consideration because OSC aims
> to be project name agnostic. We know that no matter what word we
> pick, it’s not going to be ideal. I’ve added an agenda on our
> upcoming team meeting to judge community consensus

Re: [openstack-dev] [Zun]Use 'uuid' instead of 'id' as object ident in data model

[Qiming Teng]

On Mon, Feb 20, 2017 at 02:14:20PM +0800, Wenzhi Yu wrote:
> Hi team,
> 
> I need your advice on this patch[1], which aims to implement etcd DB data 
> model and API
> for 'ResourceClass' object.
> 
> As you may know, in mysql implementation, mysql will generate a 'id' field, 
> which is an
> unique and auto increase integer. The 'id' is also used as 'primary key' or 
> 'foreign key'
> in mysql[2].

Can someone remind me the benefits we get from Integer over UUID as
primary key? UUID, as its name implies, is meant to be an identifier for
a resource. Why are we generating integer key values?

- Qiming
 
> However, in etcd implementation, etcd will NOT generate this 'id' itself, so 
> I intend to
> use the 'uuid' attribute of the object instead of 'id', and modify the DB API 
> method to use
> 'uuid' as object ident instead of 'id', like[3]. Personally I feel using 
> 'uuid' is more
> reasonable because 'id' is a specific field in DB like mysql, seems it does 
> not have actual
> meaning in data model, right?
> 
> An alternative way Hongbin suggested is to generate an unique 'id' like mysql 
> by ourselves
> and insert the 'id' into etcd data model. But he said he's OK with the idea 
> to replace 'id'
> with 'uuid' if it does not break anything.
> 
> What's your opinion on this issue? Thanks in advance!
> 
> [1]https://review.openstack.org/#/c/434909/
> [2]https://github.com/openstack/zun/blob/c0cebba170b8e3ea5e62e335536cf974bbbf08ec/zun/db/sqlalchemy/models.py#L200
> [3]https://github.com/openstack/zun/blob/c0cebba170b8e3ea5e62e335536cf974bbbf08ec/zun/db/etcd/api.py#L209
>  
> 
> 
> Best Regards,
> Wenzhi Yu (yuywz)


__
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][logos] License for new project mascots

[Qiming Teng]

Thanks, Jeremy. It works now.

- Qiming

On Wed, Feb 15, 2017 at 05:22:59PM +, Jeremy Stanley wrote:
> On 2017-02-15 09:48:28 +0800 (+0800), Qiming Teng wrote:
> > A related question: uploading file to wiki.openstack.org has been
> > blocked? I'm getting the following error when trying to do so.
> > 
> > Action failed
> > 
> > Could not open lock file for
> > "mwstore://local-backend/local-public/2/22/OpenStack_Project_Senlin_horizontal.jpg".
> 
> It seems that in a recent upgrade we ended up with the images file
> tree on the server only readable by the user the Web server runs as
> rather than writeable. I was able to reproduce the same error
> myself, but after adjusting the filesystem permissions it seems to
> be working now. Sorry about that... Can you try again and let us
> know how you get on?
> 
> As an aside, the JPEG versions of those logos suffer from some
> pretty severe compression artifacting, so using the PNG versions (or
> better still converting the EPS versions to SVG) will probably look
> a lot better in the end.
> -- 
> 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 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][logos] License for new project mascots

[Qiming Teng]

A related question: uploading file to wiki.openstack.org has been
blocked? I'm getting the following error when trying to do so.

Action failed

Could not open lock file for
"mwstore://local-backend/local-public/2/22/OpenStack_Project_Senlin_horizontal.jpg".


Regards,
 Qiming

On Tue, Feb 14, 2017 at 03:19:39PM +, Hayes, Graham wrote:
> Hi,
> 
> I did a bit of digging through email, and I *thought* someone had asked
> about the license that these logos were being released under. Turns out
> it was me, and I don't seem to have gotten a response about it.
> 
> So - what license are the new logos / mascots under?
> 
> Is the same as the wiki? [1] If not, it could present problems for
> people to upload copies of the logo to the wiki, as it assumes all
> content is CC-BY.
> 
> Thanks
> 
> - Graham
 


__
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] [octavia][sdk] service name for octavia

[Qiming Teng]

When reviewing a recent patch that adds openstacksdk support to octavia,
I found that octavia is using 'octavia' as its service name instead of
'loadbalancing' or 'loadbalancingv2' or something similar.

The overall suggestion is to use a word/phrase that indicates what a
service do instead of the name of the project providing that service.

Below is the list of the service types currently supported by
openstacksdk:

'alarming',# aodh
'baremetal',   # ironic
'clustering',  # senlin
'compute', # nova
'database',# trove
'identity',# keystone
'image',   # glance
'key-manager', # barbican
'messaging',   # zaqar
'metering',# ceilometer
'network', # neutron
'object-store',   # swift
'octavia',# <--- this is an exception
'orchestration',  # heat
'volume', # cinder
'workflowv2', # mistral

While I believe this has been discussed about a year ago, I'm not sure
if there are things we missed so I'm brining this issue to a broader
audience for discussion.

Reference:

[1] Patch to python-openstacksdk:
https://review.openstack.org/#/c/428414
[2] Octavia service naming:
http://git.openstack.org/cgit/openstack/octavia/tree/devstack/plugin.sh#n52

Regards, 
 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

[openstack-dev] [Senlin] PTL candidacy

[Qiming Teng]

The election of Pike PTL is happening during the Chinese Spring
Festival, so many developers from China are not reachable on radar.

As a community, we have done a lot of amazing work during the Ocata
cycle:

- Versioning everything, especially the engine RPCs
- Support status added to profile type, policy type
- Unified notification for message and event format
- Improved support to health policy
- Improved support to container profile
- and many others

It has been an unusual cycle because it is *very* short. It has been an
amazing cycle for the team because we have more hands working on
different things and we have identified quite some new requirements
for the team to contribute.

In the coming cycle, I'd like to again serve as the team facilitator,
which is called the PTL sometimes. My vision for the Pike cycle is as
follows:

- A mature, supported health policy implementation.
- A better management of the container clusters.
- A better support to the NFV use cases.
- A more comprehensive feature support in the dashboard project.
- A stronger team to take the Senlin project to its next level.

These are just things on top of my head. All ideas are welcomed.

- Qiming Teng


__
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] [Zun] Propose a change of the Zun core team membership

[Qiming Teng]

+1 to both.

On Mon, Jan 23, 2017 at 10:56:00PM +, Hongbin Lu wrote:
> Hi Zun cores,
> 
> I proposed a change of Zun core team membership as below:
> 
> + Kevin Zhao (kevin-zhao)
> - Haiwei Xu (xu-haiwei)
> 
> Kevin has been working for Zun for a while, and made significant 
> contribution. He submitted several non-trivial patches with high quality. One 
> of his challenging task is adding support of container interactive mode, and 
> it looks he is capable to handle this challenging task (his patches are under 
> reviews now). I think he is a good addition to the core team. Haiwei is a 
> member of the initial core team. Unfortunately, his activity dropped down in 
> the past a few months.
> 
> According to the OpenStack Governance process [1], we require a minimum of 4 
> +1 votes from Zun core reviewers within a 1 week voting window (consider this 
> proposal as a +1 vote from me). A vote of -1 is a veto. If we cannot get 
> enough votes or there is a veto vote prior to the end of the voting window, 
> this proposal is rejected.
> 
> [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
> 
> Best regards,
> Hongbin
> 

> __
> 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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Qiming Teng]

On Mon, Jan 16, 2017 at 08:21:02PM +, Fox, Kevin M wrote:
> IMO, This is why the big tent has been so damaging to OpenStack's progress. 
> Instead of lifting the commons up, by requiring dependencies on other 
> projects, there by making them commonly deployed and high quality, post big 
> tent, each project reimplements just enough to get away with making something 
> optional, and then the commons, and OpenStack as a whole suffers. This 
> behavior MUST STOP if OpenStack is to make progress again. Other projects, 
> such as Kubernetes are making tremendous progress because they are not 
> hamstrung by one component trying desperately not to depend on another when 
> the dependency is appropriate. They enhance the existing component until its 
> suitable and the whole project benefits. Yes, as an isolated dev, the 
> behavior to make deps optional seems to make sense. But as a whole, OpenStack 
> is suffering and will become increasingly irrelevant moving forward if the 
> current path is continued. Please, please reconsider what the current stance 
> on dependencies is d
>  oing to the community. This problem is not just isolated to barbican, but 
> lots of other projects as well. We can either help pull each other up, or we 
> can step on each other to try and get "on top". I'd rather we help each other 
> rather then the destructive path we seem to be on.
> 
> My 2 cents.
> Kevin
> 

Very well said, Kevin. The problem is not just about Barbican. Time for
the TC and the whole community to rethink or even just to realize
where we are heading ... Time for each and every projects to do some
introspection ... Time to solve this chicken-and-egg problem.

Stick together, there seems still a chance for future; otherwise, we
will feel guilty wasting people's life building something that is
falling apart eventually. Should we kill all "sh**-as-a-service"
projects and focus on the few "core" services and hope they will meet
all users' requirements? Or, should we give every project an equal
chance to be adopted? Who is blocking other services to get adopted?
How many projects are listed on the project navigator?

- 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

Re: [openstack-dev] Which service is using port 8778?

[Qiming Teng]

On Tue, Dec 20, 2016 at 06:16:59AM +, Ghanshyam Mann wrote:
> Yes, it seems placement API using it [1]
> 
> > 1. Recent changes to tempest is breaking our plugin. This is being
> >fixed.
> Tempest patch should fix issue but port issue blocking that[2]
> 
> For port think, I think we can change the placement API port to something 
> else. I will propose and we can get unused port there.
> But OpenStack port used by services are maintained here[3], may be it will be 
> good for each project to add their port in this list.
> 
> .. [1] - 
> https://github.com/openstack-dev/devstack/blob/master/lib/placement#L50 
> ..[2] https://review.openstack.org/#/c/412658/ 
> ..[3] 
> http://docs.openstack.org/newton/config-reference/firewalls-default-ports.html
>  
> 
> -gmann

Thanks for the pointer, Ghanshyam. We should have input port 8778 there
so people will know it is used.

 - Qiming
> 
> > -Original Message-
> > From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com]
> > Sent: 20 December 2016 14:45
> > To: openstack-dev@lists.openstack.org
> > Subject: [openstack-dev] Which service is using port 8778?
> > 
> > Hi, all,
> > 
> > Starting yesterday, Senlin's gate jobs kept failing due to two reasons:
> > 
> > 1. Recent changes to tempest is breaking our plugin. This is being
> >fixed.
> > 
> > 2. Senlin API cannot bind it to port 8778 now.
> > 
> > So, we are wondering which service else is using port 8778?
> > 
> > Thanks in advance for any hints.
> > 
> > Regards,
> >   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
> 
> __
> 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

[openstack-dev] Which service is using port 8778?

[Qiming Teng]

Hi, all,

Starting yesterday, Senlin's gate jobs kept failing due to two reasons:

1. Recent changes to tempest is breaking our plugin. This is being
   fixed.

2. Senlin API cannot bind it to port 8778 now.

So, we are wondering which service else is using port 8778?

Thanks in advance for any hints.

Regards,
  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

Re: [openstack-dev] [api][zun] Effective URL for resource actions

[Qiming Teng]

On Tue, Dec 20, 2016 at 10:14:49AM +0800, Alex Xu wrote:
> Yea, looks like no consensus at here. Look at the discussion Chris pointed
> to, the "/containers//action" sounds a good API for tasks.

Did you mean "/containers//actions" ?
 
> But we also see the disadvantage for it. When we want to use URL to
> identifying an action, we found all the actions into a single API. We faced
> this problem multiple times:

Then we should stop identifying actions based on URL. :)
The following URL for representing a 'pause' action is really ugly:

   /containers//pause

First of all, 'pause' is a verb. I cannot persuade myself that doing a
POST to a verb is a ReST call. And I cannot do a 'GET', 'DELETE' not
due to I'm not an admin ... rather, it is because I cannot explain what
it means by 'deleting a pause'.  
 
> 1. In the beginning of thinking about capability discovery, an idea is
> about returning a list of URLs if the user have the ability to execute. But
> found that all the actions are into single URL
> 2. Before there is an idea about if the policy rule name is the URL, then
> the user can easy to know the mapping between policy rule and API. The same
> problem, all the actions into single URL

Neither capability discovery or policy enforcement should be based
solely on URL, IMO. Capabilities should have its own resource
representation if possible. As for policy, it still seems an over
simplification of authorization. There many scenarios where users
want a finer granularity of access control. Even if we want to stick to
the policy.json approach today, we can somehow improve the checking, for
example:

   "containers:action:reboot": "role:owner"

Similarly, auditing and logging can be done in the same way.

> 3. Before think about using OpenAPI(swagger) to generate api doc, but the
> OpenAPI spec didn't support multiple "POST containers//action", that
> means we need to put all the actions into single entry. That makes the
> generated doc unreadable.

That is history now. We are moving to the api-ref way of documenting
APIs. Don't tell me there are plans to migrate it back, :D

- Qiming 
> But yes, that doesn't means we block on this problem. Finally we go to
> another direction. So just input something we met before for your
> consideration.
> 
> Thanks
> Alex
> 
> 2016-12-19 19:57 GMT+08:00 Chris Dent :
> 


__
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] [api][zun] Effective URL for resource actions

[Qiming Teng]

On Mon, Dec 19, 2016 at 11:57:26AM +, Chris Dent wrote:
> On Fri, 16 Dec 2016, Hongbin Lu wrote:
> 
> >I am from the Zun team and I wanted to consult with you about the API
> >design. Our team was discussing what is the best API design for
> >exposing different container operations [1]. There are two proposed
> >options:
> >
> >1. Expose multiple URLs for individual container operation. For example:
> [...]
> >
> >2. Expose a single URL for all operations. For example:
> [...]
> 
> How to deal with "actions" is something we've struggled to reach
> consensus about in the API-WG. There have been a few proposals over
> the years (including some like both of the options you've listed),
> but none have been loved by everyone. There's a great deal of
> discussion that has happened around this issue and could still
> happen. Below is my personal perspective.
> 
> There's a third option you may wish to consider that is perhaps a
> bit more resource oriented: use PUT or PATCH to update the state of
> the containers representation. Note that the examples should be take
> as describing an option, not indicating the right choices for the
> terms involved.
> 
> a) GET /containers/
> 
>This gets you a representation including some indicator of state.
> 
>{...
> "uptime": 542819,
> "state": "running",
> ...
>}
> 
> b) Change that state value to the target and PUT the representation
>back.
> 
>PUT /containers/
> 
>{...
> "state": "rebooting"
> ...
>}
> 
>Or, if for some reason you need to save some bytes, you could
>PATCH the state attribute.
> 
> c) If the change takes time and the request is asynchronous, the
>response could be 202 and doing a GET will representing the
>change in progress:

My gut feeling is that most "actions" we are initiating fall into the
asynchronous group. For example, we are not modeling a GET request on
/containers/ as an action.
 
>GET /containers/
> 
>{...
> "state": "rebooting",
> ...
>}
> 
>[time passes..]
> 
>GET /containers/
> 
>{...
> "uptime": 30,
> "state": "running",
> ...
>}
> 
> Like everything this mode has advantages and disadvantages. One
> advantage is that we avoid adding URLs. One disadvantage (for some)
> is that passing around the full representation is complex and/or
> confusing.

Another disadvantage is about access control (aka. policy). We will have
to check who is authorized to change which field to what value. Going
further down this direction we may have, for example:

   PUT/PATCH /containers//state

But we still can see a lot limitations in this approach.
 
> As discussed on the abandoned review[1] referenced from the etherpad
> it is important to distinguish between actions which are atomic (at
> least from the perspective of the user-agent) and don't need
> observation and sequences of tasks which may need observation and
> may need to be interrupted and continued.
> 
> The former are changes in resource state, and thus could be
> represented as such (as I've described above).
> 
> In the latter, the task is (or tasks are ) the actual resource and
> should be the thing that is addressed by URL. That resource should
> make reference to the other entities which are being manipulated by
> the task.

Having a single URI /containers//actions to model this seems a
better option in my opinion. These tasks are the things we are
authorizing, validating, performing, verifying, auditing... A
single task/action may change more than one states. Abstracting these
operations into state changes doesn't look the right to do.

- Qiming
> From a user's standpoint stop, start, pause, unpause, reboot etc are
> isolated actions that describe a state of the container resource.
> [1] https://review.openstack.org/#/c/234994/
> 
> -- 
> Chris Dent ¯\_(ツ)_/¯   https://anticdent.org/
> freenode: cdent tw: @anticdent


__
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] [devstack] About installing devstack on Ubuntu

[Qiming Teng]

Try:

 apt-get install python-dev 

BTW, this list is about openstack developers. For questions about
installation and usage, please post to openst...@lists.openstack.org
or try ask.openstack.org

Regards,
  Qiming

On Tue, Dec 06, 2016 at 02:07:58PM +0800, Yipei Niu wrote:
> Hi, All,
> 
> I failed installing devstack on Ubuntu. The detailed info of local.conf and
> error is pasted in http://paste.openstack.org/show/591493/.
> 
> BTW, python2.7 is installed in Ubuntu, and Python.h can be found under
> /usr/include/python2.7.
> 
> stack@stack-VirtualBox:~$ locate Python.h
> 
> /usr/include/python2.7/Python.h
> 
> 
> Look forward to your comments. Thanks.
> 
> Best regards,
> Yipei

> __
> 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] [Zun] Propose a change of Zun core membership

[Qiming Teng]

+1 to both.

On Wed, Nov 30, 2016 at 11:37:59PM +, Hongbin Lu wrote:
> Hi Zun cores,
> 
> I am going to propose the following change of the Zun core reviewers team:
> + Pradeep Kumar Singh (pradeep-singh-u)
> - Vivek Jain (vivek-jain-openstack)
> 
> Pradeep was proven to be a significant contributor to Zun. He ranked first at 
> the number of commits, and his patches were non-trivial and with high 
> quality. His reviews were also very helpful, and often prompted us to 
> re-think the design. It would be great to have him in the core team. I would 
> like to thank Vivek for his interest to join the core team when Zun was 
> found. However, he became inactive in the past a few months, but he is 
> welcomed to re-join the core team as long as he becomes active again.
> 
> According to the OpenStack Governance process [1], we require a minimum of 4 
> +1 votes from Zun core reviewers within a 1 week voting window (consider this 
> proposal as a +1 vote from me). A vote of -1 is a veto. If we cannot get 
> enough votes or there is a veto vote prior to the end of the voting window, 
> this proposal is rejected.
> 
> [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
> 
> Best regards,
> Hongbin



__
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] [Senlin]Nominating Ruijie Yuan for Senlin core reviewer

[Qiming Teng]

+1 to this. Very happy to work with him.

- Qiming

On Fri, Nov 11, 2016 at 02:27:50PM +0800, Yanyan Hu wrote:
> Hi Senlin core team,
> 
> I'd like to nominate Ruijie Yuan(IRC name 'ruijie') for Senlin core
> reviewer.
> 
> Ruijie started to work on Senlin since the beginning of Newton cycle and he
> has made significant contribution to Senlin project in last three months
> including the batch policy support, versioned API support and etc.. He is
> also actively interacting with the team for bug fix, blueprint discussion
> and code review. I have talked with him and he expressed strong enthusiasm
> and will to contribute to Senlin project and I believe he will make a great
> addition to the core review team.
> 
> So please put your +1 or -1 here. Please note any -1 will be a veto for
> this nomination. I will collect the result in seven days.
> 
> Thanks you so much!
> 
> http://stackalytics.com/report/contribution/senlin-group/60
> 
> -- 
> Best regards,
> 
> Yanyan

> __
> 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] [Zun] Propose a change of Zun core team

[Qiming Teng]

+1

Regards,
- Qiming

On Wed, Oct 19, 2016 at 09:18:49PM +, Hongbin Lu wrote:
> Hi team,
> 
> I am going to propose an exchange of the core team membership as below:
> 
> + Shubham Kumar Sharma (shubham)
> - Chandan Kumar (chandankumar)
> 
> Shubham contributed a lot for the container image feature and active on 
> reviews and IRC. I think he is a good addition to the core team. Chandan 
> became inactive for a long period of time so he didn't meet the expectation 
> of a core reviewer anymore. However, thanks for his interest to join the core 
> team when the team was found. He is welcomed to re-join the core team if he 
> become active in the future.
> 
> According to the OpenStack Governance process [1], we require a minimum of 4 
> +1 votes from Zun core reviewers within a 1 week voting window (consider this 
> proposal as a +1 vote from me). A vote of -1 is a veto. If we cannot get 
> enough votes or there is a veto vote prior to the end of the voting window, 
> this proposal is rejected and Shubham is not able to join the core team and 
> needs to wait 30 days to reapply.
> 
> [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
> 
> Best regards,
> Hongbin

> __
> 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] Endpoint structure: a free-for-all

[Qiming Teng]

On Thu, Oct 20, 2016 at 02:01:07AM -0500, Monty Taylor wrote:
> On 10/19/2016 12:07 PM, Matt Riedemann wrote:
> > On 10/19/2016 10:32 AM, Brian Curtin wrote:
> >> I'm currently facing what looks more and more like an impossible
> >> problem in determining the root of each service on a given cloud. It
> >> is apparently a free-for-all in how endpoints can be structured, and I
> >> think we're out of ways to approach it that catch all of the ways that
> >> all people can think of.
> >>
> >> In openstacksdk, we can no longer use the service catalog for
> >> determining each service's endpoints. Among other things, this is due
> >> to a combination of some versions of some services not actually being
> >> listed, and with things heading the direction of version-less services
> >> anyway. Recently we changed to using the service catalog as a pointer
> >> to where services live and then try to find the root of that service
> >> by stripping the path down and making some extra requests on startup
> >> to find what's offered. Despite a few initial snags, this now works
> >> reasonably well in a majority of cases.
> >>
> >> We have seen endpoints structured in the following ways:
> >>  A. subdomains, e.g., https://service.cloud.com/v2
> >>  B. paths, e.g., https://cloud.com/service/v2 (sometimes there are
> >> more paths in between the root and /service/)
> >>  C. service-specific ports, e.g., https://cloud.com:1234/v2
> >>  D. both A and B plus ports
> >>
> >> Within all of these, we can find the root of the given service just
> >> fine. We split the path and build successively longer paths starting
> >> from the root. In the above examples, we need to hit the path just
> >> short of the /v2, so in B it actually takes two requests as we'd make
> >> one to cloud.com which fails, but then a second one to
> >> cloud.com/service gives us what we need.
> >>
> >> However, another case came up: the root of all endpoints is itself
> >> another service. That makes it look like this:
> >>
> >>  E. https://cloud.com:/service/v2
> >>  F. https://cloud.com:/otherservice
> >>
> >> In this case, https://cloud.com: is keystone, so trying to get E's
> >> base by going from the root and outward will give me a versions
> >> response I can parse properly, but it points to keystone. We then end
> >> up building requests for 'service' that go to keystone endpoints and
> >> end up failing. We're doing this using itertools.accumulate on the
> >> path fragments, so you might think 'just throw it through
> >> `reversed()`' and go the other way. If we do that, we'll also get a
> >> versions response that we can parse, but it's the v2 specific info,
> >> not all available versions.
> >>
> >> So now that we can't reliably go from the left, and we definitely
> >> can't go from the right, how about the middle?
> >>
> >> This sounds ridiculous, and if it sounds familiar it's because they
> >> devise a "middle out" algorithm on the show Silicon Valley, but in
> >> most cases it'd actually work. In E above, it'd be fine. However,
> >> depending on the number of path fragments and which direction we chose
> >> to move first, we'd sometimes hit either a version-specific response
> >> or another service's response, so it's not reliable.
> >>
> >> Ultimately, I would like to know how something like this can be solved.
> >>
> >> 1. Is there any reliable, functional, and accurate programmatic way to
> >> get the versions and endpoints that all services on a cloud offer?
> >>
> >> 2. Are there any guidelines, rules, expectations, or other
> >> documentation on how services can be installed and their endpoints
> >> structured that are helpful to people build apps that use them, not in
> >> those trying to install and operate them? I've looked around a few
> >> times and found nothing useful. A lot of what I've found has
> >> referenced suggestions for operators setting them up behind various
> >> load balancing tools.
> >>
> >> 3. If 1 and 2 won't actually help me solve this, do you have any other
> >> suggestions that will? We already go left, right, and middle of each
> >> URI, so I'm out of directions to go, and we can't go back to the
> >> service catalog.
> >>
> >> Thanks,
> >>
> >> Brian
> >>
> >> __
> >>
> >> 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
> >>
> > 
> > That's a tricky one. Just yesterday I was looking into how Tempest
> > creates the service clients it uses and lists versions, e.g. for compute:
> > 
> > https://github.com/openstack/tempest/blob/13.0.0/tempest/lib/services/compute/versions_client.py#L27
> > 
> > 
> > I was trying to figure out where that base_url value came from and in
> > the case of Tempest it's from an auth provider class, and I think the
> > services inside that 

Re: [openstack-dev] [tosca-parser] [heat-translator] cross-project design session with [Tacker] at summit

[Qiming Teng]

You meant Nov 28th, right?

Also, I'd like to join the discussion because Senlin can help offload
the clustering, auto-scaling and auto-healing work from Tacker so Tacker
can be more focused on the NFV support.

However, the schedule for design summit was ... very packed. There are
many sessions I'll have to miss. For this one, could you please help
bring up this topic? TOSCA-parser was a blocking factor for Tacker to
use Senlin directly. We will need some helps from your team.

Thanks.

Regards,
  Qiming

On Mon, Oct 17, 2016 at 11:58:42AM -0400, Sahdev P Zala wrote:
> Hi team, 
> 
> The TOSCA-Parser/Heat-Translator and Tacker will be having a cross-project 
> design session at the Barcelona summit. Sripriya has started etherpad doc 
> to collect discussion items. If you have any, please add it there. 
> 
> Friday, Nov 18th, 11:00am - 11:40am - Workroom Session
> Location: CCIB - Centre de Convencions Internacional de Barcelona - P1 - 
> Room 128
> 
> https://etherpad.openstack.org/p/tacker-ocata-summit
> 
> 
> Safe travels. See you there!
> 
> Regards, 
> Sahdev Zala
> 


__
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] [senlin] Proposed changes to senlin core team

[Qiming Teng]

We have got enough votes for this nomination. Thanks everyone, and
welcome on board lvdongbing and XueFeng Liu.

Regards,
  Qiming

On Thu, Oct 13, 2016 at 08:27:34PM +0800, Qiming Teng wrote:
> As the project keeps growing and maturing, we are happily seeing more
> eyes on it, more hands on it. Among the many contributors, the following
> two are outstanding:
> 
> lvdongbing 
> Involved in OpenStack for a few years now. His contribution is not
> limited to senlin, but also other projects such as heat, nova, solum
> etc. His experience and passion would be a great help to our team.
> 
> ref:
> http://stackalytics.com/?module=senlin-group&metric=commits&user_id=dbcocle&release=all
> 
> XueFeng Liu 
> Both a user and a developer of senlin. His recent contribution has shown
> that he has a good understanding of the project's mission and
> implementation. His commits and reviews are all of good quality.
> 
> ref:
> http://stackalytics.com/?module=senlin-group&metric=commits&release=all&user_id=jonnary-liu
> 
> With this email, I'm formally inviting these two developers to join
> senlin core team. Please cast your votes by replying this email, core
> team. Thank you.
> 
> Regards,
>   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
> 


__
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] [senlin] Proposed changes to senlin core team

[Qiming Teng]

As the project keeps growing and maturing, we are happily seeing more
eyes on it, more hands on it. Among the many contributors, the following
two are outstanding:

lvdongbing 
Involved in OpenStack for a few years now. His contribution is not
limited to senlin, but also other projects such as heat, nova, solum
etc. His experience and passion would be a great help to our team.

ref:
http://stackalytics.com/?module=senlin-group&metric=commits&user_id=dbcocle&release=all

XueFeng Liu 
Both a user and a developer of senlin. His recent contribution has shown
that he has a good understanding of the project's mission and
implementation. His commits and reviews are all of good quality.

ref:
http://stackalytics.com/?module=senlin-group&metric=commits&release=all&user_id=jonnary-liu

With this email, I'm formally inviting these two developers to join
senlin core team. Please cast your votes by replying this email, core
team. Thank you.

Regards,
  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

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

[Qiming Teng]

project-navigator? http://www.openstack.org/software/

It is often misinterpreted as: OpenStack has 6 core services which are
all mandatory (because they are *core* services) plus 13 optional
services that can be selectively installed.

I tried hard to find out how the lists are generated, but I failed.
There are at least the following projects which are neither *core* nor
*optional* services:

cloudkitty
dragonflow
freezer
karbor
kolla
kuryr
mistral
monasca
searchlight
senlin
solum
tacker
vitrage
watcher

Looks like this is something causing some confusions. Should/can we fix
that?

Regards,
  Qiming


On Wed, Oct 12, 2016 at 02:43:45PM -0700, Mike Perez wrote:
> On 14:50 Oct 12, Flavio Percoco wrote:
> > Greetings,
> > 
> > One of the common complains about the existing project organization in the 
> > big
> > tent is that it's difficult to wrap our heads around the many projects there
> > are, their current state (in/out the big tent), their tags, etc.
> > 
> > This information is available on the governance website[0]. Each official
> > project team has a page there containing the information related to the
> > deliverables managed by that team. Unfortunately, I don't think this page is
> > checked often enough and I believe it's not known by everyone.
> 
> Besides the governance site, there is also the project navigator [1] which is
> a more friendly landing page on projects and their tags. Although it does not
> today capture separate deliverables.
> 
> Assuming the README files aren't being manually updated, I don't have a 
> problem
> with this idea.
> 
> [1] - https://www.openstack.org/software/project-navigator/
> 
> -- 
> Mike Perez


__
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 from the Ops Perspective - a few short notes

[Qiming Teng]

On Tue, Oct 11, 2016 at 10:39:11PM -0500, Michał Jastrzębski wrote:
> Hello Tom,
> 
> I must say I think this is bad news - especially for projects like
> Kolla - ops centric.
> One of reasons we created PTG in the first place is that Summit became
> big and expensive, and project developers had harder and harder time
> attending it due to budget issues.

So a trip to PTG is really cheaper than summit? Is the PTG one
sponsored by someone?

> PTG would offer many of these devs
> opportunity to talk to their peers, other project developers and build
> OpenStack dev community.

> If project attends PTG, and most of them
> plans to (again, Kolla included), that is a travel for project team.

A big IF here ...

> If we hold 2 PTGs per year, that's big hit on travel budget (but still
> smaller than summit).
> 
> PTG becomes very important for project team, summit arguably will
> become less important as many of developers will be able to afford
> only PTGs.

Summit is less (or just NOT) important to developers, emm ... that is
true if 1) the team knows exactly what users/ops want so they don't even
bother interact with them, just focus on getting things done; 2) the
person who approves your trip request also believes so.

> If we say that "Don't expect Ops at PTG", that means
> OpenStack dev community will become even more disconnected from Ops
> community.

Wasn't that part of the plan? Or maybe the Ops will travel four times a
year, go to the summit twice for (watching) shows and go to the PTGs
twice to interact with the team that is busy discussing implementation
details ...

> Let's not forget that OpenStack is ultimately operators
> tool, they need to care for it and in my opinion having close
> relationship with them is extremely important for good of project. If
> we raise cost of keeping this relationship, that might really hurt
> OpenStack.

> Cheers,
> Michal
> 

I really hope I was totally wrong.

Regards,
  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

Re: [openstack-dev] [heat] [magnum] Subjects to discuss during the summit

[Qiming Teng]

On Mon, Oct 10, 2016 at 05:11:28PM +0200, Spyros Trigazis wrote:
> Hi heat and magnum.
> 
> Apart from the scalability issues that have been observed, I'd like to
> add few more subjects to discuss during the summit.
> 
> 1. One nested stack per node and linear scale of cluster creation
> time.
> 
> 1.1
> For large stacks, the creation of all nested stack scales linearly. We
> haven't run any tested using the convergence-engine.

Convergence would hopfully help in this scenario, thus definitely worth
a try.

 
> 1.3
> After the stack create API call to heat, magnum's conductor
> busy-waits heat with a thread/cluster. (In case of a magnum conductor
> restart, we lose that thread and we can't update the status in
> magnum). Investigate better ways to sync the status between magnum
> and heat.

Sounds like something to be done when magnum conductor bootstraps
itself.
 
> 2. Next generation magnum clusters
> 
> A need that comes up frequently in magnum is heterogeneous clusters.
> * We want to able to create cluster on different hardware, (e.g. spawn
>   vms on nodes with SSDs and nodes without SSDs or other special
>   hardware available only in some nodes of the cluster FPGA, GPU)
> * Spawn cluster across different AZs

This smells very much like a senlin use case.
> I'll describe briefly our plan here, for further information we have a
> detailed spec under review. [1]
> 
> To address this issue we introduce the node-group concept in magnum.
> Each node-group will correspond to a different heat stack. The master
> nodes can be organized in one or more stacks, so as the worker nodes.

My personal feeling is that modelling a node-group as a heat stack is
feasible though not flexible. It will end up heavy dependency on the
'stack-update' operation for whatever changes needed later. Senlin
provides you more APIs on managing such a group of things, without
masking out any existing features/capabilities from heat template/stack.

> We investigate how to implement this feature. We consider the
> following:
> At the moment, we have three template files, cluster, master and
> node, and all three template files create one stack. The new
> generation of clusters will have a cluster stack containing
> the resources in the cluster template, specifically, networks, lbaas
> floating-ips etc. Then, the output of this stack would be passed as
> input to create the master node stack(s) and the worker nodes
> stack(s).

Before investing resources into this effort, you may want to check if
senlin (can be improved to) meet magnum's requirements:

 - API [1]
 - User Doc [2] 
 - Developer Doc [3]
 - Quick Tutorial [4]

> 4. Finally, a thought under investigation is replacing the nodes one
>by one using a different image. e.g. Upgrade from fedora 24 to 25
>with new versions of packages all in a new qcow2 image. How could
>we update the stack for this?

Emm.. senlin is working on an operation that allows you to replace
existing nodes: 

  POST /v1/clusters//actions

  {
'replace_nodes': {
  'name_or_id_old_node': 'name_or_id_new_node',
  ...
}
  }


References:

[1] http://developer.openstack.org/api-ref/clustering/
[2] http://docs.openstack.org/developer/senlin/user/index.html
[3] http://docs.openstack.org/developer/senlin/developer/index.html
[4] http://docs.openstack.org/developer/senlin/tutorial/index.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 Candidacy

[Qiming Teng]

I believe this is the voice we really need in the TC.
THANK YOU.

- Qiming

On Thu, Sep 29, 2016 at 11:47:12PM +, Jeremy Stanley wrote:
> I guess I'll send a copy of mine to the ML too, since all the cool
> kids seem to be doing it...
> 
> Most of you probably know me as "that short dude in the Hawaiian
> shirt and long hair." I'll answer to "Jeremy," "fungi" or even just
> "hey you." I'm starting my third cycle as PTL of the Infrastructure
> team, and have been a core reviewer and root sysadmin for
> OpenStack's community-maintained project infrastructure for the past
> four years. I've also been doing vulnerability management in
> OpenStack for almost as long, chaired conference tracks, and given
> talks to other communities on a variety of OpenStack-related topics.
> I help with elections, attend and participate in TC meetings and
> review proposed changes to governance. I have consistent, strong
> views in favor of free software and open/transparent community
> process.
> 
> https://wiki.openstack.org/user:fungi
> 
> I see OpenStack not as software, but as a community of people who
> come together to build something for the common good. We've been
> fortunate enough to experience a bubble of corporate interest which
> has provided amazing initial momentum in the form of able software
> developers and generous funding, but that can't last forever. As
> time goes on, we will need to rely increasingly on effort from
> people who contribute to OpenStack because it interests them, rather
> than because some company is paying them to do so. The way I see it,
> we should be preparing now for the future of our project:
> independent, volunteer contributors drawn from the global free
> software community. However, we're not succeeding in attracting them
> the way some other projects do, which brings me to a major
> concern...
> 
> OpenStack has a public relations problem we need to solve, and soon.
> I know I'm not the only one who struggles to convince contributors
> in other communities that we're really like them, writing free
> software under transparent processes open to any who wish to help.
> This skepticism comes from many sources, some overt (like our
> massive trade conferences and marketing budget) while others
> seemingly inconsequential (such as our constant influx of new
> community members who are unfamiliar with free software concepts and
> lack traditional netiquette). Overcoming this not-really-free
> perception is something we absolutely must do to be able to attract
> the unaffiliated volunteers who will continue to maintain OpenStack
> through the eventual loss of our current benefactors and well into
> stabilization.
> 
> Prior to OpenStack, I worked for longer than I care to remember as
> an "operator" at Internet service, hosting and telecommunications
> providers doing Unix systems administration, network engineering,
> virtualization and information security. When I first started my
> career, you couldn't be a capable systems administrator without a
> firm grasp of programming fundamentals and couldn't be a good
> programmer without understanding the basics of systems
> administration. I'm relieved that, after many years of companies
> trying to tell us otherwise, our industry as a whole is finally
> coming back around to the same realization. Similarly, I don't
> believe we as a community benefit by socializing a separation of
> "operators" from "developers" and feel the role distinction many
> attempt to strike between the two is at best vague, while at its
> worst completely alienating a potential source of current and future
> contributions.
> 
> What causes software to succeed in the long run is not hype,
> limitless funding or even technical superiority, it's the size and
> connectedness of its community of volunteers and users who invest
> themselves and their personal time. The work we're doing now is
> great, don't get me wrong, but for it to survive into the next
> decade and beyond we need to focus more on building a close-knit
> community of interested contributors even if it's not in the best
> interests of industry pundits or vendor product roadmaps.
> 
> OpenStack is people. If we lose sight of that, it's over.
> -- 
> 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

Re: [openstack-dev] [heat] resigning from heat-cores

[Qiming Teng]

Thank you very much for the helps. Good luck on your new journey!

- Qiming

On Mon, Sep 12, 2016 at 03:35:05PM +0300, Pavlo Shchelokovskyy wrote:
> Hi Heaters,
> 
> with great regret I announce my resignation from the heat-core team.
> 
> About a year ago I was reassigned to another project, and despite my best
> efforts I came to conclusion that unfortunately I can not keep up with
> duties expected from Heat core team member in appropriate capacity.
> 
> I do still work on OpenStack, so I'm not leaving the community altogether,
> and will be available in e.g. IRC. I also have some ideas left to implement
> in Heat, but, given the great community we've built around the project, I
> could surely make it as an ordinary contributor.
> 
> It was an honor to be a member of this team, I’ve learned a lot during this
> time. Hope to see some of you in Barcelona :)
> 
> Best regards,
> 
> 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


__
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][tc] establishing community-wide goals

[Qiming Teng]

Thanks for working on this.
Modified the subject to be 'community-wide goals'.

-Qiming
On Fri, Jul 29, 2016 at 04:55:22PM -0400, Doug Hellmann wrote:
> One of the outcomes of the discussion at the leadership training
> session earlier this year was the idea that the TC should set some
> community-wide goals for accomplishing specific technical tasks to
> get the projects synced up and moving in the same direction.
> 
> After several drafts via etherpad and input from other TC and SWG
> members, I've prepared the change for the governance repo [1] and
> am ready to open this discussion up to the broader community. Please
> read through the patch carefully, especially the "goals/index.rst"
> document which tries to lay out the expectations for what makes a
> good goal for this purpose and for how teams are meant to approach
> working on these goals.
> 
> I've also prepared two patches proposing specific goals for Ocata
> [2][3].  I've tried to keep these suggested goals for the first
> iteration limited to "finish what we've started" type items, so
> they are small and straightforward enough to be able to be completed.
> That will let us experiment with the process of managing goals this
> time around, and set us up for discussions that may need to happen
> at the Ocata summit about implementation.
> 
> For future cycles, we can iterate on making the goals "harder", and
> collecting suggestions for goals from the community during the forum
> discussions that will happen at summits starting in Boston.
> 
> Doug
> 
> [1] https://review.openstack.org/349068 describe a process for managing 
> community-wide goals
> [2] https://review.openstack.org/349069 add ocata goal "support python 3.5"
> [3] https://review.openstack.org/349070 add ocata goal "switch to oslo 
> libraries"
> 
> __
> 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] [Sahara] Error launching a defined domain with XML

[Qiming Teng]

This should add a [sahara] tag at subject line.

- Qiming

On Tue, Jul 26, 2016 at 05:46:25PM +0800, 云淡风轻 wrote:
> hi ,
> 
> when create cluster with sahara 4.0.0 in M version ,using command line:
> 
> 
> $  time openstack dataprocessing cluster create --json 
> my_cluster_create_default.json
> ++--+
> | Field  | Value|
> ++--+
> | Anti affinity  |  |
> | Cluster template id| b7e8f1b5-1aff-4baf-977b-3ef74d4326cf |
> | Description| None |
> | Id | 47ac6404-8fc0-4d3c-b8eb-0f3a2b9e1b2c |
> | Image  | b3e899c4-a282-4337-a084-50ca0454535e |
> | Is protected   | False|
> | Is public  | False|
> | Is transient   | False|
> | Name   | my-cluster-default-1 |
> | Neutron management network | 3aaa392b-af4d-4f70-9e2e-1b71a965ff7d |
> | Node groups| master:1, worker:1   |
> | Plugin name| vanilla  |
> | Status | Validating   |
> | Use autoconfig | True |
> | User keypair id| my_stack |
> | Version| 2.7.1|
> ++--+
> $  nova list
> +--+---+++-+--+
> | ID   | Name  | 
> Status | Task State | Power State | Networks |
> +--+---+++-+--+
> | 4e3fdb6c-6805-447c-b01d-c4cb0fc1ca87 | my-cluster-default-1-master-0 | 
> BUILD  | scheduling | NOSTATE |  |
> | 95dd207b-6047-416c-a95f-6d08aa0c6409 | my-cluster-default-1-worker-0 | 
> BUILD  | scheduling | NOSTATE |  |
> +--+---+++-+--+
> 
> 
> 
> 
> an error occur :
> 
> 
> log in nova-compute.log
> 2016-07-25 18:09:47.440 37208 INFO nova.compute.resource_tracker 
> [req-8ce86863-8324-4dc3-93bf-a997d3512ab1 - - - - -] Auditing locally 
> available compute resources for node localhost.localdomain
> 2016-07-25 18:09:47.767 37208 WARNING nova.virt.libvirt.driver 
> [req-8ce86863-8324-4dc3-93bf-a997d3512ab1 - - - - -] couldn't obtain the vcpu 
> count from domain id: af17e813-fe6d-4769-b7d3-17369afd7313, exception: 
> Requested operation is not valid: cpu affinity is not supported
> 2016-07-25 18:09:47.768 37208 WARNING nova.virt.libvirt.driver 
> [req-8ce86863-8324-4dc3-93bf-a997d3512ab1 - - - - -] couldn't obtain the vcpu 
> count from domain id: eaa076c0-2930-4257-8fd7-e36033c4e86c, exception: 
> Requested operation is not valid: cpu affinity is not supported
> 2016-07-25 18:10:41.136 37208 ERROR nova.virt.libvirt.guest 
> [req-14a51b87-4b95-4b80-a042-193df77278bb 7fff70fbbf83441a9b3c4d91a5613825 
> 6cb156a82d0f486a9f50132be9438eb6 - - -] Error launching a defined domain with 
> XML: 
>   instance-00e3
> 
> 
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager 
> [req-14a51b87-4b95-4b80-a042-193df77278bb 7fff70fbbf83441a9b3c4d91a5613825 
> 6cb156a82d0f486a9f50132be9438eb6 - - -] [instance: 
> af17e813-fe6d-4769-b7d3-17369afd7313] Instance failed to spawn
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager [instance: 
> af17e813-fe6d-4769-b7d3-17369afd7313] Traceback (most recent call last):
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager [instance: 
> af17e813-fe6d-4769-b7d3-17369afd7313]   File 
> "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2218, in 
> _build_resources
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager [instance: 
> af17e813-fe6d-4769-b7d3-17369afd7313] yield resources
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager [instance: 
> af17e813-fe6d-4769-b7d3-17369afd7313]   File 
> "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2064, in 
> _build_and_run_instance
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager [instance: 
> af17e813-fe6d-4769-b7d3-17369afd7313] block_device_info=block_device_info)
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager [instance: 
> af17e813-fe6d-4769-b7d3-17369afd7313]   File 
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 2768, in 
> spawn
> 2016-07-25 18:10:41.259 37208 ERROR nova.compute.manager [instance: 
> 

Re: [openstack-dev] [Glare][Heat][TripleO] Heat artifact type

[Qiming Teng]

On Tue, Jul 19, 2016 at 06:44:06PM +0300, Oleksii Chuprykov wrote:
> Hello!
> 
> Today it was announced that Glare is ready for public review
> http://lists.openstack.org/pipermail/openstack-dev/2016-July/099553.html So
> we are ready to start working on integration Heat with Glare and
> implementing a POC. After discussions with Glare team we see two design
> options:
> 
> 1) Create one artifact type that will contain template, nested templates
> and environments.
> Pros: It is easy to maintain integrity. Since artifact is immutable, we can
> guarantee the consistency and prevent from accidentally removing of
> dependent environment.
> Cons: If we need to add new environments to use them with template, we need
> to create new artifact.
> 
> 2) Create 2 artifact types: environment and template.
> Pros: It is easy to add new environments. You just need to create new
> dependency from template artifact to environment one.
> Cons: Some environment can be (mistakenly) removed, and template that have
> dependencies on it will be in inconsistent state.

Option 2 looks more flexible to me. I'm not sure we are encouraging
users to introduce or rely on a hard dependency from a template to an
environment file. With that, it is still good to know whether glare
supports the concept of 'reference' where a referenced artifact cannot
be deleted.

 - Qiming
 
> So we want to hear your opinions and suggestions on the matter. Thanks in
> advance!
> 
> Best regards,
> Oleksii Chuprykov


__
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] [higgins] Continued discussion from the last team meeting

[Qiming Teng]

On Tue, May 24, 2016 at 08:55:28PM +, Hongbin Lu wrote:
> Hi all,
> 
> At the last team meeting, we tried to define the scope of the Higgins 
> project. In general, we agreed to focus on the following features as an 
> initial start:
> 
> * Build a container abstraction and use docker as the first 
> implementation.
> 
> * Focus on basic container operations (i.e. CRUD), and leave advanced 
> operations (i.e. keep container alive, rolling upgrade, etc.) to users or 
> other projects/services.
> 
> * Start with non-nested container use cases (e.g. containers on 
> physical hosts), and revisit nested container use cases (e.g. containers on 
> VMs) later.
> The items below needs further discussion so I started this ML to discuss it.
> 
> 1.   Container composition: implement a docker compose like feature

No doubt this would be very useful a feature for users. However, I still
suggest we keep the initial scope to a bare minimum so folks can focus
on the first two jobs (container abstraction + CRUD) in this cycle and
get things landed soon. We already have a lot details to figure out for
the first two items.

The next step (maybe early next cycle?) would be about a higher level of
APIs that allow users to create some structured, declarative artifacts
as inputs.

> 2.   Container host management: abstract container host

I'm not quite aware of the requirements for end users to see or even to
manage the container "hosts" (bm or vm). Just like that end users are
not supposed to be aware of the compute nodes when they use Nova. For
operators, the story might be quite different. They will need such tools
or APIs for managing the "hosts" used. Such management jobs can be
automated to some extent, but I'm somehow skeptical to full automation.
At the end of the day, we need to provide some knobs for operators to
do things they want because the automation tool is never ever smarter
than the people using it.

Just my 2 cents.

 - Qiming

> For #1, it seems we broadly agreed that this is a useful feature. The 
> argument is where this feature belongs to. Some people think this feature 
> belongs to other projects, such as Heat, and others think it belongs to 
> Higgins so we should implement it. For #2, we were mainly debating two 
> things: where the container hosts come from (provisioned by Nova or provided 
> by operators); should we expose host management APIs to end-users? Thoughts?
> 
> Best regards,
> Hongbin



__
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] [API] os-api-ref HTTP Response code formating

[Qiming Teng]

> Having some generic language for each error message if. Typing "User
> must authenticate" every time there is a 401 is tiresome, and will just
> mean typos. Ideally even generating links to an overview of what each
> code means in general would be nice. I was assuming we were going to
> write up a dedicated page about error codes.
> 
> There are times when what a 409 means pretty specific things, and I
> wonder if we want to reference it there instead of elsewhere.
> 
> I kind of wonder if:
> 
> .. rest_status_code:: 400, 401, 403, 405, 409, 500
> 
>   - 409: The fizbuz is locked and can't be updated until unlock is
> performed.
> 
> And generic messages for everything without the extra entry would work.
> 

While I do like this generalization because it will help kill typos, I'm
a little worried that we are introducing more and more REST stanza into
the docs. It would be desirable that the docs can serve both human
readers and programs that can parse it for API checking/validation.
Team, please consider this aspect when improving the doc formatting.

Regards,
  Qiming


>   -Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> __
> 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] [magnum] Discuss the idea of manually managing the bay nodes

[Qiming Teng]

On Sun, May 15, 2016 at 10:49:39PM +, Hongbin Lu wrote:
> Hi all,
> 
> This is a continued discussion from the design summit. For recap, Magnum 
> manages bay nodes by using ResourceGroup from Heat. This approach works but 
> it is infeasible to manage the heterogeneity across bay nodes, which is a 
> frequently demanded feature. As an example, there is a request to provision 
> bay nodes across availability zones [1]. There is another request to 
> provision bay nodes with different set of flavors [2]. For the request 
> features above, ResourceGroup won't work very well.
> 
> The proposal is to remove the usage of ResourceGroup and manually create Heat 
> stack for each bay nodes. For example, for creating a cluster with 2 masters 
> and 3 minions, Magnum is going to manage 6 Heat stacks (instead of 1 big Heat 
> stack as right now):
> * A kube cluster stack that manages the global resources
> * Two kube master stacks that manage the two master nodes
> * Three kube minion stacks that manage the three minion nodes
> 
> The proposal might require an additional API endpoint to manage nodes or a 
> group of nodes. For example:
> $ magnum nodegroup-create --bay XXX --flavor m1.small --count 2 
> --availability-zone us-east-1 
> $ magnum nodegroup-create --bay XXX --flavor m1.medium --count 3 
> --availability-zone us-east-2 ...
> 
> Thoughts?
> 
> [1] https://blueprints.launchpad.net/magnum/+spec/magnum-availability-zones
> [2] https://blueprints.launchpad.net/magnum/+spec/support-multiple-flavor
> 
> Best regards,
> Hongbin

Seriously, I'm suggesting Magnum to use Senlin for this task. Senlin has
an API that provides rich operations you will need to manage a cluster
of things, where the "thing" here can be a Heat stack or a Nova server.

A "thing" is modeled as a Profile in Senlin, so it is pretty easy and
straightforward for Magnum to feed in the HOT templates (possibly with
parameters and environments?) to Senlin and offload the group management
task from Magnum.

Speaking of cross-AZ placement, Senlin has a policy plugin for this
purpose already. Regarding bay nodes bearing different set of flavors,
Senlin also permits that.

I believe by offloading these operations to Senlin, Magnum can remain
focusing on getting COE management and get it done well. I also believe
that Senlin team will be very responsive to your requirements if there
are needs to tune the Senlin API/policy/mechanism.

Regards,
  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

Re: [openstack-dev] [tacker]ad-hoc meeting of May 16

[Qiming Teng]

Hi,

I was thinking that autoscaling is the topic very relevant to senlin.

Regards,
 Qiming

On Fri, May 13, 2016 at 12:31:42PM +, Bruce Thompson (brucet) wrote:
> Qiming,
> 
> I don¹t think we will be discussing Senlin as part of the agenda in this
> meeting. Is there a Senlin topic that you believe should be covered?
> 
>   Bruce T
> 
> On 5/12/16, 8:37 PM, "Qiming Teng"  wrote:
> 
> >UTC 16:00 is too late for most of senlin developers to join.
> >Still interested in the outcomes from this discussion.
> >
> >Regards,
> >  Qiming
> >
> >On Thu, May 12, 2016 at 11:59:37PM +, Bruce Thompson (brucet) wrote:
> >> Hi,
> >> 
> >> IRC meeting: https://webchat.freenode.net/?channels=tacker on Monday 16
> >>starting from UTC 16:00.
> >> 
> >> Agenda:
> >> # Tacker Ceilometer Monitoring Driver and Autoscaling Sync
> >> 
> >> 
> >> 
> >> Best Regards
> >> Bruce Thompson ( brucet )
> >
> >> 
> >>_
> >>_
> >> 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
> 
> 
> __
> 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] [tacker]ad-hoc meeting of May 16

[Qiming Teng]

UTC 16:00 is too late for most of senlin developers to join.
Still interested in the outcomes from this discussion.

Regards,
  Qiming

On Thu, May 12, 2016 at 11:59:37PM +, Bruce Thompson (brucet) wrote:
> Hi,
> 
> IRC meeting: https://webchat.freenode.net/?channels=tacker on Monday 16 
> starting from UTC 16:00.
> 
> Agenda:
> # Tacker Ceilometer Monitoring Driver and Autoscaling Sync
> 
> 
> 
> Best Regards
> Bruce Thompson ( brucet )

> __
> 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] [kolla] How to contribute to kolla

[Qiming Teng]

Try setup your HTTP password on gerrit by clicking 'settings'. Say you
have a HTTP password 'abcdef', then your 'gerrit' remote should look
like:

[remote "gerrit"]
  url = https://huzhj:abc...@review.openstack.org/openstack/kolla.git
  fetch = +refs/heads/*:refs/remotes/gerrit/*

This is how we from behind the damn *** firewell manage to continue
working with the community since port 29418 was blocked.

Regards,
  Qiming

On Thu, May 12, 2016 at 03:40:57PM +0800, hu.zhiji...@zte.com.cn wrote:
> Hi all kolla fellows,
> 
> Previously, I managed submit a code review to kolla repo but now I 
> couldn't. Do I need additional rights or configurations? Below is my git 
> remote -a output:
> 
> gerrit  https://hu...@review.openstack.org/openstack/kolla.git (fetch)
> gerrit  https://hu...@review.openstack.org/openstack/kolla.git (push)
> origin  https://hu...@review.openstack.org/openstack/kolla (fetch)
> origin  https://hu...@review.openstack.org/openstack/kolla (push)
> 
> Please help to take look at this. 
> 
> 
> Many thanks!
> 
> Zhijiang 
> 
> ZTE Information Security Notice: The information contained in this mail (and 
> any attachment transmitted herewith) is privileged and confidential and is 
> intended for the exclusive use of the addressee(s).  If you are not an 
> intended recipient, any disclosure, reproduction, distribution or other 
> dissemination or use of the information contained is strictly prohibited.  If 
> you have received this mail in error, please delete it and notify us 
> immediately.

> __
> 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] [oslo.messaging] [smaug] Gate Py34 is failure

[Qiming Teng]

I believe the gate is back. You may want to do 'recheck' now.

Regards,
 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

Re: [openstack-dev] [oslo.messaging] [smaug] Gate Py34 is failure

[Qiming Teng]

I believe the infra team is busy working on it. Seems it was caused by
pip 8.1.2. Please be patient and avoid doing 'recheck' until problem is
fixed.

Regards,
  Qiming

On Wed, May 11, 2016 at 04:42:49PM +0800, xiangxinyong wrote:
> hello folks,
> 
> 
> I find [gate-smaug-python34] is FAILURE.
> 
> 
> The gate messages are as follows:
> 
> Collecting oslo.messaging>=4.5.0 (from smaug==0.0.1.dev159) Could not find a 
> version that satisfies the requirement oslo.messaging>=4.5.0 (from 
> smaug==0.0.1.dev159) (from versions: ) No matching distribution found for 
> oslo.messaging>=4.5.0 (from smaug==0.0.1.dev159)
> Could some one help me?Thanks very much.
> Best Regards,xiangxinyong

> __
> 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] [api] [senlin] [keystone] [ceilometer] [telemetry] Questions about api-ref launchpad bugs

[Qiming Teng]

On Tue, May 10, 2016 at 07:53:19AM -0500, Anne Gentle wrote:
> Great questions, so I'm copying the -docs and -dev lists to make sure
> people know the answers.
> 
> On Tue, May 10, 2016 at 5:14 AM, Atsushi SAKAI 
> wrote:
> 
> > Hello Anne
> >
> >   I have several question when I am reading through etherpad's (in
> > progress).
> >   It would be appreciated to answer these questions.
> >
> > 1)Should api-ref launchpad **bugs** be moved to each modules
> >   (like keystone, nova etc)?
> >   Also, this should be applied to moved one's only or all components?
> >(compute, baremetal Ref.2)
> >
> >   Ref.
> > https://etherpad.openstack.org/p/austin-docs-newtonplan
> > API site bug list cleanup: move specific service API ref bugs to
> > project's Launchpad
> >
> >   Ref.2
> > http://developer.openstack.org/api-ref/compute/
> > http://developer.openstack.org/api-ref/baremetal/
> 
> 
> Yes! I definitely got agreement from nova team that they want them. Does
> anyone have a Launchpad script that could help with the bulk filter/export?
> Also, are any teams concerned about taking on their API reference bugs?
> Let's chat.
> 
> 
> >
> >
> > 2)Status of API-Ref
> >   a)Why keystone and senlin are no person at this moment?
> >
> >
> >
> Keystone -- after the Summit, keystone had someone sign up [1], but sounds
> like we need someone else. Brant, can you help us find someone?
> 
> Senlin -- Qiming Teng had asked a lot of questions earlier in the process
> and tested the instructions. Qiming had good concerns about personal
> bandwidth limits following along with all the changes. Now that it's
> settled, I'll follow up (and hoping the senlin team is reading the list).

Well, I should have spoken up that we are already moving in that
direction. So far we have migrated quite some APIs into the new format.
Will let the team know when we have finished the migration for senlin.

When working on this migration, I do have some suggestions to improve
the sphinx extensions. For example, whether a parameter is optional
should be specified from where it is referenced (i.e. the RST files)
rather than where it is defined (i.e. the parameters.yaml file). Other
than that, the migration is smooth.

We were not doing a batch commit for the migration. We see this another
chance to cleanse any mistakes in API doc and/or API code. So we are
manually adding API docs one resource after another.

Regards,
  Qiming 
 
> >   b)What is your plan for sahara and ceilometer?
> >  (It seems already exist the document.)
> >
> 
> Yes, these are two I had seen already have RST, but they do not use the
> helpful Sphinx extensions.
> 
> Sahara -- Mike McCune, we should chat about the plans. Are you okay with
> moving towards the common framework and editing the current RST files to
> use the rest_method and rest_parameters Sphinx directives?
> 
> Ceilometer -- sorry, Julien, I hadn't reached out individually to you.
> Could you let me know your plans for the RST API reference docs?
> 
> 
> >   c)When is the table's status changed to "Done"?
> >  nova (compute) and ironic (baremetal) seems first patch merged
> >  and see the document already.
> >
> 
> I'll change those two to Done.
> 
> Thanks for asking -
> Anne
> 
> 
> >
> >
> >   Ref.
> > [1]
> > https://wiki.openstack.org/wiki/Documentation/Migrate#API_Reference_Plan
> >
> >
> > Thanks
> >
> > Atsushi SAKAI
> >
> 
> 
> 
> -- 
> Anne Gentle
> www.justwriteclick.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

[openstack-dev] [Senlin] Two weekly meetings skipped, Tue Apr 19/26, 13:00 UTC

[Qiming Teng]

Due most core team members are busy prepraring for the summit and design
summit next week. We are skipping the weekly meeting this week and next
week. Meeting will be resumed on May 3rd, UTC 13:00 UTC.

Sorry for the late notice.

Regards,
  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

Re: [openstack-dev] [all] Openstack rpm build

[Qiming Teng]

On Mon, Apr 18, 2016 at 06:05:41AM +0200, Andreas Jaeger wrote:
> On 04/18/2016 05:30 AM, Kenny Ji-work wrote:
> > Hi all,
> > 
> > In our developing environment, we want to create openstack's rpms by
> > ourselves. By typing 'python setup.py bdist_rpm', there would be some
> > files not packaged in. Now is there some tools or methods to package the
> > openstack's module to rpms? Thank you for answering!
> 
> 
> There's the RPM packaging team that creates spec files for all projects,
> check out their repo,
> 

Where is the repo? Thanks.

Regards,
  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

Re: [openstack-dev] [Nova] RFC Host Maintenance

[Qiming Teng]

On Fri, Apr 08, 2016 at 09:52:31AM +, Balázs Gibizer wrote:
> > -Original Message-
> > From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com]
> > Sent: April 07, 2016 15:42
> > 
> > The only gap based on my limited understanding is that nova is not emitting
> > events compute host state changes. This knowledge is still kept inside nova
> > as some service states. If that info is posted to oslo messaging, a lot of 
> > usage
> > scenarios can be enabled and we can avoid too much churns to nova itself.
> 
> Nova does not really know the state of the compute host, it knows only the 
> state of the nova-compute service running on the compute host. In Mitaka we 
> added notification about the service status[2]. 
> Also there is a proposal about notification about hypervisor info change [1].
> 
> Cheers,
> Gibi
> 
> [1] https://review.openstack.org/#/c/299807/
> [2] 
> http://docs.openstack.org/developer/nova/notifications.html#existing-versioned-notifications
>  
> 

Thanks for the sharing, Balázs. The mitaka service status notification
looks pretty useful, I'll try it.

Regards,
  Qiming

> > 
> > Regards,
> >   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
> 
> __
> 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] [Nova] RFC Host Maintenance

[Qiming Teng]

The only gap based on my limited understanding is that nova is not
emitting events compute host state changes. This knowledge is still kept
inside nova as some service states. If that info is posted to oslo
messaging, a lot of usage scenarios can be enabled and we can avoid too
much churns to nova itself.

Regards,
  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

Re: [openstack-dev] [designate][osc] new sub commands - how should they be named?

[Qiming Teng]

On Wed, Apr 06, 2016 at 01:59:29PM +, Hayes, Graham wrote:
> Designate is adding support for viewing the status of the various
> services that are running.
> 
> We have added support to our openstack client plugin, but were looking
> for guidance / advices on what the actual commands should be.
> 
> We have implemented it in [1] as "dns service list" and
> "dns service show" - but this is name-spacing the command.
do you mean?

openstack dns service list
openstack dns service show

> Is there an alternative? "service" is already taken by keystone, and if
> we take "service-status" (or other generic term) it will most likely
> conflict when nova / cinder / heat / others add support of their service
> listings to OSC.
> 
> What is the protocol here? First to grab it wins?
> 
> Thanks
> 
> - Graham
> 
> 1 - https://review.openstack.org/284103
> 
> __
> 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] [nova] [all] FYI: Removing default flavors from nova

[Qiming Teng]

Thanks for the explanation, Sean. I wasn't subscribing to the operators
mailinglist so wasn't aware of the notice. With that, I'm still
surprised that there was no response to that email.

Anyway, if people believe the benefits overweighs the impacts caused,
just do it.

The only thing I can think of is about tagging a email with some
eye-catching tags, e.g. [!!!] [Disruptive!] [Important!] ...
It is so easy to have such big change go unnoticed.

Regards,
  Qiming

On Wed, Apr 06, 2016 at 06:47:12AM -0400, Sean Dague wrote:
> On 04/06/2016 04:19 AM, Sylvain Bauza wrote:
> > 
> > 
> > Le 06/04/2016 06:44, Qiming Teng a écrit :
> >> Not an expert of Nova but I am really shocked by such a change. Because
> >> I'm not a Nova expert, I don't have a say on the *huge* efforts in
> >> maintaining some builtin/default flavors. As a user I don't care where
> >> the data have been stored, but I do care that they are gone. They are
> >> gone because they **WILL** be supported by devstack. They are gone with
> >> the workflow +1'ed **BEFORE** the devstack patch gets merged (many
> >> thanks to the depends-on tag). They are gone in hope that all deployment
> >> tools will know this when they fail, or fortunately they read this email,
> >> or they were reviewing nova patches.
> >>
> >> It would be a little nicer to initiate a discussion on the mailinglist
> >> before such a change is introduced.
> > 
> > 
> > It was communicated accordingly to operators with no strong arguments :
> > http://lists.openstack.org/pipermail/openstack-operators/2016-March/010045.html
> 
> Not only with no strong arguments, but with a general - "yes please,
> that simplifies our life".
> 
> > You can also see that https://review.openstack.org/#/c/300127/ is having
> > three items :
> >  - a DocImpact tag creating a Launchpad bug for documentation about that
> >  - a reno file meaning that our release notes will provide also some
> > comments about that
> >  - a Depends-On tag (like you said) on a devstack change meaning that
> > people using devstack won't see a modified behavior.
> > 
> > Not sure what you need more.
> 
> The default flavors were originally hardcoded in Nova (in the initial
> commit) -
> https://github.com/openstack/nova/commit/bf6e6e718cdc7488e2da87b21e258ccc065fe499#diff-5ca8c06795ef481818ea1710fce91800R64
>  and moved into the db 5 years ago to be a copy of the EC2 flavors at
> the time -
> https://github.com/openstack/nova/commit/563a77fd4aa80da9bddac5cf7f8f27ed2dedb39d.
> Those flavors were meant to be examples, not the final story.
> 
> All the public clouds delete these and do their own thing, as do I
> expect many of the products. Any assumption that software or users have
> that these will exist is a bad assumption.
> 
> It is a big change, which is why it's being communicated on Mailing
> Lists in addition to in the release notes so that people have time to
> make any of their tooling not assume these flavors by name will be
> there, or to inject them yourself if you are sure you need them (as was
> done in the devstack case).
> 
>   -Sean
> 
> -- 
> Sean Dague
> http://dague.net


__
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] [nova] FYI: Removing default flavors from nova

[Qiming Teng]

Not an expert of Nova but I am really shocked by such a change. Because
I'm not a Nova expert, I don't have a say on the *huge* efforts in
maintaining some builtin/default flavors. As a user I don't care where
the data have been stored, but I do care that they are gone. They are
gone because they **WILL** be supported by devstack. They are gone with
the workflow +1'ed **BEFORE** the devstack patch gets merged (many
thanks to the depends-on tag). They are gone in hope that all deployment
tools will know this when they fail, or fortunately they read this email,
or they were reviewing nova patches.

It would be a little nicer to initiate a discussion on the mailinglist
before such a change is introduced. 

Regards,
  Qiming

On Tue, Apr 05, 2016 at 08:09:50AM -0700, Dan Smith wrote:
> Just as a heads up, we are removing the default flavors from nova in
> this patch:
> 
>   https://review.openstack.org/#/c/300127/
> 
> Since long ago, Nova's default flavors were baked in at the database
> migration level. Now that we have moved them to another database
> entirely, this means we have to migrate them from the old/original place
> to the new one, even for new deployments. It also means that our tests
> have flavor assumptions that run (way too) deep.
> 
> Devstack will get support for auto-creating the flavors you are used to,
> as well as some less-useless ones:
> 
>   https://review.openstack.org/#/c/301257/
> 
> Normal developers shouldn't really notice, but the deployment tool
> projects may want/need to do something here along the same lines.
> 
> --Dan
> 
 


__
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] [Nova] FPGA as a resource

[Qiming Teng]

Emm... finally this is brought up. We from IBM have already done some
work on FPGA/GPU resource management [1]. Let me bring the SMEs into
this discussion and see if we together can work out a concrete roadmap
to land this upstream.

Fei and Yonghua, this is indeed very interesting a topic for us.


[1] SuperVessel Cloud: https://ptopenlab.com/

Regards,
  Qiming

On Tue, Apr 05, 2016 at 02:27:30PM +0200, Roman Dobosz wrote:
> Hey all,
> 
> On yesterday's scheduler meeting I was raised the idea of bringing up 
> the FPGA to the OpenStack as the resource, which than might be exposed 
> to the VMs.
> 
> The use cases for motivations, why one want do this, are pretty broad -
> having such chip ready on the computes might be beneficial either for
> consumers of the technology and data center administrators. The
> utilization of the hardware is very broad - the only limitations are
> human imagination and hardware capability - since it might be used for
> accelerating execution of algorithms from compression and cryptography,
> through pattern recognition, transcoding to voice/video analysis and
> processing and all the others in between. Using FPGA to perform data
> processing may significantly reduce CPU utilization, the time and power
> consumption, which is a benefit on its own.
> 
> On OpenStack side, unlike utilizing the CPU or memory, for actually 
> using specific algorithm with FPGAs, it has to be programmed first. So 
> in simplified scenario, it might go like this:
> 
> * User selects VM with image which supports acceleration,
> * Scheduler selects the appropriate compute host with FPGA available,
> * Compute gets request, program IP into FPGA and then boot up the 
>   VM with accelerator attached.
> * If VM is removed, it may optionally erase the FPGA.
> 
> As you can see, it seems not complicated at this point, however it 
> become more complex due to following things we also have to take into 
> consideration:
> 
> * recent FPGA are divided into regions (or slots) and every of them 
>   can be programmed separately
> * slots may or may not fit the same bitstream (the program which FPGA
>   is fed, the IP)
> * There is several products around (Altera, Xilinx, others), which make 
>   bitstream incompatible. Even between the products of the same company
> * libraries which abstract the hardware layer like AAL[1] and their 
>   versions
> * for some products, there is a need for tracking memory usage, which 
>   is located on PCI boards
> * some of the FPGAs can be exposed using SR-IOV, while some other not, 
>   which implies multiple usage abilities
> 
> In other words, it may be necessary to incorporate another actions:
> 
> * properly discover FPGA and its capabilities
> * schedule right bitstream with corresponding matching unoccupied FPGA
>   device/slot
> * actual program FPGA
> * provide libraries into VM, which are necessary for interacting between
>   user program and the exposed FPGA (or AAL) (this may be optional, 
>   since user can upload complete image with everything in place)
> * bitstream images have to be keep in some kind of service (Glance?) 
>   with some kind of way for identifying which image match what FPGA
> 
> All of that makes modelling resource extremely complicated, contrary to 
> CPU resource for example. I'd like to discuss how the goal of having 
> reprogrammable accelerators in OpenStack can be achieved. Ideally I'd 
> like to fit it into Jay and Chris work on resource-*.
> 
> Looking forward for any comments :)
> 
> [1] 
> http://www.intel.com/content/dam/doc/white-paper/quickassist-technology-aal-white-paper.pdf
> 
> -- 
> Cheers,
> Roman Dobosz
> 
> __
> 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] 答复: [Heat] Re-evaluate conditions specification

[Qiming Teng]

 
> parameters:
>   env:
>type: string
>default: prod
> 
>   is_prod:
> type: boolean
> default: {equals: {get_param, env}}
> 
> From an interface standpoint this seems much cleaner and more intuitive than
> the other solutions discussed IMHO, but I suspect it's potentially harder to
> implement.
> 
> Your original example gets much cleaner too if we allow all intrinsic function
> (except get_attr) in the scope of parameters:
> 
> parameters:
>   host:
> type: string
>   port:
> type: string
>   endpoint:
> type: string
> default:
>   str_replace:
> template:
>http://HOSTORT/
> params:
>HOST: {get_param: host}
>PORT: {get_param: port}
> 
> Steve

+1 to restricting the variable evaluation into the 'parameters' section
which we can treat as the 'static' part of a template. Maybe that is one
of the reasons why aws has a 'conditions' section to avoid getting into
the lazy evaluation mess?

Regards,
  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

Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification

[Qiming Teng]

On Thu, Mar 31, 2016 at 09:21:43AM -0400, Rabi Mishra wrote:
 
> If I understand the suggestion correctly, the only relation it has with 
> conditions is,
> conditions are nothing but variables(boolean).
> 
> conditions: {
> 'for_prod': {equals: [{get_param: env_type}, 'prod']}
>   }
> 
> would be
> 
> variables:
>for_prod: {equals: [{get_param: env_type}, prod]}
> 
> 
> then you can use it in your example as:
> 
> floating_ip:
>   type: OS::Nova::FloatingIP
>   condition: {get_variable: for_prod}
> 
> so suggestion is to make it more generic, so that it can be used for other 
> things
> and reduce some of the verbosity in the templates.
> 
> However, I think the term 'variable' makes is sound more like a programming 
> thing. May
> be we can use something better. However, personally I kind of like the idea.

well ... now I get a better idea about the suggestion. Actually,
'variables' is not that bad in my opinion.

Regards,
 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

Re: [openstack-dev] [Heat] Re-evaluate conditions specification

[Qiming Teng]

On Thu, Mar 31, 2016 at 10:40:33AM +0200, Thomas Herve wrote:
> Hi all,
> 
> As the patches for conditions support are incoming, I've found
> something in the code (and the spec) I'm not really happy with. We're
> creating a new top-level section in the template called "conditions"
> which holds names that can be reused for conditionally creating
> resource.
> 
> While it's fine and maps to what AWS does, I think it's a bit
> short-sighted and limited. What I have suggested in the past is to
> have a "variables" (or whatever you want to call it) section, where
> one can declare names and values. Then we can add an intrinsic
> function to retrieve data from there, and use that for examples for
> conditions.
> 
> It solves that particular issue, and it opens some interesting
> possibilities for reducing duplication in the template, as we could
> build arbitrary values out of parameters or attributes that can then
> be reused several times.
> 
> Thoughts?

Though not very excited by the current approach, I'm still a little bit
concerned about the extent to which we are extending the 'conditionals'
support. This is not an easy call given that we don't want HOT to become
a programming language.

A long time ago, we have a proposal from sdake. That one was stagnated
for ever. If we want to revisit this topic from step 0, we may as well
need to define the scope cleanly. For example, are we gonna support some
idioms for 'if, elif' only or we are introducing 'switch/case' also?
Are we introducing a boolean evaluator that can be applied to all data
types so that we get grammar completeness?
Are we gonna support logical operators as well? e.g. AND, OR, NOT?
Would this mean we are introducing some "reserved words" to HOT, or some
more builtin functions?
If these are to be modeled as functions, do we still want them to be
implemented at client side, as we do for 'get_file'?

Regards,
  Qiming
 
> -- 
> Thomas
> 
> __
> 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] [Senlin] Asking about launching an instance in Senlin cluster

[Qiming Teng]

Hi,

Please refer to Senlin user documentation [1] to start your journey (aka
adventure). Also, you can stop by the #senlin channel on freenode IRC
for any questions, suggestions.

BTW, This mailinglist is intended for developers not for usage
questions. You really want to check if someone on the IRC channel can
help you on these questions.


[1] http://docs.openstack.org/developer/senlin/user/index.html

Regards,
  Qiming

On Wed, Mar 30, 2016 at 02:39:56PM +0700, Nguyen Huy Cuong wrote:
> Dear OpenStack Supporter,
> 
> I am Cuong Nguyen, an Vietnamese IT engineer.
> 
> Currently, I am researching about Senlin to apply for my work.
> I research to launch an virtual machine on a Senlin cluster.
> Could you please advice me to perform this action?
> If I am missing something, please let me know.
> 
> Thank and best regards,
> 
> Cuong Nguyen.



__
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] [senlin][ptl] PTL Candidacy

[Qiming Teng]

Dear All,

With this mail I'm nominating myself as the PTL of the Senlin project
for the Newton cycle.

It has been an honor and a pleasure to work with developers who share
the same passion to make Senlin a useful and usable service to users.
Senlin is still at its infancy after joining the big tent family. We
still have a lot of work to do going forward although we are feeling
very happy it is pretty stable and usable now.

If I'm getting an opportunity to continue serving the team for its very
first official cycle, I'd strive to work with the team on the following
items:

- Better alignment with community

  * Getting API micro-versioning in place so that future revisions to
the API can be better managed;
  * Completing API/scenario tests using Tempest plugins, e.g. we are
to test not only how the API works normally but also how it fails;
  * Supports to live upgrade thus paving the way for future development;
  * Advanced filters for listing operations;

  etc.

- Full support to high-availability

  * A flexible, usable health policy;
  * Event/message listeners for node failure events;
  * Fencing logic regarding compute, network and storage;
  * Customizability of this feature for various usage scenarios;

- Support to container clusters

  * Enabler functions to create/manage containers in VMs / Bare-metals;
  * Simple placement policy to schedule containers based on dynamic
resource measurements;
  * Evaluate options for network and storage provisioning;

- Cross-project collaborations

  * Continue working with Heat regarding Senlin resource types;
  * Start working with Zarqar with respect to message queue receivers;
  * Engage with Tacker to support its autoscaling use case;
  * Work with Telemetry and Metering on event notifications and metrics;
  * Explore interaction with Mistral and Congress on workflow and
  * conformance (could be a policy?)
  * Explore Tooz for large-scale deployments

- Improvement to usability and scalability

Right. We have a lot work to do. We do perfer a PTL rotation practice
as some projects do and we do have strong candidates in the team.
However, when I asked around, I got the feeling that most are at the
moment over-committed in their daily jobs. Before stepping up as a PTL
candidate, one has to secure enough bandwidth for the job. Fortunately,
I am still enjoying such a support. That is the reason behind this post.

Regards,
  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

Re: [openstack-dev] [QA][all] Propose to remove negative tests from Tempest

[Qiming Teng]

> 
> I'd love to see this idea explored further. What happens if Tempest
> ends up without tests, as a library for shared code as well as a
> centralized place to run tests from via plugins?
> 

Also curious about this. It seems weird to separate the 'positive' and
the 'negative' ones, assuming those patches are mostly contributed by
the same group of developers.

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

Re: [openstack-dev] [Heat] Nomination Oleksii Chuprykov to Heat core reviewer

[Qiming Teng]

+1

- 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

Re: [openstack-dev] [ceilometer] Unable to get ceilometer events for instances running on demo project

[Qiming Teng]

This is a usage question not supposed to appear on this -dev list. But
anyway, you may want to check if you have the following lines in your
ceilometer.conf file:

  [notification]
  store_events = True


Regards,
  Qiming

On Wed, Mar 02, 2016 at 10:56:53PM +0500, Umar Yousaf wrote:
> I have a single node configuration for devstack liberty working and I want
> to record all the *ceilometer events* like compute.instance.start,
> compute.instance.end, compute.instance.update etc occurred recently.
> I am unable to get any event occurred for instances running for demo
> project i.e when I try *ceilometer event-list* I end up with an empty list
> but I could fortunately get all the necessary events occurred for instances
> running for admin project/tenant with the same command.
> In addition to this I want to get these through python client so if someone
> could provide me with the equivalent python call, that would be more than
> handy.
> Thanks in advance :)
> Regard,
> Umar

> __
> 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] [magnum][heat] spawn a group of nodes on different availability zones

[Qiming Teng]

On Fri, Mar 04, 2016 at 01:09:26PM +0800, Qiming Teng wrote:
> Another option is to try out senlin service. What you need to do is
> something like below:
> 
> 1. Create a heat template you want to deploy as a group, say,
> node_template.yaml
> 
> 2. Create a senlin profile spec (heat_stack.yaml) which may look
> like, for example:
> 
>   type: os.heat.stack
>   version: 1.0
>   properties:
> name: node_template
> template: node_template.yaml
> environment: shared_env.yaml
> 
> 3. Register the profile to senlin:
> 
>$ senlin profile-create -s heat_stack.yaml stack_profile
> 
>After this step, you can create individual instances (nodes) out of
> this profile.
> 
> 4. Create a cluster using the profile:
> 
>   $ senlin cluster-create -p stack_profile my_cluster
> 
> 5. Create a zone placement policy spec (zone_placement.yaml), which
> may look like:
> 
>   type: senlin.policy.zone_placement
>   version: 1.0
>   properties:
> zones:
>   - name: zone1
> weight: 100
>   - name: zone2
> weight: 50
> 
> 6. Initialize a policy object, which can be attaced to any clusters:
> 
>   $ senlin policy-create -s zone_placement.yaml zone_policy
> 
> 7. Attach the above policy to your cluster:
> 
>   $ senlin cluster-policy-attach -p zone_policy my_cluster

Oh, forgot to mention, this won't work at the moment because we are not
so sure that a stack as a whole can be placed into a single NOVA
AVAILABILITY ZONE, there are other availability zones as well. The above
example works if the profile is about an os.nova.server type.

Anyway, this example hopefully showed you how things are done with
senlin service.

Regards,
  Qiming
 
> Now, you can change your clusters size at will, and the zone placement
> policy will be enforced when new nodes are added or existing nodes are
> removed. For example:
> 
>   $ senlin cluster-scale-out -c 10 my_cluster
> 
> This will add 10 nodes to your cluster and the nodes will be spread
> across the availability zones based on the weight you specified. When
> you scale in your cluster, the zone distribution is also evaluated.
> 
> If any help needed, please stop by the #senlin channel IRC. We are more
> than happy to provide supports.
> 
> Regards,
>   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

Re: [openstack-dev] [magnum][heat] spawn a group of nodes on different availability zones

[Qiming Teng]

Another option is to try out senlin service. What you need to do is
something like below:

1. Create a heat template you want to deploy as a group, say,
node_template.yaml

2. Create a senlin profile spec (heat_stack.yaml) which may look
like, for example:

  type: os.heat.stack
  version: 1.0
  properties:
name: node_template
template: node_template.yaml
environment: shared_env.yaml

3. Register the profile to senlin:

   $ senlin profile-create -s heat_stack.yaml stack_profile

   After this step, you can create individual instances (nodes) out of
this profile.

4. Create a cluster using the profile:

  $ senlin cluster-create -p stack_profile my_cluster

5. Create a zone placement policy spec (zone_placement.yaml), which
may look like:

  type: senlin.policy.zone_placement
  version: 1.0
  properties:
zones:
  - name: zone1
weight: 100
  - name: zone2
weight: 50

6. Initialize a policy object, which can be attaced to any clusters:

  $ senlin policy-create -s zone_placement.yaml zone_policy

7. Attach the above policy to your cluster:

  $ senlin cluster-policy-attach -p zone_policy my_cluster

Now, you can change your clusters size at will, and the zone placement
policy will be enforced when new nodes are added or existing nodes are
removed. For example:

  $ senlin cluster-scale-out -c 10 my_cluster

This will add 10 nodes to your cluster and the nodes will be spread
across the availability zones based on the weight you specified. When
you scale in your cluster, the zone distribution is also evaluated.

If any help needed, please stop by the #senlin channel IRC. We are more
than happy to provide supports.

Regards,
  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

Re: [openstack-dev] [telemetry][aodh] "aodh alarm list" vs "aodh alarm search"

[Qiming Teng]

On Fri, Mar 04, 2016 at 09:57:35AM +0800, liusheng wrote:
> Hi folks,
> Currently, we have supported "aodh alarm list" and "aodh alarm
> search" commands to query alarms.  They both need mandatory "--type"
> parameter, and I want to drop the limitation[1]. if we agree that,
> the "alarm list"  will only used to list all alarms and don't
> support any query pamareters, it will be equal to "alarm search"
> command without any --query parameter specified.  The "alarm search"
> command is designed to support complex query which can perform
> almost all the filtering query, the complex query has been
> supportted in Gnocchi.  IRC meeting disscussions [3].
> 
> So we don't need two overlapping interfaces and want to drop one,
> "alarm list" or "alarm search" ?
> 
> i. The "alarm search" need users to post a expression in JSON format
> to perform spedific query, it is not easy to use and it is unlike a
> customary practice (I mean the most common usages of filtering query
> of other openstack projects), compare to "alarm list --filter
> xxx=zzz" usage.
> 
> ii. we don't have a strong requirement to support *complex* query
> scenarios of alarms, we only have alarms and alarm history records
> in aodh.
> 
> iii. I personally think it is enough to support filtering query with
> "--filter" which is easy to implement [2], and, we have plan to
> support pagination query in aodh.

+100
 
Really concerned that some projects keep inventing new things without
notion of cross-project guidelines. There have been a consensus to
remove individual CLIs [1], "advanced" filtering options [2]. If there
is really such a need to do ' resource search', maybe it is not
just an aodh thing.

Just two cents from a user's perspective.


[1]
http://specs.openstack.org/openstack/openstack-specs/specs/deprecate-cli.html
[2]
http://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.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] [all] A proposal to separate the design summit

[Qiming Teng]

Hi, All,

After reading through all the +1's and -1's, we realized how difficult
it is to come up with a proposal that makes everyone happy. When we are
discussing this proposal with some other contributors, we came up with a
proposal which is a little bit different. This idea could be very
impractical, very naive, given that we don't know much about the huge
efforts behind the scheduling, planning, coordination ... etc etc. So,
please treat this as a random thought.

Maybe we can still have the Summit and the Design Summit colocated, but
we can avoid the overlap that has been the source of many troubles. The
idea is to have both events scheduled by the end of a release cycle. For
example:

Week 1:
  Wednesday-Friday: 3 days Summit.
* Primarily an event for marketing, sales, CTOs, architects,
  operators, journalists, ...
* Contributors can decide whether they want to attend this.
  Saturday-Sunday:
* Social activities: contributors meet-up, hang outs ...

Week 2:
  Monday-Wednesday: 3 days Design Summit
* Primarily an event for developers.
* Operators can hold meetups during these days, or join project
  design summits.

If you need to attend both events, you don't need two trips. Scheduling
both events by the end of a release cycle can help gather more
meaningful feedbacks, experiences or lessons from previous releases and
ensure a better plan for the coming release.

If you want to attend just the main Summit or only the Design Summit,
you can plan your trip accordingly.

Thoughts?

 - 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

Re: [openstack-dev] [all] A proposal to separate the design summit

[Qiming Teng]

> >I don't think the proposal removes that opportunity. Contributors
> >/can/ still go to OpenStack Summits. They just don't /have to/. I
> >just don't think every contributor needs to be present at every
> >OpenStack Summit, while I'd like to see most of them present at
> >every separated contributors-oriented event[tm].
> 
> Yes they can, but if contributors go to the design summit, then they
> also have to get travel budget to go to the new Summit.   So, design
> summits,  midcycle meetups, and now the split off marketing summit.
> This is making it overall more expensive for contributors that meet
> with customers.
> 
My take of this is that we are saving the cost by isolating developers
(contributors) from users/customers.

- 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

Re: [openstack-dev] [all] A proposal to separate the design summit

[Qiming Teng]

On Mon, Feb 22, 2016 at 10:30:56PM -0500, michael mccune wrote:
> On 02/22/2016 11:06 AM, Dmitry Tantsur wrote:
> >+1 here. I got an impression that midcycles now usually happen in the
> >US. Indeed, it's probably much cheaper for the majority of contributors,
> >but would make things worse for non-US folks.
> 
> cost of travel has been a big reason we have never managed to have a
> sahara mid-cycle, as the team is evenly split across the world.
> 
> mike
> 
Cool. Then this proposal is about saving your mid-cycle costs for ever.

- 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

[openstack-dev] [senlin] Cancelling this and the next weekly meeting

[Qiming Teng]

Since most of the developers are on vacation during the Chinese New Year
festival. We are skipping the weekly IRC meetings this week (Feb 02
UTC 1300) and next week (Feb 09 UTC 1300).

Best wishes to you all and your family.

Regards,
  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

Re: [openstack-dev] [senlin] translatin setup

[Qiming Teng]

Thanks Andreas, we'll propose patches to set this up.

Regards,
  Qiming

On Sun, Jan 31, 2016 at 07:36:29PM +0100, Andreas Jaeger wrote:
> I noticed that senlin and python-senline havepot file in the tree
> but is not using our usual translation setup - and have no
> translations.
> 
> Do you want to enable translations using our translation server?
> Since senlin is an official team under governance, you can make use
> of that instead of having to do manually import translations.
> 
> Details about setup are at:
> 
> http://specs.openstack.org/openstack-infra/infra-specs/specs/translation_setup.html
> https://review.openstack.org/273759
> 
> If you have questions, feel free to ask. I'm happy to review your changes,
> 
> Andreas
> -- 
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
> 
> 
> __
> 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] [all] [api] API Working Group Refresher

[Qiming Teng]

On Fri, Jan 15, 2016 at 12:48:51PM +, Chris Dent wrote:
> 
> At yesterday's API Working Group meeting we decided it would be a
> good idea to send out a refresher on the existence of the group,
> its goals and activities. If you have interest in the improvement
> and standardization of OpenStack APIs please take this as an
> invitation to participate.
> 
> The group meets once a week in openstack-meeting-3 on Thursdays
> alternating between 00:00 UTC and 16:00 UTC[0].

The meeting time is quite confusing based on info on the wiki. It says
that 'next' meeting would be 2016-01-28 at 00:00UTC, previous meeting
was 2016-01-14 at 16:00UTC. Do we have a meeting on 2016-01-21? What
timeslot should it be? 16:00UTC or 00:00UTC?

Maybe we should keep at least one 'past' meeting on the wiki page so
that people can get a better idea what's going on?

- Qiming
 
> The primary goal of the group is to help OpenStack HTTP APIs adhere
> to standards and be consistent in the context of OpenStack[1]. To that
> end the main activities of members are:
> 
> * Creating, encouraging projects to create, and reviewing API
>   guidelines:
> 
>   * https://review.openstack.org/#/q/project:openstack/api-wg
>   * http://specs.openstack.org/openstack/api-wg/
> 
>   To be clear these are guidelines, not rules. The members of the
>   API working group are not cops. There's an open question of
>   whether the guidelines should codify existing behaviors or be more
>   aspirational. If you have an opinion on such things, you might
>   like to come along and share it.
> 
> * Providing guidance and sounding boards for changes which impact
>   HTTP APIS:
> 
>   * 
> https://review.openstack.org/#/q/status:open+AND+%28message:ApiImpact+OR+message:APIImpact%29,n,z
> 
> * Exploring existing APIs to get a sense of existing practices and
>   tease out which are "best":
> 
>   * https://wiki.openstack.org/wiki/API_Working_Group/Current_Design
> 
> Ideally every OpenStack project that has an HTTP API should have a
> designated cross project liaison who is willing to participate in the
> API working group and operate as bi-directional conduit. Talk to your
> PTL if you want this responsibility and then show up at the meetings.
> 
> [0] https://wiki.openstack.org/wiki/Meetings/API-WG
> [1] https://wiki.openstack.org/wiki/API_Working_Group#Purpose
> -- 
> Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
> freenode: cdent tw: @anticdent



__
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] Cross-Project Meeting, Tue Jan 12th, 21:00 UTC

[Qiming Teng]

Emm... 5 am is really not a good time for attending meetings.

- Qiming

On Mon, Jan 11, 2016 at 03:42:40PM -0800, Mike Perez wrote:
> Dear PTLs, cross-project liaisons and anyone else interested,
> 
> We'll have a cross-project meeting January 12th at 21:00 UTC in the NEW
> #openstack-meeting-cp IRC channel, with the following agenda:
> 
> * Team announcements (horizontal, vertical, diagonal)
> * API guides vision - developer.openstack.org and REST API docs
> * Cross-Project Spec Liaisons [1]
> * Open discussion
> 
>  If you're from a horizontal team (Release management, QA, Infra, Docs,
>  Security, I18n...) or a vertical team (Nova, Swift, Keystone...) and
>  have something to communicate to the other teams, feel free to abuse the
>  relevant sections of that meeting and make sure it gets #info-ed by the
>  meetbot in the meeting summary.
> 
>  See you there!
> 
>  For more details on this meeting, please see:
>  https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting
> 
>  [1] - https://review.openstack.org/#/c/266072/
> 
> -- 
> Mike Perez
 


__
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] [senlin] Welcome Elynn and Cindia-blue to Senlin team

[Qiming Teng]

During senlin mitaka mid-cycle meetup, team reviewed the latest
statistics of contributions to the senlin project. Among many
contributors, we were impressed by contributions from the following
two:

 - Ethan Lynn (ethanlynn)
 - Cindia-blue (miaoxinhuili)

Ethan has been a Heat core for some time. He has been helping make
senlin abstractions into heat resource types, improving engine
stability. He has a good understanding of senlin's vision and design.

Cindia's involvement with senlin has been about vSphere DRS support,
cross-region/az placement policies, cluster health management etc.
She has gained a pretty good understanding of senlin's design and
implementation.

They both have done good jobs helping senlin mature and they both have
shown their dedication and passion to the project.

During the meetup, we have decided to invite these two brilliant guys
into senlin team to help take the project to its next level.

Welcome to the team, guys!

 - 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

Re: [openstack-dev] [senlin] Midcycle meetup (2016-01-11/12)

[Qiming Teng]

Thanks for your interests in this event. We will try our best to use the
etherpad and the IRC channel (#senlin) for guys who cannot participate
in person. Please feel free to raise questions during any discussion
sessions.

- Qiming

On Thu, Jan 07, 2016 at 10:20:12PM +0800, Zhipeng Huang wrote:
> do we have audio communication for the meetup ?
> 
> On Mon, Jan 4, 2016 at 4:41 PM, Ethan Lynn  wrote:
> 
> > Finally I get a chance to see you all!
> >
> > Best Regards,
> > Ethan Lynn
> >
> >
> >
> > On Dec 28, 2015, at 17:54, Yanyan Hu  wrote:
> >
> > Great! Can't wait to see you guys :)
> >
> > 2015-12-28 10:03 GMT+08:00 Qiming Teng :
> >
> >> Dear all,
> >>
> >> Wish you all a merry christmas and a happy new year.
> >>
> >> Senlin team is planning a mid-cycle meetup next month in Beijing. Well,
> >> it goes beyond just a meetup between developers. We are inviting some
> >> users to share their real-life use cases and requirements.
> >>
> >> IBM Research China Lab will host the event. Please find the schedule
> >> etherpad here: https://etherpad.openstack.org/p/senlin-mitaka-midcycle
> >>
> >> Any comments/suggestions are welcomed. We are looking forward to see you
> >> guys.
> >>
> >> Regards,
> >>   Qiming
> >>
> >>
> >> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> >
> > --
> > Best regards,
> >
> > Yanyan
> > __
> > 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
> >
> >
> 
> 
> -- 
> 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


__
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] [openstacksdk][nose] Namespace conflict?

[Qiming Teng]

Thanks, Doug. Will keep an eye on this see if it is just an error made
by myself.

- 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

[openstack-dev] [openstacksdk][nose] Namespace conflict?

[Qiming Teng]

Hi,

We have been using python-openstacksdk for some time, so far so good.
Just encountered a problem when running latest devstack environment.
The error looks something like:

$ python testsdk.py
Traceback (most recent call last):
  File "testsdk.py", line 2, in 
from openstack import profile
ImportError: cannot import name profile

After examining the /usr/lib/python2.7/site-packages directory, I found
the package 'openstack.nose-plugin', which is using the 'openstack'
namespace. I have no idea what this package is about, why it was
installed and maybe I shouldn't care. The real problem is that this
package is using the 'openstack' namespace. It has only one file:

  /usr/lib/python2.7/site-packages/openstack/nose_plugin.py

This is conflicting with openstacksdk, which was installed somewhere
else. openstacksdk is also using this namespace.

Suggestions to solve this conflict?

Thanks in advance.

Regards,
  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

[openstack-dev] [senlin] Midcycle meetup (2016-01-11/12)

[Qiming Teng]

Dear all,

Wish you all a merry christmas and a happy new year.

Senlin team is planning a mid-cycle meetup next month in Beijing. Well,
it goes beyond just a meetup between developers. We are inviting some
users to share their real-life use cases and requirements.

IBM Research China Lab will host the event. Please find the schedule
etherpad here: https://etherpad.openstack.org/p/senlin-mitaka-midcycle

Any comments/suggestions are welcomed. We are looking forward to see you
guys.

Regards,
  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

Re: [openstack-dev] openstackdocstheme to be considered (very) harmful for your generated sphinx docs

[Qiming Teng]

Hi, Anne,

As someone unfortunately who was born and is still working behind a national
firewall, having a lot Google calls in docs do have some impacts on us.

It would be great if we can make the docs just self-contained docs.

Thanks.

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

Re: [openstack-dev] Fwd: [Senlin]Support more complicatedscalingscenario

[Qiming Teng]

On Wed, Nov 25, 2015 at 03:58:35PM +0800, Jun Xu wrote:
> 
> If a cluster attached two scaling_in policies(policy1 with priority
> 20 and policy2 with priority 40),
> when  policy_check function is called, it will do policy1 checking
> first and then check policy2.
> If any policy failed, it will return with CHECK_ERROR.  Is this
> conform to your original design?

yes, any policy check failure would mean the action was not supposed to
be executed.

...
 
> >Each policy instances creates its own policy-binding on a cluster. The
> >cooldown is recorded and then checked there. I can sense something is
> >wrong, but so far I'm not quite sure I understand the specific use case
> >that the current logic fails to support.
> Fo following case:
> A cluster is attached with two policies as follow.
> policy1:  type=senlin.policy.scaling, cooldown=60s,   event:
> CLUSTER_SCALE_IN
> policy2:  type=senlin.policy.scaling, cooldown=300s, event:
> CLUSTER_SCALE_OUT
> 
> Then I do following actions
> 1) senlin cluster-scale-in -c 1  mycluster
> --  scale-in  ok
> 2) after 70s,  senlin cluster-scale-in -c 1  mycluster
> ---  scale-in failed, because of policy2 is
> still in cooldown.

This sounds more like a bug in policy checking. Please help raise a bug,
we can jump onto it later.
 
> Now 'cooldown' is a common property for any kind of policy, I think
> this property maybe not necessary for all kind of policy like
> LB_POLICY.

This is actually a good point. Will bring this to the team for a
discussion. Thanks.
 
> >This is a misconcept because a Senlin policy is not a Heat
> >ScalingPolicy.  A Senlin policy is checked before and/or after a
> >specified action is performed.
> 
> I got they are different, I want to know how combine these
> operations(e.g. webhook,
> ScalePolicy, cluster, ceilometer alarms) to realize the autoscaling
> functions like in Heat?
> Hu yanyan has given an combinatorial method,  but I think this
> method doesn't  resolve the case.

Emm, I think we need to provide a tutorial document in tree.

> I really want to discuss the cooldown checking for multiple polices
> of same type.
> Following is the different for autoscaling in Senlin and Heat.
> In Senlin:
> policy1:  type=senlin.policy.scaling, cooldown=60s,   event:
> CLUSTER_SCALE_IN
> policy2:  type=senlin.policy.scaling, cooldown=300s, event:
> CLUSTER_SCALE_IN
> webhook1: count=1, action=CLUSTER_SCALE_IN
> webhook2: count=2, action=CLUSTER_SCALE_IN
> 
>trigger webhook1, all policy1's cooldown and policy2's cooldown
> will be checked.
>trigger webhook2, all policy1's cooldown and policy2's coolddow
> will be checked.
> 
> 
> In Heat
>policy1: type=OS::Heat::ScalingPolicy, cooldown=60s,
> scaling_adjustment=1
>policy2: type=OS::Heat::ScalingPolicy, cooldown=300s,
> scaling_adjustment=2
>policy1 will return a webhook as webhook1.
>policy2 will return a webhook as webhook2.
> 
>trigger webhook1, only policy1's cooldown will be checked.
>trigger webhook1, only policy1's cooldown will be checked.
> 

Think about this, why do you have 'cooldown' property? It is mainly
designed to avoid thrashing behavior of a cluster/group, right? It
doesn't make a lot senses to me having each webhook specifying a
different 'cooldown' value. In other words, 'cooldown' could be set to
be a property of the cluster/group. The cooldown checking logic you
outlined above hit the point -- should we shield the cluster from any
scaling requests during a 'cooldown' phase? My answer would be yes.
It is the cluster you want to protect, not the policy or action.

With that, we will discuss whether it makes sense to make 'cooldown' a
cluster property instead of a policy property.

Thanks,
  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

Re: [openstack-dev] Fwd: [Senlin]Support more complicated scalingscenario

[Qiming Teng]

> After debugging,  I found that former result is not overridden by
> another policy.
> http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/base.py#n441

I think you are not referring to a correct location in the source code.
That line was only about checking whether there are some policies failed
checking.
 
> >
> >2. if  a cluster attached a scaling policy with event =
> >CLUSTER_SCALE_IN,  when aCLUSTER_SCALING_OUT action is
> >triggered,  the policy also will be checked,  is this reasonable?
> >
> >/ When a ScalingPolicy is defined, you can use 'event'
> >property to specify the action type you want the policy to take
> >effect on, like:
> >http://git.openstack.org/cgit/openstack/senlin/tree/examples/policies/scaling_policy.yaml#n5
> >
> > Although a ScalingPolicy will be checked for both
> >CLUSTER_SCALE_IN and CLUSTER_SCALE_OUT actions, the check routine
> >will return immediately if the action type is not what it is
> >expecting.
> >http://git.openstack.org/cgit/openstack/senlin/tree/senlin/policies/scaling_policy.py#n133/
> 
> Yes  it's not checked in pre_op,  but all ScalingPolicies still will
> be checked whether in cooldown.
> http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/base.py#n431*

Each policy instances creates its own policy-binding on a cluster. The
cooldown is recorded and then checked there. I can sense something is
wrong, but so far I'm not quite sure I understand the specific use case
that the current logic fails to support.

> >Your suggestion has a problem when I want different cooldown
> >for each ceilometer/aodh alarms, for following cases, how
> >should I do?
> >1.  15% < cpu_util  < 30%,  scaling_in 1 instance with 300s
> >cooldown time
> >2.   cpu_util < 15%, scaling_in 2 instances with 600s
> > cooldown time
> >
> >For a senlin webhook, could we assign a policy which will be
> >checked ?
> >
> >/   User is not allowed to specify the policy when defining a
> >webhook. The webhook target is decided by target object(cluster or
> >node) and target action type./
> 
> Yes we can define cooldown for each policy, but my meaning is
> that each cluster_scaling_in action is only checked by specified
> scaling_policy like OS::Heat::ScalingPolicy in heat.

This is a misconcept because a Senlin policy is not a Heat
ScalingPolicy.  A Senlin policy is checked before and/or after a
specified action is performed.

> 1） In heat, we could define two scaling_in actions(via define
> two OS::Heat::ScalingPolicy polices ), each scaling_in action is
> checked by one OS::Heat::ScalingPolicy, so each scaling_in action's
> cooldown is only checked in one OS::Heat::ScalingPolicy.
>  2）But in senlin, each scaling_in action will be checked by all
> attached scaling_policies, so all scaling_polices' cooldown will be
> checked.How does senlin support different cooldown time for each
> scaling_in action?

The built-in policy will check if the action is a 'CLUSTER_SCALE_IN'
action or not. The policy is supposed to help you decide the number of
nodes you want to remove from a cluster. If you have a specific
requirement where you want 2 nodes to be removed under one condition, 1
node to be removed under another condition, you will create two webhooks
to explicitly specify that. A scaling policy will respect the 'count'
parameter you speicifed from the webhook.

Each policy has its default cooldown value when created. However, you
can easily override that default value when attaching such a policy to a
cluster. See 'senlin help cluster-policy-attach' for more info.

Regards,
  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

Re: [openstack-dev] Fwd: [Senlin]Support more complicated scaling scenario

[Qiming Teng]

Hi,

  Please try quote previous responses in your message because it will
make the message a little bit easier to follow. You can set up your mail
client to do so. For example:

#
# 
#

Now this is your response

#
# 
#

When appropriate, you can even delete irrelevant texts when responding.
Just some suggestions.

p.s. you can stop by the #senlin channel to ask specific questions as
well.

Regards,
  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

[openstack-dev] [senlin] Mitaka summit meetup - a summary

[Qiming Teng]

Hi,

Thanks for joining the senlin meetup last week at Tokyo summit. We know
some of you were not able to make it for various reasons. I'm trying to
summarize things we discussed during the meetup and some preliminary
conclusions we got. Please feel free to reply to this email or find the
team on #senlin channel if you have questions/suggestions.


Short Version
-

- Senlin will focus more on two things during Mitaka cycle: 1)
  stability regarding API and engine; 2) Heat resource type support.

- Senlin engine won't do "convergence" as suggested by some people,
  however the engine should be responsible to manage the lifecycles of
  the objects it creates on behalf of users.

- Team will revise the APIs according to the recent guidelines from
  api-wg and make the first version released as stable as possible.
  Before having a versioning scheme in place, we won't bump the API
  versions in ad-hoc ways.

- Senlin will NOT introduce complicated monitoring mechanisms into the
  engine albeit we'd strive to support cluster/node status checkings.
  We opt to use whatever external monitoring services and leave that
  an option for users.

- We will continue working with TOSCA team to polish policy definitions.

- We will document guidelines on how policy decisions are passed from
  one policy to another.

- We are interested in building baremetal clusters, but we will keep it
  in pipeline unless there are: 1) real requests, and 2) resources to
  get it done.

- As part of the API stabilization effort, we will generalize the
  concept of 'webhook' into 'receiver'.


Long Version (TL;DR)


* Stability v.s. Features

We had some feature requests like managing container clusters, doing
smart scheduling, running scripts on a cluster of servers, supporting
clusters of non-compute resources... etc. These are all good ideas.
However, Senlin is not aiming to become a service of everything. We have
to refrain from the temptation of too wide a scope. There are millions
of things we can do, but the first priority at this stage is about
stability. Making it usable and stable before adding fancy features,
this was the consensus we achieved during the meetup. We will stick to
that during Mitaka cycle.

* Heat Resource Type Support

Team had a discussion with heat team during a design summit slot. The
basic vision remained the same: let senlin do autoscaling and deprecate
heat autoscaling when senlin is stable. There are quite some details
to be figured out. The first thing we would do is to land senlin
cluster, node and profile resource types in Heat and build a
auto-scaling end-to-end solution comparable to existing one. Then the
two teams will make decision on how to make the transition smooth for
both developers and users.

* Convergence or Not

There were suggestions to define 'desired' state and 'observed' state
for clusters and have senlin engine do the convergence. After some
closer examination of the use case, we decided not to do it. The
'desired' state of a node is obvious (i.e. ACTIVE). The 'desired' state
of a cluster is a little bit vague. It boils down to whether we would
allow 'partial success' when creating a cluster of 1,000 nodes. Failures
are unavoidable, thus something we have to live with. However, we are
very cautious about making decisions for users. Say we have 90% nodes
ACTIVE in a cluster, should we label the cluster an 'ERROR' state, or a
'WARNING' state, or just 'ACTIVE'? We tend to leave this decision to
users who are smart people too. To avoid too much burdens on users, we
will add some defaults that can be set by operators.

There are cases where senlin engine creates objects when enforcing a
policy, e.g. the load-balancing policy. The engine should do a good job
managing the status of those objects.

* API Design

Senlin already have an API design which is documented. Before doing a
verion 1.0 release, we need to further hammer on it. Most of these
revisions would be related to guidelines from api-wg. For example, the
following changes are expected to land during Mitaka:

 - return 202 instead of 200 for asynchronous operations
 - better align with the proposed change to 'action' APIs
 - sorting keys and directions
 - returning 400 or 404 for resources not found
 - add location headers where appropriate

Another change to the current API will be about webhook. We got
suggestions related to receving notifications from other channels other
than webhooks, e.g. message queues, external monitoring services. To avoid
disruptive changes to the APIs in future, we decided to generalize webhook
APIs to 'receivers'. This is an important work even if we only support
webhook as the only type of receivers. We don't want to see webhook APIs
provided and soon replaced/deprecated.

* Relying on External Monitoring

There used to be some interests in doing status polling on cluster
nodes so that the engine will know whether nodes are healthy or not.
This idea was rejected during 

[openstack-dev] [Senlin] Design summit meetup proposed schedule

[Qiming Teng]

Hi,

After consulting with ttx, we still cannot find a meeting room for a
meetup for Senlin developers. However, we can grab a table in the Prince
room on Friday morning, as suggested by ttx.

Location: Prince Room
Time: 09:00am - 12:00am

So, team, let's get tuned for a fruitful discussion. Topics to be
discussed include, but not limited to:

- API consistency
- Health management and engine stabilization
- Webhook v.s. Receiver
- Heat resource type support
- Engine housekeeping jobs

We will use the following etherpad for discussion:

https://etherpad.openstack.org/p/senlin-mitaka-meetup

Looking forward to meet you there!

Regards,
 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

[openstack-dev] [Senlin] Weekly meeting 10/27 cancelled, resuming after summit

[Qiming Teng]

Since most developers will attend the summit next week. The weekly
Senlin meeting next Tuesday will be skipped. We will resume on
11/03/2015. Right. We have more than 10 days to prepare an agenda,
:)

https://wiki.openstack.org/wiki/Meetings/SenlinAgenda

Best Wishes,
  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

Re: [openstack-dev] [Heat] core team nomination

[Qiming Teng]

+1 to both.

Qiming

On Tue, Oct 20, 2015 at 04:38:12PM +0300, Sergey Kraynev wrote:
> I'd like to propose new candidates for heat core-team:
> Rabi Mishra
> Peter Razumovsky
> 
> According statistic both candidate made a big effort in Heat as
> reviewers and as contributors [1][2].
> They were involved in Heat community work  during last several releases and
> showed good understanding of Heat code.
> I think, that they are ready to became core-reviewers.
> 
> Heat-cores, please vote with +/- 1.
> 
> [1] http://stackalytics.com/report/contribution/heat-group/180
> [2] http://stackalytics.com/?module=heat-group&metric=person-day
> -- 
> Regards,
> Sergey.
> 
> __
> 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

[openstack-dev] [all][heat] Which repo to use in docs -- git.openstack.org or github.com?

[Qiming Teng]

Hi,

Just encountered this again in code review [1]. The question is about
the repository to point to when documenting things up. Between the
following links, which one should we use?

- https://git.openstack.org/cgit/openstack/sqlalchemy-migrate
- https://github.com/openstack/sqlalchemy-migrate

I had an impression that I saw something like 'use git.openstack.org
instead of github.com because the later is just a mirror ...' but cannot
find the link now. Maybe it is an illusion. :)

So, seriously, any recommendations or guidelines?

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

Regards,
  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

[openstack-dev] [tc][senlin] Request to senlin project to big tent

[Qiming Teng]

Dear TC members,

Your reviews on the proposal are highly appreciated.

Subject: Add senlin project to big tent
Link: https://review.openstack.org/#/c/235172/

Regards,
 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

Re: [openstack-dev] New PyCharm License

[Qiming Teng]

launchpad-id: tengqim

Thanks.
 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