Re: [openstack-dev] [OpenStack-Dev][Nova] - https://launchpad.net/bugs/1667794 Changing hostname not to be treated as a pattern instead exact match will be done.

2017-07-26 Thread nidhi.h...@wipro.com 
Thanks Matt,

Thanks for explaining this well.

and bug is being taken care by chris now.

Thanks
Nidhi


-Original Message-
From: Matt Riedemann [mailto:mriede...@gmail.com]
Sent: Wednesday, July 26, 2017 10:06 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [OpenStack-Dev][Nova] - 
https://launchpad.net/bugs/1667794 Changing hostname not to be treated as a 
pattern instead exact match will be done.

** This mail has been sent from an external source. Treat hyperlinks and 
attachments in this email with caution**

On 7/26/2017 11:34 AM, Matt Riedemann wrote:
> On 7/26/2017 11:23 AM, Matt Riedemann wrote:
>>
>> Given this, what else do you need? Please be clear about what your
>> use case is and how it is not solved using the 2.53 microversion.
>> There may need to be changes to the CLI but let's separate that
>> concern from the REST API changes.
>
> I think your issue might be with these commands which use the
> hypervisors.search python API binding in novaclient:
>
> 1. nova host-meta # Set or Delete metadata on all instances of a host.
> 2. nova host-evacuate # Evacuate all instances from failed host 3.
> nova host-evacuate-live # Live migrate all instances of the specified
> host (we should really rename this command since it doesn't 'evacuate'
> it live migrates)
> 4. nova host-servers-migrate # Cold migrate all instances off the
> specified host
>
> The risk with any of these is on the hostname match hitting more
> hypervisors than you wanted or expected. So if I have 10 computes in a
> London region in data center 1 named something like
> london.dc1.compute1.foo.bar, london.dc1.compute2.foo.bar, etc, and I do:
>
> nova host-evacuate london.dc1
>
> It's going to match all of those and evacuate instances from all of
> those dc1 computes in my london region at once, obviously probably not
> something you want, unless dc1 is being attacked by Harry Potter fans
> and you need to get those instances to another data center.
>
> The solution here is you specify the fully qualified domain name for
> the host you want to evacuate:
>
> nova host-evacuate london.dc1.compute1.foo.bar
>
> Right? What am I missing here?
>
> If you wanted to change the CLI to be more strict, we could do that by
> just adding a --strict_hostname option or something and fail if we get
> back more than one host, as a way to guard the operator from making a
> mistake.
>
> But none of this sounds like changes that need to be done in the REST
> API, and arguably isn't a bug in the CLI either.
>

Also, FYI in case you haven't read this:

https://clicktime.symantec.com/a/1/WpT1yeVBi7ncF0Ca_OTDe44XocFyzb3l8mmGaRh90eA=?d=15Eqjgzs0zz_nCSfkIZ03H85QhaaZ8qorwC1B6sNqR2qaif0YzQu9aDyucao9W0xq9TmblqjEa8vB_Uh6I73ZbcJ_aBt5DG4hUd_exR4jRYcFWvfIJ_1sJw7muMlygwsZvrfBDP-hVB_uXIw68-6qIXjtKoNEPSrkV-9tVoi_no3lioykWQyfYuIaypPH_lo9jcJ_725u3cfMocfzAqis4UJvyHrrMoOgOK2PklJIvKHbALogoTLSYmTFrN6xq8nf8PiICHVw-syDE_acSqDUCVN9XffaeX3bkJ_TyqUNTLd04O3ghc_JNsdgMV1bJLEoU802f-tZAa8ExalsfHb-X5N6KC9rAi-StOuSXqpZkLoPDifDeQoLG8KO46UxM7GC_SA_o-pD36JVzP2iPmxnbz1_pk1fg5pKYtsoxcsAHgdWlgYN-mKok_UuJXNYZci0i7D7_p-0RsbyTqrZNjuUU-O4a8j-fk0amKyj6FTVaJI-v-0kQ%3D%3D=http%3A%2F%2Fwww.danplanet.com%2Fblog%2F2016%2F03%2F03%2Fevacuate-in-nova-one-command-to-confuse-us-all%2F

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://clicktime.symantec.com/a/1/30lNRL8YgGNm4hBzvUlj4IRURgEORzz8xa3pXFvMfQk=?d=15Eqjgzs0zz_nCSfkIZ03H85QhaaZ8qorwC1B6sNqR2qaif0YzQu9aDyucao9W0xq9TmblqjEa8vB_Uh6I73ZbcJ_aBt5DG4hUd_exR4jRYcFWvfIJ_1sJw7muMlygwsZvrfBDP-hVB_uXIw68-6qIXjtKoNEPSrkV-9tVoi_no3lioykWQyfYuIaypPH_lo9jcJ_725u3cfMocfzAqis4UJvyHrrMoOgOK2PklJIvKHbALogoTLSYmTFrN6xq8nf8PiICHVw-syDE_acSqDUCVN9XffaeX3bkJ_TyqUNTLd04O3ghc_JNsdgMV1bJLEoU802f-tZAa8ExalsfHb-X5N6KC9rAi-StOuSXqpZkLoPDifDeQoLG8KO46UxM7GC_SA_o-pD36JVzP2iPmxnbz1_pk1fg5pKYtsoxcsAHgdWlgYN-mKok_UuJXNYZci0i7D7_p-0RsbyTqrZNjuUU-O4a8j-fk0amKyj6FTVaJI-v-0kQ%3D%3D=http%3A%2F%2Flists.openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-dev

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com 
__
The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The

Re: [openstack-dev] [OpenStack-Dev][Nova] - https://launchpad.net/bugs/1667794 Changing hostname not to be treated as a pattern instead exact match will be done.

2017-07-25 Thread nidhi.h...@wipro.com 
t;>>>>>>>>>>>>>>>>>>>>>>>.
return self._list(url, 'hypervisors')

we are passing servers as true in these cli commands.

Servers = True
==
1.
do_host_meta(cs, args):
"""Set or Delete metadata on all instances of a host."""
hypervisors = cs.hypervisors.search(args.host, servers=True)

2.
@utils.arg(
'hostname',
metavar='',
help=_('The hypervisor hostname (or pattern) to search for.')) def 
do_hypervisor_servers(cs, args):
"""List servers belonging to specific hypervisors."""
hypers = cs.hypervisors.search(args.hostname, servers=True)

3.
def do_host_evacuate(cs, args):
"""Evacuate all instances from failed host."""

hypervisors = cs.hypervisors.search(args.host, servers=True)

4.
def do_host_evacuate_live(cs, args):
"""Live migrate all instances of the specified host
to other available hosts.
"""
hypervisors = cs.hypervisors.search(args.host, servers=True)
response = []

5.
def do_host_servers_migrate(cs, args):
"""Cold migrate all instances off the specified host to other available
hosts.
"""

hypervisors = cs.hypervisors.search(args.host, servers=True)
response = []
for hyper in hypervisors:


Servers = false
===
1.
def _do_hypervisor_list(cs, matching=None, limit=None, marker=None):
columns = ['ID', 'Hypervisor hostname', 'State', 'Status']
if matching:
utils.print_list(cs.hypervisors.search(matching), columns)



Please suggest what is better solution?

1)Modifying http://10.141.67.190:8774/v2.1/os-hypervisors/wipro/servers api 
code in nova server side code - to match hostname as exact not as a pattern
We can code so that http://10.141.67.190:8774/v2.1/os-hypervisors/wipro/search 
remains unaffected.

2)We should introduce a new parameter in servers api which from cli which 
directs that exact match is to be
done in url.
http://10.141.67.190:8774/v2.1/os-hypervisors/wipro/servers?exact_match=true
and query parameter then interpreted in server side code and behave as desired.
In this case we will have choice to not affect at undesired commands.

Thanks
Nidhi
































-Original Message-
From: Matt Riedemann [mailto:mriede...@gmail.com]
Sent: Friday, July 14, 2017 7:22 PM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [OpenStack-Dev][Nova] - 
https://launchpad.net/bugs/1667794 Changing hostname not to be treated as a 
pattern instead exact match will be done.

** This mail has been sent from an external source. Treat hyperlinks and 
attachments in this email with caution**

On 7/14/2017 6:49 AM, nidhi.h...@wipro.com<mailto:nidhi.h...@wipro.com> wrote:
> Hello all,
>
> This is regarding bug 1667794 as mentioned in subject.
>
> Its review is going on here.
>
> https://clicktime.symantec.com/a/1/49nJvSe1Be7H66fNyloEH0VFJQ88tUzr9ao
> 8kyFM3jc=?d=huhMONMwyIvPyR_TNVFVFEoKBc2izoSPlzhtdZ1egR7bwY3hW0n6gBw5Pf
> _aKziBo_pOhFqtNZ7hwc696PKDDY0ern8LIG6XT0Pa5GnYDhIM8xtNkatqd6_xu-fn6091
> KREiE5rxafexQfe-rJ7RZKU7RWnI0BMsnrkU7NWqJOLUlJi9hKN2qxzIp-n8ZnSkjcNzp9
> 81ZLIMs7MJ--gOKTl4pZEsfb_MBwDbeOUcZA5mm8WANpU0XMEUHdqhphAf2QXPUL8oHD6l
> RCzrptg5Fi9_L4e2YX6ZA28AUqup5WAH1B4OT_E4mbfcaZxfm9sIXtUyWvbaKBRG-syj4W
> eDNjzAvxku3u9xfD1HWy1MUp36GMU4z7N3BJGZuiIu4YmCjmsKdXb_m0i5CkmgPB0jOfuP
> 6fjyr9PfbBEtvQYMIQLTIoOCFWag30Q5VqPVnfh-Nzv_T1kbO3TCFZqoZktPT8Vo6wAk45
> hsiX0HknkBnNqR21E7Fb5t2hG0HjqNSxgld9NIXGZng7JR=https%3A%2F%2Freview.
> openstack.org%2F%23%2Fc%2F474949%2F
>
> *_Bug is - _**_Nova treats hostname as pattern_*
>
> *_Description_*
>
> Nova commands such as "hypervisor-list --matching ",
>
> host-evacuate-live and host-evacuate and few more, treat the
>
> user-specified "host-name" as the input to the HTTP
>
> /os-hypervisors/{hypervisor_hostname_pattern}/search API.
>
> *Nova checks "host-name" as a pattern instead of exact match,*
>
> *which causes problem with some commands such as*
>
> *nova host-evacuate-live compute-1 where in host-evacuate*
>
> *action will apply to all "compute-1", "compute-10".*
>
> *That is not right.*
>
> Correcting it by using exact match.
>
> We have fixed it and put it for review. We need your opinion on this.
>
> *_Kindly share your opinion in case this does not seem to be an
> acceptable fix to anyone._*
>
> Thanks
>
> Nidhi
>
> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> addressee(s) and may contain proprietary, confidential or p

Re: [openstack-dev] [OpenStack-Dev][Nova] - https://launchpad.net/bugs/1667794 Changing hostname not to be treated as a pattern instead exact match will be done.

2017-07-25 Thread nidhi.h...@wipro.com 

























-Original Message-
From: Matt Riedemann [mailto:mriede...@gmail.com]
Sent: Friday, July 14, 2017 7:22 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [OpenStack-Dev][Nova] - 
https://launchpad.net/bugs/1667794 Changing hostname not to be treated as a 
pattern instead exact match will be done.

** This mail has been sent from an external source. Treat hyperlinks and 
attachments in this email with caution**

On 7/14/2017 6:49 AM, nidhi.h...@wipro.com wrote:
> Hello all,
>
> This is regarding bug 1667794 as mentioned in subject.
>
> Its review is going on here.
>
> https://clicktime.symantec.com/a/1/49nJvSe1Be7H66fNyloEH0VFJQ88tUzr9ao
> 8kyFM3jc=?d=huhMONMwyIvPyR_TNVFVFEoKBc2izoSPlzhtdZ1egR7bwY3hW0n6gBw5Pf
> _aKziBo_pOhFqtNZ7hwc696PKDDY0ern8LIG6XT0Pa5GnYDhIM8xtNkatqd6_xu-fn6091
> KREiE5rxafexQfe-rJ7RZKU7RWnI0BMsnrkU7NWqJOLUlJi9hKN2qxzIp-n8ZnSkjcNzp9
> 81ZLIMs7MJ--gOKTl4pZEsfb_MBwDbeOUcZA5mm8WANpU0XMEUHdqhphAf2QXPUL8oHD6l
> RCzrptg5Fi9_L4e2YX6ZA28AUqup5WAH1B4OT_E4mbfcaZxfm9sIXtUyWvbaKBRG-syj4W
> eDNjzAvxku3u9xfD1HWy1MUp36GMU4z7N3BJGZuiIu4YmCjmsKdXb_m0i5CkmgPB0jOfuP
> 6fjyr9PfbBEtvQYMIQLTIoOCFWag30Q5VqPVnfh-Nzv_T1kbO3TCFZqoZktPT8Vo6wAk45
> hsiX0HknkBnNqR21E7Fb5t2hG0HjqNSxgld9NIXGZng7JR=https%3A%2F%2Freview.
> openstack.org%2F%23%2Fc%2F474949%2F
>
> *_Bug is - _**_Nova treats hostname as pattern_*
>
> *_Description_*
>
> Nova commands such as "hypervisor-list --matching ",
>
> host-evacuate-live and host-evacuate and few more, treat the
>
> user-specified "host-name" as the input to the HTTP
>
> /os-hypervisors/{hypervisor_hostname_pattern}/search API.
>
> *Nova checks "host-name" as a pattern instead of exact match,*
>
> *which causes problem with some commands such as*
>
> *nova host-evacuate-live compute-1 where in host-evacuate*
>
> *action will apply to all "compute-1", "compute-10".*
>
> *That is not right.*
>
> Correcting it by using exact match.
>
> We have fixed it and put it for review. We need your opinion on this.
>
> *_Kindly share your opinion in case this does not seem to be an
> acceptable fix to anyone._*
>
> Thanks
>
> Nidhi
>
> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> addressee(s) and may contain proprietary, confidential or privileged
> information. If you are not the intended recipient, you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately and destroy all copies of this message and any attachments. 
> WARNING:
> Computer viruses can be transmitted via email. The recipient should
> check this email and any attachments for the presence of viruses. The
> company accepts no liability for any damage caused by any virus
> transmitted by this email. www.wipro.com
>
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> https://clicktime.symantec.com/a/1/9RX_Q306kvu_hhDcIzBL0WNsDUY3rwoCi9T
> 8g25S6fc=?d=huhMONMwyIvPyR_TNVFVFEoKBc2izoSPlzhtdZ1egR7bwY3hW0n6gBw5Pf
> _aKziBo_pOhFqtNZ7hwc696PKDDY0ern8LIG6XT0Pa5GnYDhIM8xtNkatqd6_xu-fn6091
> KREiE5rxafexQfe-rJ7RZKU7RWnI0BMsnrkU7NWqJOLUlJi9hKN2qxzIp-n8ZnSkjcNzp9
> 81ZLIMs7MJ--gOKTl4pZEsfb_MBwDbeOUcZA5mm8WANpU0XMEUHdqhphAf2QXPUL8oHD6l
> RCzrptg5Fi9_L4e2YX6ZA28AUqup5WAH1B4OT_E4mbfcaZxfm9sIXtUyWvbaKBRG-syj4W
> eDNjzAvxku3u9xfD1HWy1MUp36GMU4z7N3BJGZuiIu4YmCjmsKdXb_m0i5CkmgPB0jOfuP
> 6fjyr9PfbBEtvQYMIQLTIoOCFWag30Q5VqPVnfh-Nzv_T1kbO3TCFZqoZktPT8Vo6wAk45
> hsiX0HknkBnNqR21E7Fb5t2hG0HjqNSxgld9NIXGZng7JR=http%3A%2F%2Flists.op
> enstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-dev
>

Thanks for bringing this up. Your fix is in the wrong place, see the comments 
in the patch.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://clicktime.symantec.com/a/1/9RX_Q306kvu_hhDcIzBL0WNsDUY3rwoCi9T8g25S6fc=?d=huhMONMwyIvPyR_TNVFVFEoKBc2izoSPlzhtdZ1egR7bwY3hW0n6gBw5Pf_aKziBo_pOhFqtNZ7hwc696PKDDY0ern8LIG6XT0Pa5GnYDhIM8xtNkatqd6_xu-fn6091KREiE5rxafexQfe-rJ7RZKU7RWnI0BMsnrkU7NWqJOLUlJi9hKN2qxzIp-n8ZnSkjcNzp981ZLIMs7MJ--gOKTl4pZEsfb_MBwDbeOUcZA5mm8WANpU0XMEUHdqhphAf2QXPUL8oHD6lRCzrptg5Fi9_L4e2YX6ZA28AUqup5WAH1B4OT_E4mbfcaZxfm9sIXtUyWvbaKBRG-syj4WeDNjzAvxku3u9xfD1HWy1MUp36GMU4z7N3BJGZuiIu4YmCjmsKdXb_m0i5CkmgPB0jOfuP6fjyr9PfbBEtvQYMIQLTIoOCFWag30Q5VqPVnfh-Nzv_T1kbO3TCFZqoZktPT8Vo6wAk45hsiX0HknkBnNqR21E7Fb5t2hG0HjqNSxgld9NIXGZng7JR=http%3A%2F%2Flists.opensta

[openstack-dev] [OpenStack-Dev][Nova] - https://launchpad.net/bugs/1667794 Changing hostname not to be treated as a pattern instead exact match will be done.

2017-07-14 Thread nidhi.h...@wipro.com 
Hello all,

This is regarding bug 1667794 as mentioned in subject.
Its review is going on here.
https://review.openstack.org/#/c/474949/

Bug is - Nova treats hostname as pattern

Description
Nova commands such as "hypervisor-list --matching ",
host-evacuate-live and host-evacuate and few more, treat the
user-specified "host-name" as the input to the HTTP
/os-hypervisors/{hypervisor_hostname_pattern}/search API.


Nova checks "host-name" as a pattern instead of exact match,
which causes problem with some commands such as
nova host-evacuate-live compute-1 where in host-evacuate
action will apply to all "compute-1", "compute-10".
That is not right.
Correcting it by using exact match.
We have fixed it and put it for review. We need your opinion on this.

Kindly share your opinion in case this does not seem to be an acceptable fix to 
anyone.

Thanks
Nidhi


The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OpenStack-Dev][OpenStackClient] - Running functional tests

2017-07-04 Thread nidhi.h...@wipro.com 
Hello all,

I am running functional tests for openstackclient.
By using this command sudo tox -efunctional

It gives me this error

setUpClass 
(openstackclient.tests.functional.volume.v3.test_snapshot.VolumeSnapshotTests)
-

Captured traceback:
~~~
Traceback (most recent call last):
  File "openstackclient/tests/functional/volume/v3/test_snapshot.py", line 
22, in setUpClass
super(VolumeSnapshotTests, cls).setUpClass()
  File "openstackclient/tests/functional/volume/v2/test_snapshot.py", line 
31, in setUpClass
cls.VOLLY
  File "openstackclient/tests/functional/base.py", line 64, in openstack
return execute('openstack ' + cmd, fail_ok=fail_ok)
  File "openstackclient/tests/functional/base.py", line 41, in execute
result_err)
tempest.lib.exceptions.CommandFailed: Command 'openstack volume create -f 
json --size 1 ee1a858057464f15b6488ec4f3c1da5d' returned non-zero exit status 1.
stdout:

stderr:
Missing value auth-url required for auth plugin password


Can someone tell me where do I need to configure environment variables
So that functional tests run well?

Any doc /url also will be helpful.

Thanks
Nidhi

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OpenStack-Dev][Python-NovaClient]- Removing option of specifying device name from nova volume attach command.

2017-06-08 Thread nidhi.h...@wipro.com 
Hello All,

This is regarding bug https://launchpad.net/bugs/1667269 titled as Nova 
volume-attach doesn't care for device name
Review is going on at https://review.openstack.org/#/c/454048/

Description:
[root@greglinux2 ~(keystone_admin)]# nova volume-attach 
e9c63adc-e837-4108-b5cf-10a8f147a5ab f0990f38-8fc5-4710-b9ac-e846b6c634cb 
/dev/vdc >>>
+--+--+
| Property | Value |
+--+--+
| device | /dev/vdb | > Still attached as /dev/vdb  >>.
| id | f0990f38-8fc5-4710-b9ac-e846b6c634cb |
| serverId | e9c63adc-e837-4108-b5cf-10a8f147a5ab |
| volumeId | f0990f38-8fc5-4710-b9ac-e846b6c634cb |
+--+--+

It looks like nova is not considering  parameter at all. Is it expected?
It shows that "/dev/vdc" was requested by client as device name but server 
prefers to ignore it.

As seen in nova server side logs :


2017-04-05 03:35:58.902 3199 WARNING nova.virt.libvirt.driver 
[req-90bfc957-2cb2-47e4-9018-fb0e24404f7b c2a01ca6f6f84d388dbd12c68eaa1d13 
f29439bb99d54dba980631b1ef7bd8cd - - -] [instance: 
31aaa8e3-3163-4f17-8ccd-f22c3c35ce95] Ignoring supplied device name: /dev/vdr 
>>

2017-04-05 03:35:58.903 3199 WARNING nova.virt.osinfo 
[req-90bfc957-2cb2-47e4-9018-fb0e24404f7b c2a01ca6f6f84d388dbd12c68eaa1d13 
f29439bb99d54dba980631b1ef7bd8cd - - -] Cannot find OS information - Reason: 
(No configuration information found for operating system Empty)

2017-04-05 03:35:59.312 3199 INFO nova.compute.manager 
[req-90bfc957-2cb2-47e4-9018-fb0e24404f7b c2a01ca6f6f84d388dbd12c68eaa1d13 
f29439bb99d54dba980631b1ef7bd8cd - - -] [instance: 
31aaa8e3-3163-4f17-8ccd-f22c3c35ce95] Attaching volume 
657ed918-36ae-4ffc-a08b-275eefd0c152 to /dev/vde >>.

Where in code file
nova/virt/libvirt/drivers.py

we see that if a device name is not none intentionally we ignore the device 
name coming from cli.

Hence i think in that case there is no use of sending device name from 
novaclient.

As we are just confusing user by asking him device name and later ignoring it 
intentionally.

Hence we fixed it by removing device name option from shell.py in novaclient.



But there are opinion which differ like

Matt Riedemann says



"I think I'd like to see this brought up in the openstack-dev mailing list 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev or at least 
the weekly nova team meeting [1] to make sure everyone is on the same page 
before doing this, because the libvirt driver is technically the only one that 
ignores the requested device, not all drivers do that.

And I tried deprecated block device name from the API but that ran into 
complications:

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

[1] https://wiki.openstack.org/wiki/Meetings/Nova "



Can wider audience with your experience please share your thoughts on this?



Thanks

Nidhi







The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OpenStack-Dev][Python-NovaClient] Nova reset state - default state change.

2017-06-08 Thread nidhi.h...@wipro.com 
Hello All,

This is regarding bug https://launchpad.net/bugs/1674247 -- titled as   
Reset-state's default parameter needs correction
review is going on at https://review.openstack.org/#/c/463477/2

===
Description
The Bug proposes to change reset-state default state to be “active”.

Reason for setting up default state as “active”
Reset-state is an admin exposed command and once admin has sorted internal 
error occurred
in nova instance, this command will help to set the instance back to “active” 
state.

Reason for keeping default state as “error”
If I recall correctly, "reset-state" was introduced solely to handle the case 
of recovery from
Nova internal errors, and the default of 'error' was deliberately chosen to 
encourage developers
to spend their time correcting the problem in Nova rather than leveraging the 
work-around.

Other propositions are

  *   Whether we should change the default of reset-state to "active".
  *   It would also be good to discuss whether we should provide the ability to 
set other states, as this change eliminates the possibility to do so from the 
command line.
  *   So, this means that --active no longer does anything. That means we 
should deprecate the option, so we can remove it in a future release.

Kindly state your opinion what would be best suitable for admin users for this 
command?

Questions

1) Should we change reset state to “active” by default or “error” is good

2) In that case should i deprecate --active?

3)Should we consider giving user a facility of changing to any other state by 
giving --state as an optional arg?

4)But if we see difference from cinder command Cinder states "its a database 
only change"

stack@ubuntu14-OptiPlex-3020:~/openstack_install/devstack$ cinder help 
reset-state
usage: cinder reset-state [--type ] [--state ]
  [--attach-status ]
  [--reset-migration-status]
   [ ...]

Explicitly updates the entity state in the Cinder database. Being a database 
change only, this has no impact on the true state of the entity and may not 
match the actual state. This can render a entity unusable in the case of 
changing to the 'available' state.

but in case of nova Its not stated so

stack@ubuntu14-OptiPlex-3020:~/openstack_install/devstack$ nova help 
reset-state usage: nova reset-state [--all-tenants] [--active]  
[ ...]

Reset the state of a server.

So will it be possible to change state of server to any state ?

Thanks

Nidhi



The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Dev][DevStack][Neutron] devstack install - need help on local.conf settings

2017-06-02 Thread nidhi.h...@wipro.com 
Hello all,

I am using http://paste.openstack.org/show/595339/ as my local.conf.

I wanted to understand :- Which interface should we put as value in
PUBLIC_INTERFACE in local.conf.


Reason why I am asking this is,

Once, I installed OpenStack using DevStack, on my linux VM on
VirtualBox - I used PUBLIC_INTERFACE value as eth0
and
I configured only one network adapter on VM in NAT mode.

Later on I faced lot of networking problems in that OpenStack VM.
Internet wasn't accessible suddenly and many other probs.

I debugged and somehow found eth0 was added in
One ovs-bridge and if I remove eth0 from that bridge -
only then internet in my VM used to work well.

Then I doubted PUBLIC_INTERFACE value in local.conf
is something I should setup correctly..

Could not find much help on this from google.

Can someone please enlighten?

Thanks
Nidhi









From: Nidhi Mittal Hada (Product Engineering Service)
Sent: Wednesday, January 18, 2017 3:49 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [OpenStack-Dev][DevStack][Neutron] facing problem 
in devstack install - No Network found for private


Hi Andreas,



As in between you suggested to try with default devstack

neutron config params. I tried that i set no config option

for neutron part all default.



This local.conf is working well..



for others who are facing problem pasting working local.conf here

http://paste.openstack.org/show/595339/



Attaching too.



Thanks

Nidhi








From: Nidhi Mittal Hada (Product Engineering Service)
Sent: Wednesday, January 18, 2017 2:44 PM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [OpenStack-Dev][DevStack][Neutron] facing problem 
in devstack install - No Network found for private


Andreas,



I require nothing specific from neutron side.

Just a basic working setup from neutron side

because my work is mostly on storage side of

OpenStack.



Can you please suggest a working configuration

if  tried recently.



Thanks

nidhi




From: Nidhi Mittal Hada (Product Engineering Service)
Sent: Wednesday, January 18, 2017 2:35:13 PM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [OpenStack-Dev][DevStack][Neutron] facing problem 
in devstack install - No Network found for private


HI Andreas,



Thanks for your reply.



I have no specific reason for using this network configuration in local.conf.

I have only basic knowledge of these config options even.

This local.conf network configurations used to work well with earlier

devstack openstack versions. So i did not change it..

Just this time its creating trouble.



I have not created any ovs bridge manually  before running devstack.

just created this local.conf and ran ./stack.sh in devstack folder.



Can you please suggest changes if i have not created ovs-bridge manually.



At present my settings are - from local.conf - for reference -
FIXED_RANGE=10.11.12.0/24
NETWORK_GATEWAY=10.11.12.1
FIXED_NETWORK_SIZE=256

FLOATING_RANGE=10.0.2.0/24
Q_FLOATING_ALLOCATION_POOL=start=10.0.2.104,end=10.0.2.111
PUBLIC_NETWORK_GATEWAY=10.0.2.1
HOST_IP=10.0.2.15

PUBLIC_INTERFACE=eth0

Q_USE_SECGROUP=True
ENABLE_TENANT_VLANS=True
TENANT_VLAN_RANGE=1000:1999
PHYSICAL_NETWORK=default
OVS_PHYSICAL_BRIDGE=br-ex


Q_USE_PROVIDER_NETWORKING=True
Q_L3_ENABLED=False

PROVIDER_SUBNET_NAME="provider_net"
PROVIDER_NETWORK_TYPE="vlan"
SEGMENTATION_ID=2010









Thanks

Nidhi






From: Andreas Scheuring 
<scheu...@linux.vnet.ibm.com<mailto:scheu...@linux.vnet.ibm.com>>
Sent: Wednesday, January 18, 2017 1:09:17 PM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [OpenStack-Dev][DevStack][Neutron] facing problem 
in devstack install - No Network found for private

** This mail has been sent from an external source **

Without looking into the details

you're specifying
Q_USE_PROVIDER_NETWORKING=True
in your local.conf - usually this results in the creation of a single
provider network called "public". But the manila devstack plugin seems
not to be able to deal with provider networks as it's expecting a
network named "private" to be present.


Why are you using provider networks? Just for sake of VLANs? You can
also configure devstack to use vlans with the default setup. This has
worked for me in the past - results in a private network using vlans
(assuming you have created ovs b bridge br-data manually):


OVS_PHYSICAL_BRIDGE=br-data
PHYSICAL_NETWORK=phys-data

ENABLE_TENANT_TUNNELS=False
Q_ML2_TENANT_NETWORK_TYPE=vlan
ENABLE_TENANT_VLANS=True
TENANT_VLAN_RANGE=1000:1000




--
-
Andreas
IRC: andreas_s



On Mi, 2017-01-18 at 06:59 +, 
nidhi.h...@wipro.com<mailto:nidhi.h...@wipro.com> wrote:
>

[openstack-dev] [OpenStack-Dev][Cinder][Driver][Nimble] - Need Point of contact

2017-04-04 Thread nidhi.h...@wipro.com 
Hi all,


I was working on few bugs related to Nimble cinder driver.

I needed some clarification.


May i know right point of contact for this?


Who from nimble should be contacted for their cinder

driver bugs?


Thanks

Nidhi



The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev