Re: [openstack-dev] [magnum] Problems with multi-regional OpenStack installation

[Fei Long Wang]

Hi Andrei,

Thanks for raising this issue. I'm keen to review and happy to help. I
just done a quick look for https://review.openstack.org/#/c/578356, it
looks good for me.

As for heat-container-eingine issue, it's probably a bug. I will test an
propose a patch, which needs to release a new image then. Will update
progress here. Cheers.



On 28/06/18 19:11, Andrei Ozerov wrote:
> Greetings.
>
> Has anyone successfully deployed Magnum in the multi-regional
> OpenStack installation?
> In my case different services (Nova, Heat) have different public
> endpoint in every region. I couldn't start Kube-apiserver until I
> added "region" to a kube_openstack_config.
> I created a story with full description of that problem:
> https://storyboard.openstack.org/#!/story/2002728
>  and opened a
> review with a small fix: https://review.openstack.org/#/c/578356.
>
> But apart from that I have another problem with such kind of OpenStack
> installation.
> Say I have two regions. When I create a cluster in the second
> OpenStack region, Heat-container-engine tries to fetch Stack data from
> the first region.
> It then throws the following error: "The Stack (hame-uuid) could not
> be found". I can see GET requests for that stack in logs of Heat-API
> in the first region but I don't see them in the second one (where that
> Heat stack actually exists).
>
> I'm assuming that Heat-container-engine doesn't pass "region_name"
> when it searches for Heat endpoints:
> https://github.com/openstack/magnum/blob/master/magnum/drivers/common/image/heat-container-agent/scripts/heat-config-notify#L149.
> I've tried to change it but it's tricky because the
> Heat-container-engine is installed via Docker system-image and it
> won't work after restart if it's failed in the initial bootstrap
> (because /var/run/heat-config/heat-config is empty).
> Can someone help me with that? I guess it's better to create a
> separate story for that issue?
>
> -- 
> Ozerov Andrei
> oze...@selectel.com 
> +7 (800) 555 06 75
> 
>
>
> __
> 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

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

__
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] New temporary meeting on Thursdays 1700UTC

[Fei Long Wang]

Hi Spyros,

Thanks for posting the discussion output. I'm not sure I can follow the
idea of simplifying CNI configuration. Though we have both calico and
flannel for k8s, but if we put both of them into single one config
script. The script could be very complex. That's why I think we should
define some naming and logging rules/policies for those scripts for long
term maintenance to make our life easier. Thoughts?


On 25/06/18 19:20, Spyros Trigazis wrote:
> Hello again,
>
> After Thursday's meeting I want to summarize what we discussed and add
> some pointers.
>
>   * Work on using the out-of-tree cloud provider and move to the new
> model of defining it
> https://storyboard.openstack.org/#!/story/1762743
> 
> https://review.openstack.org/#/c/577477/
>   * Configure kubelet and kube-proxy on master nodes
> This story of the master node label can be
> extened https://storyboard.openstack.org/#!/story/2002618
> 
> or we can add a new one
>   * Simplify CNI configuration, we have calico and flannel. Ideally we
> should a single config script for each
> one. We could move flannel to the kubernetes hosted version that
> uses kubernetes objects for storage.
> (it is the recommended way by flannel and how it is done with kubeadm)
>   * magum support in gophercloud
> https://github.com/gophercloud/gophercloud/issues/1003
>   * *needs discussion *update version of heat templates (pike or
> queens) This need its own tread
>   * Post deployment scripts for clusters, I have this since some time
> for my but doing it in
> heat is slightly (not a lot) complicated. Most magnum users favor 
> the simpler solution
> of passing a url of a manifest or script to the cluster (at least
> let's add sha512sum).
>   * Simplify addition of custom labels/parameters. To avoid patcing
> magnum, it would be
> more ops friendly to have a generic field of custom parameters
>
> Not discussed in the last meeting but we should in the next ones:
>
>   * Allow cluster scaling from different users in the same project
> https://storyboard.openstack.org/#!/story/2002648
> 
>   * Add the option to remove node from a resource group for swarm
> clusters like
> in kubernetes
> https://storyboard.openstack.org/#!/story/2002677
> 
>
> Let's follow these up in the coming meetings, Tuesday 1000UTC and
> Thursday 1700UTC.
>
> You can always consult this page [1] for future meetings.
>
> Cheers,
> Spyros
>
> [1] https://wiki.openstack.org/wiki/Meetings/Containers
>
> On Wed, 20 Jun 2018 at 18:05, Spyros Trigazis  > wrote:
>
> Hello list,
>
> We are going to have a second weekly meeting for magnum for 3 weeks
> as a test to reach out to contributors in the Americas.
>
> You can join us tomorrow (or today for some?) at 1700UTC in
> #openstack-containers .
>
> Cheers,
> Spyros
>
>
>
>
> __
> 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

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

__
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] K8S apiserver key sync

[Fei Long Wang]

Hi Remo,

I can't see obvious issue from the log you posted. You can pop up at
#openstack-containers IRC channel as for Magnum questions. Cheers.


On 21/06/18 08:56, Remo Mattei wrote:
> Hello guys, what will be the right channel to as a question about
> having K8 (magnum working with Tripleo)? 
>
> I have the following errors..
>
> http://pastebin.mattei.co/index.php/view/2d1156f1
>
> Any tips are appreciated. 
>
> Thanks 
> Remo 
>
>> On Jun 19, 2018, at 2:13 PM, Fei Long Wang > <mailto:feil...@catalyst.net.nz>> wrote:
>>
>> Hi there,
>>
>> For people who maybe still interested in this issue. I have proposed
>> a patch, see https://review.openstack.org/576029 And I have verified
>> with Sonobuoy for both multi masters (3 master nodes) and single
>> master clusters, all worked. Any comments will be appreciated. Thanks.
>>
>>
>> On 21/05/18 01:22, Sergey Filatov wrote:
>>> Hi!
>>> I’d like to initiate a discussion about this bug: [1].
>>> To resolve this issue we need to generate a secret cert and pass it
>>> to master nodes. We also need to store it somewhere to support scaling.
>>> This issue is specific for kubernetes drivers. Currently in magnum
>>> we have a general cert manager which is the same for all the drivers.
>>>
>>> What do you think about moving cert_manager logic into a
>>> driver-specific area?
>>> Having this common cert_manager logic forces us to generate client
>>> cert with “admin” and “system:masters” subject & organisation names
>>> [2], 
>>> which is really something that we need only for kubernetes drivers.
>>>
>>> [1] https://bugs.launchpad.net/magnum/+bug/1766546
>>> [2] 
>>> https://github.com/openstack/magnum/blob/2329cb7fb4d197e49d6c07d37b2f7ec14a11c880/magnum/conductor/handlers/common/cert_manager.py#L59-L64
>>>
>>>
>>> ..Sergey Filatov
>>>
>>>
>>>
>>>> On 20 Apr 2018, at 20:57, Sergey Filatov >>> <mailto:s.s.filato...@gmail.com>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> I looked into k8s drivers for magnum I see that each api-server on
>>>> master node generates it’s own service-account-key-file. This
>>>> causes issues with service-accounts authenticating on api-server.
>>>> (In case api-server endpoint moves).
>>>> As far as I understand we should have either all api-server keys
>>>> synced on api-servesr or pre-generate single api-server key.
>>>>
>>>> What is the way for magnum to get over this issue?
>>>
>>>
>>>
>>> __
>>> 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
>>
>> -- 
>> Cheers & Best regards,
>> Feilong Wang (王飞龙)
>> --
>> Senior Cloud Software Engineer
>> Tel: +64-48032246
>> Email: flw...@catalyst.net.nz
>> Catalyst IT Limited
>> Level 6, Catalyst House, 150 Willis Street, Wellington
>> -- 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org
>> <mailto: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

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

__
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] K8S apiserver key sync

[Fei Long Wang]

Hi there,

For people who maybe still interested in this issue. I have proposed a
patch, see https://review.openstack.org/576029 And I have verified with
Sonobuoy for both multi masters (3 master nodes) and single master
clusters, all worked. Any comments will be appreciated. Thanks.


On 21/05/18 01:22, Sergey Filatov wrote:
> Hi!
> I’d like to initiate a discussion about this bug: [1].
> To resolve this issue we need to generate a secret cert and pass it to
> master nodes. We also need to store it somewhere to support scaling.
> This issue is specific for kubernetes drivers. Currently in magnum we
> have a general cert manager which is the same for all the drivers.
>
> What do you think about moving cert_manager logic into a
> driver-specific area?
> Having this common cert_manager logic forces us to generate client
> cert with “admin” and “system:masters” subject & organisation names [2], 
> which is really something that we need only for kubernetes drivers.
>
> [1] https://bugs.launchpad.net/magnum/+bug/1766546
> [2] 
> https://github.com/openstack/magnum/blob/2329cb7fb4d197e49d6c07d37b2f7ec14a11c880/magnum/conductor/handlers/common/cert_manager.py#L59-L64
>
>
> ..Sergey Filatov
>
>
>
>> On 20 Apr 2018, at 20:57, Sergey Filatov > > wrote:
>>
>> Hello,
>>
>> I looked into k8s drivers for magnum I see that each api-server on
>> master node generates it’s own service-account-key-file. This causes
>> issues with service-accounts authenticating on api-server. (In case
>> api-server endpoint moves).
>> As far as I understand we should have either all api-server keys
>> synced on api-servesr or pre-generate single api-server key.
>>
>> What is the way for magnum to get over this issue?
>
>
>
> __
> 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

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

__
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] [Zaqar] Nominating yangzhenyu for Zaqar core

[Fei Long Wang]

Hi team,

I would like to propose adding Zhenyu Yang(yangzhenyu) for the Zaqar core team. 
He has been an awesome contributor since joining the Zaqar team. And now he is 
the most active non-core contributor on Zaqar projects for the last 180 
days[1]. Zhenyu has great technical expertise and contributed many high quality 
patches. I'm sure he would be an excellent addition to the team. If no one 
objects, I'll proceed and add him in a week from now. Thanks.

[1] http://stackalytics.com/report/contribution/zaqar-group/180

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 



__
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] [zaqar] Not run for PTL

[Fei Long Wang]

Hi team,

I have been working on Zaqar for more than 4 years and serving the PTL
for the past 5 cycles. I don't plan to run for Zaqar PTL again for the
Rocky release. I think it's time for somebody else to lead the team for
next milestone. It has been a great experience for me and thank you for
all the support from the team and the whole community. I will still be
around for sure. Thank you.

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 



__
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] Unstable API in cloudci

[Fei Long Wang]

Sorry, wrong mail list.


On 23/01/18 15:14, Fei Long Wang wrote:
> Hi team,
>
> I think it's important to highlight this issue because it's affecting
> the whole team now. Recently (basically after the holiday or after the
> meltdown patching), we're experiencing an unstable cloudci. When you
> deploy a new cloudci env, you will see some random 500 or 503 error from
> different services. And so far, based on our investigation, it's caused
> by Keystone, and Keystone is experiencing a weird IO error. Now it's
> basically blocking Magnum and Octavia testing. We need to put some
> effort on this.

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] Unstable API in cloudci

[Fei Long Wang]

Hi team,

I think it's important to highlight this issue because it's affecting
the whole team now. Recently (basically after the holiday or after the
meltdown patching), we're experiencing an unstable cloudci. When you
deploy a new cloudci env, you will see some random 500 or 503 error from
different services. And so far, based on our investigation, it's caused
by Keystone, and Keystone is experiencing a weird IO error. Now it's
basically blocking Magnum and Octavia testing. We need to put some
effort on this.


-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 



__
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] PTL Election Season

[Fei Long Wang]

Matt, thank you for all you have done for Nova. It's a good journey to
work with you in past 7 years. And I'm looking forward to meeting you in
next summit.


On 23/01/18 12:09, Matt Riedemann wrote:
> On 1/15/2018 11:04 AM, Kendall Nelson wrote:
>> Election details: https://governance.openstack.org/election/
>>
>> Please read the stipulations and timelines for candidates and
>> electorate contained in this governance documentation.
>>
>> Be aware, in the PTL elections if the program only has one candidate,
>> that candidate is acclaimed and there will be no poll. There will
>> only be a poll if there is more than one candidate stepping forward
>> for a program's PTL position.
>>
>> There will be further announcements posted to the mailing list as
>> action is required from the electorate or candidates. This email is
>> for information purposes only.
>>
>> If you have any questions which you feel affect others please reply
>> to this email thread.
>>
>
> To anyone that cares, I don't plan on running for Nova PTL again for
> the Rocky release. Queens was my fourth tour and it's definitely time
> for someone else to get the opportunity to lead here. I don't plan on
> going anywhere and I'll be here to help with any transition needed
> assuming someone else (or a couple of people hopefully) will run in
> the election. It's been a great experience and I thank everyone that
> has had to put up with me and my obsessive paperwork and process
> disorder in the meantime.
>

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] [trove] Changes to the Trove core team

[Fei Long Wang]

+1 and congrats!


On 10/01/18 12:10, Manoj Kumar wrote:
> I would like to announce the following changes to the Trove core
> reviewers:
>
> -amrith
> +maciej.jozefczyk
> +fanzhang
>
> Amrith's stewardship of Trove and active contributions over the last
> several cycles would be missed dearly.
> Would like to welcome Fan and Maciej.
>
> - Manoj
>
>
> __
> 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

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

__
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] Switching to longer development cycles

[Fei Long Wang]

On 21/12/17 12:57, McLellan, Steven wrote:
>
> On 12/20/17, 5:29 PM, "Matt Riedemann"  wrote:
>
> On 12/20/2017 3:21 PM, Matt Riedemann wrote:
> > On 12/20/2017 9:30 AM, Zane Bitter wrote:
> >> To answer the question from your other mail about user-space 
> >> notifications:
> >>
> >>> We (Zaqar team) have been asked many times about this area but 
> without a
> >>> support from more services, it's hard. I know Heat has some best
> >>> practice using Zaqar, is it possible to "copy" it to 
> >>> Nova/Cinder/Neutron?
> >>
> >> Sure, it would be dead easy, but Nova cores have made it abundantly 
> >> clear that under no circumstances would they ever accept any code like 
> >> this in Nova. Hence it's on this list.
> > 
> > Again, this is news to me. Why isn't this proposed as a community-wide 
> > goal for Rocky?
> > 
> > And if it would be dead easy, why aren't we trying to get part time or 
> > new contributors to work on this, like OSIC was for awhile around the 
> > time of the Austin summit?
> > 
> 
> Now I know.
> 
> 
> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-20.log.html#t2017-12-20T21:46:11
> 
> -- 
> 
> Since in that IRC conversation ceilometer's notification consumer was 
> mentioned: there was some prototype work done on this (publishing messages to 
> Zaqar off the notification bus to Zaqar) by Lei Zhang in the searchlight 
> codebase - https://review.openstack.org/#/c/271958/. It would be reasonably 
> straightforward to add a service to Zaqar to consume messages off the bus, 
> and I would imagine that it's going to be easier in terms of getting things 
> done to take the notifications (which are a well established format and 
> mechanism) and the transformation to publish them in Zaqar than add a new 
> component to all the individual services.
>
> Steve

Yep, that one is another try in this area. And we (Zaqar team) will
seriously consider the option consuming messages off the infra bus.

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

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] Switching to longer development cycles

[Fei Long Wang]

On 20/12/17 09:29, Joshua Harlow wrote:
> Zane Bitter wrote:
>> Getting off-topic, but since you walked in to this one ;)
>>
>> On 14/12/17 21:43, Matt Riedemann wrote:
>>> What are the real problems that the Nova team is not working on and
>>> apparently is a priority to everyone else in the OpenStack ecosystem
>>> but we are somehow oblivious?
>>
>> * Providing a secure channel to get credentials to guests so that
>> applications running on them can authenticate to OpenStack APIs.
>>
>> * Providing reliable, user-space notifications of events that may
>> require application or application-operator intervention (e.g. VM
>> reboot, hypervisor died, ).
>
> I'll add on.
>
> * Clear workflow state (and transition) 'machine' that is followed in
> code and can be used by operators/others such as UI developers to get
> a view on what nova is or is not doing (may fit under the broad topic
> of observability?)
>
> Take for example
> http://flower.readthedocs.io/en/latest/screenshots.html and ask
> yourself why nova-compute (or nova-conductor or nova-scheduler...)
> doesn't have an equivalent kind of 'viewer' (and no it doesn't need to
> be flower, that's just an example...)
>

That's one of the changes we (at least me and Rob Cresswell) would like
to improve in Horizon. The idea is services (Nova, Cinder, Nutron, etc)
putting notifications into Zaqar queue and then Horizon can easily get
the resources status instead of doing stupid polling. And it could be
easily doing the thing shown on above link.

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

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] Switching to longer development cycles

[Fei Long Wang]

On 20/12/17 07:07, Zane Bitter wrote:
> On 13/12/17 11:17, Thierry Carrez wrote:
>> So... What do you think ?
>
> Some points against that I haven't seen mentioned much yet:
>
> * Following our standard deprecation policy, it would take up to 3
> years to remove anything. For perspective, 3 years ago we had just
> shipped Juno. (I feel old now.)
>
> * Other large, complex software distributions have moved to 6-month or
> shorter development cycles (e.g. Ubuntu, Fedora, Chromium, Linux,
> Firefox), with apparent success. What do we think is different about
> the context in which we work that makes it a good idea to go in the
> other direction?
>
> * Upgrading OpenStack is painful for our users. Modern software
> development theory holds that you make painful things less painful by
> doing them *more* often, in smaller bites. (And preferably make the
> developers suffer some of the pain, so they're motivated to reduce
> it.) Less frequent upgrades with bigger changes is likely to provoke
> even more of our users to remain on old releases indefinitely.
>
> * It's true that OpenStack is mature in the sense that the things it
> does are pretty stable. It's not true in the sense of it being close
> to fulfilling our mission, of implementing a full-featured cloud.
> (e.g. my pet bug-bear: applications can't use it unless they have
> economies of scale, are prepared to implement a bunch of stuff
> themselves, and are extremely motivated to use OpenStack over
> alternatives that are designed with application support in mind... so
> basically just infra.) We absolutely need to keep up a fast pace of
> innovation in order not to become irrelevant.
>

+100

> * Natural complements to OpenStack like Kubernetes also have rapid
> release cycles. If we're unable to respond rapidly to changes in them
> (by adjusting our integration points in a timely fashion) then they're
> going to be more inclined to put effort into working around OpenStack
> than into working together. (The fact that said integration points
> largely don't exist at the moment is also an example of the previous
> point.)

Very good point.

>
> * As someone who will probably volunteer as a PTL again at some point,
> the prospect of having to sign up for an entire year is a major
> disincentive to do so.
>
>
> I'm all for encouraging companies who are using OpenStack to
> contribute e.g. 20% of a developer to helping out upstream. I'm not at
> all convinced that regular releases are an obstacle to that - by the
> 'pace' of development I suspect they mean the constant code churn
> resulting in never-ending rebases of outstanding patches that they
> struggle to get reviews on (often, it must be said, because they are
> GIANT), and not the release cadence. So count me as -1 on this change.
>
> cheers,
> Zane.
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] Switching to longer development cycles

[Fei Long Wang]

On 20/12/17 08:20, Zane Bitter wrote:
> Getting off-topic, but since you walked in to this one ;)
>
> On 14/12/17 21:43, Matt Riedemann wrote:
>> What are the real problems that the Nova team is not working on and
>> apparently is a priority to everyone else in the OpenStack ecosystem
>> but we are somehow oblivious?
>
> * Providing a secure channel to get credentials to guests so that
> applications running on them can authenticate to OpenStack APIs.
>

I'm trying to do that in Trove with Zaqar, if there is any interest,
please jump in #openstack-zaqar and let's have a talk.

> * Providing reliable, user-space notifications of events that may
> require application or application-operator intervention (e.g. VM
> reboot, hypervisor died, ).

We (Zaqar team) have been asked many times about this area but without a
support from more services, it's hard. I know Heat has some best
practice using Zaqar, is it possible to "copy" it to Nova/Cinder/Neutron?

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

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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][election] Question for the candidates

[Fei Long Wang]

One thing I wish the TC could do in the past years or so is using their
"power" to help to push a more integrated/collaborative OpenStack.
Though some(all) TC members may think they don't have the power.


On 13/10/17 07:38, Ed Leafe wrote:
> In the past year or so, has there been anything that made you think “I wish 
> the TC would do something about that!” ? If so, what was it, and what would 
> you have wanted the TC to do about it?
>
> -- Ed Leafe
>
>
>
>
>
>
> __
> 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

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] TC Candidates: what does an OpenStack user look like?

[Fei Long Wang]

We're on the same page. I was just not sure if I should go to far away
given we're even mixing all the 'users' now. And I think it's related to
the other point I mentioned in my candidacy:  Constellation. User could
be defined by user case, which is the constellation here composed by
different services.



On 13/10/17 12:43, Fox, Kevin M wrote:
> I slightly disagree. I think there are 3 sets of users not 2...
> Operators, Tenant Users, and Tenant Application Developers.
>
> Tenant Application Developers develop software that the Tenant Users
> deploy in their tenant.
>
> Most OpenStack developers consider the latter two to always be the
> same person. And it has made it very difficult to use for Tenant Users
> that aren't Tenant Application Developers to use OpenStack.
>
> Sometimes Tenant Users are pure ops, not devops. Sometimes they are
> not even traditional CS folks but physicists, biologists, etc.
>
> Thanks,
> Kevin
>
> --------
> *From:* Fei Long Wang [feil...@catalyst.net.nz]
> *Sent:* Thursday, October 12, 2017 4:16 PM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* Re: [openstack-dev] [all][tc] TC Candidates: what does an
> OpenStack user look like?
>
> That's one of the points I mentioned in my candidacy: whom we're
> building the software for. As a service maintainer and upstream
> developer of a public cloud based on OpenStack, I would say some times
> we're mixing the term 'users'. The user in OpenStack world includes
> *operators* and *tenant users* (developers or devops using the cloud).
> We have done a good job to get the feedback from operators with "user"
> survey, operators mailing list, etc. But we don't have a good way to
> hear the voices from those tenant users, including developers and
> devops. And that's very important for the near future of OpenStack.
>
>
> On 13/10/17 10:34, Emilien Macchi wrote:
>> Replying on top of Mohammed, since I like his answer and want to add
>> some comments.
>>
>> On Thu, Oct 12, 2017 at 12:07 PM, Mohammed Naser <mna...@vexxhost.com> wrote:
>> [...]
>>
>>> Ideally, I think that OpenStack should be targeted to become a core
>>> infrastructure tool that's part of organizations all around the world
>>> which can deliver both OpenStack-native services (think Nova for VMs,
>>> Cinder for block storage) and OpenStack-enabled services (think Magnum
>>> which deployed Kubernetes integrated with OpenStack, Sahara which
>>> deploys Big Data software integrated with Swift).
>>>
>>> This essentially makes OpenStack sit at the heart of the operations of
>>> every organization (ideally!).  It also translates well with
>>> OpenStack's goal of providing a unified set of APIs and interfaces
>>> which are always predictable to do the operations that you expect them
>>> to do.  With time, this will make OpenStack much more accessible, as
>>> it becomes very easy to interact with as any individuals move from one
>>> organization to another.
>> I agree a lot with Mohammed here. I also like to think we build
>> OpenStack to place it at the heart of all organizations consuming
>> infrastructure at any scale or any architecture.
>> It can be some pieces from OpenStack or a whole set of services
>> working together.
>> Also like he said, providing set of API, that are well known; I would
>> add "stable APIs" (see discussions with Glare / Glance) and ensure
>> some "perennity" for our end-users.
>>
>> Having talked with some users, some folks say "OpenStack becomes
>> boring and we like it". Pursuing the discussion, they like to have
>> long life API support and stability in how they operate. I think at a
>> TC level we need to make sure we can both innovate and maintain this
>> stability at a certain level.
>>
>> [...]
>
> -- 
> Cheers & Best regards,
> Feilong Wang (王飞龙)
> --
> Senior Cloud Software Engineer
> Tel: +64-48032246
> Email: flw...@catalyst.net.nz
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> -- 
>
>
> __
> 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

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)

Re: [openstack-dev] [all][tc] TC Candidates: what does an OpenStack user look like?

[Fei Long Wang]

That's one of the points I mentioned in my candidacy: whom we're
building the software for. As a service maintainer and upstream
developer of a public cloud based on OpenStack, I would say some times
we're mixing the term 'users'. The user in OpenStack world includes
*operators* and *tenant users* (developers or devops using the cloud).
We have done a good job to get the feedback from operators with "user"
survey, operators mailing list, etc. But we don't have a good way to
hear the voices from those tenant users, including developers and
devops. And that's very important for the near future of OpenStack.


On 13/10/17 10:34, Emilien Macchi wrote:
> Replying on top of Mohammed, since I like his answer and want to add
> some comments.
>
> On Thu, Oct 12, 2017 at 12:07 PM, Mohammed Naser  wrote:
> [...]
>
>> Ideally, I think that OpenStack should be targeted to become a core
>> infrastructure tool that's part of organizations all around the world
>> which can deliver both OpenStack-native services (think Nova for VMs,
>> Cinder for block storage) and OpenStack-enabled services (think Magnum
>> which deployed Kubernetes integrated with OpenStack, Sahara which
>> deploys Big Data software integrated with Swift).
>>
>> This essentially makes OpenStack sit at the heart of the operations of
>> every organization (ideally!).  It also translates well with
>> OpenStack's goal of providing a unified set of APIs and interfaces
>> which are always predictable to do the operations that you expect them
>> to do.  With time, this will make OpenStack much more accessible, as
>> it becomes very easy to interact with as any individuals move from one
>> organization to another.
> I agree a lot with Mohammed here. I also like to think we build
> OpenStack to place it at the heart of all organizations consuming
> infrastructure at any scale or any architecture.
> It can be some pieces from OpenStack or a whole set of services
> working together.
> Also like he said, providing set of API, that are well known; I would
> add "stable APIs" (see discussions with Glare / Glance) and ensure
> some "perennity" for our end-users.
>
> Having talked with some users, some folks say "OpenStack becomes
> boring and we like it". Pursuing the discussion, they like to have
> long life API support and stability in how they operate. I think at a
> TC level we need to make sure we can both innovate and maintain this
> stability at a certain level.
>
> [...]

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

__
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] Thanks for all the fish

[Fei Long Wang]

Thank you for all your hard work, Lana. Enjoy your new job.


On 11/10/17 13:34, Lana Brindley wrote:
> Hi everyone,
>
> As most of you know, I was caught up in the Rackspace layoffs that happened 
> earlier this year, and have been looking for work (in between knee surgery) 
> since then. Well, in good news for my bank account, I have now secured a new 
> job with a startup based here in Brisbane. The bad news is that, while it's 
> working on cool stuff and is likely to be at least partially open sourced at 
> some point, there's currently no scope for me to continue working on 
> OpenStack. Sadly, an OpenStack related position just did not come my way, 
> despite my best efforts.
>
> So, this is goodbye for now. I'm going to unsubscribe from the OpenStack 
> mailing lists, and resign my core positions, but you can still email me at 
> this address if you want to. Feel free to hit me up on LinkedIn or Twitter, 
> if that's your thing.
>
> I'm going to miss being part of the community we built here, and all the 
> fabulous people I've met over my OpenStack years. Keep being awesome, I'll be 
> cheering from the sidelines.
>
> Keep on Doc'ing :)
>
> Lana
>
>
>
> __
> 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

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 



signature.asc
Description: OpenPGP digital signature
__
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][QA][group-based-policy][zaqar][packaging_deb][fuel][networking-*] Marking <= mitaka EOL

[Fei Long Wang]

Hi Tony,

TBH, I have no idea what happened for Zaqar's Liberty. So I don't think
we need a liberty2. Thanks.


On 24/08/17 15:14, Tony Breeds wrote:
> Hello all,
> We have a number of old stable/* branches hanging around and I'd
> like to mark anything <= stable/mitaka as EOL.  I've highlighted a few
> projects on the subject line:
>
> QA: Are the older branches of grenade safe to go?  IIUC we don't use
> them as we don't do grenade testing on $oldest stable branch
> group-based-policy: In the past you've requested your old branches stay
> around Do you still need this?  Is there value in
> the *all* staying active?
> zaqar: I see that liberty was EOL and then reactivated do you still need
>liberty2?
> packaging_deb: As these repos have the $project origin using the
>standard series-eol tag doesn't make sense  for exaxple
>deb-nova gets a mitaka-eol from the nova repo.   So I've
>picked mitaka-eol-dpkg.
> fuel, networking-*: There are several entries for these projects groups
> so I'm calling them out here for attention.
>
> I'm proposing we do this removal during the PTG.  Once we've done the
> series based branches we can look at old versioned releases like
> stable/16.04 etc.
>
> It's hard to present the data in a clear way so given infra will be the
> ultimate actioners of this list I present this as a shell script:
>
> ---
> eol-branch.sh -- stable/essex essex-eol openstack/anvil
> eol-branch.sh -- stable/folsom folsom-eol openstack/anvil
> eol-branch.sh -- stable/grizzly grizzly-eol openstack/anvil
> eol-branch.sh -- stable/havana havana-eol openstack/openstack
> eol-branch.sh -- stable/icehouse icehouse-eol \
>  openstack/astara openstack/networking-brocade \
>  openstack/networking-cisco openstack/networking-mlnx \
>  openstack/networking-odl openstack/networking-plumgrid \
>  openstack/nova-solver-scheduler \
>  openstack/sahara-image-elements openstack/tricircle \
>  openstack/trio2o openstack/vmware-nsx
> eol-branch.sh -- stable/icehouse icehouse-eol-dpkg \
>  openstack/deb-networking-cisco \
>  openstack/deb-networking-mlnx openstack/deb-networking-odl
> eol-branch.sh -- stable/juno juno-eol \
>  openstack/astara openstack/astara-appliance \
>  openstack/astara-horizon openstack/astara-neutron \
>  openstack/group-based-policy \
>  openstack/group-based-policy-automation \
>  openstack/group-based-policy-ui openstack/mistral \
>  openstack/mistral-dashboard openstack/mistral-extra \
>  openstack/networking-bigswitch \
>  openstack/networking-brocade openstack/networking-cisco \
>  openstack/networking-mlnx openstack/networking-odl \
>  openstack/networking-plumgrid \
>  openstack/nova-solver-scheduler \
>  openstack/openstack-resource-agents \
>  openstack/powervc-driver openstack/proliantutils \
>  openstack/puppet-n1k-vsm openstack/puppet-vswitch \
>  openstack/python-group-based-policy-client \
>  openstack/python-mistralclient \
>  openstack/python-muranoclient openstack/vmware-nsx
> eol-branch.sh -- stable/juno juno-eol-dpkg \
>  openstack/deb-mistral openstack/deb-networking-cisco \
>  openstack/deb-networking-mlnx openstack/deb-networking-odl \
>  openstack/deb-python-mistralclient \
>  openstack/deb-python-muranoclient \
>  openstack/deb-python-proliantutils
> eol-branch.sh -- stable/kilo kilo-eol \
>  openstack-dev/grenade openstack/murano-apps \
>  openstack/networking-h3c openstack/requirements
> eol-branch.sh -- stable/kilo kilo-eol1 \
>  openstack/group-based-policy \
>  openstack/group-based-policy-automation \
>  openstack/group-based-policy-ui \
>  openstack/python-group-based-policy-client
> eol-branch.sh -- stable/kilo_v2 kilo_v2-eol openstack/networking-bigswitch
> eol-branch.sh -- stable/liberty liberty-eol \
>  openstack-dev/grenade openstack/ceilometer-powervm \
>  openstack/ceilometer-zvm openstack/ceilometermiddleware \
>  openstack/fuel-plugin-calico openstack/group-based-policy \
>  openstack/group-based-policy-automation \
>  openstack/group-based-policy-ui openstack/mistral-extra \
>  openstack/networking-infoblox openstack/networking-powervm \
>  openstack/networking-zvm openstack/nova-powervm \
>  openstack/nova-zvm-virt-driver \
>  

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Fei Long Wang]

I agree with Zane for most of the parts. But one thing I don't really
understand is, why OpenStack community is still confusing at the IaaS,
PaaS and SaaS, does the classification really mater at nowadays? Do we
really need a label/tag for OpenStack to limit it as an IaaS, PaaS or
SaaS? I never see AWS says it's an IaaS, PaaS or SaaS. Did Azure or
Google Cloud say that? I think they're just providing the service their
customer want.


On 14/07/17 05:03, Zane Bitter wrote:
> On 29/06/17 10:55, Monty Taylor wrote:
>> (Incidentally, I think it's unworkable to have an IaaS without DNS.
>> Other people have told me that having an IaaS without LBaaS or a
>> message queuing service is unworkable, while I neither need nor want
>> either of those things from my IaaS - they seem like PaaS components
>> to me)
>
> I resemble that remark, so maybe it's worth clarifying how I see things.
>
> In many ways the NIST definitions of SaaS/PaaS/IaaS from 2011, while
> helpful to cut through the vagueness of the 'cloud' buzzword and frame
> the broad outlines of cloud service models (at least at the time),
> have proven inadequate to describe the subtlety of the various
> possible offerings. The only thing that is crystal clear is that LBaaS
> and message queuing are not PaaS components ;)
>
> I'd like to suggest that the 'Platform' in PaaS means the same thing
> that it has since at least the '90s: the Operating System and possibly
> there language runtime if any. The difference between PaaS and IaaS in
> terms of compute is that in the latter case you're given a machine and
> you install whatever platform you like on it, while in the former the
> platform is provided as a service. Hence the name.
>
> To the extent that hardware load balancers are used, LBaaS is pretty
> clearly IaaS. Hardware is infrastructure, if you provide access to
> that as a service it's Infrastructure as a Service. QED. It's also
> possible to provide software load balancers as a service. Technically
> I guess this is SaaS. Theoretically you could make an argument that an
> API that can abstract over either hardware or software load balancers
> is not "real" IaaS. And I would label that argument as BS sophistry :)
>
> The fact that PaaS implementations use load balancers internally is
> really neither here nor there.
>
> You can certainly build a useful cloud without LBaaS. That just means
> that anybody who needs load balancing will have to spin up their own
> software load balancer to do it. But that has a couple of
> consequences. One is that every application developer has to build
> their own orchestration to update the load balancer configuration when
> it needs to change. The other is that they're stuck with the least
> common denominator - if you use one cloud that doesn't have an LBaaS
> API, even one backed by software load balancers, then you won't be
> able to take advantage of hardware load balancers on another cloud
> without rewriting a chunk of your application. That's a big concern
> for OpenStack, which has application portability as one of its
> foremost goals. Thus an IaaS cloud that includes LBaaS is considerably
> more valuable than one that does not, for a large range of very common
> use cases.
>
> This is pretty much the same argument as I would make for DNSaaS.
> Without it you're developing your own orchestration and/or manually
> updating stuff every time you make a change in your infrastructure,
> which pretty much negates the benefits of IaaS for a very large subset
> of applications and leaves you stuck back in the pre-aaS days where
> making any changes to where your application ran was slow and painful.
> That's despite the fact that DNSaaS is arguably pure SaaS. This is
> where the NIST model breaks down IMHO. We tend to assume that only
> stuff that faces end users is SaaS and therefore everything
> developer-facing has to fall into either IaaS/PaaS. This results in
> IaaS developers treating "PaaS" as a catch-all bucket for "everything
> application developer-facing that I don't think is infrastructure",
> rather than a term that has meaning in itself.
>
> This confusion leads to the implicit argument that these kinds of
> developer-facing SaaS offerings are only useful to applications
> running in a PaaS, and therefore should be Someone Else's Problem,
> which is WRONG. It's wrong because different parts of an application
> have different needs. Just because I need to tweak the kernel
> parameters on my app server, it doesn't follow that I need to tweak
> the kernel parameters on my load balancer, or my database, too. It
> just doesn't.
>
> At one level, a message queue falls into the same bucket as other SaaS
> components (like DBaaS, sometimes LBaaS, ). Something that's useful
> to a subset of applications running in either an IaaS or a PaaS. The
> subset of applications that would use it is probably quite a bit
> smaller than the subset that would use e.g. LBaaS.
>
> However, there's also another dimension to 

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

[Fei Long Wang]

On 20/06/17 12:56, Curtis wrote:
> On Sun, Jun 18, 2017 at 5:35 AM, Amrith Kumar  wrote:
>> Trove has evolved rapidly over the past several years, since integration in
>> IceHouse when it only supported single instances of a few databases. Today
>> it supports a dozen databases including clusters and replication.
>>
>> The user survey [1] indicates that while there is strong interest in the
>> project, there are few large production deployments that are known of (by
>> the development team).
>>
>> Recent changes in the OpenStack community at large (company realignments,
>> acquisitions, layoffs) and the Trove community in particular, coupled with a
>> mounting burden of technical debt have prompted me to make this proposal to
>> re-architect Trove.
>>
>> This email summarizes several of the issues that face the project, both
>> structurally and architecturally. This email does not claim to include a
>> detailed specification for what the new Trove would look like, merely the
>> recommendation that the community should come together and develop one so
>> that the project can be sustainable and useful to those who wish to use it
>> in the future.
>>
>> TL;DR
>>
>> Trove, with support for a dozen or so databases today, finds itself in a
>> bind because there are few developers, and a code-base with a significant
>> amount of technical debt.
>>
>> Some architectural choices which the team made over the years have
>> consequences which make the project less than ideal for deployers.
>>
>> Given that there are no major production deployments of Trove at present,
>> this provides us an opportunity to reset the project, learn from our v1 and
>> come up with a strong v2.
>>
>> An important aspect of making this proposal work is that we seek to
>> eliminate the effort (planning, and coding) involved in migrating existing
>> Trove v1 deployments to the proposed Trove v2. Effectively, with work
>> beginning on Trove v2 as proposed here, Trove v1 as released with Pike will
>> be marked as deprecated and users will have to migrate to Trove v2 when it
>> becomes available.
>>
>> While I would very much like to continue to support the users on Trove v1
>> through this transition, the simple fact is that absent community
>> participation this will be impossible. Furthermore, given that there are no
>> production deployments of Trove at this time, it seems pointless to build
>> that upgrade path from Trove v1 to Trove v2; it would be the proverbial
>> bridge from nowhere.
>>
>> This (previous) statement is, I realize, contentious. There are those who
>> have told me that an upgrade path must be provided, and there are those who
>> have told me of unnamed deployments of Trove that would suffer. To this, all
>> I can say is that if an upgrade path is of value to you, then please commit
>> the development resources to participate in the community to make that
>> possible. But equally, preventing a v2 of Trove or delaying it will only
>> make the v1 that we have today less valuable.
>>
>> We have learned a lot from v1, and the hope is that we can address that in
>> v2. Some of the more significant things that I have learned are:
>>
>> - We should adopt a versioned front-end API from the very beginning; making
>> the REST API versioned is not a ‘v2 feature’
>>
>> - A guest agent running on a tenant instance, with connectivity to a shared
>> management message bus is a security loophole; encrypting traffic,
>> per-tenant-passwords, and any other scheme is merely lipstick on a security
>> hole
>>
>> - Reliance on Nova for compute resources is fine, but dependence on Nova VM
>> specific capabilities (like instance rebuild) is not; it makes things like
>> containers or bare-metal second class citizens
>>
>> - A fair portion of what Trove does is resource orchestration; don’t
>> reinvent the wheel, there’s Heat for that. Admittedly, Heat wasn’t as far
>> along when Trove got started but that’s not the case today and we have an
>> opportunity to fix that now
>>
>> - A similarly significant portion of what Trove does is to implement a
>> state-machine that will perform specific workflows involved in implementing
>> database specific operations. This makes the Trove taskmanager a stateful
>> entity. Some of the operations could take a fair amount of time. This is a
>> serious architectural flaw
>>
>> - Tenants should not ever be able to directly interact with the underlying
>> storage and compute used by database instances; that should be the default
>> configuration, not an untested deployment alternative
>>
> As an operator I wouldn't run Trove as it is, unless I absolutely had to.
>
> I think it is a good idea to reboot the project. I really think the
> concept of "service VMs" should be a thing. I'm not sure where the
> OpenStack community has landed on that, my fault for not paying close
> attention, but we should be able to create VMs for a tenant that are
> not managed by the tenant but that could be 

Re: [openstack-dev] [qa][cinder][ceph] should Tempest tests the backend specific feature?

[Fei Long Wang]

On 04/05/17 15:01, Ghanshyam Mann wrote:
>
> On Wed, May 3, 2017 at 21:57 Andrea Frittoli
> > wrote:
>
> On Tue, May 2, 2017 at 2:41 PM Jordan Pittier
> >
> wrote:
>
> On Tue, May 2, 2017 at 7:42 AM, Ghanshyam Mann
> > wrote:
>
> In Cinder, there are many features/APIs which are backend
> specific and
> will return 405 or 501 if same is not implemented on any
> backend [1].
> If such tests are implemented in Tempest, then it will
> break some gate
> where that backend job is voting. like ceph job in
> glance_store gate.
>
> There been many such cases recently where ceph jobs were
> broken due to
> such tests and recently it is for force-delete backup
> feature[2].
> Reverting force-delete tests in [3]. To resolve such cases
> at some
> extend, Jon is going to add a white/black list of tests
> which can run
> on ceph job [4] depends on what all feature ceph
> implemented. But this
> does not resolve it completely due to many reason like
> 1. External use of Tempest become difficult where user
> needs to know
> what all tests to skip for which backend
> 2. Tempest tests become too specific to backend.
>
> Now there are few options to resolve this:
> 1. Tempest should not tests such API/feature which are backend
> specific like mentioned by api-ref like[1].
>
> So basically, if one of the 50 Cinder driver doesn't support a
> feature, we should never test that feature ? What about the 49
> other drivers ? If a feature exists and can be tested in the
> Gate (with whatever default config/driver is shipped) then I
> think we should test it.
>  
>
> 2. Tempest test can be disabled/skip based on backend. -
> This is not
> good idea as it increase config options and overhead of
> setting those.
>
> Using regex and blacklist, any 3rd party CI can skip any test
> based on the test ID. Without introducing a config flag.
> See: 
> https://github.com/openstack-infra/project-config/blob/1cea31f402b6b047cde203c12184b5392c90/jenkins/jobs/devstack-gate.yaml#L1871
>
>
> This way each 3rd party system has to maintain its own list, which
> has the advantage that
> different teams maintain their own list (which is nice from an
> ownership and scale pov).
>
> However I think such list of tests are not as re-usable as having
> a devstack plugin (or an
> ansible or puppet module) changing a few tempest config options. 
>
>
> Humm, I am little bit hesitate to go that way. For gate and CI it
> might be good solution but for production cloud testing it makes
> Tenpest difficult to use.
>
> If I use Tempest to test my cloud, few tests going to fail as those
> were not supported by cinder driver my cloud has or going to have. 
> I do not have any way to configure something so that test can be
> disabled. Instead I need to maintain list of tests to run or skip. And
> that list is not static, it grows dynamically. 
> This makes Tempest difficult to use. 
>
>

Agree. We (Catalyst Cloud based in NZ) are using Tempest as the
monitoring tool and CI/CD gate for our cloud. But we do have to maintain
a white list of test cases because there are some cases are not fitting
our cloud.

>
>
>  
>
> 3. Tempest test can verify behavior with if else condition
> as per
> backend. This is bad idea and lose the test strength.
>
> Yeah, that's bad. 
>
>
> IMO options 1 is better options. More feedback are welcome. 
>
>
> ..1
> 
> https://developer.openstack.org/api-ref/block-storage/v3/?expanded=force-delete-a-backup-detail#force-delete-a-backup
> ..2 https://bugs.launchpad.net/glance/+bug/1687538
> ..3 https://review.openstack.org/#/c/461625/
> ..4
> 
> http://lists.openstack.org/pipermail/openstack-dev/2017-April/115229.html
>
> -gmann
>
> 
> __
> 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

[Fei Long Wang]

+1 :)


On 29/04/17 16:05, Hongbin Lu wrote:
>
> Hi all,
>
>  
>
> I proposes a change of Zun’s core team memberships as below:
>
>  
>
> + Feng Shengqin (feng-shengqin)
>
> - Wang Feilong (flwang)
>
>  
>
> Feng Shengqin has contributed a lot to the Zun projects. Her
> contribution includes BPs, bug fixes, and reviews. In particular, she
> completed an essential BP and had a lot of accepted commits in Zun’s
> repositories. I think she is qualified for the core reviewer position.
> I would like to thank Wang Feilong for his interest to join the team
> when the project was found. I believe we are always friends regardless
> of his core membership.
>
>  
>
> By convention, 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.
>
>  
>
> 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

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

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

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

[Fei Long Wang]

Hi Kendall,

Yep， if you can help reserve a lunch slot, it would be great. Thanks.


On 28/03/17 05:36, Kendall Nelson wrote:
> Hello :)
>
> At this point we have a full list, but if you are interested in a
> lunch slot I can put Zaqar down for one of those unless some other
> project is willing to share their space/time?
>
> Thanks for the interest!
>
> -Kendall Nelson(diablo_rojo)
>
> On Tue, Mar 21, 2017 at 4:50 PM Fei Long Wang <feil...@catalyst.net.nz
> <mailto:feil...@catalyst.net.nz>> wrote:
>
> As far as I know, most of Zaqar team members won't be in Boston.
> But I will be there, so pls help put Zaqar on the list if there is
> one available. Thanks.
>
>
> On 16/03/17 07:20, Kendall Nelson wrote:
>> Hello All!
>>
>> As you may have seen in a previous thread [1] the Forum will
>> offer project on-boarding rooms! This idea is that these rooms
>> will provide a place for new contributors to a given project to
>> find out more about the project, people, and code base. The slots
>> will be spread out throughout the whole Summit and will be 90 min
>> long.
>>
>> We have a very limited slots available for interested projects so
>> it will be a first come first served process. Let me know if you
>> are interested and I will reserve a slot for you if there are
>> spots left.
>>
>> - Kendall Nelson (diablo_rojo)
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2017-March/113459.html
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> <mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> -- 
> Cheers & Best regards,
> Feilong Wang (王飞龙)
> --
> Senior Cloud Software Engineer
> Tel: +64-48032246 <tel:+64%204-803%202246>
> Email: flw...@catalyst.net.nz <mailto:flw...@catalyst.net.nz>
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> 
> -- 
>
> __
> 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
>

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

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

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

[Fei Long Wang]

As far as I know, most of Zaqar team members won't be in Boston. But I
will be there, so pls help put Zaqar on the list if there is one
available. Thanks.


On 16/03/17 07:20, Kendall Nelson wrote:
> Hello All!
>
> As you may have seen in a previous thread [1] the Forum will offer
> project on-boarding rooms! This idea is that these rooms will provide
> a place for new contributors to a given project to find out more about
> the project, people, and code base. The slots will be spread out
> throughout the whole Summit and will be 90 min long.
>
> We have a very limited slots available for interested projects so it
> will be a first come first served process. Let me know if you are
> interested and I will reserve a slot for you if there are spots left.
>
> - Kendall Nelson (diablo_rojo)
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2017-March/113459.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

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

__
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][all][designate] The way forward for Designate

[Fei Long Wang]

It would be nice to record this discussion/summary on an etherpad or
somewhere, because it's not just the problem for Designate, IMHO, many
other big tent projects are facing the same issue. Thanks.



On 22/02/17 09:25, Hayes, Graham wrote:
> For those that are interested, we will have an hour discussion about
> how designate can move forward tomorrow (wed 22nd) at the PTG.
>
> We will be in Savannah 3 @ 11:00 for an hour.
>
> Thanks,
>
> Graham
>
> On 09/02/2017 14:22, Hayes, Graham wrote:
>> The HTML version of this is here:
>> http://graham.hayes.ie/posts/openstack-designate-where-we-are/
>>
>> I have been asked a few times recently "What is the state of the Designate
>> project?", "How is Designate getting on?", and by people who know what is
>> happening "What are you going to do about Designate?".
>>
>> Needless to say, all of this is depressing to me, and the people that I have
>> worked with for the last number of years to make Designate a truly useful,
>> feature rich project.
>>
>> *TL;DR;* for this - Designate is not in a sustainable place.
>>
>> To start out - Designate has always been a small project. DNS does not have
>> massive *cool* appeal - its not shiny, pretty, or something you see on the
>> front page of HackerNews (unless it breaks - then oh boy do people
>> become DNS
>> experts).
>>
>> A line a previous PTL for the project used to use, and I have happily
>> robbed is
>> "DNS is like plumbing, no one cares about it until it breaks, and then
>> you are
>> standing knee deep in $expletive". (As an aside, that was the reason we
>> chose
>> the crocodile as our mascot - its basically a dinosaur, old as dirt, and
>> when
>> it bites it causes some serious complications).
>>
>> Unfortunately that comes over into the development of DNS products
>> sometimes.
>> DNSaaS is a check box on a tender response, an assumption.
>>
>> We were lucky in the beginning - we had 2 large(ish) public clouds that
>> needed
>> DNS services, and nothing currently existed in the eco-system, so we got
>> funding for a team from a few sources.
>>
>> We got a ton done in that period - we moved from a v1 API which was
>> synchronous to a new v2 async API, we massively increased the amount of DNS
>> servers we supported, and added new features.
>>
>> Unfortunately, this didn't last. Internal priorities within companies
>> sponsoring the development changed, and we started to shed contributors,
>> which
>> happens, however disappointing. Usually when this happens if a project is
>> important enough the community will pick up where the previous group
>> left off.
>>
>> We have yet to see many (meaningful) commits from the community though. We
>> have some great deployers who will file bugs, and if they can put up patch
>> sets - but they are (incredibly valuable and appreciated) tactical
>> contributions. A project cannot survive on them, and we are no exception.
>>
>> So where does that leave us? Let have a look at how many actual commits we
>> have had:
>>
>> Commits per cycle
>>
>>  +--+-+
>>  | Havana   | 172 |
>>  +--+-+
>>  | Icehouse | 165 |
>>  +--+-+
>>  | Juno | 254 |
>>  +--+-+
>>  | Kilo | 340 |
>>  +--+-+
>>  | Liberty  | 327 |
>>  +--+-+
>>  | Mitaka   | 246 |
>>  +--+-+
>>  | Newton   | 299 |
>>  +--+-+
>>  | Ocata| 98  |
>>  +--+-+
>>
>> Next cycle, we are going to have 2 community goals:
>>
>> * Control Plane API endpoints deployment via WSGI
>> * Python 3.5 functional testing
>>
>> We would have been actually OK for the tempest one - we were one of the
>> first
>> external repo based plug-ins with `designate-tempest-plugin`_
>>
>> For WSGI based APIs, this will be a chunk of work - due to our internal code
>> structure splitting out the API is going to be ... an issue. (and I think it
>> will be harder than most people expect - anyone using olso.service has
>> eventlet imported - I am not sure how that affects running in a WSGI server)
>>
>> Python 3.5 - I have no idea. We can't even run all our unit tests on python
>> 3.5, so I suspect getting functional testing may be an issue. And,
>> convincing
>> management that re-factoring parts of the code base due to "community goals"
>> or a future potential pay-off can be more difficult than it should.
>>
>>   http://graham.hayes.ie/images/oct-2016-projects-prod.jpg
>>
>> We now have a situation where the largest "non-core" project [1]_ in the
>> tent
>> has a tiny number of developers working on it. 42% of deployers are
>> evaluating
>> Designate, so we should see this start to increase.
>>
>> How did this happen?
>> 
>>
>> Like most situations, there is no single cause.
>>
>> Certainly there may have been fault on 

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

[Fei Long Wang]

Hi all,

There will be no meetings this week due to the PTG
(https://www.openstack.org/ptg/)

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] [zaqar] Zaqar logo files

[Fei Long Wang]

Hi team,

Here is the final version of Zaqar mascot.



 Forwarded Message 
Subject:Zaqar logo files
Date:   Mon, 13 Feb 2017 15:26:12 -0800
From:   Heidi Joy Tretheway <heidi...@openstack.org>
To:     Fei Long Wang <feil...@catalyst.net.nz>



Hi Fei Long, 

I’m excited to finally be able to share final project logo files with
you. Inside this folder, you’ll find full-color and one-color versions
of the logo, plus a mascot-only version, in EPS, JPG and PNG formats.
You can use them on presentations and wherever else you’d like to add
some team flair. 

https://www.dropbox.com/sh/6z7lw9f09yfkvtg/AAB5rTSchDMJae0sltTuf2zra?dl=0 

At the PWG, we’ll have stickers for your team of the mascot, plus
signage on your room. I’m especially excited for the project teams to
see all of the logos together as one group, because they work
beautifully together stylistically while making each project’s mark
distinctive. Feel free to share this with your team, and thanks to you
and to them for the hard work they put into reaching an agreement on the
mascot. Also feel free to direct any questions my way!


photo   

*Heidi Joy Tretheway*
Senior Marketing Manager, OpenStack Foundation
503 816 9769 <tel:503%20816%209769> | Skype: heidi.tretheway
<https://webapp.wisestamp.com/sig_iframe?origin=mac-mail_id=5499768844845056=0.9726545857097719#>
<http://linkedin.com/in/heiditretheway> <http://twitter.com/heiditretheway> 
<http://www.openstack.org/>




__
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] [glance] Propose Dharini Chandrasekar for Glance core

[Fei Long Wang]

+1


On 25/01/17 02:36, Brian Rosmaita wrote:
> I'd like to propose Dharini Chandrasekar (dharinic on IRC) for Glance
> core.  She has been an active reviewer and contributor to the Glance
> project during the Newton and Ocata cycles, has contributed to other
> OpenStack projects, and has represented Glance in some interactions with
> other project teams.  Additionally, she recently jumped in and saw
> through to completion a high priority feature for Newton when the
> original developer was unable to continue working on it.  Plus, she's
> willing to argue with me (and the other cores) about points of software
> engineering.  She will be a great addition to the Glance core reviewers
> team.
>
> If you have any concerns, please let me know.  I plan to add Dharini to
> the core list after this week's Glance meeting.
>
> 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

-- 
Cheers & Best regards,
FeiLong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


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

[Fei Long Wang]

Hi all,

I've had the pleasure of serving the Zaqar community as PTL for the past
three cycles, and I'd like to continue for Pike cycle, if you'll have me.

For Pike release, things I'd like to do:

1. Scalability
   A scalable service should be able to process increases in load
without obvious degradation of latency or availability. For Zaqar,
"load" can refer to various dimensions of usage:
   1) number of queues
   2) number of publishers
   3) number of subscribers
   4) number of messages
   5) size of messages
   6) rate of messages published or consumed
Luckily, we have merged the OSProfiler patch in Ocata, so it would be
nice to leverage it to do more benchmarks to improve above metrics.

2. Availability
   Fortunately, Zaqar has a simple architecture which makes keeping its
availability relatively easy. That said, we need to improve the
behaviors of Zaqar so that it can gracefully failing over in a way that
is unnoticeable to end users.

3. Latency
   Latency is a typical time-based measure for the performance of a
system. Obvious, Zaqar would like to minimize latency wherever possible.
There are two most important latency metrics I would like to improve in
Pike are:
   1) The amount of time to claim a message
   2) The amount of time to deliver a message from publisher Zaqar server
   3) The amount of time to deliver a message from Zaqar to subscriber

4. Encourage diversity in our Community
   We are still a small team needs to grow. I would like to encourage
more people, organizations to join Zaqar community to make sure we have
a good coverage.

It's a fantastic experience working with this amazing team and I know
without the dedication and hard work of everyone who has contributed to
Zaqar we can't make those success stories of Ocata happen. I would be
pleased to serve as PTL for another cycle and I'd appreciate your vote.

Thanks for your consideration!


-- 
Cheers & Best regards,
FeiLong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


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

[Fei Long Wang]

On 17/01/17 13:00, Fox, Kevin M wrote:
> Your right, it is not what the big tent was about, but the big tent had some 
> unintended side affects. The list, as you stated:
>
> * No longer having a formal incubation and graduation period/review for
> applying projects
> * Having a single, objective list of requirements and responsibilities
> for inclusion into the OpenStack development community
> * Specifically allowing competition of different source projects in the
> same "space" (e.g. deployment or metrics)
>
> Turned into (my opinion):
>
> #1, projects, having a formal incubation/graduation period had the 
> opportunity to get feedback on what they could do to better integrate with 
> other projects and were strongly encouraged to do so to make progress towards 
> graduation. Without the formality, no one tended to bother.
>
> #2, Not having a single, objective list of requirements/responsibility: I 
> believe not having a list made folks take a hard look at what other projects 
> were doing and try harder to play nice in order to get graduated or risk the 
> unknown of folks coming back over and over and telling them more integration 
> was required.
>
> #3, the benefits/drawbacks of specifically allowing competition is rather 
> hard to predict. It can encourage alternate solutions to be created and 
> create a place where better ideas can overcome less good ideas. But it also 
> removes pressure to cooperate on one project rather then just take the 
> sometimes much easier route of just doing it yourself in your own project.
>
> I'm not blaming the big tent for all the ills of the OpenStack world. It has 
> had some real benefits. This problem is something bigger then the big tent. 
> It preexisted the tent. The direction the pressure to share was very 
> unidirectional pre big tent, applied to new projects much more then old 
> projects.
>
> But, I'm just saying the Big Tent had an (unintended) net negative affect 
> making this particular problem worse.
>
> Looking at the why of a problem is one of the important steps to formulating 
> a solution. OpenStack no longer has the amount of tooling to help elevate the 
> issue it had under the time before the Big Tent. Nothing has come up since to 
> replace it.
>
> I'm not stating that the big tent should be abolished and we go back to the 
> way things were. But I also know the status quo is not working either. How do 
> we fix this? Anyone have any thoughts? 

Could we create a new tag (at
https://governance.openstack.org/tc/reference/tags/) to indicate the
project is trusted to be integrated. Then, if there is a existing
project want to use a feature in the trusted-integrated project, then no
new wheel. To be more clear, the integration is a force integration.
Look at this list, https://www.openstack.org/software/project-navigator/
most of the projects has been developed more than 3 years,
unfortunately, they're not trusted, on the contrary, sometimes we're
brave to use some 3rd party library very new. That's a little ironic.

>
> Thanks,
> Kevin
> 
> From: Jay Pipes [jaypi...@gmail.com]
> Sent: Monday, January 16, 2017 1:57 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all] [barbican] [security] Why are projects 
> trying to avoid Barbican, still?
>
> On 01/16/2017 04:09 PM, Fox, Kevin M wrote:
>> If the developers that had issue with the lack of functionality,
>> contributed to Barbican rather then go off on their own, the problem
>>  would have been solved much more quickly. The lack of sharing means
>>  the problems don't get fixed as fast.
> Agreed completely.
>
>> As for operators, If the more common projects all started depending
>> on it, it would be commonly deployed.
> Also agreed.
>
>> Would the operators deploy Barbican just for Magnum? maybe not. maybe
>> so. For Magnum, Ironic, and Sahara, more likely . Would they deploy
>> it if Neutron and Keystone depended on it, yeah. they would. And then
>> all the other projects would benefit from it being there, such as
>> Magnum.
> Totally agreed.
>
>  > The sooner OpenStack as a whole can decide on some new core
>> components so that projects can start hard depending on them, the
>> better I think. That process kind of stopped with the arrival of the
>> big tent.
> You are using a false equivalence again.
>
> As I've mentioned numerous times before on the mailing list, the Big
> Tent was NOT either of these things:
>
> * Expanding what the "core components" of OpenStack
> * Expanding the mission or scope of OpenStack
>
> What the Big Tent -- technically "Project Structure Reform" -- was about
> was actually the following:
>
> * No longer having a formal incubation and graduation period/review for
> applying projects
> * Having a single, objective list of requirements and responsibilities
> for inclusion into the OpenStack development community
> * Specifically allowing competition of different source projects in the
> same 

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Fei Long Wang]

On 17/01/17 10:09, Fox, Kevin M wrote:
> If the developers that had issue with the lack of functionality, contributed 
> to Barbican rather then go off on their own, the problem would have been 
> solved much more quickly. The lack of sharing means the problems don't get 
> fixed as fast.
>
> As for operators, If the more common projects all started depending on it, it 
> would be commonly deployed. Would the operators deploy Barbican just for 
> Magnum? maybe not. maybe so. For Magnum, Ironic, and Sahara, more likely . 
> Would they deploy it if Neutron and Keystone depended on it, yeah. they would.

IMHO, I think one of reasons is some projects just care the projects
themselves. They don't want to add any any dependency for the other
projects if they can. Though we know we should think this from higher
level, which can finally benefit OpenStack.  In other words, we only
care about if the project I'm working on can be adopted more widely. We
don't think this from the whole community's view. Big tent is making
things worse from this point of view. Most of the new non-core services
want more adoption, so any thing may impact their adoptions will be
removed from the list. As for core service, anything may impact their
existing positions will be removed from the list. It maybe correct from
the project's view, but it's not good from the OpenStack's view. For
example, if Nova or Neutron need a secret store, what are they going to
do? I'm sure Barbican will be a soft dep, just like Magnum did.

We're fear to let the projects end up depending on each other. I don't
think integration is wrong if the integration is made for good reasons.

> And then all the other projects would benefit from it being there, such as 
> Magnum. The sooner OpenStack as a whole can decide on some new core 
> components so that projects can start hard depending on them, the better I 
> think. That process kind of stopped with the arrival of the big tent.
>
> Thanks,
> Kevin
>
> 
> From: Adrian Otto [adrian.o...@rackspace.com]
> Sent: Monday, January 16, 2017 11:55 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all] [barbican] [security] Why are projects 
> trying to avoid Barbican, still?
>
>> On Jan 16, 2017, at 11:02 AM, Dave McCowan (dmccowan)  
>> wrote:
>>
>> On 1/16/17, 11:52 AM, "Ian Cordasco"  wrote:
>>
>>> -Original Message-
>>> From: Rob C 
>>> Reply: OpenStack Development Mailing List (not for usage questions)
>>> 
>>> Date: January 16, 2017 at 10:33:20
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> 
>>> Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
>>> projects trying to avoid Barbican, still?
>>>
 Thanks for raising this on the mailing list Ian, I too share some of
 your consternation regarding this issue.

 I think the main point has already been hit on, developers don't want to
 require that Barbican be deployed in order for their service to be
 used.

 The resulting spread of badly audited secret management code is pretty
 ugly and makes certifying OpenStack for some types of operation very
 difficult, simply listing where key management "happens" and what
 protocols are in use quickly becomes a non-trivial operation with some
 teams using hard coded values while others use configurable algorithms
 and no connection between any of them.

 In some ways I think that the castellan project was supposed to help
 address the issue. The castellan documentation[1] is a little sparse but
 my understanding is that it exists as an abstraction layer for
 key management, such that a service can just be set to use castellan,
 which in turn can be told to use either a local key-manager, provided by
 the project or Barbican when it is available.

 Perhaps a miss-step previously was that Barbican made no efforts to
 really provide a robust non-HSM mode of operation. An obvious contrast
 here is with Hashicorp Vault[2] which has garnered significant market
 share in key management because it's software-only* mode of operation is
 well documented, robust and cryptographically sound. I think that the
 lack of a sane non-HSM mode, has resulted in developers trying to create
 their own and contributed to the situation.
> Bingo!
>
 I'd be interested to know if development teams would be less concerned
 about requiring Barbican deployments, if it had a robust non-HSM
 (i.e software only) mode of operation. Lowering the cost of deployment
 for organisations that want sensible key management without the expense
 of deploying multi-site HSMs.

 * Vault supports HSM deployments also

 [1] 

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Fei Long Wang]

On 17/01/17 09:21, 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 doing 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. 
+ 100

As the PTL of Zaqar, I know some projects using agent are reluctant to
leverage Zaqar to resolve potential security/communication issues. As a
result, customer/deployer don't want to deploy the project. So that
said, a new dependency may make the deployment harder, but sometimes
without the support/benefit from the other services, that project may
won't be on the list unless you reimplement the wheel.

> My 2 cents.
> Kevin
>
> 
> From: Chris Friesen [chris.frie...@windriver.com]
> Sent: Monday, January 16, 2017 9:25 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all] [barbican] [security] Why are projects 
> trying to avoid Barbican, still?
>
> On 01/16/2017 10:31 AM, Rob C wrote:
>
>> I think the main point has already been hit on, developers don't want to
>> require that Barbican be deployed in order for their service to be
>> used.
> I think that this is a perfectly reasonable stance for developers to take.  As
> long as Barbican is an optional component, then making your service depend on 
> it
> has a good chance of limiting your potential install base.
>
> Given that, it seems like the ideal model from a security perspective would be
> to use Barbican if it's available at runtime, otherwise use something 
> else...but
> that has development and maintenance costs.
>
> Chris
>
> __
> 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

-- 
Cheers & Best regards,
FeiLong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 



__
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] [zaqar] Next meeting in 2017

[Fei Long Wang]

Hi team,

Due to most of the team members will be on vacation in the next couple
of weeks, so we will cancel the next 3 meetings. And the first meeting
of 2017 will be 10th of Jan.

And I also proposed the new meeting time based on our poll, see
https://review.openstack.org/411564 If the patch is merged before 10th
Jan, then we will follow the new meeting time. Thanks.

Merry Christmas and Happy New Year!

-- 
Cheers & Best regards,
FeiLong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] [glance] Propose Steve Lewis for Glance core

[Fei Long Wang]

+1 Steve has done a great job, nice to have him in the team.


On 14/12/16 11:05, Brian Rosmaita wrote:
> I'd like to propose Steve Lewis (stevelle on IRC) for Glance core.  Take
> a look at any of his reviews, and you can see that he's thorough and
> comprehensive in his reviewing.  He's knowledgeable about Python,
> Glance, and software engineering in general.  He's gained a lot of
> experience in various OpenStack projects (including experience as a core
> reviewer), and will be a great addition to the Glance core reviewers team.
>
> If you have any concerns, please let me know.  I plan to add Steve to
> the core list after this week's Glance meeting.
>
> 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

-- 
Cheers & Best regards,
FeiLong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] [zaqar] Zaqar's draft logo

[Fei Long Wang]

Hi team,

We have got the draft logo of Zaqar from foundation. Could you please 
reply if you have any comments? We need to return the feedback by this 
Friday, 11.11. Sorry for the late. Thanks.


Personally, the shape looks good. But I'm expecting a cooler colour :)



 Forwarded Message 
Subject:Your draft logo & a sneak peek
Date:   Wed, 19 Oct 2016 12:07:23 -0700
From:   Heidi Joy Tretheway <heidi...@openstack.org>
To:     Fei Long Wang <feil...@catalyst.net.nz>



Hi Fei Long,

We're excited to show you the draft version of your project logo, 
attached. We want to give you and your team a chance to see the mascot 
illustrations before we make them official, so we decided to make 
Barcelona the draft target, with final logos ready by the Project Team 
Gathering in Atlanta in February.


Our illustrators worked as fast as possible to draft nearly 60 logos, 
and we're thrilled to see how they work as a family. Here's a 50-second 
"sneak peek" at how they came together: https://youtu.be/JmMTCWyY8Y4


We welcome you to *share this logo with your team and discuss it in 
Barcelona*. We're very happy to take feedback on it if we've missed the 
mark. The style of the logos is consistent across projects, and we did 
our best to incorporate any special requests, such as an element of an 
animal that is especially important, or a reference to an old logo.


We ask that you don't start using this logo now since it's a draft. 
Here's *what you can expect for the final product*:


 * A horizontal version of the logo, including your mascot, project
   name and the words "An OpenStack Community project"
 * A square(ish) version of the logo, including all of the above
 * A mascot-only version of the logo
 * Stickers for all project teams distributed at the PTG
 * One piece of swag that incorporates all project mascots, such as a
   deck of playing cards, distributed at the PTG
 * All digital files will be available through the website


We know this is a busy time for you, so to take some of the burden of 
coordinating feedback off you, we made a feedback form*:* 
http://tinyurl.com/OSmascot You are also welcome to reach out to Heidi 
Joy directly with questions or concerns. Please provide *feedback by 
Friday, Nov. 11*, so that we can request revisions from the illustrators 
if needed. Or, if this logo looks great, just reply to this email and 
you don't need to take any further action.


Thank you!
Heidi Joy Tretheway - project lead
Todd Morey - creative lead

P.S. Here's an email that you can copy/paste to send to your team 
(remember to attach your logo from my email):


Hi team,
I just received a draft version of our project logo, using the mascot we 
selected together. A final version (and some cool swag) will be ready 
for us before the Project Team Gathering in February. Before they make 
our logo final, they want to be sure we're happy with our mascot.


We can discuss any concerns in Barcelona and you can also provide direct 
feedback to the designers: http://tinyurl.com/OSmascot Logo feedback is 
due Friday, Nov. 11. To get a sense of how ours stacks up to others, 
check out this sneak preview of several dozen draft logos from our 
community: https://youtu.be/JmMTCWyY8Y4



photo   

*Heidi Joy Tretheway*
Senior Marketing Manager, OpenStack Foundation
503 816 9769 <tel:503%20816%209769> | Skype: heidi.tretheway 
<https://webapp.wisestamp.com/sig_iframe?origin=mac-mail_id=5499768844845056=0.9726545857097719#>
<http://linkedin.com/in/heiditretheway> 
<http://twitter.com/heiditretheway> <http://www.openstack.org/>






__
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] [zaqar] Ocata Assignments

[Fei Long Wang]

Hi team,

I just drafted the assignments of Ocata cycle based on our discussion on 
Barcelona summit, see 
https://etherpad.openstack.org/p/ocata-zaqar-assignment Please feel free 
to add your comments. Thanks.


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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] [zaqar] Summary of Barcelona Design Summit

[Fei Long Wang]

Greetings,

Firstly, thank you for everyone joined Zaqar sessions at Barcelona 
summit. We definitely made some great progress for those working 
sessions. Here are the high level summary and those are basically our 
Ocata priorities. I may miss something so please feel free to 
comment/reply this mail.


Performance matters


We got some interests last cycle about deploying Zaqar as messaging 
service in public/private cloud. And performance is one of popular 
questions. Though we have a built-in benchmark tool, there is no way to 
diagnose when the performance can't the meet user's exception in a given 
deployed environment. Besides, there is no good way to grantee a new 
patch won't impact the performance. Hence we discussed this topic in summit.


For the first issue, the solution is osprofiler. The patches are already 
there[1], we just need some review and it would be great if we can merge 
them in Ocata-1.


For the second issue, we would like to introduce a new gate job which 
based on our built-in benchmark tool. The idea is comparing the 
performance before/after current patch.


Subscription confirmation
--

Xiyuan Wang and Hao Wang did a great job in last cycle about 
subscription confirmation. As a result, we have merged the webhook 
confirmation patches. In the design session, we reviewed the design of 
email part, which changed the original design a bit about how to set the 
external URL for confirmation page.


Swift storage driver
--

Based on current design, Zaqar relays on under layer storage backend to 
get the stability and scalability. For example, if you're using MongoDB, 
you have to enable the replicaset to get replicating messages. Since 
Swift has the native support of replication and it's deployment for most 
of the OpenStack environment. So it's would be great if Zaqar can 
support using Swift as the storage backend driver.


Purge queue
-

It's not a new blueprint but seems it's a good time to pick since we do 
have some users asking it. And the conclusion in the session is, the 
feature is safe and good to have. A spec will be posed soon which will 
mainly discuss what the API looks like and how to design it to avoid 
race condition issue.


Notification delivery policy
--

We didn't touch this topic due a stranger in this session. See below for 
more details.


Interest for real deployment
-

A cloud architect from Mirantis joined our design session to discuss 
about using Zaqar as the messaging queue service for their customer. In 
their requirement, purge queue and dead letter queue are on the list 
which are also on our road map. And we had a great discussion about the 
deployment architecture, especially how to get a great scalability.



Please contribute this thread to fill the points/things I missed or pop 
up in #openstack-zaqar channel directly with questions and suggestions.


[1] https://review.openstack.org/141356

--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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][zaqar][telemetry] Subscribing to events

[Fei Long Wang]

Firstly, thank you for bring this topic up, therve.

IMHO, there are some requirements can't be met(or need to be confirmed 
by Aodh team) by Aodh for this case.


1. Granularity
For Aodh event alarm, user can only define the alarm based on a 
particular event(Pls correct me). However, Personally I would like to 
see a flexible 'filter' for the notifications.


2. Content Format
The info/data forwarded by Aodh is alarm, not the original event. 
At here, I assume most of the users would like to see the original 
event, not the alarm.


And it triggers me another idea. Recently, I'm playing with 
Ceilometer/Aodh a lot. The idea is, let Panko support event filter 
before dispatching. Currently, Panko/Ceilometer is using two yaml files 
to define the event related options. We can still keep it and meanwhile 
adding a per tenant, persistent filter in DB as user's customized 
options. It won't break the backward compatibility. Julien, LiuSheng, 
does that make any sense? Thanks.



On 26/10/16 02:48, Thomas Herve wrote:

On Tue, Oct 25, 2016 at 12:12 AM, Zane Bitter <zbit...@redhat.com> wrote:

On 22/10/16 10:38, Thomas Herve wrote:

Hi all,

One of my long time goal since I started contributing to OpenStack is
to try to remove polling where I can. With Zaqar WebSocket support, we
now have a transport available for users to connect to, and where we
can push notifications. We already leveraged that in Heat [1], so that
you can manipulate a stack and you'll be notified when its status
changes.

Still, not everyone uses Heat, and under the hood it still polls for
you. We should be able to use the various notifications that projects
publish to push similar events. Ceilometer already consumes those
notifications and try to make them somewhat consumable [2].

The missing piece is something that bridges Ceilometer and Zaqar. I
wrote a small service [3] which provide a simple API, so that you can
say "Subscribe to those events and send them to this queue". The data
flow looks like this:

Service (Nova, Neutron) -> Notification -> Ceilometer -> Bridge ->
Zaqar -> User.

This way, you'll get a Zaqar message per event, with some filtering
done by the bridge service. It's far from being ideal, as the
notification format is a endless topic of conversation, but I hope
that if we start using it things will move further. I also hope I can
get some feedback on the approach.


Could you document what makes this different from
http://docs.openstack.org/developer/aodh/event-alarm.html? (I can think of
some ways, but it's not clear to me whether a separate service is the right
thing or if the existing Aodh event alarms can be modified to do what we
want.)

Asking the tough questions :). I don't know about the details, but
it's possible that since https://review.openstack.org/#/c/335289/ got
merged, you have the same possibilities nowadays. I'd need to test it,
in which case my service is not necessary anymore (though the other
questions still apply). But in terms of semantics, it feels a bit
weird to use alarming for continuous event retrieval.



--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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

[Fei Long Wang]

+1


On 20/10/16 16:59, Shuu Mutou wrote:
> +1 for both.
>
> Regards,
> Shu Muto
>
>> -Original Message-
>> From: Kumari, Madhuri [mailto:madhuri.kum...@intel.com]
>> Sent: Thursday, October 20, 2016 12:33 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> <openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [Zun] Propose a change of Zun core team
>>
>> +1 for both. Shubham will be a great addition to team.
>>
>>
>>
>> Thanks!
>>
>>
>>
>> Madhuri
>>
>>
>>
>> From: Hongbin Lu [mailto:hongbin...@huawei.com]
>> Sent: Thursday, October 20, 2016 2:49 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> <openstack-dev@lists.openstack.org>
>> Subject: [openstack-dev] [Zun] Propose a change of Zun core team
>>
>>
>>
>> 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
>> <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

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] [zaqar] Design Summit Schedule

[Fei Long Wang]

Hi All,

As we discussed, I've pushed the final design summit schedule[1][2] for 
Zaqar. Please take a look and let me know if there is anything we need 
to change to avoid conflicts.


[1] 
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Zaqar

[2] https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Zaqar

--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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] [zaqar] Meeting cancelled at 17th Oct

[Fei Long Wang]

Hi Team,

Since most of us maybe in travel to summit, so the meeting will be 
cancelled and let's meet at Barcelona.


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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] [ptl] code churn and questionable changes

[Fei Long Wang]

On 23/09/16 11:19, Lana Brindley wrote:

On 23/09/16 02:19, Amrith Kumar wrote:

Joshua,

I think Steve and you may be missing the point of my email. It *IS* because I 
want to be open and inviting that I even asked the question, and what I'm 
asking for is how to deal with it.

All Steve says is " The fact that a new-to-openstack contributor would make such and 
error doesn’t warrant such a negative response even if it a hassle for the various PTLs 
and core reviewer teams to deal with".

I'm not proposing a negative response, I'm asking how to deal with it.

What, for example, does one do if a patch is proposed virtually identically in 
a half dozen (or two dozen) projects by someone and is totally bat-shit crazy? 
Merely -1'ing it and offering to help in a private email is not really the 
answer. I've tried it.

We all have. And we keep doing it. And doing it again.


Having a file in the projects repo that talks about guidelines for 
contributions isn't it either. We have one of those. It is up to the 
contributor to read it; yes, I can keep pointing contributors to that but this 
is a systemic problem which I'm hoping to address.

It's only systemic in the sense that it's standard human behaviour. And I doubt 
you'll be able to fix that with some automation.


What does one do when a contributor continually proposes one line changes that 
fix typos in comments (yes, really). At some point, these changes (while 
absolutely, and unarguably valid) begin to be a drag on the community.

Coach. Train. Communicate.


What I'm asking for is something, something that may cross project boundaries, 
that will help bring contributors onto openstack, and rapidly bring them to the 
point where they are contributing at a level that materially benefits the 
project(s).

-amrith


Sounds like you're looking for a technical solution to a social problem.


Agree, it's not a technical problem. And as you know, most of them are 
new comers, normally, they just need more time to familiar with the 
rules or find a project they're interested in. I don't think an very 
experienced openstacker will enjoy proposing a lot of low-value patches.



You're the PTL. Make sure there's good documentation about expected behaviours, 
point to it when you decline a patch, and always be available for mentoring and 
coaching. Yes, you will teach people the 101 version of contributing a million 
times over, and you'll repeat yourself ad nauseum, often to the same people. 
It's called leadership.

If you have a truly toxic person in your midst (hint: these are rarely 
newcomers, you don't discover these people straight away, I've found), *then* 
you can do something to remove them from your community. Here's a good place to 
start: https://hypatia.ca/2016/06/21/no-more-rock-stars/

No one said leadership was easy.

L



__
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


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

__
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] [zaqar] PTL candidacy

[Fei Long Wang]

Hi all,

I've had the pleasure of serving the Zaqar community as PTL for the past 
two cycles, and I'd like to continue for Ocata cycle, if you'll have me.


For Ocata release, things I'd like to do:

1. Real-world deployment
   Puppet and Ansible Zaqar are ready. And we have got many interests 
for Zaqar's production deployment. Some of them are doing evaluation, so 
we need to support them in Ocata and try to make them happen.


2. Notification service
   We have partially landed the subscription confirmation feature in 
Newton, so let's get it done in Ocata. Notification delivery policy is 
another good one to have.


3. Collaboration with other OpenStack projects
   We did a great job in Newton to support trust subscriber, which 
means any OpenStack services can be used as a subscriber of Zaqar and 
being secured. And I believe there are some other projects could be 
benefited by Zaqar from their view. For example, the notification 
middleware of Swift, Zaqar's websocket transport for Searchlight/Horizon 
etc.


4. More contributors
   We got some new members joined the team in Newton. And some of them 
has been nominated as core reviewer who grew very fast. It's really 
awesome. In Ocata, I would like to encourage more people/organizations 
to join Zaqar community to make sure we have a good coverage.


It's a fantastic experience working with this amazing team and I know 
without the dedication and hard work of everyone who has contributed to 
Zaqar we can't make those success stories of Newton happen. I would be 
pleased to serve as PTL for another cycle and I'd appreciate your vote.


Thanks for your consideration!

--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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] [glance] [elections] Glance PTL non-candidacy

[Fei Long Wang]

Hi Nikhil,

Thanks for your hard work as Glance PTL, you did a great job. And happy 
to know you will still work in OpenStack, see you around ;)


On 12/09/16 18:08, Nikhil Komawar wrote:

Hi team,


Just wanted to share my decision for not running for PTL for Glance.
It's been great serving the community in this role however, there are
some personal and family matters that I need to attend to over the next
couple of months or so.


I think the Glance team has done great and we've quite a bunch of bright
developers who are helping push the project forward in the appropriate
direction. With Glare becoming separate project and Ocata being short
cycle, I anticipate the priorities being rather obvious to those who
have stayed in touch. I will be available to do the rightful handoff to
the incoming PTL (for Ocata) and update with Newton happenings once
we're done with a few important bugs that are being targeted for RC1.


I intend to stick around in Glance and related projects like
Searchlight, Glare, etc. However, I am planning to take a more hands on
role and see a few features through in Ocata.  Given more and more
glance-cores time sharing with other projects, I think we need some
throttle in our review system. So, I'd like to help any new developers
get their reviews up, that in turn will help the Glance community.


Last but not the least, I have thoroughly enjoyed working in this role
with all my fellow stackers, particularly glancers! So, a BIG thank you
for having worked with me in making Glance better over the last couple
of years.




--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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] [zaqar] Summit planning etherpad

[Fei Long Wang]

Hi team,

Here is the etherpad for planning summit sessions:
https://etherpad.openstack.org/p/zaqar-ocata-summit


NOTE: The sessions have been requested but not scheduled, so the actual
number maybe different.

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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][Higgins] Proposing Sudipta Biswas and Wenzhi Yu for Zun core reviewer team

[Fei Long Wang]

+1

On 12/08/16 19:22, taget wrote:


+1 for both, they would be great addition to zun team.

On 2016年08月12日 10:26, Yanyan Hu wrote:


Both Sudipta and Wenzhi have been actively contributing to the Zun 
project for a while. Sudipta provided helpful advice for the project 
roadmap and architecture design. Wenzhi consistently contributed high 
quality patches and insightful reviews. I think both of them are 
qualified to join the core team.






--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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] persistently single-vendor projects

[Fei Long Wang]

ong way) we got an agreement that not all the projects are equal.
However, we're always applying the same rules for every projects. That's
fine, actually my point is for those projects which are not *equal* as
Nova, Neutron or Cinder, it would be nice if we could give them more
time, more space, more support to help them grow. I would like to say
that again, OpenStack is a cloud ecosystem, the goal is not creating a
better VM-creator. Though it's not good if a project is single-vendor,
it's worse if we lost a useful service on the list, because we(at least
me) want to see a reasonable diversity for the service coverage.

> To me, one of the most important items is engaging with mentees from other
> programs. I see this also as a way to give back to the communities and
the rest
> of the world.
>
> Flavio
>
>
>
> __
> 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

- -- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
- --
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
- --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJXooNAAAoJED4ISAHkpt8cbjIH/1b0hwpkP4cyt841rCnfG5wS
apV5mcYXIcXJFc/pHUCxA4yJC3XtCU15rAOKT050MZ1osKydrE7Fv53uzGocPKP/
m9VonHWjmuPQfFWB5X0VGUP6a1LYXTTuFyAcOU5SoF03+I35MZ4Yzvjc5LLt6Ke5
wekxRu2jmnPN6Q/FBGgCLJ51hz3qnTi5nckDP2Y4seWQ4/1dpW+31V79AvSemCXA
Ky/+rQkHY4TlIt8QPAxM/mf+j9RckNwVLWFx729v/qVFpXsqz/udTp4W5cevrWRw
jGSmdPtxvnZuOiUvrt0pmP1H4z3Ok7oMbKzx4UU+dykemLifCcMYm0L33GqkI/8=
=bpro
-END PGP SIGNATURE-

__
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] How to create a image using http img file

[Fei Long Wang]

As the error said, you need to see the disk_format and container_format.
I haven't digged the code, but I think you should try to set the
container_format and disk_format when you create the image like this:

image = self.glance.images.create(name="myNewImage",
  
container_format='bare',
  
disk_format='raw',)

On 03/08/16 13:27, kris...@itri.org.tw wrote:
>
>
>
> refer to: glance client Python API v2
>
> http://docs.openstack.org/developer/python-glanceclient/ref/v2/images.html
>
>  
>
> *add_location*(/image_id/, /url/, /metadata/)
>
> Add a new location entry to an image’s list of locations.
>
> It is an error to add a URL that is already present in the list of
> locations.
>
> *Parameters:*
>
>   
>
> · *image_id* –ID of image to which the location is to be added.
>
> · *url* –URL of the location to add.
>
> · *metadata* –Metadata associated with the location.
>
> *Returns:*
>
>   
>
> The updated image
>
> ---
>
> #--source code--
>
> from glanceclient.v2.client import Client
>
> ……
>
> url = 'http:///ubuntu1604.qcow2'
>
> image = self.glance.images.create(name="myNewImage")
>
> self.glance.images.add_location(image.id, url, {})
>
> #--end
>
> ---
>
>  
>
> I am sure the images.create is work.
>
> I got image .id  ‘be416e4a-f266-4ad5-a62f-979242d23633’.
>
> I don’t Know which data should be assign to metadata.
>
> Then I got :
>
>  
>
> self.glance.images.add_location(image.id, url, {})
>
>   File "/usr/lib/python2.7/dist-packages/glanceclient/v2/images.py",
> line 311, in add_location
>
> self._send_image_update_request(image_id, add_patch)
>
>   File "/usr/lib/python2.7/dist-packages/glanceclient/v2/images.py",
> line 296, in _send_image_update_request
>
> self.http_client.patch(url, headers=hdrs, data=json.dumps(patch_body))
>
>   File "/usr/lib/python2.7/dist-packages/glanceclient/common/http.py",
> line 284, in patch
>
> return self._request('PATCH', url, **kwargs)
>
>   File "/usr/lib/python2.7/dist-packages/glanceclient/common/http.py",
> line 267, in _request
>
> resp, body_iter = self._handle_response(resp)
>
>   File "/usr/lib/python2.7/dist-packages/glanceclient/common/http.py",
> line 83, in _handle_response
>
> raise exc.from_response(resp, resp.content)
>
> HTTPBadRequest: 400 Bad Request: Properties disk_format,
> container_format must be set prior to saving data. (HTTP 400)
>
>  
>
> Best Regards,
>
> Kristen
>
>  
>
>
>
> --
> 本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內
> 容，並請銷毀此信件。 This email may contain confidential information.
> Please do not use or disclose it in any way and delete it if you are
> not the intended recipient.
>
>
> __
> 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

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

__
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] [zaqar] Mascot for Zaqar

[Fei Long Wang]

Hi Team,

Based on the initial proposals on etherpad, we have decided to go for
*Nightingale *or***Carrier Pigeon*, and we can use either of them which
is confirmed by Foundation. So let's do a final vote on
https://etherpad.openstack.org/p/zaqar-project-mascot Thanks for all
your support.

On 15/07/16 11:30, Fei Long Wang wrote:
> Not sure why the URL is wrong. Please use this
> https://etherpad.openstack.org/p/zaqar-project-mascot  Thanks.
>
> On 15/07/16 11:25, Fei Long Wang wrote:
>> Hi team,
>>
>> I've created an etherpad [1] to discuss mascots for Zaqar project.
>> Please input and vote. Thanks.
>>
>> [1] https://etherpad.openstack.org/p/zaqar-project-mascot
>> -- 
>> Cheers & Best regards,
>> Fei Long Wang (王飞龙)
>> --
>> Senior Cloud Software Engineer
>> Tel: +64-48032246
>> Email: flw...@catalyst.net.nz
>> Catalyst IT Limited
>> Level 6, Catalyst House, 150 Willis Street, Wellington
>> -- 
>>
>>
>> __
>> 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
>
> -- 
> Cheers & Best regards,
> Fei Long Wang (王飞龙)
> --
> Senior Cloud Software Engineer
> Tel: +64-48032246
> Email: flw...@catalyst.net.nz
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> -- 
>
>
> __
> 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

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

__
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][all] Big tent? (Related to Plugins for all)

[Fei Long Wang]

Thank you for making it more clear, Zane. I totally agree with you at here.

IMHO, as a cloud computing platform, it should be an ecosystem just like 
the others. That said, not only looking from bottom to top, but also 
looking from top to bottom. It should looks like an unified platform. In 
other words, we need to understand what are the app developer need. I'm 
sure except a good VM creation, they also need something else. To avoid 
it turns to be another chicken/egg problem, we could/should to eat our 
dog food, instead of just "waiting" a service get matured by itself, we 
could provide some support/help. Therefore, I think plugins for all 
could be a good start.


My 0.02

On 22/07/16 10:04, Zane Bitter wrote:

On 20/07/16 18:41, Clint Byrum wrote:

Excerpts from Fox, Kevin M's message of 2016-07-20 20:12:48 +:
And maybe this raises an interesting defininition mismatch in the 
conversation.


There is archetectural stuff like, do we support 7 different web 
frameworks, or do we standardize on flask... python vs go.




Yeah meh, that's developer centric implementation details and I think
not very interesting. To me the architectural questions are deeper. "How
do we do locking?", "How should we enable inter-process and inter-host
communication?", "How do we handle distributed transactions?" and "What
concurrency model should we use?".

Theres also the architectural stuff at the, what interactive surface 
do you expose to users/operators. How consistant is it. Does it have 
all the features, no matter where they are implemented to do work.


I believe this is the goal of the API-WG. But again, they're not there
to compel, they're there to advise, assist, and work. Ultimately, if an
API is created and is poor, like Linus, the community can definitely say
"No" and refuse to use that API.


No, the API-WG is pretty much just about coming up with standards for 
how individual REST APIs look. Kevin (IIUC) is talking about something 
at least as different from that as 'which web framework?' is from your 
list of architecture questions. It's questions like: How can 
applications running in the cloud authenticate themselves to the 
cloud? How can the user limit their authorisation to a minimal 
surface? How can the cloud notify applications of events? How can the 
user configure the cloud to respond to events without having to write 
their own service to process them? How should guest agents communicate 
with the cloud?


If we're not to end up with 20 different answers to the those 
questions, we'll need some cross-project co-ordination and part of 
that will involve depending on various projects for functionality 
instead of implementing multiple different one-off solutions. Pick an 
asynchronous message transport (Zaqar). Pick an event source 
(Ceilometer? Searchlight?). Maybe pick an event sink (just Mistral? or 
lots of sinks?).


So it's architecture, but it is in a sense "user-space" architecture, 
figuring out how services fit together into a cohesive whole, as 
opposed to the questions you're talking about which are more 
engineering-focused. I'd be very interested to know if you consider 
this stuff in scope for your architecture group or if you think it 
should have its own separate working group.


cheers,
Zane.

__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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] [zaqar] Mascot for Zaqar

[Fei Long Wang]

Not sure why the URL is wrong. Please use this 
https://etherpad.openstack.org/p/zaqar-project-mascot  Thanks.


On 15/07/16 11:25, Fei Long Wang wrote:

Hi team,

I've created an etherpad [1] to discuss mascots for Zaqar project. 
Please input and vote. Thanks.


[1] https://etherpad.openstack.org/p/zaqar-project-mascot
--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email:flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

__
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] [zaqar] Mascot for Zaqar

[Fei Long Wang]

Hi team,

I've created an etherpad [1] to discuss mascots for Zaqar project. 
Please input and vote. Thanks.


[1] https://etherpad.openstack.org/p/zaqar-project-mascot 
<https://etherpad.openstack.org/p/sahara-mascot>


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

__
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] [Zaqar] Nominate Thomas Herve for Zaqar core

[Fei Long Wang]

Hi team,

I would like to propose adding Thomas Herve(therve) for the Zaqar core 
team. TBH, I have drafted this mail about 6 months ago, the reason you 
see this mail until now is because I'm not sure if Thomas can dedicate 
his time on Zaqar(He is a very busy man). But as you see, I'm wrong. He 
continually contribute a lot of high quality patches for Zaqar[1] and a 
lot of inspiring comments for this project and team. I'm sure he would 
make excellent addition to the team. If no one objects, I'll proceed and 
add him  in a week from now.


[1] 
http://stackalytics.com/?module=zaqar-group=commits=all_id=therve 



--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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] [zaqar][zaqar-ui] Nomating Shu Muto for Zaqar-UI core

[Fei Long Wang]

+1 and thanks for all the great work.

On 08/06/16 08:27, Thai Q Tran wrote:


Hello all,

I am pleased to nominate Shu Muto to the Zaqar-UI core team. Shu's 
reviews are extremely thorough and his work exemplary. His expertise 
in angularJS, translation, and project infrastructure proved to be 
invaluable. His support and reviews has helped the project progressed. 
Combine with his strong understanding of the project, I believe his 
will help guide us in the right direction and allow us to keep our 
current pace.


Please vote +1 or -1 to the nomination.

Thanks,
Thai (tqtran)


__
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


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

__
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] Should we rename "Higgins"?

[Fei Long Wang]

read/ia3o3vz7mzmjxmcx
>>>>
>>>> And if project name issue will be fixed, I'd like to propose UI
>>>> subproject.
>>>>
>>>> Thanks,
>>>> Shu
>>>>
>>>>
>>>>
>>> __
>>> _
>>>> ___
>>>> 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
>>
>> __
>> 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

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] Proposing Eli Qiao to be a Higgins core

[Fei Long Wang]

+1

On 01/06/16 09:39, Hongbin Lu wrote:
>
> Hi team,
>
>  
>
> I wrote this email to propose Eli Qiao (taget-9) to be a Higgins core.
> Normally, the requirement to join the core team is to consistently
> contribute to the project for a certain period of time. However, given
> the fact that the project is new and the initial core team was formed
> based on a commitment, I am fine to propose a new core based on a
> strong commitment to contribute plus a few useful patches/reviews. In
> addition, Eli Qiao is currently a Magnum core and I believe his
> expertise will be an asset of Higgins team.
>
>  
>
> According to the OpenStack Governance process [1], we require a
> minimum of 4 +1 votes from existing Higgins core team 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, Eli is not able to join the
> core team and needs to wait 30 days to reapply.
>
>  
>
> The voting is open until Tuesday June 7st.
>
>  
>
> [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

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

__
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] [Mistral][Zaqar][Ceilometer][Searchlight] Triggering Mistral workflows from Zaqar messages

[Fei Long Wang]

m thing that I did *not* mention in the spec:
>>>>> there are
>>>>> both Zaqar notifications and Mistral actions for sending email and
>>>>> hitting
>>>>> webhooks. These are two of the hardest things for a cloud operator to
>>>>> secure. It would be highly advantageous if there were only _one_
>>>>> place in
>>>>> OpenStack where these were implemented. Either project would
>>>>> potentially
>>>>> work - Zaqar notifications could call a simple, operator defined
>>>>> workflow
>>>>> behind the scenes for email/webhook notifications; alternatively the
>>>>> Mistral
>>>>> email/webhook actions could drop a message on a Zaqar queue
>>>>> connected to
>>>>> a
>>>>> notification - although the former sounds easier to me. (And of
>>>>> course
>>>>> clouds with only one of the services available could fall back to the
>>>>> current plugins.) Something to think about for the future...
>>>>
>>>>
>>>> And you're forgetting about Aodh alarm notifications, which are
>>>> webhooks as well.
>>>
>>>
>>> Yeah, those just need to go away :) Aodh can already post the
>>> notifications
>>> to Zaqar instead, and hopefully we'll be able to migrate everything
>>> to that
>>> method over time.
>>>
>>>> Unfortunately, I think none of them do a
>>>> particularly great job in terms of robustness and security.
>>>
>>>
>>> Agree. The best you can do is still middling, and we're not there yet.
>>>
>>>> I
>>>> suggested moving away from doing webhook in Zaqar to Flavio in the
>>>> past, and I think he responded that he thought it was part of the core
>>>> functionality. It's hard to delegate such operations and create a
>>>> dependency on another project. Maybe we can start by creating some
>>>> library code.
>>>
>>>
>>> I guess that's a start, but if I were running a large public cloud I'd
>>> probably want to isolate this on its own network surrounded by some
>>> pretty
>>> custom firewalls. A library doesn't really help make that easier.
>>>
>>> cheers,
>>> Zane.
>>>
>>>
>>> __
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
>
> 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

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] [Zaqar] Nominate XiYuan Wang and Hao Wang for Zaqar core

[Fei Long Wang]

Hi team,

I would like to propose adding XiYuan Wang(wxy) and Hao Wang(wanghao) for the 
Zaqar core team. They have been awesome contributors since joining the Zaqar 
team about 6 months ago. And now they are currently the most active non-core 
reviewers on Zaqar projects for the last 90 days[1]. XiYuan has great technical 
expertise and contributed many high quality patches. Hao has got an good eye 
for review and contributed some wonderful patches. I'm sure they would make 
excellent addition to the team. If no one objects, I'll proceed and add them in 
a week from now.

[1]http://stackalytics.com/report/contribution/zaqar-group/90

--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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] [Mistral][Zaqar] Triggering Mistral workflows from Zaqar messages

[Fei Long Wang]

Hi Zane,

Generally, I think it's a very good idea just like I said in the IRC 
channel. I will review the spec and thank you for proposing it.


On 19/05/16 06:49, Zane Bitter wrote:
I've been lobbying the Mistral developers for $SUBJECT since, 
basically, forever.[1][2][3] I like to think after a couple of years I 
succeeded in changing their view on it from "crazy" to merely 
"unrealistic".[4] In the last few months I've had a couple of 
realisations though:


1) The 'pull' model I've been suggesting is the wrong one, 
architecturally speaking. It's asking Mistral to do too much to poll 
Zaqar queues.
2) A 'push' model is the correct architecture and it already exists in 
the form of Zaqar's Notifications, which suddenly makes this goal look 
very realistic indeed.


I've posted a Zaqar spec for this here:

https://review.openstack.org/#/c/318202/

Not being super familiar with either project myself, I think this 
needs close scrutiny from Mistral developers as well as Zaqar 
developers to make sure I haven't got any of the details wrong. I'd 
also welcome any volunteers interested in implementing this :)



One more long-term thing that I did *not* mention in the spec: there 
are both Zaqar notifications and Mistral actions for sending email and 
hitting webhooks. These are two of the hardest things for a cloud 
operator to secure. It would be highly advantageous if there were only 
_one_ place in OpenStack where these were implemented. Either project 
would potentially work - Zaqar notifications could call a simple, 
operator defined workflow behind the scenes for email/webhook 
notifications; alternatively the Mistral email/webhook actions could 
drop a message on a Zaqar queue connected to a notification - although 
the former sounds easier to me. (And of course clouds with only one of 
the services available could fall back to the current plugins.) 
Something to think about for the future...


cheers,
Zane.

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-April/062617.html
[2] 
http://lists.openstack.org/pipermail/openstack-dev/2015-May/063884.html

[3] Also in-person at every summit since at least Juno :)
[4] 
http://lists.openstack.org/pipermail/openstack-dev/2015-May/063904.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


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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] [zaqar] Zaqar weekly meeting time changed

[Fei Long Wang]

Hi team,

Based on our previous discussion, the weekly meeting time has been
changed. The new meeting time is as below. Thanks.

time:   18:00 UTC
day: Monday
irc:   openstack-meeting-3
frequency:  weekly
start_date: 20160516

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] [glance] [VMT] [Security] Proposal to add Brian Rosmaita to the glance-coresec team

[Fei Long Wang]

+1 for Brian

On 12/05/16 15:39, Nikhil Komawar wrote:
> Hello all,
>
> I would like to propose adding add Brian to the team. He has been doing
> great work on improving the Glance experience for user and operators and
> tying the threads with the security aspects of the service. He also
> brings in good perspective of running large scale glance deployment and
> the issues seen therein.
>
> Please cast your vote with +1, 0 or -1, or you can reply back to me.
>
> Thank you.
>

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] [Zaqar] Austin Design Summit Recap and Priorities in Newton

[Fei Long Wang]

Hi team,

Here is the summary of Zaqar Austin design summit. Please feel free to 
chime if there is anything I missed.


1. Subscription confirmation

Subscription need to be confirmed before zaqar sending notifications to 
them, now we're using patch https://review.openstack.org/284555 to track 
the spec. The feature is our 1st high priority of Newton.


On the design session, most of the time we were discussing about the 
email subscription case since the webhook case is relatively easy. We 
agreed to use POST to confirm a subscription instead of GET. And it's 
agreed to add a 'unsubscribe' support as well, which will be a link on 
the confirmation response web page. The page is not a part of Zaqar but 
provided by the cloud provider(We can provide a sample page in Zaqar 
tree). Generally, it's simple page that send an Ajax request to Zaqar to 
change the subscription state. Wang Hao and Wang Xiyuan from Huawei will 
lead this work in Newton.


2. Dead Letter Queue

Dead letter queue will be a great value-add for Zaqar. A dead letter 
queue is a queue which other queues can send messages to that based on 
the pre-defined rules. On the design session,
we agreed to use max claims as the threshold. The dead letter queue name 
and the max claims will be saved in the source queue's metadata. A new 
attribute would be added for message to save the max claims. So the idea 
is when user try to claim a message and exceed the max claims, then the 
message will be moved from the source queue to dead letter queue. 
Feilong(flwang) will drive this work in N release.


3. Delayed Queue

It's agreed to put delayed queue on a hold-on status until we can see a 
strong requirement from end user about this.


4. Notification Format Improvement

Currently, our notification format is very simple, which is keep the 
original message format forwarded by zaqar's notification service. And 
in this session, we discussed what are the new attributes we can add in 
favour of the notification consuming. We have added queue name to the 
notification and in Newtion, the message id will be added. Besides, we 
had a general agreement for leveraging oslo.versionedobject for 
notification to support versioned notification so that the zaqar server 
and client with different versions can work together perfectly. 
Eva(Eva-i) will continually work on this.


5. Pool group deprecation

 Unfortunately, we didn't work out a conclusion for this. 
Feilong(flwang) will follow up this with Flavio(flaper87) to figure out 
what we can do in Newton.


6. Docs

Docs is still the high priority in Newton for us though we didn't cover 
this topic in the design summit.  We have merged the configuration docs 
into docs.openstack.org in Mitaka. And in Newton, we will try to make 
install guide and API ref docs happen in Newton. Now Eva(Eva-i) is 
working on the install guide and Feilong(flwang) is working on the API 
ref doc.


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

__
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] [zaqar] Zaqar meeting cancelled this week

[Fei Long Wang]

Hi team,

We cancelled the meeting today as most of the team is either OOO or in vacation 
after summit. We may also cancel the next meeting if there is no topic raised. 
Thanks.

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] [zaqar] Newton Design Summit Session Schedule

[Fei Long Wang]

Hi team,

The schedule of Zaqar design summit sessions is up now [1]. Some of the
session descriptions might need a little bit polish, like adding
etherpad links, but this is the schedule at least. And I know the
schedule may conflict with yours for the summit tour, so please feel
free let me know so that we can work out a better plan. Thanks.

[1]
https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Zaqar%3A

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] [zaqar-ui][zaqar] Nominating Thai Tran for zaqar-ui core

[Fei Long Wang]

Hi team,

I would like to propose adding Thai Tran(tqtran) for the Zaqar UI core
team. Thai has done amazing work since the beginning of Zaqar UI project.
He is currently the most active contributor on Zaqar UI projects for
the last 90 days[1]. If no one objects, I'll proceed and add him in a week
from now.

[1] http://stackalytics.com/report/contribution/zaqar-ui/90

--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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] [zaqar] PTL candidacy

[Fei Long Wang]

Hi all,

I've had the pleasure of serving the Zaqar community as PTL for the
Mitaka cycle, and I'd like to continue for Newton cycle, if
you'll have me.

For Newton release, things I'd like to do:

1. Real-world deployment
   Puppet Zaqar is ready. Ansible Zaqar role is on the way. So we need 
to get

the ansible work done ASAP,  and then interlock and provide more support for
potential cloud providers who have shown interest for Zaqar.

2. Notification service
   We got notification service alive since Liberty and fixed several 
bugs in

Mitaka. But we do still have things to do to make it fully functioning.
Such as subscription confirm and more drivers, etc.

2. Docs
   The config reference doc has been done in Mitaka which is an fantastic
milestone. And in Newton, I would like to complete API reference document
and admin guide for Zaqar.

4. Collaboration with other OpenStack projects
   We did a great job in Mitaka for the integration with Aodh, Mistral and
Tripleo. And I believe there are some other projects could be benefited by
Zaqar. For example, the notification middleware of Swift, Zaqar's websocket
transport for Searchlight/Horizon etc.

5. Encourage diversity in our Community
   We got some new members joined the team in Mitaka. And one of them 
has been

nominated as core reviewer who grew very fast. It's really awesome. In
Newton, I would like to encourage more people/organizations to join Zaqar
community.

It's a fantastic experience working with this amazing team and I know 
without
the dedication and hard work of everyone who has contributed to Zaqar we 
can't

make those success stories of Mitaka happen. I would be pleased to serve
as PTL for another cycle and I'd appreciate your vote.

Thanks for your consideration!

Election patch is here: https://review.openstack.org/#/c/293196 
<https://review.openstack.org/#/c/293083/>


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

__
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] [glance] Glance Mitaka: Passing the torch

[Fei Long Wang]

 that done. Glance's v1 is not considered 
secure and
it must be deprecated. Let's do that as well. Glance's stability and 
security
has shown some weaknesses. Let's not ignore that. Working on new 
features is
always sexy. Working on the new cool stuff that other projects are 
doing might
seem like a must do task. I'd argue and say there's a time for 
everything and,
while Glance shares OpenStack's priorities, there are times where the 
project
needs to take a step back, put itself together again and start again. 
I don't
believe Glance has left that self-healing period and I'd like to urge 
the whole

community to keep this in mind.

To the new PTL
==

Listen! Listen to the things the OpenStack community has to say. 
Listen to the
things external folks have to say. Most importantly, listen to what 
the Glance
community has to say. Glance is not a playground for making random 
decisions. If
you listen to what the community has to say, it'll be easy enough to 
know what
to do and what the next steps are. However, you should be ready for 
making hard
decisions and you need to have the courage to do so. During the last 
elections,
I wrote a post[0] about what being a PTL means and I'd like to 
encourage you to

read it, even if you've done so already.

If you look at the goals we set for Glance during Mitaka and the 
results we
achieved, you'll soon notice what the priorities for the next cycle 
should be.
The community will help shaping those priorities but the baseline is 
there

already.

A great cycle is not measured on how many features the community is 
able to

implement. Therefore, I encourage you to not fall under the temptation of
approving as many specs as possible. It is *perfectly fine* to say no 
to specs
because they conflict with the project's priorities. The more specs 
the team
approves, the more code there will be, the more people the project 
will need to
complete the feature (code wise and review wise). Keep the release 
small, keep
it concise, keep it focused. It's extremely important to communicate 
the intent

of the release to the rest of the community. Do not forget Glance *is* a
critical piece of every cloud.

Glance's community is not formed by the core team. It's formed by 
every person
willing to dedicate time to the project either on reviews or code. 
Work with
them, encourage them. They *are* helping the project. Some folks 
simply don't
want to do reviews, that's fine. They are still helping with code and 
bug fixes.
Recognize that and make sure they feel part of the community because 
they are.
Expanding the core team is great as long as you can ensure folks in 
the team are
aligned with the team's priorities. Welcome new members and do it 
gradually.


One more thing, learn to delegate. During my time as a PTL, I relied 
on other
members as much as possible for keeping up with some tasks. For 
instance, Erno
Kuvaja helped immensely with releases and stable maintenance, Nikhil 
Komawar
kept the team updated about the cross-project initiatives, Stuart 
Mclaren,
Hemanth Makkapati and Brian Rosmaita worked with the vulnerability 
team on
security issues, etc. Thanks to all of them for their immense help and 
I do hope
you'll keep up at what you're doing :). In other words, burnout is 
real and you
gotta take care of yourself too. Work with the community, there's no 
need to
take everything on your shoulders as you might end up dropping some 
balls. When
folks don't show up on reviews and they don't share their opinions, do 
not give

those as granted. Find them and ask for it.

And please, I beg you, let's get rid of v1!

[0] http://blog.flaper87.com/post/something-about-being-a-ptl/

Thanks for reading this long email (or to at least have bothered to 
skip till

the end of it ;)
Flavio

P.S: I've posted this in my blog too: 
http://blog.flaper87.com/post/glance-mitaka-passing-the-torch

/


__
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


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

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

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

[Fei Long Wang]

On 10/03/16 06:26, Doug Hellmann wrote:
> It's time to start opening the stable branches for libraries. I've
> prepared a list of repositories and the proposed versions from which
> we will create stable/mitaka branches, and need each team to sign off on
> the versions. If you know you intend to release a bug fix version in
> the next couple of days, we can wait to avoid having to backport
> patches, but otherwise we should go ahead and create the branches.
>
> I will process each repository as I hear from the owning team.
>
> openstack/ceilometermiddleware 0.4.0
> openstack/django_openstack_auth 2.2.0
> openstack/glance_store 0.13.0
> openstack/ironic-lib 1.1.0
> openstack/keystoneauth 2.3.0
> openstack/keystonemiddleware 4.3.0
> openstack/os-brick 1.1.0
> openstack/os-client-config 1.16.0
> openstack/pycadf 2.1.0
> openstack/python-barbicanclient 4.0.0
> openstack/python-brick-cinderclient-ext 0.1.0
> openstack/python-ceilometerclient 2.3.0
> openstack/python-cinderclient 1.6.0
> openstack/cliff 2.0.0
> openstack/python-designateclient 2.0.0
> openstack/python-glanceclient 2.0.0
> openstack/python-heatclient 1.0.0
> openstack/python-ironic-inspector-client 1.5.0
> openstack/python-ironicclient 1.2.0
> openstack/python-keystoneclient 2.3.1
> openstack/python-manilaclient 1.8.0
> openstack/python-neutronclient 4.1.1
> openstack/python-novaclient 3.3.0
> openstack/python-saharaclient 0.13.0
> openstack/python-swiftclient 3.0.0
> openstack/python-troveclient 2.1.0
> openstack/python-zaqarclient 1.0.0
The zaqarclient looks good. Thanks, Doug.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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][zaqar][cloudkitty] Default ports list

[Fei Long Wang]

Hi all,

Yesterday I just found cloudkitty is using the same default port () 
which is used by Zaqar now. So I'm wondering if there is any rule/policy 
for those new services need to be aware. I googled but can't find 
anything about this. The only link I can find is 
http://docs.openstack.org/liberty/config-reference/content/firewalls-default-ports.html. 
So my question is should we document the default ports list on an 
official place given the big tent mode? Thanks.


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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] [Zaqar] Nominating Eva Balycheva for Zaqar core

[Fei Long Wang]

Hi all,

I would like to propose adding Eva Balycheva(Eva-i) for the Zaqar core
team. Eva has been an awesome contributor since joining the Zaqar team.
She is currently the most active non-core reviewer on Zaqar projects for
the last 90 days[1]. During this time, she's been contributing to many
different areas:

1. Websocket binary support
2. Zaqar Configuration Reference docs
3. Zaqar client
4. Zaqar benchmarking 

Eva has got an good eye for review and contributed a lot of wonderful
patches[2]. I think she would make an excellent addition to the team. If
no one objects, I'll proceed and add her in a week from now.

[1] http://stackalytics.com/report/contribution/zaqar-group/90
[2]
https://review.openstack.org/#/q/owner:ubershy%2540gmail.com+status:merged

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] Questions regarding image "location" and glanceclient behaviour ...

[Fei Long Wang]

specify a
> string like '{"url": "192.168.1.111/foo/bar
> <http://192.168.1.111/foo/bar>", "metadata": {}}' for there is
> no conversion from command line strings to python dicts nor is
> there any
> conversion from a simple URL string to a suitable location object.
>
> If I modify glanceclient.v2.images.Controller.create to
> convert the
> locations parameter from a URL string to the desired object
> then the
> request goes through to the glance server where it fails with
> a 403 error
> (Attribute 'locations' is reserved).
>
> So is this discrepancy between V1 & V2 deliberate (a feature
> :)) or is it a
> bug?
> 
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> <mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>     ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> <mailto:OpenStack-dev@lists.openstack.org>
> 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

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

__
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] [glance] Glance Core team additions/removals

[Fei Long Wang]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi team,

As you know, I'm working on Zaqar team as PTL in Mitaka and it's a
time-consuming work. So my focus shifted for a bit but I'm now trying to
balance my time. I'd rather stay in the team if there is still space :)
Thanks.

My recent code review:
http://stackalytics.com/report/contribution/glance-group/30
Glance DB-based quota: https://review.openstack.org/27  


On 27/01/16 03:41, Flavio Percoco wrote:
>
> Greetings,
>
> I'd like us to have one more core cleanup for this cycle:
>
> Additions:
>
> - Kairat Kushaev
> - Brian Rosmaita
>
> Both have done amazing reviews either on specs or code and I think
they both
> would be an awesome addition to the Glance team.
>
> Removals:
>
> - Alexander Tivelkov
> - Fei Long Wang
>
> Fei Long and Alexander are both part of the OpenStack community.
However, their
> focus and time has shifted from Glance and, as it stands right now, it
would
> make sense to have them both removed from the core team. This is not
related to
> their reviews per-se but just prioritization. I'd like to thank both,
Alexander
> and Fei Long, for their amazing contributions to the team. If you guys
want to
> come back to Glance, please, do ask. I'm sure the team will be happy
to have you
> on board again.
>
> To all other members of the community. Please, provide your feedback.
Unless
> someone objects, the above will be effective next Tuesday.
>
> Cheers,
> Flavio
>
>
>
> __
> 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

- -- 
Cheers & Best regards,
Fei Long Wang (???)
- --
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
- --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJWp+ZOAAoJEOshLRZu+ElUhwgH/RISV2JuhKCsBWKePexBLO5s
uNVLqyRzHYknCG+5nZ8CZMw1YglRe5WtiiyDTSaapHf2dUQmEsp9eXkU/3hjxeS+
uS4lpeqCg1c7PQKSZTfnk53XDNVj5dZMtNnYlV3iZ0TDuPRC7kK+5vD8dCgz38hj
C1+0girlMgMoXxx6/rJxRvtVrxxfTKcZK37ttrQkjZIxKhofMEHdFqIRj3j1EDOc
KsSed/UNqe3QSi0kb8eGiXN39MoxfbA326AcAzHPg+7doYIyzIkiJQHwlC6t0s/z
4iILWcqZ1W6RCtux8S37GkowVP5cPq6WKfy2hwCgoowa4dB+tKetdjkD3IKSsVc=
=1+am
-END PGP SIGNATURE-

__
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] [glance] allow a ranking mechanism for glance-api to order image locations

[Fei Long Wang]

Hi Jake,

Thanks for raising this topic. I'm really interested in it. I reviewed 
most of the locations patches of Glance, so drop my 2 cents about this. 
So firstly, I think it's a valid user case. As for the implementation, I 
think a spec-lite is enough, given it's just a driver for current 
location strategy. I haven't seen your code, so I'm not sure if your 
implementation is ok for upstreaming. But I would assume your code is a 
driver under 
https://github.com/openstack/glance/tree/master/glance/common/location_strategy 
and personally, I think the metadata of location is right way since the 
location URL can't provide clear and enough information for the ranking. 
We can discuss more on #openstack-glance channel. Cheers.


On 14/01/16 13:07, Jake Yip wrote:

Hi all,

I've recently ran across a constraint in glance-api while working with 
image locations. In essence, there is no way to customize ordering of 
image-locations other than the default location strategies, namely 
location_order and store_type [0]. It seems like a more generic method 
of ordering image locations is needed, IMHO.


Some background - We are in a multi-cell environment and each cell has 
it's own glance-api server. All images are stored in a global swift 
cluster. We would like glance to be able to fetch images from a local 
store, so that we can do COW for backends like RBD.


Unfortunately, none of the current location strategies works for us, 
as we might have multiple cells sharing the same backend. I've opened 
a bug / wishlist describing this issue [1]. I have also implemented 
code that allows us to achieve that based on image location metadata.


I am wondering anyone else have solved this before? I would like to 
hear your opinions on how we can achieve this, and whether ranking it 
by metadata is the way to go.


The current wishlist is now tracked as a spec-lite. Is this ok?

Regards,
Jake

[0] 
http://docs.openstack.org/liberty/config-reference/content/section_glance-api.conf.html

[1] https://bugs.launchpad.net/glance/+bug/1528453


__
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


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

__
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] status of distil?

[Fei Long Wang]

Hi Steve,

Thanks for the heads up. I just worked this out with AJaejer. The
.gitreview file has been updated and we will disable the CI job
temporarily. Please let me know if there is any question. Cheers.


On 14/12/15 22:01, Steve Martinelli wrote:
>
> While I was trying to submit patches for projects that had old
> keystoneclient references (distil was one of the projects), I noticed
> that there hasn't been much action on this project [0]. It's been a
> year since a commit [1], no releases [2], and I can't submit a patch
> since the .gitreview file doesn't point to review.openstack.org [3].
>
> Is distil alive?
>
> [0] https://github.com/openstack/distil
> [1] https://github.com/openstack/distil/commits/master
> [2] https://github.com/openstack/distil/releases
> [3] https://github.com/openstack/distil/blob/master/.gitreview
>
> thanks,
> stevemar
>

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

__
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] [glance] Add Ian Cordasco back into glance-core

[Fei Long Wang]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

+1 welcome back!

On 08/12/15 05:36, Flavio Percoco wrote:
> Greetings,
>
> Not long ago, Ian Cordasco, sent an email out stepping down from his
> core roles as he didn't have the time to dedicate to the project
> team's he was part of.
>
> Ian has contacted me mentioning that he's gotten clearance, and
> therefore, time to dedicate to Glance and other activities around our
> community (I'll let him expand on this and answer questions if there
> are).
>
> As it was mentioned in the "goodbye thread" - and because Ian knows
> Glance quite well already, including the processes we follow - I'd
> like to propose a fast-track addition for him to join the team again.
>
> Please, just like for every other folk volunteering for this role, do
> provide your feedback on this. If no rejections are made, I'll proceed
> to adding Ian back to our core team in a week from now.
>
> Cheers,
> Flavio
>
>
>
> __
> 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

- -- 
Cheers & Best regards,
Fei Long Wang (???)
- --
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
- --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJWZeU4AAoJEOshLRZu+ElU6T8H/A4qM3E6beqH6Rx9XQx0V05s
591vbIBp7wiOGuPv3phG5peYTCgE+ATUoEDO3bw1aT4xojgVmqskmYakyb5j6YJD
6PI8v63OpLakrJmM3hKH8fBoU9OotQVjqkoUIeO1L8k2GkOLVwDYZPUM7vpRAqn7
lY+eGOBVCSNxo+tgv3/eWuDSAyRPiw6FVnvyI1QcguSoFHY5psX4TEGnDBWcQnFi
zpKlMUs6rAXjog7OxCHTcCJMUHmCzvqnwOdlcAq04HByF0EEzCwKXLLulCwhNg/7
1g5I9zLmfo7t/6fXQtbv67GyMMS6WMf2cVnJXkvi6HCdNxzkRG1HD4FbK1Uy7YM=
=bQ32
-END PGP SIGNATURE-

__
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] [Zaqar] OpenStack Tokyo Summit Summary

[Fei Long Wang]

asn't been completed. For v2, we're stilling missing
>>> the support for subscription and signed URL.
>>>
>>> https://blueprints.launchpad.net/zaqar/+spec/finish-client-support-for-v1.1-features
>>>
>
> +1
>
>>> SqlAlchemy Migration
>>> -
>>>
>>> Now we're missing the db migration support for SqlAlchemy, the control
>>> plane driver. We will fix it in M as well.
>>>
>>> https://blueprints.launchpad.net/zaqar/+spec/sqlalchemy-migration
>>> <https://blueprints.launchpad.net/zaqar/+spec/sqlalchemy-migration>
>
> Would this just be the addition of alembic (how heat and other
> projects handle it)?
>
Basically, yes.
>>> Guys, please contribute this thread to fill the points/things I missed
>>> or pop up in #openstack-zaqar channel directly with questions and
>>> suggestions.
>>>
>>
>> __
>>
>> 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
>>
>

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] [Zaqar] OpenStack Tokyo Summit Summary

[Fei Long Wang]

Thanks, Doug. I will talk with Ceilometer team to see what we can do.

On 07/11/15 07:36, Doug Hellmann wrote:

Excerpts from Fei Long Wang's message of 2015-11-07 01:31:09 +1300:

Greetings,

Firstly, thank you for everyone joined Zaqar sessions at Tokyo summit.
We definitely made some great progress for those working sessions. Here
are the high level summary and those are basically our Mitaka
priorities. I may miss something so please feel free to comment/reply
this mail.

Sahara + Zaqar
-

We have a great discussion with Ethan Gafford from Sahara team. Sahara
team is happy to use Zaqar to fix some potential security issues. The
main user case will be covered in Mitaka is protecting tenant guest and
data from administrative user. So what Zaqar team needs to do in Mitaka
is completing the zaqar client function gaps for v2 to support signed
URL, which will be used by Sahara guest agent. Ethan will create a spec
in Sahara to track this work. This is a POC of what it'd look like to
have a guest agent in Sahara on top of Zaqar. The Sahara team has not
decided to use Zaqar yet but this would be the bases for that discussion.

Horizon + Zaqar
--

We used 1 horizon work session and 1 Zaqar work session to discuss this
topic. The main user case we would like to address is the async
notification so that Horizon won't have to poll the other OpenStack
components(e.g. Nova, Glance or Cinder) per second to get the latest
status. And I'm really happy to see we worked out a basic plan by
leveraging Zaqar's notification and websocket.

1. Implement a basic filter for Zaqar subscription, so that Zaqar can
decide if the message should be posted/forwarded to the subscriber when
there is a new message posted the queue. With this feature, Horizon will
only be notified by its interested notifications.

https://blueprints.launchpad.net/zaqar/+spec/suport-filter-for-subscription

2. Listen OpenStack notifications

We may need more discussion about this to make sure if it should be in
the scope of Zaqar's services. It could be separated process/service of
Zaqar to listen/collect interested notifications/messages and post them
in to particular Zaqar queues. It sounds very interesting and useful but
we need to define the scope carefully for sure.

The Telemetry team discussed splitting out the code in Ceilometer that
listens for notifications to make it a more generic service that accepts
plugins to process events. One such plugin might be an interface to
filter events and republish them to Zaqar, so if you're interested in
working on that you might want to coordinate with the Telemetry team to
avoid duplicating effort.



Pool Group and Flavor
-

Thanks MD MADEEM proposed this topic so that we have a chance to review
the design of pool, pool group and flavor. Now the pool group and flavor
has a 1:1 mapping relationship and the pool group and pool has a 1:n
mapping relationship. But end user don't know the existence of pool, so
flavor is the way for end user to select what kind of storage(based on
capabilities) he want to use. Since pool group can't provide more
information than flavor so it's not really necessary, so we decide to
deprecate/remove it in Mitaka. Given this is hidden from users (done
automatically by Zaqar), there won't be an impact on the end user and
the API backwards compatibility will be kept.

https://blueprints.launchpad.net/zaqar/+spec/deprecate-pool-group

Zaqar Client


Some function gaps need to be filled in Mitaka. Personally, I would rate
the client work as the 1st priority of M since it's very key for the
integration with other OpenStack components. For v1.1, the support for
pool and flavor hasn't been completed. For v2, we're stilling missing
the support for subscription and signed URL.

https://blueprints.launchpad.net/zaqar/+spec/finish-client-support-for-v1.1-features

SqlAlchemy Migration
-

Now we're missing the db migration support for SqlAlchemy, the control
plane driver. We will fix it in M as well.

https://blueprints.launchpad.net/zaqar/+spec/sqlalchemy-migration
<https://blueprints.launchpad.net/zaqar/+spec/sqlalchemy-migration>


Guys, please contribute this thread to fill the points/things I missed
or pop up in #openstack-zaqar channel directly with questions and
suggestions.


__
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


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, 

Re: [openstack-dev] [Zaqar] OpenStack Tokyo Summit Summary

[Fei Long Wang]

Sorry typo:  it should be 'pre-signed URL'

On 07/11/15 01:31, Fei Long Wang wrote:

Greetings,

Firstly, thank you for everyone joined Zaqar sessions at Tokyo summit. 
We definitely made some great progress for those working sessions. 
Here are the high level summary and those are basically our Mitaka 
priorities. I may miss something so please feel free to comment/reply 
this mail.


Sahara + Zaqar
-

We have a great discussion with Ethan Gafford from Sahara team. Sahara 
team is happy to use Zaqar to fix some potential security issues. The 
main user case will be covered in Mitaka is protecting tenant guest 
and data from administrative user. So what Zaqar team needs to do in 
Mitaka is completing the zaqar client function gaps for v2 to support 
pre-signed URL, which will be used by Sahara guest agent. Ethan will 
create a spec in Sahara to track this work. This is a POC of what it'd 
look like to have a guest agent in Sahara on top of Zaqar. The Sahara 
team has not decided to use Zaqar yet but this would be the bases for 
that discussion.


Horizon + Zaqar
--

We used 1 horizon work session and 1 Zaqar work session to discuss 
this topic. The main user case we would like to address is the async 
notification so that Horizon won't have to poll the other OpenStack 
components(e.g. Nova, Glance or Cinder) per second to get the latest 
status. And I'm really happy to see we worked out a basic plan by 
leveraging Zaqar's notification and websocket.


1. Implement a basic filter for Zaqar subscription, so that Zaqar can 
decide if the message should be posted/forwarded to the subscriber 
when there is a new message posted the queue. With this feature, 
Horizon will only be notified by its interested notifications.


https://blueprints.launchpad.net/zaqar/+spec/suport-filter-for-subscription

2. Listen OpenStack notifications

We may need more discussion about this to make sure if it should be in 
the scope of Zaqar's services. It could be separated process/service 
of Zaqar to listen/collect interested notifications/messages and post 
them in to particular Zaqar queues. It sounds very interesting and 
useful but we need to define the scope carefully for sure.



Pool Group and Flavor
-

Thanks MD MADEEM proposed this topic so that we have a chance to 
review the design of pool, pool group and flavor. Now the pool group 
and flavor has a 1:1 mapping relationship and the pool group and pool 
has a 1:n mapping relationship. But end user don't know the existence 
of pool, so flavor is the way for end user to select what kind of 
storage(based on capabilities) he want to use. Since pool group can't 
provide more information than flavor so it's not really necessary, so 
we decide to deprecate/remove it in Mitaka. Given this is hidden from 
users (done automatically by Zaqar), there won't be an impact on the 
end user and the API backwards compatibility will be kept.


https://blueprints.launchpad.net/zaqar/+spec/deprecate-pool-group

Zaqar Client


Some function gaps need to be filled in Mitaka. Personally, I would 
rate the client work as the 1st priority of M since it's very key for 
the integration with other OpenStack components. For v1.1, the support 
for pool and flavor hasn't been completed. For v2, we're stilling 
missing the support for subscription and pre-signed URL.


https://blueprints.launchpad.net/zaqar/+spec/finish-client-support-for-v1.1-features

SqlAlchemy Migration
-

Now we're missing the db migration support for SqlAlchemy, the control 
plane driver. We will fix it in M as well.


https://blueprints.launchpad.net/zaqar/+spec/sqlalchemy-migration


Guys, please contribute this thread to fill the points/things I missed 
or pop up in #openstack-zaqar channel directly with questions and 
suggestions.

--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email:flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

__
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] [Zaqar] OpenStack Tokyo Summit Summary

[Fei Long Wang]

Greetings,

Firstly, thank you for everyone joined Zaqar sessions at Tokyo summit. 
We definitely made some great progress for those working sessions. Here 
are the high level summary and those are basically our Mitaka 
priorities. I may miss something so please feel free to comment/reply 
this mail.


Sahara + Zaqar
-

We have a great discussion with Ethan Gafford from Sahara team. Sahara 
team is happy to use Zaqar to fix some potential security issues. The 
main user case will be covered in Mitaka is protecting tenant guest and 
data from administrative user. So what Zaqar team needs to do in Mitaka 
is completing the zaqar client function gaps for v2 to support signed 
URL, which will be used by Sahara guest agent. Ethan will create a spec 
in Sahara to track this work. This is a POC of what it'd look like to 
have a guest agent in Sahara on top of Zaqar. The Sahara team has not 
decided to use Zaqar yet but this would be the bases for that discussion.


Horizon + Zaqar
--

We used 1 horizon work session and 1 Zaqar work session to discuss this 
topic. The main user case we would like to address is the async 
notification so that Horizon won't have to poll the other OpenStack 
components(e.g. Nova, Glance or Cinder) per second to get the latest 
status. And I'm really happy to see we worked out a basic plan by 
leveraging Zaqar's notification and websocket.


1. Implement a basic filter for Zaqar subscription, so that Zaqar can 
decide if the message should be posted/forwarded to the subscriber when 
there is a new message posted the queue. With this feature, Horizon will 
only be notified by its interested notifications.


https://blueprints.launchpad.net/zaqar/+spec/suport-filter-for-subscription

2. Listen OpenStack notifications

We may need more discussion about this to make sure if it should be in 
the scope of Zaqar's services. It could be separated process/service of 
Zaqar to listen/collect interested notifications/messages and post them 
in to particular Zaqar queues. It sounds very interesting and useful but 
we need to define the scope carefully for sure.



Pool Group and Flavor
-

Thanks MD MADEEM proposed this topic so that we have a chance to review 
the design of pool, pool group and flavor. Now the pool group and flavor 
has a 1:1 mapping relationship and the pool group and pool has a 1:n 
mapping relationship. But end user don't know the existence of pool, so 
flavor is the way for end user to select what kind of storage(based on 
capabilities) he want to use. Since pool group can't provide more 
information than flavor so it's not really necessary, so we decide to 
deprecate/remove it in Mitaka. Given this is hidden from users (done 
automatically by Zaqar), there won't be an impact on the end user and 
the API backwards compatibility will be kept.


https://blueprints.launchpad.net/zaqar/+spec/deprecate-pool-group

Zaqar Client


Some function gaps need to be filled in Mitaka. Personally, I would rate 
the client work as the 1st priority of M since it's very key for the 
integration with other OpenStack components. For v1.1, the support for 
pool and flavor hasn't been completed. For v2, we're stilling missing 
the support for subscription and signed URL.


https://blueprints.launchpad.net/zaqar/+spec/finish-client-support-for-v1.1-features

SqlAlchemy Migration
-

Now we're missing the db migration support for SqlAlchemy, the control 
plane driver. We will fix it in M as well.


https://blueprints.launchpad.net/zaqar/+spec/sqlalchemy-migration 
<https://blueprints.launchpad.net/zaqar/+spec/sqlalchemy-migration>



Guys, please contribute this thread to fill the points/things I missed 
or pop up in #openstack-zaqar channel directly with questions and 
suggestions.


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

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

Re: [openstack-dev] [release] new change management tools and processes for stable/liberty and mitaka

[Fei Long Wang]

openstack.org/241344
[5] https://review.openstack.org/241343

__
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


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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] [Zaqar] No meeting until 9 Nov

[Fei Long Wang]

Hi everyone,

As we discussed in last meeting, we won't be holding our weekly meetings until 
after summit. Normal weekly meeting will resume on Nov 9. The time for the
meeting that week will be 21:00 UTC. Thanks.

--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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] [Zaqar] Design Summit Schedule

[Fei Long Wang]

Hi everyone,

I just posted the Zaqar schedule for design summit:

https://mitakadesignsummit.sched.org/overview/type/zaqar

Please let me know if there is any schedule conflicts for you, so we can work 
out it on next weekly meeting.

Session Leaders: Please fill the etherpad on 
https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Zaqar Thanks.

--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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] [Zaqar][Horizon] UI for pools and flavors

[Fei Long Wang]

On 12/10/15 20:36, Matthias Runge wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/10/15 09:25, Flavio Percoco wrote:

On 10/10/15 21:07 +0530, Shifali Agrawal wrote:

Greetings!

I have prepared mock-ups[1],[2] to build Zaqar UI, at present
focusing only to bring pools and flavors on dashboard. Sharing
two mock-ups for same purpose - allowing all operations related
to them(CRUD).

It will be great to know the views of zaqar developers/users if
the design is satisfactory to them or they want some amendments.
Also let me know if any information of pools/flavors is missing
and need to be added.

In first mockup[1] showing pools information by default and will
show flavors if user click on flavors button present on top
second menu bar.

[1]: http://tinyurl.com/o2b9q6r [2]: http://tinyurl.com/pqwgwhl

I'm adding `[horizon]` to the subject to get more folks'
attention.


Thank you for bringing this up!

maybe it's necessary to give a brief context for those mockups?
+1 For now, it would be nice if we can figure out where to hold the 
source code, a new dashboard project or in Horizon.

What does a pool here?
A pool is like a container to organize queues/messages. Admin can create 
many different pools based on their capabilities.

  why is a pool weighted (or how)
When there are many pools, the pool with higher weight will be selected 
to be posted messages.

and isn't a
pools and a pool group somehow the same?

Pool group is most like a group/container for group to organize groups.

If you have pools, what is the intention of flavors then?
Admin can create flavor based on pool group's capabilities. Then user 
can create queue based on pool group to leverage the advantage of the 
pool group. For example, there are two pool groups. One named 'fast 
storage' which contains pools: pool_A and pool_B, one named 'reliable 
storage' which contains pool_C and pool_D, then admin can create a 
flavor named 'fast_storage'. When user created a new queue and set the 
flavor with 'fast_storage', then the messages posted to the queue will 
be stored in pool_A and pool_B.

Just to ask the obvious questions here

Matthias

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWG2LZAAoJEBdpskgc9eOLSnYQAIFJb2/u5FWUkuk+mAVcRHXJ
nHD0oAN5fxmAR0fqZH57n0T7et8Ocp+Xgp9aUD9roLPGlj9uFnLntMSHo9WIAzU9
gq2fl0pgnmpMzwJ0yooAiMq4HXyJcG5UaY9xImTReTH4382x8j1OTVFvS+9ws+VU
enK4S/2JW4Rvf6jpYGUcoNqtdmkFRLQohvu/K3V1Cg1Y+zMeYIQZxb4oZzcEOEyo
6E+DicR/4VVGi8gl0UGPkXSmm/jFaG8H3m5KTvTQr0PDd6l5ypwDXvZcRKQvPYmc
c155EvjeXPByhm1jXpE6Cgv6NNROQFr+uRM1jKLF0Ss030XI7TSyMNYv9br6OVxi
/SMlF+BG+FK26uwTc9Mf5D5mqTF6qgbPTLLu4vlqKa3JX0/y7Z8a7NoujzTKUBEl
WAftY2ADAJE6Vb/1TEubujDIlKGBtoT/lGQUIJtj1t5VftfaNrZ1N2vMQ4P7c9hA
W2EoRCTe6m8YbPPT3b3QFuuH2oecPECTiWcjEgRxp23ksnoFDkgjEGeM1+xNeQVV
kfwfG4mcGP4lEUwPk2sdL/3xu16iUTMJURZdvkqI1FX3YfMwITjiY/jdqIwVwlNF
03XhFn1uloXyHSNRNNFXf85r3v4FDw9FWQCeCU5mqOzkdZZafhvdi2tUjkHniGsG
mDyxERTHHiDOAqHUhLNn
=nLNP
-END PGP SIGNATURE-

__
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


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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] [Zaqar][Horizon] UI for pools and flavors

[Fei Long Wang]

On 12/10/15 20:36, Matthias Runge wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/10/15 09:25, Flavio Percoco wrote:

On 10/10/15 21:07 +0530, Shifali Agrawal wrote:

Greetings!

I have prepared mock-ups[1],[2] to build Zaqar UI, at present
focusing only to bring pools and flavors on dashboard. Sharing
two mock-ups for same purpose - allowing all operations related
to them(CRUD).

It will be great to know the views of zaqar developers/users if
the design is satisfactory to them or they want some amendments.
Also let me know if any information of pools/flavors is missing
and need to be added.

In first mockup[1] showing pools information by default and will
show flavors if user click on flavors button present on top
second menu bar.

[1]: http://tinyurl.com/o2b9q6r [2]: http://tinyurl.com/pqwgwhl

I'm adding `[horizon]` to the subject to get more folks'
attention.


Thank you for bringing this up!

maybe it's necessary to give a brief context for those mockups?
+1 For now, it would be nice if we can figure out where to hold the 
source code, a new dashboard project or in Horizon.

What does a pool here?
A pool is like a container to organize queues/messages. Admin can create 
many different pools based on their capabilities.

  why is a pool weighted (or how)
When there are many pools, the pool with higher weight will be selected 
to be posted messages.

and isn't a
pools and a pool group somehow the same?

Pool group is most like a group/container for group to organize groups.

If you have pools, what is the intention of flavors then?
Admin can create flavor based on pool group's capabilities. Then user 
can create queue based on pool group to leverage the advantage of the 
pool group. For example, there are two pool groups. One named 'fast 
storage' which contains pools: pool_A and pool_B, one named 'reliable 
storage' which contains pool_C and pool_D, then admin can create a 
flavor named 'fast_storage'. When user created a new queue and set the 
flavor with 'fast_storage', then the messages posted to the queue will 
be stored in pool_A and pool_B.

Just to ask the obvious questions here

Matthias

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWG2LZAAoJEBdpskgc9eOLSnYQAIFJb2/u5FWUkuk+mAVcRHXJ
nHD0oAN5fxmAR0fqZH57n0T7et8Ocp+Xgp9aUD9roLPGlj9uFnLntMSHo9WIAzU9
gq2fl0pgnmpMzwJ0yooAiMq4HXyJcG5UaY9xImTReTH4382x8j1OTVFvS+9ws+VU
enK4S/2JW4Rvf6jpYGUcoNqtdmkFRLQohvu/K3V1Cg1Y+zMeYIQZxb4oZzcEOEyo
6E+DicR/4VVGi8gl0UGPkXSmm/jFaG8H3m5KTvTQr0PDd6l5ypwDXvZcRKQvPYmc
c155EvjeXPByhm1jXpE6Cgv6NNROQFr+uRM1jKLF0Ss030XI7TSyMNYv9br6OVxi
/SMlF+BG+FK26uwTc9Mf5D5mqTF6qgbPTLLu4vlqKa3JX0/y7Z8a7NoujzTKUBEl
WAftY2ADAJE6Vb/1TEubujDIlKGBtoT/lGQUIJtj1t5VftfaNrZ1N2vMQ4P7c9hA
W2EoRCTe6m8YbPPT3b3QFuuH2oecPECTiWcjEgRxp23ksnoFDkgjEGeM1+xNeQVV
kfwfG4mcGP4lEUwPk2sdL/3xu16iUTMJURZdvkqI1FX3YfMwITjiY/jdqIwVwlNF
03XhFn1uloXyHSNRNNFXf85r3v4FDw9FWQCeCU5mqOzkdZZafhvdi2tUjkHniGsG
mDyxERTHHiDOAqHUhLNn
=nLNP
-END PGP SIGNATURE-

__
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


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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] [glance][nova] how to upgrade from v1 to v2?

[Fei Long Wang]

Thanks for raising this topic. I don't know why you think the 
images/snapshots created by v1 can't be accessed by v2. But I would say 
it's not true, see http://paste.openstack.org/show/473956/


Personally, I don't think there is any big blocker for this. What we 
need to do is working out a plan on the summit(Glance team have planned 
a design session for this). And meanwhile I'm going to split this 
https://review.openstack.org/#/c/144875/ to make it easier to review.



On 25/09/15 09:17, melanie witt wrote:

Hi All,

I have been looking and haven't yet located documentation about how to upgrade 
from glance v1 to glance v2.

 From what I understand, images and snapshots created with v1 can't be 
listed/accessed through the v2 api. Are there instructions about how to migrate 
images and snapshots from v1 to v2? Are there other incompatibilities between 
v1 and v2?

I'm asking because I have read that glance v1 isn't defcore compliant and so we 
need all projects to move to v2, but the incompatibility from v1 to v2 is 
preventing that in nova. Is there anything else preventing v2 adoption? Could 
we move to glance v2 if there's a migration path from v1 to v2 that operators 
can run through before upgrading to a version that uses v2 as the default?

Thanks,
-melanie (irc: melwitt)







__
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


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

__
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] [Glance] glance core rotation part 1

[Fei Long Wang]

+1

Yep, it would be nice if Zhi Yan can promote OpenStack in Alibaba :)

On 14/09/15 22:59, Mikhail Fedosin wrote:

+1.
I hope that Zhi Yan joined Alibaba to make it use Openstack in the 
future :)


On Mon, Sep 14, 2015 at 11:23 AM, Kuvaja, Erno <kuv...@hpe.com 
<mailto:kuv...@hpe.com>> wrote:


+1

*From:*Alex Meade [mailto:mr.alex.me...@gmail.com
<mailto:mr.alex.me...@gmail.com>]
*Sent:* Friday, September 11, 2015 7:37 PM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [Glance] glance core rotation part 1

+1

On Fri, Sep 11, 2015 at 2:33 PM, Ian Cordasco
<ian.corda...@rackspace.com <mailto:ian.corda...@rackspace.com>>
wrote:



-Original Message-
From: Nikhil Komawar <nik.koma...@gmail.com
<mailto:nik.koma...@gmail.com>>
Reply: OpenStack Development Mailing List (not for usage
questions) <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Date: September 11, 2015 at 09:30:23
To: openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Subject:  [openstack-dev] [Glance] glance core rotation part 1

> Hi,
>
> I would like to propose the following removals from
glance-core based on
> the simple criterion of inactivity/limited activity for a
long period (2
> cycles or more) of time:
>
> Alex Meade
> Arnaud Legendre
> Mark Washenberger
> Iccha Sethi

I think these are overdue

> Zhi Yan Liu (Limited activity in Kilo and absent in Liberty)

Sad to see Zhi Yan Liu's activity drop off.

> Please vote +1 or -1 and we will decide by Monday EOD PT.

+1

--
Ian Cordasco


__
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


__
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




__
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


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

__
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] [zaqar] Zaqar PTL Candidacy

[Fei Long Wang]

Greeting,

I'd like to announce my candidacy for the Zaqar PTL in Mikata.

I've been working on and contributing to Zaqar since Icehouse release as 
a core developer. That said, I really understand the ups and downs which 
Zaqar went through and I know the blueprints, direction and pains of 
this project.


For Mikata release, there are some items that I feel are important for 
us to focus on:


1. Collaboration with other OpenStack projects
We did a great job in Liberty for the integration of Heat and 
Zaqar. And I believe there are some other projects could be benefited by 
Zaqar. For example, the notification middleware of Swift, Zaqar's 
websocket transport for Horizon, communicating with guests agents via 
Zaqar for Sahara/Trove, etc.


2. Real-world deployment
puppet-zaqar is on the way. It could be an great deployment tool 
for operator who want to deploy Zaqar. So in next release, we will 
continually provide more support for the project to get a stable release 
ASAP. Interlock and provide more support for potential cloud providers 
who have shown interest for Zaqar.


3. API improvement
We have released three API versions. The API of key functions are 
more and more stable. But given the bug fix and new features, it's time 
to review the overall API of v2 to make it more stable.


4. Encourage diversity in our Community
We're still a small team and obviously we need more new blood to 
join the team. And meanwhile, we would like to see the new comers from 
different organizations so that we can get different feedback from a 
wide range of users and industries. Not only developers, but also 
reviewers and operators.


It's a fantastic experience working with this amazing team and I know 
without the dedication and hard work of everyone who has contributed to 
Zaqar we can't make those success stories of Liberty happen. So I 
believe the PTL of this smart team is most like a facilitator, 
coordinator and mentor. I would be pleased to serve as PTL for Zaqar for 
the Mikata cycle and I'd appreciate your vote.


Thanks for your consideration

--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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] [zaqar][all] PTL No-Candidacy

[Fei Long Wang]

One thing I'd like the whole team to put some efforts on, regardless
what technical decisions will be taken, is on increasing the diversity
of the project. Zaqar is not as diverse[11] (company wise) as I'd like
that worries me A LOT. Growth will, hopefully, bring more people and
reaching out to other communities remain something important.

It's been an honor to serve as Zaqar's PTL and it'll be an honor for
me to contribute to the next PTL's future plans and leads.

Sincerely,
Flavio

P.S: #openstack-zaqar remains the funiest channel ever, just sayin'.

[0] 
http://lists.openstack.org/pipermail/openstack-dev/2015-April/061967.html

[1] https://launchpad.net/zaqar/+milestone/liberty-1
[2] https://launchpad.net/zaqar/+milestone/liberty-2
[3] https://launchpad.net/zaqar/+milestone/liberty-3
[4] https://launchpad.net/zaqar/+milestone/liberty-rc1
[5] 
http://lists.openstack.org/pipermail/openstack-dev/2015-May/064739.html
[6] 
https://github.com/openstack/heat-specs/blob/master/specs/kilo/software-config-zaqar.rst
[7] 
http://specs.openstack.org/openstack/zaqar-specs/specs/liberty/pre-signed-url.html

[8] https://review.openstack.org/#/c/185822/
[9] https://github.com/openstack/puppet-zaqar
[10] 
http://lists.openstack.org/pipermail/openstack-dev/2015-August/072191.html

[11] http://stackalytics.com/?module=zaqar-group



__
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


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

__
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] [glance] differences between def detail() and def index() in glance/registry/api/v1/images.py

[Fei Long Wang]

I assume you're using Glance client, if so, by default, when you issuing 
command 'glance image-list', it will call /v1/images/detail instead of 
/v1/images, you can use curl or any browser http client to see the 
difference. Basically, just like the endpoint name, /v1/images/detail 
will give you more details. See below difference of their response.


Response from /v1/images/detail
{
"images": [
{
"status": "active",
"deleted_at": null,
"name": "fedora-21-atomic-3",
"deleted": false,
"container_format": "bare",
"created_at": "2015-09-03T22:56:37.00",
"disk_format": "qcow2",
"updated_at": "2015-09-03T23:00:15.00",
"min_disk": 0,
"protected": false,
"id": "b940521b-97ff-48d9-a22e-ecc981ec0513",
"min_ram": 0,
"checksum": "d3b3da0e07743805dcc852785c7fc258",
"owner": "5f290ac4b100440b8b4c83fce78c2db7",
"is_public": true,
"virtual_size": null,
"properties": {
"os_distro": "fedora-atomic"
},
"size": 770179072
}
]
}

Response with /v1/images
{
"images": [
{
"name": "fedora-21-atomic-3",
"container_format": "bare",
"disk_format": "qcow2",
"checksum": "d3b3da0e07743805dcc852785c7fc258",
"id": "b940521b-97ff-48d9-a22e-ecc981ec0513",
"size": 770179072
}
]
}


On 10/09/15 11:46, Su Zhang wrote:


Hello,

I am hitting an error and its trace passes def index () 
in glance/registry/api/v1/images.py.


I assume def index() is called by glance image-list. However, while 
testing glance image-list I realized that def detail() is called 
under glance/registry/api/v1/images.py instead of def index().


Could someone let me know what's the difference between the two 
functions? How can I test out def index() under 
glance/registry/api/v1/images.py through CLI or API?


Thanks,

--
Su Zhang



__
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


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

__
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] [Glance] Feature Freeze Exception proposal

[Fei Long Wang]

+1 It would be nice to have it.

On 03/09/15 14:11, Nikhil Komawar wrote:
> Hi,
>
> I wanted to propose 'Single disk image OVA import' [1] feature proposal
> for exception. This looks like a decently safe proposal that should be
> able to adjust in the extended time period of Liberty. It has been
> discussed at the Vancouver summit during a work session and the proposal
> has been trimmed down as per the suggestions then; has been overall
> accepted by those present during the discussions (barring a few changes
> needed on the spec itself). It being a addition to already existing
> import task, doesn't involve API change or change to any of the core
> Image functionality as of now.
>
> Please give your vote: +1 or -1 .
>
> [1] https://review.openstack.org/#/c/194868/
>

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] [Glance] [all] Proposal for Weekly Glance Drivers meeting.

[Fei Long Wang]

Awesome, glad to see it's proposed.

On 16/06/15 11:41, Nikhil Komawar wrote:

Hi,

As per the discussion during the last weekly Glance meeting (14:51:42at
http://eavesdrop.openstack.org/meetings/glance/2015/glance.2015-06-11-14.00.log.html
), we will begin a short drivers' meeting where anyone can come and get
more feedback.

The purpose is to enable those who need multiple drivers in the same
place; easily co-ordinate, schedule  collaborate on the specs, get
core-reviewers assigned to their specs etc. This will also enable more
synchronous style feedback, help with more collaboration as well as with
dedicated time for giving quality input on the specs. All are welcome to
attend and attendance from drivers is not mandatory but encouraged.
Initially it would be a 30 min meeting and if need persists we will
extend the period.

Please vote on the proposed time and date:
https://review.openstack.org/#/c/192008/ (Note: Run the tests for your
vote to ensure we are considering feasible  non-conflicting times.) We
will start the meeting next week unless there are strong conflicts.



--
Cheers  Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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] [puppet] [zaqar] Adding puppet-zaqar Module to Puppet Modules Project

[Fei Long Wang]

Hi Richard,

Thank you for working on this. It's really cool.

On 16/06/15 07:48, Richard Raseley wrote:
 Here are the two changes I submitted for review to get puppet-zaqar
 added to the project:

 https://review.openstack.org/#/c/191942/
 https://review.openstack.org/#/c/191946/

 I am not sure these are 100% correct, but I followed the guide[0] as
 well as I could.

 Any feedback would be appreciated.

 Regards,

 Richard

 [0] - http://docs.openstack.org/infra/manual/creators.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

-- 
Cheers  Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] [Glance] [all] Liberty summit: Updates in Glance

[Fei Long Wang]

On 02/06/15 01:51, Jay Pipes wrote:
 On 06/01/2015 08:30 AM, John Garbutt wrote:
 On 1 June 2015 at 13:10, Flavio Percoco fla...@redhat.com wrote:
 On 01/06/15 11:57 +0100, John Garbutt wrote:
 On 26/05/15 13:54 -0400, Nikhil Komawar wrote:
 FWIW, moving Nova from glance v1 to glance v2, without breaking Nova's
 public API, will require someone getting a big chunk of glance v1 on
 top of glance v2.

 AFAIK, the biggest issue right now is changed-since which is
 something Glance doesn't have in v2 but it's exposed throught Nova's
 image API.

I'm working on something in Glance related to this.
 Thats the big unanswered question that needs fixing in any spec we
 would approve around this effort.

 I'm happy you brought this up. What are Nova's plans to adopt Glance's
 v2 ? I heard there was a discussion and something along the lines of
 creating a library that wraps both APIs came up.

 We don't have anyone who has stepped up to work on it at his point.

 I think the push you made around this effort in kilo is the latest
 updated on this:
 http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/remove-glanceclient-wrapper.html


 It would be great if we could find a glance/nova CPL to drive this
 effort.

 I am happy to take the lead on this from the Nova side. I'm familiar
 with the code in Nova.

 I really think nova should put some more effort on helping this
 happen. The work I did[0] - all red now, I swear it wasn't - during
 Kilo didn't get enough attention even before we decided to push it
 back. Not a complain, really. However, I'd love to see some
 cross-project efforts on making this happen.
 [0] https://review.openstack.org/#/c/144875/

 As there is no one to work on the effort, we haven't made it a
 priority for liberty.

 It's not a huge amount of work. I can do it.
Yes, given the L release is just starting. I think we have enough time
to make it happen.

 If someone is able to step up to help complete the work, I can do my
 best to help get that effort reviewed, by raising its priority, just
 as we did in Kilo.

 I suspect looking at how to slowly move towards v2, rather than going
 for a big bang approach, will make this easier to land. That and
 solving how we implement changed-since, if thats not available in
 the newer glance APIs. Honestly, part of me wonders about skipping v2,
 and going straight to v3.

 We actually already support Glance V2 in some things. It shouldn't be
 too difficult to complete the work to fully support V2.

 Please assign me as the CPL for Glance from Nova.
I'm happy  to work with Jay for Nova from Glance :)

 Best,
 -jay

 __

 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

-- 
Cheers  Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 



__
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] Does Nova has a command line to restart an instance?

[Fei Long Wang]

Did you try 'nova start server'?

On 22/05/15 16:16, Lily.Sing wrote:

Hi experts,

I setup an OpenStack multinode environment without Horizon installed. 
After host rebooting, the instances are in 'shutoff' status. I hope to 
re-use these instances, but seems there is no command line for this. 
Any suggestion?


Thanks.

Best regards,
Lily Xing(邢莉莉)


__
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


--
Cheers  Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

__
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] [glance] missing implementation on glance basic quota

[Fei Long Wang]

We're using user_storage_quota to limit the total number of bytes of
each user for now based on the discussion, you can see that from the
blueprint. May I know your user case for number of images? Cheers.

On 20/05/15 02:10, Gareth wrote:
 Hi glance guys

 There is a bp[0] said it would implement two basic quota usage:

 a, the number of image stored
 b, the amount of storage in occupied by a set of image

 However, only b is implemented in the patch[1], and a is still missing
 in current glance.

 [0] https://blueprints.launchpad.net/glance/+spec/glance-basic-quotas
 [1] https://review.openstack.org/#/c/37993/18

 -- 
 Gareth

 /Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball/
 /OpenStack contributor, kun_huang@freenode/
 /My promise: if you find any spelling or grammar mistakes in my email
 from Mar 1 2013, notify me /
 /and I'll donate $1 or ￥1 to an open organization you specify./


 __
 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

-- 
Cheers  Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

__
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] time based auto scaling

[Fei Long Wang]

+1, if you really care about time range, Mistral can meet your requirements.

Besides, maybe not directly related, as for autoscaling, I always
believe there should be a message queue service(like Zaqar) between the
(web) application and the worker, a task request will be posted to the
queue as a message, worker will pick the message from the queue to
handle. And then we can trigger the autoscaling based on the workload of
queue instead of the hardware usage. Just drop my 2 cents.

On 29/04/15 16:39, Fox, Kevin M wrote:
 what about Mistral?

 https://wiki.openstack.org/wiki/Mistral

 Thanks,
 Kevin *
  
 *
 
 *From:* ZhiQiang Fan
 *Sent:* Tuesday, April 28, 2015 9:23:20 PM
 *To:* OpenStack Development Mailing List
 *Subject:* [openstack-dev] [ceilometer] time based auto scaling

 Hi devs,

 I'm thinking to add new type of alarm for time based auto scaling, but
 not sure if there is a better way to achieve it outside ceilometer scope

 Currently we can auto scaling based on vm load, but it will take
 several minutes to do it. For the worst case, when the vm load is
 heavy, ceilometer needs 10 minutes (by default) to collect the
 performance data, and alarm need 1 minutes to evaluate it, maybe there
 is evaluation_periods which set to higher that 1 to avoid performance
 peak. 

 So even though we can collect data by 1 minutes, but evaluation
 periods may be set to 3, so the worst case is after vm load perfomance
 in high level for 4 minutes, then the alarm is triggered, then heat
 will expand vm count, nova will take dozens seconds or more to create,
 finally the service on the in the heat server group will performance
 bad or unavailable for several minutes, which is not acceptable for
 some critical applications.

 But if we can know some high load which related with time, for
 example, 08:00am will be a peak, and after 22:00pm will definitely
 drop to idel level, then heat can increase some vms at 07:30am, then
 decrease some vms at 22:00 (or decrease by load as normal routine)

 However, current ceilometer only provide time constraint alarm, which
 will only evaluate but not guarantee it will be triggered. And heat
 cannot provide something like timer, but just can wait for the signal.

 So I propose to add a new type of alarm, which will definitely send a
 signal to action when it is evaluated (with or without repeat, it will
 work well with time constraint)

 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

-- 
Cheers  Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

__
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] [Zaqar] Call for adoption (or exclusion?)

[Fei Long Wang]

On 24/04/15 06:02, Richard Raseley wrote:
 Flavio Percoco wrote:
 I think getting operators to adopt it is key to getting other openstack
 projects to also adopt it. There is something of a chicken and the egg
 problem
 with the integration. Some of the projects you will want to integrate
 the most
 with are already considered pretty stable and may not want to rewrite
 working
 bits to target a service thats hard for ops to deploy. It makes their
 service
 hard to deploy too.

 Getting into RDO and Ubuntu will go a long way there. Getting into
 Packstack
 and other deployment tools even further.

 I don't fully agree with the above. The problem on waiting for
 operators to adopt it is that they might actually not have a reason to
 do it, which doesn't mean the project is useless. Each operator will
 decide what services they want to provide.

 The needs of operators are a reflection of the needs of their users.

 I don't want to use the word 'useless', because it has a clear
 negative connotation - and I don't think Zaqar is 'useless'. Let's
 instead discuss 'utility'.

 The utility of any solution or product is completely subjective, and
 solely based upon the underlying requirements. If real operators with
 real requirements do not view a particular solution as having utility
 for them - then it doesn't.

 You are correct in that there is a bit of a bootstrapping problem, but
 I strongly feel like the answer to that is continuing to listen to,
 and test against, the market (the architects and operators).

 Build a minimally viable product that (a) has clear messaging and use
 cases (b) is easy to deploy and configure and (c) doesn't demand deep
 integration into an existing cloud and operators will start deploying,
 testing, and providing feedback. This will create the right feedback
 cycle and help in validating (or completely demolishing) assumptions
 on what users actually need.

 With regard to '(b)' above, it doesn't appear that there any any
 Puppet modules to assist with the installation and configuration of
 Zaqar. If you're interested, let's chat in Vancouver to see if I can
 help in get a basic set out there.

Awesome, thank you for the support. I believe the puppet work is one of
our goals in Liberty, so please pop in #openstack-zaqar and let's have a
talk.
 Regards,

 Richard Raseley

 SysOps Engineer
 Puppet Labs

 __

 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

-- 
Cheers  Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] [Zaqar] Call for adoption (or exclusion?)

[Fei Long Wang]

 approaches
 don't.

 --
 Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.

 __
 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

 __
 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




 __
 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

-- 
Cheers  Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

__
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] FW: Migration/Evacuation of instance on desired host

[Fei Long Wang]

To make  it more clear, it depends on the release. Nova supports
evacuate instance without specifying a host since Juno. See
https://review.openstack.org/#/c/88749/

On 16/04/15 03:16, Chris Friesen wrote:
 On 04/15/2015 03:22 AM, Akshik dbk wrote:
 Hi,

 would like to know if schedule filters are considered while instance
 migration/evacuation.

 If you migrate or evacuate without specifying a destination then the
 scheduler filters will be considered.

 Chris


 __

 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

-- 
Cheers  Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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