from:"Bhor, Dinesh"

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

2018-10-24 Thread ボーアディネシュ [Bhor Dinesh]

Hi All,

We were having a similar use case like *Preemptible Instances* called as 
*Rich-VM’s* which
are high in resources and are deployed each per hypervisor. We have a custom 
code in
production which tracks the quota for such instances separately and for the 
same reason
we have *rich_instances* custom quota class same as *instances* quota class. 

I discussed this thing pretty recently with sean-k-mooney I hope he remembers 
it.

ボーアディネシュ Bhor Dinesh
Verda2チーム

〒160-0022　東京都新宿区新宿4-1-6 JR新宿ミライナタワー 23階
Mobile 08041289520 Fax 03-4316-2116
Email dinesh.b...@linecorp.com

-Original Message-
From: "Kevin L. Mitchell"
To: "OpenStack Development Mailing List (not for usage 
questions)"; 
"openstack-operat...@lists.openstack.org";
Cc:
Sent: Oct 25, 2018 (Thu) 11:35:08
Subject: Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota 
class functionality in Nova?

> On 10/24/18 10:10, Jay Pipes wrote:
> > Nova's API has the ability to create "quota classes", which are
> > basically limits for a set of resource types. There is something called
> > the "default quota class" which corresponds to the limits in the
> > CONF.quota section. Quota classes are basically templates of limits to
> > be applied if the calling project doesn't have any stored
> > project-specific limits.

For the record, my original concept in creating quota classes is that
you'd be able to set quotas per tier of user and easily be able to move
users from one tier to another.  This was just a neat idea I had, and
AFAIK, Rackspace never used it, so you can call it YAGNI as far as I'm
concerned :)

> > Has anyone ever created a quota class that is different from "default"?
> >
> > I'd like to propose deprecating this API and getting rid of this
> > functionality since it conflicts with the new Keystone /limits endpoint,
> > is highly coupled with RAX's turnstile middleware

I didn't intend it to be highly coupled, but it's been a while since I
wrote it, and of course I've matured as a developer since then, so
*shrug*.  I also don't think Rackspace has ever used turnstile.

> > and I can't seem to
> > find anyone who has ever used it. Deprecating this API and functionality
> > would make the transition to a saner quota management system much easier
> > and straightforward.

I'm fine with that plan, speaking as the original developer; as I say,
I don't think Rackspace ever utilized the functionality anyway, and if
no one else pipes up saying that they're using it, I'd be all over
deprecating the quota classes in favor of the new hotness.
--
Kevin L. Mitchell 

__
OpenStack Development Mailing 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] [masakari] Masakari Project Meeting time

2018-04-25 Thread Bhor, Dinesh

+1
This time may not fit for attendees who work in IST time zone as it will 07.30 
AM in the morning.

Thanks,
Dinesh

> On Apr 26, 2018, at 12:06 AM, Kwan, Louie  wrote:
>
> Sampath, Dinesh and others,
>
> It was a good meeting last week.
>
> As briefly discussed with Sampath, I would like to check whether we can 
> adjust the meeting time.
>
> We are at EST time zone, the meeting is right on our midnight time, 12:00 am.
>
> It will be nice if the meeting can be started ~2 hours earlier e.g. Could it 
> be  started at 02:00: UTC instead?
>
> Thanks.
> Louie
>
>

Disclaimer: This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged,confidential, 
and proprietary data. If you are not the intended recipient,please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding.

__
OpenStack Development Mailing 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] [masakari] Masakari Project mascot ideas

2018-03-13 Thread Bhor, Dinesh

Hi Sampath San,


There is one more option which we discussed in yesterdays masakari meeting [1]:

St. Bernard(Dog) [2].


[1] 
http://eavesdrop.openstack.org/meetings/masakari/2018/masakari.2018-03-13-04.01.log.html#l-38


[2] https://en.wikipedia.org/wiki/St._Bernard_(dog)


Thank you,

Dinesh Bhor



From: Sam P 
Sent: 13 March 2018 22:19:00
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [masakari] Masakari Project mascot ideas

Hi All,

We started this discussion on IRC meeting few weeks ago and still no 
progress..;)
(aspiers: thanks for the reminder!)

Need mascot proposals for Masakari, see FAQ [1] for more info
Current ideas: Origin of "Masakari" is related to hero from Japanese folklore 
[2].
Considering that relationship and to start the process, here are few ideas,
(1) Asiatic black bear
(2) Gekko : Geckos is able to regrow it's tail when the tail is lost.

[1] https://www.openstack.org/project-mascots/
[2] https://en.wikipedia.org/wiki/Kintar%C5%8D

--- Regards,
Sampath


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
OpenStack Development Mailing 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] [masakari] Any masakari folks at the PTG this week ?

2018-02-28 Thread Bhor, Dinesh

Hi Greg,


We below are present:


Tushar Patil(tpatil)

Yukinori Sagara(sagara)

Abhishek Kekane(abhishekk)

Dinesh Bhor(Dinesh_Bhor)


Thank you,

Dinesh Bhor



From: Waines, Greg 
Sent: 28 February 2018 19:22:26
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [masakari] Any masakari folks at the PTG this week ?


Any masakari folks at the PTG this week ?



Would be interested in meeting up and chatting,

let me know,

Greg.

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing 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] [masakari] [notification api] How to clean up or purging of records

2018-02-15 Thread Bhor, Dinesh

Hi Kwan Louie,

I think you are looking for this:
https://review.openstack.org/#/c/487430/

Thank you,
Dinesh Bhor


From: Kwan, Louie 
Sent: 16 February 2018 02:46:14
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [masakari] [notification api] How to clean up or 
purging of records

Hi All,

Just wondering, how can we clean up the masakari notification list or purging 
all old records in the DB?

openstack notification list
  returns too many old records

During semi-auto testing, I created a long list of history of records and would 
like to clean it up and avoid unnecessary actions.

Any short term solution is what I am looking for and/or ideas how to extend the 
CLI is also welcomed so that some of us can extend it later.

Thanks,
Louie


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
OpenStack Development Mailing 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] [masakari] Change service-type from "ha" to "instance-ha"

2018-01-22 Thread Bhor, Dinesh

Hi Masakari team,


Below are the patches up for review to change the masakari service-type from 
“ha” to “instance-ha”:


openstack/python-masakariclient :

https://review.openstack.org/#/c/53/1


openstack/masakari-monitors :

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


openstack/masakari :

https://review.openstack.org/#/c/536653/1


openstack/service-types-authority :

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



We should go with below order to fix this issue:


  1.  Merge the python-masakariclient patch.
  2.  Release newer version of python-masakariclient library.
  3.  Bump the newer version of python-masakariclient to global-requirements.
 *   The requirements freeze is near (coming Friday at 23:59:59 UTC)
*   
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126475.html
  4.  Bot job will propose a patch in masakari-monitors to update the 
python-masakariclient version.
  5.  Merge the bot job proposed patch.
  6.  Merge the masakari-monitors service-type patch.
  7.  Merge the masakari service-type patch.
  8.  Merge openstack/service-types-authority patch with updated service-type 
“instance-ha”.


Please help to merge these patches asap.


Thank you,

Dinesh Bhor

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing 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] [masakari] problems starting up masakari instance monitoring in devstack @ master

2017-12-13 Thread Bhor, Dinesh

Hi Greg,


Looks like you don’t have “devstack-masakari” host registered in Masakari 
database.


Currently operator have to add all the hosts from failover-segment manually to 
Masakari database.


You can use below command:


Register failover-segment to Masakari database:

openstack segment create   


Register hosts under the created segment to Masakari database:

openstack segment host create



There is a work in progress on auto compute node registration.

Please refer: 
https://blueprints.launchpad.net/masakari-monitors/+spec/auto-compute-node-registration



Thank you,

Dinesh Bhor


From: Waines, Greg 
Sent: 13 December 2017 19:26:32
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [masakari] problems starting up masakari instance 
monitoring in devstack @ master


ok ... i changed all the domain related attributes in 
/etc/masakarimonitors/masakarimonitors.conf to be set to ‘default’ .

I seemed to get further,

but now get the following error when instancemonitor tries to send a 
notification:

  Bad Request (HTTP 400) (Request-ID: 
req-556c6c4d-0e12-414e-ac8c-8ef3a61d4864), Host with name devstack-masakari 
could not be found.

however:

- devstack-masakari is in the /etc/hosts

- nova hypervisor-list shows devstack-masakari as a hypervisor hostname

- i am running both hostmonitor, processmonitor and instancemonitor



any ideas ?

see details below,

Greg.



2017-12-13 13:50:34.353 7637 INFO 
masakarimonitors.instancemonitor.libvirt_handler.callback [-] Libvirt Event: 
type=VM, hostname=devstack-masakari, uuid=6ae0b09b-3e93-4f0c-b81b-fa140636f267, 
time=2017-12-13 13:50:34.353037, event_id=LIFECYCLE, detail=STOPPED_DESTROYED)

2017-12-13 13:50:34.353 7637 INFO masakarimonitors.ha.masakari [-] Send a 
notification. {'notification': {'hostname': 'devstack-masakari', 'type': 'VM', 
'payload': {'instance_uuid': '6ae0b09b-3e93-4f0c-b81b-fa140636f267', 
'vir_domain_event': 'STOPPED_DESTROYED', 'event': 'LIFECYCLE'}, 
'generated_time': datetime.datetime(2017, 12, 13, 13, 50, 34, 353037)}}

2017-12-13 13:50:34.461 7637 WARNING masakarimonitors.ha.masakari [-] Retry 
sending a notification. (HttpException: Bad Request (HTTP 400) (Request-ID: 
req-556c6c4d-0e12-414e-ac8c-8ef3a61d4864), Host with name devstack-masakari 
could not be found.): HttpException: HttpException: Bad Request (HTTP 400) 
(Request-ID: req-556c6c4d-0e12-414e-ac8c-8ef3a61d4864), Host with name 
devstack-masakari could not be found.

^C2017-12-13 13:50:42.462 7637 INFO oslo_service.service [-] Caught SIGINT 
signal, instantaneous exiting

root@devstack-masakari:~#

root@devstack-masakari:~# ping devstack-masakari

PING localhost (127.0.0.1) 56(84) bytes of data.

64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.049 ms

64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.022 ms

^C

--- localhost ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 999ms

rtt min/avg/max/mdev = 0.022/0.035/0.049/0.014 ms

root@devstack-masakari:~#



stack@devstack-masakari:~$ nova hypervisor-list

+--+-+---+-+

| ID   | Hypervisor hostname | State | Status  |

+--+-+---+-+

| 5fb1b09b-e5f5-465a-828a-2101135ff700 | devstack-masakari   | up| enabled |

+--+-+---+-+

stack@devstack-masakari:~$













From: Greg Waines 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Wednesday, December 13, 2017 at 8:17 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [masakari] problems starting up masakari instance 
monitoring in devstack @ master



So i believe the error is:

HttpException: HttpException: Expecting to find domain in project.



I have attached the /etc/masakarimonitors/masakarimonitors.conf file and the 
/etc/masakari/masakari.conf file .



See the domain related attributes in each file below.



Is the Default vs default causing this problem ?

Are there other domain related attributes that should be set to default ?



stack@devstack-masakari:~$ fgrep -i domain /etc/masakari/masakari.conf

project_domain_name = Default

user_domain_name = Default



stack@devstack-masakari:~$ fgrep -i domain 
/etc/masakarimonitors/masakarimonitors.conf

#logging_user_identity_format = %(user)s %(tenant)s %(domain)s %(user_domain)s 
%(project_domain)s

# Domain ID to scope to (string value)

#domain_id = 

# Domain name to scope to (string value)

#domain_name = 

# Domain ID containing project (string value)

#project_domain_id = 

# Domain name containing project (string value)

#project_domain_name = 

project_domain_name = default

#

[openstack-dev] [Neutron] Status of adding global-req-id support in neutron

2017-11-28 Thread Bhor, Dinesh

Hi Neutron devs,

This is regarding adding global-req-id support in Neutron projects.

Below is the spec and URL for reference:
spec: https://review.openstack.org/#/c/464746/
status of patches submitted: 
https://review.openstack.org/#/q/message:I65de8261746b25d45e105394f4eeb95b9cb3bd42

Is anyone working on adding global-req-id support in neutron project ?
I would like to know the status of this feature.
I was having information that Sean Dague is working on this.

@Sean-
It will be great if your share the status of adding global-req-id support in 
neutron.
I will be happy to help if required.

Thanks and Regards,
Dinesh Bhor | App. Software Dev. Cnslt.
dinesh.b...@nttdata.com | m. +91.9730809841 | 
VOIP. 8833 8622
NTT DATA Services | nttdataservices.com | 
@nttdataservices  | Digital & Application Services


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing 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] [masakari] Propose changes of the core team

2017-10-13 Thread Bhor, Dinesh

Not a core but contributes to Masakari.


(A) Proposed to remove from Core team:
   (1) Toshikazu Ichikawa
   I think we should also consider Toshikazu Ichikawa San in "Confirm your 
availability as Core member".


B) Confirm your availability as Core member:
   Following members, please confirm your ability to contribute to
   Masakari in Queens and future cycles.
   (1) Takashi Kajinami
   (2) Masahito Muroi

   +1


(C) Add to new members to core team:
   (1) Adam Spiers (Suse)
   (2) Kengo Takahara (NTT-TX)

   ++1 Very much deserving candidates.


Thanks and Regards,

Dinesh Bhor | App. Software Dev. Cnslt.

dinesh.b...@nttdata.com | m. +91.9730809841 | 
VOIP. 8833 8622

NTT DATA Services | nttdataservices.com | 
@nttdataservices  | Digital & Application Services


From: Sam P 
Sent: 13 October 2017 15:09
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [masakari] Propose changes of the core team

Hi All Masakari Cores,

 I would like to propose following changes to Masakari core team.

Current core team:
Masahito Muroi
Rikimaru Honjo
Sampath Priyankara (samP)
Takashi Kajinami
Toshikazu Ichikawa
Tushar Patil
Yukinori Sagara

(A) Proposed to remove from Core team:
(1) Toshikazu Ichikawa
 He was one of the initial members of the project and did a great work
on design the initial Masakari API and Masakari architecture.
However, he is no longer a active member of the community.
I would like to take this opportunity to thank Toshikazu for his work
on Masakari.

(B) Confirm your availability as Core member:
 Following members, please confirm your ability to contribute to
Masakari in Queens and future cycles.
(1) Takashi Kajinami
(2) Masahito Muroi
I understand that you are extremely busy with other tasks or other projects
in OpenStack. If it is difficult for you to contribute to Masakari,
I suggest that you step down from core team for now. In future, if you are
wish to participate again, then we can discuss about reinstate you as a core
member of the team.

(C) Add to new members to core team:
(1) Adam Spiers (Suse)
  I would like to add  Adam to core team. He is the current maintainer
of the openstack-resource-agents and leader of the OpenStack HA team.
Considering his technical knowledge of the subject, and past work he
has done in Masakari and related work[1][2],
I think Adam is one of the best persons we can have in our team.

(2) Kengo Takahara (NTT-TX)
 Kengo has been an active contributor to the Masakari project from Newton
 and heavily contribute to crate masakari-monitors and python-masakariclient
 from scratch [3].

All Masakari core members, please respond with your comments and objections.
Please cast your vote on (A) and (C).

[1] 
https://review.openstack.org/#/q/project:openstack/openstack-resource-agents-specs
[2] https://etherpad.openstack.org/p/newton-instance-ha
[3] 
http://stackalytics.com/?project_type=all=all=commits_id=takahara.kengo@as.ntts.co.jp

--- Regards,
Sampath

__
OpenStack Development Mailing 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 mailing list - lists.openstack.org Mailing 
Lists
lists.openstack.org
This list for the developers of OpenStack to discuss development issues and 
roadmap. It is focused on the next release of OpenStack: you should post on 
this list if ...




__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing 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] [keystone] [keystoneauth] Debug data isn't sanitized - bug 1638978

2017-09-27 Thread Bhor, Dinesh

Hi Team,

There are four solutions to fix the below bug:
https://bugs.launchpad.net/keystoneauth/+bug/1638978

1) Carry a copy of mask_password() method to keystoneauth from oslo_utils [1]:
Pros:
A. keystoneauth will use already tested and used version of mask_password.

Cons:
A. keystoneauth will have to keep the version of mask_password() method sync
with oslo_utils version.
If there are any new "_SANITIZE_KEYS" added to oslo_utils mask_password
then those should be added in keystoneauth mask_password also.
B. Copying the "mask_password" will also require to copy its supporting code
[2] which is huge.

2) Use Oslo.utils mask_password() method in keystoneauth:
Pros:
A) No synching issue as described in solution #1. keystoneauth will directly
use mask_password() method from Oslo.utils.

Cons:
A) You will need oslo.utils library to use keystoneauth.
Objection by community:
- keystoneauth community don't want any dependency on any of OpenStack common
oslo libraries.
Please refer to the comment from Morgan:
https://bugs.launchpad.net/keystoneauth/+bug/1700751/comments/3

3) Add a custom logging filter in oslo logger
Please refer to POC sample here: http://paste.openstack.org/show/617093/
OpenStack core services using any OpenStack individual python-*client (for e.g
python-cinderclient used in nova service) will need to pass oslo_logger object
during it's
initialization which will do the work of masking sensitive information.
Note: In nova, oslo.logger object is not passed during cinder client
initialization
(https://github.com/openstack/nova/blob/master/nova/volume/cinder.py#L135-L141),
In this case, sensitive information will not be masked as it isn't using
Oslo.logger.

Pros:
A) No changes required in oslo.logger or any OpenStack services if
mask_password method is modified in oslo.utils.

Cons:
A) Every log message will be scanned for certain password fields degrading the
performance.
B) If consumer of keystoneauth doesn't use oslo_logger, then the sensitive
information will not be masked.
C) Will need to make changes wherever applicable to the OpenStack core services
to pass oslo.logger object during python-novaclient initialization.

4) Add mask_password formatter parameter in oslo_log:
Add "mask_password" formatter to sanitize sensitive data and pass it as a
keyword argument to the log statement.
If the mask_password is set, then only the sensitive information will be masked
at the time of logging.
The log statement will look like below:

logger.debug("'adminPass': 'Now you see me'"), mask_password=True)

Please refer to the POC code here: http://paste.openstack.org/show/618019/

Pros:
A) No changes required in oslo.logger or any OpenStack services if
mask_password method is modified in oslo.utils.

Cons:
A) If consumer of keystoneauth doesn't use oslo_logger, then the sensitive
information will not be masked.
B) If you forget to pass mask_password=True for logging messages where
sensitive information is present, then those fields won't be masked with ***.
But this can be clearly documented as suggested by Morgan and Lance.
C) This solution requires you to add a below check in keystoneauth to avoid
from an exception being raised in case logger is pure python Logger as it
doesn't accept mask_password keyword argument.

if isinstance(logger, logging.Logger):
logger.debug(' '.join(string_parts))
else:
logger.debug(' '.join(string_parts), mask_password=True)

This check assumes that the logger instance will be oslo_log only if it is not
of python default logging.Logger.
Keystoneauth community is not ready to have any dependency on any oslo-* lib,
so it seems this solution has low acceptance chances.

Please let me know your opinions about the above four approaches. Which one
should we adopt?

[1]
https://github.com/openstack/oslo.utils/blob/master/oslo_utils/strutils.py#L248-L313
[2]
https://github.com/openstack/oslo.utils/blob/6e04f882c4308ff64fa199d1b127ad225e0a30c4/oslo_utils/strutils.py#L56-L96

[Description: Description:
cid:image009.jpg@01D193F0.F70B44C0]

[Description: Description:
cid:image010.jpg@01D193F0.F70B44C0]

[Description: Description:
cid:image011.jpg@01D193F0.F70B44C0]

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the

Re: [openstack-dev] [requirements][masakari] FFE for adding python-masakariclient in global-requirements

2017-08-10 Thread Bhor, Dinesh

Hi Tony and all,

Sorry for the delay to reply. 

We are planning to create the stable/pike branch soon. I am contacting the PTL 
Sampath Priyankara(samP) for the exact date.

Thanks and Regards,
Dinesh Bhor | App. Software Dev. Cnslt.
dinesh.b...@nttdata.com | nttdata.com/americas

-Original Message-
From: Tony Breeds [mailto:t...@bakeyournoodle.com] 
Sent: Wednesday, August 09, 2017 5:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [requirements][masakari] FFE for adding 
python-masakariclient in global-requirements

On Wed, Aug 09, 2017 at 06:39:52AM +, Bhor, Dinesh wrote:
> Hello everyone,
> 
> I would like to ask for the FFE for adding "python-masakariclient" in 
> global-requirements.
> 
> Earlier, we were not having "check-requirements" job for masakari-* projects. 
> At that time, we use to manually add "python-masakariclient" as a requirement 
> in masakari-monitors project [1].
> Now we have added "check-requirements" job for masakari-* projects, 
> but we missed to add "python-masakariclient" in global-requirements and now 
> the bigger issue is it is not possible to manually update the 
> "python-masakariclient" requirement in masakari-monitors project as the 
> "gate-masakari-monitors-requirements" requirements job keeps failing on the 
> patch [1].
> To resolve this problem permanently, we need to add "python-masakariclient" 
> library requirement in global-requirements.
> I have submitted a patch [2] for adding the python-masakariclient in 
> global-requirements.
> 
> Please consider my request and grant FFE to solve this problem.
> 
> [1] https://review.openstack.org/#/c/457491/
> [2] https://review.openstack.org/#/c/491692/

Are you intending to create a stable/pike branch and perform releases from it?  
Looking at masakari-monitors the whole history can be seen on one page so it's 
clearly very new.

Yours Tony.

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
OpenStack Development Mailing 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] [requirements][masakari] FFE for adding python-masakariclient in global-requirements

2017-08-09 Thread Bhor, Dinesh

Hello everyone,

I would like to ask for the FFE for adding "python-masakariclient" in 
global-requirements.

Earlier, we were not having "check-requirements" job for masakari-* projects. 
At that time, we use to manually add "python-masakariclient" as a requirement 
in masakari-monitors project [1].
Now we have added "check-requirements" job for masakari-* projects, but we 
missed to add "python-masakariclient" in global-requirements and now the bigger 
issue is it is not possible
to manually update the "python-masakariclient" requirement in masakari-monitors 
project as the "gate-masakari-monitors-requirements" requirements job keeps 
failing on the patch [1].
To resolve this problem permanently, we need to add "python-masakariclient" 
library requirement in global-requirements.
I have submitted a patch [2] for adding the python-masakariclient in 
global-requirements.

Please consider my request and grant FFE to solve this problem.

[1] https://review.openstack.org/#/c/457491/
[2] https://review.openstack.org/#/c/491692/


Thank you,
Dinesh Bhor | App. Software Dev. Cnslt.
dinesh.b...@nttdata.com | nttdata.com/americas

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.db] Stepping down from core

2017-06-12 Thread Bhor, Dinesh

Good luck with your new position Roman. You were always helpful and friendly.

Thanks,
Dinesh Bhor

-Original Message-
From: Roman Podoliaka [mailto:roman.podoli...@gmail.com] 
Sent: Sunday, June 11, 2017 8:03 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [oslo.db] Stepping down from core

Hi all,

I recently changed job and hasn't been able to devote as much time to oslo.db 
as it is expected from a core reviewer. I'm no longer working on OpenStack, so 
you won't see me around much.

Anyway, it's been an amazing experience to work with all of you! Best of luck! 
And see ya at various PyCon's around the world! ;)

Thanks,
Roman

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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Remove duplicate code using Data Driven Tests (DDT)

2016-07-25 Thread Bhor, Dinesh



-Original Message-
From: Sean Dague [mailto:s...@dague.net] 
Sent: Monday, July 25, 2016 5:53 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] Remove duplicate code using Data Driven 
Tests (DDT)

On 07/25/2016 08:05 AM, Daniel P. Berrange wrote:
> On Mon, Jul 25, 2016 at 07:57:08AM -0400, Sean Dague wrote:
>> On 07/22/2016 11:30 AM, Daniel P. Berrange wrote:
>>> On Thu, Jul 21, 2016 at 07:03:53AM -0700, Matt Riedemann wrote:
>>>> On 7/21/2016 2:03 AM, Bhor, Dinesh wrote:
>>>>
>>>> I agree that it's not a bug. I also agree that it helps in some 
>>>> specific types of tests which are doing some kind of input 
>>>> validation (like the patch you've proposed) or are simply iterating 
>>>> over some list of values (status values on a server instance for example).
>>>>
>>>> Using DDT in Nova has come up before and one of the concerns was 
>>>> hiding details in how the tests are run with a library, and if 
>>>> there would be a learning curve. Depending on the usage, I 
>>>> personally don't have a problem with it. When I used it in manila 
>>>> it took a little getting used to but I was basically just looking 
>>>> at existing tests and figuring out what they were doing when adding new 
>>>> ones.
>>>
>>> I don't think there's significant learning curve there - the way it 
>>> lets you annotate the test methods is pretty easy to understand and 
>>> the ddt docs spell it out clearly for newbies. We've far worse 
>>> things in our code that create a hard learning curve which people 
>>> will hit first :-)
>>>
>>> People have essentially been re-inventing ddt in nova tests already 
>>> by defining one helper method and them having multiple tests methods 
>>> all calling the same helper with a different dataset. So ddt is just 
>>> formalizing what we're already doing in many places, with less code 
>>> and greater clarity.
>>>
>>>> I definitely think DDT is easier to use/understand than something 
>>>> like testscenarios, which we're already using in Nova.
>>>
>>> Yeah, testscenarios feels little over-engineered for what we want 
>>> most of the time.
>>
>> Except, DDT is way less clear (and deterministic) about what's going 
>> on with the test name munging. Which means failures are harder to 
>> track back to individual tests and data load. So debugging the failures is 
>> harder.
> 
> I'm not sure what you think is unclear - given an annotated test:
> 
>@ddt.data({"foo": "test", "availability_zone": "nova1"},
>   {"name": "  test  ", "availability_zone": "nova1"},
>   {"name": "", "availability_zone": "nova1"},
>   {"name": "x" * 256, "availability_zone": "nova1"},
>   {"name": "test", "availability_zone": "x" * 256},
>   {"name": "test", "availability_zone": "  nova1  "},
>   {"name": "test", "availability_zone": ""},
>   {"name": "test", "availability_zone": "nova1", "foo": "bar"})
> def test_create_invalid_create_aggregate_data(self, value):
> 
> It is generated one test for each data item:
> 
>  test_create_invalid_create_aggregate_data_1
>  test_create_invalid_create_aggregate_data_2
>  test_create_invalid_create_aggregate_data_3
>  test_create_invalid_create_aggregate_data_4
>  test_create_invalid_create_aggregate_data_5
>  test_create_invalid_create_aggregate_data_6
>  test_create_invalid_create_aggregate_data_7
>  test_create_invalid_create_aggregate_data_8
> 
> This seems about as obvious as you can possibly get

At least when this was attempted to be introduced into Tempest, the naming was 
a lot less clear, maybe it got better. But I still think milestone 3 isn't the 
time to start a thing like this.

-Sean

Hi Sean,

IMO it is possible to have a descriptive name to test cases using DDT.

For ex.,

@ddt.data(annotated('missing_name', {"foo": "test", "availability_zone": 
"nova1"}),
  annotated('name_greater_than_255_characters', {"name": "x" * 256, 
"availability_zone": "nova1"}))
def test_create_invalid_aggregate_data(self, value):

Re: [openstack-dev] [keystone][murano][trove][imm] Changing OpenStack LLC to OpenStack Foundation