[openstack-dev] Fwd: [cinder] OpenStack Hackathon for Rocky release

[TommyLike Hu]

Forward the next hackathon session and add cinder tag :)

-- Forwarded message -
From: Fred Li 
Date: 2018年6月12日周二 下午4:40
Subject: [openstack-dev] OpenStack Hackathon for Rocky release
To: OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>


Hi all OpenStackers,

Since April 2015, there have been 7 OpenStack Bug Smash events in
China. If you are interested, please visit [1].

Now, the 8th OpenStack bug smash is coming. Intel, Huawei, Tecent and
CESI will host this event. Just to highlight, this event is changed to
Open Source Hackathon as more open source communities are joining. You
can find Kata Containers, Ceph, Kubernetes, Cloud Foundry besides
OpenStack.

This event[2] will be on Jun 19 and 20 in Beijing, just prior to
OpenInfra Days China 2018 [3].

To all the projects team leaders, you can discuss with your team in
the project meeting and mark the bugs[4] you expect the attendees to
work on. If you can arrange core reviewers to take care of the patches
during the 2 days, that will be more efficient.

[1]
https://www.openstack.org/videos/sydney-2017/what-china-developers-brought-to-community-after-6-openstack-bug-smash-events
[2] https://etherpad.openstack.org/p/OpenSource-Hackathon-8-beijing
[3] http://china.openinfradays.org/
[4]
https://etherpad.openstack.org/p/OpenSource-Hackathon-Rocky-Beijing-Bugs-List

-- 
Regards
Fred Li (李永乐)

__
OpenStack Development Mailing 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] Support share backup to different projects?

[TommyLike Hu]

Hey Gorka,
Thanks for your input:) I think I need to clarify that our idea is to
share the backup resource to another tenants, that is different with
transfer as the original tenant still can fully control the backup
resource, and the tenants that have been shared to only have the ability to
see and read the content of that backup.

Gorka Eguileor <gegui...@redhat.com>于2018年3月21日周三 下午7:15写道：

> On 20/03, Jay S Bryant wrote:
> >
> >
> > On 3/19/2018 10:55 PM, TommyLike Hu wrote:
> > > Now Cinder can transfer volume (with or without snapshots) to different
> > > projects,  and this make it possbile to transfer data across tenant via
> > > volume or image. Recently we had a conversation with our customer from
> > > Germany, they mentioned they are more pleased if we can support
> transfer
> > > data accross tenant via backup not image or volume, and these below are
> > > some of their concerns:
> > >
> > > 1. There is a use case that they would like to deploy their
> > > develop/test/product systems in the same region but within different
> > > tenants, so they have the requirment to share/transfer data across
> > > tenants.
> > >
> > > 2. Users are more willing to use backups to secure/store their volume
> > > data since backup feature is more advanced in product openstack version
> > > (incremental backups/periodic backups/etc.).
> > >
> > > 3. Volume transfer is not a valid option as it's in AZ and it's a
> > > complicated process if we would like to share the data to multiple
> > > projects (keep copy in all the tenants).
> > >
> > > 4. Most of the users would like to use image for bootable volume only
> > > and share volume data via image means the users have to maintain lots
> of
> > > image copies when volume backup changed as well as the whole system
> > > needs to differentiate bootable images and none bootable images, most
> > > important, we can not restore volume data via image now.
> > >
> > > 5. The easiest way for this seems to support sharing backup to
> different
> > > projects, the owner project have the full authority while shared
> > > projects only can view/read the backups.
> > >
> > > 6. AWS has the similar concept, share snapshot. We can share it by
> > > modify the snapshot's create volume permissions [1].
> > >
> > > Looking forward to any like or dislike or suggestion on this idea
> > > accroding to my feature proposal experience:)
> > >
> > >
> > > Thanks
> > > TommyLike
> > >
> > >
> > > [1]:
> https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.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
> > Tommy,
> >
> > As discussed at the PTG, this still sounds like improper usage of
> Backup.
> > Happy to hear input from others but I am having trouble getting my head
> > around it.
> >
> > The idea of sharing a snapshot, as you mention AWS supports sounds like
> it
> > could be a more sensible approach.  Why are you not proposing that?
> >
> > Jay
> >
>
> Hi,
>
> I agree with Jay that this sounds like an improper use of Backups, and I
> believe that this feature, just like trying to transfer snapshots, would
> incur in a lot of code changes as well as an ever greater number of
> bugs, because the ownership structure in Cinder is hierarchical and well
> defined.
>
> So if you transferred a snapshot then you would lose that snapshot
> information on the source volume, which means that we could not prevent
> a volume deletion with a snapshot, or we could prevent it but would
> either have to prevent the deletion from happening (creating a terrible
> user experience since the user can't delete the volume now because
> somebody else still has one of its snapshots) or we have to implement
> some kind of "trash" mechanism to postpone cleanup until all the
> snapshots have been deleted, which would make our quota code more
> complex as well as make our stats reporting and scheduling diverge from
> what the user think has actually happened (they deleted a bunch of
> volumes but the data has not been freed from the backend).
>
> As for backups, you have an even worse situatio

Re: [openstack-dev] [cinder] Support share backup to different projects?

[TommyLike Hu]

Sure! I will bring this to our weekly meeting when more feedbacks are
gathered : )

Jay S Bryant <jungleb...@gmail.com>于2018年3月21日周三 下午1:05写道：

> Tommy,
>
> I am still not sure that this is going to move the team to a different
> decision.
>
> Now that you have more information you can propose it as a topic in
> tomorrow's team meeting if you wish.
>
> Jay
>
> On 3/20/2018 8:54 PM, TommyLike Hu wrote:
>
>
> Thanks Jay,
> The question is AWS doesn't have the concept of backup and their
> snapshot is incremental backup internally and will be finllay stored into
> S3 which is more sound like backup for us. Our snapshot can not be used
> across AZ.
>
> Jay S Bryant <jungleb...@gmail.com>于2018年3月21日周三 上午4:13写道：
>
>>
>>
>> On 3/19/2018 10:55 PM, TommyLike Hu wrote:
>>
>> Now Cinder can transfer volume (with or without snapshots) to different
>> projects,  and this make it possbile to transfer data across tenant via
>> volume or image. Recently we had a conversation with our customer from
>> Germany, they mentioned they are more pleased if we can support transfer
>> data accross tenant via backup not image or volume, and these below are
>> some of their concerns:
>>
>> 1. There is a use case that they would like to deploy their
>> develop/test/product systems in the same region but within different
>> tenants, so they have the requirment to share/transfer data across tenants.
>>
>> 2. Users are more willing to use backups to secure/store their volume
>> data since backup feature is more advanced in product openstack version
>> (incremental backups/periodic backups/etc.).
>>
>> 3. Volume transfer is not a valid option as it's in AZ and it's a
>> complicated process if we would like to share the data to multiple projects
>> (keep copy in all the tenants).
>>
>> 4. Most of the users would like to use image for bootable volume only and
>> share volume data via image means the users have to maintain lots of image
>> copies when volume backup changed as well as the whole system needs to
>> differentiate bootable images and none bootable images, most important, we
>> can not restore volume data via image now.
>>
>> 5. The easiest way for this seems to support sharing backup to different
>> projects, the owner project have the full authority while shared projects
>> only can view/read the backups.
>>
>> 6. AWS has the similar concept, share snapshot. We can share it by modify
>> the snapshot's create volume permissions [1].
>>
>> Looking forward to any like or dislike or suggestion on this idea
>> accroding to my feature proposal experience:)
>>
>>
>> Thanks
>> TommyLike
>>
>>
>> [1]:
>> https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html
>>
>>
>> __
>> 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
>>
>> Tommy,
>>
>> As discussed at the PTG, this still sounds like improper usage of
>> Backup.  Happy to hear input from others but I am having trouble getting my
>> head around it.
>>
>> The idea of sharing a snapshot, as you mention AWS supports sounds like
>> it could be a more sensible approach.  Why are you not proposing that?
>>
>> 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
>>
>
>
> __
> 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.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] Support share backup to different projects?

[TommyLike Hu]

Thanks Jay,
The question is AWS doesn't have the concept of backup and their
snapshot is incremental backup internally and will be finllay stored into
S3 which is more sound like backup for us. Our snapshot can not be used
across AZ.

Jay S Bryant <jungleb...@gmail.com>于2018年3月21日周三 上午4:13写道：

>
>
> On 3/19/2018 10:55 PM, TommyLike Hu wrote:
>
> Now Cinder can transfer volume (with or without snapshots) to different
> projects,  and this make it possbile to transfer data across tenant via
> volume or image. Recently we had a conversation with our customer from
> Germany, they mentioned they are more pleased if we can support transfer
> data accross tenant via backup not image or volume, and these below are
> some of their concerns:
>
> 1. There is a use case that they would like to deploy their
> develop/test/product systems in the same region but within different
> tenants, so they have the requirment to share/transfer data across tenants.
>
> 2. Users are more willing to use backups to secure/store their volume data
> since backup feature is more advanced in product openstack version
> (incremental backups/periodic backups/etc.).
>
> 3. Volume transfer is not a valid option as it's in AZ and it's a
> complicated process if we would like to share the data to multiple projects
> (keep copy in all the tenants).
>
> 4. Most of the users would like to use image for bootable volume only and
> share volume data via image means the users have to maintain lots of image
> copies when volume backup changed as well as the whole system needs to
> differentiate bootable images and none bootable images, most important, we
> can not restore volume data via image now.
>
> 5. The easiest way for this seems to support sharing backup to different
> projects, the owner project have the full authority while shared projects
> only can view/read the backups.
>
> 6. AWS has the similar concept, share snapshot. We can share it by modify
> the snapshot's create volume permissions [1].
>
> Looking forward to any like or dislike or suggestion on this idea
> accroding to my feature proposal experience:)
>
>
> Thanks
> TommyLike
>
>
> [1]:
> https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html
>
>
> __
> 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
>
> Tommy,
>
> As discussed at the PTG, this still sounds like improper usage of Backup.
> Happy to hear input from others but I am having trouble getting my head
> around it.
>
> The idea of sharing a snapshot, as you mention AWS supports sounds like it
> could be a more sensible approach.  Why are you not proposing that?
>
> 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
>
__
OpenStack Development Mailing 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] [cinder] Support share backup to different projects?

[TommyLike Hu]

Now Cinder can transfer volume (with or without snapshots) to different
projects,  and this make it possbile to transfer data across tenant via
volume or image. Recently we had a conversation with our customer from
Germany, they mentioned they are more pleased if we can support transfer
data accross tenant via backup not image or volume, and these below are
some of their concerns:

1. There is a use case that they would like to deploy their
develop/test/product systems in the same region but within different
tenants, so they have the requirment to share/transfer data across tenants.

2. Users are more willing to use backups to secure/store their volume data
since backup feature is more advanced in product openstack version
(incremental backups/periodic backups/etc.).

3. Volume transfer is not a valid option as it's in AZ and it's a
complicated process if we would like to share the data to multiple projects
(keep copy in all the tenants).

4. Most of the users would like to use image for bootable volume only and
share volume data via image means the users have to maintain lots of image
copies when volume backup changed as well as the whole system needs to
differentiate bootable images and none bootable images, most important, we
can not restore volume data via image now.

5. The easiest way for this seems to support sharing backup to different
projects, the owner project have the full authority while shared projects
only can view/read the backups.

6. AWS has the similar concept, share snapshot. We can share it by modify
the snapshot's create volume permissions [1].

Looking forward to any like or dislike or suggestion on this idea accroding
to my feature proposal experience:)


Thanks
TommyLike


[1]:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] [manila] Performance concern on new quota system

[TommyLike Hu]

Thanks Gorka,
To be clear, I started this discussion not because I reject this
feature, instead I like it as it's much more clean and simple, compared
with performance impact it solves several other issues which we hate badly.
I wrote this is to point out we may have this issue, and to see whether we
could improve it before it's actually landed. Better is better:)



*- Using a single query to retrieve both counts and sums instead of 2
   queries.*

For this advice, I think I already combined count and sum into single query.

 - DB triggers to do the actual counting.

This seems a good idea, but not sure whether it could cover all of the
cases we have in our quota system and whether can be easily integrated into
cinder, can you share more detail on this?

Thanks
TommyLike


Gorka Eguileor <gegui...@redhat.com>于2018年3月9日周五 下午8:11写道：

> On 09/03, TommyLike Hu wrote:
> > Hey all,
> > During the Cinder and Manila's cross project discussion on quota
> system
> > last week, I raise our concern of performance impact on the count
> resource
> > feature, and Gorka pointed out we might miss some of the indexes when
> > testing. So I reshaped the environment and share some test results here
> as
> > below:
> >
> > *Test patch:*
> >  Basically this [1] is borrowed from Nova for Cinder, and only the
> > create volume process has been updated to use the new system.
> >
> > *Test Environment on AWS:*
> > 1. 3 EC2 t2.large(2 vCPU, 8GiB，80G SSD) each one deployed cinder API
> > service with 10 api workers (coordinated by haproxy)
> > 2. 1 RDS db.m4.xlarge(4 vCPU, 16GiB，200G SSD) MySQL 5.7.19
> >
> > *Database upgrade:*
> > Composite index has been added to volume table
> (volumes__composite_index):
> >
> +-++--+--+-+---+-+--++--++-+---+
> > | Table   | Non_unique | Key_name  | Seq_in_index |
> > Column_name | Collation | Cardinality | Sub_part | Packed | Null
> |
> > Index_type | Comment | Index_comment |
> >
> +-++--+--+-+---+-+--++--++-+---+
> > |   .other index... |
> > | volumes | 1 | volumes__composite_index | 1
> |
> > project_id  | A |   2 | NULL | NULL   | YES
> |
> > BTREE  | |   |
> > | volumes | 1 | volumes__compoite_index |
>  2 |
> > deleted | A |   2 | NULL | NULL   | YES
> |
> > BTREE  | |   |
> > | volumes | 1 | volumes__composite_index | 3
> |
> > volume_type_id  | A |   2 | NULL | NULL   | YES
> |
> > BTREE  | |   |
> >
> +-++--+--+-+---+-+--++--++-+---+
> >  Explain result for one of the sql statements for new quota system
> (*explain
> > select count(*), sum(size) from volumes where project_id={project_id} and
> > volume_type_id={type_id} and deleted=false*):
> >
> >
> ++-+-++--+--+--+-+---+--+--+---+
> > | id | select_type | table   | partitions | type | possible_keys
> >  | key  | key_len | ref   | rows |
> filtered
> > | Extra |
> >
> >
> ++-+-++--+--+--+-+---+--+--+---+
> > |  1 | SIMPLE  | volumes | NULL   | ref  |
> volumes__composite_index
> > | volumes__composite_index | 881 | const,const,const |1 |
>  100.00
> > | NULL  |
> >
> >
> ++-+-++--+--+--+-+---+--+--+---+
> >
> > *Time comparsion between two system (in Seconds, * *Conc =
> Concurrency**):*
> >
> > *NOTE**:*
> >
> >   1. *QUOTAS.check_deltas*  stands for the total time consumed
> > including two sql statements as below when creating single volume:
> >
> >   1. SELECT count(id), sum(size) from volumes where
> > project_id=$(project_id) and deleted=False
>

Re: [openstack-dev] [api-wg] [api] [cinder] [nova] Support specify action name in request url

[TommyLike Hu]

Thanks Hongbin, These links are useful for me!

Hongbin Lu <hongbin...@huawei.com>于2018年1月20日周六 上午3:20写道：

> I remembered there are several discussions about action APIs in the past.
> This is one discussion I can find:
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/109136.html
> . An obvious alternative is to expose each action with an independent API
> endpoint. For example:
>
>
>
> * POST /servers//start:Start a server
>
> * POST /servers//stop:Stop a server
>
> * POST /servers//reboot:Reboot a server
>
> * POST /servers//pause:Pause a server
>
>
>
> Several people pointed out the pros and cons of either approach and other
> alternatives [1] [2] [3]. Eventually, we (OpenStack Zun team) have adopted
> the alternative approach [4] above and it works very well from my
> perspective. However, I understand that there is no consensus on this
> approach within the OpenStack community.
>
>
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/109178.html
>
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/109208.html
>
> [3]
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/109248.html
>
> [4]
> https://developer.openstack.org/api-ref/application-container/#manage-containers
>
>
>
> Best regards,
>
> Hongbin
>
>
>
> *From:* TommyLike Hu [mailto:tommylik...@gmail.com]
> *Sent:* January-18-18 5:07 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* [openstack-dev] [api-wg] [api] [cinder] [nova] Support specify
> action name in request url
>
>
>
> Hey all,
>
>Recently We found an issue related to our OpenStack action APIs. We
> usually expose our OpenStack APIs by registering them to our API Gateway
> (for instance Kong [1]), but it becomes very difficult when regarding to
> action APIs. We can not register and control them seperately because them
> all share the same request url which will be used as the identity in the
> gateway service, not say rate limiting and other advanced gateway features,
> take a look at the basic resources in OpenStack
>
>
>
>1. *Server*: "/servers/{server_id}/action"  35+ APIs are include.
>
>2. *Volume*: "/volumes/{volume_id}/action"  14 APIs are include.
>
>3. Other resource
>
>
>
> We have tried to register different interfaces with same upstream url,
> such as:
>
>
>
>   * api gateway*: /version/resource_one/action/action1 =>* upstream*:
> /version/resource_one/action
>
> *   api gateway*: /version/resource_one/action/action2 =>* upstream*:
> /version/resource_one/action
>
>
>
> But it's not secure enough cause we can pass action2 in the request body
> while invoking /action/action1, also, try to read the full body for route
> is not supported by most of the api gateways(maybe plugins) and will have a
> performance impact when proxy. So my question is do we have any solution or
> suggestion for this case? Could we support specify action name both in
> request body and url such as:
>
>
>
> *URL:/volumes/{volume_id}/action*
>
> *BODY:*{'extend':{}}
>
>
>
> and:
>
>
>
> *URL:/volumes/{volume_id}/action/extend*
>
> *BODY:* {'extend':{}}
>
>
>
> Thanks
>
> Tommy
>
>
>
> [1]: https://github.com/Kong/kong
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [api-wg] [api] [cinder] [nova] Support specify action name in request url

[TommyLike Hu]

Hey all,
   Recently We found an issue related to our OpenStack action APIs. We
usually expose our OpenStack APIs by registering them to our API Gateway
(for instance Kong [1]), but it becomes very difficult when regarding to
action APIs. We can not register and control them seperately because them
all share the same request url which will be used as the identity in the
gateway service, not say rate limiting and other advanced gateway features,
take a look at the basic resources in OpenStack

   1. *Server*: "/servers/{server_id}/action"  35+ APIs are include.
   2. *Volume*: "/volumes/{volume_id}/action"  14 APIs are include.
   3. Other resource

We have tried to register different interfaces with same upstream url, such
as:

  * api gateway*: /version/resource_one/action/action1 =>* upstream*:
/version/resource_one/action
*   api gateway*: /version/resource_one/action/action2 =>* upstream*:
/version/resource_one/action

But it's not secure enough cause we can pass action2 in the request body
while invoking /action/action1, also, try to read the full body for route
is not supported by most of the api gateways(maybe plugins) and will have a
performance impact when proxy. So my question is do we have any solution or
suggestion for this case? Could we support specify action name both in
request body and url such as:

*URL:*/volumes/{volume_id}/action
*BODY:*{'extend':{}}

and:

*URL:*/volumes/{volume_id}/action/extend
*BODY:* {'extend':{}}

Thanks
Tommy

[1]: https://github.com/Kong/kong
__
OpenStack Development Mailing 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] [security] [api] Script injection issue

[TommyLike Hu]

Based on my understanding. the BASIC LIMITATION in the API here is only a
guidance or suggestion from community. It defines the default API behaviour
and also configurable. BTW, OpenStack now doesn't have an explicit rule for
valid user input (such as name and description), and this is inconsistent
across different projects. So no matter what the agreement
we finally reach. could we document the supported characters in API? The
inconsistency and ambiguity would confuse any release provider who wants to
add the security support in API while obey the testcases in our DefCore
[1]&[2].

[1]: https://refstack.openstack.org/#/guidelines
[2]:
https://github.com/openstack/tempest/blob/c961a656ccdc0f1242b4ff3237a16d4a7cdf4e07/tempest/api/volume/test_volumes_get.py#L98


Duncan Thomas <duncan.tho...@gmail.com>于2017年11月20日周一 上午11:08写道：

> But the filtering requirements are going to be different for different
> front ends, and we can't hope to catch them all. Trying to do any filtering
> at the cinder/nova API level just provides a false sense of security -
> horizon and other UI *have* to get their escaping right. If you put
> incomplete filtering at the cinder level, it becomes more likely that
> consumers will assume they don't need to bother.
>
> On 20 Nov 2017 2:18 am, "TommyLike Hu" <tommylik...@gmail.com> wrote:
>
>> Our API service is open to any client or any API consumer. We can not
>> guarantee every frontend has the ability to protect themself from script
>> injections. Although the specific cases would differ, the security issue is
>> the same. If we have to keep asking them to add this support repeatedly,
>> Can we just define the BASIC limitation for the input?
>>
>> Tristan Cacqueray <tdeca...@redhat.com>于2017年11月17日周五 下午11:55写道：
>>
>>> On November 17, 2017 1:56 pm, Jeremy Stanley wrote:
>>> > On 2017-11-17 12:47:34 + (+), Luke Hinds wrote:
>>> >> This will need the VMT's attention, so please raise as an issue on
>>> >> launchpad and we can tag it as for the vmt members as a possible OSSA.
>>> > [...]
>>> >
>>> > Ugh, looks like someone split this thread, and I already replied to
>>> > the original thread. In short, I don't think it's safe to assume we
>>> > know what's going to be safe for different frontends and consuming
>>> > applications, so trying to play whack-a-mole with various unsafe
>>> > sequences at the API side puts the responsibility for safe filtering
>>> > in the wrong place and can lead to lax measures in the software
>>> > which should actually be taking on that responsibility.
>>> >
>>> > Of course, I'm just one voice. Others on the VMT certainly might
>>> > disagree with my opinion on this.
>>>
>>> We had similar issues[0][1] in the past where we already draw the line
>>> that it is the client responsibility to filter out API response.
>>>
>>> Thus I agree with Jeremy, perhaps it is not ideal, but at least it
>>> doesn't give a false sense of security if^Wwhen the server side
>>> filtering let unpredicted malicious content through.
>>>
>>> -Tristan
>>>
>>> [0] https://launchpad.net/bugs/1486565
>>> [1] https://launchpad.net/bugs/1649248
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] [api] Script injection issue

[TommyLike Hu]

Our API service is open to any client or any API consumer. We can not
guarantee every frontend has the ability to protect themself from script
injections. Although the specific cases would differ, the security issue is
the same. If we have to keep asking them to add this support repeatedly,
Can we just define the BASIC limitation for the input?

Tristan Cacqueray 于2017年11月17日周五 下午11:55写道：

> On November 17, 2017 1:56 pm, Jeremy Stanley wrote:
> > On 2017-11-17 12:47:34 + (+), Luke Hinds wrote:
> >> This will need the VMT's attention, so please raise as an issue on
> >> launchpad and we can tag it as for the vmt members as a possible OSSA.
> > [...]
> >
> > Ugh, looks like someone split this thread, and I already replied to
> > the original thread. In short, I don't think it's safe to assume we
> > know what's going to be safe for different frontends and consuming
> > applications, so trying to play whack-a-mole with various unsafe
> > sequences at the API side puts the responsibility for safe filtering
> > in the wrong place and can lead to lax measures in the software
> > which should actually be taking on that responsibility.
> >
> > Of course, I'm just one voice. Others on the VMT certainly might
> > disagree with my opinion on this.
>
> We had similar issues[0][1] in the past where we already draw the line
> that it is the client responsibility to filter out API response.
>
> Thus I agree with Jeremy, perhaps it is not ideal, but at least it
> doesn't give a false sense of security if^Wwhen the server side
> filtering let unpredicted malicious content through.
>
> -Tristan
>
> [0] https://launchpad.net/bugs/1486565
> [1] https://launchpad.net/bugs/1649248
> __
> OpenStack Development Mailing 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] [security] [api] Script injection issue

[TommyLike Hu]

The special character is allowed in default, tested in nova's and cinder's
master branch. And I guess most of the projects allow  those characters as
the community doesn't have a explicit red line for this :)

Adam Heczko <ahec...@mirantis.com>于2017年11月17日周五 下午8:33写道：

> Thanks TommyLike for this bug report. Sounds like Stored XSS [1].
> Could you please share more details, e.g. branch / release, APIs tested
> etc.?
>
> [1] https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting
>
> On Fri, Nov 17, 2017 at 12:36 PM, Davanum Srinivas <dava...@gmail.com>
> wrote:
>
>> Adding [api] to make sure the API (SIG?) sees this too
>>
>> On Fri, Nov 17, 2017 at 3:22 AM, TommyLike Hu <tommylik...@gmail.com>
>> wrote:
>> > Hey all,
>> >  Recently when we integrating and testing OpenStack services. We
>> found
>> > there is a potential script injection issue that some of our services
>> accept
>> > the input with special character [1] [2], for instance we can create an
>> > instance or a volume with the name of 'script inside'.
>> One
>> > of the possible solutions is add HTML encode/decode support in Horizon,
>> but
>> > it's not guaranteed every OpenStack user is using Horizon. So should we
>> > apply more strict restriction on user's input?
>> >  Also, I found  Google Cloud have a strict and explicit restrction
>> in
>> > their instance insert API document [3].
>> >
>> > [1]: Nova:
>> >
>> https://github.com/openstack/nova/blob/master/nova/api/validation/parameter_types.py#L148
>> > [2]: Cinder:
>> >
>> https://github.com/openstack/cinder/blob/master/cinder/api/openstack/wsgi.py#L1253
>> > [3]: Google Cloud:
>> > https://cloud.google.com/compute/docs/reference/latest/instances/insert
>> >
>> > Thanks
>> > TommyLike.Hu
>> >
>> >
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>>
>> --
>> Davanum Srinivas :: https://twitter.com/dims
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Adam Heczko
> Security Engineer @ Mirantis Inc.
> __
> OpenStack Development Mailing 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] [manila] Nominating Zhong Jun (zhongjun) for Manila core

[TommyLike Hu]

+1 if I can vote:) Zhongjun is always a nice and hard working people. She
keeps making a hug and continual contribution to Manila.

Thanks
TommyLike.Hu

Ravi, Goutham 于2017年11月20日周一 上午7:30写道：

> Hello Manila developers,
>
>
>
> I would like to nominate Zhong Jun (zhongjun on irc, zhongjun2 on gerrit)
> to be part of the Manila core team. Zhongjun has been an important member
> of our community since the Kilo release, and has, in the past few releases
> made significant contributions to the constellation of projects related to
> openstack/manila [1]. She is also our ambassador in the APAC
> region/timezones. Her opinion is valued amongst the core team and I think,
> as a core reviewer and maintainer, she would continue to help grow and
> maintain our project.
>
>
>
> Please respond with a +1/-1.
>
>
>
> We will not be having an IRC meeting this Thursday (23rd November 2017),
> so if we have sufficient quorum, PTL extraordinaire, Ben Swartzlander will
> confirm her nomination here.
>
>
>
> [1]
> http://stackalytics.com/?user_id=jun-zhongjun=all=person-day
>
>
>
> Thanks,
>
> Goutham
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [security] Script injection issue

[TommyLike Hu]

Hey all,
 Recently when we integrating and testing OpenStack services. We found
there is a potential script injection issue that some of our services
accept the input with special character [1] [2], for instance we can create
an instance or a volume with the name of 'script inside'.
One of the possible solutions is add HTML encode/decode support in Horizon,
but it's not guaranteed every OpenStack user is using Horizon. So should we
apply more strict restriction on user's input?
 Also, I found  Google Cloud have a strict and explicit restrction in
their instance insert API document [3].

[1]: Nova:
https://github.com/openstack/nova/blob/master/nova/api/validation/parameter_types.py#L148
[2]: Cinder:
https://github.com/openstack/cinder/blob/master/cinder/api/openstack/wsgi.py#L1253
[3]: Google Cloud:
https://cloud.google.com/compute/docs/reference/latest/instances/insert

Thanks
TommyLike.Hu
__
OpenStack Development Mailing 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 TommyLikeHu for Cinder core

[TommyLike Hu]

Thank you Sean and Cinder team. It's my honor to be a member of the big
family, looking forward to work with all of you!


Sean McGinnis 于2017年8月3日周四 上午9:21写道：

> I'm a little late getting back to it, but I have just added TommyLike
> to the Gerrit and Launchpad groups.
>
> Welcome to the Cinder core team TommyLike. We're glad to have you.
>
> Sean
>
> On Tue, Jul 25, 2017 at 03:07:08AM -0500, Sean McGinnis wrote:
> > I am proposing we add TommyLike as a Cinder core.
> >
> > DISCLAIMER: We work for the same company.
> >
> > I have held back on proposing him for some time because of this
> conflict. But
> > I think from his number of reviews [1] and code contributions [2] it's
> > hopefully clear that my motivation does not have anything to do with
> this.
> >
> > TommyLike has consistently done quality code reviews. He has contributed
> a
> > lot of bug fixes and features. And he has been available in the IRC
> channel
> > answering questions and helping out, despite some serious timezone
> > challenges.
> >
> > I think it would be great to add someone from this region so we can get
> more
> > perspective from the APAC area, as well as having someone around that may
> > help as more developers get involved in non-US and non-EU timezones.
> >
> > Cinder cores, please respond with your opinion. If no reason is given to
> do
> > otherwise, I will add TommyLike to the core group in one week.
> >
> > And absolutely call me out if you see any in bias in my proposal.
> >
> > Thanks,
> > Sean
> >
> > [1] http://stackalytics.com/report/contribution/cinder-group/90
> > [2]
> https://review.openstack.org/#/q/owner:%22TommyLike+%253Ctommylikehu%2540gmail.com%253E%22++status:merged
>
> __
> OpenStack Development Mailing 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] [Nova] Extend attached volume

[TommyLike Hu]

Hey, Mathieu Thanks for bringing us the solution, Jay and I are willing to help 
if you are looking for someone to coordinate at the Cinder side. TommyLike.Hu 
On 2017-04-04 08:50 , Mathieu Gagné Wrote: Hi, On Mon, Apr 3, 2017 at 8:40 PM, 
Jay S Bryant  wrote: > > Thank you for sharing this.  
Nice to see you have a solution that looks > agreeable to Matt.  Do you think 
you can get a spec pushed up and propose > your code? > I will go ahead, write 
the spec and contribute the implementation. Thanks -- Mathieu 
__ 
OpenStack Development Mailing List (not for usage questions) Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Cinder] [Nova] Extend attached volume

[TommyLike Hu]

There was a time when this feature had been both proposed in Cinder [1] and
Nova [2], but unfortunately no one (correct me if I am wrong) is going to
handle this feature during Pike. We do think extending an online volume is
a beneficial and mostly supported by venders feature. We really don't want
this feature missed from OpenStack and would like to continue on. So anyone
could share your knowledge of how many works are left till now and  where
should I start with?

Thanks
TommyLike.Hu

[1] https://review.openstack.org/#/c/272524/
[2]
https://blueprints.launchpad.net/nova/+spec/nova-support-attached-volume-extend
__
OpenStack Development Mailing 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] [Cinder] Refactor reset-status command for cinder resources at client side

[TommyLike Hu]

Hi cinder members,

   Eharney recently add a comment about 'resource-reset-status' command
here [1] on Dec 22, and I'd like to paste his comment here to get more
attention and discussion before the patch can go on.

 *I'd like to discuss the general design here and get input from others
before landing more reset-state commands.*
* I get the feeling that we are just copying existing things because
they are already there, but I think we can come up with something better.*
* (Note: I asked for more details about the CLI in the spec review, but
the only thing that showed up there was a command example that doesn't say
anything about defaults and  mirrors what existed already. So I think
we can get further into details now that there's code here.)*
* We also need to stop defaulting these commands to "available". It's
dangerous and almost guaranteed to produce an undesirable result for
someone who runs this without  studying --help first, which is not
good design.(I know we do this in other commands. It's wrong there, too.)*
* We could at least require input of "--state " rather than having a
default here.*

I try to figure out the his concerns there:

1. We should consider redesign the 'resource-rest-status' in the
cinderclient as we could have too many reset commands here:
   - reset-state
   - snapshot-reset-state
   - backup-reset-state
   - group-reset-state with this patch
   - group-snapshot-reset-state with this patch

  Additionly, he add a new patch [2] and try to have them covered with
a single reset command:

  (draft)cinder reset-state --type snapshot abcd-1234 --status error

2. Stop using default value 'available' for reset-status command.

3. The codes there just mirror what existed already (If the main point
here is about reduce duplication, I think this could be easily fixed by
another patch, and could be ignored).

Please leave comments here or in the patches if you are interested in.

Merry Christmas
TommyLike

[1] https://review.openstack.org/#/c/390169/
[2] https://review.openstack.org/#/c/413156/
__
OpenStack Development Mailing 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] [manila] spec detail of IPv6's export locations

[TommyLike Hu]

Hey manila memebers and driver maintainers,
  I wanna set up an new thread to talk about the proper and better
exprienced way for both end users and drivers who want use or support IPv6
in manila, and I wish this can be discussed and optimised before the
spec[1] can get ready to the next review.
 The issue was initial raise by Ben Swartzlander on the manila IPv6
spec[1] (please check PS9 line 56), and this draft only state the
export_location part which is currently fully focused in the spec.

*proposed changes**(Based on Bens' comments)** are below*:
1.  Add new share type extra_spec 'ip_version' that can indicate the access
ip version:
  * ip_version = '4' or '6' or '4&6'*. default without declaration is '4'.
2. Drivers have to report the capabilties with the ip versions that it can
support, the capability is report
   in the form: *support_ip_versions = '4' or '6' or '4&6'*. default
without override is '4'
3. The ip versions of share type's, driver supported's and share network's
will be all checked whether
   they matched before the creating of new share.
4. Driver will export the locations according the share-network's ip
version.
5. (About access rules)the ip versions of share type's and access host's
will be also checked.

Please leave any comments about your concern or just which is not clear or
missed  here.

Thanks
TommyLike.Hu

[1] https://review.openstack.org/#/c/362786/9/specs/ocata/manila-ipv6.rst
__
OpenStack Development Mailing 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] Proposed logo

[TommyLike Hu]

Vroom! Looks like a Ferrari in OpenStack

Sean McGinnis 于2016年10月26日周三 下午3:55写道：

> Hey team,
>
> Attached is the proposed new logo for the Cinder project. I think some
> have already seen this, so making sure everyone gets a chance to see it
> before it's finalized.
>
> Sean
> (smcginnis)__
> OpenStack Development Mailing 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] No weekly meeting

[TommyLike Hu]

Cool, wish I could join the next Summit~

Sean McGinnis 于2016年10月19日周三 下午4:57写道：

> Hello all,
>
> I know there are a lot of folks travelling for the Summit already. There
> are no agenda items added to the weekly meeting wiki, so I am going to
> cancel this weeks meeting.
>
> If there are any important topics or things that need to be discussed
> prior to the Summit, please bring those up in the #openstack-cinder
> channel. Responses may be delayed, but we should be able to get some
> discussion going if needed.
>
> Thanks, and I hope to see a lot of you in Barcelona!
>
> Sean (smcginnis)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Propose support generate IPv4 and IPv6 random address( or network) for documentation(test?)

[TommyLike Hu]

Thanks for your explicit explanations，I even misunderstand(maybe
superficial understand) the intentions of the random IP when I set up this
thread :)

Ihar Hrachyshka 于2016年10月19日周三 上午12:05写道：

> (To clarify for those not part of the neutron dev team, ‘fullstack’ in
> neutron gate is not devstack/tempest, and does not involve other openstack
> services, or multiple nodes.)
>
> No, we don’t dump a seed. I don’t think I saw a ‘fullstack’ failure that
> required an exact environment duplication to reproduce a test failure.
>
> For neutron ‘fullstack’ tests, we run complete neutron services, and
> collect all their logs, per test scenario. Basically, every ‘fullstack’
> test case is a tiny openstack setup with just neutron services running,
> using some common resources like amqp bus, or ovs bridge emulating physical
> infrastructure. As long as service logs are sufficient to debug failures,
> it doesn’t differ much from any other failure in neutron f.e. in tempest.
>
> It’s common for neutron to allocate a ‘random’ address from a subnet
> allocation pool for its network and instance ports, in which case we need
> to trace port-ids and whatnot to link related server/agent/tempest logs.
> (If you ask me why we randomize ip address allocation in neutron IPAM code,
> that’s actually for a reason, to reduce database contention when allocating
> addresses for parallel port requests).
>
> Ihar
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Propose support generate IPv4 and IPv6 random address( or network) for documentation(test?)

[TommyLike Hu]

Ha,thanks for your link, it's absolutely much clearer and more correct
here, and how do you think of this util function itself?

Kiall Mac Innes <ki...@macinnes.ie>于2016年10月18日周二 上午12:03写道：

> We tend to try stick with the various TEST-NET CIDRs etc as well in
> Designate, and document them here:
>
>
> http://docs.openstack.org/developer/designate/developer-guidelines.html#example-dns-names-and-ip-space
> Thanks,
> Kiall
>
>
> On 17/10/16 10:56, TommyLike Hu wrote:
>
> When I handle some stuff related to Manila recently, I found a case which
> may be suitable for Oslo, Anyhow I put it in the maillist so it can be
> discussed before I put it in action.
> In testcase, we need a function(maybe 2) to generate random ip address (or
> network), also they should in the range of [1](ipv4 documentation range) or
> [2](ipv6 documentation range), this is the draft code for ipv4:
>
> import six
> import random
>
>
> def rand_ipv4(network=False):
> """This uses the TEST-NET-3 range of reserved IP addresses."""
>
> test_net_3 = '203.0.113.'
> if network:
> host_length = random.randint(0, 8)
> address_segment = random.randint(0, 8 - host_length)
> address_segment <<= host_length
> address = test_net_3 + six.text_type(address_segment)
> address = '/'.join((address,
> six.text_type(32 - host_length)))
> else:
> address = test_net_3 + six.text_type(random.randint(0, 255))
> return address
>
> The primary use case here is writing testcases,  I am not sure whether it
> is suitable here, or maybe I misunderstood the intention of TEST-NET-3,
> please leave any comment you like.
>
>
> [1]  https://tools.ietf.org/html/rfc5737
> [2]  https://tools.ietf.org/html/rfc5156
>
>
>
>
> __
> 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.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Propose support generate IPv4 and IPv6 random address( or network) for documentation(test?)

[TommyLike Hu]

Hmm,it's used to generate the ip address for validation or rule checking,
Meanwhile add some randomness. Of course it's unreasonable the case you
mentioned, please check the existed cases [1] and [2]

[1]
https://github.com/openstack/manila/blob/master/manila_tempest_tests/tests/api/base.py#L828
[2]
https://github.com/openstack/manila/blob/master/manila_tempest_tests/tests/api/test_replication.py#L76

Doug Hellmann 于2016年10月18日周二 上午12:01写道：

> Excerpts from TommyLike Hu's message of 2016-10-17 14:46:36 +:
> > It's used in testcase already, and basic codes is from here:
> >
> https://github.com/openstack/manila/blob/master/manila_tempest_tests/utils.py#L93
>
> OK, I guess the real question I had is why use *random* addresses.
> Because that seems like a way to end up having two tests try to use the
> same address at the same time. If that did happen, would it cause
> conflicts or race conditions for the manila tests?
>
> >
> > Doug Hellmann 于2016年10月17日周一 下午10:13写道：
> >
> > > Excerpts from TommyLike Hu's message of 2016-10-17 09:56:15 +:
> > > > When I handle some stuff related to Manila recently, I found a case
> which
> > > > may be suitable for Oslo, Anyhow I put it in the maillist so it can
> be
> > > > discussed before I put it in action.
> > > > In testcase, we need a function(maybe 2) to generate random ip
> address
> > > (or
> > > > network), also they should in the range of [1](ipv4 documentation
> range)
> > > or
> > > > [2](ipv6 documentation range), this is the draft code for ipv4:
> > > >
> > > > import six
> > > > import random
> > > >
> > > >
> > > > def rand_ipv4(network=False):
> > > > """This uses the TEST-NET-3 range of reserved IP addresses."""
> > > >
> > > > test_net_3 = '203.0.113.'
> > > > if network:
> > > > host_length = random.randint(0, 8)
> > > > address_segment = random.randint(0, 8 - host_length)
> > > > address_segment <<= host_length
> > > > address = test_net_3 + six.text_type(address_segment)
> > > > address = '/'.join((address,
> > > > six.text_type(32 - host_length)))
> > > > else:
> > > > address = test_net_3 + six.text_type(random.randint(0, 255))
> > > > return address
> > > >
> > > > The primary use case here is writing testcases,  I am not sure
> whether it
> > > > is suitable here, or maybe I misunderstood the intention of
> TEST-NET-3,
> > > > please leave any comment you like.
> > > >
> > > >
> > > > [1]  https://tools.ietf.org/html/rfc5737
> > > > [2]  https://tools.ietf.org/html/rfc5156
> > >
> > > In what way are you using random addresses in tests?
> > >
> > > 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
> > >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Propose support generate IPv4 and IPv6 random address( or network) for documentation(test?)

[TommyLike Hu]

It's used in testcase already, and basic codes is from here:
https://github.com/openstack/manila/blob/master/manila_tempest_tests/utils.py#L93

Doug Hellmann 于2016年10月17日周一 下午10:13写道：

> Excerpts from TommyLike Hu's message of 2016-10-17 09:56:15 +:
> > When I handle some stuff related to Manila recently, I found a case which
> > may be suitable for Oslo, Anyhow I put it in the maillist so it can be
> > discussed before I put it in action.
> > In testcase, we need a function(maybe 2) to generate random ip address
> (or
> > network), also they should in the range of [1](ipv4 documentation range)
> or
> > [2](ipv6 documentation range), this is the draft code for ipv4:
> >
> > import six
> > import random
> >
> >
> > def rand_ipv4(network=False):
> > """This uses the TEST-NET-3 range of reserved IP addresses."""
> >
> > test_net_3 = '203.0.113.'
> > if network:
> > host_length = random.randint(0, 8)
> > address_segment = random.randint(0, 8 - host_length)
> > address_segment <<= host_length
> > address = test_net_3 + six.text_type(address_segment)
> > address = '/'.join((address,
> > six.text_type(32 - host_length)))
> > else:
> > address = test_net_3 + six.text_type(random.randint(0, 255))
> > return address
> >
> > The primary use case here is writing testcases,  I am not sure whether it
> > is suitable here, or maybe I misunderstood the intention of TEST-NET-3,
> > please leave any comment you like.
> >
> >
> > [1]  https://tools.ietf.org/html/rfc5737
> > [2]  https://tools.ietf.org/html/rfc5156
>
> In what way are you using random addresses in tests?
>
> 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
>
__
OpenStack Development Mailing 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] [oslo] Propose support generate IPv4 and IPv6 random address( or network) for documentation(test?)

[TommyLike Hu]

When I handle some stuff related to Manila recently, I found a case which
may be suitable for Oslo, Anyhow I put it in the maillist so it can be
discussed before I put it in action.
In testcase, we need a function(maybe 2) to generate random ip address (or
network), also they should in the range of [1](ipv4 documentation range) or
[2](ipv6 documentation range), this is the draft code for ipv4:

import six
import random


def rand_ipv4(network=False):
"""This uses the TEST-NET-3 range of reserved IP addresses."""

test_net_3 = '203.0.113.'
if network:
host_length = random.randint(0, 8)
address_segment = random.randint(0, 8 - host_length)
address_segment <<= host_length
address = test_net_3 + six.text_type(address_segment)
address = '/'.join((address,
six.text_type(32 - host_length)))
else:
address = test_net_3 + six.text_type(random.randint(0, 255))
return address

The primary use case here is writing testcases,  I am not sure whether it
is suitable here, or maybe I misunderstood the intention of TEST-NET-3,
please leave any comment you like.


[1]  https://tools.ietf.org/html/rfc5737
[2]  https://tools.ietf.org/html/rfc5156
__
OpenStack Development Mailing 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] [cinder] [oslo] privsep socket's client receive thread may crash without attention

[TommyLike Hu]

Hello everyone:

  I found an error when backing up a volume with oslo_privsep,it seems that
the client channel use a thread to receive socket message,but the thread
may crash with inner exception unhandled while the main procedure
continues,so I report a bug and upload a patchset to fix:
https://review.openstack.org/#/c/369786/, what I did is just ignore the
timeout exception when receiving message.
  This change seems a little arbitrary and unreasonable,so I start this
thread to raise attention,please add your advices or solutions. I will
abandon this change if any better solutions provided


Thanks
TommyLike.Hu
-- 
It is not the mountain we conquer but ourselves.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev