Re: [openstack-dev] [devstack] Core team proposals

2014-08-08 Thread Gary Kotton
+1

From: chandankumar 
chandankumar.093...@gmail.commailto:chandankumar.093...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Friday, August 8, 2014 at 2:14 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [devstack] Core team proposals


On 08/08/2014 01:05 PM, Chmouel Boudjnah wrote:

On Thu, Aug 7, 2014 at 8:09 PM, Dean Troyer 
dtro...@gmail.commailto:dtro...@gmail.com wrote:
Please respond in the usual manner, +1 or concerns.

+1, I would be happy to see Ian joining the team.

+1
Chmouel



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

Thanks,

Chandan Kumar

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


Re: [openstack-dev] [Neutron][LBaaS] Improvements to current reviews

2014-08-10 Thread Gary Kotton
Hi,
I took a look at https://review.openstack.org/#/c/105331/ and had one minor 
issue which I think can be addressed. Prior to approving we need to understand 
what the state of the V2 API will be.
Thanks
Gary

From: Vijay Venkatachalam 
vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Sunday, August 10, 2014 at 2:57 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Improvements to current reviews


Thanks Brandon for constant  improvisation.

I agree with Doug. Please update current one. We already hv  more number of 
reviews :-). It will be difficult to manage if we add more.

Thanks,
Vijay

Sent using CloudMagic

On Sun, Aug 10, 2014 at 3:23 AM, Doug Wiegley 
do...@a10networks.commailto:do...@a10networks.com wrote:


I think you should update the current reviews (new patch set, not additional 
review.)

Doug


 On Aug 9, 2014, at 3:34 PM, Brandon Logan 
 brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:

 So I've done some work on improving the code on the current pending
 reviews.  And would like to get peoples' opinions on whether I should
 add antoher patch set to those reviews, or add the changes as as another
 review dependent on the pending ones.

 To be clear, no matter what the first review in the chain will not
 change:
 https://review.openstack.org/#/c/105331/

 However, if adding another patch set is preferrable then plugin and db
 implementation review would get another patch set and then obviously
 anything depending on that.

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

 My opinion is that I'd like to get both of these in as a new patch set.
 Reason being that the reviews don't have any +2's and there is
 uncertainty because of the GBP discussion.  So, I don't think it'd be a
 major issue if a new patch set was created.  Speak up if you think
 otherwise.  I'd like to get as many people's thoughts as possible.

 The changes are:

 1) Added data models, which are just plain python object mimicking the
 sql alchemy models, but don't have the overhead or dynamic nature of
 being sql alchemy models.  These data models are now returned by the
 database methods, instead of the sql alchemy objects.  Also, I moved the
 definition of the sql alchemy models into its own module.  I've been
 wanting to do this but since I thought I was running out of time I left
 it for later.

 These shouldn't cause many merge/rebase conflicts, but it probably cause
 a few because the sql alchemy models were moved to a different module.


 2) The LoadBalancerPluginv2 no longer inherits from the
 LoadBalancerPluginDbv2.  The database is now a composite attribute of
 the plugin (i.e. plugin.db.get_loadbalancer()).  This cleans up the code
 a bit and removes the necessity for _delete_db_entity methods that the
 drivers needed because now they can actually call the database methods.
 Also, this makes testing more clear, though I have not added any tests
 for this because the previous tests are sufficient for now.  Adding the
 appropriate tests would add 1k or 2k lines most likely.

 This will likely cause more conflicts because the _db_delete_entity
 methods have been removed.  However, the new driver interface/mixins
 defined a db_method for all drivers to use, so if that is being used
 there shouldn't be any problems.

 Thanks,
 Brandon




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

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


Re: [openstack-dev] [nova] fair standards for all hypervisor drivers

2014-08-11 Thread Gary Kotton
In the past there was smokestack that used a fedora version of libvirt.
Any idea what happened to that?

On 8/11/14, 12:53 PM, Daniel P. Berrange berra...@redhat.com wrote:

On Fri, Aug 08, 2014 at 09:06:29AM -0400, Russell Bryant wrote:
 On 08/07/2014 08:06 PM, Michael Still wrote:
  It seems to me that the tension here is that there are groups who
  would really like to use features in newer libvirts that we don't CI
  on in the gate. Is it naive to think that a possible solution here is
  to do the following:
  
   - revert the libvirt version_cap flag
 
 I don't feel strongly either way on this.  It seemed useful at the time
 for being able to decouple upgrading libvirt and enabling features that
 come with that.  I'd like to let Dan get back from vacation and weigh in
 on it, though.

Yes, I think that version cap feature is valuable no matter what we
do about CI testing, which is why I +2'd it originally.

 
 I wonder if the job could be as simple as one with an added step in the
 config to install latest libvirt from source.  Dan, do you think someone
 could add a libvirt-current.tar.gz to
https://urldefense.proofpoint.com/v1/url?u=http://libvirt.org/sources/k=
oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPh
CZFxPEq8%3D%0Am=rPfYVc630ymUlJf3W60dbNbCgcW5TimMFx1ooqIdr38%3D%0As=0298
f3506d0ac41e81fce6b0b3096455c3e78ba578970e42290997a766b0811e ?
 Using the latest release seems better than master from git.

I'd strongly recommend against using GIT master. It will cause openstack
CI more pain than benefits. Using the latest stable release is a better
bet

 I'll mess around and see if I can spin up an experimental job.

There is work to add support for this in devestack already which I
prefer since it makes it easy for developers to get an environment
which matches the build system:

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

Regards,
Daniel
-- 
|: 
https://urldefense.proofpoint.com/v1/url?u=http://berrange.com/k=oIvRg1%2
BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%
3D%0Am=rPfYVc630ymUlJf3W60dbNbCgcW5TimMFx1ooqIdr38%3D%0As=d7e4cac70435cd
1066f4f7ec8795f16c345c0ca4529bb4b3033762552817e775  -o-
https://urldefense.proofpoint.com/v1/url?u=http://www.flickr.com/photos/db
errange/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfD
tysg45MkPhCZFxPEq8%3D%0Am=rPfYVc630ymUlJf3W60dbNbCgcW5TimMFx1ooqIdr38%3D%
0As=0f30863dcc9a34ffe520b0cee787f76bb67334963ebcd57d9b53b3890f0265ea :|
|: 
https://urldefense.proofpoint.com/v1/url?u=http://libvirt.org/k=oIvRg1%2B
dGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3
D%0Am=rPfYVc630ymUlJf3W60dbNbCgcW5TimMFx1ooqIdr38%3D%0As=07044ea24f9483f
b87f1c67511c4c62a3e2b8971ad8418b7a0a61068f623f529  -o-
 
https://urldefense.proofpoint.com/v1/url?u=http://virt-manager.org/k=oIvR
g1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxP
Eq8%3D%0Am=rPfYVc630ymUlJf3W60dbNbCgcW5TimMFx1ooqIdr38%3D%0As=185d42ae1a
5b0422c1fa3306e55397461140024c38530f3a6986a72c51edec08 :|
|: 
https://urldefense.proofpoint.com/v1/url?u=http://autobuild.org/k=oIvRg1%
2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8
%3D%0Am=rPfYVc630ymUlJf3W60dbNbCgcW5TimMFx1ooqIdr38%3D%0As=2e295d841588d
8cb243a6c37eb0c17007760ba0506cd621fff34de6a6f7c7b03   -o-
https://urldefense.proofpoint.com/v1/url?u=http://search.cpan.org/~danberr
/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45M
kPhCZFxPEq8%3D%0Am=rPfYVc630ymUlJf3W60dbNbCgcW5TimMFx1ooqIdr38%3D%0As=39
b473e1829f6e6c4f7bd4e27304334df8c0d1e9ac2cf7432490ac72fbe111e6 :|
|: 
https://urldefense.proofpoint.com/v1/url?u=http://entangle-photo.org/k=oI
vRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZF
xPEq8%3D%0Am=rPfYVc630ymUlJf3W60dbNbCgcW5TimMFx1ooqIdr38%3D%0As=c100dc7d
e638a7bd0477a6d9723599041f442e80207213597a220e1a2cd34c74   -o-
https://urldefense.proofpoint.com/v1/url?u=http://live.gnome.org/gtk-vnck
=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPh
CZFxPEq8%3D%0Am=rPfYVc630ymUlJf3W60dbNbCgcW5TimMFx1ooqIdr38%3D%0As=5c43d
0b2c8ad31d53813420ce9ab1885943b4ef88458006edcb2295f47c46846 :|

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


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


[openstack-dev] [Nova] PCI support

2014-08-11 Thread Gary Kotton
Hi,
At the moment all of the drivers are required CI support. Are there any plans 
regarding the PIC support. I understand that this is something that requires 
specific hardware. Are there any plans to add this?
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] PCI support

2014-08-11 Thread Gary Kotton
Thanks for the update.

From: Robert Li (baoli) ba...@cisco.commailto:ba...@cisco.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, August 11, 2014 at 5:08 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] PCI support

Gary,

Cisco is adding it in our CI testbed. I guess that mlnx is doing the same for 
their MD as well.

-Robert

On 8/11/14, 9:05 AM, Gary Kotton 
gkot...@vmware.commailto:gkot...@vmware.com wrote:

Hi,
At the moment all of the drivers are required CI support. Are there any plans 
regarding the PIC support. I understand that this is something that requires 
specific hardware. Are there any plans to add this?
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [OpenStack][InstanceGroup] metadetails and metadata in instance_group.py

2014-08-11 Thread Gary Kotton


On 8/11/14, 6:06 PM, Dan Smith d...@danplanet.com wrote:

 As the person who -2'd the review, I'm thankful you raised this issue on
 the ML, Jay. Much appreciated.

The metadetails term isn't being invented in this patch, of course. I
originally complained about the difference when this was being added:

https://review.openstack.org/#/c/109505/1/nova/api/openstack/compute/contr
ib/server_groups.py,cm

As best I can tell, the response in that patch set about why it's being
translated is wrong (backwards). I expect that the API extension at the
time called it metadetails and they decided to make the object the
same and do the translation there.

From what I can tell, the actual server_group API extension that made it
into the tree never got the ability to set/change/etc the
metadata/metadetails anyway, so there's no reason (AFAICT) to add it in
wrongly.

If we care to have this functionality, then I propose we change the
attribute on the object (we can handle this with versioning) and reflect
it as metadata in the API.

However, I have to ask: do we really need another distinct metadata
store attached to server_groups? If not, how about we just remove it
from the database and the object, clean up the bit of residue that is
still in the API extension and be done with it?

The initial version of the feature did not make use of this. The reason
was that we chose for a very
Limited subset to be used, that is, affinity and anti affinity. Moving
forwards we would like to implement
A number of different policies with this. We can drop it at the moment due
to the fact that it is not used.

I think that Yathi may be using this for the constrain scheduler. But I am
not 100% sure.


--Dan



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


Re: [openstack-dev] [Nova] PCI support

2014-08-12 Thread Gary Kotton
Thanks, the concern is for the code in Nova and not in Neutron. That is, there 
is quite a lot of PCI code being added and no way of knowing that it actually 
works (unless we trust the developers working on it :)).
Thanks
Gary

From: Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com
Date: Tuesday, August 12, 2014 at 10:25 AM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Cc: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com
Subject: RE: [openstack-dev] [Nova] PCI support

Hi Gary,
Mellanox already established CI support on Mellanox SR-IOV NICs, as one of the 
jobs of Mellanox External Testing CI 
(Check-MLNX-Neutron-ML2-Sriov-driverhttps://urldefense.proofpoint.com/v1/url?u=http://144.76.193.39/ci-artifacts/94888/13/Check-MLNX-Neutron-ML2-Sriov-driverk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=OFhjKT9ipKmAmkiQpq6hlqZIHthaGP7q1PTygNW2RXs%3D%0As=13fdee114a421eeed33edf26a639f8450df6efa361ba912c41694ff75292e789).
Meanwhile not voting, but will be soon.

BR,
Irena

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Monday, August 11, 2014 5:17 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] PCI support

Thanks for the update.

From: Robert Li (baoli) ba...@cisco.commailto:ba...@cisco.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, August 11, 2014 at 5:08 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] PCI support

Gary,

Cisco is adding it in our CI testbed. I guess that mlnx is doing the same for 
their MD as well.

-Robert

On 8/11/14, 9:05 AM, Gary Kotton 
gkot...@vmware.commailto:gkot...@vmware.com wrote:

Hi,
At the moment all of the drivers are required CI support. Are there any plans 
regarding the PIC support. I understand that this is something that requires 
specific hardware. Are there any plans to add this?
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] PCI support

2014-08-13 Thread Gary Kotton
Hi,
If I understand correctly the only way that this work is with nova and neutron 
running. My understanding would be to have the CI running with this as the 
configuration. I just think that this should be a prerequisite similar to 
having validations of virtualization drivers.
Does that make sense?
Thanks
Gary

From: Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com
Date: Wednesday, August 13, 2014 at 9:01 AM
To: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com, OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: RE: [openstack-dev] [Nova] PCI support

Hi Gary,
I understand your concern. I think CI is mandatory to ensure that code is not 
broken. While unit tests provide great value, it may end up with the code that 
does not work...
I am not sure how this code can be checked for validity without running the 
neutron part.
Probably our CI job should be triggered by nova changes in the PCI area.
What do you suggest?

Irena

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Tuesday, August 12, 2014 4:29 PM
To: Irena Berezovsky; OpenStack Development Mailing List (not for usage 
questions)
Subject: Re: [openstack-dev] [Nova] PCI support

Thanks, the concern is for the code in Nova and not in Neutron. That is, there 
is quite a lot of PCI code being added and no way of knowing that it actually 
works (unless we trust the developers working on it :)).
Thanks
Gary

From: Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com
Date: Tuesday, August 12, 2014 at 10:25 AM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Cc: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com
Subject: RE: [openstack-dev] [Nova] PCI support

Hi Gary,
Mellanox already established CI support on Mellanox SR-IOV NICs, as one of the 
jobs of Mellanox External Testing CI 
(Check-MLNX-Neutron-ML2-Sriov-driverhttps://urldefense.proofpoint.com/v1/url?u=http://144.76.193.39/ci-artifacts/94888/13/Check-MLNX-Neutron-ML2-Sriov-driverk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=OFhjKT9ipKmAmkiQpq6hlqZIHthaGP7q1PTygNW2RXs%3D%0As=13fdee114a421eeed33edf26a639f8450df6efa361ba912c41694ff75292e789).
Meanwhile not voting, but will be soon.

BR,
Irena

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Monday, August 11, 2014 5:17 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] PCI support

Thanks for the update.

From: Robert Li (baoli) ba...@cisco.commailto:ba...@cisco.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, August 11, 2014 at 5:08 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] PCI support

Gary,

Cisco is adding it in our CI testbed. I guess that mlnx is doing the same for 
their MD as well.

-Robert

On 8/11/14, 9:05 AM, Gary Kotton 
gkot...@vmware.commailto:gkot...@vmware.com wrote:

Hi,
At the moment all of the drivers are required CI support. Are there any plans 
regarding the PIC support. I understand that this is something that requires 
specific hardware. Are there any plans to add this?
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron] Rotating the weekly Neutron meeting

2014-08-13 Thread Gary Kotton
Huge +1

On 8/13/14, 5:19 PM, Paul Michali (pcm) p...@cisco.com wrote:

+1

PCM (Paul Michali)

MAIL Š..Š. p...@cisco.com
IRC ŠŠ..Š pcm_ (irc.freenode.com)
TW ŠŠŠ... @pmichali
GPG Key Š 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83



On Aug 13, 2014, at 10:05 AM, Kyle Mestery mest...@mestery.com wrote:

 Per this week's Neutron meeting [1], it was decided that offering a
 rotating meeting slot for the weekly Neutron meeting would be a good
 thing. This will allow for a much easier time for people in
 Asia/Pacific timezones, as well as for people in Europe.
 
 So, I'd like to propose we rotate the weekly as follows:
 
 Monday 2100UTC
 Tuesday 1400UTC
 
 If people are ok with these time slots, I'll set this up and we'll
 likely start with this new schedule in September, after the FPF.
 
 Thanks!
 Kyle
 
 [1] 
http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-0
8-11-21.00.html
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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


Re: [openstack-dev] Enabling silent Docker tests for Nova?

2014-08-16 Thread Gary Kotton
+1

From: Eric Windisch ewindi...@docker.commailto:ewindi...@docker.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Friday, August 15, 2014 at 9:45 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] Enabling silent Docker tests for Nova?

I have proposed a _silent_ check for Nova for integration of the Docker driver:

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

It has been established that this code cannot move back into Nova until the 
tests are running and have a solid history of success. That cannot happen 
unless we're allowed to run the tests. Running a silent check on changes to 
Nova is the first step in establishing that history.

Joe Gordon suggests we need a spec to bring the driver back into Nova. Besides 
the fact that specs are closed and there is no intention of reintegrating the 
driver for Juno, I'm uncertain of proposing a spec without first having solid 
history of successful testing, especially given the historical context of this 
driver's relationship with Nova.

If we could enable silent checks, we could help minimize API skew and branch 
breakages, improving driver quality and reducing maintenance while we prepare 
for the Kilo spec + merge windows. Furthermore, by having a history of testing, 
we can seek faster inclusion into Kilo.

Finally, I acknowledge that we may be entering a window of significant load on 
the CI servers and I'm sensitive to the needs of the infrastructure team to 
remain both focused and to conserve precious compute resources. If this is an 
issue, then I'd like to plot a timeline, however rough, with the infrastructure 
team.

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


[openstack-dev] [All] LOG.warning/LOG.warn

2014-08-17 Thread Gary Kotton
Hi,
Over the last few weeks I have seen a number of patches where LOG.warn is 
replacing LOG.warning. I think that if we do something it should be the 
opposite as warning is the documented one in python 2 and 3 
https://docs.python.org/3/howto/logging.html.
Any thoughts?
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][core] Expectations of core reviewers

2014-08-19 Thread Gary Kotton


From: Joe Gordon joe.gord...@gmail.commailto:joe.gord...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, August 18, 2014 at 9:31 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova][core] Expectations of core reviewers




On Mon, Aug 18, 2014 at 8:18 AM, Russell Bryant 
rbry...@redhat.commailto:rbry...@redhat.com wrote:
On 08/18/2014 06:18 AM, Thierry Carrez wrote:
 Doug Hellmann wrote:
 On Aug 13, 2014, at 4:42 PM, Russell Bryant 
 rbry...@redhat.commailto:rbry...@redhat.com wrote:
 Let me try to say it another way.  You seemed to say that it wasn't much
 to ask given the rate at which things happen in OpenStack.  I would
 argue that given the rate, we should not try to ask more of individuals
 (like this proposal) and risk burnout.  Instead, we should be doing our
 best to be more open an inclusive to give the project the best chance to
 grow, as that's the best way to get more done.

 I think an increased travel expectation is a raised bar that will hinder
 team growth, not help it.

 +1, well said.

 Sorry, I was away for a few days. This is a topic I have a few strong
 opinions on :)

 There is no denial that the meetup format is working well, comparatively
 better than the design summit format. There is also no denial that that
 requiring 4 travels per year for a core dev is unreasonable. Where is
 the limit ? Wouldn't we be more productive and aligned if we did one per
 month ? No, the question is how to reach a sufficient level of focus and
 alignment while keeping the number of mandatory travel at 2 per year.

 I don't think our issue comes from not having enough F2F time. Our issue
 is that the design summit no longer reaches its objectives of aligning
 key contributors on a common plan, and we need to fix it.

 We established the design summit as the once-per-cycle opportunity to
 have face-to-face time and get alignment across the main contributors to
 a project. That used to be completely sufficient, but now it doesn't
 work as well... which resulted in alignment and team discussions to be
 discussed at mid-cycle meetups instead. Why ? And what could we change
 to have those alignment discussions at the design summit again ?

 Why are design summits less productive that mid-cycle meetups those days
 ? Is it because there are too many non-contributors in the design summit
 rooms ? Is it the 40-min format ? Is it the distractions (having talks
 to give somewhere else, booths to attend, parties and dinners to be at)
 ? Is it that beginning of cycle is not the best moment ? Once we know
 WHY the design summit fails its main objective, maybe we can fix it.

 My gut feeling is that having a restricted audience and a smaller group
 lets people get to the bottom of an issue and reach consensus. And that
 you need at least half a day or a full day of open discussion to reach
 such alignment. And that it's not particularly great to get such
 alignment in the middle of the cycle, getting it at the start is still
 the right way to align with the release cycle.

 Nothing prevents us from changing part of the design summit format (even
 the Paris one!), and restrict attendance to some of the sessions. And if
 the main issue is the distraction from the conference colocation, we
 might have to discuss the future of co-location again. In that 2 events
 per year objective, we could make the conference the optional cycle
 thing, and a developer-oriented specific event the mandatory one.

 If we manage to have alignment at the design summit, then it doesn't
 spell the end of the mid-cycle things. But then, ideally the extra
 mid-cycle gatherings should be focused on getting specific stuff done,
 rather than general team alignment. Think workshop/hackathon rather than
 private gathering. The goal of the workshop would be published in
 advance, and people could opt to join that. It would be totally optional.

Great response ... I agree with everything you've said here.  Let's
figure out how to improve the design summit to better achieve team
alignment.

Of the things you mentioned, I think the biggest limit to alignment has
been the 40 minute format.  There are some topics that need more time.
It may be that we just need to take more advantage of the ability to
give a single topic multiple time slots to ensure enough time is
available.  As Dan discussed, there are some topics that we could stand
to turn down and distribute information another way that is just as
effective.

I would also say that the number of things going on at one time is also
problematic.  Not only are there several design summit sessions going
once, but there are conference sessions and customer meetings.  The
rapid rate of jumping around and context switching is exhausting.  It
also makes it a bit harder to get critical mass for an extended period
of time around a topic.  In mid-cycle 

[openstack-dev] [Nova][VMware] Minesweeper status

2014-08-19 Thread Gary Kotton
Hi,
Minesweeper is back up and running - this is now called Vmware NSX CI.
A patch for the deprecation of the ESX driver resulted in endless Minesweeper 
failures (https://review.openstack.org/#/c/108854/). These were resolved by a 
number of patches, the last being https://review.openstack.org/#/c/113923/.
So if you would like a MS +1 then please make sure that you have rebased your 
code - any code posted prior to the 14th August may not get a+1 from MS.
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Neutron] Author tags

2014-08-27 Thread Gary Kotton
Hi,
A few cycles ago the Nova group decided to remove @author from copyright 
statements. This is due to the fact that this information is stored in git. 
After adding a similar hacking rule to Neutron it has stirred up some debate.
Does anyone have any reason to for us not to go ahead with 
https://review.openstack.org/#/c/112329/.
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] libvirt version_cap, a postmortem

2014-08-31 Thread Gary Kotton
Hi,
Very nice write up. I take my hat off for taking the time and doing a
postmortem. As a community we really need to work on how we communicate
with one another. At the end of the day we all have the common goal in the
success of the project.
At times I feel like things are done very quickly without any discussion
at all, for example the reverting of patches. I can understand when the
gate is broken that this is a must, but in other cases I think that we
need to discuss things in order to build trust and for people in the
community to learn what they may or may not have done correctly.
Thanks
Gary

On 8/30/14, 7:08 PM, Mark McLoughlin mar...@redhat.com wrote:


Hey

The libvirt version_cap debacle continues to come up in conversation and
one perception of the whole thing appears to be:

  A controversial patch was ninjaed by three Red Hat nova-cores and
  then the same individuals piled on with -2s when a revert was proposed
  to allow further discussion.

I hope it's clear to everyone why that's a pretty painful thing to hear.
However, I do see that I didn't behave perfectly here. I apologize for
that.

In order to understand where this perception came from, I've gone back
over the discussions spread across gerrit and the mailing list in order
to piece together a precise timeline. I've appended that below.

Some conclusions I draw from that tedious exercise:

 - Some people came at this from the perspective that we already have
   a firm, unwritten policy that all code must have functional written
   tests. Others see that test all the things is interpreted as a
   worthy aspiration, but is only one of a number of nuanced factors
   that needs to be taken into account when considering the addition of
   a new feature.

   i.e. the former camp saw Dan Smith's devref addition as attempting
   to document an existing policy (perhaps even a more forgiving
   version of an existing policy), whereas other see it as a dramatic
   shift to a draconian implementation of test all the things.

 - Dan Berrange, Russell and I didn't feel like we were ninjaing a
   controversial patch - you can see our perspective expressed in
   multiple places. The patch would have helped the live snapshot
   issue, and has other useful applications. It does not affect the
   broader testing debate.

   Johannes was a solitary voice expressing concerns with the patch,
   and you could see that Dan was particularly engaged in trying to
   address those concerns and repeating his feeling that the patch was
   orthogonal to the testing debate.

   That all being said - the patch did merge too quickly.

 - What exacerbates the situation - particularly when people attempt to
   look back at what happened - is how spread out our conversations
   are. You look at the version_cap review and don't see any of the
   related discussions on the devref policy review nor the mailing list
   threads. Our disjoint methods of communicating contribute to
   misunderstandings.

 - When it came to the revert, a couple of things resulted in
   misunderstandings, hurt feelings and frayed tempers - (a) that our
   retrospective veto revert policy wasn't well understood and (b)
   a feeling that there was private, in-person grumbling about us at
   the mid-cycle while we were absent, with no attempt to talk to us
   directly.


To take an even further step back - successful communities like ours
require a huge amount of trust between the participants. Trust requires
communication and empathy. If communication breaks down and the pressure
we're all under erodes our empathy for each others' positions, then
situations can easily get horribly out of control.

This isn't a pleasant situation and we should all strive for better.
However, I tend to measure our flamewars against this:

  
https://urldefense.proofpoint.com/v1/url?u=https://mail.gnome.org/archives
/gnome-2-0-list/2001-June/msg00132.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0
Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=WnWRoI3TSZlh7lPB
Z67S7KqCg6LUo1tMHirwwCXEY0o%3D%0As=cb0293d31053f67f603946a43e6ebb99333df6
d73adeb6d3965380aa94424519

GNOME in June 2001 was my introduction to full-time open-source
development, so this episode sticks out in my mind. The two individuals
in that email were/are immensely capable and reasonable people, yet ...

So far, we're doing pretty okay compared to that and many other
open-source flamewars. Let's make sure we continue that way by avoiding
letting situations fester.


Thanks, and sorry for being a windbag,
Mark.

---

= July 1 =

The starting point is this review:

   https://review.openstack.org/103923

Dan Smith proposes a policy that the libvirt driver may not use libvirt
features until they have been available in Ubuntu or Fedora for at least
30 days.

The commit message mentions:

  broken us in the past when we add a new feature that requires a newer
   libvirt than we test with, and we discover that it's totally broken
   when we upgrade in the gate.

Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

2014-09-04 Thread Gary Kotton
Hi,
I do not think that Nova is in a death spiral. I just think that the
current way of working at the moment is strangling the project. I do not
understand why we need to split drivers out of the core project. Why not
have the ability to provide Œcore review¹ status to people for reviewing
those parts of the code? We have enough talented people in OpenStack to be
able to write a driver above gerrit to enable that.
Fragmenting the project will be very unhealthy.
For what it is worth having a release date at the end of a vacation is
really bad. Look at the numbers:
http://stackalytics.com/report/contribution/nova-group/30
Thanks
Gary

On 9/4/14, 3:59 PM, Thierry Carrez thie...@openstack.org wrote:

Like I mentioned before, I think the only way out of the Nova death
spiral is to split code and give control over it to smaller dedicated
review teams. This is one way to do it. Thanks Dan for pulling this
together :)

A couple comments inline:

Daniel P. Berrange wrote:
 [...]
 This is a crisis. A large crisis. In fact, if you got a moment, it's
 a twelve-storey crisis with a magnificent entrance hall, carpeting
 throughout, 24-hour portage, and an enormous sign on the roof,
 saying 'This Is a Large Crisis'. A large crisis requires a large
 plan.
 [...]

I totally agree. We need a plan now, because we can't go through another
cycle without a solution in sight.

 [...]
 This has quite a few implications for the way development would
 operate.
 
  - The Nova core team at least, would be voluntarily giving up a big
amount of responsibility over the evolution of virt drivers. Due
to human nature, people are not good at giving up power, so this
may be painful to swallow. Realistically current nova core are
not experts in most of the virt drivers to start with, and more
important we clearly do not have sufficient time to do a good job
of review with everything submitted. Much of the current need
for core review of virt drivers is to prevent the mis-use of a
poorly defined virt driver API...which can be mitigated - See
later point(s)
 
  - Nova core would/should not have automatic +2 over the virt driver
repositories since it is unreasonable to assume they have the
suitable domain knowledge for all virt drivers out there. People
would of course be able to be members of multiple core teams. For
example John G would naturally be nova-core and nova-xen-core. I
would aim for nova-core and nova-libvirt-core, and so on. I do not
want any +2 responsibility over VMWare/HyperV/Docker drivers since
they're not my area of expertize - I only look at them today because
they have no other nova-core representation.
 
  - Not sure if it implies the Nova PTL would be solely focused on
Nova common. eg would there continue to be one PTL over all virt
driver implementation projects, or would each project have its
own PTL. Maybe this is irrelevant if a Czars approach is chosen
by virt driver projects for their work. I'd be inclined to say
that a single PTL should stay as a figurehead to represent all
the virt driver projects, acting as a point of contact to ensure
we keep communication / co-operation between the drivers in sync.
 [...]

At this point it may look like our current structure (programs, one PTL,
single core teams...) prevents us from implementing that solution. I
just want to say that in OpenStack, organizational structure reflects
how we work, not the other way around. If we need to reorganize
official project structure to work in smarter and long-term healthy
ways, that's a really small price to pay.

-- 
Thierry Carrez (ttx)

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


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


Re: [openstack-dev] [Nova][FFE] Feature freeze exception for virt-driver-numa-placement

2014-09-04 Thread Gary Kotton


On 9/4/14, 4:30 PM, Sean Dague s...@dague.net wrote:

On 09/04/2014 09:21 AM, Daniel P. Berrange wrote:
 On Thu, Sep 04, 2014 at 03:07:24PM +0200, Nikola Đipanov wrote:
 On 09/04/2014 02:31 PM, Sean Dague wrote:
 On 09/04/2014 07:58 AM, Nikola Đipanov wrote:
 Hi team,

 I am requesting the exception for the feature from the subject (find
 specs at [1] and outstanding changes at [2]).

 Some reasons why we may want to grant it:

 First of all all patches have been approved in time and just lost the
 gate race.

 Rejecting it makes little sense really, as it has been commented on
by a
 good chunk of the core team, most of the invasive stuff (db
migrations
 for example) has already merged, and the few parts that may seem
 contentious have either been discussed and agreed upon [3], or can
 easily be addressed in subsequent bug fixes.

 It would be very beneficial to merge it so that we actually get real
 testing on the feature ASAP (scheduling features are not tested in
the
 gate so we need to rely on downstream/3rd party/user testing for
those).

 This statement bugs me. It seems kind of backwards to say we should
 merge a thing that we don't have a good upstream test plan on and put
it
 in a release so that the testing will happen only in the downstream
case.


 The objective reality is that many other things have not had upstream
 testing for a long time (anything that requires more than 1 compute
node
 in Nova for example, and any scheduling feature - as I mention clearly
 above), so not sure how that is backwards from any reasonable point.
 
 More critically with NUMA feature, AFAIK, there is no public cloud in
 existance which exposes NUMA to the guest. So unless someone is willing
 to pay for 100's of bare metal servers to run tempest on, I don't know
 of any infrastructure on which we can test NUMA today.
 
 Of course once we include NUMA features in Nova and release Nova, then
 the Rackspace and/or HP clouds will be in a position to start
considering
 how  when they might expose NUMA features for instances they host. So
by
 including it in Nova today, we would be helping move towards a future
 where we will be able to run tempest against NUMA features.
 
 Blocking NUMA from Nova for lack of automated testing will leave us
trapped
 in a chicken and egg scenario, potentially forever. That's not in
anyones
 best interests IMHO

The spec specifically calls out the scheduler piece being the part that
probably most needs to be tested, especially at large scales here. Those
pieces don't need Tempest to test them, they need more solid functional
tests around the scheduler under those circumstances.

There are interesting (and not all that difficult) ways to do this given
the resources we have, which don't seem to be being explored, which is
my concern.

I share your concern with this feature. I stated it on review
https://review.openstack.org/#/c/115007/ in PS 16. I think that we have
well known scheduling issues and these will be accentuated by a feature
like this. My feeling is that this feature and the PCI feature are both
going to be problematic under scale.

My reservations are when the feature is not enabled that a lot of
unnecessary data will be passed between hosts and the scheduler (this is
why we should have gone with the extensible resources (but that is opening
a can of worms)).

Having said that I think that Nova needs features like this. I am in favor
of moving ahead with this for a number of reasons:
1. The filter is not enabled by default
2. We can fix things moving forwards

So I am +1 on this. If we can document that it is experimental or use at
your own risk then I am +2. But I think that the fact that the admin needs
to configure the filter she/he knows it is at their own risk.

A luta continua



   -Sean

-- 
Sean Dague
https://urldefense.proofpoint.com/v1/url?u=http://dague.net/k=oIvRg1%2BdG
AgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%
0Am=Vr9ci4W1jJwlMVh7NJWsxGeY52I2AJ113JDTFO2CluA%3D%0As=45070dc04c1c3bb93
93b6273d23a8310ea404b716cf40c299b487e24ba5a8552

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

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


Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

2014-09-09 Thread Gary Kotton


On 9/8/14, 7:23 PM, Sylvain Bauza sba...@redhat.com wrote:


Le 08/09/2014 18:06, Steven Dake a écrit :
 On 09/05/2014 06:10 AM, Sylvain Bauza wrote:

 Le 05/09/2014 12:48, Sean Dague a écrit :
 On 09/05/2014 03:02 AM, Sylvain Bauza wrote:
 Le 05/09/2014 01:22, Michael Still a écrit :
 On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange
 berra...@redhat.com wrote:

 [Heavy snipping because of length]

 The radical (?) solution to the nova core team bottleneck is thus
to
 follow this lead and split the nova virt drivers out into separate
 projects and delegate their maintainence to new dedicated teams.

- Nova becomes the home for the public APIs, RPC system,
database
  persistent and the glue that ties all this together with the
  virt driver API.

- Each virt driver project gets its own core team and is
 responsible
  for dealing with review, merge  release of their codebase.
 I think this is the crux of the matter. We're not doing a great
 job of
 landing code at the moment, because we can't keep up with the review
 workload.

 So far we've had two proposals mooted:

- slots / runways, where we try to rate limit the number of
things
 we're trying to review at once to maintain focus
- splitting all the virt drivers out of the nova tree
 Ahem, IIRC, there is a third proposal for Kilo :
   - create subteam's half-cores responsible for reviewing patch's
 iterations and send to cores approvals requests once they consider
the
 patch enough stable for it.

 As I explained, it would allow to free up reviewing time for cores
 without loosing the control over what is being merged.
 I don't really understand how the half core idea works outside of a
 math
 equation, because the point is in core is to have trust over the
 judgement of your fellow core members so that they can land code when
 you aren't looking. I'm not sure how I manage to build up half trust
in
 someone any quicker.

 Well, this thread is becoming huge so that's becoming hard to follow
 all the discussion but I explained the idea elsewhere. Let me just
 provide it here too :
 The idea is *not* to land patches by the halfcores. Core team will
 still be fully responsible for approving patches. The main problem in
 Nova is that cores are spending lots of time because they review each
 iteration of a patch, and also have to look at if a patch is good or
 not.

 That's really time consuming, and for most of the time, quite
 frustrating as it requires to follow the patch's life, so there are
 high risks that your core attention is becoming distracted over the
 life of the patch.

 Here, the idea is to reduce dramatically this time by having teams
 dedicated to specific areas (as it's already done anyway for the
 various majority of reviewers) who could on their own take time for
 reviewing all the iterations. Of course, that doesn't mean cores
 would loose the possibility to specifically follow a patch and bypass
 the halfcores, that's just for helping them if they're overwhelmed.

 About the question of trusting cores or halfcores, I can just say
 that Nova team is anyway needing to grow up or divide it so the
 trusting delegation has to be real anyway.

 This whole process is IMHO very encouraging for newcomers because
 that creates dedicated teams that could help them to improve their
 changes, and not waiting 2 months for getting a -1 and a frank reply.


 Interesting idea, but having been core on Heat for ~2 years, it is
 critical to be involved in the review from the beginning of the patch
 set.  Typically you won't see core reviewer's participate in a review
 that is already being handled by two core reviewers.

 The reason it is important from the beginning of the change request is
 that the project core can store the iterations and purpose of the
 change in their heads.  Delegating all that up front work to a
 non-core just seems counter to the entire process of code reviews.
 Better would be reduce the # of reviews in the queue (what is proposed
 by this change) or trust new reviewers faster.  I'm not sure how you
 do that - but this second model is what your proposing.

 I think one thing that would be helpful is to point out somehow in the
 workflow that two core reviewers are involved in the review so core
 reviewers don't have to sift through 10 pages of reviews to find new
 work.


Now that the specs repo is in place and has been proved with Juno, most
of the design stage is approved before the implementation is going. If
the cores are getting more time because they wouldn't be focused on each
single patchset, they could really find some patches they would like to
look at, or they could just wait for the half-approvals from the
halfcores.

If a core thinks that a patch is enough tricky for looking at each
iteration, I don't see any bad things. At least, it's up to the core
reviewer to choose which patches he could look at, and he would be more
free than if the slots proposal would be there.

I'm a core from a 

Re: [openstack-dev] [nova][neutron][cinder] Averting the Nova crisis by splitting out virt drivers

2014-09-11 Thread Gary Kotton


On 9/11/14, 2:55 PM, Thierry Carrez thie...@openstack.org wrote:

Sean Dague wrote:
 [...]
 Why don't we start with let's clean up the virt interface and make it
 more sane, as I don't think there is any disagreement there. If it's
 going to take a cycle, it's going to take a cycle anyway (it will
 probably take 2 cycles, realistically, we always underestimate these
 things, remember when no-db-compute was going to be 1 cycle?). I don't
 see the need to actually decide here and now that the split is clearly
 at least 7 - 12 months away. A lot happens in the intervening time.

Yes, that sounds like the logical next step. We can't split drivers
without first doing that anyway. I still think people need smaller
areas of work, as Vish eloquently put it. I still hope that refactoring
our test architecture will let us reach the same level of quality with
only a fraction of the tests being run at the gate, which should address
most of the harm you see in adding additional repositories. But I agree
there is little point in discussing splitting virt drivers (or anything
else, really) until the internal interface below that potential split is
fully cleaned up and it becomes an option.

How about we start to try and patch gerrit to provide +2 permissions for
people
Who can be assigned Œdriver core¹ status. This is something that is
relevant to Nova and Neutron and I guess Cinder too.

Thanks
Gary


-- 
Thierry Carrez (ttx)

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


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


Re: [openstack-dev] [nova][neutron][cinder] Averting the Nova crisis by splitting out virt drivers

2014-09-11 Thread Gary Kotton


On 9/11/14, 4:30 PM, Sean Dague s...@dague.net wrote:

On 09/11/2014 09:09 AM, Gary Kotton wrote:
 
 
 On 9/11/14, 2:55 PM, Thierry Carrez thie...@openstack.org wrote:
 
 Sean Dague wrote:
 [...]
 Why don't we start with let's clean up the virt interface and make it
 more sane, as I don't think there is any disagreement there. If it's
 going to take a cycle, it's going to take a cycle anyway (it will
 probably take 2 cycles, realistically, we always underestimate these
 things, remember when no-db-compute was going to be 1 cycle?). I don't
 see the need to actually decide here and now that the split is clearly
 at least 7 - 12 months away. A lot happens in the intervening time.

 Yes, that sounds like the logical next step. We can't split drivers
 without first doing that anyway. I still think people need smaller
 areas of work, as Vish eloquently put it. I still hope that
refactoring
 our test architecture will let us reach the same level of quality with
 only a fraction of the tests being run at the gate, which should
address
 most of the harm you see in adding additional repositories. But I agree
 there is little point in discussing splitting virt drivers (or anything
 else, really) until the internal interface below that potential split
is
 fully cleaned up and it becomes an option.
 
 How about we start to try and patch gerrit to provide +2 permissions for
 people
 Who can be assigned Œdriver core¹ status. This is something that is
 relevant to Nova and Neutron and I guess Cinder too.

If you think that's the right solution, I'd say go and investigate it
with folks that understand enough gerrit internals to be able to figure
out how hard it would be. Start a conversation in #openstack-infra to
explore it.

My expectation is that there is more complexity there than you give it
credit for. That being said one of the biggest limitations we've had on
gerrit changes is we've effectively only got one community member, Kai,
who does any of that. If other people, or teams, were willing to dig in
and own things like this, that might be really helpful.

What about what Radoslav suggested? Having a background task running -
that can set a flag indicating that the code has been approved by the
driver ‘maintainers’. This can be something that driver CI should run -
that is, driver code can only be approved if it has X +1’s from the driver
maintainers and a +1 from the driver CI.



   -Sean

-- 
Sean Dague
https://urldefense.proofpoint.com/v1/url?u=http://dague.net/k=oIvRg1%2BdG
AgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%
0Am=krRe7RLL8WDd62ypHGZ6F1MqaSzJLkWn153Ch9UZktk%3D%0As=9b417c5fd29939b40
eee619ca9ed30be48192d939b824941d42d6e6ab36b1883

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

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


Re: [openstack-dev] [Openstack] [Devstack][VCenter][n-cpu]Error: Service n-cpu is not running

2014-09-15 Thread Gary Kotton
Hi,
I am not sure why your setup is not working. The Vmware configuration looks 
correct. Please note that the ML2 plugin is currently not supported when 
working with the Vmware driver. You should use traditional nova networking. 
Please note that there are plans in K to add this support.
Thanks
Gary

From: foss geek thefossg...@gmail.commailto:thefossg...@gmail.com
Date: Monday, September 15, 2014 at 2:44 PM
To: openst...@lists.openstack.orgmailto:openst...@lists.openstack.org 
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org, 
OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [Openstack] [Devstack][VCenter][n-cpu]Error: Service n-cpu is not 
running

Dear All,

I am using Devstack Icehouse stable version to integrate openstack with 
VCenter.  I am using CentOS 6.5 64 bit.

I am facing the below issue while running ./stack.  Any pointer/help would be 
greatly appreciated.

Here is related error log.


$./stack.sh

snip

2014-09-15 11:35:27.881 | + [[ -x /opt/stack/devstack/local.sh ]]
2014-09-15 11:35:27.898 | + service_check
2014-09-15 11:35:27.910 | + local service
2014-09-15 11:35:27.925 | + local failures
2014-09-15 11:35:27.936 | + SCREEN_NAME=stack
2014-09-15 11:35:27.953 | + SERVICE_DIR=/opt/stack/status
2014-09-15 11:35:27.964 | + [[ ! -d /opt/stack/status/stack ]]
2014-09-15 11:35:27.981 | ++ ls /opt/stack/status/stack/n-cpu.failure
2014-09-15 11:35:27.999 | + failures=/opt/stack/status/stack/n-cpu.failure
2014-09-15 11:35:28.006 | + for service in '$failures'
2014-09-15 11:35:28.023 | ++ basename /opt/stack/status/stack/n-cpu.failure
2014-09-15 11:35:28.034 | + service=n-cpu.failure
2014-09-15 11:35:28.051 | + service=n-cpu
2014-09-15 11:35:28.057 | + echo 'Error: Service n-cpu is not running'
2014-09-15 11:35:28.074 | Error: Service n-cpu is not running
2014-09-15 11:35:28.091 | + '[' -n /opt/stack/status/stack/n-cpu.failure ']'
2014-09-15 11:35:28.098 | + die 1164 'More details about the above errors can 
be found with screen, with ./rejoin-stack.sh'
2014-09-15 11:35:28.109 | + local exitcode=0
2014-09-15 11:35:28.126 | [Call Trace]
2014-09-15 11:35:28.139 | ./stack.sh:1313:service_check
2014-09-15 11:35:28.174 | /opt/stack/devstack/functions-common:1164:die
2014-09-15 11:35:28.184 | [ERROR] /opt/stack/devstack/functions-common:1164 
More details about the above errors can be found with screen, with 
./rejoin-stack.sh

snip


Here is n-cpu screen log:
==

$ cd /opt/stack/nova  /usr/bin/nova-compute --config-file /etc/nova/nova.conf 
 echo $! /opt/stack/status/stack/n-cpu.pid; fg || echo n-cpu failed to 
start | tee /opt/stack/status/stack/n-cpu.failure 2 eror
[1] 32476
cd /opt/stack/nova  /usr/bin/nova-compute --config-file /etc/nova/nova.conf
2014-09-15 08:00:50.685 DEBUG nova.servicegroup.api [-] ServiceGroup driver 
defined as an instance of db from (pid=32477) __new__ 
/opt/stack/nova/nova/servicegroup/api.py:65
2014-09-15 08:00:51.435 INFO nova.openstack.common.periodic_task [-] Skipping 
periodic task _periodic_update_dns because its interval is negative
2014-09-15 08:00:52.104 DEBUG stevedore.extension [-] found extension 
EntryPoint.parse('file = nova.image.download.file') from (pid=32477) 
_load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156
2014-09-15 08:00:52.178 DEBUG stevedore.extension [-] found extension 
EntryPoint.parse('file = nova.image.download.file') from (pid=32477) 
_load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156
2014-09-15 08:00:52.186 INFO nova.virt.driver [-] Loading compute driver 
'vmwareapi.VMwareVCDriver'
2014-09-15 08:01:21.188 DEBUG stevedore.extension [-] found extension 
EntryPoint.parse('file = nova.image.download.file') from (pid=32477) 
_load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156
2014-09-15 08:01:21.188 DEBUG stevedore.extension [-] found extension 
EntryPoint.parse('file = nova.image.download.file') from (pid=32477) 
_load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156
2014-09-15 08:01:21.825 DEBUG stevedore.extension [-] found extension 
EntryPoint.parse('file = nova.image.download.file') from (pid=32477) 
_load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156
2014-09-15 08:01:21.826 DEBUG stevedore.extension [-] found extension 
EntryPoint.parse('file = nova.image.download.file') from (pid=32477) 
_load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156
2014-09-15 08:01:26.208 INFO oslo.messaging._drivers.impl_rabbit [-] Connecting 
to AMQP server on 
10.10.2.2:5672https://urldefense.proofpoint.com/v1/url?u=http://10.10.2.2:5672k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=f90qkLxV3WQGxElluKkFrACcdYFJfquFb3%2FxNYy4f%2Bk%3D%0As=ab611045ee9d5deff98d0b3b844a9a83f09a91a3d71338cea87894ca1de47c2b
2014-09-15 08:01:26.235 INFO oslo.messaging._drivers.impl_rabbit [-] Connected 
to AMQP server on 

Re: [openstack-dev] [Nova] What's holding nova development back?

2014-09-16 Thread Gary Kotton


On 9/16/14, 11:12 AM, Daniel P. Berrange berra...@redhat.com wrote:

On Tue, Sep 16, 2014 at 07:30:26AM +1000, Michael Still wrote:
 On Tue, Sep 16, 2014 at 12:30 AM, Russell Bryant rbry...@redhat.com
wrote:
  On 09/15/2014 05:42 AM, Daniel P. Berrange wrote:
  On Sun, Sep 14, 2014 at 07:07:13AM +1000, Michael Still wrote:
  Just an observation from the last week or so...
 
  The biggest problem nova faces at the moment isn't code review
latency. Our
  biggest problem is failing to fix our bugs so that the gate is
reliable.
  The number of rechecks we've done in the last week to try and land
code is
  truly startling.
 
  I consider both problems to be pretty much equally as important. I
don't
  think solving review latency or test reliabilty in isolation is
enough to
  save Nova. We need to tackle both problems as a priority. I tried to
avoid
  getting into my concerns about testing in my mail on review team
bottlenecks
  since I think we should address the problems independantly / in
parallel.
 
  Agreed with this.  I don't think we can afford to ignore either one
of them.
 
 Yes, that was my point. I don't mind us debating how to rearrange
 hypervisor drivers. However, if we think that will solve all our
 problems we are confused.
 
 So, how do we get people to start taking bugs / gate failures more
 seriously?

I think we should have formal Bug squash wednesdays  (or pick another
day). By this I mean that the core reviewers will focus their attention
on just reviews that are related to bug fixing. They will also try to
work on bugs if they have time and encourage everyone else involved in
Nova todo the same. We'd have a team of people in the Nova IRC channel
to publicise  co-ordinate bug squashing, perhaps  with a list of top
20 bugs we want to attack this week. I wouldn't focus just on gate bugs
here since many a pretty darn hard  so would put off many people. Have
a mix of bugs of varying difficulties to point people to. Make this a
regular fortnightly or even weekly event which we publicise in advance
on mailing lists, etc.

I am in favor of that. This is similar to what I suggested in
http://lists.openstack.org/pipermail/openstack-dev/2014-September/045440.ht
ml

Thanks
Gary

Regards,
Daniel
-- 
|: 
https://urldefense.proofpoint.com/v1/url?u=http://berrange.com/k=oIvRg1%2
BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%
3D%0Am=%2BBB%2BI2z%2F47JBRJ4B1mOkFOq0SW%2F4bOrVdaRdWsCsYn0%3D%0As=23d33d
afdd513f39cce7f5f3ab73352c456981edc8f0aa6c4861d61f1ce0528c  -o-
https://urldefense.proofpoint.com/v1/url?u=http://www.flickr.com/photos/db
errange/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfD
tysg45MkPhCZFxPEq8%3D%0Am=%2BBB%2BI2z%2F47JBRJ4B1mOkFOq0SW%2F4bOrVdaRdWsC
sYn0%3D%0As=2d1a888a2988ac4dd3736b5e3cbd83af371bb5155b92ed769a7dd5516d7ed
a31 :|
|: 
https://urldefense.proofpoint.com/v1/url?u=http://libvirt.org/k=oIvRg1%2B
dGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3
D%0Am=%2BBB%2BI2z%2F47JBRJ4B1mOkFOq0SW%2F4bOrVdaRdWsCsYn0%3D%0As=c2a7391
a88982f704eb0c1d17acfcb531f6388d637bc72d0fa6dbd5f2ee5077e
-o- 
https://urldefense.proofpoint.com/v1/url?u=http://virt-manager.org/k=oIvR
g1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxP
Eq8%3D%0Am=%2BBB%2BI2z%2F47JBRJ4B1mOkFOq0SW%2F4bOrVdaRdWsCsYn0%3D%0As=8f
e922c5cb03f8a55c11b821bf9f4c011b6a3403db100266dba66e2e5f0c69ff :|
|: 
https://urldefense.proofpoint.com/v1/url?u=http://autobuild.org/k=oIvRg1%
2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8
%3D%0Am=%2BBB%2BI2z%2F47JBRJ4B1mOkFOq0SW%2F4bOrVdaRdWsCsYn0%3D%0As=3eb04
79ea977e54c5203c70c9a8043195c3addd86cb4f2d0aca9ee34deff3f9f   -o-

https://urldefense.proofpoint.com/v1/url?u=http://search.cpan.org/~danberr
/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45M
kPhCZFxPEq8%3D%0Am=%2BBB%2BI2z%2F47JBRJ4B1mOkFOq0SW%2F4bOrVdaRdWsCsYn0%3D
%0As=a13745c2c9636ce6c906c4467ba453cd8a2011fde467959cde586abc69cc0717 :|
|: 
https://urldefense.proofpoint.com/v1/url?u=http://entangle-photo.org/k=oI
vRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZF
xPEq8%3D%0Am=%2BBB%2BI2z%2F47JBRJ4B1mOkFOq0SW%2F4bOrVdaRdWsCsYn0%3D%0As=
53d5c4828d9a4c7529bb8bb589b686af7eb1026f0bb7355655b32b06350c85f2
-o-   
https://urldefense.proofpoint.com/v1/url?u=http://live.gnome.org/gtk-vnck
=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPh
CZFxPEq8%3D%0Am=%2BBB%2BI2z%2F47JBRJ4B1mOkFOq0SW%2F4bOrVdaRdWsCsYn0%3D%0A
s=427473a2fc971ad2586cfc228d80b49c48a730603946888ed33085a30da98985 :|

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


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


[openstack-dev] [nova][vmware] Juno update

2014-09-21 Thread Gary Kotton
Hi,

Below is a short update of the current status of the driver in Juno.

We managed to complete the following specs:

  *   Integration with oslo.vmware 
(https://github.com/openstack/nova-specs/blob/master/specs/juno/use-oslo-vmware.rst)
  *   Hot plug interface 
(https://github.com/openstack/nova-specs/blob/master/specs/juno/vmware-hot-plug.rst)
  *   Span refactor 
(https://github.com/openstack/nova-specs/blob/master/specs/juno/vmware-spawn-refactor.rst)

The following specs were implemented but did not manage to land:

  *   Ephemeral disk support 
(https://github.com/openstack/nova-specs/blob/master/specs/juno/vmware-ephemeral-disk-support.rst)
  *   Storage based policies 
(https://github.com/openstack/nova-specs/blob/master/specs/juno/vmware-spbm-support.rst)

The following specs were partially implemented - they need to be rebased after 
the spawn refactor:

  *   Spawning an OVA image 
(https://github.com/openstack/nova-specs/blob/master/specs/juno/vmware-driver-ova-support.rst)
  *   VSAN support 
(https://github.com/openstack/nova-specs/blob/master/specs/juno/vmware-vsan-support.rst)

In addition to this the ESX driver is no longer supported.

In addition to this we have a number of critical bugs that are in review:

  *   Update to latest oslo.vmware (https://review.openstack.org/#/c/121614/)
  *   VMware: Convert file_size to int 
(https://review.openstack.org/#/c/120309/)
  *   VMware: fix exception when multiple compute nodes are running 
(https://review.openstack.org/#/c/108225)
  *   VMware: fix regression for 'TaskInProgress' 
(https://review.openstack.org/#/c/121479/)
  *   VMware: prevent race condition with VNC port allocation 
(https://review.openstack.org/#/c/114548/)
  *   VMware: fix VM rescue problem with VNC console 
(https://review.openstack.org/#/c/113908/)
  *   VMware: support inventory folders 
(https://review.openstack.org/#/c/122017/)
  *   vc driver breaks instances.hypervisor_hostname value 
(https://review.openstack.org/#/c/99623/)

Hopefully we can get the above patches in (some may require a rebase ...)

Thanks
Gary



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


Re: [openstack-dev] [all] To slide or not to slide? OpenStack Bootstrapping Hour...

2014-09-23 Thread Gary Kotton
Hi,
I think that it was very informative and useful. I have forwarded it to a
number of new people starting to work on OpenStack and who were wondering
how to use mockŠ So two birds with one stone.
Thanks!
Gary

On 9/22/14, 7:27 PM, Jay Pipes jaypi...@gmail.com wrote:

Hi all,

OK, so we had our inaugural OpenStack Bootstrapping Hour last Friday.
Thanks to Sean and Dan for putting up with my rambling about unittest
and mock stuff. And thanks to one of my pugs, Winnie, for, according to
Shrews, looking like she was drunk. :)

One thing we're doing today is a bit of a post-mortem around what worked
and what didn't.

For this first OBH session, I put together some slides [1] that were
referenced during the hangout session. I'm wondering what folks who
watched the video [2] thought about using the slides.

Were the slides useful compared to just providing links to code on the
etherpad [3]?

Were the slides a hindrance to the flow of the OBH session?

Would a production of slides be better to do *after* an OBH session,
instead of before?

Very much interested in hearing answers/opinions about the above
questions. We're keen to provide the best experience possible, and are
open to any ideas.

Best,
-jay

[1] 
https://urldefense.proofpoint.com/v1/url?u=http://bit.ly/obh-mock-best-pra
cticesk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDty
sg45MkPhCZFxPEq8%3D%0Am=mRBZtkhZN%2FYXcozwcqLrrfLMrE2ItK9T2%2FjmB72dQiY%3
D%0As=9001183cba07f4c3dfeaba68c6f48b006fcf8974432f53b94a6ee424511a65c5
[2] 
https://urldefense.proofpoint.com/v1/url?u=http://youtu.be/jCWtLoSEfmwk=o
IvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZ
FxPEq8%3D%0Am=mRBZtkhZN%2FYXcozwcqLrrfLMrE2ItK9T2%2FjmB72dQiY%3D%0As=843
cf6d8b5dd4f38e3c9b452744928093eafe10ccd6b0dca7419915484229bd2
[3] https://etherpad.openstack.org/p/obh-mock-best-practices

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


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


[openstack-dev] [Gating-Failures] Docs creation is failing

2013-12-10 Thread Gary Kotton
Hi,
An example for this is: 
http://logs.openstack.org/94/59994/10/check/gate-nova-docs/b0f3910/console.html
Any ideas?
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Gating-Failures] Docs creation is failing

2013-12-10 Thread Gary Kotton
Hi,
Saw that this was dealt with in most projects. I have posted the Nova review - 
https://review.openstack.org/61329
Thanks
Gary

From: Administrator gkot...@vmware.commailto:gkot...@vmware.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, December 11, 2013 9:22 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Gating-Failures] Docs creation is failing

Hi,
An example for this is: 
http://logs.openstack.org/94/59994/10/check/gate-nova-docs/b0f3910/console.htmlhttps://urldefense.proofpoint.com/v1/url?u=http://logs.openstack.org/94/59994/10/check/gate-nova-docs/b0f3910/console.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=279ITFH7scJScdwu5PYhpOh05S8WGtu2ANCbSE%2B6gog%3D%0As=ce4126c75df32882d012754658680a6565084e9118666b66b69539b4cd158195
Any ideas?
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova]

2013-12-10 Thread Gary Kotton


On 12/11/13 12:43 AM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote:



On Tuesday, December 10, 2013 4:17:45 PM, Maithem Munshed 71510 wrote:
 Hello,

 I was wondering, what is the reason behind having nova audit resources
 as opposed to using usage stats directly from what is reported by the
 compute driver. The available resources reported from the audit can be
 incorrect in some cases. Also, in many cases the reported usage stats
 from the driver are correct, so auditing periodically while having the
 usage stats from the driver is inefficient. One of the which result in
 an incorrect audit is: existing VMs on a hypervisor that are created
 prior to deploying nova. As a result, the scheduler will see more
 available resources than what actually is available. I am aware that
 Nova shouldn¹t be managing VMs that it hasn¹t created, but the
 reported available resources should be as accurate as possible.

 I have proposed the following blueprint to provide the option of using
 usage stats directly from the driver :

 
https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.n
et/nova/%2Bspec/use-driver-usage-statsk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0
Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=x02rSPjpn8NY7Hm
djKaREzjyWdCIsrjbjolGum3k878%3D%0As=c7dfed6064da0be905447da3533cf6b6d2fa
7eefb2364fad1df4d484e39a9914

 I would like to know what your thoughts are and would appreciate
feedback.

 Regards,

 Maithem



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi
-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar
=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=x02rSPjpn8NY7HmdjK
aREzjyWdCIsrjbjolGum3k878%3D%0As=d8f5240e69583b063b2435d4e62244f1df9acaa
268d332922afba4d35a0add57

One (big) problem is the virt drivers don't follow a standard format
for the usage diagnostics, which has been discussed before in the
mailing list [1].

There is a nova blueprint [2] for standard auditing formats like in
ceilometer which might be related to what you're looking for.

This is one of the issue that we spoke about at the summit. At the moment
the virt drivers return their usage statistics (not VM diagnostics). The
resource tracker just ignores this, well actually it has a LOG debug for
the results 
(https://github.com/openstack/nova/blob/master/nova/compute/resource_tracke
r.py#L401), and proceed to calculate the available resources on the
compute node.

The conclusion from that session was that we should add in a configuration
variable (to ensure backward compatibility) which will enable the resource
tracker to make use of the girt driver statistics instead of recalculating
them 
(https://github.com/openstack/nova/blob/master/nova/compute/resource_tracke
r.py#L291)

Thanks
Gary


[1] 
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/pipe
rmail/openstack-dev/2013-October/016385.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D
%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=x02rSPjpn8N
Y7HmdjKaREzjyWdCIsrjbjolGum3k878%3D%0As=df8314a31fb99b591d081b1888f38e2be
9e19f289afaaa7224844a964d4b1680
[2] 
https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.ne
t/nova/%2Bspec/support-standard-audit-formatsk=oIvRg1%2BdGAgOoM1BIlLLqw%3
D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=x02rSPjpn8
NY7HmdjKaREzjyWdCIsrjbjolGum3k878%3D%0As=f8f7b3aebf0e3226926146aed4b6caf4
d380d410f35fb7ee974655ad6190fa71

--

Thanks,

Matt Riedemann


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e
H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=x02rSPjpn8NY7HmdjKaRE
zjyWdCIsrjbjolGum3k878%3D%0As=d8f5240e69583b063b2435d4e62244f1df9acaa268d
332922afba4d35a0add57


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


[openstack-dev] [nova] VM diagnostics - V3 proposal

2013-12-16 Thread Gary Kotton
Hi,
At the moment the administrator is able to retrieve diagnostics for a running 
VM. Currently the implementation is very loosely defined, that is, each driver 
returns whatever they have to return. This is problematic in a number of 
respects:

 1.  The tempest tests were written specifically for one driver and break with 
all other drivers (the test was removed to prevent this – bug 1240043)
 2.  An admin is unable to write tools that may work with a hybrid cloud
 3.  Adding support for get_diagnostics for drivers that do not support is 
painful

I'd like to propose the following for the V3 API (we will not touch V2 in case 
operators have applications that are written against this – this may be the 
case for libvirt or xen. The VMware API support was added in I1):

 1.  We formalize the data that is returned by the API [1]
 2.  We enable the driver to add extra information that will assist the 
administrators in troubleshooting problems for VM's

I have proposed a BP for this - 
https://blueprints.launchpad.net/nova/+spec/diagnostics-namespace (I'd like to 
change the name to v3-api-diagnostics – which is more apt)

And as Nelson Mandel would have said: “It always seems impossible until it's 
done.”

Moving forwards we decide to provide administrator the option of using the for 
V2 (it may be very helpful with debugging issues). But that is another 
discussion.

Thanks
Gary

[1] https://etherpad.openstack.org/p/vm-diagnostics
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] VM diagnostics - V3 proposal

2013-12-16 Thread Gary Kotton


On 12/16/13 5:25 PM, Daniel P. Berrange berra...@redhat.com wrote:

On Mon, Dec 16, 2013 at 06:58:24AM -0800, Gary Kotton wrote:
 Hi,
 At the moment the administrator is able to retrieve diagnostics for a
running VM. Currently the implementation is very loosely defined, that
is, each driver returns whatever they have to return. This is
problematic in a number of respects:
 
  1.  The tempest tests were written specifically for one driver and
break with all other drivers (the test was removed to prevent this ­ bug
1240043)
  2.  An admin is unable to write tools that may work with a hybrid cloud
  3.  Adding support for get_diagnostics for drivers that do not support
is painful

Technically 3 is currently easy, since currently you don't need to care
about what the other drivers have done - you can return any old info
for your new driver's get_diagnostics API impl ;-)

To be honest it was not easy at all.


Seriously though, I agree the current API is a big trainwreck.

 I'd like to propose the following for the V3 API (we will not touch V2
 in case operators have applications that are written against this ­ this
 may be the case for libvirt or xen. The VMware API support was added
 in I1):
 
  1.  We formalize the data that is returned by the API [1]

Before we debate what standard data should be returned we need
detail of exactly what info the current 3 virt drivers return.
IMHO it would be better if we did this all in the existing wiki
page associated with the blueprint, rather than etherpad, so it
serves as a permanent historical record for the blueprint design.

I will add this to the wiki. Not sure what this will achieve - other than
the fact that it will crystalize the fact that we need to have common data
returned.


While we're doing this I think we should also consider whether
the 'get_diagnostics' API is fit for purpose more generally.
eg currently it is restricted to administrators. Some, if
not all, of the data libvirt returns is relevant to the owner
of the VM but they can not get at it.

This is configurable. The default is for an admin user. This is in the
policy.json file - 
https://github.com/openstack/nova/blob/master/etc/nova/policy.json#L202


For a cloud administrator it might be argued that the current
API is too inefficient to be useful in many troubleshooting
scenarios since it requires you to invoke it once per instance
if you're collecting info on a set of guests, eg all VMs on
one host. It could be that cloud admins would be better
served by an API which returned info for all VMs ona host
at once, if they're monitoring say, I/O stats across VM
disks to identify one that is causing I/O trouble ? IOW, I
think we could do with better identifying the usage scenarios
for this API if we're to improve its design / impl.

Host diagnostics would be a nice feature to have. I do not think that it
is part of the scope of what we want to achieve here but I will certainly
be happy to work on this afterwards.



  2.  We enable the driver to add extra information that will assist the
administrators in troubleshooting problems for VM's
 
 I have proposed a BP for this -
https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.n
et/nova/%2Bspec/diagnostics-namespacek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A
r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=xY7Bdz7UGQQFxbe2
g6zVO%2FBUpkZfN%2BImM564xugLjsk%3D%0As=9d0ecd519b919b6c87bbdd2e1e1bf9a51
6f469143d15797d272cfd8c7e2d0686 (I'd like to change the name to
v3-api-diagnostics ­ which is more apt)

The bp rename would be a good idea.

 [1] 
https://urldefense.proofpoint.com/v1/url?u=https://etherpad.openstack.org
/p/vm-diagnosticsk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6h
goMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=xY7Bdz7UGQQFxbe2g6zVO%2FBUpkZfN%2BIm
M564xugLjsk%3D%0As=d1386b91ca07f5504844e7f4312dc5b53b709660fe71ca96c76c3
8d447bec2e5

Regards,
Daniel
-- 
|: 
https://urldefense.proofpoint.com/v1/url?u=http://berrange.com/k=oIvRg1%2
BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%
3D%0Am=xY7Bdz7UGQQFxbe2g6zVO%2FBUpkZfN%2BImM564xugLjsk%3D%0As=c421c25857
f1ca0294b5cc318e87a758a2b49ecc35b3ca9f75b57be574ce0299  -o-
https://urldefense.proofpoint.com/v1/url?u=http://www.flickr.com/photos/db
errange/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfD
tysg45MkPhCZFxPEq8%3D%0Am=xY7Bdz7UGQQFxbe2g6zVO%2FBUpkZfN%2BImM564xugLjsk
%3D%0As=281520d30342d840da18dac821fdc235faf903c0bb7e8fcb51620217bf7b236a
:|
|: 
https://urldefense.proofpoint.com/v1/url?u=http://libvirt.org/k=oIvRg1%2B
dGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3
D%0Am=xY7Bdz7UGQQFxbe2g6zVO%2FBUpkZfN%2BImM564xugLjsk%3D%0As=9424295e978
7fe72415305745f36556f0b8167ba0da8ac9632a4f8a183a926aa  -o-
 
https://urldefense.proofpoint.com/v1/url?u=http://virt-manager.org/k=oIvR
g1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxP
Eq8%3D%0Am=xY7Bdz7UGQQFxbe2g6zVO%2FBUpkZfN

Re: [openstack-dev] [nova] VM diagnostics - V3 proposal

2013-12-17 Thread Gary Kotton
Hi,
Following the discussion yesterday I have updated the wiki - please see
https://wiki.openstack.org/wiki/Nova_VM_Diagnostics. The proposal is
backwards compatible and will hopefully provide us with the tools to be
able to troubleshoot VM issues.
Thanks
Gary

On 12/16/13 5:50 PM, Daniel P. Berrange berra...@redhat.com wrote:

On Mon, Dec 16, 2013 at 03:37:39PM +, John Garbutt wrote:
 On 16 December 2013 15:25, Daniel P. Berrange berra...@redhat.com
wrote:
  On Mon, Dec 16, 2013 at 06:58:24AM -0800, Gary Kotton wrote:
  I'd like to propose the following for the V3 API (we will not touch
V2
  in case operators have applications that are written against this ­
this
  may be the case for libvirt or xen. The VMware API support was added
  in I1):
 
   1.  We formalize the data that is returned by the API [1]
 
  Before we debate what standard data should be returned we need
  detail of exactly what info the current 3 virt drivers return.
  IMHO it would be better if we did this all in the existing wiki
  page associated with the blueprint, rather than etherpad, so it
  serves as a permanent historical record for the blueprint design.
 
 +1
 
  While we're doing this I think we should also consider whether
  the 'get_diagnostics' API is fit for purpose more generally.
  eg currently it is restricted to administrators. Some, if
  not all, of the data libvirt returns is relevant to the owner
  of the VM but they can not get at it.
 
 Ceilometer covers that ground, we should ask them about this API.

If we consider what is potentially in scope for ceilometer and
subtract that from what the libvirt get_diagnostics impl currently
returns, you pretty much end up with the empty set. This might cause
us to question if 'get_diagnostics' should exist at all from the
POV of the libvirt driver's impl. Perhaps vmware/xen return data
that is out of scope for ceilometer ?

  For a cloud administrator it might be argued that the current
  API is too inefficient to be useful in many troubleshooting
  scenarios since it requires you to invoke it once per instance
  if you're collecting info on a set of guests, eg all VMs on
  one host. It could be that cloud admins would be better
  served by an API which returned info for all VMs ona host
  at once, if they're monitoring say, I/O stats across VM
  disks to identify one that is causing I/O trouble ? IOW, I
  think we could do with better identifying the usage scenarios
  for this API if we're to improve its design / impl.
 
 I like the API that helps you dig into info for a specific host that
 other system highlight as problematic.
 You can do things that could be expensive to compute, but useful for
 troubleshooting.

If things get expensive to compute, then it may well be preferrable to
have separate APIs for distinct pieces of interesting diagnostic
data. eg If they only care about one particular thing, they don't want
to trigger expensive computations of things they don't care about seeing.

Regards,
Daniel
-- 
|: 
https://urldefense.proofpoint.com/v1/url?u=http://berrange.com/k=oIvRg1%2
BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%
3D%0Am=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0As=dd903dfca0
b7b3ace5c560509caf1164f8f3f4dda62174e6374b07a85724183c  -o-
https://urldefense.proofpoint.com/v1/url?u=http://www.flickr.com/photos/db
errange/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfD
tysg45MkPhCZFxPEq8%3D%0Am=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8
%3D%0As=3d3587124076d99d0ad02847a95a69c541cfe296f650027c99cf098aad764ab9
:|
|: 
https://urldefense.proofpoint.com/v1/url?u=http://libvirt.org/k=oIvRg1%2B
dGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3
D%0Am=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0As=60b14571198
ff9afdeb5949597de9596b75ab79abca0496a96703e15aa10  -o-
 
https://urldefense.proofpoint.com/v1/url?u=http://virt-manager.org/k=oIvR
g1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxP
Eq8%3D%0Am=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0As=a6f1f8
5bb37036e37ed7e7dba4d88c00a289cfb0e42740528d5c7ca1bd690620 :|
|: 
https://urldefense.proofpoint.com/v1/url?u=http://autobuild.org/k=oIvRg1%
2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8
%3D%0Am=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0As=ee08dd8de
4174a142a6d8c5aa18ede84b47ec0db358b96c3b729232e004641e1   -o-
https://urldefense.proofpoint.com/v1/url?u=http://search.cpan.org/~danberr
/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45M
kPhCZFxPEq8%3D%0Am=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0A
s=313fd521d220dc3b7cbba305533de490bf614449d0489e705e15f2536657c222 :|
|: 
https://urldefense.proofpoint.com/v1/url?u=http://entangle-photo.org/k=oI
vRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZF
xPEq8%3D%0Am=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0As=da78

Re: [openstack-dev] [nova][vmware]VMware VCenter Driver

2013-12-18 Thread Gary Kotton
Hi,
Currently there are 2 VMware drivers:

 *   VMwareVCDriver – this lets nova compute communicate with a vCenter server 
(which manages the ESX hosts)
 *   VMwareESXDriver – this lets nova compute manage the ESX host

Thanks
Gary

From: Ray Sun xiaoq...@gmail.commailto:xiaoq...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, December 18, 2013 8:29 AM
To: OpenStack Dev 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova][vmware]VMware VCenter Driver

Sorry, I forget to modify the subject.

Best Regards
-- Ray


On Wed, Dec 18, 2013 at 2:21 PM, Ray Sun 
xiaoq...@gmail.commailto:xiaoq...@gmail.com wrote:
Hi Stackers,
I just looked into the VMware Vcenter Driver, seems it manages a vcenter 
cluster as a single compute node, even it contains more than 1 physical 
servers. It's not very connivence to know what's the real resource I had in my 
cluster.

Is there any reason why we don't identify every ESXI host in OpenStack?

Thanks.

Best Regards
-- Ray

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


Re: [openstack-dev] Subject: [nova][vmware] VMwareAPI sub-team status 2013-12-08

2013-12-18 Thread Gary Kotton
Would it be possible that an additional core please take a look at 
https://review.openstack.org/#/c/51793/?
Thanks
Gary

From: Shawn Hartsock harts...@acm.orgmailto:harts...@acm.org
Date: Wednesday, December 18, 2013 6:32 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Subject: [openstack-dev][nova][vmware] VMwareAPI sub-team status 
2013-12-08


Greetings Stackers!

BTW: Reviews by fitness at the end.

It's Wednesday so it's time for me to cheer-lead for our VMwareAPI subteam. Go 
team! Our normal Wednesday meetings fall on December 25th and January 1st 
coming up so, no meetings until January 8th. If there's a really strong 
objection to that we can organize an impromptu meeting.

Here's the community priorities so far for IceHouse.

== Blueprint priorities ==

Icehouse-2

Nova

*. 
https://blueprints.launchpad.net/nova/+spec/vmware-image-cache-managementhttps://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.net/nova/%2Bspec/vmware-image-cache-managementk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=2Z6cPGiN95TzM3Icsm04rGTUvZ6LPXzCtZtlTdFDx6I%3D%0As=05e3a71c9662717a7129b4204627534366b5e678917b03140fca2d97cd23eb1c

*. 
https://blueprints.launchpad.net/nova/+spec/vmware-vsan-supporthttps://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.net/nova/%2Bspec/vmware-vsan-supportk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=2Z6cPGiN95TzM3Icsm04rGTUvZ6LPXzCtZtlTdFDx6I%3D%0As=5c9402d30409e65473e93ffd49383af99262d2aa5ad5e837f91337e10a59ea91

*. 
https://blueprints.launchpad.net/nova/+spec/autowsdl-repairhttps://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.net/nova/%2Bspec/autowsdl-repairk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=2Z6cPGiN95TzM3Icsm04rGTUvZ6LPXzCtZtlTdFDx6I%3D%0As=9cc20651933d6dfc738d744740219bdc50ca8ee9dace8d4498feb724c5f88e49

Glance

*. 
https://blueprints.launchpad.net/glance/+spec/vmware-datastore-storage-backendhttps://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.net/glance/%2Bspec/vmware-datastore-storage-backendk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=2Z6cPGiN95TzM3Icsm04rGTUvZ6LPXzCtZtlTdFDx6I%3D%0As=ff7848ba793a0f31e1e106615da1c1d3750057b69c23f416fabf3ff20bd6cf49

Icehouse-3

*. 
https://blueprints.launchpad.net/nova/+spec/config-validation-scripthttps://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.net/nova/%2Bspec/config-validation-scriptk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=2Z6cPGiN95TzM3Icsm04rGTUvZ6LPXzCtZtlTdFDx6I%3D%0As=8e1631833966591b6ba5f0e698961d4b6431542d51a1962ed9572226e622727b


== Bugs by priority: ==

The priority here is an aggregate, Nova Priority / VMware Driver priority where 
the priorities are determined independently.


* High/Critical, needs review : 'vmware driver does not work with more than one 
datacenter in vC'

https://review.openstack.org/62587https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/62587k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=2Z6cPGiN95TzM3Icsm04rGTUvZ6LPXzCtZtlTdFDx6I%3D%0As=df81237939ed49c909bff4e0d98cda67b6cfe143446077aec98dbf902f77c48c

* High/High, needs one more +2/approval : 'VMware: NotAuthenticated occurred in 
the call to RetrievePropertiesEx'

https://review.openstack.org/61555https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/61555k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=2Z6cPGiN95TzM3Icsm04rGTUvZ6LPXzCtZtlTdFDx6I%3D%0As=28bf16f26dc907fc6d9334ea3046d1d7f911570dc8f79071f2c0b0084e1566a6

* High/High, needs review : 'VMware: spawning large amounts of VMs concurrently 
sometimes causes VMDK lock error'

https://review.openstack.org/58598https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/58598k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=2Z6cPGiN95TzM3Icsm04rGTUvZ6LPXzCtZtlTdFDx6I%3D%0As=4d25b665c267fcb3a86febb2f1462032dcb6cc71b24bb29e177b7f84957754d5

* High/High, needs review : 'VMWare: AssertionError: Trying to re-send() an 
already-triggered event.'

https://review.openstack.org/54808https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/54808k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=2Z6cPGiN95TzM3Icsm04rGTUvZ6LPXzCtZtlTdFDx6I%3D%0As=fa306c2d6b74a360e765c33f6742ff8447e8e4a66e6d9b9b5367759c8620e448

* High/High, needs review : 'VMware: timeouts due to nova-compute stuck at 100% 
when using deploying 100 VMs'


Re: [openstack-dev] [nova] VM diagnostics - V3 proposal

2013-12-19 Thread Gary Kotton


On 12/19/13 5:50 PM, Daniel P. Berrange berra...@redhat.com wrote:

On Tue, Dec 17, 2013 at 04:28:30AM -0800, Gary Kotton wrote:
 Hi,
 Following the discussion yesterday I have updated the wiki - please see
 
https://urldefense.proofpoint.com/v1/url?u=https://wiki.openstack.org/wik
i/Nova_VM_Diagnosticsk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZ
yF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDE
tRLmlzFb5ORuM%3D%0As=d13969885872ea187937a89d12aab9b36b51452ba47e35c7e41
692335967b9f7. The proposal is
 backwards compatible and will hopefully provide us with the tools to be
 able to troubleshoot VM issues.

Some comments

 If the driver is unable to return the value or does not have
  access to it at the moment then it should return 'n/a'.

I think it is better if the driver just omitted any key that
it doesn't support altogether. That avoids clients / users
having to do magic string comparisons to identify omitted
data.

I am fine with this. If the data is marked optional then whoever is
parsing the data should check to see if the field exists prior.


 An ID for the diagnostics version. The structure defined below
  is version 1 (Integer)

What are the proposed semantics for version numbers. Do they incremented
on any change, or only on backwards incompatible changes ?

The purpose of this was to be backward compatible. But I guess that if we
go with the optional approach then this is redundant.


 The amount of time in seconds that the VM has been running (Integer)

I'd suggest nano-seconds here. I've been burnt too many times in the
past providing APIs where we rounded data to a coarse unit like seconds.

Sure, sounds reasonable.


Let client programs convert from nanoseconds to seconds if they wish
to display it in that way, but keep the API with the full precision.

  The version of the raw data

I guess that this is redundant too.


Same question as previously.



The allowed keys in network/disk/memory details seem to be
unduly limited. Just having a boolean activity for disk
or NICs seems almost entirely useless. eg the VM might have
sent 1 byte when it first booted and nothing more for the
next 10 days, and an admin can't see this.

I'd suggest we should follow the much expanded set of possible
stats shown by the libvirt driver. These are pretty common
things to show for disk/nic activity and a driver wouldn't have
to support all of them if it doesn't have that info.

Ok. I was just trying to provide an indicator for the admin to dive into
the raw data. But I am fine with this.


It would be nice to have CPU stats available too.

At the moment libvirt only return the cpu0_time. Can you please let me
know what other stats you would like here?

 


 
https://urldefense.proofpoint.com/v1/url?u=http://berrange.com/k=oIvRg1
%2
 
BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq
8%
 
3D%0Am=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0As=dd903dfc
a0
 b7b3ace5c560509caf1164f8f3f4dda62174e6374b07a85724183c  -o-
 
https://urldefense.proofpoint.com/v1/url?u=http://www.flickr.com/photos/
db
 
errange/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2B
fD
 
tysg45MkPhCZFxPEq8%3D%0Am=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivT
K8
 
%3D%0As=3d3587124076d99d0ad02847a95a69c541cfe296f650027c99cf098aad764ab
9

BTW if you would be nice if you can get your email program not to
mangle URLs in mails you're replying to. In this case it was just
links in a signature so didn't matter, but in other messages it is
mangled stuff in the body of the message :-( It makes it painful
to read the context.

Regards,
Daniel
-- 
|: 
https://urldefense.proofpoint.com/v1/url?u=http://berrange.com/k=oIvRg1%2
BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%
3D%0Am=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDEtRLmlzFb5ORuM%3D%0As=3b9f7af3a2bc
4ffaf73f6cff69fd1e88b2af95ced9b60945bc1e2f97ebaf7da4  -o-
https://urldefense.proofpoint.com/v1/url?u=http://www.flickr.com/photos/db
errange/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfD
tysg45MkPhCZFxPEq8%3D%0Am=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDEtRLmlzFb5ORuM%3
D%0As=3fa5cf45352c4dcbedf56f5ba059edf46fec10637a329c808cdfca2f66d3a4ce :|
|: 
https://urldefense.proofpoint.com/v1/url?u=http://libvirt.org/k=oIvRg1%2B
dGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3
D%0Am=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDEtRLmlzFb5ORuM%3D%0As=4bf16f2a8e571
3d2fb13f8dcb0ab13e78a5ec376b215f6c07476f4a75c1b829f  -o-
   
https://urldefense.proofpoint.com/v1/url?u=http://virt-manager.org/k=oIvR
g1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxP
Eq8%3D%0Am=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDEtRLmlzFb5ORuM%3D%0As=1d14716b
524d2c056cb5b26f32b13df0a602ca98fb80380d7e1964491f43b44f :|
|: 
https://urldefense.proofpoint.com/v1/url?u=http://autobuild.org/k=oIvRg1%
2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8
%3D%0Am=vzUZT3t

Re: [openstack-dev] [nova] VM diagnostics - V3 proposal

2013-12-19 Thread Gary Kotton


On 12/19/13 6:07 PM, Daniel P. Berrange berra...@redhat.com wrote:

On Thu, Dec 19, 2013 at 08:02:16AM -0800, Gary Kotton wrote:
 
 
 On 12/19/13 5:50 PM, Daniel P. Berrange berra...@redhat.com wrote:
 
 On Tue, Dec 17, 2013 at 04:28:30AM -0800, Gary Kotton wrote:
  Hi,
  Following the discussion yesterday I have updated the wiki - please
see
  
 
https://urldefense.proofpoint.com/v1/url?u=https://wiki.openstack.org/w
ik
 
i/Nova_VM_Diagnosticsk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8N
PZ
 
yF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=vzUZT3t%2BPvKlvBTFueAjUjo8YUZv
DE
 
tRLmlzFb5ORuM%3D%0As=d13969885872ea187937a89d12aab9b36b51452ba47e35c7e
41
 692335967b9f7. The proposal is
  backwards compatible and will hopefully provide us with the tools to
be
  able to troubleshoot VM issues.
 
 Some comments
 
  If the driver is unable to return the value or does not have
   access to it at the moment then it should return 'n/a'.
 
 I think it is better if the driver just omitted any key that
 it doesn't support altogether. That avoids clients / users
 having to do magic string comparisons to identify omitted
 data.
 
 I am fine with this. If the data is marked optional then whoever is
 parsing the data should check to see if the field exists prior.
 
 
  An ID for the diagnostics version. The structure defined below
   is version 1 (Integer)
 
 What are the proposed semantics for version numbers. Do they
incremented
 on any change, or only on backwards incompatible changes ?
 
 The purpose of this was to be backward compatible. But I guess that if
we
 go with the optional approach then this is redundant.
 
 
  The amount of time in seconds that the VM has been running (Integer)
 
 I'd suggest nano-seconds here. I've been burnt too many times in the
 past providing APIs where we rounded data to a coarse unit like
seconds.
 
 Sure, sounds reasonable.

Oh hang on, when you say 'amount of time in seconds the VM has been
running'
you're meaning wall-clock time since boot.  Seconds is fine for wall clock
time actually.


I was getting mixed up with CPU utilization time, since libvirt doesn't
actually provide any way to get uptime.


 Let client programs convert from nanoseconds to seconds if they wish
 to display it in that way, but keep the API with the full precision.
 
   The version of the raw data
 
 I guess that this is redundant too.
 
 
 Same question as previously.
 
 
 
 The allowed keys in network/disk/memory details seem to be
 unduly limited. Just having a boolean activity for disk
 or NICs seems almost entirely useless. eg the VM might have
 sent 1 byte when it first booted and nothing more for the
 next 10 days, and an admin can't see this.
 
 I'd suggest we should follow the much expanded set of possible
 stats shown by the libvirt driver. These are pretty common
 things to show for disk/nic activity and a driver wouldn't have
 to support all of them if it doesn't have that info.
 
 Ok. I was just trying to provide an indicator for the admin to dive into
 the raw data. But I am fine with this.
 
 
 It would be nice to have CPU stats available too.
 
 At the moment libvirt only return the cpu0_time. Can you please let me
 know what other stats you would like here?

Since we have numCpus, I'd suggest we allow for a list of cpus in the
same way we do for disk/nics and returning the execution time split
out for each vCPU.  We could still have a merged execution time too
since I can imagine some hypervisors won't be able to provide the
split out per-vcpu time.

Good call. I'll add this!


Daniel
-- 
|: 
https://urldefense.proofpoint.com/v1/url?u=http://berrange.com/k=oIvRg1%2
BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%
3D%0Am=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D%0As=43e28d32e5a671
8ba104d118a69e659866e10cb5981b43bd8c89ac09d96bc6de  -o-
https://urldefense.proofpoint.com/v1/url?u=http://www.flickr.com/photos/db
errange/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfD
tysg45MkPhCZFxPEq8%3D%0Am=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D%
0As=69b56c12bb439e62c6aa90ec908016b701d268210a464d9d1f43f8c070e6e1db :|
|: 
https://urldefense.proofpoint.com/v1/url?u=http://libvirt.org/k=oIvRg1%2B
dGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3
D%0Am=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D%0As=d4d36b4c778f308
9290ed06239bad90dbe8b52370f9c6c24b60a935510fb74d7  -o-
 
https://urldefense.proofpoint.com/v1/url?u=http://virt-manager.org/k=oIvR
g1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxP
Eq8%3D%0Am=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D%0As=edb1182136
b3c880b14557de1856e0fbb4a950fceb89b39bb0cef7df081fa10c :|
|: 
https://urldefense.proofpoint.com/v1/url?u=http://autobuild.org/k=oIvRg1%
2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8
%3D%0Am=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D%0As=42e39e02e8829
734ca2e30d74e10da2b0b3467c1cf019dc51c2edf1886f1

[openstack-dev] [nova] HyperV-CI

2013-12-23 Thread Gary Kotton
Hi,
There seems to be an issue with the hyper CI. Please see - 
https://review.openstack.org/#/c/52687/. This code does is not related to the 
HyperV driver.
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] VM diagnostics - V3 proposal

2013-12-29 Thread Gary Kotton
Hi,
Following all of the discussion I have done the following:
1. Update the wiki with all of the details -
https://wiki.openstack.org/wiki/Nova_VM_Diagnostics
2. Renamed the BP. It is now called v3-diagnostics
https://blueprints.launchpad.net/openstack/?searchtext=v3-diagnostics
3. Posted a patch with libvirt support -
https://review.openstack.org/#/c/61753/
The other drivers that support diagnostics will be updated in the coming
days.
I am not sure how tempest behaves with the V3 client but I am in the
process of looking into that so that we can leverage this API with
tempest. Do we also want the same support in V2? I think that it could be
very helpful with the spurious test failures that we have.
Thanks and a happy new year to all
Gary


On 12/19/13 6:21 PM, Vladik Romanovsky vladik.romanov...@enovance.com
wrote:

Ah, I think I've responded too fast, sorry.

meter-list provides a list of various measurements that are being done
per resource.
sample-list provides a list of samples per every meter: ceilometer
sample-list --meter cpu_util -q resource_id=vm_uuid
These samples can be aggregated over a period of time per every meter and
resource:
ceilometer statistics -m cpu_util -q
'timestampSTART;timestamp=END;resource_id=vm_uuid' --period 3600

Vladik



- Original Message -
 From: Daniel P. Berrange berra...@redhat.com
 To: Vladik Romanovsky vladik.romanov...@enovance.com
 Cc: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org, John
 Garbutt j...@johngarbutt.com
 Sent: Thursday, 19 December, 2013 10:37:27 AM
 Subject: Re: [openstack-dev] [nova] VM diagnostics - V3 proposal
 
 On Thu, Dec 19, 2013 at 03:47:30PM +0100, Vladik Romanovsky wrote:
  I think it was:
  
  ceilometer sample-list -m cpu_util -q 'resource_id=vm_uuid'
 
 Hmm, a standard devstack deployment of ceilometer doesn't seem to
 record any performance stats at all - just shows me the static
 configuration parameters :-(
 
  ceilometer meter-list  -q
'resource_id=296b22c6-2a4d-4a8d-a7cd-2d73339f9c70'
 
+-+---+--+---
---+--+--
+
 | Name| Type  | Unit | Resource ID
 | | User ID  | Project ID
 | |
 
+-+---+--+---
---+--+--
+
 | disk.ephemeral.size | gauge | GB   |
 | 296b22c6-2a4d-4a8d-a7cd-2d73339f9c70 |
96f9a624a325473daf4cd7875be46009 |
 | ec26984024c1438e8e2f93dc6a8c5ad0 |
 | disk.root.size  | gauge | GB   |
 | 296b22c6-2a4d-4a8d-a7cd-2d73339f9c70 |
96f9a624a325473daf4cd7875be46009 |
 | ec26984024c1438e8e2f93dc6a8c5ad0 |
 | instance| gauge | instance |
 | 296b22c6-2a4d-4a8d-a7cd-2d73339f9c70 |
96f9a624a325473daf4cd7875be46009 |
 | ec26984024c1438e8e2f93dc6a8c5ad0 |
 | instance:m1.small   | gauge | instance |
 | 296b22c6-2a4d-4a8d-a7cd-2d73339f9c70 |
96f9a624a325473daf4cd7875be46009 |
 | ec26984024c1438e8e2f93dc6a8c5ad0 |
 | memory  | gauge | MB   |
 | 296b22c6-2a4d-4a8d-a7cd-2d73339f9c70 |
96f9a624a325473daf4cd7875be46009 |
 | ec26984024c1438e8e2f93dc6a8c5ad0 |
 | vcpus   | gauge | vcpu |
 | 296b22c6-2a4d-4a8d-a7cd-2d73339f9c70 |
96f9a624a325473daf4cd7875be46009 |
 | ec26984024c1438e8e2f93dc6a8c5ad0 |
 
+-+---+--+---
---+--+--
+
 
 
 If the admin user can't rely on ceilometer guaranteeing availability of
 the performance stats at all, then I think having an API in nova to
report
 them is in fact justifiable. In fact it is probably justifiable no
matter
 what as a fallback way to check that VMs are doing in the fact of
failure
 of ceilometer / part of the cloud infrastructure.
 
 Daniel
 --
 |: 
https://urldefense.proofpoint.com/v1/url?u=http://berrange.com/k=oIvRg1%
2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq
8%3D%0Am=rSOjPJG6y%2F7%2B6l5u7ekbOpyWGQbpEaEZGcEqj8pnDJk%3D%0As=6555259
3e486953ee40218f87feced256047c7277195f1c4e44e44fa847210a4  -o-
https://urldefense.proofpoint.com/v1/url?u=http://www.flickr.com/photos/d
berrange/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2B
fDtysg45MkPhCZFxPEq8%3D%0Am=rSOjPJG6y%2F7%2B6l5u7ekbOpyWGQbpEaEZGcEqj8pn
DJk%3D%0As=5a2cc10d6d1df7a65129d7b3184e7280c0e2ad47c969e16bdba70a66d3b34
905 :|
 |: 
https://urldefense.proofpoint.com/v1/url?u=http://libvirt.org/k=oIvRg1%2
BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8
%3D%0Am=rSOjPJG6y%2F7%2B6l5u7ekbOpyWGQbpEaEZGcEqj8pnDJk%3D%0As=64423471
28d8c5384877cb4e356baa489330dd532f9cdf764bfb6d5fd65ce984
-o- 
https://urldefense.proofpoint.com/v1/url?u=http://virt-manager.org/k=oIv
Rg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZF

[openstack-dev] [nova] Turbo-hipster

2013-12-31 Thread Gary Kotton
Hi,
It seems that she/he is behaving oddly again. I have posted a patch that does 
not have any database changes and it has give me a –1….
Happy new year
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [DevStack] Nominate Chmouel Boudjnah for core team

2014-01-07 Thread Gary Kotton
+1

On 1/6/14 7:55 PM, Florent Flament florent.flament-...@cloudwatt.com
wrote:

+1

- Original Message -
From: Sean Dague s...@dague.net
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Monday, January 6, 2014 5:30:09 PM
Subject: Re: [openstack-dev] [DevStack] Nominate Chmouel Boudjnah for
core team

On 01/06/2014 11:26 AM, Dean Troyer wrote:
 With the new year comes a long-overdue cleanup to the devstack-core
 membership and the desire to expand he team a bit.  I propose to add
 Chmouel Boudjnah as he has been a steady contributor for some time,
 doing much of the Swift implementation.
 
 dt
 
 -- 
 
 Dean Troyer
 dtro...@gmail.com mailto:dtro...@gmail.com
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi
-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar
=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=53Z5LDc715UooKPoE2
13Vj0lKt7CUHw%2BrXpa6Wles%2Bg%3D%0As=402e30f564128120f358220904c2e24a56e
6cc8a2a23249f9b7578b8102fc396
 

+1

   -Sean

-- 
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
https://urldefense.proofpoint.com/v1/url?u=http://dague.net/k=oIvRg1%2BdG
AgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%
0Am=53Z5LDc715UooKPoE213Vj0lKt7CUHw%2BrXpa6Wles%2Bg%3D%0As=51cdb7007e27c
2c40c9596dc8fd55707794bf515598bbab5d347c0bfb9db940b


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e
H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=53Z5LDc715UooKPoE213V
j0lKt7CUHw%2BrXpa6Wles%2Bg%3D%0As=402e30f564128120f358220904c2e24a56e6cc8
a2a23249f9b7578b8102fc396

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e
H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=53Z5LDc715UooKPoE213V
j0lKt7CUHw%2BrXpa6Wles%2Bg%3D%0As=402e30f564128120f358220904c2e24a56e6cc8
a2a23249f9b7578b8102fc396


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


[openstack-dev] [Nova] libvirt unit test errors

2014-01-07 Thread Gary Kotton
Hi,
Anyone aware of the following:


2014-01-07 
11:59:47.428http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_11_59_47_428
 | Requirement already satisfied (use --upgrade to upgrade): markupsafe in 
./.tox/py27/lib/python2.7/site-packages (from Jinja2=2.3-sphinx=1.1.2,1.2)
2014-01-07 
11:59:47.429http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_11_59_47_429
 | Cleaning up...
2014-01-07 
12:01:32.134http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_01_32_134
 | Unimplemented block at ../../relaxng.c:3824
2014-01-07 
12:01:33.893http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_01_33_893
 | Unimplemented block at ../../relaxng.c:3824
2014-01-07 
12:10:25.292http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_10_25_292
 | libvirt:  error : internal error: could not initialize domain event timer
2014-01-07 
12:11:32.783http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_11_32_783
 | running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
2014-01-07 
12:11:32.783http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_11_32_783
 | OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
2014-01-07 
12:11:32.783http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_11_32_783
 | OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
2014-01-07 
12:11:32.784http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_11_32_784
 | ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --list
2014-01-07 
12:11:32.784http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_11_32_784
 | running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
2014-01-07 
12:11:32.784http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_11_32_784
 | OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
2014-01-07 
12:11:32.784http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_11_32_784
 | OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
2014-01-07 
12:11:32.784http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_11_32_784
 | ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list 
/tmp/tmp.pS70eSqBIL/tmpZV93Uv
2014-01-07 
12:11:32.784http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_11_32_784
 | running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
2014-01-07 
12:11:32.784http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_11_32_784
 | OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
2014-01-07 
12:11:32.785http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_11_32_785
 | OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
2014-01-07 
12:11:32.785http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_11_32_785
 | ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list 
/tmp/tmp.pS70eSqBIL/tmpC2pLuK
2014-01-07 
12:11:32.785http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_11_32_785
 | running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
2014-01-07 
12:11:32.785http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_11_32_785
 | OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
2014-01-07 
12:11:32.785http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_11_32_785
 | OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
2014-01-07 
12:11:32.785http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_11_32_785
 | ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list 
/tmp/tmp.pS70eSqBIL/tmpd1ZnJj
2014-01-07 
12:11:32.785http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_11_32_785
 | running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
2014-01-07 
12:11:32.786http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_11_32_786
 | OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
2014-01-07 
12:11:32.786http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_11_32_786
 | OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
2014-01-07 
12:11:32.786http://logs.openstack.org/10/60010/2/check/gate-nova-python27/ebd53ea/console.html#_2014-01-07_12_11_32_786
 | ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list 
/tmp/tmp.pS70eSqBIL/tmpRB7C09
2014-01-07 

Re: [openstack-dev] [Nova][Vmware]Bad Performance when creating a new VM

2014-01-08 Thread Gary Kotton
Hi,
In order for the VM to be booted the image needs to be on a datastore 
accessible by the host. By default the data tore will not have the image. This 
is copied from glance tot he datastore. This is most probably where the problem 
is. This may take a while depending on the connectivity between the openstack 
setup and  your backbend datastore. Once you have done this you will see a 
directory on the datastore called vmware_base. This will contain that image. 
From then on it should be smooth sailing.
Please note that we are working on a number of things to improve this:

 1.  Image cache aging (blueprint is implemented and pending review)
 2.  Adding a Vmware glance datastore – which will greatly improve the copy 
process described above

Thanks
Gary

From: Ray Sun xiaoq...@gmail.commailto:xiaoq...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, January 8, 2014 4:30 AM
To: OpenStack Dev 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Nova][Vmware]Bad Performance when creating a new VM

Stackers,
I tried to create a new VM using the driver VMwareVCDriver, but I found it's 
very slow when I try to create a new VM, for example, 7GB Windows Image spent 3 
hours.

Then I tried to use curl to upload a iso to vcenter directly.

curl -H Expect: -v --insecure --upload-file windows2012_server_cn_x64.iso 
https://administrator:root123.@200.21.0.99/folder/iso/windows2012_server_cn_x64.iso?dcPath=dataCenterdsName=datastore2https://urldefense.proofpoint.com/v1/url?u=https://administrator:root123.%40200.21.0.99/folder/iso/windows2012_server_cn_x64.iso?dcPath%3DdataCenter%26dsName%3Ddatastore2k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=lhA2fUha%2FtHWjSl8QcZq5lQ9MSETFSwBcyKMNtXnhx0%3D%0As=e4e18c64b88329d7c54cdaef299e186aa13f2dd63f37654a0171a70d70b42cd3

The average speed is 0.8 MB/s.

Finally, I tried to use vSpere web client to upload it, it's only 250 KB/s.

I am not sure if there any special configurations for web interface for 
vcenter. Please help.

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


[openstack-dev] [nova][turbo hipster] unable to rebase

2014-01-08 Thread Gary Kotton
Hi,
Patch sets that are cascaded has have the following errors:

Database migration testing failed either due to migrations unable to be 
applied correctly or taking too long.

This change was unable to be automatically merged with the current state of the 
repository. Please rebase your change and upload a new patch set.

What do you suggest?

Thanks

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


Re: [openstack-dev] [Nova][Vmware]Bad Performance when creating a new VM

2014-01-08 Thread Gary Kotton


From: Ray Sun xiaoq...@gmail.commailto:xiaoq...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, January 8, 2014 4:09 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova][Vmware]Bad Performance when creating a new 
VM

Gary,
Thanks. Curretly, our upload speed is in the normal range?

[Gary] #hrs for a 7G file is far too long. For testing I have a 1G image. This 
takes about 2 minutes to upload to the cache. Please note that I am running on 
a virtual setup so thing take far longer than they would if it was bare metal


Best Regards
-- Ray


On Wed, Jan 8, 2014 at 4:31 PM, Gary Kotton 
gkot...@vmware.commailto:gkot...@vmware.com wrote:
Hi,
In order for the VM to be booted the image needs to be on a datastore 
accessible by the host. By default the data tore will not have the image. This 
is copied from glance tot he datastore. This is most probably where the problem 
is. This may take a while depending on the connectivity between the openstack 
setup and  your backbend datastore. Once you have done this you will see a 
directory on the datastore called vmware_base. This will contain that image. 
From then on it should be smooth sailing.
Please note that we are working on a number of things to improve this:

 1.  Image cache aging (blueprint is implemented and pending review)
 2.  Adding a Vmware glance datastore – which will greatly improve the copy 
process described above

Thanks
Gary

From: Ray Sun xiaoq...@gmail.commailto:xiaoq...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, January 8, 2014 4:30 AM
To: OpenStack Dev 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Nova][Vmware]Bad Performance when creating a new VM

Stackers,
I tried to create a new VM using the driver VMwareVCDriver, but I found it's 
very slow when I try to create a new VM, for example, 7GB Windows Image spent 3 
hours.

Then I tried to use curl to upload a iso to vcenter directly.

curl -H Expect: -v --insecure --upload-file windows2012_server_cn_x64.iso 
https://administrator:root123.@200.21.0.99/folder/iso/windows2012_server_cn_x64.iso?dcPath=dataCenterdsName=datastore2https://urldefense.proofpoint.com/v1/url?u=https://administrator:root123.%40200.21.0.99/folder/iso/windows2012_server_cn_x64.iso?dcPath%3DdataCenter%26dsName%3Ddatastore2k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=lhA2fUha%2FtHWjSl8QcZq5lQ9MSETFSwBcyKMNtXnhx0%3D%0As=e4e18c64b88329d7c54cdaef299e186aa13f2dd63f37654a0171a70d70b42cd3

The average speed is 0.8 MB/s.

Finally, I tried to use vSpere web client to upload it, it's only 250 KB/s.

I am not sure if there any special configurations for web interface for 
vcenter. Please help.

Best Regards
-- Ray

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devhttps://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=9a6QiCBNYRRJYDjh9SisIB0JUGIlDmd5rmicgbmlEVw%3D%0As=2323d9a1eee95934422fcce0089a81480b96a8acf29badb57e47d81fda353394


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


[openstack-dev] [Nova][Neutron][Temptest] Gating failures

2014-01-12 Thread Gary Kotton
Hi,
I was looking into SSH failures and stumbled upon the following tempest issue. 
The validations would not take into account the neutron agent heartbeat 
timeout. This would cause tests to occasionally fail. In short there was a 
window of at most 4 second for the test test_list_agent to run in order to 
pass. Please see: https://bugs.launchpad.net/tempest/+bug/1268293
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [nova] Gate issues

2014-01-23 Thread Gary Kotton
Hi,
1 in 3 failures today are due to:


2014-01-23 
11:54:03.879http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_879
 |
2014-01-23 
11:54:03.880http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_880
 | Traceback (most recent call last):
2014-01-23 
11:54:03.880http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_880
 |   File nova/tests/compute/test_compute.py, line 577, in 
test_poll_volume_usage_with_data
2014-01-23 
11:54:03.880http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_880
 | self.compute._last_vol_usage_poll)
2014-01-23 
11:54:03.880http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_880
 |   File /usr/lib/python2.7/unittest/case.py, line 420, in assertTrue
2014-01-23 
11:54:03.880http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_880
 | raise self.failureException(msg)
2014-01-23 
11:54:03.880http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_880
 | AssertionError: _last_vol_usage_poll was not properly updated 1390477654.28
2014-01-23 
11:54:03.880http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_880
 | ==
2014-01-23 
11:54:03.880http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_880
 | FAIL: nova.tests.db.test_sqlite.TestSqlite.test_big_int_mapping
2014-01-23 
11:54:03.880http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_880
 | tags: worker-1
2014-01-23 
11:54:03.880http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_880
 | --
2014-01-23 
11:54:03.880http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_880
 | Empty attachments:
2014-01-23 
11:54:03.880http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_880
 |   pythonlogging:''
2014-01-23 
11:54:03.881http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_881
 |   stderr
2014-01-23 
11:54:03.881http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_881
 |   stdout
2014-01-23 
11:54:03.881http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_881
 |
2014-01-23 
11:54:03.881http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_881
 | Traceback (most recent call last):
2014-01-23 
11:54:03.881http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_881
 |   File nova/tests/db/test_sqlite.py, line 53, in test_big_int_mapping
2014-01-23 
11:54:03.881http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_881
 | output, _ = utils.execute(get_schema_cmd, shell=True)
2014-01-23 
11:54:03.881http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_881
 |   File nova/utils.py, line 166, in execute
2014-01-23 
11:54:03.881http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_881
 | return processutils.execute(*cmd, **kwargs)
2014-01-23 
11:54:03.881http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_881
 |   File nova/openstack/common/processutils.py, line 168, in execute
2014-01-23 
11:54:03.881http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_881
 | result = obj.communicate()
2014-01-23 
11:54:03.881http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_881
 |   File /usr/lib/python2.7/subprocess.py, line 754, in communicate
2014-01-23 
11:54:03.882http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_882
 | return self._communicate(input)
2014-01-23 
11:54:03.882http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_882
 |   File /usr/lib/python2.7/subprocess.py, line 1314, in _communicate
2014-01-23 
11:54:03.882http://logs.openstack.org/14/68614/1/check/gate-nova-python27/e11a79c/console.html#_2014-01-23_11_54_03_882
 | stdout, stderr = self._communicate_with_select(input)
2014-01-23 

Re: [openstack-dev] [gantt] Scheduler sub-group meeting agenda 1/28

2014-01-28 Thread Gary Kotton
Hi,

Just an update regarding the instance groups:
1. The API has been posted - https://review.openstack.org/#/c/62557/
2. The CLI has been posted - https://review.openstack.org/#/c/32904/

Thanks
Gary

On 1/28/14 12:45 PM, Khanh-Toan Tran khanh-toan.t...@cloudwatt.com
wrote:

Dear all,

If we have time, I would like to discuss our new blueprint:
Policy-Based-Scheduler:

https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.ne
t/nova/%2Bspec/policy-based-schedulerk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A
r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=mlxSl7eekysxEmXTQX
H%2Fn3BYc7EtH9FtCkvzpurmzGs%3D%0As=d2b07d92e07836a2c09310e8af480e091f3ea4
0765ab07e30f3224f9fe3e4825
whose code is ready for review:

https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%2
3/c/61386/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2B
fDtysg45MkPhCZFxPEq8%3D%0Am=mlxSl7eekysxEmXTQXH%2Fn3BYc7EtH9FtCkvzpurmzGs
%3D%0As=636a4589d04859dc931db99487a6414966ae4b651df123e902905dee787d4b7e


Best regards,

Toan

- Original Message -
From: Donald D Dugger donald.d.dug...@intel.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Tuesday, January 28, 2014 4:46:12 AM
Subject: [openstack-dev] [gantt] Scheduler sub-group meeting agenda 1/28

1) Memcached based scheduler updates
2) Scheduler code forklift
3) Opens

--
Don Dugger
Censeo Toto nos in Kansa esse decisse. - D. Gale
Ph: 303/443-3786


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e
H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=mlxSl7eekysxEmXTQXH%2
Fn3BYc7EtH9FtCkvzpurmzGs%3D%0As=b4c1585b0940f1afd95f490dd9ac935c31906b00c
efac8fe709226c913afbb79

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e
H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=mlxSl7eekysxEmXTQXH%2
Fn3BYc7EtH9FtCkvzpurmzGs%3D%0As=b4c1585b0940f1afd95f490dd9ac935c31906b00c
efac8fe709226c913afbb79


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


Re: [openstack-dev] [nova] vmware minesweeper jobs failing?

2014-01-28 Thread Gary Kotton
Hi,
Lats week there were some infra problems. These have been addressed and
minesweeper is back in action.
Thanks
Gary

On 1/25/14 4:58 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote:

Seeing a few patches where vmware minesweeper is saying the build
failed, but looks like an infra issue? An example:

https://urldefense.proofpoint.com/v1/url?u=http://208.91.1.172/logs/nova/6
9046/1/console.txtk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6h
goMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=JPltzh9ECwHiCNsFh5JfzMLgzSkhXMe3%2BmY
6PnXr1KM%3D%0As=3521236ab51271ea722cb51a5ca6be02ed5d7d143abfe3176026fdfe4
b227f19

-- 

Thanks,

Matt Riedemann


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e
H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=JPltzh9ECwHiCNsFh5Jfz
MLgzSkhXMe3%2BmY6PnXr1KM%3D%0As=ba8f2962e62ce0d9bdc32ad802e6aa5cd11497509
ddb02812d2c5666adb351e5


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


[openstack-dev] [Nova] Minesweeper update

2014-01-29 Thread Gary Kotton
Hi,
At the moment we have a terribly long queue for minesweeper. We are able to 
reduce this considerably by running tempest tests in parallel. We have 
encountered 2 race conditions when we do this and it would be very helpful if 
we can get the following patches in – they will help with the speed of the 
minesweeper validations.
- https://review.openstack.org/#/c/65306/ - VMware: fix race for datastore 
directory existence
- https://review.openstack.org/#/c/69622/ - VMware: prevent race for vmdk 
deletion
These have both been validated by minesweeper and show that they address the 
problems.
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

2014-01-29 Thread Gary Kotton


On 1/29/14 7:39 PM, Russell Bryant rbry...@redhat.com wrote:

On 01/29/2014 12:27 PM, Daniel P. Berrange wrote:
 On Wed, Jan 29, 2014 at 11:47:07AM -0500, Russell Bryant wrote:
 Greetings,

 A while back I mentioned that we would revisit the potential
deprecation
 of nova-network in Icehouse after the icehouse-2 milestone.  The time
 has come.  :-)

 First, let me recap my high level view of the blockers to deprecating
 nova-network in favor of Neutron:

   - Feature parity
 - The biggest gap here has been nova-network's multi-host mode.
   Neutron needs some sort of HA for l3 agents, as well as the
   ability to run in a mode that enables a single tenant's traffic
   to be actively handled by multiple nodes.

   - Testing / Quality parity
 - Neutron needs to reach testing and quality parity in CI.  This
   includes running the full tempest suite, for example.  For all
   tests run against nova with nova-network that are applicable,
they
   need to be run against Neutron, as well.  All of these jobs
should
   have comparable or better reliability than the ones with
   nova-network.

   - Production-ready open source components
 - nova-network provides basic, but usable in production networking
   based purely on open source components.  Neutron must have
   production-ready options based purely on open source components,
   as well, that provides comparable or better performance and
   reliability.
 
 What, no mention of providing an automated upgrade path ? Given how
 we go to great lengths to enable continuous deployment with automated
 upgrade paths, I'd really expect to see something to deal with migrating
 people from nova-network to neutron with existing tenants unaffected.

I was thinking for the upgrade process that we could leverage the port
attach/detach BP done by Dan Smith a while ago. This has libvirt support
and there are patches pending approval for Xen and Vmware. Not sure about
the other drivers.

If the guest can deal with the fact that the nova port is being removed
and a new logical port is added then we may have the chance of no down
time. If this works then we may need to add support for nova-network port
detach and we may have a seamless upgrade path.


That's a good point.  This is actually a very sticky situation.  We have
a upgrade path already, which is why I didn't mention it.  It's not
really great though, so it's worth further discussion.  The path is
roughly:

1) Deploy a parallel nova install that uses Neutron, but shares all
other services with the existing Nova that uses nova-network.
(Keystone, glance, cinder, etc)

2) Spawn new instances in the new Nova.

3) For any instances that you want to migrate over to Neutron, snapshot
them to glance, and then re-spawn them in the new Nova.

This is the only plan that I've heard that we *know* should work for all
deployment variations.  I've seen very little effort go into
investigating or documenting any more advanced upgrade paths.

The other upgrade piece is some sort of data migration.  There are some
bits of data, such as security group definitions, that we should be able
to automatically export from nova and import into neutron.  I don't
think anyone has worked on that, either.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e
H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=L%2FurKFNkdV1Uy8T0anh
nW56lLyvFw%2BDQxjEDvp4Ji5I%3D%0As=27097272ad5841caccb4cf2ca0e9f6cf02cbf30
a9cff5a58fcee92b9933bad37


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


Re: [openstack-dev] [Nova][Scheduler] Will the Scheuler use Nova Objects?

2014-01-30 Thread Gary Kotton
Hi,
I started to do the work – https://review.openstack.org/#/c/65691/. From the 
comments on the review it did not seem the right way to go. So I gave up on it. 
Sorry to not have updated. I personally think that the scheduler should use 
objects, the reason for this is as follows:

 1.  One of the aims of the objects is to enable seamless upgrades. If we have 
this in the gannet, that starts with using only the nova database then we can 
upgrade to using another database. The object interface will do the translations
 2.  We may be able to leverage objects to interface with different types of 
services. That will enable us to provide cross service features far quicker.

Thanks
Gary

From: Murray, Paul (HP Cloud Services) 
pmur...@hp.commailto:pmur...@hp.com
Date: Thursday, January 30, 2014 11:41 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Cc: Administrator gkot...@vmware.commailto:gkot...@vmware.com, Dan Smith 
d...@danplanet.commailto:d...@danplanet.com
Subject: [Nova][Scheduler] Will the Scheuler use Nova Objects?

Hi,

I have heard a couple of conflicting comments about the scheduler and nova 
objects that I would like to clear up. In one scheduler/gantt meeting, Gary 
Kotton offered to convert the scheduler to use Nova objects. In another I heard 
that with the creation of Gantt, the scheduler would avoid using any Nova 
specific features including Nova objects.

I can see that these things are evolving at the same time, so it makes sense 
that plans or opinions might change. But I am at a point where it would be nice 
to know.

Which way should this go?

Paul.

Paul Murray
HP Cloud Services
+44 117 312 9309

Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN 
Registered No: 690597 England. The contents of this message and any attachments 
to it are confidential and may be legally privileged. If you have received this 
message in error, you should delete it from your system immediately and advise 
the sender. To any recipient of this message within HP, unless otherwise stated 
you should consider this message and attachments as HP CONFIDENTIAL.

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


Re: [openstack-dev] [nova] vmware minesweeper

2014-02-06 Thread Gary Kotton
Hi,
The following patches will really help minesweeper:
1. Treat exceptions that are caused by parallel tests. This enables us to
run parallel jobs (we have very promising results of running 8 parallel
test jobs):
https://review.openstack.org/#/c/70137/
https://review.openstack.org/#/c/65306/
https://review.openstack.org/#/c/69622/
2. Improve test time considerably:
https://review.openstack.org/#/c/70079/

One of the requirements for Nova is that each driver would provide CI that
validate patches. If there was no CI then the driver would be marked as:
- quality warning (for example the Vmware ESX driver) -
https://review.openstack.org/#/c/70850/
- deprecation warning (for example the Xen driver) -
https://review.openstack.org/#/c/71289/

Having met the requirements is the first step in a long and adventurous
road ahead. As we can see from the gate upstream it is really important
that we constantly work on improving the stability of the CI and the
drivers that are being used. I would also like to note that we are
approaching the end of the cycle - there will soon be a mad rush for
gating. If we have stable CI's then we can provide quicker and more
reliable results. Without these we are shooting ourselves in the foot.

Thanks
Gary


On 2/6/14 2:38 AM, Ryan Hsu r...@vmware.com wrote:

Did you mean flags as in excluding tests? We have an exclude list but
these bugs are intermittent problems that can affect tests at random.

 On Feb 5, 2014, at 4:18 PM, John Dickinson m...@not.mn wrote:
 
 
 On Feb 5, 2014, at 4:04 PM, Ryan Hsu r...@vmware.com wrote:
 
 Also, I have added a section noting crucial bugs/patches that are
blocking Minesweeper.
 
 
 Can we just put flags around them and move on?
 
 
 
 signature.asc
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi
-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar
=0GxzU7fJvvhFTHF4JHrlbg%3D%3D%0Am=PaNv1e10cXsdYwWWKCJcK9%2Fj6DZ6FSoJrgPy
%2FgU%2BqRk%3D%0As=c39743f7af92cf915b297291118d723c9de907f51ddf0f25e7084
5769fcff2c4

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e
H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=NQIsczUP2%2FyA%2FqLVn
6C3i%2FRV3GmAj9EhqVAJDXb5%2FKs%3D%0As=4824efd32fe73aef7e219bc72c25ec37c13
10320c160faff9cdc170b44587bb3


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


[openstack-dev] [Nova] Image caching aging

2014-02-06 Thread Gary Kotton
Hi,
It has come to my attention that this blueprint 
(https://blueprints.launchpad.net/nova/+spec/vmware-image-cache-management) has 
been deferred to the next milestone series. The blueprint ensures that the 
driver has aging for cached images. This is a critical issue for the driver and 
is important as a parity feature.

I really am not sure why it has been deferered and would like to clarify a few 
points.

 1.  The blueprint code was implemented and pending review in November. This 
was blocked due to a blueprint 
(https://blueprints.launchpad.net/nova/+spec/multiple-image-cache-handlers) 
that is not at all related to the driver itself. Russells point for blocking 
the BP was there is common code between all drivers. This was addressed by: 
https://review.openstack.org/#/c/59994/ (approved on 17th December).
 2.  That aging code was rebased and pushed again in December.

It would really be nice to understand why the BP has been deferred to Juno. 
There was a mail that stated the following:

 1.  All BP's need to be in by Feb 4th (this BP was in and approved in I2)
 2.  The code for BP's needs to be in by February the 18th. The code was ready 
for review in December.

The code is specific to the VMware driver and provides parity to other drivers 
that have image caching. It would really be nice to understand why this has 
been deferred and why a feature that this totally isolated to a virtualization 
driver is deferred.

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


Re: [openstack-dev] [Nova][vmware] A new VMwareAPISession

2014-02-06 Thread Gary Kotton
Hi,
Thanks for the detailed mail. For the first step of moving the code into
OSLO we are trying to be as conservative as possible (similar to the fork
lift of the scheduler code). That is, we are taking working code and
moving it to the common library, not doing any rewrites and using the same
functionality and flows. Once that is in and stable then we should start
to work on making it more robust. Incidentally the code that was copied is
not Nova's but Cinders. When the Cinder driver was being posted the team
made a considerable amount of improvements to the driver.
The reason that the _call_method is used is that this deals with session
failures and has support for retries etc. Please see
https://review.openstack.org/#/c/61555/.
I certainly agree that we can improve the code moving forwards. I think
that the first priority should get a working version in OSLO. Once it is
up and running then we should certain start addressing issues that you
have raised.
Thanks
Gary


On 2/6/14 12:43 PM, Matthew Booth mbo...@redhat.com wrote:

There's currently an effort to create a common internal API to the
vSphere/ESX API:

https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.ne
t/oslo/%2Bspec/vmware-apik=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8
NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=8nIWvYjr1NVyVpYg3ZwDiG5VZAeqSk
w8MPwOPQ4k8zs%3D%0As=facc68779808dd3d6fb45fbb9a7addb9c8f392421bfe850a9941
ec732195d641

I see there's some code already in place which essentially copies what's
currently in Nova. Having spent some time digging in this code recently,
I would take the opportunity of this refactor to fix a few design issues
in the current code, which has an 'organic' feel to it.

The current code has 2 main objects:

* driver.VMwareAPISession

This object creates a Vim object and manages a session in it. It
provides _call_method(), which calls a method in an external module and
retries it if it failed because of a bad session. _call_method has also
had shoehorned into it the ability to make direct Vim calls.

* vim.Vim

This object creates a connection to vSphere/ESX and provides an API to
make remote calls.

Here are 2 typical uses of the API, both taken from vmops.py:

---
  hardware_devices = self._session._call_method(vim_util,
  get_dynamic_property, vm_ref,
  VirtualMachine, config.hardware.device)
---

This is using _call_method() to wrap:

  vim_util.get_dynamic_property(vm_ref, VirtualMachine,
config.hardware.device)

vim_util.get_dynamic_property() does an amount of work and creates a
number of objects before ultimately calling:

 return vim.RetrievePropertiesEx(...)

Note that in the event that this call fails, for example due to a
session timeout or a network error, the entire function will be
needlessly re-executed.

---
  reconfig_task = self._session._call_method(
  self._session._get_vim(),
  ReconfigVM_Task, vm_ref,
  spec=vmdk_attach_config_spec)
  self._session._wait_for_task(instance_uuid, reconfig_task)
---

This is using _call_method() to wrap:

  reconfig_task = vim.ReconfigVM_Task(
  vm_ref, spec=vmdk_attach_config_spec)
  wait_for_task(reconfig_task)  [1]

Things wrong with both of the above:
* It obfuscates the intention.
* It makes backtraces confusing.
* It's possible to forget to use _call_method() and it will still work,
resulting in uncaught intermittent faults.

Additionally, the choice of the separation of driver.VMwareAPISession
and vim.Vim results in several confused messes. In particular, notice
how the fault checker called by vim_request_handler can raise
FAULT_NOT_AUTHENTICATED, which then has to be caught and rechecked by
the driver because the required context isn't available in Vim.

As somebody who has come to this code recently, I can also attest that
the varying uses of _call_method with a module or a vim object, and the
fact that it isn't used at all in some places, is highly confusing to
anybody who isn't intimately familiar with the driver.

There's also a subtle point to do with the Vim object's use of
__getattr__ to syntactically sugar remote API calls: it can lead to
non-obvious behaviour. An example of this is
https://urldefense.proofpoint.com/v1/url?u=https://bugs.launchpad.net/nova
/%2Bbug/1275773k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoM
Qu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=8nIWvYjr1NVyVpYg3ZwDiG5VZAeqSkw8MPwOPQ4k
8zs%3D%0As=db08b5e7f320ff7df857d33a65fbe96e61783518e4e4ae2a65020b12bd5151
a1, where the use of a Vim
object in boolean context to test for None[2] resulted in an attempt to
make a remote API call '__nonzero__'. Another example is
https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%2
3/c/69652/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2B
fDtysg45MkPhCZFxPEq8%3D%0Am=8nIWvYjr1NVyVpYg3ZwDiG5VZAeqSkw8MPwOPQ4k8zs%3

Re: [openstack-dev] [Nova][vmware] A new VMwareAPISession

2014-02-06 Thread Gary Kotton


On 2/6/14 1:58 PM, Matthew Booth mbo...@redhat.com wrote:

On 06/02/14 11:24, Gary Kotton wrote:
 Hi,
 Thanks for the detailed mail. For the first step of moving the code into
 OSLO we are trying to be as conservative as possible (similar to the
fork
 lift of the scheduler code). That is, we are taking working code and
 moving it to the common library, not doing any rewrites and using the
same
 functionality and flows. Once that is in and stable then we should start
 to work on making it more robust.

In moving the code to oslo there's going to be some donkey work required
to find all current uses of the code and fix them up. I'm proposing this
change now because it would be a great opportunity to do that donkey
work just once.

The work has already been done - https://review.openstack.org/#/c/70175/
This also has a +1 from the minesweeper which means that the API's are
working correctly.


Also notice that the actual usage of the proposed API is very similar to
the old one. The donkey work would essentially amount to:

* Change all instances of vim.Method(object, args) in vim_util to
vim.call(object, Method, args)

* Change all instances of session._call_method(vim_util, 'method', args)
everywhere to vim_util.method(session, args)

Note that the changes are mechanical, and you're going to have to touch
it for the move to oslo anyway.

Also note that the proposed API would, at least in the first instance,
be substantially a cut and paste of existing code.

Incidentally the code that was copied is
 not Nova's but Cinders. When the Cinder driver was being posted the team
 made a considerable amount of improvements to the driver.

I've read it. It's certainly much prettier python, but the design is the
same as the Nova driver.

 The reason that the _call_method is used is that this deals with session
 failures and has support for retries etc. Please see
 
https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%
23/c/61555/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%
2BfDtysg45MkPhCZFxPEq8%3D%0Am=co4zzllM3r0kGeYRL5kq9xJgzPe0T9gSqW%2B2XOJ%
2FTKY%3D%0As=3efe43037653b6caff24d2d253f566c1a1defa1fe4f0a902f57a17bf1bf
d2311.

That's one of the explicit design goals of the proposed API. Notice that
mistakes like this are no longer possible, as the call() method does
session management and retries, and there is no other exposed interface
to make remote API calls.

 I certainly agree that we can improve the code moving forwards. I think
 that the first priority should get a working version in OSLO. Once it is
 up and running then we should certain start addressing issues that you
 have raised.

I think it's almost no additional work to fix it at this stage, given
that the code is being refactored anyway and it will require donkey work
in the driver to match up with it. If we wait until later it becomes a
whole additional task.

Matt

 Thanks
 Gary
 
 
 On 2/6/14 12:43 PM, Matthew Booth mbo...@redhat.com wrote:
 
 There's currently an effort to create a common internal API to the
 vSphere/ESX API:

 
https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.
ne
 
t/oslo/%2Bspec/vmware-apik=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZ
o8
 
NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=8nIWvYjr1NVyVpYg3ZwDiG5VZAeq
Sk
 
w8MPwOPQ4k8zs%3D%0As=facc68779808dd3d6fb45fbb9a7addb9c8f392421bfe850a99
41
 ec732195d641

 I see there's some code already in place which essentially copies
what's
 currently in Nova. Having spent some time digging in this code
recently,
 I would take the opportunity of this refactor to fix a few design
issues
 in the current code, which has an 'organic' feel to it.

 The current code has 2 main objects:

 * driver.VMwareAPISession

 This object creates a Vim object and manages a session in it. It
 provides _call_method(), which calls a method in an external module and
 retries it if it failed because of a bad session. _call_method has also
 had shoehorned into it the ability to make direct Vim calls.

 * vim.Vim

 This object creates a connection to vSphere/ESX and provides an API to
 make remote calls.

 Here are 2 typical uses of the API, both taken from vmops.py:

 ---
  hardware_devices = self._session._call_method(vim_util,
  get_dynamic_property, vm_ref,
  VirtualMachine, config.hardware.device)
 ---

 This is using _call_method() to wrap:

  vim_util.get_dynamic_property(vm_ref, VirtualMachine,
config.hardware.device)

 vim_util.get_dynamic_property() does an amount of work and creates a
 number of objects before ultimately calling:

 return vim.RetrievePropertiesEx(...)

 Note that in the event that this call fails, for example due to a
 session timeout or a network error, the entire function will be
 needlessly re-executed.

 ---
  reconfig_task = self._session._call_method(
  self._session._get_vim(),
  ReconfigVM_Task, vm_ref

[openstack-dev] [Nova] Gate broken

2014-02-07 Thread Gary Kotton
Hi,
Anyone aware of:


2014-02-08 
06:49:42.022http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_022
 | ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list 
/tmp/tmp.aaa9SCw11a/tmpuyhFPj
2014-02-08 
06:49:42.022http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_022
 | ==
2014-02-08 
06:49:42.022http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_022
 | FAIL: nova.tests.test_objectstore.S3APITestCase.test_unknown_bucket
2014-02-08 
06:49:42.023http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_023
 | tags: worker-0
2014-02-08 
06:49:42.023http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_023
 | --
2014-02-08 
06:49:42.023http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_023
 | Empty attachments:
2014-02-08 
06:49:42.024http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_024
 |   stderr
2014-02-08 
06:49:42.024http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_024
 |   stdout
2014-02-08 
06:49:42.024http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_024
 |
2014-02-08 
06:49:42.025http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_025
 | pythonlogging:'': {{{
2014-02-08 
06:49:42.025http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_025
 | INFO [nova.wsgi] S3 Objectstore listening on 127.0.0.1:53278
2014-02-08 
06:49:42.025http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_025
 | INFO [nova.S3 Objectstore.wsgi.server] (29932) wsgi starting up on 
http://127.0.0.1:53278/
2014-02-08 
06:49:42.026http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_026
 | INFO [nova.S3 Objectstore.wsgi.server] 127.0.0.1 HEAD /falalala/ HTTP/1.1 
status: 200 len: 115 time: 0.0010102
2014-02-08 
06:49:42.026http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_026
 | INFO [nova.wsgi] Stopping WSGI server.
2014-02-08 
06:49:42.026http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_026
 | }}}
2014-02-08 
06:49:42.026http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_026
 |
2014-02-08 
06:49:42.027http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_027
 | Traceback (most recent call last):
2014-02-08 
06:49:42.027http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_027
 |   File nova/tests/test_objectstore.py, line 133, in test_unknown_bucket
2014-02-08 
06:49:42.027http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_027
 | bucket_name)
2014-02-08 
06:49:42.028http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_028
 |   File 
/home/jenkins/workspace/gate-nova-python26/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py,
 line 393, in assertRaises
2014-02-08 
06:49:42.028http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_028
 | self.assertThat(our_callable, matcher)
2014-02-08 
06:49:42.028http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_028
 |   File 
/home/jenkins/workspace/gate-nova-python26/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py,
 line 406, in assertThat
2014-02-08 
06:49:42.029http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_029
 | raise mismatch_error
2014-02-08 
06:49:42.029http://logs.openstack.org/93/61693/9/check/gate-nova-python26/9db0d67/console.html#_2014-02-08_06_49_42_029
 | MismatchError: bound method S3Connection.get_bucket of 
S3Connection:127.0.0.1 returned Bucket: falalala

Thanks

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


Re: [openstack-dev] [Nova] Gate broken

2014-02-09 Thread Gary Kotton
Thanks for fixing this.

From: Qiu Yu unic...@gmail.commailto:unic...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Saturday, February 8, 2014 9:44 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] Gate broken


On Sat, Feb 8, 2014 at 3:29 PM, Gary Kotton 
gkot...@vmware.commailto:gkot...@vmware.com wrote:
Hi,
Anyone aware of:


It is caused the new boto 2.25 release.
Joe Gordon filed a new bug on this[1], and I just submitted a patch [2] to fix.

[1] 
https://bugs.launchpad.net/nova/+bug/1277790https://urldefense.proofpoint.com/v1/url?u=https://bugs.launchpad.net/nova/%2Bbug/1277790k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=vI%2BXgZM0Jp3%2FXnNc6HdXuLiyoSz9X9STn67VyRUuQFE%3D%0As=fd96e0f368b4d139e35c6b7a37c7234dbcb580e81a49fd4fc2b5c5bc95535e0d
[2] 
https://review.openstack.org/#/c/72066/https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%23/c/72066/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=vI%2BXgZM0Jp3%2FXnNc6HdXuLiyoSz9X9STn67VyRUuQFE%3D%0As=4eaee74f7d34704dd0e64d6ecbb345ea8f51e1e02cf2532d191d3145d84c1416

Thanks,
--
Qiu Yu

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


Re: [openstack-dev] [gantt] Scheduler sub-group meeting 2/11 - Cancel this week

2014-02-10 Thread Gary Kotton
Hi,
I saw that one of the days there will be talk about Gantt. Would it be possible 
that people not at the local meet up can join this discussion?
Thanks
Gary

From: Dugger, Donald D 
donald.d.dug...@intel.commailto:donald.d.dug...@intel.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, February 10, 2014 6:54 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [gantt] Scheduler sub-group meeting 2/11 - Cancel this 
week

Let’s cancel the meeting this week, some of us (me for sure) will be tied up at 
the Icehouse mid-cycle meetup.

--
Don Dugger
Censeo Toto nos in Kansa esse decisse. - D. Gale
Ph: 303/443-3786

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


Re: [openstack-dev] [Neutron] Nominate Oleg Bondarev for Core

2014-02-11 Thread Gary Kotton
+1


On 2/11/14 1:28 AM, Mark McClain mmccl...@yahoo-inc.com wrote:

All-

I¹d like to nominate Oleg Bondarev to become a Neutron core reviewer.
Oleg has been valuable contributor to Neutron by actively reviewing,
working on bugs, and contributing code.

Neutron cores please reply back with +1/0/-1 votes.

mark
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e
H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=KKs5yVeNC6c7WnUVDuIoU
h%2BlWzSzcE1BVaTK%2B71PUM0%3D%0As=b38d5081ce0f288403c87ba38281d93cd1796c9
3f5482ded0916ee3b26e54774


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


Re: [openstack-dev] [OpenStack][Nova][VCDriver] VMWare VCDriver problems

2014-02-13 Thread Gary Kotton
Hi,
The commit 
https://github.com/openstack/nova/commit/c4bf32c03283cbedade9ab8ca99e5b13b9b86ccb
 added a warning that the ESX driver is not tested. My understanding is that 
there are a number of people using the ESX driver so it should not be 
deprecated. In order to get the warning removed we will need to have CI on the 
driver. As far as I know there is no official decision to deprecate it.
Thanks
Gary

From: Jay Lau jay.lau@gmail.commailto:jay.lau@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, February 13, 2014 4:00 AM
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [OpenStack][Nova][VCDriver] VMWare VCDriver problems

Greetings,

I was now doing some integration with VMWare VCDriver and have some questions 
during the integration work.

1) In Hong Kong Summit, it was mentioned that ESXDriver will be dropped, so do 
we have any plan when to drop this driver?
2) There are many good features in VMWare was not supportted by VCDriver, such 
as live migration, cold migration and resize within one vSphere cluster, also 
we cannot get individual ESX Server details via VCDriver.

Do we have some planning to make those features worked?

--
Thanks,

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


Re: [openstack-dev] [OpenStack][Nova][VCDriver] VMWare VCDriver problems

2014-02-14 Thread Gary Kotton
Hi,
We are currently looking into that.
Thanks
Gary

From: Jay Lau jay.lau@gmail.commailto:jay.lau@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, February 13, 2014 11:14 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [OpenStack][Nova][VCDriver] VMWare VCDriver 
problems

Thanks Gary.

What about live migration with VCDriver, currently I cannot do live migration 
in the condition of between ESX servers in one cluster.

2014-02-13 16:47 GMT+08:00 Gary Kotton 
gkot...@vmware.commailto:gkot...@vmware.com:
Hi,
The commit 
https://github.com/openstack/nova/commit/c4bf32c03283cbedade9ab8ca99e5b13b9b86ccbhttps://urldefense.proofpoint.com/v1/url?u=https://github.com/openstack/nova/commit/c4bf32c03283cbedade9ab8ca99e5b13b9b86ccbk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=lzrbNoejQXG1NI2jpS6g%2FYJanvcIezST4Uenp6Sd5BI%3D%0As=1a39cfb2c41b8ce978956de28a2773a98b75bcfe4c0f135905dc6aa3257b9570
 added a warning that the ESX driver is not tested. My understanding is that 
there are a number of people using the ESX driver so it should not be 
deprecated. In order to get the warning removed we will need to have CI on the 
driver. As far as I know there is no official decision to deprecate it.
Thanks
Gary

From: Jay Lau jay.lau@gmail.commailto:jay.lau@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, February 13, 2014 4:00 AM
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [OpenStack][Nova][VCDriver] VMWare VCDriver problems

Greetings,

I was now doing some integration with VMWare VCDriver and have some questions 
during the integration work.

1) In Hong Kong Summit, it was mentioned that ESXDriver will be dropped, so do 
we have any plan when to drop this driver?
2) There are many good features in VMWare was not supportted by VCDriver, such 
as live migration, cold migration and resize within one vSphere cluster, also 
we cannot get individual ESX Server details via VCDriver.

Do we have some planning to make those features worked?

--
Thanks,

Jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devhttps://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=lzrbNoejQXG1NI2jpS6g%2FYJanvcIezST4Uenp6Sd5BI%3D%0As=b1d6c73107a271d9b3e2c6948bb4bc32185a964d0af83eb60a510d180a4d75f6




--
Thanks,

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


Re: [openstack-dev] [Nova][VMWare] VMwareVCDriver related to resize/cold migration

2014-02-16 Thread Gary Kotton
Hi,
There are two issues here.
The first is a bug fix that is in review:
- https://review.openstack.org/#/c/69209/ (this is where they have the same 
configuration)
The second is WIP:
- https://review.openstack.org/#/c/69262/ (we need to restore)
Thanks
Gary

From: Jay Lau jay.lau@gmail.commailto:jay.lau@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Sunday, February 16, 2014 6:39 AM
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Nova][VMWare] VMwareVCDriver related to resize/cold 
migration

Hey,

I have one question related with OpenStack vmwareapi.VMwareVCDriver resize/cold 
migration.

The following is my configuration:

 DC
|
|Cluster1
|  |
|  |9.111.249.56
|
|Cluster2
   |
   |9.111.249.49

Scenario 1:
I started two nova computes manage the two clusters:
1) nova-compute1.conf
cluster_name=Cluster1

2) nova-compute2.conf
cluster_name=Cluster2

3) Start up two nova computes on host1 and host2 separately
4) Create one VM instance and the VM instance was booted on Cluster2 node  
9.111.249.49
| OS-EXT-SRV-ATTR:host | host2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | domain-c16(Cluster2)   
  |
5) Cold migrate the VM instance
6) After migration finished, the VM goes to VERIFY_RESIZE status, and nova 
show indicates that the VM now located on host1:Cluster1
| OS-EXT-SRV-ATTR:host | host1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | domain-c12(Cluster1)   
  |
7) But from vSphere client, it indicates the the VM was still running on 
Cluster2
8) Try to confirm the resize, confirm will be failed. The root cause is that 
nova compute on host2 has no knowledge of domain-c12(Cluster1)

2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp   File 
/usr/lib/python2.6/site-packages/nova/compute/manager.py, line 2810, in 
do_confirm_resize
2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp 
migration=migration)
2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp   File 
/usr/lib/python2.6/site-packages/nova/compute/manager.py, line 2836, in 
_confirm_resize
2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp 
network_info)
2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp   File 
/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py, line 420, in 
confirm_migration
2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp _vmops = 
self._get_vmops_for_compute_node(instance['node'])
2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp   File 
/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py, line 523, in 
_get_vmops_for_compute_node
2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp resource 
= self._get_resource_for_node(nodename)
2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp   File 
/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py, line 515, in 
_get_resource_for_node
2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp raise 
exception.NotFound(msg)
2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp NotFound: 
NV-3AB798A The resource domain-c12(Cluster1) does not exist
2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp


Scenario 2:

1) Started two nova computes manage the two clusters, but the two computes have 
same nova conf.
1) nova-compute1.conf
cluster_name=Cluster1
cluster_name=Cluster2

2) nova-compute2.conf
cluster_name=Cluster1
cluster_name=Cluster2

3) Then create and resize/cold migrate a VM, it can always succeed.


Questions:
For multi-cluster management, does vmware require all nova compute have same 
cluster configuration to make sure resize/cold migration can succeed?

--
Thanks,

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


[openstack-dev] [infra] reverify/recheck

2014-02-17 Thread Gary Kotton
Hi,
It seems that the command 'reverify bug number' is not working. Anyone else 
experienced this lately.
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra] reverify/recheck

2014-02-17 Thread Gary Kotton
Hi,
The reverify no bug was removed. But reverify bug # used to work. That no 
longer does. With the constant gate failures how can we ensure that a approved 
patch does a retry?
Thanks
Gary

From: Sylvain Bauza sylvain.ba...@gmail.commailto:sylvain.ba...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, February 17, 2014 2:53 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [infra] reverify/recheck

Hi Gary,

That's normal, this command has been removed since Dec'13, see 
http://lists.openstack.org/pipermail/openstack-dev/2013-December/021649.htmlhttps://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/pipermail/openstack-dev/2013-December/021649.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=B8yQ75uRFa7dyD%2FbgPgO%2FMT2x229MkK1vHWBVAzpFtM%3D%0As=d9cbcbde99b7c88c15ca138499de8f36edd4247ce351e41b241d675b09b79956

-Sylvain


2014-02-17 13:00 GMT+01:00 Gary Kotton 
gkot...@vmware.commailto:gkot...@vmware.com:
Hi,
It seems that the command 'reverify bug number' is not working. Anyone else 
experienced this lately.
Thanks
Gary

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devhttps://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=B8yQ75uRFa7dyD%2FbgPgO%2FMT2x229MkK1vHWBVAzpFtM%3D%0As=21e7f4ebc24f0a13780981720f9332111dd603f3c0661229dc90d82bfb5c3122


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


Re: [openstack-dev] [infra] reverify/recheck

2014-02-17 Thread Gary Kotton
Thanks!
That makes sense. Just odd how a -1 was received.

On 2/17/14 3:15 PM, Akihiro Motoki mot...@da.jp.nec.com wrote:

Hi Gary,

According to zuul layout.yaml [1], reverify bug # should still work
but it seems to work only when verified score from jenkins is -2.
https://urldefense.proofpoint.com/v1/url?u=https://github.com/openstack-in
fra/config/blob/master/modules/openstack_project/files/zuul/layout.yaml%23
L25k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg4
5MkPhCZFxPEq8%3D%0Am=Nf6%2FyHMSSchQO59xIcg6NKX1O2wlkkHHd42bYQim0k0%3D%0A
s=8fc4d7e6970936977dc85989e4e7e9429afb15f5091a768efa4ce236417d9c9b

Note that core team can trigger gate jobs by re-approving the patch.

Thanks,
Akihiro

(2014/02/17 22:03), Gary Kotton wrote:
 Hi,
 The reverify no bug was removed. But reverify bug # used to work.
That no longer does. With the constant gate failures how can we ensure
that a approved patch does a retry?
 Thanks
 Gary

 From: Sylvain Bauza sylvain.ba...@gmail.com
mailto:sylvain.ba...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage
questions) openstack-dev@lists.openstack.org
mailto:openstack-dev@lists.openstack.org
 Date: Monday, February 17, 2014 2:53 PM
 To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
mailto:openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [infra] reverify/recheck

 Hi Gary,

 That's normal, this command has been removed since Dec'13, see
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/pip
ermail/openstack-dev/2013-December/021649.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw
%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=Nf6%2Fy
HMSSchQO59xIcg6NKX1O2wlkkHHd42bYQim0k0%3D%0As=826274ca8ad9562b557322274a
cdacd97482338456820af8c330b76ea7639838
 
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/pi
permail/openstack-dev/2013-December/021649.htmlk=oIvRg1%2BdGAgOoM1BIlLLq
w%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=B8yQ75
uRFa7dyD%2FbgPgO%2FMT2x229MkK1vHWBVAzpFtM%3D%0As=d9cbcbde99b7c88c15ca138
499de8f36edd4247ce351e41b241d675b09b79956

 -Sylvain


 2014-02-17 13:00 GMT+01:00 Gary Kotton gkot...@vmware.com
mailto:gkot...@vmware.com:

 Hi,
 It seems that the command 'reverify bug number' is not working.
Anyone else experienced this lately.
 Thanks
 Gary

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
mailto:OpenStack-dev@lists.openstack.org
 
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi
-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar
=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=Nf6%2FyHMSSchQO59x
Icg6NKX1O2wlkkHHd42bYQim0k0%3D%0As=1a2a59024e18b786b5c2c13535b7f3d050363
ff628dc96b8561e12489d30c0bd
 
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cg
i-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A
r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=B8yQ75uRFa7dyD%2F
bgPgO%2FMT2x229MkK1vHWBVAzpFtM%3D%0As=21e7f4ebc24f0a13780981720f9332111d
d603f3c0661229dc90d82bfb5c3122




 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi
-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar
=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=Nf6%2FyHMSSchQO59x
Icg6NKX1O2wlkkHHd42bYQim0k0%3D%0As=1a2a59024e18b786b5c2c13535b7f3d050363
ff628dc96b8561e12489d30c0bd

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e
H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=Nf6%2FyHMSSchQO59xIcg
6NKX1O2wlkkHHd42bYQim0k0%3D%0As=1a2a59024e18b786b5c2c13535b7f3d050363ff62
8dc96b8561e12489d30c0bd


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


Re: [openstack-dev] call for help with nova bug management

2014-02-19 Thread Gary Kotton
I will help out.
Thanks
Gary

From: Tracy Jones tjo...@vmware.commailto:tjo...@vmware.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, February 18, 2014 9:48 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] call for help with nova bug management

So i have been rather underwhelmed in the enthusiastic response to help out :-)



So far only wendar and johnthetubaguy have signed up.   I was hoping for at 
least 3-5 people to help with the initial triage.  Please sign up this week if 
you can help and i’ll schedule the meetings starting next week




On Feb 14, 2014, at 2:16 PM, Tracy Jones 
tjo...@vmware.commailto:tjo...@vmware.com wrote:

Hi Folks - I’ve offered to help Russell out with managing nova’s bug queue.  
The charter of this is as follows


 1.  Triage the 125 new bugs
 2.  Ensure that the critical bugs are assigned properly and are making progress

Once this part is done we will shift our focus to things like

 *   Bugs in incomplete state with no update by the reporter - they should be 
set to invalid if they requester does not update them in a timely manner.
 *   Bugs which say they are in progress but no progress is being made.   If a 
bug is assigned and simply being ignored we should remove the assignment so 
others can grab it and work on it

The bug triage policy is defined here 
https://wiki.openstack.org/wiki/BugTriagehttps://urldefense.proofpoint.com/v1/url?u=https://wiki.openstack.org/wiki/BugTriagek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=iM9c3M7WWm7TTEGxg7DO4spZaxt3S5NgP6GRop8sfEE%3D%0As=08b0cf24ea8e2ea9f5e9f40e65000c7571d8f39d2478752bbd05798db182f36d


What can you do???  First I need a group of folks to volunteer to help with 1 
and 2.  I will start a weekly IRC meeting where we work on the triage and check 
progress on critical (or even high) prio bugs.  If you can help out, please 
sign up at the end of this etherpad and include your timezone.  Once I have a 
few people to help i will schedule the meeting at a time that I hope is 
convenient for all.

https://etherpad.openstack.org/p/nova-bug-managementhttps://urldefense.proofpoint.com/v1/url?u=https://etherpad.openstack.org/p/nova-bug-managementk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=iM9c3M7WWm7TTEGxg7DO4spZaxt3S5NgP6GRop8sfEE%3D%0As=200cb74eb4c0ca7611cb39ee5cc35cdd40bcf2bb8e50813b2f4a6c469980832c

Thanks in advance for your help.

Tracy

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


Re: [openstack-dev] [nova][libvirt] Is there anything blocking the libvirt driver from implementing the host_maintenance_mode API?

2014-02-23 Thread Gary Kotton
Hi,
Plesae note that regarding the Vmware driver the maintenance mode only works 
with the ESX driver and not the VC driver. For the VC driver there is a patch 
in review - https://review.openstack.org/#/c/72143/
Thanks
Gary

From: Jay Lau jay.lau@gmail.commailto:jay.lau@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Sunday, February 23, 2014 3:14 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova][libvirt] Is there anything blocking the 
libvirt driver from implementing the host_maintenance_mode API?

So there is no need to implement libvirt driver for the host_maintenance_mode 
API as host_maintenance_mode is mainly for VMWare and XenServer, also we can 
use evacuate and os-services/disable for libvirt host maintain, right?

Thanks,

Jay



2014-02-23 5:22 GMT+08:00 Bruce Montague 
bruce_monta...@symantec.commailto:bruce_monta...@symantec.com:

On Fri Feb 21 21:14:56 UTC 2014 Joe Gordon joe.gordon0 at 
gmail.comhttps://urldefense.proofpoint.com/v1/url?u=http://gmail.comk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=qZox2RtL9TtyfQTCmPHLVKpeImL2Fe1NG33oxxlIFTU%3D%0As=aa22811e8ac28f6361f9a621b6fddd174c06e474b0585238e1ef7d294f5fe501
 wrote:

 On Thu, Feb 20, 2014 at 9:38 AM, Matt Riedemann mriedem at 
 linux.vnet.ibm.comhttps://urldefense.proofpoint.com/v1/url?u=http://linux.vnet.ibm.comk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=qZox2RtL9TtyfQTCmPHLVKpeImL2Fe1NG33oxxlIFTU%3D%0As=d0e9aac9517d6900c84731a432cf9180404b53911f3b683c6d41860465926d44
  wrote:


 On 2/19/2014 4:05 PM, Matt Riedemann wrote:

 The os-hosts OS API extension [1] showed up before I was working on the
 project and I see that only the VMware and XenAPI drivers implement it,
 but was wondering why the libvirt driver doesn't - either no one wants
 it, or there is some technical reason behind not implementing it for
 that driver?


 If  I remember correctly maintenance mode is a special thing in Xen.


Maintenance mode is pretty heavily used with VMware vCenter. When an 
environment supports universal live migration of all VMs, it makes sense to 
migrate all VMs running on a physical machine off of that machine before 
bringing it down for maintenance, such as upgrading the hardware. Provides some 
classes of end-users with a more 24x7x365 experience.


 [1]

 http://docs.openstack.org/api/openstack-compute/2/content/PUT_os-hosts-v2_updateHost_v2__tenant_id__os-hosts__host_name__ext-os-hosts.htmlhttps://urldefense.proofpoint.com/v1/url?u=http://docs.openstack.org/api/openstack-compute/2/content/PUT_os-hosts-v2_updateHost_v2__tenant_id__os-hosts__host_name__ext-os-hosts.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=qZox2RtL9TtyfQTCmPHLVKpeImL2Fe1NG33oxxlIFTU%3D%0As=8120001d41ddc39e4e5edf7721c4f47ea324a388dfb95cad944a140fa8b257de



 By the way, am I missing something when I think that this extension is
 already covered if you're:

 1. Looking to get the node out of the scheduling loop, you can just disable
 it with os-services/disable?

 2. Looking to evacuate instances off a failed host (or one that's in
 maintenance mode), just use the evacuate server action.

 I don't think your missing anything.



 --

 Thanks,

 Matt Riedemann





-bruce



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devhttps://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=qZox2RtL9TtyfQTCmPHLVKpeImL2Fe1NG33oxxlIFTU%3D%0As=7d513d1b8c61f68ad14e8f896d90dab47a2eb82e320c9a4f6542a0f677b26349



--
Thanks,

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


Re: [openstack-dev] [All] Fixed recent gate issues

2014-02-23 Thread Gary Kotton


On 2/19/14 10:31 PM, Alan Pevec ape...@gmail.com wrote:

 Yeah it's pip weirdness where things falls apart because of version
cap. It's
 basically installing bin/swift from 1.9 when it sees the version
requirement
 but it leaves everything in python-swiftclient namespace from master.

 So I've actually been looking at this since late yesterday the
conclusion we've
 reached is to just skip the exercises on grizzly. Removing the version
cap isn't
 going to be simple on grizzly because there global requirements wasn't
enforced
 back in grizzly. We'd have to change the requirement for both glance,
horizon,
 and swift and being ~3 weeks away from eol for grizzly I don't think we
should
 mess with that. This failure is only an issue with cli swiftclient on
grizzly
 (and one swift functional test) which as it sits now is just the
devstack
 exercises on grenade. So if we just don't run those exercises on the
grizzly
 side of a grenade run there shouldn't be an issue. I've got 2 patches
to do
 this here:

 
https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%
23/c/74419/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%
2BfDtysg45MkPhCZFxPEq8%3D%0Am=PlTk6Hx5SymtM%2BlXLUIqyNGMz3z9JFKMcy7XJRvm
k6s%3D%0As=591c1b105d86204158b21bd572a7f589f8ad032359282b84da9bc2b649d1a
3f9

 
https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%
23/c/74451/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%
2BfDtysg45MkPhCZFxPEq8%3D%0Am=PlTk6Hx5SymtM%2BlXLUIqyNGMz3z9JFKMcy7XJRvm
k6s%3D%0As=d531e1933102045d5b77138fc42bd8e68ddc3d5b25dd281d94bfb0e9a22b9
a64

Looks like only the latter is needed, devstack-gate core please
approve it to unblock stable/havana.

It looks like this does not solve the issue. I wonder if we need the same
change for stable/havana.


Cheers,
Alan

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e
H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=PlTk6Hx5SymtM%2BlXLUI
qyNGMz3z9JFKMcy7XJRvmk6s%3D%0As=8a9c304e78b852d9eaa9063697282ccd38a303300
54aebe635797a8bce793bbe


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


Re: [openstack-dev] [Nova][VMWare] VMware VM snapshot

2014-02-25 Thread Gary Kotton
Hi,
This is something that would be nice to add as an extension. At the moment it 
is not part of our near term development plans. It would be nice to engage the 
community to discuss and see how this can be exposed correctly using the Nova 
API's. It may be something worthwhile discussing at the up and coming summit.
Thanks
Gary

From: Qin Zhao chaoc...@gmail.commailto:chaoc...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, February 25, 2014 2:05 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova][VMWare] VMware VM snapshot

What I mean is the snapshot of vsphere, which is describe in this page -- 
http://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.vm_admin.doc_50%2FGUID-CA948C69-7F58-4519-AEB1-739545EA94E5.html

It is very useful, if the user plan to perform some risky operations in a VM. I 
am not quite sure if we can model it in Nova, and let the user to create 
snapshot chain via Nova api. Has it been discussed in design session or mail 
group? Anybody know that?


On Tue, Feb 25, 2014 at 6:40 PM, John Garbutt 
j...@johngarbutt.commailto:j...@johngarbutt.com wrote:
On 25 February 2014 09:27, Qin Zhao 
chaoc...@gmail.commailto:chaoc...@gmail.com wrote:
 Hi,

 One simple question about VCenter driver. I feel the VM snapshot function of
 VCenter is very useful and is loved by VCenter users. Does anybody think
 about to let VCenter driver support it?

It depends if that can be modelled well with the current
Nova/Cinder/Glance primitives.

If you do boot from volume, and you see the volume snapshots, and they
behave how cinder expects, and you can model that snapshot as an image
in glance that you can boot new instances from, then maybe it would
work just fine. But we need to take care not to bend the current API
primitives too far out of place.

I remember there being some talk about this at the last summit. How did that go?

John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devhttps://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=HIkeI2LxCwLrVL13ha6fGUuaB%2Fd1GMZdBl5zsu8jMAE%3D%0As=53c780e5a48bdf84774db49876ef2ef822a63a8b8d20e23190bb42273a40c1d0



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


Re: [openstack-dev] What's the name of IRC channel for novaclient?

2014-03-03 Thread Gary Kotton
Hi,
This is the same channel as nova – that is #openstack-nova
Thanks
Gary

From: wu jiang win...@gmail.commailto:win...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, March 3, 2014 10:11 AM
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] What's the name of IRC channel for novaclient?

Hi all,

I want to know what's the name of IRC channel for novaclient? I want to ask 
something about one BP.

And I don't know whether it exists or not, I don't find it in wiki[1].

If you know the information, please tell me. Thanks very much.


Best Wishes,
wingwj

---
[1]. 
https://wiki.openstack.org/wiki/IRChttps://urldefense.proofpoint.com/v1/url?u=https://wiki.openstack.org/wiki/IRCk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=rSQ7EiJDzvK1G5N5PJ%2F7c%2F%2BRab4oueu7AYnZLnM6rtI%3D%0As=c2fa94b9e6cbf44dc5ba85bd824cad3a4704928d51775f57782da3ef7bb8bc9e

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


[openstack-dev] [Nova] FFE Request: ISO support for the VMware driver

2014-03-05 Thread Gary Kotton
Hi,
Unfortunately we did not get the ISO support approved by the deadline. If 
possible can we please get the FFE.

The feature is completed and has been tested extensively internally. The 
feature is very low risk and has huge value for users. In short a user is able 
to upload a iso to glance then boot from that iso.

BP: https://blueprints.launchpad.net/openstack/?searchtext=vmware-iso-boot
Code: https://review.openstack.org/#/c/63084/ and 
https://review.openstack.org/#/c/77965/
Sponsors: John Garbutt and Nikola Dipanov

One of the things that we are planning on improving in Juno is the way that the 
Vmops code is arranged and organized. We will soon be posting a wiki for ideas 
to be discussed. That will enable use to make additions like this a lot simpler 
in the future. But sadly that is not part of the scope at the moment.

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


[openstack-dev] [Nova] Tox issues on a clean environment

2014-03-06 Thread Gary Kotton
Hi,
Anyone know how I cam solve the error below:

  Running setup.py install for jsonpatch
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution 
option: 'entry_poimts'
  warnings.warn(msg)
changing mode of build/scripts-2.7/jsondiff from 664 to 775
changing mode of build/scripts-2.7/jsonpatch from 664 to 775

changing mode of /home/gk-dev/nova/.tox/py27/bin/jsonpatch to 775
changing mode of /home/gk-dev/nova/.tox/py27/bin/jsondiff to 775
  Found existing installation: distribute 0.6.24dev-r0
Not uninstalling distribute at /usr/lib/python2.7/dist-packages, outside 
environment /home/gk-dev/nova/.tox/py27
  Running setup.py install for setuptools

Installing easy_install script to /home/gk-dev/nova/.tox/py27/bin
Installing easy_install-2.7 script to /home/gk-dev/nova/.tox/py27/bin
  Running setup.py install for mccabe

  Running setup.py install for cffi
Traceback (most recent call last):
  File string, line 1, in module
  File /home/gk-dev/nova/.tox/py27/build/cffi/setup.py, line 94, in 
module
from setuptools import setup, Feature, Extension
ImportError: cannot import name Feature
Complete output from command /home/gk-dev/nova/.tox/py27/bin/python2.7 -c 
import 
setuptools;__file__='/home/gk-dev/nova/.tox/py27/build/cffi/setup.py';exec(compile(open(__file__).read().replace('\r\n',
 '\n'), __file__, 'exec')) install --record 
/tmp/pip-2sWKRK-record/install-record.txt --single-version-externally-managed 
--install-headers /home/gk-dev/nova/.tox/py27/include/site/python2.7:
Traceback (most recent call last):

  File string, line 1, in module

  File /home/gk-dev/nova/.tox/py27/build/cffi/setup.py, line 94, in module

from setuptools import setup, Feature, Extension

ImportError: cannot import name Feature


Cleaning up...
Command /home/gk-dev/nova/.tox/py27/bin/python2.7 -c import 
setuptools;__file__='/home/gk-dev/nova/.tox/py27/build/cffi/setup.py';exec(compile(open(__file__).read().replace('\r\n',
 '\n'), __file__, 'exec')) install --record 
/tmp/pip-2sWKRK-record/install-record.txt --single-version-externally-managed 
--install-headers /home/gk-dev/nova/.tox/py27/include/site/python2.7 failed 
with error code 1 in /home/gk-dev/nova/.tox/py27/build/cffi
Traceback (most recent call last):
  File .tox/py27/bin/pip, line 9, in module
load_entry_point('pip==1.5.4', 'console_scripts', 'pip')()
  File 
/home/gk-dev/nova/.tox/py27/local/lib/python2.7/site-packages/pip/__init__.py,
 line 148, in main
parser.print_help()
  File 
/home/gk-dev/nova/.tox/py27/local/lib/python2.7/site-packages/pip/basecommand.py,
 line 169, in main
log_file_fp.write(text)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 72: 
ordinal not in range(128)

ERROR: could not install deps [-r/home/gk-dev/nova/requirements.txt, 
-r/home/gk-dev/nova/test-requirements.txt]

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


Re: [openstack-dev] [nova][vmware] Locking: A can of worms

2014-03-08 Thread Gary Kotton
Hi,
I have provided a solution for the single node setup that. That is, we
make use of the nova lock utilities to provide locking so that that the
cached images will not be removed whilst an instance is spawned. I hope
that this will unblock the feature an enable us to continue with the FFE.
The reasons for this are as follow:
1. The feature can be disable if a user wishes
2. In the case the user wants to make use of multiple compute nodes we can
address the issues via configuration variables, that is, each compute node
can use a different cache directory on the datastore.
Thanks
Gary

On 3/7/14 11:03 PM, Vui Chiap Lam vuich...@vmware.com wrote:

Thanks Matt, good points raised here.

I think at minimum we should address the single-node case by
@synchronized-ing
all access to the image cache data on the datastore, in a way that is
fairly 
easy to reason about. Spawn failures are not desirable but acceptable in
edge
cases if a subsequent retry on same or different node can succeed. What
we need
to absolutely avoid is a partially deleted image cache directory rendering
future spawns impossible.

There are some non-elegant ways to work around the multi-node scenarios
if one
really has to (e.g. dedicating a different cache location for each node),
but 
i think the multi-node should get addressed at some point too.

There is distributing locking provisions in the a vSphere datastore for
files
in use (you cannot delete a disk used by a running VM, say). The image
cache as
implemented exists as a collection of files on a datastore, many of which
may
not be used by any process. Either that picture changes or we need to
adopt
some other means to achieve distributed locking.

Vui


- Original Message -
| From: Matthew Booth mbo...@redhat.com
| To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
| Sent: Friday, March 7, 2014 8:53:26 AM
| Subject: [openstack-dev] [nova][vmware] Locking: A can of worms
| 
| We need locking in the VMware driver. There are 2 questions:
| 
| 1. How much locking do we need?
| 2. Do we need single-node or multi-node locking?
| 
| I believe these are quite separate issues, so I'm going to try not to
| confuse them. I'm going to deal with the first question first.
| 
| In reviewing the image cache ageing patch, I came across a race
| condition between cache ageing and spawn(). One example of the race is:
| 
| Cache Ageingspawn()
| * Check timestamps
| * Delete timestamp
| * Check for image cache directory
| * Delete directory
| * Use image cache directory
| 
| This will cause spawn() to explode. There are various permutations of
| this. For example, the following are all possible:
| 
| * A simple failure of spawn() with no additional consequences.
| 
| * Calling volumeops.attach_disk_to_vm() with a vmdk_path that doesn't
| exist. It's not 100% clear to me that ReconfigVM_Task will throw an
| error in this case, btw, which would probably be bad.
| 
| * Leaving a partially deleted image cache directory which doesn't
| contain the base image. This would be really bad.
| 
| The last comes about because recursive directory delete isn't atomic,
| and may partially succeed, which is a tricky problem. However, in
| discussion, Gary also pointed out that directory moves are not atomic
| (see MoveDatastoreFile_Task). This is positively nasty. We already knew
| that spawn() races with itself to create an image cache directory, and
| we've hit this problem in practise. We haven't fixed the race, but we do
| manage it. The management relies on the atomicity of a directory move.
| Unfortunately it isn't atomic, which presents the potential problem of
| spawn() attempting to use an incomplete image cache directory. We also
| have the problem of 2 spawns using a linked clone image racing to create
| the same resized copy.
| 
| We could go through all of the above very carefully to assure ourselves
| that we've found all the possible failure paths, and that in every case
| the problems are manageable and documented. However, I would place a
| good bet that the above is far from a complete list, and we would have
| to revisit it in its entirety every time we touched any affected code.
| And that would be a lot of code.
| 
| We need something to manage concurrent access to resources. In all of
| the above cases, if we make the rule that everything which uses an image
| cache directory must hold a lock on it whilst using it, all of the above
| problems go away. Reasoning about their correctness becomes the
| comparatively simple matter of ensuring that the lock is used correctly.
| Note that we need locking in both the single and multi node cases,
| because even single node is multi-threaded.
| 
| The next question is whether that locking needs to be single node or
| multi node. Specifically, do we currently, or do we plan to, allow an
| architecture where 

[openstack-dev] [Nova client] gate-python-novaclient-pypy

2014-03-10 Thread Gary Kotton
Hi,
The client gate seems to be broken with the following error:


2014-03-10 
08:19:39.566http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_566
 |   Running setup.py install for python-mimeparse
2014-03-10 
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
 |
2014-03-10 
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
 |   Found existing installation: setuptools 2.2
2014-03-10 
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
 | Uninstalling setuptools:
2014-03-10 
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
 |   Successfully uninstalled setuptools
2014-03-10 
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
 |   Running setup.py install for mccabe
2014-03-10 
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
 | /usr/lib/pypy/lib-python/2.7/distutils/dist.py:267: UserWarning: Unknown 
distribution option: 'entry_points'
2014-03-10 
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
 |   warnings.warn(msg)
2014-03-10 
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
 | /usr/lib/pypy/lib-python/2.7/distutils/dist.py:267: UserWarning: Unknown 
distribution option: 'zip_safe'
2014-03-10 
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
 |   warnings.warn(msg)
2014-03-10 
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
 | usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
2014-03-10 
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
 |or: -c --help [cmd1 cmd2 ...]
2014-03-10 
08:19:39.567http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_567
 |or: -c --help-commands
2014-03-10 
08:19:39.568http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
 |or: -c cmd --help
2014-03-10 
08:19:39.568http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
 |
2014-03-10 
08:19:39.568http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
 | error: option --single-version-externally-managed not recognized
2014-03-10 
08:19:39.568http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
 | Complete output from command 
/home/jenkins/workspace/gate-python-novaclient-pypy/.tox/pypy/bin/pypy -c 
import setuptools, 
tokenize;__file__='/home/jenkins/workspace/gate-python-novaclient-pypy/.tox/pypy/build/mccabe/setup.py';exec(compile(getattr(tokenize,
 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec')) 
install --record /tmp/tmp.l53ekBaPmF/pip-5i1oDp-record/install-record.txt 
--single-version-externally-managed --compile --install-headers 
/home/jenkins/workspace/gate-python-novaclient-pypy/.tox/pypy/include/site/python2.7:
2014-03-10 
08:19:39.568http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
 | /usr/lib/pypy/lib-python/2.7/distutils/dist.py:267: UserWarning: Unknown 
distribution option: 'entry_points'
2014-03-10 
08:19:39.568http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
 |
2014-03-10 
08:19:39.568http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
 |   warnings.warn(msg)
2014-03-10 
08:19:39.568http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
 |
2014-03-10 
08:19:39.568http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
 | /usr/lib/pypy/lib-python/2.7/distutils/dist.py:267: UserWarning: Unknown 
distribution option: 'zip_safe'
2014-03-10 
08:19:39.568http://logs.openstack.org/74/67074/8/check/gate-python-novaclient-pypy/44c12e7/console.html#_2014-03-10_08_19_39_568
 |
2014-03-10 

Re: [openstack-dev] [nova] An analysis of code review in Nova

2014-03-24 Thread Gary Kotton
Regarding the spawn there are a number of patches up for review at the
moment - they are all mutually exclusive and hopefully will make the
process a lot smoother.
https://review.openstack.org/#/q/topic:bp/vmware-spawn-refactor,n,z
In addition to this we have a patch up for review with the OSLO
integration - https://review.openstack.org/#/c/70175/ (ideally it would be
best that this gets in first)
Thanks
Gary

On 3/22/14 8:03 PM, Chris Behrens cbehr...@codestud.com wrote:

I'd like to get spawn broken up sooner rather than later, personally. It
has additional benefits of being able to do better orchestration of
builds from conductor, etc.

On Mar 14, 2014, at 3:58 PM, Dan Smith d...@danplanet.com wrote:

 Just to answer this point, despite the review latency, please don't be
 tempted to think one big change will get in quicker than a series of
 little, easy to review, changes. All changes are not equal. A large
 change often scares me away to easier to review patches.
 
 Seems like, for Juno-1, it would be worth cancelling all non-urgent
 bug fixes, and doing the refactoring we need.
 
 I think the aim here should be better (and easier to understand) unit
 test coverage. Thats a great way to drive good code structure.
 
 Review latency will be directly affected by how good the refactoring
 changes are staged. If they are small, on-topic and easy to validate,
 they will go quickly. They should be linearized unless there are some
 places where multiple sequences of changes make sense (i.e. refactoring
 a single file that results in no changes required to others).
 
 As John says, if it's just a big change everything patch, or a ton of
 smaller ones that don't fit a plan or process, then it will be slow and
 painful (for everyone).
 
 +1 sounds like a good first step is to move to oslo.vmware
 
 I'm not sure whether I think that refactoring spawn would be better done
 first or second. My gut tells me that doing spawn first would mean that
 we could more easily validate the oslo refactors because (a) spawn is
 impossible to follow right now and (b) refactoring it to smaller methods
 should be fairly easy. The tests for spawn are equally hard to follow
 and refactoring it first would yield a bunch of more unit-y tests that
 would help us follow the oslo refactoring.
 
 However, it sounds like the osloificastion has maybe already started and
 that refactoring spawn will have to take a backseat to that.
 
 --Dan
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi
-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar
=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=q5RejnjmrSIFg0K7ua
AZbKHVqAKLHnVAB98J%2BszOfhw%3D%0As=1629f4e9008260c5f8ea577da1bdc69388dbe
fa3646803244df992a31d94bc96

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e
H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=q5RejnjmrSIFg0K7uaAZb
KHVqAKLHnVAB98J%2BszOfhw%3D%0As=1629f4e9008260c5f8ea577da1bdc69388dbefa36
46803244df992a31d94bc96


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


[openstack-dev] Stable/grizzly

2013-10-10 Thread Gary Kotton
Hi,
The gate is once again broken:

2013-10-10 05:15:05.036 | Traceback (most recent call last):

2013-10-10 05:15:05.036 |   File 
/home/jenkins/workspace/gate-nova-python26/nova/tests/test_api.py, line 389, 
in test_group_name_valid_length_security_group
2013-10-10 05:15:05.036 | self.expect_http()
2013-10-10 05:15:05.036 |   File 
/home/jenkins/workspace/gate-nova-python26/nova/tests/test_api.py, line 246, 
in expect_http
2013-10-10 05:15:05.037 | is_secure).AndReturn(self.http)
2013-10-10 05:15:05.037 |   File 
/home/jenkins/workspace/gate-nova-python26/.tox/py26/lib/python2.6/site-packages/mox.py,
 line 765, in __call__
2013-10-10 05:15:05.037 | return mock_method(*params, **named_params)
2013-10-10 05:15:05.038 |   File 
/home/jenkins/workspace/gate-nova-python26/.tox/py26/lib/python2.6/site-packages/mox.py,
 line 998, in __call__
2013-10-10 05:15:05.038 | self._checker.Check(params, named_params)
2013-10-10 05:15:05.038 |   File 
/home/jenkins/workspace/gate-nova-python26/.tox/py26/lib/python2.6/site-packages/mox.py,
 line 929, in Check
2013-10-10 05:15:05.039 | % (' '.join(sorted(still_needed
2013-10-10 05:15:05.039 | AttributeError: No values given for arguments: 
is_secure

Any ideas?

Thanks

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


Re: [openstack-dev] Stable/grizzly

2013-10-10 Thread Gary Kotton
Same on trunk!

From: Administrator gkot...@vmware.commailto:gkot...@vmware.com
Reply-To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, October 10, 2013 9:10 AM
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] Stable/grizzly

Hi,
The gate is once again broken:

2013-10-10 05:15:05.036 | Traceback (most recent call last):

2013-10-10 05:15:05.036 |   File 
/home/jenkins/workspace/gate-nova-python26/nova/tests/test_api.py, line 389, 
in test_group_name_valid_length_security_group
2013-10-10 05:15:05.036 | self.expect_http()
2013-10-10 05:15:05.036 |   File 
/home/jenkins/workspace/gate-nova-python26/nova/tests/test_api.py, line 246, 
in expect_http
2013-10-10 05:15:05.037 | is_secure).AndReturn(self.http)
2013-10-10 05:15:05.037 |   File 
/home/jenkins/workspace/gate-nova-python26/.tox/py26/lib/python2.6/site-packages/mox.py,
 line 765, in __call__
2013-10-10 05:15:05.037 | return mock_method(*params, **named_params)
2013-10-10 05:15:05.038 |   File 
/home/jenkins/workspace/gate-nova-python26/.tox/py26/lib/python2.6/site-packages/mox.py,
 line 998, in __call__
2013-10-10 05:15:05.038 | self._checker.Check(params, named_params)
2013-10-10 05:15:05.038 |   File 
/home/jenkins/workspace/gate-nova-python26/.tox/py26/lib/python2.6/site-packages/mox.py,
 line 929, in Check
2013-10-10 05:15:05.039 | % (' '.join(sorted(still_needed
2013-10-10 05:15:05.039 | AttributeError: No values given for arguments: 
is_secure

Any ideas?

Thanks

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


Re: [openstack-dev] Stable/grizzly

2013-10-10 Thread Gary Kotton
Hi,
The problem seems to be with the boto python library. I am not really familiar 
with this but I have seen this is the last – we may need to update the 
requirements again to exclude a specific version.
Thanks
Gary

From: Lingxian Kong anlin.k...@gmail.commailto:anlin.k...@gmail.com
Reply-To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, October 10, 2013 9:21 AM
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Stable/grizzly

Hi Gary:

Same problem with me. There may be some races between the parallelled unittests.


2013/10/10 Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com
Hi,
The gate is once again broken:

2013-10-10 05:15:05.036 | Traceback (most recent call last):

2013-10-10 05:15:05.036 |   File 
/home/jenkins/workspace/gate-nova-python26/nova/tests/test_api.py, line 389, 
in test_group_name_valid_length_security_group
2013-10-10 05:15:05.036 | self.expect_http()
2013-10-10 05:15:05.036 |   File 
/home/jenkins/workspace/gate-nova-python26/nova/tests/test_api.py, line 246, 
in expect_http
2013-10-10 05:15:05.037 | is_secure).AndReturn(self.http)
2013-10-10 05:15:05.037 |   File 
/home/jenkins/workspace/gate-nova-python26/.tox/py26/lib/python2.6/site-packages/mox.py,
 line 765, in __call__
2013-10-10 05:15:05.037 | return mock_method(*params, **named_params)
2013-10-10 05:15:05.038 |   File 
/home/jenkins/workspace/gate-nova-python26/.tox/py26/lib/python2.6/site-packages/mox.py,
 line 998, in __call__
2013-10-10 05:15:05.038 | self._checker.Check(params, named_params)
2013-10-10 05:15:05.038 |   File 
/home/jenkins/workspace/gate-nova-python26/.tox/py26/lib/python2.6/site-packages/mox.py,
 line 929, in Check
2013-10-10 05:15:05.039 | % (' '.join(sorted(still_needed
2013-10-10 05:15:05.039 | AttributeError: No values given for arguments: 
is_secure

Any ideas?

Thanks

Gary

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




--

Lingxian Kong
Huawei Technologies Co.,LTD.
IT Product Line CloudOS PDU
China, Xi'an
Mobile: +86-18602962792
Email: konglingx...@huawei.commailto:konglingx...@huawei.com; 
anlin.k...@gmail.commailto:anlin.k...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Jekins failed for all nova submit due to library boto change method signature

2013-10-10 Thread Gary Kotton
Hi,
I am dealing this with this – please see https://review.openstack.org/50904
Thanks
Gary

From: Chang Bo Guo guoc...@cn.ibm.commailto:guoc...@cn.ibm.com
Reply-To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, October 10, 2013 2:15 PM
To: 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova] Jekins failed for all nova submit due to 
library boto change method signature

Hi ALL,

Recently, Jekins build failed for all nova submit. This is due to boto changed 
method signature.
get_http_connection(host,is_secure)--- get_http_connection(host, port, 
is_secure)
see 
https://boto.readthedocs.org/en/latest/ref/boto.html#boto.connection.AWSAuthConnection.get_http_connection

I open a bug https://bugs.launchpad.net/nova/+bug/1237825, and I'm not boto 
expert but submit a temporary fix for this 
https://review.openstack.org/#/c/50873/
Hope this can be merged or others can help fix this urgent issue ASAP.

Best Regards
---
Eric Guo  郭长波
Cloud Solutions and Openstack Development
China System  Technology Laboratories (CSTL), IBM
Tel:86-10-82452019
Internet Mail: guoc...@cn.ibm.commailto:guoc...@cn.ibm.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Openstack-stable-maint] Stable/grizzly

2013-10-10 Thread Gary Kotton
Trunk - https://review.openstack.org/50904
Stable/Grizzly - https://review.openstack.org/#/c/50905/
There is an alternative patch - https://review.openstack.org/#/c/50873/7
I recall seeing the same problem a few month ago and the bot version was
excluded - not sure why the calling code was not updated. Maybe someone
who is familiar with that can chime in.
Thanks
Gary

On 10/10/13 12:20 PM, Alan Pevec ape...@gmail.com wrote:

2013/10/10 Gary Kotton gkot...@vmware.com:
 The problem seems to be with the boto python library. I am not really
 familiar with this but I have seen this is the last ­ we may need to
update
 the requirements again to exclude a specific version.

Yeah, it's bad boto update again:
-boto==2.13.3
+boto==2.14.0

Let's cap it as a quickfix, it's stable/grizzly freeze today so we
need gates fixed asap!

Cheers,
Alan

___
Openstack-stable-maint mailing list
openstack-stable-ma...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint


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


Re: [openstack-dev] [Nova] Icehouse design summit proposal deadline

2013-10-12 Thread Gary Kotton
FYI

On 10/10/13 9:43 PM, Russell Bryant rbry...@redhat.com wrote:

Greetings,

We already have more proposals for the Nova design summit track than
time slots.  Please get your proposals in as soon as possible, and
ideally no later than 1 week from today - Thursday, October 17.  At that
point we will be focusing on putting a schedule together in order to
have the schedule completed at least a week in advance of the summit.

Thanks!

-- 
Russell Bryant

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


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


Re: [openstack-dev] [nova] Looking for clarification on the diagnostics API

2013-10-12 Thread Gary Kotton
Yup, it seems to be hypervisor specific. I have added in the Vmware support 
following you correcting in the Vmware driver.
Thanks
Gary

From: Matt Riedemann mrie...@us.ibm.commailto:mrie...@us.ibm.com
Reply-To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, October 10, 2013 10:17 PM
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Looking for clarification on the 
diagnostics API

Looks like this has been brought up a couple of times:

https://lists.launchpad.net/openstack/msg09138.html

https://lists.launchpad.net/openstack/msg08555.html

But they seem to kind of end up in the same place I already am - it seems to be 
an open-ended API that is hypervisor-specific.



Thanks,

MATT RIEDEMANN
Advisory Software Engineer
Cloud Solutions and OpenStack Development


Phone: 1-507-253-7622 | Mobile: 1-507-990-1889
E-mail: mrie...@us.ibm.commailto:mrie...@us.ibm.com
[cid:_1_0B6881F80B687C640069F4B286257C00]

3605 Hwy 52 N
Rochester, MN 55901-1407
United States






From:Matt Riedemann/Rochester/IBM
To:OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org,
Date:10/10/2013 02:12 PM
Subject:[nova] Looking for clarification on the diagnostics API



Tempest recently got some new tests for the nova diagnostics API [1] which 
failed when I was running against the powervm driver since it doesn't implement 
that API.  I started looking at other drivers that did and found that libvirt, 
vmware and xenapi at least had code for the get_diagnostics method.  I found 
that the vmware driver was re-using it's get_info method for get_diagnostics 
which led to bug 1237622 [2] but overall caused some confusion about the 
difference between the compute driver's get_info and get_diagnostics mehods.  
It looks like get_info is mainly just used to get the power_state of the 
instance.

First, the get_info method has a nice docstring for what it needs returned [3] 
but the get_diagnostics method doesn't [4].  From looking at the API docs [5], 
the diagnostics API basically gives an example of values to get back which is 
completely based on what the libvirt driver returns.  Looking at the xenapi 
driver code, it looks like it does things a bit differently than the libvirt 
driver (maybe doesn't return the exact same keys, but it returns information 
based on what Xen provides).

I'm thinking about implementing the diagnostics API for the powervm driver but 
I'd like to try and get some help on defining just what should be returned from 
that call.  There are some IVM commands available to the powervm driver for 
getting hardware resource information about an LPAR so I think I could 
implement this pretty easily.

I think it basically comes down to providing information about the processor, 
memory, storage and network interfaces for the instance but if anyone has more 
background information on that API I'd like to hear it.

[1] 
https://github.com/openstack/tempest/commit/da0708587432e47f85241201968e6402190f0c5d
[2] https://bugs.launchpad.net/nova/+bug/1237622
[3] https://github.com/openstack/nova/blob/2013.2.rc1/nova/virt/driver.py#L144
[4] https://github.com/openstack/nova/blob/2013.2.rc1/nova/virt/driver.py#L299
[5] http://paste.openstack.org/show/48236/



Thanks,

MATT RIEDEMANN
Advisory Software Engineer
Cloud Solutions and OpenStack Development


Phone: 1-507-253-7622 | Mobile: 1-507-990-1889
E-mail: mrie...@us.ibm.commailto:mrie...@us.ibm.com
[cid:_1_0B682BA80B6826140069F4B286257C00]

3605 Hwy 52 N
Rochester, MN 55901-1407
United States



attachment: ATT1..gifattachment: ATT2..gif___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Looking for clarification on the diagnostics API

2013-10-12 Thread Gary Kotton
Hi,
I agree with Matt here. This is not broad enough. One option is to have a 
tempest class that overrides for various backend plugins. Then the test can be 
haredednd for each driver. I am not sure if that is something that has been 
talked about.
Thanks
Gary

From: Matt Riedemann mrie...@us.ibm.commailto:mrie...@us.ibm.com
Reply-To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Sunday, October 13, 2013 6:13 AM
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Looking for clarification on the 
diagnostics API

There is also a tempest patch now to ease some of the libvirt-specific keys 
checked in the new diagnostics tests there:

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

To relay some of my concerns that I put in that patch:

I'm not sure how I feel about this. It should probably be more generic but I 
think we need more than just a change in tempest to enforce it, i.e. we should 
have a nova patch that changes the doc strings for the abstract compute driver 
method to specify what the minimum keys are for the info returned, maybe a doc 
api sample change, etc?

For reference, here is the mailing list post I started on this last week:

http://lists.openstack.org/pipermail/openstack-dev/2013-October/016385.html

There are also docs here (these examples use xen and libvirt):

http://docs.openstack.org/grizzly/openstack-compute/admin/content/configuring-openstack-compute-basics.html

And under procedure 4.4 here:

http://docs.openstack.org/admin-guide-cloud/content/ch_introduction-to-openstack-compute.html#section_manage-the-cloud

=

I also found this wiki page related to metering and the nova diagnostics API:

https://wiki.openstack.org/wiki/EfficientMetering/FutureNovaInteractionModel

So it seems like if at some point this will be used with ceilometer it should 
be standardized a bit which is what the Tempest part starts but I don't want it 
to get lost there.


Thanks,

MATT RIEDEMANN
Advisory Software Engineer
Cloud Solutions and OpenStack Development


Phone: 1-507-253-7622 | Mobile: 1-507-990-1889
E-mail: mrie...@us.ibm.commailto:mrie...@us.ibm.com
[cid:_1_09B39E1009B3987C0011B74C86257C03]

3605 Hwy 52 N
Rochester, MN 55901-1407
United States






From:Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com
To:OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org,
Date:10/12/2013 01:42 PM
Subject:Re: [openstack-dev] [nova] Looking for clarification on the 
diagnostics API




Yup, it seems to be hypervisor specific. I have added in the Vmware support 
following you correcting in the Vmware driver.
Thanks
Gary

From: Matt Riedemann mrie...@us.ibm.commailto:mrie...@us.ibm.com
Reply-To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, October 10, 2013 10:17 PM
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Looking for clarification on the 
diagnostics API

Looks like this has been brought up a couple of times:

https://lists.launchpad.net/openstack/msg09138.html

https://lists.launchpad.net/openstack/msg08555.html

But they seem to kind of end up in the same place I already am - it seems to be 
an open-ended API that is hypervisor-specific.



Thanks,

MATT RIEDEMANN
Advisory Software Engineer
Cloud Solutions and OpenStack Development


Phone: 1-507-253-7622 | Mobile: 1-507-990-1889
E-mail: mrie...@us.ibm.commailto:mrie...@us.ibm.com
[cid:_1_09BCCED809BCCAD80011B74C86257C03]

3605 Hwy 52 N
Rochester, MN 55901-1407
United States







From:Matt Riedemann/Rochester/IBM
To:OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org,
Date:10/10/2013 02:12 PM
Subject:[nova] Looking for clarification on the diagnostics API



Tempest recently got some new tests for the nova diagnostics API [1] which 
failed when I was running against the powervm driver since it doesn't implement 
that API.  I started looking at other drivers that did and found that libvirt, 
vmware and xenapi at least had code for the get_diagnostics method.  I found 
that the vmware driver was re-using it's get_info method for get_diagnostics 
which led to bug 1237622 [2] but overall caused some confusion about the 
difference between the compute driver's get_info and get_diagnostics mehods.  
It looks like get_info is mainly just used to get the power_state of the 
instance.

First, the get_info method has a nice docstring for what it needs returned [3] 
but the get_diagnostics method

Re: [openstack-dev] Scheduler meeting and Icehouse Summit

2013-10-16 Thread Gary Kotton
Hi,
I agree with Phil. This has been on the agenda of the scheduling meetings
for over a month now.
Thanks
Gary

On 10/15/13 2:40 PM, Day, Phil philip@hp.com wrote:

Hi Alex,

My understanding is that the 17th is the deadline and that Russell needs
to be planning the sessions from that point onwards.  If we delay in
giving him our suggestions until the 22nd I think it would be too late.
 We've had weeks if not months now of discussing possible scheduler
sessions, I really don't see why we can't deliver a recommendation on how
best to fit into the 3 committed slots on or before the 17th.

Phil

On Mon, Oct 14, 2013 at 10:56 AM, Alex Glikson glik...@il.ibm.com wrote:
 IMO, the three themes make sense, but I would suggest waiting until
 the submission deadline and discuss at the following IRC meeting on the
22nd.
 Maybe there will be more relevant proposals to consider.

 Regards,
 Alex

 P.S. I plan to submit a proposal regarding scheduling policies, and
 maybe one more related to theme #1 below



 From:Day, Phil philip@hp.com
 To:OpenStack Development Mailing List
 openstack-dev@lists.openstack.org,
 Date:14/10/2013 06:50 PM
 Subject:Re: [openstack-dev] Scheduler meeting and Icehouse
Summit
 



 Hi Folks,

 In the weekly scheduler meeting we've been trying to pull together a
 consolidated list of Summit sessions so that we can find logical
 groupings and make a more structured set of sessions for the limited
 time available at the summit.

 https://etherpad.openstack.org/p/IceHouse-Nova-Scheduler-Sessions

 With the deadline for sessions being this Thursday 17th, tomorrows IRC
 meeting is the last chance to decide which sessions we want to combine /
 prioritize.Russell has indicated that a starting assumption of three
 scheduler sessions is reasonable, with any extras depending on what
 else is submitted.

 I've matched the list on the Either pad to submitted sessions below,
 and added links to any other proposed sessions that look like they are
related.


 1) Instance Group Model and API
Session Proposal:
 http://summit.openstack.org/cfp/details/190

 2) Smart Resource Placement:
   Session Proposal:
 http://summit.openstack.org/cfp/details/33
Possibly related sessions:
Resource
 optimization service for nova
 (http://summit.openstack.org/cfp/details/201)

 3) Heat and Scheduling and Software, Oh My!:
 Session Proposal:
 http://summit.openstack.org/cfp/details/113

 4) Generic Scheduler Metrics and Celiometer:
 Session Proposal:
 http://summit.openstack.org/cfp/details/218
 Possibly related sessions:  Making Ceilometer and Nova
 play nice  http://summit.openstack.org/cfp/details/73

 5) Image Properties and Host Capabilities
 Session Proposal:  NONE

 6) Scheduler Performance:
 Session Proposal:  NONE
 Possibly related Sessions: Rethinking Scheduler Design
 http://summit.openstack.org/cfp/details/34

 7) Scheduling Across Services:
 Session Proposal: NONE

 8) Private Clouds:
 Session Proposal:
 http://summit.openstack.org/cfp/details/228

 9) Multiple Scheduler Policies:
 Session Proposal: NONE


 The proposal from last weeks meeting was to use the three slots for:
 - Instance Group Model and API   (1)
 - Smart Resource Placement (2)
 - Performance (6)

 However, at the moment there doesn't seem to be a session proposed to
 cover the performance work ?

 It also seems to me that the Group Model and Smart Placement are
 pretty closely linked along with (3) (which says it wants to combine 1
  2 into the same topic) , so if we only have three slots available
then these look like
 logical candidates for consolidating into a single session.That
would
 free up a session to cover the generic metrics (4) and Ceilometer -
 where a lot of work in Havana stalled because we couldn't get a
 consensus on the way forward.  The third slot would be kept for
 performance - which based on the lively debate in the scheduler
meetings I'm assuming will still be submitted
 as a session.Private Clouds isn't really a scheduler topic, so I
suggest
 it takes its chances as a general session.  Hence my revised proposal
 for the three slots is:

  i) Group Scheduling / Smart Placement / Heat and Scheduling  (1),
 (2), (3),  (7)
 - How do you schedule something more complex that a
 single VM ?

 ii) Generalized scheduling metrics / celiometer integration (4)
 - How do we extend the set of resources a scheduler
 can use to make its decisions ?
 - How do we make this work with  / compatible with
 Celiometer ?

 iii) Scheduler Performance (6)

 In that way we will at least give airtime to all of the topics. If
a 4th
 scheduler slot becomes available 

Re: [openstack-dev] [Nova] VMWare Mine Sweeper, Congrats!

2013-10-19 Thread Gary Kotton
Kudos to Sreeram. Great work here.

From: Sreeram Yerrapragada 
syerraprag...@vmware.commailto:syerraprag...@vmware.com
Reply-To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Saturday, October 19, 2013 1:29 AM
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] VMWare Mine Sweeper, Congrats!

We had some infrastructure issues in the morning and went back to silent mode. 
I just re-triggered tempest run for your patchset. Also note that until we 
stabilize our CI infrastructure you would only be seeing postings from vmware 
minesweeper for passed builds. For failed build we will manually update it on 
the review.

Thanks
Sreeram


From: Yaguang Tang 
yaguang.t...@canonical.commailto:yaguang.t...@canonical.com
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Sent: Friday, October 18, 2013 8:59:19 AM
Subject: Re: [openstack-dev] [Nova] VMWare Mine Sweeper, Congrats!

How can I enable or trigger Mine Sweeper for VMware related patches?  I have 
update a patch about VMware driver today  
https://review.openstack.org/#/c/51793/ . but haven't seen any posting results .


2013/10/18 Sean Dague s...@dague.netmailto:s...@dague.net
On 10/17/2013 02:29 PM, Dan Smith wrote:
This system is running tempest against a VMWare deployment and posting
the results publicly.  This is really great progress.  It will go a long
way in helping reviewers be more confident in changes to this driver.

This is huge progress, congrats and thanks to the VMware team for making
this happen! There is really no substitute for the value this will
provide for overall quality.

Agreed. Nice job guys! It's super cool to now see SmokeStack and Mine Sweeper 
posting back on patches.

Tip of the hat to the VMWare team for pulling this together so quickly.

-Sean

--
Sean Dague
http://dague.net


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



--
Tang Yaguang

Canonical Ltd. | www.ubuntu.comhttp://www.ubuntu.com/ | 
www.canonical.comhttp://www.canonical.com/
Mobile:  +86 152 1094 6968
gpg key: 0x187F664F


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

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


[openstack-dev] [nova] resource tracking

2013-10-21 Thread Gary Kotton
Hi,
I have encountered a few issues regarding the resource tracking and hopefully 
someone can help clarify here. From what I understand we just seem to ignore 
the actual used disk and memory from the hypervisor and calculate it according 
to the allocated instances. For example, if the hypervisor has cached images or 
volume support, then this disk usage is ignored.
I have posted https://review.openstack.org/#/c/52900/ but I am not 100% sure 
that this is the correct way of addressing this (here we need to ensure that 
the hypervisor is not returning the disk spaces used by instances, similarly 
with memory)
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Nova] Stable/Havana Gate broken

2013-10-24 Thread Gary Kotton
Hi,
The gate for stable Hanava is broken in Nova with the following error:


 ==
2013-10-24 
12:48:35.629http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_629
 | FAIL: setUpClass 
(tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern)
2013-10-24 
12:48:35.629http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_629
 | setUpClass (tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern)
2013-10-24 
12:48:35.629http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_629
 | --
2013-10-24 
12:48:35.629http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_629
 | _StringException: Traceback (most recent call last):
2013-10-24 
12:48:35.629http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_629
 |   File tempest/scenario/manager.py, line 204, in setUpClass
2013-10-24 
12:48:35.629http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_629
 | cls.manager = OfficialClientManager(username, password, tenant_name)
2013-10-24 
12:48:35.630http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_630
 |   File tempest/scenario/manager.py, line 69, in __init__
2013-10-24 
12:48:35.630http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_630
 | tenant_name)
2013-10-24 
12:48:35.630http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_630
 |   File tempest/scenario/manager.py, line 101, in _get_compute_client
2013-10-24 
12:48:35.630http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_630
 | http_log_debug=True)
2013-10-24 
12:48:35.630http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_630
 |   File /opt/stack/new/python-novaclient/novaclient/client.py, line 450, in 
Client
2013-10-24 
12:48:35.630http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_630
 | client_class = get_client_class(version)
2013-10-24 
12:48:35.631http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_631
 |   File /opt/stack/new/python-novaclient/novaclient/client.py, line 446, in 
get_client_class
2013-10-24 
12:48:35.631http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_631
 | return utils.import_class(client_path)
2013-10-24 
12:48:35.631http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_631
 |   File /opt/stack/new/python-novaclient/novaclient/utils.py, line 336, in 
import_class
2013-10-24 
12:48:35.631http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_631
 | __import__(mod_str)
2013-10-24 
12:48:35.631http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_631
 |   File /opt/stack/new/python-novaclient/novaclient/v1_1/__init__.py, line 
17, in module
2013-10-24 
12:48:35.631http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_631
 | from novaclient.v1_1.client import Client   # noqa
2013-10-24 
12:48:35.631http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_631
 |   File /opt/stack/new/python-novaclient/novaclient/v1_1/client.py, line 
18, in module
2013-10-24 
12:48:35.632http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_632
 | from novaclient.v1_1 import agents
2013-10-24 
12:48:35.632http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_632
 |   File /opt/stack/new/python-novaclient/novaclient/v1_1/agents.py, line 
22, in module
2013-10-24 
12:48:35.632http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_632
 | from novaclient import base
2013-10-24 
12:48:35.632http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_632
 |   File /opt/stack/new/python-novaclient/novaclient/base.py, line 166, in 
module
2013-10-24 

Re: [openstack-dev] [Nova] Blueprint review process

2013-10-24 Thread Gary Kotton


On 10/24/13 4:46 PM, Dan Smith d...@danplanet.com wrote:

 In the last meeting we discussed an idea that I think is worth trying at
 least for icehouse-1 to see if we like it or not.  The idea is that
 *every* blueprint starts out at a Low priority, which means best
 effort, but no promises.  For a blueprint to get prioritized higher, it
 should have 2 nova-core members signed up to review the resulting code.

Huge +1 to this. I'm in favor of the whole plan, but specifically the
prioritization piece is very important, IMHO.

I too am in favor of the idea. It is just not clear how 2 Nova cores will
be signed up.


--Dan

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


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


Re: [openstack-dev] [Nova] Stable/Havana Gate broken

2013-10-24 Thread Gary Kotton
Thanks for doing this.
Gary

From: Joe Gordon joe.gord...@gmail.commailto:joe.gord...@gmail.com
Reply-To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, October 24, 2013 9:48 PM
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] Stable/Havana Gate broken

This is being tracked in bug https://bugs.launchpad.net/tempest/+bug/1244055 
and a fix is working its way through the gate now 
(https://review.openstack.org/#/c/53699/)


On Thu, Oct 24, 2013 at 2:51 PM, Gary Kotton 
gkot...@vmware.commailto:gkot...@vmware.com wrote:
Hi,
The gate for stable Hanava is broken in Nova with the following error:


 ==
2013-10-24 
12:48:35.629http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_629
 | FAIL: setUpClass 
(tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern)
2013-10-24 
12:48:35.629http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_629
 | setUpClass (tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern)
2013-10-24 
12:48:35.629http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_629
 | --
2013-10-24 
12:48:35.629http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_629
 | _StringException: Traceback (most recent call last):
2013-10-24 
12:48:35.629http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_629
 |   File tempest/scenario/manager.py, line 204, in setUpClass
2013-10-24 
12:48:35.629http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_629
 | cls.manager = OfficialClientManager(username, password, tenant_name)
2013-10-24 
12:48:35.630http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_630
 |   File tempest/scenario/manager.py, line 69, in __init__
2013-10-24 
12:48:35.630http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_630
 | tenant_name)
2013-10-24 
12:48:35.630http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_630
 |   File tempest/scenario/manager.py, line 101, in _get_compute_client
2013-10-24 
12:48:35.630http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_630
 | http_log_debug=True)
2013-10-24 
12:48:35.630http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_630
 |   File /opt/stack/new/python-novaclient/novaclient/client.py, line 450, in 
Client
2013-10-24 
12:48:35.630http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_630
 | client_class = get_client_class(version)
2013-10-24 
12:48:35.631http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_631
 |   File /opt/stack/new/python-novaclient/novaclient/client.py, line 446, in 
get_client_class
2013-10-24 
12:48:35.631http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_631
 | return utils.import_class(client_path)
2013-10-24 
12:48:35.631http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_631
 |   File /opt/stack/new/python-novaclient/novaclient/utils.py, line 336, in 
import_class
2013-10-24 
12:48:35.631http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_631
 | __import__(mod_str)
2013-10-24 
12:48:35.631http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_631
 |   File /opt/stack/new/python-novaclient/novaclient/v1_1/__init__.py, line 
17, in module
2013-10-24 
12:48:35.631http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_631
 | from novaclient.v1_1.client import Client   # noqa
2013-10-24 
12:48:35.631http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_631
 |   File /opt/stack/new/python-novaclient/novaclient/v1_1/client.py, line 
18, in module
2013-10-24 
12:48:35.632http://logs.openstack.org/95/53595/1/check/check-tempest-devstack-vm-full/14c606f/console.html#_2013-10-24_12_48_35_632
 | from

[openstack-dev] Stable backports

2013-10-27 Thread Gary Kotton
Hi,
In the case of stable back ports which have Fixes bug: #XYZ we will have to 
change this to the new format Closes-bug: #XYZ. Any thoughts on this?
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][scheduler] Instance Group Model and APIs - Updated document with an example request payload

2013-10-30 Thread Gary Kotton


From: Alex Glikson glik...@il.ibm.commailto:glik...@il.ibm.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, October 30, 2013 12:32 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova][scheduler] Instance Group Model and APIs - 
Updated document with an example request payload

Andrew Laski andrew.la...@rackspace.commailto:andrew.la...@rackspace.com 
wrote on 29/10/2013 11:14:03 PM:
 [...]
 Having Nova call into Heat is backwards IMO.  If there are specific
 pieces of information that Nova can expose, or API capabilities to help
 with orchestration/placement that Heat or some other service would like
 to use then let's look at that.  Nova has placement concerns that extend
 to finding a capable hypervisor for the VM that someone would like to
 boot, and then just slightly beyond.

+1

[Gary Kotton] When we proposed the initial VM ensembles this was one of the 
option that was considered. The guys from Heat did not like this approach. I 
like the idea and see it as something plumbable, for example like the 
networking module. This can be a pluggable scheduling interface that has a 
global picture of all of the systems resources.

  If there are higher level
 decisions to be made about placement decisions I think that belongs
 outside of Nova, and then just tell Nova where to put it.

I wonder whether it is possible to find an approach that takes into account 
cross-resource placement considerations (VM-to-VM communicating over the 
application network, or VM-to-volume communicating over storage network), but 
does not require delivering all the intimate details of the entire environment 
to a single place -- which probably can not be either of 
Nova/Cinder/Neutron/etc.. but can we still use the individual schedulers in 
each of them with partial view of the environment to drive a placement decision 
which is consistently better than random?

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


[openstack-dev] [nova] Closes-Bug and Launchpad

2013-10-31 Thread Gary Kotton
Hi,
Over the last few days I have noticed that bug fixes posted to gerrit are not 
updated in Launchpad. Am I doing something wrong? I think that the commit 
message is the correct format: Closes-Bug: #bug number.
Any ideas?
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] Configuration validation

2013-11-11 Thread Gary Kotton
Hi,
I think that John has a very valid point. My understanding from the
session was that this should be a stand alone tool that will also work
across services, that is, if neutron is configured then it will check that
the neutron credentials are correct.
Thanks
Gary

On 11/11/13 1:55 PM, John Garbutt j...@johngarbutt.com wrote:

I like the idea of a more general config validation phase to help
people when first starting out.

My worry is that it would slow down the starting back up of servers
for people deploying their code using CI, where the have already
verified their configuration. But maybe its so fast I don't care, but
I just felt I should raise that.

John

On 11 November 2013 11:44, Nikola Đipanov ndipa...@redhat.com wrote:
 Hey all,

 During the summit session on the the VMWare driver roadmap, a topic of
 validating the passed configuration prior to starting services came up
 (see [1] for more detail on how it's connected to that specific topic).

 Several ideas were thrown around during the session mostly documented in
 [1].

 There are a few more cases when something like this could be useful (see
 bug [2] and related patch [3]), and I was wondering if a slightly
 different approach might be useful. For example use an already existing
 validation hook in the service class [4] to call into a validation
 framework that will potentially stop the service with proper
 logging/notifications. The obvious benefit would be that there is no
 pre-run required from the user, and the danger of running a
 misconfigured stack is smaller.

 Since there is already a blueprint raised based on the etherpad [1]- I
 am bringing this up here so that we can agree on the approach, before
 raising another one to solve the same problem.

 Thanks,

 Nikola

 [1] https://etherpad.openstack.org/p/T4tQMQf5uS
 [2] https://bugs.launchpad.net/nova/+bug/1243614
 [3] https://review.openstack.org/#/c/53303/
 [4] 
http://git.openstack.org/cgit/openstack/nova/tree/nova/service.py#n283

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

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

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


Re: [openstack-dev] [qa] Policy on spelling and grammar

2013-11-11 Thread Gary Kotton
I am in favor/favour of the -1 with suggestions on what to change. The
more input we can provide on a review the better.
Thanks
Gary

On 11/11/13 8:21 PM, Collins, Sean (Contractor)
sean_colli...@cable.comcast.com wrote:

As long as the -1's include a correction that can be copied
and pasted, I think they're OK.

I know I would be grateful if someone were to
proofread my work, if I had to document in a second-language.

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


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


Re: [openstack-dev] Problems with devstack installation

2013-11-13 Thread Gary Kotton
Please delete the file - /usr/bin/nova-rootwrap (this code was updated to use 
the openstack common root wrap code).
I also hit the same issue yesterday
Thanks
Gary

From: Sullivan, Jon Paul 
jonpaul.sulli...@hp.commailto:jonpaul.sulli...@hp.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, November 13, 2013 5:02 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Problems with devstack installation


From: Telles Nobrega [mailto:tellesnobr...@gmail.com]


Hi, I'm trying to setup a dev environment, but I'm getting this error on nova 
http://paste.openstack.org/show/52392/https://urldefense.proofpoint.com/v1/url?u=http://paste.openstack.org/show/52392/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=5bAz1L03WBCey3wJPRpIh7UBTgV838HPW%2Fh2TPhWgtU%3D%0As=a840e8fcf6b472a19e342db259351af16c5a1a9d2b9de78efcac0782e0ba31e6
 can anyone give me a hint on how to work this out?

I just saw the same problem.  I found that in my case the 2012.1 (Essex!) 
packages were installed from the Ubuntu apt repositories, which contained an 
outdated nova-rootwrap in /usr/bin/ that was using the wrong import statement.  
The nova-rootwrap built by devstack was in /usr/local/bin/ and so I copied that 
in place of the incorrect one in /usr/bin/.

Yes, this is a massive hack, but it did work for me for a similar error in the 
scheduler.

thanks

--
--
Telles Mota Vidal Nobrega
Developer at PulsarOpenStack Project - HP/LSD-UFCG

Thanks,
Jon-Paul Sullivan:)Cloud Services - @hpcloud

Postal Address: Hewlett-Packard Galway Limited, Ballybrit Business Park, Galway.
Registered Office: Hewlett-Packard Galway Limited, 63-74 Sir John Rogerson's 
Quay, Dublin 2.
Registered Number: 361933

The contents of this message and any attachments to it are confidential and may 
be legally privileged. If you have received this message in error you should 
delete it from your system immediately and advise the sender.

To any recipient of this message within HP, unless otherwise stated, you should 
consider this message and attachments as HP CONFIDENTIAL.

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


[openstack-dev] [stable/havana] gate broken

2013-11-17 Thread Gary Kotton
Hi,
The gating for the stable version is broken when the running the neutron gate. 
Locally this works but the gate has problem. All of the services are up and 
running correctly. There are some exceptions with the ceilometer service but 
that is not related to the neutron gating.

The error message is as follows:
2013-11-17 
11:00:05.855http://logs.openstack.org/46/56746/1/check/check-tempest-devstack-vm-neutron/a02894b/console.html#_2013-11-17_11_00_05_855
 | 2013-11-17 11:00:05

2013-11-17 
11:00:17.239http://logs.openstack.org/46/56746/1/check/check-tempest-devstack-vm-neutron/a02894b/console.html#_2013-11-17_11_00_17_239
 | Process leaked file descriptors. See 
http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for 
more information
2013-11-17 
11:00:17.437http://logs.openstack.org/46/56746/1/check/check-tempest-devstack-vm-neutron/a02894b/console.html#_2013-11-17_11_00_17_437
 | Build step 'Execute shell' marked build as failure
2013-11-17 
11:00:19.129http://logs.openstack.org/46/56746/1/check/check-tempest-devstack-vm-neutron/a02894b/console.html#_2013-11-17_11_00_19_129
 | [SCP] Connecting to static.openstack.org

Thanks

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


Re: [openstack-dev] [stable/havana] gate broken

2013-11-17 Thread Gary Kotton
Thanks. Looks like something fishy with tempest. When I just run neutron
everything is well and fine.

On 11/17/13 5:50 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote:



On Sunday, November 17, 2013 7:46:39 AM, Gary Kotton wrote:
 Hi,
 The gating for the stable version is broken when the running the
 neutron gate. Locally this works but the gate has problem. All of the
 services are up and running correctly. There are some exceptions with
 the ceilometer service but that is not related to the neutron gating.

 The error message is as follows:
 2013-11-17 11:00:05.855
 
https://urldefense.proofpoint.com/v1/url?u=http://logs.openstack.org/46/
56746/1/check/check-tempest-devstack-vm-neutron/a02894b/console.html%23_2
013-11-17_11_00_05_855k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NP
ZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=VL2%2F41a4nc9qu2UHN5inNr9%2FGGz
5fBDhLKNRNs4pcNw%3D%0As=863f07cf06a33e05b6b0343fd1d72f51124f5a4b4812e758
e9c677b24759a2e0
 | 2013-11-17 11:00:05
 2013-11-17 11:00:17.239
https://urldefense.proofpoint.com/v1/url?u=http://logs.openstack.org/46/
56746/1/check/check-tempest-devstack-vm-neutron/a02894b/console.html%23_2
013-11-17_11_00_17_239k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NP
ZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=VL2%2F41a4nc9qu2UHN5inNr9%2FGGz
5fBDhLKNRNs4pcNw%3D%0As=bf4edc850a2f4350b3d5ae1374e2fd518d2c065fa17cbf3d
bbf00a753e556e26  | Process leaked file descriptors.
Seehttp://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+bui
ld  for more information
 2013-11-17 11:00:17.437
https://urldefense.proofpoint.com/v1/url?u=http://logs.openstack.org/46/
56746/1/check/check-tempest-devstack-vm-neutron/a02894b/console.html%23_2
013-11-17_11_00_17_437k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NP
ZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=VL2%2F41a4nc9qu2UHN5inNr9%2FGGz
5fBDhLKNRNs4pcNw%3D%0As=918eca2e42d056e435c956c540ad22266272db674ec4cded
e82d5a286b072190  | Build step 'Execute shell' marked build as failure
 2013-11-17 11:00:19.129
https://urldefense.proofpoint.com/v1/url?u=http://logs.openstack.org/46/
56746/1/check/check-tempest-devstack-vm-neutron/a02894b/console.html%23_2
013-11-17_11_00_19_129k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NP
ZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=VL2%2F41a4nc9qu2UHN5inNr9%2FGGz
5fBDhLKNRNs4pcNw%3D%0As=542399fe0cb38aaee9ab1d272370f3e721010032e518b30d
b50f63f5161f16a8  | [SCP] Connecting to static.openstack.org
 Thanks
 Gary


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi
-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar
=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=VL2%2F41a4nc9qu2UH
N5inNr9%2FGGz5fBDhLKNRNs4pcNw%3D%0As=4af7d1dfeb1ddcba19ac6d0d17b8aab58f1
c37ce4a335aadbcb19be7f9b1e437

I've seen this fail on at least two stable/havana patches in nova
today, so I opened this bug:

https://urldefense.proofpoint.com/v1/url?u=https://bugs.launchpad.net/open
stack-ci/%2Bbug/1252024k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NP
ZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=VL2%2F41a4nc9qu2UHN5inNr9%2FGGz5
fBDhLKNRNs4pcNw%3D%0As=028348b32601b6806fc8e7087b63e4a6858297905224ae85b0
d81a494c39f5fb

--

Thanks,

Matt Riedemann



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


Re: [openstack-dev] [stable/havana] gate broken

2013-11-17 Thread Gary Kotton
Thanks for dealing with this!


On 11/17/13 10:45 PM, Sean Dague s...@dague.net wrote:

Clark,

Thanks for tracking that down, just pushed those changes to the gate.

On Sun, Nov 17, 2013 at 3:03 PM, Clark Boylan clark.boy...@gmail.com
wrote:
 On Sun, Nov 17, 2013 at 7:53 AM, Gary Kotton gkot...@vmware.com wrote:
 Thanks. Looks like something fishy with tempest. When I just run
neutron
 everything is well and fine.

 On 11/17/13 5:50 PM, Matt Riedemann mrie...@linux.vnet.ibm.com
wrote:



On Sunday, November 17, 2013 7:46:39 AM, Gary Kotton wrote:
 Hi,
 The gating for the stable version is broken when the running the
 neutron gate. Locally this works but the gate has problem. All of the
 services are up and running correctly. There are some exceptions with
 the ceilometer service but that is not related to the neutron gating.

 The error message is as follows:
 2013-11-17 11:00:05.855

https://urldefense.proofpoint.com/v1/url?u=http://logs.openstack.org/
46/56746/1/check/check-tempest-devstack-vm-neutron/a02894b/console
.html%23_2
013-11-17_11_00_05_855k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo
8NP
ZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=VL2%2F41a4nc9qu2UHN5inNr9%2F
GGz
5fBDhLKNRNs4pcNw%3D%0As=863f07cf06a33e05b6b0343fd1d72f51124f5a4b4812e
758
e9c677b24759a2e0
 | 2013-11-17 11:00:05
 2013-11-17 11:00:17.239
https://urldefense.proofpoint.com/v1/url?u=http://logs.openstack.org/
46/56746/1/check/check-tempest-devstack-vm-neutron/a02894b/console
.html%23_2
013-11-17_11_00_17_239k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo
8NP
ZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=VL2%2F41a4nc9qu2UHN5inNr9%2F
GGz
5fBDhLKNRNs4pcNw%3D%0As=bf4edc850a2f4350b3d5ae1374e2fd518d2c065fa17cb
f3d
bbf00a753e556e26  | Process leaked file descriptors.
Seehttp://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+
bui
ld  for more information
 2013-11-17 11:00:17.437
https://urldefense.proofpoint.com/v1/url?u=http://logs.openstack.org/
46/56746/1/check/check-tempest-devstack-vm-neutron/a02894b/console
.html%23_2
013-11-17_11_00_17_437k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo
8NP
ZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=VL2%2F41a4nc9qu2UHN5inNr9%2F
GGz
5fBDhLKNRNs4pcNw%3D%0As=918eca2e42d056e435c956c540ad22266272db674ec4c
ded
e82d5a286b072190  | Build step 'Execute shell' marked build as
failure
 2013-11-17 11:00:19.129
https://urldefense.proofpoint.com/v1/url?u=http://logs.openstack.org/
46/56746/1/check/check-tempest-devstack-vm-neutron/a02894b/console
.html%23_2
013-11-17_11_00_19_129k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo
8NP
ZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=VL2%2F41a4nc9qu2UHN5inNr9%2F
GGz
5fBDhLKNRNs4pcNw%3D%0As=542399fe0cb38aaee9ab1d272370f3e721010032e518b
30d
b50f63f5161f16a8  | [SCP] Connecting to static.openstack.org
 Thanks
 Gary


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org

https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/
cgi
-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0
Ar
=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=VL2%2F41a4nc9qu
2UH
N5inNr9%2FGGz5fBDhLKNRNs4pcNw%3D%0As=4af7d1dfeb1ddcba19ac6d0d17b8aab5
8f1
c37ce4a335aadbcb19be7f9b1e437

I've seen this fail on at least two stable/havana patches in nova
today, so I opened this bug:

https://urldefense.proofpoint.com/v1/url?u=https://bugs.launchpad.net/o
pen
stack-ci/%2Bbug/1252024k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo
8NP
ZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=VL2%2F41a4nc9qu2UHN5inNr9%2FG
Gz5
fBDhLKNRNs4pcNw%3D%0As=028348b32601b6806fc8e7087b63e4a6858297905224ae8
5b0
d81a494c39f5fb

--

Thanks,

Matt Riedemann



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cg
i-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A
r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=7ZK7sERvy8knXJB
WZxy401dx7dr5FDpHqwm%2BawIwbc4%3D%0As=73b9b2e5146d7396e37cc5cd0b0adad1b
db0a71572bdabca8815b02d56642e66

 There was a recent change to tempest to add a new tox environment
 (smoke-serial). This tox environment is used by devstack-gate when
 running the neutron tests. As a result, the new tox env needs to be
 backported to tempest stable/havana and stable/grizzly. I have
 proposed those changes at
https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%
23/c/56825/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%
2BfDtysg45MkPhCZFxPEq8%3D%0Am=7ZK7sERvy8knXJBWZxy401dx7dr5FDpHqwm%2BawIw
bc4%3D%0As=43a60c69b1e2e244311527f5aba0a99ecb479bda12823cca3fd825f0ef6db
68a and
 
https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%
23/c/56826/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%
2BfDtysg45MkPhCZFxPEq8%3D%0Am=7ZK7sERvy8knXJBWZxy401dx7dr5FDpHqwm%2BawIw
bc4%3D%0As=ff6e1020daaa0b4063f52d1cb905cc69b97bf0c4a73cd0caaf153359229b7

Re: [openstack-dev] [Nova] Proposal to add Matt Riedemann to nova-core

2013-11-23 Thread Gary Kotton
+1

On 11/23/13 4:53 PM, Sean Dague s...@dague.net wrote:

+1 would be happy to have Matt on the team

On Fri, Nov 22, 2013 at 8:23 PM, Brian Elliott bdelli...@gmail.com
wrote:
 +1

 Solid reviewer!

 Sent from my iPad

 On Nov 22, 2013, at 2:53 PM, Russell Bryant rbry...@redhat.com wrote:

 Greetings,

 I would like to propose adding Matt Riedemann to the nova-core review
team.

 Matt has been involved with nova for a long time, taking on a wide
range
 of tasks.  He writes good code.  He's very engaged with the development
 community.  Most importantly, he provides good code reviews and has
 earned the trust of other members of the review team.

 
https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/
%23/dashboard/6873k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF
6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=W%2FbCZODtVcj75xh%2FtJc5Dt79rku6S
ABkMbVij058%2FP4%3D%0As=00158ef2fef8fac11346e6ad5e5d49ae2367546c7002a80
5d72e8a448db18431
 
https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/
%23/q/owner:6873%2Cn%2Czk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo
8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=W%2FbCZODtVcj75xh%2FtJc5Dt7
9rku6SABkMbVij058%2FP4%3D%0As=1c5a657875ba709ce9765dc9cbbccaacbf66a8f4c
5ed18ee5dbb7bb6b586a88e
 
https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/
%23/q/reviewer:6873%2Cn%2Czk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxT
UZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=W%2FbCZODtVcj75xh%2FtJc5
Dt79rku6SABkMbVij058%2FP4%3D%0As=e4455cdcd7b6458ace3c28fe2742109b31e97f
1cce0cca10ef2380fc38fd27ef

 Please respond with +1/-1, or any further comments.

 Thanks,

 --
 Russell Bryant

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cg
i-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A
r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=W%2FbCZODtVcj75
xh%2FtJc5Dt79rku6SABkMbVij058%2FP4%3D%0As=cbf89d7011d821ee62b9540ab49d3
918608e3493c05c63fceaceb8aaae1b65ee

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi
-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar
=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=W%2FbCZODtVcj75xh%
2FtJc5Dt79rku6SABkMbVij058%2FP4%3D%0As=cbf89d7011d821ee62b9540ab49d39186
08e3493c05c63fceaceb8aaae1b65ee



-- 
Sean Dague
https://urldefense.proofpoint.com/v1/url?u=http://dague.net/k=oIvRg1%2BdG
AgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%
0Am=W%2FbCZODtVcj75xh%2FtJc5Dt79rku6SABkMbVij058%2FP4%3D%0As=f0267afc282
303499ba8bd5d52a30894111fa3464d040fb31557f51ae753b0b7

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e
H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=W%2FbCZODtVcj75xh%2Ft
Jc5Dt79rku6SABkMbVij058%2FP4%3D%0As=cbf89d7011d821ee62b9540ab49d3918608e3
493c05c63fceaceb8aaae1b65ee


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


Re: [openstack-dev] [nova] future fate of nova-network?

2013-11-23 Thread Gary Kotton


On 11/22/13 2:47 PM, Daniel P. Berrange berra...@redhat.com wrote:

On Fri, Nov 22, 2013 at 11:25:51AM +, John Garbutt wrote:
  On Fri, Nov 15, 2013 at 2:21 PM, Russell Bryant rbry...@redhat.com
wrote:
  In particular, has there been a decision made about whether it will
  definitely be deprecated in some (as yet unspecified) future
release, or
  whether it will continue to be supported for the foreseeable
future?
 
  We want to deprecate it.  There are some things blocking moving
forward
  with this.  In short:
 
  1) Feature parity (primarily something that satisfies performance
and HA
  requirements addressed by nova-network in multi-host mode)
 
  2) Testing and quality parity.  The status of Neutron testing in the
  gate is far inferior to the testing done against nova-network.
 
  I'm personally more worried about #2 than #1 at this point.
 
  A major issue is that very few people actually stepped up and
agreed to
  help with #2 at the summit [2].  Only one person signed up to work
on
  tempest issues.  Nobody signed up to help with grenade.  If this
doesn't
  happen, nova-network can't be deprecated, IMO.
 
  If significant progress isn't made ASAP this cycle, and ideally by
  mid-cycle so we can change directions if necessary, then we'll have
to
  discuss what next step to take.  That may include un-freezing
  nova-network so that various people holding on to enhancements to
  nova-network can start submitting them back.  It's a last resort,
but I
  consider it on the table.
 
 Another approach to help with (1) is in Icehouse we remove the
 features from nova-network that neutron does not implement. We have
 warned about deprecation for a good few releases, so its almost OK.

We deprecated it on the basis that users would be able to do a upgrade
to new release providing something that was feature equivalent.

We didn't deprecate it on the basis that we were going to remove the
feature and provide no upgrade path, leaving users screwed.

So I don't consider removing features from nova-network to be an
acceptable approach, until they exist in Neutron or something else
that users can upgrade their existing deployments to.

As far as I see it the only thing that is missing for parity today is the
HA for the floating IP's. A partial solution was added and this was
dropped due to disagreement in the Neutron community. What I think that a
lot of people miss is that the HA floating IP support in Nova is not
really scalable and that is where the Neutron solution fills a void.

One of the items we spoke about at summit was fixing the interfaces with
Neutron - today a ton of work is done on the compute node and this should
be done elsewhere - either on the conductor or at the API level. My
feeling is that a this provide a more robust solution. The original Nova
network solution was a lot simpler as as the hypervisor was controlling
the network - this was a matter of just hooking up some bridges (and there
are still bug fix trickling in). With the advent of SDN there are 3rd
party controllers that do that and the solution becomes a lot more complex.

I do not think that features being used should be deprecated. But I think
that we should try and draw up a plan to move forwards.




Regards,
Daniel
-- 
|: 
https://urldefense.proofpoint.com/v1/url?u=http://berrange.com/k=oIvRg1%2
BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%
3D%0Am=YKXNOhIeMZZxofQPJS95IeO8WBQECmhj78fI1meXNmM%3D%0As=4bd67950e755e5
9b2116f01a609be9851c2efc1bb5080f1e81f6373150799636  -o-
https://urldefense.proofpoint.com/v1/url?u=http://www.flickr.com/photos/db
errange/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfD
tysg45MkPhCZFxPEq8%3D%0Am=YKXNOhIeMZZxofQPJS95IeO8WBQECmhj78fI1meXNmM%3D%
0As=7d93f60bdf39912d9d28058a3ae257f8e82243386aa585913a0c0b23755e65ed :|
|: 
https://urldefense.proofpoint.com/v1/url?u=http://libvirt.org/k=oIvRg1%2B
dGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3
D%0Am=YKXNOhIeMZZxofQPJS95IeO8WBQECmhj78fI1meXNmM%3D%0As=05d919a1e336ead
cc1847702b19a675ecaa5e89509dbced8aaa04302a4b30cf3  -o-
 
https://urldefense.proofpoint.com/v1/url?u=http://virt-manager.org/k=oIvR
g1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxP
Eq8%3D%0Am=YKXNOhIeMZZxofQPJS95IeO8WBQECmhj78fI1meXNmM%3D%0As=4ab771588a
99aeaa02ff5a3f7d2a6cfb69fa6d350c0d6e379b07023b4d0b5f13 :|
|: 
https://urldefense.proofpoint.com/v1/url?u=http://autobuild.org/k=oIvRg1%
2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8
%3D%0Am=YKXNOhIeMZZxofQPJS95IeO8WBQECmhj78fI1meXNmM%3D%0As=66111a111c895
bcb11642867a97e5149591089e23137c5b8388dae546a97f801   -o-
https://urldefense.proofpoint.com/v1/url?u=http://search.cpan.org/~danberr
/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45M
kPhCZFxPEq8%3D%0Am=YKXNOhIeMZZxofQPJS95IeO8WBQECmhj78fI1meXNmM%3D%0As=df
8acdd0ac83e97c9e5b26dce7599a705765e3f0b0eff8a3afef07673ece09b9 :|
|: 

[openstack-dev] Gate failures

2013-11-23 Thread Gary Kotton
Hi,
To whoever fixed the gate – Thanks! Can someone please let us know what the 
problems were.
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Scheduler sub-group agenda 11/26

2013-11-25 Thread Gary Kotton
Hi,
Thanks. I think that it may also be good to discuss Robert Collins proposal of 
moving the scheduler out of Nova.
Thanks
Gary

From: Dugger, Donald D 
donald.d.dug...@intel.commailto:donald.d.dug...@intel.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, November 26, 2013 1:55 AM
To: 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] Scheduler sub-group agenda 11/26


1)  Memcached based scheduler

2)  Instance groups

3)  Black box scheduler

4)  Scheduler as a Service


Most of those can potentially create a bit of a discussion, wouldn’t be 
surprised if we don’t get through everything tomorrow.

--
Don Dugger
Censeo Toto nos in Kansa esse decisse. - D. Gale
Ph: 303/443-3786

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


  1   2   3   4   5   6   >