Re: [openstack-dev] [infra] [devstack] [smaug] gate-smaug-dsvm-fullstack-nv is failed with exit code: 2

[liuxinguo]

Hi xinyong,

I remembered that I have seen this error times ago in my CI.

Seems like nova doesn’t need noVNC before but now it needs noVNC to complete 
the installation.
You need to clone noVNC into /opt/stack/new manually, or add noVNC project to 
the $PROJECTS variable in file like: 
/home/Jenkins/workspaces/workspace/YOU-JOB-NAME/devstack-gate/devstack-vm-gate-wrap.sh

Hope that could help you:)

--
Wilson Liu

发件人: xiangxinyong [mailto:xiangxingy...@qq.com]
发送时间: 2016年5月31日 19:05
收件人: openstack-dev@lists.openstack.o
主题: [openstack-dev] [infra] [devstack] [smaug] gate-smaug-dsvm-fullstack-nv is 
failed with exit code: 2

Hello team,

The gate-smaug-dsvm-fullstack-nv is failed with exit code: 2.

The console.html [1] includes the below information:
Running devstack
ERROR: the main setup script run by this job failed - exit code: 2

The devstacklog.txt.gz [2] includes the below information:+ 
functions-common:git_clone:533:   echo 'The /opt/stack/new/noVNC project was 
not found; if this is a gate job, add'The /opt/stack/new/noVNC project was not 
found; if this is a gate job, add+ functions-common:git_clone:534:   echo 'the 
project to the $PROJECTS variable in the job definition.'the project to the 
$PROJECTS variable in the job definition.+ functions-common:git_clone:535:   
die 535 'Cloning not allowed in this configuration'+ functions-common:die:186:  
 local exitcode=0

I guess the problem is related with this file [3].
Could some one help?Thanks very much.
[1] 
http://logs.openstack.org/29/321329/2/check/gate-smaug-dsvm-fullstack-nv/c734eea/console.html
[2] 
http://logs.openstack.org/29/321329/2/check/gate-smaug-dsvm-fullstack-nv/c734eea/logs/devstacklog.txt.gz
[3] 
https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/smaug.yaml

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

[openstack-dev] [cinder] Is a volume always not attachable if it's 'migration_status' is 'migrating'?

[liuxinguo]

Hi cinder team,

When a volume's 'migration_status' is 'migrating', we've no idea whether this 
volume is able to attach to a server to use:
IF the migration way is host-copy, it is not attachable to use, but if the 
migration is handling by driver, some driver's implementation can make it 
attachable to use.

End users will always have no idea whether the volume is attachable to use 
through cinder list or cinder show command, they just know whether the volume 
is 'migrating'.

So should we have the assumption that if a volume's 'migration_status' is 
'migrating', we should take it as not attachable to use?
Need we add some flags to indicate whether a volume is attachable when it's 
'migration_status' is 'migrating'?

I raise this question because I have a little confusion about this when I 
propose this spec:
https://review.openstack.org/#/c/312853/ , anyone interesting about this can 
take a look at this spec:)

Thanks for any input!
Wilson Liu
__
OpenStack Development Mailing 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] Does the OpenStack community(or Cinder team) allow one driver to call another driver's public method?

[liuxinguo]

Hi Jon,

My basic idea is that, when we need to migrate a volume from my (vendor of) 
storage array to another backend (storage array), we will firstly call the 
other backend's create_volume() to create a volume on the other backend, 
and then we will take my backend (storage array) as a "host" and attach other 
backend's volume to our backend (storage array). And then we can migrate the 
volume from our storage array to other storage array directly and very 
efficiently.
And at last when the migration finished, we call the other backend's 
terminate_connection() to detach the volume from our storage array.

Of course, the precondition is that our backend array is connected (can copy 
data) to other backend array so we can migrate volume directly between them.

--
Wilson Liu

-邮件原件-
发件人: Jon Bernard [mailto:jbern...@tuxion.com] 
发送时间: 2016年3月23日 4:44
收件人: OpenStack Development Mailing List (not for usage questions)
抄送: Luozhen
主题: Re: [openstack-dev] [cinder] Does the OpenStack community(or Cinder team) 
allow one driver to call another driver's public method?

* liuxinguo <liuxin...@huawei.com> wrote:
> Hi Cinder team,
> 
> We are going to implement storage-assisted volume migrate in our 
> driver between different backend storage array or even different array 
> of different vendors.  This is really high-efficiency than the 
> host-copy migration between different array of different vendors.

Could you elaborate more on this?  During a volume migration operation we give 
the driver an opportunity to more-intelligently relocate the volume's data.  
This is done through the migrate_volume() method defined in the driver itself.  
If this method exists, it will be called before falling back to a byte-for-byte 
copy approach - and if it succeeds the volume is considered migrated and the 
operation returns.

Is this what you were looking for, or did you have something different in mind?

--
Jon

__
OpenStack Development Mailing 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] Does the OpenStack community(or Cinder team) allow one driver to call another driver's public method?

[liuxinguo]

Hi Cinder team,

We are going to implement storage-assisted volume migrate in our driver between 
different backend storage array or even different array of different vendors.
This is really high-efficiency than the host-copy migration between different 
array of different vendors.

To implement this, we need to call other backend's method like create_volume() 
or initialize_connection(). We can call them like the cinder/volume/manage.py:

rpcapi.create_volume(ctxt, new_volume, host['host'],
 None, None, allow_reschedule=False)

or
conn = rpcapi.initialize_connection(ctxt, volume, properties)

And my question is: Does the OpenStack community(or Cinder team) allow driver 
to call rpcapi in order to call other driver's method like create_volume() or 
initialize_connection()?


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

Re: [openstack-dev] [OpenStack-Infra] [cinder] How to configure the third party CI to be triggered only when jenkins +1

[liuxinguo]

In layout.yaml:
Delete:
  - event: patchset-created
And add:  
  - event: comment-added
  require-approval:
- verified: 1
  username: Jenkins

Works for me now, thanks for all your input!
Wilson Liu

-邮件原件-
发件人: Mikhail Medvedev [mailto:mihail...@gmail.com] 
发送时间: 2016年2月23日 20:35
收件人: OpenStack Development Mailing List (not for usage questions)
抄送: OpenStack Infra; Luozhen
主题: Re: [OpenStack-Infra] [openstack-dev] [cinder] How to configure the third 
party CI to be triggered only when jenkins +1

On Mon, Feb 22, 2016 at 7:32 PM, liuxinguo <liuxin...@huawei.com> wrote:
> Hi,
>
>
>
> There is no need to trigger third party CI if a patch does not pass 
> Jenkins Verify.
>
> I think there is a way to reach this but I’m not sure how.
>
>
>
> So is there any reference or suggestion to configure the third party 
> CI to be triggered only when jenkins +1?
>
>

If you are using zuul, then you should look into 'approval' setting in layout. 
E.g. check the current layout that Infra uses for gate
pipeline: 
https://github.com/openstack-infra/project-config/blob/6b71e8cac676e04141839eeecce3462df3a04848/zuul/layout.yaml#L41-L46.

>
> Thanks for any input!
>
>
>
> Regards,
>
> Wilson Liu
>
>
>
>
>
>
> __
>  OpenStack Development Mailing 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-Infra mailing list
openstack-in...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Infra] [cinder] How to configure the third party CI to be triggered only when jenkins +1

[liuxinguo]

Thanks for your input John Griffith, it looks like that the code you modify is 
not in layout.yaml ().
Could you tell me the exactly filename where you made the change?

Thanks very much!
Wilson Liu

发件人: John Griffith [mailto:john.griffi...@gmail.com]
发送时间: 2016年2月23日 9:40
收件人: OpenStack Development Mailing List (not for usage questions)
抄送: OpenStack Infra; Luozhen
主题: Re: [OpenStack-Infra] [openstack-dev] [cinder] How to configure the third 
party CI to be triggered only when jenkins +1



On Mon, Feb 22, 2016 at 6:32 PM, liuxinguo 
<liuxin...@huawei.com<mailto:liuxin...@huawei.com>> wrote:
Hi,

There is no need to trigger third party CI if a patch does not pass Jenkins 
Verify.
I think there is a way to reach this but I’m not sure how.

So is there any reference or suggestion to configure the third party CI to be 
triggered only when jenkins +1?

Thanks for any input!

Regards,
Wilson Liu



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
​In my case I inspect the comments and only trigger a run on either "run 
solidfire" or on a Jenkins +1.  The trick is to parse out the comments and look 
for the conditions that you are interested in.  The code looks something like 
this:

if (event.get('type', 'nill') == 'comment-added' and


'Verified+1' in event['comment'] and


cfg['AccountInfo']['project_name'] == event['change']['project'] and


event['author']['username'] == 'jenkins' and


event['change']['branch'] == 'master'):

​

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

[openstack-dev] [OpenStack-Infra][cinder] How to configure the third party CI to be triggered only when jenkins +1

[liuxinguo]

Hi,

There is no need to trigger third party CI if a patch does not pass Jenkins 
Verify.
I think there is a way to reach this but I'm not sure how.

So is there any reference or suggestion to configure the third party CI to be 
triggered only when jenkins +1?

Thanks for any input!

Regards,
Wilson Liu


__
OpenStack Development Mailing 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] Should we add 'os-initialize_connection' to Blockstorage API Document?

[liuxinguo]

Hi,

'os-initialize_connection' is a important API for Cinder to complete the volume 
attach operation,
but there is no record in Cinder(Blockstorage) API Document(1).
Also some developers want to find the description for the 
'os-initialize_connection' API.

So should we add this API to the Blockstorage API Document?

Wilson Liu
__
OpenStack Development Mailing 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] [nova][cinder]Detach a encrypted volume won't cleanup the device patch

[liuxinguo]

Hi hemna:

When we attach a encrypted volume and then detach it, the device path created 
when the volume is attached won't be cleanup.
This is probably due to nova and cinder not work coordinately when detach a 
encrypted volume.
This will cause next volume attachment fails and also cause some test cases of 
CI fail because the not cleaned up device path.

I opened a bug in os-brick(not sure it's a nova or os-brick bug:)):
https://bugs.launchpad.net/os-brick/+bug/1528092

And want to see if you have any idea about this?

Thanks!
Wilson Liu
__
OpenStack Development Mailing 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] Is there any cli command for "manage_existing"?

[liuxinguo]

Hi,
I have saw the "manage_existing" interface in cinder/contrib/volume_manager.py 
but can't find the responding cli command.
Is there any cli command for "manage_existing"? If not, who will call this api?

Thanks for any input!
Wilson Liu
__
OpenStack Development Mailing 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] How to make a mock effactive for all method of a testclass

[liuxinguo]

Hi,

In a.py we have a function:
def _change_file_mode(filepath):
utils.execute('chmod', '600', filepath, run_as_root=True)

In test_xxx.py, there is a testclass:
class DriverTestCase(test.TestCase):
def test_a(self)
...
Call a. _change_file_mode
...

def test_b(self)
...
Call a. _change_file_mode
...

I have tried to mock like mock out function _change_file_mode like this:
@mock.patch.object(a, '_change_file_mode', return_value=None)
class DriverTestCase(test.TestCase):
def test_a(self)
...
Call a. _change_file_mode
...

def test_b(self)
...
Call a. _change_file_mode
...

But the mock takes no effort, the real function _change_file_mode is still 
executed.
So how to make a mock effactive for all method of a testclass?
Thanks for any input!

Wilson Liu
__
OpenStack Development Mailing 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] About permission of cinder.conf

[liuxinguo]

Hi,

Why the permission of cinder.conf is set to 640 not 600? Can we set it to 600 
instead of 640 and is there any problems if we change it?

Any input will be appreciate, thanks!

Wilson Liu
__
OpenStack Development Mailing 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] Infortrend driver and Netapp driver cannot pass gate-cinder-python27 cause jenkins failed

[liuxinguo]

Infortrend driver and Netapp driver's failure about gate-cinder-python27 
caused Jenkins -1 at patch https://review.openstack.org/#/c/201578/,
log link: 
http://logs.openstack.org/78/201578/22/check/gate-cinder-python27/2212cdc/console.html

Engineers of Infortrend driver and Netapp driver please check if there is 
something wrong, thanks!

The error message is:

2015-08-21 04:36:51.449 |
2015-08-21 04:36:51.449 | Captured stderr:
2015-08-21 04:36:51.449 | 
2015-08-21 04:36:51.449 | cinder/zonemanager/fc_zone_manager.py:85: 
DeprecationWarning: object() takes no parameters
2015-08-21 04:36:51.449 |   class_._instance = object.__new__(class_, 
*args, **kwargs)
2015-08-21 04:36:51.449 |
2015-08-21 04:36:56.613 |
2015-08-21 04:36:56.613 | ==
2015-08-21 04:36:56.613 | Failed 2 tests - output below:
2015-08-21 04:36:56.613 | ==
2015-08-21 04:36:56.613 |
2015-08-21 04:36:56.613 | 
cinder.tests.unit.test_infortrend_common.InfortrendFCCommonTestCase.test_initialize_connection
2015-08-21 04:36:56.613 | 
--
2015-08-21 04:36:56.613 |
2015-08-21 04:36:56.613 | Captured traceback:
2015-08-21 04:36:56.613 | ~~~
2015-08-21 04:36:56.613 | Traceback (most recent call last):
2015-08-21 04:36:56.614 |   File 
/home/jenkins/workspace/gate-cinder-python27/.tox/py27/local/lib/python2.7/site-packages/mock/mock.py,
 line 1305, in patched
2015-08-21 04:36:56.614 | return func(*args, **keywargs)
2015-08-21 04:36:56.614 |   File 
cinder/tests/unit/test_infortrend_common.py, line 164, in 
test_initialize_connection
2015-08-21 04:36:56.614 | test_volume, test_connector)
2015-08-21 04:36:56.614 |   File 
/home/jenkins/workspace/gate-cinder-python27/.tox/py27/local/lib/python2.7/site-packages/oslo_concurrency/lockutils.py,
 line 252, in inner
2015-08-21 04:36:56.614 | return f(*args, **kwargs)
2015-08-21 04:36:56.614 |   File 
cinder/volume/drivers/infortrend/eonstor_ds_cli/common_cli.py, line 1264, in 
initialize_connection
2015-08-21 04:36:56.614 | volume, connector)
2015-08-21 04:36:56.614 |   File 
cinder/volume/drivers/infortrend/eonstor_ds_cli/common_cli.py, line 1276, in 
_initialize_connection_fc
2015-08-21 04:36:56.614 | self._do_fc_connection(volume, connector)
2015-08-21 04:36:56.614 |   File 
cinder/volume/drivers/infortrend/eonstor_ds_cli/common_cli.py, line 1308, in 
_do_fc_connection
2015-08-21 04:36:56.615 | channel_id = 
wwpn_channel_info[target_wwpn.upper()]['channel']
2015-08-21 04:36:56.615 | KeyError: '2000643E8C4C5F66'
2015-08-21 04:36:56.615 |
2015-08-21 04:36:56.615 |
2015-08-21 04:36:56.615 | 
cinder.tests.unit.volume.drivers.netapp.eseries.test_library.NetAppEseriesLibraryTestCase.test_initialize_connection_fc_no_target_wwpns
2015-08-21 04:36:56.615 | 
---
2015-08-21 04:36:56.615 |
2015-08-21 04:36:56.615 | Captured traceback:
2015-08-21 04:36:56.615 | ~~~
2015-08-21 04:36:56.615 | Traceback (most recent call last):
2015-08-21 04:36:56.615 |   File 
cinder/tests/unit/volume/drivers/netapp/eseries/test_library.py, line 594, in 
test_initialize_connection_fc_no_target_wwpns
2015-08-21 04:36:56.616 | get_fake_volume(), connector)
2015-08-21 04:36:56.616 |   File 
/home/jenkins/workspace/gate-cinder-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py,
 line 422, in assertRaises
2015-08-21 04:36:56.616 | self.assertThat(our_callable, matcher)
2015-08-21 04:36:56.616 |   File 
/home/jenkins/workspace/gate-cinder-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py,
 line 435, in assertThat
2015-08-21 04:36:56.616 | raise mismatch_error
2015-08-21 04:36:56.616 | testtools.matchers._impl.MismatchError: bound 
method NetAppESeriesLibrary.initialize_connection_fc of 
cinder.volume.drivers.netapp.eseries.library.NetAppESeriesLibrary object at 
0x7faf81dc43d0 returned {'driver_volume_type': 'fibre_channel', 'data': 
{'target_lun': 0, 'initiator_target_map': {'1090fa0d6754': 
['2000643e8c4c5f66']}, 'access_mode': 'rw', 'target_wwn': ['2000643e8c4c5f66'], 
'target_discovered': True}}


__
OpenStack Development Mailing 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] Detach a volume when it's under migration

[liuxinguo]

Detach a volume when it's under migration, volume status is still in-use:

1.   create vol-1

2.   attach vol-1 to a vm

3.   migrate vol-1

4.   when vol-1 is under migration, detach vol-1

5.   after vol-1 is detached, command cinder list show that the Status of 
vol-1 is still in-use.

If 'migration_status' of the volume is not None, detach process won't update 
the status of the volume to 'available':

volume_ref = _volume_get(context, volume_id, session=session)
if not remain_attachment:
# Hide status update from user if we're performing volume migration
# or uploading it to image
if (not volume_ref['migration_status'] and
not (volume_ref['status'] == 'uploading')):
volume_ref['status'] = 'available'

So how to deal with this? Dose it means that we should not detach a volume when 
it's under migration?

Thanks for any input!
__
OpenStack Development Mailing 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] Need your check whether these bps are OK for Liberty

[liuxinguo]

Hi Mike,

I kindly need your help to have a check whether the following blueprints are OK 
to be merged in Liberty:
https://blueprints.launchpad.net/cinder/+spec/huawei-storage-volume-migration-support
https://blueprints.launchpad.net/cinder/+spec/huawei-driver-fc-zone-enhancement
https://blueprints.launchpad.net/cinder/+spec/huawei-storage-multiple-pools-support
https://blueprints.launchpad.net/cinder/+spec/huawei-storage-iscsi-multipath-support
https://blueprints.launchpad.net/cinder/+spec/support-smartx-for-huawei-volume-driver
https://blueprints.launchpad.net/cinder/+spec/huawei-driver-support-retype

The corresponding code are already committed and are under review now:
https://review.openstack.org/#/c/188251/
https://review.openstack.org/#/c/188365/
https://review.openstack.org/#/c/188732/
https://review.openstack.org/#/c/202023/
https://review.openstack.org/#/c/201578/
https://review.openstack.org/#/c/201406/
https://review.openstack.org/#/c/201485/

These blueprints are all for the existing cinder driver, and just try to add 
some furthers that other drivers already have.
And the corresponding Third Party CI are reporting stably now.

I just want you to have a check whether these bps are OK for Liberty or there 
is something I forgot to do and need to complete.

Thanks and best regards,
--
Liuxinguo
__
OpenStack Development Mailing 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] Huawei CI's problem have been solved, and is reporting stably now.

[liuxinguo]

Hi Mike,

We have solved the problem of Huawei CI, and it is running and reporting stably 
now. The logs is also ok to access.

Following are the very recently patchs it have been posted to:

https://review.openstack​.org/180873
https://review.openstack​.org/186312
https://review.openstack​.org/193954
https://review.openstack​.org/195027
https://review.openstack​.org/163641
https://review.openstack​.org/196818
https://review.openstack​.org/177054
https://review.openstack​.org/184404
https://review.openstack​.org/196888
https://review.openstack​.org/193937
https://review.openstack​.org/195795
https://review.openstack​.org/193003
https://review.openstack​.org/188328
https://review.openstack​.org/194549
https://review.openstack​.org/188240
https://review.openstack​.org/196966
https://review.openstack​.org/194524
https://review.openstack​.org/196979
https://review.openstack​.org/163641
https://review.openstack​.org/195027
https://review.openstack​.org/193124
https://review.openstack​.org/194532
https://review.openstack​.org/180873
https://review.openstack​.org/139071
https://review.openstack​.org/156939
https://review.openstack​.org/196071
https://review.openstack​.org/197049
https://review.openstack​.org/197065

We will be very appreciate if you can have a consider of remove the -2 review 
to Huawei driver, thanks! ☺
The following patchs of Huawei driver is still marked as “CI failure”:
https://review.openstack.org/#/c/188240/
https://review.openstack.org/#/c/188732/
https://review.openstack.org/#/c/188365/
https://review.openstack.org/#/c/188360/
https://review.openstack.org/#/c/188251/

Thanks,
Liu

__
OpenStack Development Mailing 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] Huawei CI's problem have been solved, and is reporting normally now

[liuxinguo]

Hi Mike,

We have solved the problem of Huawei CI, and it is running and reporting stably 
now. The logs is ok to access.

The very recently patchs it have been posted to isi:
https://review.openstack.org/#/c/147726/
https://review.openstack.org/#/c/147738/

We will be very appreciate if you can have a consider of remove the -2 review 
to Huawei driver, thanks! :)

Best regards,
Liu

__
OpenStack Development Mailing 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] Will CI failures recently cause the corresponding driver removed from the L?

[liuxinguo]

Hi,
Our CI can not connect to port 29418 of review.openstack.org recently, possibly 
because the GFW filtered the access. Now we are processing this problem as soon 
as we found it.
According to the decision of Cinder Meeting 2015-06-10:
June 15th proposed drivers for Liberty without passing code in Jenkins and a 
CI will be removed. These drivers will have to submit for the M release. 
(thingeehttp://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-06-10-16.00.log.html#l-32,
 16:04:01)
Is the corresponding driver will be removed from the L for the CI failures?
The corresponding drivers I am saying have been merged into Kilo, and we will 
try to fix the problem as soon as possible.

Thanks and best regards,
Liu Xinguo

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

Re: [openstack-dev] [OpenStack-Infra] Need help! Zuul can not connect to port 29418 of review.openstack.org

[liuxinguo]

Thanks Tom, the method you provide is really a good idea, but probably it won't 
work for a 3rd CI. I have tried to change ssh to https for 3rd CI, but it is 
not a simple work like that. It related to lots of zuul code change.

-邮件原件-
发件人: Tom Fifield [mailto:t...@openstack.org] 
发送时间: 2015年6月12日 17:09
收件人: OpenStack Development Mailing List (not for usage questions); 
openstack-in...@lists.openstack.org
抄送: Luozhen
主题: Re: [OpenStack-Infra] [openstack-dev] Need help! Zuul can not connect to 
port 29418 of review.openstack.org

On 12/06/15 17:04, liuxinguo wrote:
 Hi,

 Recentlyour CI can not connect to port 29418 of 
 review.openstack.org.app:ds:recently

 Following are the failuer message, is there anyone know the reasion 
 why our CI can not cennect to 29418 of review.openstack.org?


That port on review.openstack.org currently appears to be blocked by China 
country-level firewall.

In this case, changing access from SSH to HTTPS could help avoid the block, 
like in Clark's email:

http://lists.openstack.org/pipermail/openstack-dev/2014-September/045385.html


Regards,


Tom

___
OpenStack-Infra mailing list
openstack-in...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
__
OpenStack Development Mailing 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] Does zonemanager support virtual fabric?

[liuxinguo]

Hi,

Many FC switchs have the function of virtual fabric and sometimes we need to 
manage the virtual fabric like create zone, delete zone etc.
But it seems like that there is no virtual fabric support in our zonemanager.

So can we manage virtual fabric with zonemaneger, if not, how to manage virtual 
fabric?

Any input will be apprecaite!

Thanks,
Liu
__
OpenStack Development Mailing 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] Is there any way to put the driver backend error message to the horizon

[liuxinguo]

· I’m just trying to have a  analysisapp:ds:analysis into it, maybe 
can begin with the “wrapper around the python-cinderclient” as George 
Peristerakis suggested.


发件人: Erlon Cruz [mailto:sombra...@gmail.com]
发送时间: 2015年4月27日 20:07
收件人: OpenStack Development Mailing List (not for usage questions)
抄送: Luozhen; Fanyaohong
主题: Re: [openstack-dev] [cinder] Is there any way to put the driver backend 
error message to the horizon

Alex,

Any scratch of the solution you plan to propose?

On Mon, Apr 27, 2015 at 5:57 AM, liuxinguo 
liuxin...@huawei.commailto:liuxin...@huawei.com wrote:
Thanks for your suggestion, George. But when I looked into python-cinderclient 
(not very deep), I can not find the “wrapper around the python-cinderclient” 
you have mentioned.
Could you please give me a little more hint to find the “wrapper”?

Thanks,
Liu


发件人: George Peristerakis 
[mailto:gperi...@redhat.commailto:gperi...@redhat.com]
发送时间: 2015年4月13日 23:22
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [cinder] Is there any way to put the driver backend 
error message to the horizon

Hi Lui,

I'm not familiar with the error you are trying to show, but Here's how Horizon 
typically works. In the case of cinder, we have a wrapper around the 
python-cinderclient which if the client sends a exception with a valid message, 
by default Horizon will display the exception message. The message can also be 
overridden in the translation file. So a good start is to look in 
python-cinderclient and see if you could produce a more meaningful message.


Cheers.
George
On 10/04/15 06:16 AM, liuxinguo wrote:

Hi,



When we create a volume in the horizon, there may occurrs some errors at the 
driver

backend, and the in horizon we just see a error in the volume status.



So is there any way to put the error information to the horizon so users can 
know what happened exactly just from the horizon?

Thanks,

Liu





__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribemailto: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://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] Is there any way to put the driver backend error message to the horizon

[liuxinguo]

Thanks for your suggestion, George. But when I looked into python-cinderclient 
(not very deep), I can not find the “wrapper around the python-cinderclient” 
you have mentioned.
Could you please give me a little more hint to find the “wrapper”?

Thanks,
Liu


发件人: George Peristerakis [mailto:gperi...@redhat.com]
发送时间: 2015年4月13日 23:22
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [cinder] Is there any way to put the driver backend 
error message to the horizon

Hi Lui,

I'm not familiar with the error you are trying to show, but Here's how Horizon 
typically works. In the case of cinder, we have a wrapper around the 
python-cinderclient which if the client sends a exception with a valid message, 
by default Horizon will display the exception message. The message can also be 
overridden in the translation file. So a good start is to look in 
python-cinderclient and see if you could produce a more meaningful message.


Cheers.
George
On 10/04/15 06:16 AM, liuxinguo wrote:

Hi,



When we create a volume in the horizon, there may occurrs some errors at the 
driver

backend, and the in horizon we just see a error in the volume status.



So is there any way to put the error information to the horizon so users can 
know what happened exactly just from the horizon?

Thanks,

Liu






__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribemailto: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] Report status of Huawei Volume CI from April 1

[liuxinguo]

Yes! There is a block at 80 port, and if you change it to 8088, for example 
app:ds:for%20example%20(e.g.) :
Change   http://182.138.104.27/huawei-18000-iscsi-dsvm-tempest-full/70
to  http://182.138.104.27:8088/huawei-18000-iscsi-dsvm-tempest-full/70
then it works!

And I have updated my apache configuration to ajust this.

Liu

发件人: Steve Martinelli [mailto:steve...@ca.ibm.com]
发送时间: 2015年4月6日 13:42
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [cinder] Report status of Huawei Volume CI from April 1

Just trying this out for fun (Mike's reply made me curious)

A lot of the link on the initial note weren't working for me, but this one did: 
https://review.openstack.org/#/c/169781/
and it's CI reports seem to work as well. They route me to: 
http://182.138.104.29:8088/huawei-18000-fc-dsvm-tempest-full/13/
and http://182.138.104.29:8088/huawei-18000-iscsi-dsvm-tempest-full/13/

I found that the ones that don't work (like this patch 
https://review.openstack.org/#/c/159704/) are attempting to
connect to a different ip address (and port): 
http://182.138.104.27/huawei-18000-iscsi-dsvm-tempest-full/70

Thanks,

Steve Martinelli
OpenStack Keystone Core

Mike Perez thin...@gmail.commailto:thin...@gmail.com wrote on 04/06/2015 
01:05:00 AM:

 From: Mike Perez thin...@gmail.commailto:thin...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
 Date: 04/06/2015 01:09 AM
 Subject: Re: [openstack-dev] [cinder] Report status of Huawei Volume
 CI from April 1

 On 12:47 Sat 04 Apr , liuxinguo wrote:
  Hello Cinder team,
 
  · Huawei Volume CI has posted to about forty cinder
 reviews from April 1 to now and will keep reporting stably.
  ·
  · It now runs 304 tests, passed 293 and skipped 11.
 
  The following are links to the cinder reviews our CI has posted
 results to, please check it:
  https://review.openstack.org/12‍

 I've tried a few of the links and unfortunately none of the log pages are
 loading for me. Is anyone else having luck?

 --
 Mike Perez

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribemailto: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] Huawei Volume CI have changed the port of log server from 80 to 8088

[liuxinguo]

Hi Cinder team,

Since the 80 port or our log server have some issue to be accessed from the 
public, we have changed the port from 80 to 8088.

* So if you opened a link like 
http://182.138.104.27/huawei-18000-iscsi-dsvm-tempest-full/70, please change 
the access port to 8088,
* like 
http://182.138.104.27:8088/huawei-18000-iscsi-dsvm-tempest-full/70.
*
* And I make an apologyapp:ds:make%20an%20apology for the 
inconvenientapp:ds:inconvenient when you access the CI logs:).

Liu


__
OpenStack Development Mailing 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] Please use 8088 port to access Huawei Volume CI's log instead of 80 port

[liuxinguo]

Hi Duncan,

For the 80 port of our log server is blocked by some reason, I have updated my 
apache configuretion to use 8088 port.
Hence, please change to access our CI logs use 8088 port.
For example, when you access
http://182.138.104.27/huawei-18000-iscsi-dsvm-tempest-full/89, please change to 
use 8088 port like
http://182.138.104.27:8088/huawei-18000-iscsi-dsvm-tempest-full/89/ .

I make an apologyapp:ds:make%20an%20apology for the 
inconvenientapp:ds:inconvenient to access the CI logs:).

Thanks and regards,
Liu
__
OpenStack Development Mailing 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] Please check the log access

[liuxinguo]

Hi Mike,

Please check this patch at Patch Set 3 our CI have newly posted result:
https://review.openstack.org/#/c/170770/‍

· We have changed the report link to 8088 port and it can be accessed 
successfully, needn’t to manuallyapp:ds:manually change the port to 8088 any 
more.

Thanks and regards,
Liu
__
OpenStack Development Mailing 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] Report status of Huawei Volume CI from April 1

[liuxinguo]

Hello Cinder team,

· Huawei Volume CI has posted to about forty cinder reviews from April 
1 to now and will keep reporting stably.
·
· It now runs 304 tests, passed 293 and skipped 11.

The following are links to the cinder reviews our CI has posted results to, 
please check it:
https://review.openstack.org/12‍
https://review.openstack.org/163641‍
https://review.openstack.org/169430‍
https://review.openstack.org/168177‍
https://review.openstack.org/168179‍
https://review.openstack.org/169153 ‍
https://review.openstack.org/165798‍
https://review.openstack.org/167134‍
https://review.openstack.org/169653‍
https://review.openstack.org/159704‍
https://review.openstack.org/154350‍
https://review.openstack.org/169707‍
https://review.openstack.org/164527‍
https://review.openstack.org/165688‍
https://review.openstack.org/163706‍
https://review.openstack.org/144409‍
https://review.openstack.org/169781 ‍
https://review.openstack.org/169812  ‍
https://review.openstack.org/169831  ‍
https://review.openstack.org/165655‍
https://review.openstack.org/16‍
https://review.openstack.org/17‍
https://review.openstack.org/169915‍
https://review.openstack.org/170156‍
https://review.openstack.org/170157‍
https://review.openstack.org/151567‍
https://review.openstack.org/170199‍
https://review.openstack.org/170178‍
https://review.openstack.org/163232‍
https://review.openstack.org/170588‍
https://review.openstack.org/152284 ‍
https://review.openstack.org/156904‍
https://review.openstack.org/160682‍
https://review.openstack.org/170346‍
https://review.openstack.org/170616‍
https://review.openstack.org/164692‍
https://review.openstack.org/161363‍
https://review.openstack.org/170310‍
https://review.openstack.org/169858‍
https://review.openstack.org/152475‍
https://review.openstack.org/161209‍
https://review.openstack.org/155607‍
https://review.openstack.org/168901‍
https://review.openstack.org/169060‍
https://review.openstack.org/160209‍
https://review.openstack.org/163910‍
https://review.openstack.org/159856‍
https://review.openstack.org/147476‍

· Or you can just check it at here:
· https://review.openstack.org/#/q/project:openstack/cinder,n,z
·
I will pay very close attention to the status of our CI and keep it running 
stably.
If there is any requirement our CI has not satisfied, please let us know.

Thanks and regards,
Liu

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

[openstack-dev] [OpenStack-Infra] [cinder] Status of Huawei Volume CI

[liuxinguo]

Hello Cinder team,

* Huawei Volume CI has been reporting since Decemberapp:ds:December 
20 th 2014. Now it runs
* two tempest jobs for Huawei 18000 iSCSI driver and Huawei 18000 FC 
driver.
* Considering that our drivers have been moved for the upstream, I have 
added some
* code to ensureapp:ds:ensure the jobs run against the real storage 
backend when building devstack.
*
* And now the CI is reporting much more stably and will keep running 
and reporting from now on.
* Below is a link shows the recentlyapp:ds:recently posted results 
from the CI:

https://review.openstack.org/#/q/reviewer:%22Huawei+Volume+CI%22,n,z

I kindly request that you accept our CI result and consider re-integrating
our 18000 iSCSI and 18000 FC drivers back in Kilo RC.

If there is any concern, please let us know.

Thanks and regards,
Liu


__
OpenStack Development Mailing 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] Request exemption for removal of NetApp FC drivers (no voting CI)

[liuxinguo]

I request the same consideration for Huawei 18000 iSCSI driver and 18000 FC 
driver. May I also add it to the meeting agenda?

· I promise Huawei Volume CI will become stable and reporting stably  
before March 31. Our CI will be moved to a more better environment 
tomorrowapp:ds:tomorrow or the day after 
tomorrowapp:ds:the%20day%20after%20tomorrow.
· And we also have find out why some times the job will failed. It is 
because that Jenkins allow the job builds concurrently on the same node by 
default and this will cause the job building fails. We have changed this to not 
to build job concurrently on the same node.

So I request the same exemption or FFE for Huawei 18000 iSCSI driver and Huawei 
18000 FC driver.

Thanks and best regards,
Liu
·


新国刘
华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]

Phone:
Fax:
Mobile:
Email:
地址：深圳市龙岗区坂田华为基地 邮编：518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!
发件人: Duncan Thomas [mailto:duncan.tho...@gmail.com]
发送时间: 2015年3月23日 21:28
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [cinder] Request exemption for removal of NetApp FC 
drivers (no voting CI)

Timothy
You are very welcome to add it to the meeting agenda if you feel it should be 
discussed - the agenda is open and managed on the wiki.

On 23 March 2015 at 15:15, ClaytonLuce, Timothy 
timothy.claytonl...@netapp.commailto:timothy.claytonl...@netapp.com wrote:
Mike,

Did not see a response to this request.  Please respond, we can discuss in the 
Cinder Core meeting this week.

-Original Message-
From: ClaytonLuce, Timothy 
[mailto:timothy.claytonl...@netapp.commailto:timothy.claytonl...@netapp.com]
Sent: Friday, March 20, 2015 5:27 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] Request exemption for removal of NetApp 
FC drivers (no voting CI)

Mike,

I request the same consideration being given to the Oracle driver team:

 The tag for Kilo in Cinder has already happened, so it's too late to revert. 
 We
 may be able to revisit this in Kilo RC, but I want to see your CI reporting
 reliably now to then to Cinder reviews.

We are going to try by hook or crook to scrounge/borrow equipment to put a 
quick and dirty CI together and get it reliably reporting.

Tim

From: Mike Perez thin...@gmail.commailto:thin...@gmail.com
Sent: Friday, March 20, 2015 2:55 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] Request exemption for removal of NetApp 
FC drivers (no voting CI)

On 12:33 Fri 20 Mar , ClaytonLuce, Timothy wrote:
 I'd like to point out that for NetApp FC drivers NetApp has been in
 discussions and updating progress on these drivers since their submission.

 I will point out a discussion in the Nov Core meeting where I brought up the
 challenge around FC environments and the response I received:

snip

 NetApp has in good faith been working toward implementing a CI for FC,
 I won't go into the challenges of spending $$ for lab equipment to build out
 a scalable quality CI system but suffice it to say the lab equipment is on
 order and scheduled for arrival the first part of April, at which point we
 can put in place the CI for FC.

1) We've been talking about CI's since Feburary 2014. That's really too bad
   this took so long. The deadline itself has been overly announced on the
   mailing list and Cinder IRC meetings. [1][2][3][4][5][6][7][8]

2) We have a number of FC drivers today that had no problem meeting this
   deadline that was expressed in November 2014.

3) I've barely received updates from Netapp folks on progress here. I'm the
   only point of contact, so if you weren't talking to me, then it's unknown.
   I've expressed this to a number of your engineers and in my announcements
   about the CI deadline [8]

I had to engage with Netapp to get updates, no one came to me with updates. The
last update I heard from one of your engineers was, we bought the hardware,
but it's just sitting there. That is not acceptable with us being past the
deadline, and shows a clear sign of this not being a priority.

 NetApp has been very forthcoming in our progress and have 

Re: [openstack-dev] [cinder] Request exemption for removal of NetApp FC drivers (no voting CI)

[liuxinguo]

Hi Mike,

I think what we are talking is huawei-volume-ci, not huawei-ci. It is 
huawei-volume-ci that is on behalf of huawei 18000 iSCSI and huawei 18000 FC 
driver.
Regarding to only report failures when a patch really does break your 
integration, I think huawei-volume-ci probaly should be marked as not 
stable, but not not reported. And have a look at all the other CI's report, 
I think some of them are really not stable too.
I do not understand why huawei-volume-ci is marked as not reported.

The server of review.openstack.org is located at the United States (U.S.) and 
there is really a network problem between our CI and the review server. 
Till now we are really working hard for this and our CI will be moved to a more 
stable network soon.

Mike, will you please have a consider about this? Thanks very much!

Thanks and best regards,
Liu

-邮件原件-
发件人: Mike Perez [mailto:thin...@gmail.com] 
发送时间: 2015年3月21日 6:37
收件人: OpenStack Development Mailing List (not for usage questions)
抄送: Fanyaohong
主题: Re: [openstack-dev] [cinder] Request exemption for removal of NetApp FC 
drivers (no voting CI)

On 21:53 Fri 20 Mar , Rochelle Grober wrote:
 Ditto for Huawei.  
 
 While we are not *reliably* reporting, we are reporting and the 
 necessary steps have already been taken (and more importantly, 
 approved) to get this reliably working ASAP.
 
 We respectfully request the same consideration for our cinder drivers.

The most important piece of a CI meeting the requirements is that the test pass 
with your storage solution configured in Cinder, and to only report failures 
when a patch really does break your integration. Otherwise, there is no point. 
So far, the times Huawei-ci has reported have been false failures [1].

[1] - 
https://review.openstack.org/#/q/reviewer:+huawei-ci+project:openstack/cinder,n,z

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

Re: [openstack-dev] [cinder] May you reconsider about huawei driver?

[liuxinguo]

Yes, currently our CI is not stable now, but it is really reporting, and have a 
look at all the other CI’s report, I think some of them are really not stable 
too.


The server of review.openstack.org is located at the United States (U.S.) and 
the network is really not good between our CI and the review server.

Till now we are really working hard for this and our CI will be moved to a more 
stable network soon.


· And we really have a whole test team to test our drivers out side of 
the CI, maybe more strict than the tests in CI.
·
Thanks Walt




发件人: Walter A. Boring IV [mailto:walter.bor...@hp.com]
发送时间: 2015年3月20日 23:49
收件人: openstack-dev@lists.openstack.org
主题: Re: [openstack-dev] [cinder] May you reconsider about huawei driver?

On 03/19/2015 07:13 PM, liuxinguo wrote:
Hi Mike,

I have seen the patch at https://review.openstack.org/#/c/165990/ saying that 
huawei driver will be removed because “the maintainer does not have a CI 
reporting to ensure their driver integration is successful”.

Looking at this patch, there is no CI reporting from the Huawei Volume CI check.
Your CI needs to be up and stable, running on all patches.



But in fact we really have a CI months ago and it is really reporting to 
reviews, the most resently posts are:‍

*https://review.openstack.org/#/c/165796/
Post time:‍ 2015-3-19 0:14:56

*https://review.openstack.org/#/c/164697/
Post time: 2015-3-18 23:55:37
I don't see any 3rd PARTY CI Reporting here because the patch is in merge 
conflict.



*https://review.openstack.org/164702/
Post time: 2015-3-18 23:55:37
Same



*https://review.openstack.org/#/c/152401/
Post time: 3-18 23:08:45
This patch also has NO Huawei Volume CI check results.


From what I'm seeing there isn't any consistent evidence prooving that the 
Huawei Volume CI checks are stable and running on every Cinder patch.

Walt
__
OpenStack Development Mailing 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] May you reconsider about huawei driver?

[liuxinguo]

It is huawei-volume-ci that is on behalf of huawei 18000 iSCSI and huawei 18000 
FC driver, not huawei-ci. I am sorry for these two ci names so similar.

And I think the point is: Does the requirement is really a stable CI, and if 
one CI is not stable, can it make a exemption like NetApp FC drivers?
I think this is the point.

Thanks,
Liu

-邮件原件-
发件人: Mike Perez [mailto:thin...@gmail.com] 
发送时间: 2015年3月21日 2:28
收件人: jsbry...@electronicjungle.net; OpenStack Development Mailing List (not for 
usage questions)
主题: Re: [openstack-dev] [cinder] May you reconsider about huawei driver?

On 09:41 Fri 20 Mar , Jay S. Bryant wrote:
 Mike,
 
 Looks like this removal may have been a mistake.  We should readdress.

This was not a mistake. As Walt has mentioned that CI run failed anyways. Also 
if you take a look at Huawei's CI reporting history, it's not that often AND 
not reliable [1].

This is not satisfactory meeting the requirements. If we're saying they're 
having networking issues from January to now, this really sounds like to me it 
was *not* a priority.

[1] - 
https://review.openstack.org/#/q/reviewer:+huawei-ci+project:openstack/cinder,n,z

--
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-dev] [cinder] Status of Huawei Volume CI

[liuxinguo]

Hi Mike,

Regarding the Huawei Volume CI:
As I am dealing with the CI process of Huawei, please modify the contact person 
to liuxin...@huawei.commailto:liuxin...@huawei.com, so I won't miss 
important announcements from you regarding the CI.‍


The CI of huawei 18000 ISCSI and huawei 18000 FC have posted results to lots of 
review, the most resently posts are:‍

*https://review.openstack.org/#/c/165796/
Post time:‍ 2015-3-19 0:14:56

*https://review.openstack.org/#/c/164697/
Post time: 2015-3-18 23:55:37

*https://review.openstack.org/164702/
Post time: 2015-3-18 23:55:37

*https://review.openstack.org/#/c/152401/
Post time: 3-18 23:08:45

So can this mean that the huawei 18000 ISCSI‍ and  huawei 18000 FC may probably 
be marked with a light green color as Reporting/WIP  Reporting in Cinder 
upstream, not stable‍?
‍

Thanks and regards,‍
Liu
__
OpenStack Development Mailing 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] May you reconsider about huawei driver?

[liuxinguo]

Hi Mike,

I have seen the patch at https://review.openstack.org/#/c/165990/ saying that 
huawei driver will be removed because “the maintainer does not have a CI 
reporting to ensure their driver integration is successful”.

But in fact we really have a CI months ago and it is really reporting to 
reviews, the most resently posts are:‍

*https://review.openstack.org/#/c/165796/
Post time:‍ 2015-3-19 0:14:56

*https://review.openstack.org/#/c/164697/
Post time: 2015-3-18 23:55:37

*https://review.openstack.org/164702/
Post time: 2015-3-18 23:55:37

*https://review.openstack.org/#/c/152401/
Post time: 3-18 23:08:45

And if you want, I will give you more proof of reviews.

Thanks and regards,
Liu
__
OpenStack Development Mailing 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] I will add Dorado and T CI within one week if I can't revome Dorado and T driver

[liuxinguo]

Hi Mike,

* Maybe I have a misunderstandapp:ds:misunderstand of the 
warningapp:ds:warning you said that all drivers must have a CI. I have taken 
that as if the Dorado and T driver did not have a CI then the Dorado and T 
driver will be removed from the community individually.

If I can't remove Dorado and T driver individually, will you please give me 
some time to add CI for these two drivers? I promise to add the CI for the 
following drivers within one week:

HuaweiOceanStor Dorado ISCSI

HuaweiOceanStor Dorado FC

HuaweiOceanStor T Series ISCSI

HuaweiOceanStor T Series FC

And I promise these CI can post results to cinder reviews.

Thanks and regards,
Liu



__
OpenStack Development Mailing 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] Ask for review for cinder driver patch

[liuxinguo]

Hi Mike,

I have fixed the patch as your comments and have committed it at 
https://review.openstack.org/#/c/152116/.

Would you please have a review at it, thanks!

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

[openstack-dev] [openstack-docs] Question about the patch of QoS configuration to commit

[liuxinguo]

Recently I have commit a patch in 
openstack-manuals/doc/config-reference/block-storage/drivers/huawei-storage-driver.xmlhttps://review.openstack.org/#/c/150761/8/doc/config-reference/block-storage/drivers/huawei-storage-driver.xml
 contains the QoS configuration and the reviewers said that I should not put 
the QoS configuration as Huawei specific information but in the Cloud Admin 
Guide.

The problem is I think the QoS configuration I want to commit in the patch 
might be really Huawei specific information. For example, I described how to 
create minIOPS QoS in the patch because the name minIOPS is the exactly 
name the user should use in Huawei driver. So I think these configuration is 
really Huawei specific information and I think maybe it is not appropriate to 
put these information in Cloud Admin Guide.

I am confused where to put the QoS configuration and I would be very 
appreciative if anyone can give me some ideas.

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

Re: [openstack-dev] [all] Ask for help with devstack error: 401 Unauthorized

[liuxinguo]

 related, but it seems similar (try manually backing out the 
change for cinder and see if it fixes your problem).

Good luck!
Peter

From: liuxinguo [mailto:liuxin...@huawei.com]
Sent: February-12-15 6:57 AM
To: 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org; 
openstack-in...@lists.openstack.orgmailto:openstack-in...@lists.openstack.org
Cc: Zhangli (ISSP); Fanyaohong; Chenzongliang
Subject: [openstack-dev] [all] Ask for help with devstack error

Our CI failed when building devstack, the error is about “Unauthorized”. 
Following is the segment of the devstacklog:


2015-02-12 11:16:14.639 | + is_service_enabled c-api
2015-02-12 11:16:14.646 | + return 0
2015-02-12 11:16:14.646 | + is_service_enabled tls-proxy
2015-02-12 11:16:14.646 | + _run_process c-vol '/usr/local/bin/cinder-volume 
--config-file /etc/cinder/cinder.conf' ''
2015-02-12 11:16:14.647 | + local service=c-vol
2015-02-12 11:16:14.647 | + local 'command=/usr/local/bin/cinder-volume 
--config-file /etc/cinder/cinder.conf'
2015-02-12 11:16:14.647 | + local group=
2015-02-12 11:16:14.647 | + exec
2015-02-12 11:16:14.647 | + exec
2015-02-12 11:16:14.658 | + return 1
2015-02-12 11:16:14.658 | + create_volume_types
2015-02-12 11:16:14.659 | + is_service_enabled c-api
2015-02-12 11:16:14.687 | + return 0
2015-02-12 11:16:14.688 | + [[ -n lvm:default ]]
2015-02-12 11:16:14.688 | + local be be_name be_type
2015-02-12 11:16:14.688 | + for be in '${CINDER_ENABLED_BACKENDS//,/ }'
2015-02-12 11:16:14.688 | + be_type=lvm
2015-02-12 11:16:14.688 | + be_name=default
2015-02-12 11:16:14.689 | + cinder type-create default
2015-02-12 11:16:22.734 | ERROR: Unauthorized (HTTP 401) (Request-ID: 
req-33c9392a-046f-4894-b22a-1a119eacec62)‍

In c-api.log, I find the error with “auth_token”:

2015-02-12 03:16:19.722 19912 WARNING keystonemiddleware.auth_token [-] 
Retrying on HTTP connection exception: SSL exception connecting to 
https://127.0.0.1:35357/
2015-02-12 03:16:20.723 19912 DEBUG keystoneclient.session [-] REQ: curl -g -i 
--cacert /opt/stack/data/ca-bundle.pem -X GET https://127.0.0.1:35357/ -H 
Accept: application/json -H User-Agent: python-keystoneclient 
_http_log_request 
/opt/stack/new/python-keystoneclient/keystoneclient/session.py:190
2015-02-12 03:16:20.724 19912 DEBUG urllib3.util.retry [-] Converted retries 
value: 0 - Retry(total=0, connect=None, read=None, redirect=0) from_int 
/usr/local/lib/python2.7/dist-packages/urllib3/util/retry.py:155
2015-02-12 03:16:22.730 19912 ERROR keystonemiddleware.auth_token [-] HTTP 
connection exception: SSL exception connecting to https://127.0.0.1:35357/
2015-02-12 03:16:22.731 19912 WARNING keystonemiddleware.auth_token [-] 
Authorization failed for token‍

Any one can give me some help?
Thanks!
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] Ask for help with devstack error

[liuxinguo]

Our CI failed when building devstack, the error is about “Unauthorized”. 
Following is the segment of the devstacklog:


2015-02-12 11:16:14.639 | + is_service_enabled c-api
2015-02-12 11:16:14.646 | + return 0
2015-02-12 11:16:14.646 | + is_service_enabled tls-proxy
2015-02-12 11:16:14.646 | + _run_process c-vol '/usr/local/bin/cinder-volume 
--config-file /etc/cinder/cinder.conf' ''
2015-02-12 11:16:14.647 | + local service=c-vol
2015-02-12 11:16:14.647 | + local 'command=/usr/local/bin/cinder-volume 
--config-file /etc/cinder/cinder.conf'
2015-02-12 11:16:14.647 | + local group=
2015-02-12 11:16:14.647 | + exec
2015-02-12 11:16:14.647 | + exec
2015-02-12 11:16:14.658 | + return 1
2015-02-12 11:16:14.658 | + create_volume_types
2015-02-12 11:16:14.659 | + is_service_enabled c-api
2015-02-12 11:16:14.687 | + return 0
2015-02-12 11:16:14.688 | + [[ -n lvm:default ]]
2015-02-12 11:16:14.688 | + local be be_name be_type
2015-02-12 11:16:14.688 | + for be in '${CINDER_ENABLED_BACKENDS//,/ }'
2015-02-12 11:16:14.688 | + be_type=lvm
2015-02-12 11:16:14.688 | + be_name=default
2015-02-12 11:16:14.689 | + cinder type-create default
2015-02-12 11:16:22.734 | ERROR: Unauthorized (HTTP 401) (Request-ID: 
req-33c9392a-046f-4894-b22a-1a119eacec62)‍

In c-api.log, I find the error with “auth_token”:

2015-02-12 03:16:19.722 19912 WARNING keystonemiddleware.auth_token [-] 
Retrying on HTTP connection exception: SSL exception connecting to 
https://127.0.0.1:35357/
2015-02-12 03:16:20.723 19912 DEBUG keystoneclient.session [-] REQ: curl -g -i 
--cacert /opt/stack/data/ca-bundle.pem -X GET https://127.0.0.1:35357/ -H 
Accept: application/json -H User-Agent: python-keystoneclient 
_http_log_request 
/opt/stack/new/python-keystoneclient/keystoneclient/session.py:190
2015-02-12 03:16:20.724 19912 DEBUG urllib3.util.retry [-] Converted retries 
value: 0 - Retry(total=0, connect=None, read=None, redirect=0) from_int 
/usr/local/lib/python2.7/dist-packages/urllib3/util/retry.py:155
2015-02-12 03:16:22.730 19912 ERROR keystonemiddleware.auth_token [-] HTTP 
connection exception: SSL exception connecting to https://127.0.0.1:35357/
2015-02-12 03:16:22.731 19912 WARNING keystonemiddleware.auth_token [-] 
Authorization failed for token‍

Any one can give me some help?
Thanks!
__
OpenStack Development Mailing 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] Question about the plan of L

[liuxinguo]

Our driver have been merged into Kilo before K-1 and have implemented many 
features, so I think our driver is not a new driver.

For these drivers aleady merged in Kilo and if they want add some new features, 
does they should be merged before L-1 too?



Thanks,

Liu



Yes, assume NEW drivers have to land in before the L-1 milestone.  This

also includes getting a CI system up and running.



Walt



 Hi,



 In Kilo the cinder driver is requested to be merged before K-1, I want

 to ask that in L does the driver will be requested to be merged before

 L-1?



 Thanks and regards,



 Liu

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

Re: [openstack-dev] [openstack-infra] CI failed with 401 Unauthorized when build devstack

[liuxinguo]

I updated the lib/swift file and the devstack build failded with the same error 
when uploading image.

I commented the script in stack.sh to disable the uploading image procedure, 
but the build still failed when running cinder type-create default , the 
error is still  Unauthorized :

2015-02-10 07:10:03.254 | + is_service_enabled c-api
2015-02-10 07:10:03.254 | + local service=c-vol
2015-02-10 07:10:03.254 | + local 'command=/usr/local/bin/cinder-volume 
--config-file /etc/cinder/cinder.conf'
2015-02-10 07:10:03.254 | + local group=
2015-02-10 07:10:03.254 | + exec
2015-02-10 07:10:03.254 | + exec
2015-02-10 07:10:03.259 | + return 0
2015-02-10 07:10:03.259 | + is_service_enabled tls-proxy
2015-02-10 07:10:03.365 | + return 1
2015-02-10 07:10:03.365 | + create_volume_types
2015-02-10 07:10:03.365 | + is_service_enabled c-api
2015-02-10 07:10:03.393 | + return 0
2015-02-10 07:10:03.393 | + [[ -n lvm:default ]]
2015-02-10 07:10:03.393 | + local be be_name be_type
2015-02-10 07:10:03.393 | + for be in '${CINDER_ENABLED_BACKENDS//,/ }'
2015-02-10 07:10:03.393 | + be_type=lvm
2015-02-10 07:10:03.393 | + be_name=default
2015-02-10 07:10:03.393 | + cinder type-create default
2015-02-10 07:10:11.416 | ERROR: Unauthorized (HTTP 401) (Request-ID: 
req-237ec280-2cda-4864-ac9a-d708d4e4de70)
2015-02-10 07:10:11.459 | ++ err_trap
2015-02-10 07:10:11.460 | ++ local r=1
2015-02-10 07:10:11.460 | stack.sh failed: full log in 
/opt/stack/new/devstacklog.txt.2015-02-09-230158

In c-api.log, I found this:
2015-02-09 23:10:07.751 3894 ERROR keystonemiddleware.auth_token [-] HTTP 
connection exception: SSL exception connecting to https://127.0.0.1:35357/
2015-02-09 23:10:07.751 3894 WARNING keystonemiddleware.auth_token [-] 
Authorization failed for token

I think there is something wrong with the keyston, but I don't know how to deal 
with it, all the source files have updated to the latest.


Date: Fri, 6 Feb 2015 13:11:13 +
From: Bob Ball bob.b...@citrix.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
openstack-in...@lists.openstack.org
openstack-in...@lists.openstack.org
Cc: Zhangli \(ISSP\) zhangl...@huawei.com, Fanyaohong
fanyaoh...@huawei.com, Chenzongliang chenzongli...@huawei.com
Subject: Re: [openstack-dev] [OpenStack-Infra] Devstack error when
running g-reg: 401 Unauthorized
Message-ID:
bb824ea959b82f43820ffee5e6b00aa625ad2...@amspex01cl01.citrite.net
Content-Type: text/plain; charset=cp1256

This is likely https://launchpad.net/bugs/1415795 which is fixed by 
https://review.openstack.org/#/c/151506/

Make sure you have the above change in your devstack and it should work again.

Bob

From: liuxinguo [mailto:liuxin...@huawei.com]
Sent: 06 February 2015 03:08
To: OpenStack Development Mailing List (not for usage questions); 
openstack-in...@lists.openstack.org
Cc: Zhangli (ISSP); Fanyaohong; Chenzongliang
Subject: [openstack-dev] [OpenStack-Infra] Devstack error when running g-reg: 
401 Unauthorized

Our CI get the following error when build devstack, begin from service ?g-reg? 
when uploading image:

is_service_enabled g-reg
2015-02-05 03:14:54.966 | + return 0
2015-02-05 03:14:54.968 | ++ keystone token-get
2015-02-05 03:14:54.968 | ++ grep ' id '
2015-02-05 03:14:54.969 | ++ get_field 2
2015-02-05 03:14:54.970 | ++ local data field
2015-02-05 03:14:54.970 | ++ read data
2015-02-05 03:14:55.797 | ++ '[' 2 -lt 0 ']'
2015-02-05 03:14:55.798 | ++ field='$3'
2015-02-05 03:14:55.799 | ++ echo '| id| 
9660a765e04d4d0a8bc3f0f44b305161 |'
2015-02-05 03:14:55.800 | ++ awk '-F[ \t]*\\|[ \t]*' '{print $3}'
2015-02-05 03:14:55.802 | ++ read data
2015-02-05 03:14:55.804 | + TOKEN=9660a765e04d4d0a8bc3f0f44b305161
2015-02-05 03:14:55.804 | + die_if_not_set 1137 TOKEN 'Keystone fail to get 
token'
2015-02-05 03:14:55.804 | + local exitcode=0
2015-02-05 03:14:55.810 | + echo_summary 'Uploading images'
2015-02-05 03:14:55.810 | + [[ -t 3 ]]
2015-02-05 03:14:55.810 | + [[ True != \T\r\u\e ]]
2015-02-05 03:14:55.810 | + echo -e Uploading images
2015-02-05 03:14:55.810 | + [[ -n '' ]]
2015-02-05 03:14:55.810 | + for image_url in '${IMAGE_URLS//,/ }'
2015-02-05 03:14:55.811 | + upload_image 
http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-uec.tar.gz 
9660a765e04d4d0a8bc3f0f44b305161
2015-02-05 03:14:55.811 | + local 
image_url=http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-uec.tar.gz
2015-02-05 03:14:55.811 | + local token=9660a765e04d4d0a8bc3f0f44b305161
2015-02-05 03:14:55.811 | + local image image_fname image_name
2015-02-05 03:14:55.811 | + mkdir -p /opt/stack/new/devstack/files/images
2015-02-05 03:14:55.813 | ++ basename 
http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-uec.tar.gz
2015-02-05 03:14:55.815 | + image_fname=cirros-0.3.2-x86_64-uec.tar.gz
2015-02-05 03:14:55.815 | + [[ 
http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-uec.tar.gz != file* 
]]
2015-02-05 03:14

[openstack-dev] [cinder] Question about the plan of L

[liuxinguo]

Hi,

In Kilo the cinder driver is requested to be merged before K-1, I want to ask 
that in L does the driver will be requested to be merged before L-1?

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

[openstack-dev] [OpenStack-Infra] Devstack error when running g-reg: 401 Unauthorized

[liuxinguo]

Our CI get the following error when build devstack, begin from service ‘g-reg’ 
when uploading image:

is_service_enabled g-reg
2015-02-05 03:14:54.966 | + return 0
2015-02-05 03:14:54.968 | ++ keystone token-get
2015-02-05 03:14:54.968 | ++ grep ' id '
2015-02-05 03:14:54.969 | ++ get_field 2
2015-02-05 03:14:54.970 | ++ local data field
2015-02-05 03:14:54.970 | ++ read data
2015-02-05 03:14:55.797 | ++ '[' 2 -lt 0 ']'
2015-02-05 03:14:55.798 | ++ field='$3'
2015-02-05 03:14:55.799 | ++ echo '| id| 
9660a765e04d4d0a8bc3f0f44b305161 |'
2015-02-05 03:14:55.800 | ++ awk '-F[ \t]*\\|[ \t]*' '{print $3}'
2015-02-05 03:14:55.802 | ++ read data
2015-02-05 03:14:55.804 | + TOKEN=9660a765e04d4d0a8bc3f0f44b305161
2015-02-05 03:14:55.804 | + die_if_not_set 1137 TOKEN 'Keystone fail to get 
token'
2015-02-05 03:14:55.804 | + local exitcode=0
2015-02-05 03:14:55.810 | + echo_summary 'Uploading images'
2015-02-05 03:14:55.810 | + [[ -t 3 ]]
2015-02-05 03:14:55.810 | + [[ True != \T\r\u\e ]]
2015-02-05 03:14:55.810 | + echo -e Uploading images
2015-02-05 03:14:55.810 | + [[ -n '' ]]
2015-02-05 03:14:55.810 | + for image_url in '${IMAGE_URLS//,/ }'
2015-02-05 03:14:55.811 | + upload_image 
http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-uec.tar.gz 
9660a765e04d4d0a8bc3f0f44b305161
2015-02-05 03:14:55.811 | + local 
image_url=http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-uec.tar.gz
2015-02-05 03:14:55.811 | + local token=9660a765e04d4d0a8bc3f0f44b305161
2015-02-05 03:14:55.811 | + local image image_fname image_name
2015-02-05 03:14:55.811 | + mkdir -p /opt/stack/new/devstack/files/images
2015-02-05 03:14:55.813 | ++ basename 
http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-uec.tar.gz
2015-02-05 03:14:55.815 | + image_fname=cirros-0.3.2-x86_64-uec.tar.gz
2015-02-05 03:14:55.815 | + [[ 
http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-uec.tar.gz != file* 
]]
2015-02-05 03:14:55.815 | + [[ ! -f 
/opt/stack/new/devstack/files/cirros-0.3.2-x86_64-uec.tar.gz ]]
2015-02-05 03:14:55.816 | ++ stat -c %s 
/opt/stack/new/devstack/files/cirros-0.3.2-x86_64-uec.tar.gz
2015-02-05 03:14:55.818 | + [[ 8655821 = \0 ]]
2015-02-05 03:14:55.818 | + 
image=/opt/stack/new/devstack/files/cirros-0.3.2-x86_64-uec.tar.gz
2015-02-05 03:14:55.819 | + [[ 
http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-uec.tar.gz =~ openvz 
]]
2015-02-05 03:14:55.819 | + [[ 
http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-uec.tar.gz =~ \.vmdk 
]]
2015-02-05 03:14:55.819 | + [[ 
http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-uec.tar.gz =~ 
\.vhd\.tgz ]]
2015-02-05 03:14:55.819 | + [[ 
http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-uec.tar.gz =~ 
\.xen-raw\.tgz ]]
2015-02-05 03:14:55.819 | + local kernel=
2015-02-05 03:14:55.819 | + local ramdisk=
2015-02-05 03:14:55.819 | + local disk_format=
2015-02-05 03:14:55.819 | + local container_format=
2015-02-05 03:14:55.819 | + local unpack=
2015-02-05 03:14:55.819 | + local img_property=
2015-02-05 03:14:55.819 | + case $image_fname in
2015-02-05 03:14:55.819 | + '[' cirros-0.3.2-x86_64-uec '!=' 
cirros-0.3.2-x86_64-uec.tar.gz ']'
2015-02-05 03:14:55.819 | + image_name=cirros-0.3.2-x86_64-uec
2015-02-05 03:14:55.819 | + local 
xdir=/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec
2015-02-05 03:14:55.819 | + rm -Rf 
/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec
2015-02-05 03:14:55.912 | + mkdir 
/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec
2015-02-05 03:14:55.913 | + tar -zxf 
/opt/stack/new/devstack/files/cirros-0.3.2-x86_64-uec.tar.gz -C 
/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec
2015-02-05 03:14:56.619 | ++ for f in '$xdir/*-vmlinuz*' '$xdir/aki-*/image'
2015-02-05 03:14:56.619 | ++ '[' -f 
/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec/cirros-0.3.2-x86_64-vmlinuz
 ']'
2015-02-05 03:14:56.619 | ++ echo 
/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec/cirros-0.3.2-x86_64-vmlinuz
2015-02-05 03:14:56.619 | ++ break
2015-02-05 03:14:56.620 | ++ true
2015-02-05 03:14:56.620 | + 
kernel=/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec/cirros-0.3.2-x86_64-vmlinuz
2015-02-05 03:14:56.621 | ++ for f in '$xdir/*-initrd*' '$xdir/ari-*/image'
2015-02-05 03:14:56.622 | ++ '[' -f 
/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec/cirros-0.3.2-x86_64-initrd
 ']'
2015-02-05 03:14:56.622 | ++ echo 
/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec/cirros-0.3.2-x86_64-initrd
2015-02-05 03:14:56.622 | ++ break
2015-02-05 03:14:56.622 | ++ true
2015-02-05 03:14:56.623 | + 
ramdisk=/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec/cirros-0.3.2-x86_64-initrd
2015-02-05 03:14:56.624 | ++ for f in '$xdir/*.img' '$xdir/ami-*/image'
2015-02-05 03:14:56.624 | ++ '[' -f 
/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec/cirros-0.3.2-x86_64-blank.img
 ']'
2015-02-05 03:14:56.625 | ++ echo 

[openstack-dev] [all] Question about import module

[liuxinguo]

* I have seen that the module 'oslo.config' have changed to 
'oslo_config' in Kilo but in Juno it is still 'oslo.config'.

I want my code work compatibly both for Juno and Kilo so I import this module 
in this way:

try:
from oslo_config import cfg
except:
from oslo.config import cfg

* Does this way of importing module will be accepted by the 
communityapp:ds:community? Or is there any other better wayapp:ds:way?

Thanks and regards,
Liu

__
OpenStack Development Mailing 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][3rd CI] Confused about “*real* storage backend”requirement for 3rd CI.

[liuxinguo]

It still can not work. 

My local.conf is:

[[post-config|\$CINDER_CONF]]
[DEFAULT]
enabled_backends=huawei_18000
[huawei_18000]
volume_driver=cinder.volume.drivers.huawei.HuaweiVolumeDriver
cinder_huawei_conf_file=/etc/cinder/cinder_huawei_conf.xml

And the resulted cinder.conf is:

[DEFAULT]
default_volume_type = default
enabled_backends = default
[default]
volume_group = stack-volumes-default
volume_driver = cinder.volume.drivers.lvm.LVMISCSIDriver
volume_backend_name = default

Looks like it did not work as I expected. Is there anything I am wrong?

Thanks and regards,
Liu


-邮件原件-
发件人: Mike Perez [mailto:thin...@gmail.com] 
发送时间: 2015年1月24日 3:08
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [Cinder][3rd CI] Confused about “*real* storage 
backend”requirement for 3rd CI.

On 11:30 Fri 23 Jan , Bharat Kumar wrote:
 Liu,
 
 Yes, by default DevStack configures cinder with LVM. But we can 
 customize DevStack to configure cinder with our own backend (real 
 storage backend).
 
 Below is the link to the path, enables Automatic Configuration of 
 GlusterFS for Cinder using devstack:
 https://review.openstack.org/#/c/133102/
 
 And also below it the link to Configure CEPH with Cinder using devstack:
 https://review.openstack.org/#/c/65113/
 
 Above two are old way of real storage plugin implementation. Sean 
 Dague proposed a new way of devstack plugin implementation. Have a 
 look at below two links:
 https://review.openstack.org/#/c/142805/
 https://review.openstack.org/#/c/142805/7/doc/source/plugins.rst

Just want to clarify that you don't have to make any changes in upstream 
devstack to configure devstack to use your volume driver. Information for 
configuring Devstack to use your driver as mentioned earlier can be found here:

https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#How_do_I_configure_DevStack_so_my_Driver_Passes_Tempest.3F

--
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-dev] [Cinder][3rd CI] Confused about “*real* storage backend”requirement for 3rd CI.

[liuxinguo]

Hi Mike,



I received a email named “All Cinder Drivers Must Have a Third Party CI By 
March 19th 2015” and I feel confused about the “*real* storage backend”.



One of the requirements is: Run Tempest [5][6] volume tests against the 
devstack environment that's hooked up to your *real* storage backend.


· And my confusion is:
· Every time the CI is triggered by a newly came patch, the 3rd CI will 
build a new devstack environment and create a default cinder.conf file whick 
will set the backend to “lvmdriver-1” automaticallyapp:ds:automatically. And 
the tempest will run against “lvmdriver-1”. So what’s the meaning for a *real* 
storage backend since the cinder.conf will be set to use “lvmdriver-1” 
automaticallyapp:ds:automatically for every newly came patch ? And how should 
I configure the cinder.conf file to run the tempest for the newly came driver 
patch came from different venders since different venders need different 
configuration for cinder.conf file and need different storage backend. I mean, 
does our CI should run tempest against our *real* storage backend for every 
newly came driver patch in cinder?

Thanks and regards,
Liu
__
OpenStack Development Mailing 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] [Neutron] grenade failures

[liuxinguo]

Mine in cinder failed too.
https://review.openstack.org/#/c/143765/

Please check it, thanks.

liu


新国刘
华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]

Phone:
Fax:
Mobile:
Email:
地址：深圳市龙岗区坂田华为基地 邮编：518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!
发件人: yatin kumbhare [mailto:yatinkumbh...@gmail.com]
发送时间: 2015年1月14日 17:58
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [Neutron] grenade failures

Many of them on gerrit page.

Mine is also one of them.
https://review.openstack.org/#/c/145290/

Regards,
Yatin

On Wed, Jan 14, 2015 at 2:21 PM, Miguel Ángel Ajo 
majop...@redhat.commailto:majop...@redhat.com wrote:
Hi Sukhdev, thanks,
Can you post links to the specific patches?

Miguel Ángel Ajo


On Wednesday, 14 de January de 2015 at 09:01, Sukhdev Kapur wrote:
Hi All,

I noticed that several neutron patches are failing check-grenade-dsvm-neutron. 
I pinged it on IRC, did not get any response, thought I post it here.


-Sukhdev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribemailto: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://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] [Jenkins gate failure] Can not find any error for my patch.

[liuxinguo]

Hi all,

I have commit a bug-fix patch and it have passed the Jenkins check, but in 
Jenkins gate it failed for 
gate-cinder-python27http://logs.openstack.org/65/143765/9/gate/gate-cinder-python27/2e7afd6/.
I have dig into the error log but can not see anything wrong in my patch code.

Review page is:  https://review.openstack.org/#/c/143765/
And the error log for 
gate-cinder-python27http://logs.openstack.org/65/143765/9/gate/gate-cinder-python27/2e7afd6/
 in Jenkins gate can be seen in the attachmentapp:ds:attachment.

Appreciate for any input, thanks!

liu
__
OpenStack Development Mailing 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] 答复: [devstack] Opensatck installation issue.

[liuxinguo]

Hi Abhishek,

For the error in the first line:
“mkdir: cannot create directory `/logs': Permission denied”
and the error at the end:
“ln: failed to create symbolic link `/logs/screen/screen-key.log': No such file 
or directory”

The stack user does not have the permission on “/” so it can not create 
directory `/logs'.

Please check the permission.

liu

发件人: Abhishek Shrivastava [mailto:abhis...@cloudbyte.com]
发送时间: 2015年1月9日 15:26
收件人: OpenStack Development Mailing List (not for usage questions)
主题: [openstack-dev] [devstack] Opensatck installation issue.

Hi,

I'm trying to install Openstack through devstack master on my Ubuntu 12.04 VM, 
but it is failing and generating the following error.

If anyone can help me resolving this issue please do reply.

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

[openstack-dev] [cinder bug commit] How to commit a bug which depends on another bug that have not been merged?

[liuxinguo]

Hi all,

* I have commit a bug and it is not yet merged. Now I want to commit 
another bug but this bug is depends on the previousapp:ds:previous one which 
have not been merged?
* So how should I do? Should I commit the latterapp:ds:latter bug 
directly or wait the previousapp:ds:previous bug to be merged?

Any input will be appreciated, thanks!

liu

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

[openstack-dev] [nova blueprint] Ask for the blueprint of Enhance iSCSI volume multipath support.

[liuxinguo]

Hi all,

I have seen that the blueprint of Enhance iSCSI multipath support for cinder 
have been approved and target in 
kilo-2https://launchpad.net/cinder/+milestone/kilo-2, I want to know that 
will the blueprint of Enhance iSCSI volume multipath support for nova be 
implemented in Kilo?

Any input will be appreciated, thanks!
liu
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [docs] Question about submit docs

[liuxinguo]

We have opened a bug for document of huawei storage driver, and have posted the 
document at https://review.openstack.org/#/c/143926/‍.

Now I have two things not very clear:
1. When will be this document merged into Kilo? At the end of K-2 or will a 
little earlier?
2. What should we do if we want amend the document both in IceHouse and Juno? 
Should I use “git cherry-pick” and how to use “git cherry-pick”?

Any input will be appreciated, thanks!
--
Liu



新国刘
华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]

Phone:
Fax:
Mobile:
Email:
地址：深圳市龙岗区坂田华为基地 邮编：518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Have added mapping for huawei-storage-drivers

[liuxinguo]

Hi Mike,

Sorry to delay so long. Now we have added a mapping in 
cinder/volume/manager.pyhttps://review.openstack.org/#/c/133193/25/cinder/volume/manager.py
 and add a file named 
test_huawei_drivers_compatibility.pyhttps://review.openstack.org/#/c/133193/25/cinder/tests/test_huawei_drivers_compatibility.py
 to test the compatibility, please check it, thanks.

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

[openstack-dev] [devstack] image create mysql error

[liuxinguo]

When our CI run devstack, it occurs error when run  image create mysql. Log 
is pasted as following:

  22186 2014-11-29 21:11:48.611 | ++ basename 
/opt/stack/new/devstack/files/mysql.qcow2 .qcow2
  22187 2014-11-29 21:11:48.623 | + image_name=mysql
  22188 2014-11-29 21:11:48.624 | + disk_format=qcow2
  22189 2014-11-29 21:11:48.624 | + container_format=bare
  22190 2014-11-29 21:11:48.624 | + is_arch ppc64
  22191 2014-11-29 21:11:48.628 | ++ uname -m
  22192 2014-11-29 21:11:48.710 | + [[ i686 == \p\p\c\6\4 ]]
  22193 2014-11-29 21:11:48.710 | + '[' bare = bare ']'
  22194 2014-11-29 21:11:48.710 | + '[' '' = zcat ']'
  22195 2014-11-29 21:11:48.710 | + openstack --os-token 
5387fe9c6f6d4182b09461fe232501db --os-url 
http://127.0.0.1:9292http://127.0.0.1:9292/ image create mysql --public 
--container-format=bare --disk-format qcow2
  22196 2014-11-29 21:11:57.275 | ERROR: openstack html
  22197 2014-11-29 21:11:57.275 |  head
  22198 2014-11-29 21:11:57.275 |   title401 Unauthorized/title
  22199 2014-11-29 21:11:57.275 |  /head
  22200 2014-11-29 21:11:57.275 |  body
  22201 2014-11-29 21:11:57.275 |   h1401 Unauthorized/h1
  22202 2014-11-29 21:11:57.275 |   This server could not verify that you are 
authorized to access the document you requested. Either you supplied the wrong 
credentials (e.g., bad password), or your browser does not understand how to 
supply the credentials required.br /br /
  22203 2014-11-29 21:11:57.275 |
  22204 2014-11-29 21:11:57.276 |  /body
  22205 2014-11-29 21:11:57.276 | /html (HTTP 401)
  22206 2014-11-29 21:11:57.344 | + exit_trap

* Any one can give me some hintapp:ds:hint?
* Thanks.


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

[openstack-dev] Ask for spec review, thanks!

[liuxinguo]

We have submitted our spec just a few days ago while I have heared that we 
should have our spec to be approved before 15/11/2014 if we want our cinder 
driver merged in Kilo. Just few days left!

Having our cinder driver merged into Kilo is turely important for us, so I 
would be very appreciate if someone can have a review at our spec.

Our blueprint is: huawei-storage-drivers
  
And sorry for thar our spec submited so late, next time we will submit our spec 
just at the beginning.

Regards,

Liu

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

[openstack-dev] [cinder]How to do the cert test?

[liuxinguo]

I have read the related article in 
https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers, but I still 
have a little confused about the cert test:

1. Should I run the the tempest (at https://github.com/openstack/tempest) in 
our own 3rd party CI test environment? Our 3rd party CI have already set up.
2. How should I post the result and where to post?
3. Is there any thing else should I do for our driver to passes the cert test 
and the results are posted?

Thanks,

Liu

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