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

2017-09-22 Thread Huang Zhiteng 
gt; Email: zhipe...@uci.edu
>> > Office: Calit2 Building Room 2402
>> >
>> > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>>
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Product Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards
Huang Zhiteng

__
OpenStack Development Mailing 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] [cinder] pending review

2016-12-12 Thread Huang Zhiteng 
Hi Sam,

Thank you for reporting the bug and trying to fix it.  Sorry that you
change sit there for such long time.  I've left some comment in your patch.

On Tue, Dec 13, 2016 at 12:33 PM, Sam Morrison <sorri...@gmail.com> wrote:

> Hi Cinder devs,
>
> I’ve had a review [1] waiting for some eyes for over a month now. What’s
> the process here, usually I get a response to a review in other projects in
> a day or two.
> Is there someone I need to alert or add to the review specifically for
> cinder patches?
>
> Thanks,
> Sam
>
> [1] https://review.openstack.org/#/c/393092/
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Regards
Huang Zhiteng
__
OpenStack Development Mailing 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][cinder] Schedule Instances according to Local disk based Volume?

2016-09-26 Thread Huang Zhiteng 
t; build instances like mentioned above.
>>>>>
>>>>> Or do we have any other ways of doing this?
>>>>>
>>>>> References:
>>>>> [1] http://cloudgeekz.com/71/how-to-setup-openstack-to-use-l
>>>>> ocal-disks-for-instances.html
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Kevin Zheng
>>>>>
>>>>>
>>>>> __
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe: 
>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>>
>>>>> 
>>>>> __
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe: openstack-dev-requ...@lists.op
>>>>> enstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>> 
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: openstack-dev-requ...@lists.op
>>>> enstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Regards
Huang Zhiteng
__
OpenStack Development Mailing 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][cinder] Schedule Instances according to Local disk based Volume?

2016-09-26 Thread Huang Zhiteng 
On Tue, Sep 27, 2016 at 12:00 AM, Joshua Harlow <harlo...@fastmail.com>
wrote:

> Huang Zhiteng wrote:
>
>>
>> On Mon, Sep 26, 2016 at 12:05 PM, Joshua Harlow <harlo...@fastmail.com
>> <mailto:harlo...@fastmail.com>> wrote:
>>
>> Huang Zhiteng wrote:
>>
>> In eBay, we did some inhouse change to Nova so that our big data
>> type of
>> use case can have physical disks as ephemeral disk for this type
>> of
>> flavors.  It works well so far.   My 2 cents.
>>
>>
>> Is there a published patch (or patchset) anywhere that people can
>> look at for said in-house changes?
>>
>>
>> Unfortunately no, but I think we can publish it if there are enough
>> interests.  However, I don't think that can be easily adopted onto
>> upstream Nova since it depends on other in-house changes we've done to
>> Nova.
>>
>>
> Is there any blog, or other that explains the full bunch of changes that
> ebay has done (u got me curious)?
>
> The nice thing about OSS is that if u just get the patchsets out (even to
> github or somewhere), those patches may trigger things to change to match
> your usecase better just by the nature of people being able to read them;
> but if they are never put out there, then well ya, it's a little hard to
> get anything to change.


> Anything stopping a full release of all in-house changes?
>
> Even if they are not 'super great quality' it really doesn't matter :)

Apology for sidetracking the topic a bit.  While we encourage our engineers
to embrace community and open source, I think we didn't do a good job to
actually emphasize that.  'Time To Market' is another factor, usually a
feature requirement becomes deployed service in 2,3 sprint (4~6 weeks), but
you know how much can be done in same amount of time in community,
especially with Nova. :)

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



-- 
Regards
Huang Zhiteng
__
OpenStack Development Mailing 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][cinder] Schedule Instances according to Local disk based Volume?

2016-09-25 Thread Huang Zhiteng 
On Mon, Sep 26, 2016 at 12:05 PM, Joshua Harlow <harlo...@fastmail.com>
wrote:

> Huang Zhiteng wrote:
>
>> In eBay, we did some inhouse change to Nova so that our big data type of
>> use case can have physical disks as ephemeral disk for this type of
>> flavors.  It works well so far.   My 2 cents.
>>
>
> Is there a published patch (or patchset) anywhere that people can look at
> for said in-house changes?
>

Unfortunately no, but I think we can publish it if there are enough
interests.  However, I don't think that can be easily adopted onto upstream
Nova since it depends on other in-house changes we've done to Nova.

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



-- 
Regards
Huang Zhiteng
__
OpenStack Development Mailing 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][cinder] Schedule Instances according to Local disk based Volume?

2016-09-25 Thread Huang Zhiteng 
com/71/how-to-setup-openstack-to-use-loca
>>>> l-disks-for-instances.html>
>>>>
>>>> Thanks,
>>>>
>>>> Kevin Zheng
>>>>
>>>>
>>>> 
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: openstack-dev-requ...@lists.op
>>>> enstack.org?subject:unsubscribe
>>>> <mailto:openstack-dev-requ...@lists.openstack.org?subject:un
>>>> subscribe>
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
>>>> k-dev
>>>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/opensta
>>>> ck-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:un
>>> subscribe>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
>>> k-dev <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:un
>>> subscribe>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>>
>>>
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> Are you asking about the scenario where you are creating a server with a
>> source_type=blank/image/snapshot bdm and nova creates the volume to
>> attach to the server? In that case nova doesn't pass enough information to
>> cinder to build the volume on the same host that the server is building on.
>> Nova passes an AZ but that would mean you'd need to have 1:1 AZs mapped for
>> each compute node in the deployment (I think?).
>>
>> Maybe you're thinking of like nova passing a scheduler hint to cinder
>> telling it where to build the volume?
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Regards
Huang Zhiteng
__
OpenStack Development Mailing 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] [Cinder] FFE request for RBD replication

2016-09-11 Thread Huang Zhiteng 
+1 for this long-waited feature to land in Newton.

On Sun, Sep 11, 2016 at 1:09 AM, Jay S. Bryant <
jsbry...@electronicjungle.net> wrote:

> +1 from me.  It is making good progress and is low risk.
>
> -Jay
>
>
>
> On 09/09/2016 02:32 PM, Gorka Eguileor wrote:
>
>> Hi,
>>
>> As some of you may know, Jon Bernard (jbernard on IRC) has been working
>> on the RBD v2.1 replication implementation [1] for a while, and we would
>> like to request a Feature Freeze Exception for that work, as we believe
>> it is a good candidate being a low risk change for the integrity of
>> the existing functionality in the driver:
>>
>> - It's non intrusive if it's not enabled (enabled using
>>replication_device configuration option).
>> - It doesn't affect existing deployments (disabled by default).
>> - Changes are localized to the driver itself (rbd.py) and the driver
>>unit tests file (test_rbd.py).
>>
>> Jon would have liked to make this request himself, but due to the
>> untimely arrival of his newborn baby this is not possible.
>>
>> For obvious reasons Jon will not be available for a little while, but
>> this will not be a problem, as I am well acquainted with the code -and
>> I'll be able to reach Jon if necessary- and will be taking care of the
>> final steps of the review process of his patch: replying to comments in
>> a timely fashion, making changes to the code as required, and answering
>> pings on IRC regarding the patch.
>>
>> Since some people may be interested in testing this functionality during
>> the reviewing process -or just for fun- I'll be publishing a post with
>> detailed explanation on how to deploy and test this feature as well as
>> an automated way to deploy 2 Ceph clusters -linked to be mirroring one
>> another-, and one devstack node with everything ready to test the
>> functionality (configuration and keys for the Ceph clusters, cinder
>> configuration, the latest upstream patch, and a volume type with the
>> right configuration).
>>
>> Please, do not hesitate to ask if there are any questions to or concerns
>> related to this request.
>>
>> Thank you for taking the time to evaluate this request.
>>
>> Cheers,
>> Gorka.
>>
>> [1]: https://review.openstack.org/333565
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards
Huang Zhiteng
__
OpenStack Development Mailing 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] [Cinder] Nominating Michał Dulko to Cinder Core

2016-05-05 Thread Huang Zhiteng 
+1, Michal has been contributing good quality code and reivew since he got
involved with Cinder.  It's great to have him as core.
On May 6, 2016 8:56 AM, "Alex Meade"  wrote:

+1 I thought he was already! which is usually a good sign.

On Thu, May 5, 2016 at 1:39 PM, Mike Perez  wrote:

> On 13:16 May 03, Sean McGinnis wrote:
> > Hey everyone,
> >
> > I would like to nominate Michał Dulko to the Cinder core team. Michał's
> > contributions with both code reviews [0] and code contributions [1] have
> > been significant for some time now.
>
> +1 welcome!
>
> --
> Mike Perez
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

Re: [openstack-dev] [cinder] Proposing Gorka Eguileor for core

2015-08-14 Thread Huang Zhiteng 
+1

On Fri, Aug 14, 2015 at 4:05 PM, Deepak Shetty dpkshe...@gmail.com wrote:



 On Fri, Aug 14, 2015 at 12:43 AM, Mike Perez thin...@gmail.com wrote:

 It gives me great pleasure to nominate Gorka Eguileor for Cinder core.

 Gorka's contributions to Cinder core have been much apprecated:


 https://review.openstack.org/#/q/owner:%22Gorka+Eguileor%22+project:openstack/cinder,p,0035b6410002dd11

 60/90 day review stats:

 http://russellbryant.net/openstack-stats/cinder-reviewers-60.txt
 http://russellbryant.net/openstack-stats/cinder-reviewers-90.txt

 Cinder core, please reply with a +1 for approval. This will be left
 open until August 19th. Assuming there are no objections, this will go
 forward after voting is closed.


 I am not cinder core, but +1 for Gorka to be one.
 His reviews have helped me in the past, and I particularly appreciate the
 fine grain reviews he does, which helps reduce patch iterations for the
 author

 Good luck Gorka!



 --
 Mike Perez

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



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




-- 
Regards
Huang Zhiteng
__
OpenStack Development Mailing 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] [cinder] Consider using Explicit type casts on filters

2015-06-01 Thread Huang Zhiteng 
Not a DB expert but looks like a valid bug.  Do you mind file a bug on this?

On Mon, Jun 1, 2015 at 5:43 PM, Vasco Rodrigues v...@vvro.net wrote:

 Running Cinder on postgresql, i get the following error:

 2015-06-02 01:21:27.471 32698 DEBUG cinder.api.v2.volumes
 [req-a0a15e07-2a86-4f98-a371-2f7203706b9f
 e8bd9bfef65c4def9d3977993c56b9b0 9dbebc529a0a469cb4574c3f9c0d86f7 - - -]
 Could not evaluate value 1, assuming string _get_volumes
 /usr/lib/python2.7/dist-packages/cinder/api/v2/volumes.py:238
 2015-06-02 01:21:27.471 32698 DEBUG cinder.volume.api
 [req-a0a15e07-2a86-4f98-a371-2f7203706b9f
 e8bd9bfef65c4def9d3977993c56b9b0 9dbebc529a0a469cb4574c3f9c0d86f7 - - -]
 Searching by: MultiDict([(u'status', u'available'), (u'bootable', 1)]).
 get_all /usr/lib/python2.7/dist-packages/cinder/volume/api.py:421
 2015-06-02 01:21:27.486 32698 ERROR oslo_db.sqlalchemy.exc_filters
 [req-a0a15e07-2a86-4f98-a371-2f7203706b9f
 e8bd9bfef65c4def9d3977993c56b9b0 9dbebc529a0a469cb4574c3f9c0d86f7 - - -]
 DBAPIError exception wrapped from (psycopg2.ProgrammingError) operator
 does not exist: boolean = integer
 LINE 3: ...volumes.status = 'available' AND volumes.bootable = 1 AND vo...
  ^
 HINT:  No operator matches the given name and argument type(s). You
 might need to add explicit type casts.


 I think it's because postgresql doesn't allow comparing integer to boolean.

 Which I fixed by adding:

 if 'bootable' in filters:
filters['bootable'] = bool(filters['bootable'])


 to VolumeController._get_volumes


 Regards,
 Vasco Rodrigues

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




-- 
Regards
Huang Zhiteng
__
OpenStack Development Mailing 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] [cinder] Some Changes to Cinder Core

2015-05-22 Thread Huang Zhiteng 
+1

On Fri, May 22, 2015 at 4:55 PM, Duncan Thomas duncan.tho...@gmail.com
wrote:

 +1 without hesitation
 On 22 May 2015 16:36, Mike Perez thin...@gmail.com wrote:

 This is long overdue, but it gives me great pleasure to nominate Sean
 McGinnis for
 Cinder core.

 Reviews:
 https://review.openstack.org/#/q/reviewer:+%22Sean+McGinnis%22,n,z

 Contributions:
 https://review.openstack.org/#/q/owner:+%22Sean+McGinnis%22,n,z

 30/90 day review stats:
 http://stackalytics.com/report/contribution/cinder-group/30
 http://stackalytics.com/report/contribution/cinder-group/90

 As new contributors step up to help in the project, some move onto
 other things. I would like to recognize Avishay Traeger for his
 contributions, and now
 unfortunately departure from the Cinder core team.

 Cinder core, please reply with a +1 for approval. This will be left
 open until May 29th. Assuming there are no objections, this will go
 forward after voting is closed.

 --
 Mike Perez

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


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




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

Re: [openstack-dev] [nova][all] Architecture Diagrams in ascii art?

2015-05-12 Thread Huang Zhiteng 
On Tue, May 12, 2015 at 5:22 PM, Thierry Carrez thie...@openstack.org
wrote:

 John Garbutt wrote:
  On 11 May 2015 at 23:46, Boris Pavlovic bo...@pavlovic.me wrote:
  Couldn't we just use real image files to do this. IIRC, gerrit supports
  displaying image files which are included in a commit. For example,
 I've
  been
  planning to copy these images:
 
  +1 for real images
 
  One suggestion I remember around specs was we might want a separate
  repo to contain the images, to stop massively increasing the git clone
  times.

 Also like Matt mentioned, images can't be easily modified. As time
 passes by, that usually results in stale information as people don't go
 through the hassle of completely redoing the image to update the
 information in it. That makes them fine for shiny one-time
 presentations, but inadequate for long-term technical docs.

 For those I really prefer to optimize for accuracy than for prettiness,
 so ascii art, or blockdiag, or anything we can easily share the source
 of, is to be preferred to raw images.

+1 for ascii art.


 --
 Thierry Carrez (ttx)

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




-- 
Regards
Huang Zhiteng
__
OpenStack Development Mailing 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] [swift] Go! Swift!

2015-05-07 Thread Huang Zhiteng 
Well put, Clay.  Totally Agree.

On Fri, May 8, 2015 at 10:19 AM, Clay Gerrard clay.gerr...@gmail.com wrote:


 On Thu, May 7, 2015 at 5:05 PM, Adam Lawson alaw...@aqorn.com wrote:

 what sort of limitations have you discovered that had to do specifically
 with the fact we're using Python?


 Python is great.  Conscious decision to optimize for developer wall time
 over cpu cycles has made it a great language for 20 years - and probably
 will for another 20 at *least* (IMHO).

 I don't think you would pick out anything to point at as a limitation of
 python that you couldn't point at any dynamic interpreted language, but my
 list is something like this:

 Dynamic Interpreted Runtime overhead
 Eventlet non-blocking hub is NOT OK for blocking operations (cpu, disk)
 OTOH, dispatch to threads has overhead AND GIL
 non-byte-aligned buffers restricts access to O_DIRECT and asyncio

 *So often* this kinda stuff just doesn't matter.  Or even lots of times even
 when it *does* matter - it doesn't matter that much in the grand scheme of
 things.  Or maybe it matters a non-trivial amount, *but* there's still other
 things that just mater more *right now*.  I think Swift has been in that
 last case for a long time, maybe we still are - great thing about
 open-source is redbo can publish an experiment on a feature branch in gerrit
 and in-between the hard work of testing it - we can pontificate about it on
 the mailing list!  ;)

 FWIW, I don't think anyone should find it particularly surprising that a
 mature data-path project would naturally gravitate closer to the metal in
 the critical paths - it shouldn't be a big deal - unless it all works out -
 and it's $%^! tons faster - then BOOYAH! ;)

 But I'd suggest you be very careful not to draw any assumptions in general
 about a great language like python even if this one time this one project
 thought maybe they should find out if some part of the distributed system
 might be better by some measure in something not-python.  ;)

 Cheers,

 -Clay

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




-- 
Regards
Huang Zhiteng

__
OpenStack Development Mailing 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] Changes to Cinder Core

2015-01-22 Thread Huang Zhiteng 
+1

Welcome to the team Ivan!

On Fri, Jan 23, 2015 at 1:23 AM, Walter A. Boring IV
walter.bor...@hp.com wrote:
 sorry I didn't see this earlier.

 I'd welcome Ivan to the team!

 +1


 Walt

 On Wed, Jan 21, 2015 at 10:14 AM, Mike Perez thin...@gmail.com wrote:

 It gives me great pleasure to nominate Ivan Kolodyazhny (e0ne) for
 Cinder core. Ivan's reviews have been valuable in decisions, and his
 contributions to Cinder core code have been greatly appreciated.

 Reviews:

 https://review.openstack.org/#/q/reviewer:%22Ivan+Kolodyazhny+%253Ce0ne%2540e0ne.info%253E%22,n,z

 Contributions:

 https://review.openstack.org/#/q/owner:%22Ivan+Kolodyazhny%22+project:+openstack/cinder,n,z

 30/90 day review stats:
 http://stackalytics.com/report/contribution/cinder-group/30
 http://stackalytics.com/report/contribution/cinder-group/90

 As new contributors step up to help in the project, some move onto
 other things. I would like to recognize Josh Durgin for his early
 contributions to Nova volume, early involvement with Cinder, and now
 unfortunately departure from the Cinder core team.

 Cinder core, please reply with a +1 for approval. This will be left
 open until Jan 26th. Assuming there are no objections, this will go
 forward after voting is closed.

 And apologies for missing the [cinder] subject prefix.

 --
 Mike Perez

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



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



-- 
Regards
Huang Zhiteng

__
OpenStack Development Mailing 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] China blocking access to OpenStack git review push

2014-09-08 Thread Huang Zhiteng 
I am a China Telecom user and have been blocked by the same issue for
days.  I actually reported this to China Telecom customer service.  I
don't expect these ISPs have the authority to unblock this, all I
wanted is they file something to GFW so that those guys would be aware
that one innocent site got blocked.  Well, until then I'll go with
Clark's suggestion with https.

On Mon, Sep 8, 2014 at 12:20 PM, Thomas Goirand z...@debian.org wrote:
 Am I dreaming, or is the Chinese government is trying to push for the
 cloud, they said. However, today, bad surprise:

 # nmap -p 29418 23.253.232.87

 Starting Nmap 6.00 ( http://nmap.org ) at 2014-09-09 03:10 CST
 Nmap scan report for review.openstack.org (23.253.232.87)
 Host is up (0.21s latency).
 PORT  STATESERVICE
 29418/tcp filtered unknown

 Oh dear ... not fun!

 FYI, this is from China Unicom (eg: CNC Group)

 I'm guessing that this is the Great Firewall of China awesome automated
 ban script which detected too many ssh connection to a weird port. It
 has blocked a few of my servers recently too, as it became a way too
 aggressive. I very much prefer to use my laptop to use git review than
 having to bounce around servers. :(

 Are their alternative IPs that I could use for review.openstack.org?

 Cheers,

 Thomas Goirand (zigo)

 P.S: If a Chinese official read this, an easy way to unlist (legitimate)
 servers access would be the first action any reasonable Chinese
 government people must do.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Regards
Huang Zhiteng

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Dev][Cinder] Cinder Core nomination

2014-08-27 Thread Huang Zhiteng 
Definitely +1.

Xing has been very active in providing feedback for reviews.  Thanks
for the help and welcome to the team!

On Tue, Aug 19, 2014 at 5:24 PM, Avishay Traeger
avis...@stratoscale.com wrote:
 +1


 On Thu, Aug 14, 2014 at 9:55 AM, Boring, Walter walter.bor...@hp.com
 wrote:

 Hey guys,
I wanted to pose a nomination for Cinder core.

 Xing Yang.
 She has been active in the cinder community for many releases and has
 worked on several drivers as well as other features for cinder itself.   She
 has been doing an awesome job doing reviews and helping folks out in the
 #openstack-cinder irc channel for a long time.   I think she would be a good
 addition to the core team.


 Walt
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Regards
Huang Zhiteng

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Cinder] Feature about Raw Device Mapping

2014-03-18 Thread Huang Zhiteng 
On Tue, Mar 18, 2014 at 11:01 AM, Zhangleiqiang (Trump)
zhangleiqi...@huawei.com wrote:
 From: Huang Zhiteng [mailto:winsto...@gmail.com]
 Sent: Tuesday, March 18, 2014 10:32 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Nova][Cinder] Feature about Raw Device
 Mapping

 On Tue, Mar 18, 2014 at 9:40 AM, Zhangleiqiang (Trump)
 zhangleiqi...@huawei.com wrote:
  Hi, stackers：
 
  With RDM, the storage logical unit number (LUN) can be directly
 connected to a instance from the storage area network (SAN).
 
  For most data center applications, including Databases, CRM and
 ERP applications, RDM can be used for configurations involving clustering
 between instances, between physical hosts and instances or where SAN-aware
 applications are running inside a instance.
 If 'clustering' here refers to things like cluster file system, which 
 requires LUNs
 to be connected to multiple instances at the same time.
 And since you mentioned Cinder, I suppose the LUNs (volumes) are managed by
 Cinder, then you have an extra dependency for multi-attach
 feature: https://blueprints.launchpad.net/cinder/+spec/multi-attach-volume.

 Yes.  Clustering include Oracle RAC, MSCS, etc. If they want to work in 
 instance-based cloud environment, RDM and multi-attached-volumes are both 
 needed.

 But RDM is not only used for clustering, and haven't dependency for 
 multi-attach-volume.

Set clustering use case and performance improvement aside, what other
benefits/use cases can RDM bring/be useful for?

  RDM, which permits the use of existing SAN commands, is
 generally used to improve performance in I/O-intensive applications and block
 locking. Physical mode provides access to most hardware functions of the
 storage system that is mapped.
 It seems to me that the performance benefit mostly from virtio-scsi, which is
 just an virtual disk interface, thus should also benefit all virtual disk 
 use cases
 not just raw device mapping.
 
  For libvirt driver, RDM feature can be enabled through the lun
 device connected to a virtio-scsi controller:
 
  disk type='block' device='lun'
 driver name='qemu' type='raw' cache='none'/
 source
 dev='/dev/mapper/360022a11ecba5db427db0023'/
 target dev='sdb' bus='scsi'/
 address type='drive' controller='0' bus='0'/
  /disk
 
  controller type='scsi' index='0' model='virtio-scsi'/
 
  Currently，the related works in OpenStack as follows:
  1. block-device-mapping-v2 extension has already support the
 lun device with scsi bus type listed above, but cannot make the disk use
 virtio-scsi controller instead of default lsi scsi controller.
  2. libvirt-virtio-scsi-driver BP ([1]) whose milestone target is
 icehouse-3 is aim to support generate a virtio-scsi controller when using an
 image with virtio-scsi property, but it seems not to take boot-from-volume
 and attach-rdm-volume into account.
 
  I think it is meaningful if we provide the whole support for RDM
 feature in OpenStack.
 
  Any thoughts? Welcome any advices.
 
 
  [1]
  https://blueprints.launchpad.net/nova/+spec/libvirt-virtio-scsi-driver
  --
  zhangleiqiang (Trump)
 
  Best Regards
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 --
 Regards
 Huang Zhiteng

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Regards
Huang Zhiteng

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Cinder] Feature about Raw Device Mapping

2014-03-18 Thread Huang Zhiteng 
On Tue, Mar 18, 2014 at 5:33 PM, Zhangleiqiang (Trump)
zhangleiqi...@huawei.com wrote:
 From: Huang Zhiteng [mailto:winsto...@gmail.com]
 Sent: Tuesday, March 18, 2014 4:40 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Nova][Cinder] Feature about Raw Device
 Mapping

 On Tue, Mar 18, 2014 at 11:01 AM, Zhangleiqiang (Trump)
 zhangleiqi...@huawei.com wrote:
  From: Huang Zhiteng [mailto:winsto...@gmail.com]
  Sent: Tuesday, March 18, 2014 10:32 AM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Nova][Cinder] Feature about Raw Device
  Mapping
 
  On Tue, Mar 18, 2014 at 9:40 AM, Zhangleiqiang (Trump)
  zhangleiqi...@huawei.com wrote:
   Hi, stackers：
  
   With RDM, the storage logical unit number (LUN) can be
   directly
  connected to a instance from the storage area network (SAN).
  
   For most data center applications, including Databases, CRM
   and
  ERP applications, RDM can be used for configurations involving
  clustering between instances, between physical hosts and instances or
  where SAN-aware applications are running inside a instance.
  If 'clustering' here refers to things like cluster file system, which
  requires LUNs to be connected to multiple instances at the same time.
  And since you mentioned Cinder, I suppose the LUNs (volumes) are
  managed by Cinder, then you have an extra dependency for multi-attach
  feature:
 https://blueprints.launchpad.net/cinder/+spec/multi-attach-volume.
 
  Yes.  Clustering include Oracle RAC, MSCS, etc. If they want to work in
 instance-based cloud environment, RDM and multi-attached-volumes are both
 needed.
 
  But RDM is not only used for clustering, and haven't dependency for
 multi-attach-volume.

 Set clustering use case and performance improvement aside, what other
 benefits/use cases can RDM bring/be useful for?

 Thanks for your reply.

 The advantages of Raw device mapping are all introduced by its capability of 
 pass scsi command to the device, and the most common use cases are 
 clustering and performance improvement mentioned above.

As mentioned in earlier email, I doubt the performance improvement
comes from 'virtio-scsi' interface instead of RDM.  We can actually
test them to verify.  Here's what I would do: create one LUN(volume)
on the SAN, attach the volume to instance using current attach code
path but change the virtual bus to 'virtio-scsi' and then measure the
IO performance using standard IO benchmark; next, attach the volume to
instance using 'lun' device for 'disk' and 'virtio-scsi' for bus, and
do the measurement again.  We shall be able to see the performance
difference if there is any.  Since I don't have a SAN to play with,
could you please do the test and share the results?

 And besides these two scenarios, there is another use case: running SAN-aware 
 application inside instances, such as:
 1. SAN management app
Yes, that is possible if RDM is enable.  But I wonder what is the real
use case behind this.  Even though SAN mgmt app inside instance is
able to manage the LUN directly, but it is just a LUN instead of a
real SAN, what the instance can do is *limited* to the specific LUN,
which doesn't seem very useful IMO.  Or are you thinking about
creating a big enough LUN for user so they can treat it like a
'virtual' SAN and do all kinds of management stuff to it and even
maybe resell it for PaaS use cases?

 2. Apps which can offload the device related works, such as snapshot, backup, 
 etc, to SAN.
Not sure I follow this use cases either, nor do I understand why end
users want to do all those operations _inside_ instance instead of
utilizing existing infrastructure like Cinder.  If the goal behind
this is to make traditional IT users happy, I tend to agree with what
Duncan said in another thread
(http://osdir.com/ml/openstack-dev/2014-03/msg01395.html)



 
   RDM, which permits the use of existing SAN commands, is
  generally used to improve performance in I/O-intensive applications
  and block locking. Physical mode provides access to most hardware
  functions of the storage system that is mapped.
  It seems to me that the performance benefit mostly from virtio-scsi,
  which is just an virtual disk interface, thus should also benefit all
  virtual disk use cases not just raw device mapping.
  
   For libvirt driver, RDM feature can be enabled through the lun
  device connected to a virtio-scsi controller:
  
   disk type='block' device='lun'
  driver name='qemu' type='raw' cache='none'/
  source
  dev='/dev/mapper/360022a11ecba5db427db0023'/
  target dev='sdb' bus='scsi'/
  address type='drive' controller='0' bus='0'/
   /disk
  
   controller type='scsi' index='0' model='virtio-scsi'/
  
   Currently，the related works in OpenStack as follows:
   1. block-device-mapping-v2 extension has already support
   the
  lun

Re: [openstack-dev] [Nova][Cinder] Feature about Raw Device Mapping

2014-03-17 Thread Huang Zhiteng 
On Tue, Mar 18, 2014 at 9:40 AM, Zhangleiqiang (Trump)
zhangleiqi...@huawei.com wrote:
 Hi, stackers：

 With RDM, the storage logical unit number (LUN) can be directly 
 connected to a instance from the storage area network (SAN).

 For most data center applications, including Databases, CRM and ERP 
 applications, RDM can be used for configurations involving clustering between 
 instances, between physical hosts and instances or where SAN-aware 
 applications are running inside a instance.
If 'clustering' here refers to things like cluster file system, which
requires LUNs to be connected to multiple instances at the same time.
And since you mentioned Cinder, I suppose the LUNs (volumes) are
managed by Cinder, then you have an extra dependency for multi-attach
feature: https://blueprints.launchpad.net/cinder/+spec/multi-attach-volume.
 RDM, which permits the use of existing SAN commands, is generally 
 used to improve performance in I/O-intensive applications and block locking. 
 Physical mode provides access to most hardware functions of the storage 
 system that is mapped.
It seems to me that the performance benefit mostly from virtio-scsi,
which is just an virtual disk interface, thus should also benefit all
virtual disk use cases not just raw device mapping.

 For libvirt driver, RDM feature can be enabled through the lun 
 device connected to a virtio-scsi controller:

 disk type='block' device='lun'
driver name='qemu' type='raw' cache='none'/
source dev='/dev/mapper/360022a11ecba5db427db0023'/
target dev='sdb' bus='scsi'/
address type='drive' controller='0' bus='0'/
 /disk

 controller type='scsi' index='0' model='virtio-scsi'/

 Currently，the related works in OpenStack as follows:
 1. block-device-mapping-v2 extension has already support the lun 
 device with scsi bus type listed above, but cannot make the disk use 
 virtio-scsi controller instead of default lsi scsi controller.
 2. libvirt-virtio-scsi-driver BP ([1]) whose milestone target is 
 icehouse-3 is aim to support generate a virtio-scsi controller when using an 
 image with virtio-scsi property, but it seems not to take boot-from-volume 
 and attach-rdm-volume into account.

 I think it is meaningful if we provide the whole support for RDM 
 feature in OpenStack.

 Any thoughts? Welcome any advices.


 [1] https://blueprints.launchpad.net/nova/+spec/libvirt-virtio-scsi-driver
 --
 zhangleiqiang (Trump)

 Best Regards

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Regards
Huang Zhiteng

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Cinder] Feature about volume delete protection

2014-03-11 Thread Huang Zhiteng 
On Tue, Mar 11, 2014 at 11:38 AM, Zhangleiqiang
zhangleiqi...@huawei.com wrote:
 Hi all,



 Besides the soft-delete state for volumes, I think there is need for
 introducing another fake delete state for volumes which have snapshot.



 Current Openstack refuses the delete request for volumes which have
 snapshot. However, we will have no method to limit users to only use the
 specific snapshot other than the original volume ,  because the original
 volume is always visible for the users.



 So I think we can permit users to delete volumes which have snapshots, and
 mark the volume as fake delete state. When all of the snapshots of the
 volume have already deleted, the original volume will be removed
 automatically.

Can you describe the actual use case for this?  I not sure I follow
why operator would like to limit the owner of the volume to only use
specific version of snapshot.  It sounds like you are adding another
layer.  If that's the case, the problem should be solved at upper
layer instead of Cinder.




 Any thoughts? Welcome any advices.







 --

 zhangleiqiang



 Best Regards



 From: John Griffith [mailto:john.griff...@solidfire.com]
 Sent: Thursday, March 06, 2014 8:38 PM


 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Nova][Cinder] Feature about volume delete
 protection







 On Thu, Mar 6, 2014 at 9:13 PM, John Garbutt j...@johngarbutt.com wrote:

 On 6 March 2014 08:50, zhangyu (AI) zhangy...@huawei.com wrote:
 It seems to be an interesting idea. In fact, a China-based public IaaS,
 QingCloud, has provided a similar feature
 to their virtual servers. Within 2 hours after a virtual server is
 deleted, the server owner can decide whether
 or not to cancel this deletion and re-cycle that deleted virtual server.

 People make mistakes, while such a feature helps in urgent cases. Any idea
 here?

 Nova has soft_delete and restore for servers. That sounds similar?

 John



 -Original Message-
 From: Zhangleiqiang [mailto:zhangleiqi...@huawei.com]
 Sent: Thursday, March 06, 2014 2:19 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [Nova][Cinder] Feature about volume delete
 protection

 Hi all,

 Current openstack provide the delete volume function to the user.
 But it seems there is no any protection for user's delete operation miss.

 As we know the data in the volume maybe very important and valuable.
 So it's better to provide a method to the user to avoid the volume delete
 miss.

 Such as:
 We can provide a safe delete for the volume.
 User can specify how long the volume will be delay deleted(actually
 deleted) when he deletes the volume.
 Before the volume is actually deleted, user can cancel the delete
 operation and find back the volume.
 After the specified time, the volume will be actually deleted by the
 system.

 Any thoughts? Welcome any advices.

 Best regards to you.


 --
 zhangleiqiang

 Best Regards



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 I think a soft-delete for Cinder sounds like a neat idea.  You should file a
 BP that we can target for Juno.



 Thanks,

 John




 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Regards
Huang Zhiteng

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Cinder] Feature about volume delete protection

2014-03-11 Thread Huang Zhiteng 
On Tue, Mar 11, 2014 at 5:09 PM, Zhangleiqiang zhangleiqi...@huawei.com wrote:
 From: Huang Zhiteng [mailto:winsto...@gmail.com]
 Sent: Tuesday, March 11, 2014 4:29 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Nova][Cinder] Feature about volume delete
 protection

 On Tue, Mar 11, 2014 at 11:38 AM, Zhangleiqiang
 zhangleiqi...@huawei.com wrote:
  Hi all,
 
 
 
  Besides the soft-delete state for volumes, I think there is need for
  introducing another fake delete state for volumes which have snapshot.
 
 
 
  Current Openstack refuses the delete request for volumes which have
  snapshot. However, we will have no method to limit users to only use
  the specific snapshot other than the original volume ,  because the
  original volume is always visible for the users.
 
 
 
  So I think we can permit users to delete volumes which have snapshots,
  and mark the volume as fake delete state. When all of the snapshots
  of the volume have already deleted, the original volume will be
  removed automatically.
 
 Can you describe the actual use case for this?  I not sure I follow why 
 operator
 would like to limit the owner of the volume to only use specific version of
 snapshot.  It sounds like you are adding another layer.  If that's the case, 
 the
 problem should be solved at upper layer instead of Cinder.

 For example, one tenant's volume quota is five, and has 5 volumes and 1 
 snapshot already. If the data in base volume of the snapshot is corrupted, 
 the user will need to create a new volume from the snapshot, but this 
 operation will be failed because there are already 5 volumes, and the 
 original volume cannot be deleted, too.

Hmm, how likely is it the snapshot is still sane when the base volume
is corrupted?  Even if this case is possible, I don't see the 'fake
delete' proposal is the right way to solve the problem.  IMO, it
simply violates what quota system is designed for and complicates
quota metrics calculation (there would be actual quota which is only
visible to admin/operator and an end-user facing quota).  Why not
contact operator to bump the upper limit of the volume quota instead?
 
 
 
 
  Any thoughts? Welcome any advices.
 
 
 
 
 
 
 
  --
 
  zhangleiqiang
 
 
 
  Best Regards
 
 
 
  From: John Griffith [mailto:john.griff...@solidfire.com]
  Sent: Thursday, March 06, 2014 8:38 PM
 
 
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Nova][Cinder] Feature about volume
  delete protection
 
 
 
 
 
 
 
  On Thu, Mar 6, 2014 at 9:13 PM, John Garbutt j...@johngarbutt.com
 wrote:
 
  On 6 March 2014 08:50, zhangyu (AI) zhangy...@huawei.com wrote:
  It seems to be an interesting idea. In fact, a China-based public
  IaaS, QingCloud, has provided a similar feature to their virtual
  servers. Within 2 hours after a virtual server is deleted, the server
  owner can decide whether or not to cancel this deletion and re-cycle
  that deleted virtual server.
 
  People make mistakes, while such a feature helps in urgent cases. Any
  idea here?
 
  Nova has soft_delete and restore for servers. That sounds similar?
 
  John
 
 
 
  -Original Message-
  From: Zhangleiqiang [mailto:zhangleiqi...@huawei.com]
  Sent: Thursday, March 06, 2014 2:19 PM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: [openstack-dev] [Nova][Cinder] Feature about volume delete
  protection
 
  Hi all,
 
  Current openstack provide the delete volume function to the user.
  But it seems there is no any protection for user's delete operation miss.
 
  As we know the data in the volume maybe very important and valuable.
  So it's better to provide a method to the user to avoid the volume
  delete miss.
 
  Such as:
  We can provide a safe delete for the volume.
  User can specify how long the volume will be delay deleted(actually
  deleted) when he deletes the volume.
  Before the volume is actually deleted, user can cancel the delete
  operation and find back the volume.
  After the specified time, the volume will be actually deleted by the
  system.
 
  Any thoughts? Welcome any advices.
 
  Best regards to you.
 
 
  --
  zhangleiqiang
 
  Best Regards
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  I think a soft-delete for Cinder sounds like a neat idea.  You should
  file a BP that we can target for Juno.
 
 
 
  Thanks,
 
  John

Re: [openstack-dev] coding standards question

2014-01-07 Thread Huang Zhiteng 
Yes, you turn it off.  Once the change to enforce this rule is merged
into hacking, other projects can start refresh their hacking
dependency (e.g. upgrading to latest version).  The patch to update
the dependency has to turn the newly added check off and then
consecutive patches can fix all violations in that project and then
turn the rule back on.

On Tue, Jan 7, 2014 at 11:19 PM, Greg Hill greg.h...@rackspace.com wrote:
 Thanks Sean.  I'll work on adding this one to the hacking repo.  That brings 
 up another question, though, what are the implications of suddenly enforcing 
 a rule that wasn't previously enforced?  I know there are at least 30 other 
 violations of this rule just within trove, and I imagine larger projects 
 probably have more.  I'd hate to be the target of all the ire that sudden 
 rejections of every commit would cause.  Do we have a way to make it off by 
 default for some period to let the projects all clean themselves up then turn 
 it on by default after that?

 Or we could just loosen the coding standards, but that's just crazy talk :D

 Greg

 On Jan 7, 2014, at 8:46 AM, Sean Dague s...@dague.net wrote:

 On 01/07/2014 09:26 AM, Greg Hill wrote:
 I got a -1 on a review for a standards violation that isn't caught by
 the automated checks, so I was wondering why the automated check doesn't
 catch it.  The violation was:

 from X import Y, Z

 According to the coding standards page on the openstack wiki, the coding
 standards are PEP8 (they just link to the PEP8 docs):
 https://wiki.openstack.org/wiki/CodingStandards and PEP8 explicitly says
 this format is allowed.

 It was pointed out that there's an additional wiki page I had missed,
 http://docs.openstack.org/developer/hacking/ which specifies this rule.
  So now that I see it is a rule, it comes back to my original question,
 why is it not enforced by the checker?  Apparently there's not a flake8
 rule for this either https://flake8.readthedocs.org/en/2.0/warnings.html

 So, two questions:

 1. Is this really the rule or just a vaguely worded repeat of the PEP8
 rule about import X, Y?
 2. If it is the rule, what's involved in getting the pep8 tests to check
 for it?

 Writing the hacking test to support it - 
 https://github.com/openstack-dev/hacking

 The policy leads the automatic enforcement scripts, so there are plenty of 
 rules in the policy that are not in automatic enforcement. Contributions to 
 fill in the gaps are welcomed.

 My own personal frustration aside, this would be helpful for other
 newcomers I imagine.  We have some pretty rigid and extensive coding
 standards, so its not reasonable to expect new contributors to remember
 them all.  It's also much nicer to have an automated tool tell you you
 violated some coding standard than to think you were ok and then have
 your code rejected 2 weeks later because of it.

 Thanks,
 Greg

 P.S. I can fix the wiki to point to the right page after the discussion.

 Agreed, it's all about bandwidth. Contributors on hacking to help fill it 
 out are appreciated. Right now it's mostly just Joe with a few others 
 throwing in when they can.

   -Sean

 --
 Sean Dague
 Samsung Research America
 s...@dague.net / sean.da...@samsung.com
 http://dague.net

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Regards
Huang Zhiteng

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] weekly meeting

2013-12-16 Thread Huang Zhiteng 
04:00 or 05:00 UTC works for me.

On Tue, Dec 17, 2013 at 11:04 AM, John Griffith
john.griff...@solidfire.com wrote:
 Hi All,

 Prompted by a recent suggestion from Tom Fifield, I thought I'd gauge
 some interest in either changing the weekly Cinder meeting time, or
 proposing a second meeting to accomodate folks in other time-zones.

 A large number of folks are already in time-zones that are not
 friendly to our current meeting time.  I'm wondering if there is
 enough of an interest to move the meeting time from 16:00 UTC on
 Wednesdays, to 04:00 or 05:00 UTC?  Depending on the interest I'd be
 willing to look at either moving the meeting for a trial period or
 holding a second meeting to make sure folks in other TZ's had a chance
 to be heard.

 Let me know your thoughts, if there are folks out there that feel
 unable to attend due to TZ conflicts and we can see what we might be
 able to do.

 Thanks,
 John

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Regards
Huang Zhiteng

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack][Cinder] Driver qualification

2013-07-25 Thread Huang Zhiteng 
Great idea and 100% agree.  It'd be even better if maintainer can publish
functional test results using their own back-ends on a regular basis
(weekly/bi-weekly test report) to 'openstack-dev' mailing list.


On Fri, Jul 26, 2013 at 9:05 AM, Joshua Harlow harlo...@yahoo-inc.comwrote:

  100% agree, its hard to handle these 3rd party type of drivers but I
 think we need to find out a way that will test it in a way that doesn't
 require having said 3rd party gear directly available.

  Could it be possible to have CI gating be blocked/tested by individual
 subfolders of cinder.

  For example when the solidfire driver is modified, this would cause a
 'trigger' to say solidfire (via some API) that solidfire can respond with
 back saying said commit works.

  Not sure if that’s feasible, but it does seem to be a similar situation
 in nova, neturon, cinder as more and more 3rd party 'driver-like' code
 appears.

   From: John Griffith john.griff...@solidfire.com
 Reply-To: OpenStack Development Mailing List 
 openstack-dev@lists.openstack.org
 Date: Thursday, July 25, 2013 5:44 PM
 To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [OpenStack][Cinder] Driver qualification

   Hey Everyone,

  Something I've been kicking around for quite a while now but never
 really been able to get around to is the idea of requiring that drivers in
 Cinder run a qualification test and submit results prior to introduction in
 to Cinder.

  To elaborate a bit, the idea could start as something really simple like
 the following:
 1. We'd add a functional_qual option/script to devstack

  2. Driver maintainer runs this script to setup devstack and configure it
 to use their backend device on their own system.

  3. Script does the usual devstack install/configure and runs the volume
 pieces of the Tempest gate tests.

  4. Grabs output and checksums of the directories in the devstack and
 /opt/stack directories, bundles up the results for submission

  5. Maintainer submits results

  So why would we do this you ask?  Cinder is pretty heavy on the third
 party driver plugin model which is fantastic.  On the other hand while
 there are a lot of folks who do great reviews that catch things like syntax
 or logic errors in the code, and unit tests do a reasonable job of
 exercising the code it's difficult for folks to truly verify these devices
 all work.

  I think it would be a very useful tool for initial introduction of a new
 driver and even perhaps some sort of check that's run and submitted again
 prior to milestone releases.

  This would also drive some more activity and contribution in to Tempest
 with respect to getting folks like myself motivated to contribute more
 tests (particularly in terms of new functionality) in to Tempest.

  I'd be interested to hear if folks have any interest or strong opinions
 on this (positive or otherwise).  I know that some vendors like RedHat have
 this sort of thing in place for certifications, and to be honest that
 observation is something that caused me to start thinking about this again.

  There are a lot of gaps here regarding how the submission process would
 look, but we could start relatively simple and grow from there if it's
 valuable or just abandon the idea if it proves to be unpopular and a waste
 of time.

  Anyway, I'd love to get feed-back from folks and see what they think.

  Thanks,
 John


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Regards
Huang Zhiteng
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] [cinder] Proposal for Ollie Leahy to join cinder-core

2013-07-17 Thread Huang Zhiteng 
+1 for Ollie.


On Wed, Jul 17, 2013 at 2:42 PM, Avishay Traeger avis...@il.ibm.com wrote:

 Walter A. Boring IV walter.bor...@hp.com wrote on 07/18/2013 12:04:07
 AM:
 snip
  +1 to Ollie from me.
 
  +1 to John's points.   If a company is colluding with other core
  members, from the same company, to do bad things within a project,
  it should become pretty obvious at some point and the project's
  community should take action.   If someone is putting in an extra
  effort to provide quality code and reviews on a regular basis, then
  why wouldn't we want that person on the team?  Besides, being a core
  member really just means that you are required to do reviews and
  help out with the community.  You do get some gerrit privileges for
  reviews, but that's about it.   I for one think that we absolutely
  can use more core members to help out with reviews during the
  milestone deadlines :)

 Walt,
 As I said, I really wasn't worried about anyone colluding or doing bad
 things.  As you said, that would be obvious and could be handled.  I was
 concerned about creating a limited view, and I thank you and everyone who
 replied for easing those concerns.

 And BTW, I don't think there is an HP conspiracy to take over Cinder and
 make it FC-only :)

 Thanks,
 Avishay


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Regards
Huang Zhiteng
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev