Re: [openstack-dev] In loving memory of Chris Yeoh
What bad news.. Chris helped me a lot, we lost a mentor and friend. May God bless his/her soul. WingWJ On Mon, Apr 13, 2015 at 1:03 PM, Gary Kotton gkot...@vmware.com wrote: Hi, I am very saddened to read this. Not only will Chris be missed on a professional level but on a personal level. He was a real mensh (http://www.thefreedictionary.com/mensh). He was always helpful and supportive. Wishing his family a long life. Thanks Gary On 4/13/15, 4:33 AM, Michael Still mi...@stillhq.com wrote: Hi, as promised I now have details of a charity for people to donate to in Chris' memory: https://urldefense.proofpoint.com/v2/url?u=http-3A__participate.freetobrea the.org_site_TR-3Fpx-3D1582460-26fr-5Fid-3D2710-26pg-3Dpersonal-23.VSscH5S Ud90d=AwIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzk WT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=IFwED7YYaddl7JbqZ5OLChF6gtEGxYkxfFHwjWRm sD8s=B3EgunFqBdY8twmv-iJ7G7xvKZ4Th48oB4HKSv2uGKge= In the words of the family: We would prefer that people donate to lung cancer research in lieu of flowers. Lung cancer has the highest mortality rate out of all the cancers, and the lowest funding out of all the cancers. There is a stigma attached that lung cancer is a smoker's disease, and that sufferers deserve their fate. They bring it on through lifestyle choice. Except that Chris has never smoked in his life, like a surprisingly large percentage of lung cancer sufferers. These people suffer for the incorrect beliefs of the masses, and those that are left behind are equally innocent. We shouldn't be doing this now. He shouldn't be gone. We need to do more to fix this. There will be charity envelopes available at the funeral, or you can choose your preferred research to fund, should you wish to do so. You have our thanks. Michael On Wed, Apr 8, 2015 at 2:49 PM, Michael Still mi...@stillhq.com wrote: It is my sad duty to inform the community that Chris Yeoh passed away this morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will remember Chris as the clever and caring person that I will remember him as. I haven¹t had a chance to confirm with the family if they want flowers or a donation to a charity. As soon as I know those details I will reply to this email. Chris worked on open source for a very long time, with OpenStack being just the most recent in a long chain of contributions. He worked tirelessly on his contributions to Nova, including mentoring other developers. He was dedicated to the cause, with a strong vision of what OpenStack could become. He even named his cat after the project. Chris might be the only person to have ever sent an email to his coworkers explaining what his code review strategy would be after brain surgery. It takes phenomenal strength to carry on in the face of that kind of adversity, but somehow he did. Frankly, I think I would have just sat on the beach. Chris was also a contributor to the Linux Standards Base (LSB), where he helped improve the consistency and interoperability between Linux distributions. He ran the ŒHackfest¹ programming contests for a number of years at Australia¹s open source conference -- linux.conf.au. He supported local Linux user groups in South Australia and Canberra, including involvement at installfests and speaking at local meetups. He competed in a programming challenge called Loki Hack, and beat out the world to win the event[1]. Alyssa¹s memories of her dad need to last her a long time, so we¹ve decided to try and collect some fond memories of Chris to help her along the way. If you feel comfortable doing so, please contribute a memory or two at https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_form s_d_1kX-2DePqAO7Cuudppwqz1cqgBXAsJx27GkdM-2DeCZ0c1V8_viewformd=AwIGaQc= Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTe q9N3-diTlNj4GyNcm=IFwED7YYaddl7JbqZ5OLChF6gtEGxYkxfFHwjWRmsD8s=iihsaOMe lNeIR3VZapWKjr5KLgMQArZ3nifKDo1yy8oe= Chris was humble, helpful and honest. The OpenStack and broader Open Source communities are poorer for his passing. Michael [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lokigames.com_hac k_d=AwIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkW T5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=IFwED7YYaddl7JbqZ5OLChF6gtEGxYkxfFHwjWRm sD8s=9SJI7QK-jzCsVUN2hTXSthqiXNEbq2Fvl9JqQiX9tfoe= -- Rackspace Australia __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [nova] Why is there a 'None' task_state between 'SCHEDULING' 'BLOCK_DEVICE_MAPPING'?
Hi Phil, thanks for your reply. So should I need to submit a patch/spec to add it now? On Wed, Jun 25, 2014 at 5:53 PM, Day, Phil philip@hp.com wrote: Looking at this a bit deeper the comment in _*start*_buidling() says that its doing this to “Save the host and launched_on fields and log appropriately “.But as far as I can see those don’t actually get set until the claim is made against the resource tracker a bit later in the process, so this whole update might just be not needed – although I still like the idea of a state to show that the request has been taken off the queue by the compute manager. *From:* Day, Phil *Sent:* 25 June 2014 10:35 *To:* OpenStack Development Mailing List *Subject:* RE: [openstack-dev] [nova] Why is there a 'None' task_state between 'SCHEDULING' 'BLOCK_DEVICE_MAPPING'? Hi WingWJ, I agree that we shouldn’t have a task state of None while an operation is in progress. I’m pretty sure back in the day this didn’t use to be the case and task_state stayed as Scheduling until it went to Networking (now of course networking and BDM happen in parallel, so you have to be very quick to see the Networking state). Personally I would like to see the extra granularity of knowing that a request has been started on the compute manager (and knowing that the request was started rather than is still sitting on the queue makes the decision to put it into an error state when the manager is re-started more robust). Maybe a task state of “STARTING_BUILD” for this case ? BTW I don’t think _*start*_building() is called anymore now that we’ve switched to conductor calling build_and_run_instance() – but the same task_state issue exist in there well. *From:* wu jiang [mailto:win...@gmail.com win...@gmail.com] *Sent:* 25 June 2014 08:19 *To:* OpenStack Development Mailing List *Subject:* [openstack-dev] [nova] Why is there a 'None' task_state between 'SCHEDULING' 'BLOCK_DEVICE_MAPPING'? Hi all, Recently, some of my instances were stuck in task_state 'None' during VM creation in my environment. So I checked found there's a 'None' task_state between 'SCHEDULING' 'BLOCK_DEVICE_MAPPING'. The related codes are implemented like this: #def _start_building(): #self._instance_update(context, instance['uuid'], # vm_state=vm_states.BUILDING, # task_state=None, # expected_task_state=(task_states.SCHEDULING, # None)) So if compute node is rebooted after that procession, all building VMs on it will always stay in 'None' task_state. And it's useless and not convenient for locating problems. Why not a new task_state for this step? WingWJ ___ 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] Two questions about 'backup' API
Hi all, I tested the 'backup' API recently and got two questions about it: 1. Why 'daily' 'weekly' appear in code comments novaclient about 'backup_type' parameter? The 'backup_type' parameter is only a tag for this backup(image). And there isn't corresponding validation for 'backup_type' about these two types. Moreover, there is also no periodic_task for 'backup' in compute host. (It's fair to leave the choice to other third-parts system) So, why we leave 'daily | weekly' example in code comments and novaclient? IMO it may lead confusion that Nova will do more actions for 'daily|weekly' backup request. 2. Is it necessary to backup instance when 'rotation' is equal to 0? Let's look at related codes in nova/compute/manager.py: # def backup_instance(self, context, image_id, instance, backup_type, rotation): # #self._do_snapshot_instance(context, image_id, instance, rotation) #self._rotate_backups(context, instance, backup_type, rotation) I knew Nova will delete all backup images according the 'backup_type' parameter when 'rotation' equals to 0. But according the logic above, Nova will generate one new backup in _do_snapshot_instance(), and delete it in _rotate_backups().. It's weird to snapshot a useless backup firstly IMO. We need to add one new branch here: if 'rotation' is equal to 0, no need to backup, just rotate it. So, what's your opinions? Look forward to your suggestion. Thanks. WingWJ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Why is there a 'None' task_state between 'SCHEDULING' 'BLOCK_DEVICE_MAPPING'?
Hi Phil, Ok, I'll submit a patch to add a new task_state(like 'STARTING_BUILD') in these two days. And related modifications will be definitely added in the Doc. Thanks for your help. :) WingWJ On Thu, Jun 26, 2014 at 6:42 PM, Day, Phil philip@hp.com wrote: Why do others think – do we want a spec to add an additional task_state value that will be set in a well defined place. Kind of feels overkill for me in terms of the review effort that would take compared to just reviewing the code - its not as there are going to be lots of alternatives to consider here. *From:* wu jiang [mailto:win...@gmail.com] *Sent:* 26 June 2014 09:19 *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [nova] Why is there a 'None' task_state between 'SCHEDULING' 'BLOCK_DEVICE_MAPPING'? Hi Phil, thanks for your reply. So should I need to submit a patch/spec to add it now? On Wed, Jun 25, 2014 at 5:53 PM, Day, Phil philip@hp.com wrote: Looking at this a bit deeper the comment in _*start*_buidling() says that its doing this to “Save the host and launched_on fields and log appropriately “.But as far as I can see those don’t actually get set until the claim is made against the resource tracker a bit later in the process, so this whole update might just be not needed – although I still like the idea of a state to show that the request has been taken off the queue by the compute manager. *From:* Day, Phil *Sent:* 25 June 2014 10:35 *To:* OpenStack Development Mailing List *Subject:* RE: [openstack-dev] [nova] Why is there a 'None' task_state between 'SCHEDULING' 'BLOCK_DEVICE_MAPPING'? Hi WingWJ, I agree that we shouldn’t have a task state of None while an operation is in progress. I’m pretty sure back in the day this didn’t use to be the case and task_state stayed as Scheduling until it went to Networking (now of course networking and BDM happen in parallel, so you have to be very quick to see the Networking state). Personally I would like to see the extra granularity of knowing that a request has been started on the compute manager (and knowing that the request was started rather than is still sitting on the queue makes the decision to put it into an error state when the manager is re-started more robust). Maybe a task state of “STARTING_BUILD” for this case ? BTW I don’t think _*start*_building() is called anymore now that we’ve switched to conductor calling build_and_run_instance() – but the same task_state issue exist in there well. *From:* wu jiang [mailto:win...@gmail.com win...@gmail.com] *Sent:* 25 June 2014 08:19 *To:* OpenStack Development Mailing List *Subject:* [openstack-dev] [nova] Why is there a 'None' task_state between 'SCHEDULING' 'BLOCK_DEVICE_MAPPING'? Hi all, Recently, some of my instances were stuck in task_state 'None' during VM creation in my environment. So I checked found there's a 'None' task_state between 'SCHEDULING' 'BLOCK_DEVICE_MAPPING'. The related codes are implemented like this: #def _start_building(): #self._instance_update(context, instance['uuid'], # vm_state=vm_states.BUILDING, # task_state=None, # expected_task_state=(task_states.SCHEDULING, # None)) So if compute node is rebooted after that procession, all building VMs on it will always stay in 'None' task_state. And it's useless and not convenient for locating problems. Why not a new task_state for this step? WingWJ ___ 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] [nova] Two questions about 'backup' API
Hi Vish, thanks for your reply. About Q1, I mean that Nova doesn't have extra processions/works for 'daily'/'weekly' than other backup_types like '123'/'test'. The 'daily' 'weekly' don't have unique places in the API than any other else. But we gave them as examples in code comments especially in novaclient. A few users asked me why their instances were not backup-ed automatically, they thought we have a timing task to do this if the 'backup_type' equals to 'daily'/'weekly' because we prompt them to use it.. Therefore, it's useless and inclined to make confusion for this API IMO. No need to show them in code comments novaclient. P.S. So maybe 'backup_name'/'backup_tag' is a better name, but we can't modify the API for compatibility.. Thanks. WingWJ On Fri, Jun 27, 2014 at 5:20 AM, Vishvananda Ishaya vishvana...@gmail.com wrote: On Jun 26, 2014, at 5:07 AM, wu jiang win...@gmail.com wrote: Hi all, I tested the 'backup' API recently and got two questions about it: 1. Why 'daily' 'weekly' appear in code comments novaclient about 'backup_type' parameter? The 'backup_type' parameter is only a tag for this backup(image). And there isn't corresponding validation for 'backup_type' about these two types. Moreover, there is also no periodic_task for 'backup' in compute host. (It's fair to leave the choice to other third-parts system) So, why we leave 'daily | weekly' example in code comments and novaclient? IMO it may lead confusion that Nova will do more actions for 'daily|weekly' backup request. The tag affects the cleanup of old copies, so if you do a tag of ‘weekly’ and the rotation is 3, it will insure you only have 3 copies that are tagged weekly. You could also have 3 copies of the daily tag as well. 2. Is it necessary to backup instance when 'rotation' is equal to 0? Let's look at related codes in nova/compute/manager.py: # def backup_instance(self, context, image_id, instance, backup_type, rotation): # #self._do_snapshot_instance(context, image_id, instance, rotation) #self._rotate_backups(context, instance, backup_type, rotation) I knew Nova will delete all backup images according the 'backup_type' parameter when 'rotation' equals to 0. But according the logic above, Nova will generate one new backup in _do_snapshot_instance(), and delete it in _rotate_backups().. It's weird to snapshot a useless backup firstly IMO. We need to add one new branch here: if 'rotation' is equal to 0, no need to backup, just rotate it. That makes sense I suppose. Vish So, what's your opinions? Look forward to your suggestion. Thanks. WingWJ ___ 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
[openstack-dev] [nova] Why is there a 'None' task_state between 'SCHEDULING' 'BLOCK_DEVICE_MAPPING'?
Hi all, Recently, some of my instances were stuck in task_state 'None' during VM creation in my environment. So I checked found there's a 'None' task_state between 'SCHEDULING' 'BLOCK_DEVICE_MAPPING'. The related codes are implemented like this: #def _start_building(): #self._instance_update(context, instance['uuid'], # vm_state=vm_states.BUILDING, # task_state=None, # expected_task_state=(task_states.SCHEDULING, # None)) So if compute node is rebooted after that procession, all building VMs on it will always stay in 'None' task_state. And it's useless and not convenient for locating problems. Why not a new task_state for this step? WingWJ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Nominating Ken'ichi Ohmichi for nova-core
Congratulation! On Wed, Jun 18, 2014 at 7:07 PM, Kenichi Oomichi oomi...@mxs.nes.nec.co.jp wrote: -Original Message- From: Michael Still [mailto:mi...@stillhq.com] Sent: Wednesday, June 18, 2014 7:54 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] Nominating Ken'ichi Ohmichi for nova-core Kenichi has now been added to the nova-core group in gerrit. Welcome aboard! Thank you for many +1s, and I'm glad to join the nova-core group :-) I am going to try hard for the smooth development. Thanks Ken'ichi Ohmichi --- On Tue, Jun 17, 2014 at 6:18 PM, Michael Still mi...@stillhq.com wrote: Hi. I'm going to let this sit for another 24 hours, and then we'll declare it closed. Cheers, Michael On Tue, Jun 17, 2014 at 6:16 AM, Mark McLoughlin mar...@redhat.com wrote: On Sat, 2014-06-14 at 08:40 +1000, Michael Still wrote: Greetings, I would like to nominate Ken'ichi Ohmichi for the nova-core team. Ken'ichi has been involved with nova for a long time now. His reviews on API changes are excellent, and he's been part of the team that has driven the new API work we've seen in recent cycles forward. Ken'ichi has also been reviewing other parts of the code base, and I think his reviews are detailed and helpful. +1, great to see Ken'ichi join the team Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Rackspace Australia -- Rackspace Australia ___ 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
[openstack-dev] [nova][qa] Do all turbo-hipster jobs fail in stable/havana?
Hi all, Is turbo-hipster OK for stable/havana? I found all turbo-hipster jobs after 06/09 failed in stable/havana [1]. And the 'recheck migrations' command didn't trigger the re-examination of turbo-hipster, but Jenkins recheck work.. Thanks. WingWJ --- [1] https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/havana,n,z [2] https://review.openstack.org/#/c/67613/ [3] https://review.openstack.org/#/c/72521/ [4] https://review.openstack.org/#/c/98874/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Nominating Ken'ichi Ohmichi for nova-core
+1. I got lots of helpful assistance from him. :) On Sun, Jun 15, 2014 at 8:44 PM, Alex Xu x...@linux.vnet.ibm.com wrote: +1 On 2014年06月14日 06:40, Michael Still wrote: Greetings, I would like to nominate Ken'ichi Ohmichi for the nova-core team. Ken'ichi has been involved with nova for a long time now. His reviews on API changes are excellent, and he's been part of the team that has driven the new API work we've seen in recent cycles forward. Ken'ichi has also been reviewing other parts of the code base, and I think his reviews are detailed and helpful. Please respond with +1s or any concerns. References: https://review.openstack.org/#/q/owner:ken1ohmichi% 2540gmail.com+status:open,n,z https://review.openstack.org/#/q/reviewer:ken1ohmichi% 2540gmail.com,n,z http://www.stackalytics.com/?module=nova-groupuser_id=oomichi As a reminder, we use the voting process outlined at https://wiki.openstack.org/wiki/Nova/CoreTeam to add members to our core team. Thanks, Michael ___ 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] Review guidelines for API patches
+1 to Matt. On Fri, Jun 13, 2014 at 10:03 AM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 6/12/2014 8:58 PM, Matt Riedemann wrote: On 6/12/2014 5:58 PM, Christopher Yeoh wrote: On Fri, Jun 13, 2014 at 8:06 AM, Michael Still mi...@stillhq.com mailto:mi...@stillhq.com wrote: In light of the recent excitement around quota classes and the floating ip pollster, I think we should have a conversation about the review guidelines we'd like to see for API changes proposed against nova. My initial proposal is: - API changes should have an associated spec +1 - API changes should not be merged until there is a tempest change to test them queued for review in the tempest repo +1 Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev We do have some API change guidelines here [1]. I don't want to go overboard on every change and require a spec if it's not necessary, i.e. if it falls into the 'generally ok' list in that wiki. But if it's something that's not documented as a supported API (so it's completely new) and is pervasive (going into novaclient so it can be used in some other service), then I think that warrants some spec consideration so we don't miss something. To compare, this [2] is an example of something that is updating an existing API but I don't think warrants a blueprint since I think it falls into the 'generally ok' section of the API change guidelines. [1] https://wiki.openstack.org/wiki/APIChangeGuidelines [2] https://review.openstack.org/#/c/99443/ I think I'd like to say I think something about something a few more times... :) -- Thanks, Matt Riedemann ___ 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] Review guidelines for API patches
If one new feature relates to some API modifications, and its spec has already involved the modifications' description, is it necessary to add one more API spec here? On Fri, Jun 13, 2014 at 10:20 AM, wu jiang win...@gmail.com wrote: +1 to Matt. On Fri, Jun 13, 2014 at 10:03 AM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 6/12/2014 8:58 PM, Matt Riedemann wrote: On 6/12/2014 5:58 PM, Christopher Yeoh wrote: On Fri, Jun 13, 2014 at 8:06 AM, Michael Still mi...@stillhq.com mailto:mi...@stillhq.com wrote: In light of the recent excitement around quota classes and the floating ip pollster, I think we should have a conversation about the review guidelines we'd like to see for API changes proposed against nova. My initial proposal is: - API changes should have an associated spec +1 - API changes should not be merged until there is a tempest change to test them queued for review in the tempest repo +1 Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev We do have some API change guidelines here [1]. I don't want to go overboard on every change and require a spec if it's not necessary, i.e. if it falls into the 'generally ok' list in that wiki. But if it's something that's not documented as a supported API (so it's completely new) and is pervasive (going into novaclient so it can be used in some other service), then I think that warrants some spec consideration so we don't miss something. To compare, this [2] is an example of something that is updating an existing API but I don't think warrants a blueprint since I think it falls into the 'generally ok' section of the API change guidelines. [1] https://wiki.openstack.org/wiki/APIChangeGuidelines [2] https://review.openstack.org/#/c/99443/ I think I'd like to say I think something about something a few more times... :) -- Thanks, Matt Riedemann ___ 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] [infra] Jenkins jobs are always running for abandoned patches..
Hi all, I found Jenkins met some problems about abandoned patches. The jenkins-jobs are always running even if the jobs were successful or failed.. I've checked some patches[1][2][3] suit the issue. It look like if you add comments to an abandoned patch, the Jenkins will start check jobs again and again.. I've submitted the issue on launchpad now[4]. So if you have idea about the issue, please give some tips about that. Thanks. wingwj --- [1] https://review.openstack.org/#/c/75802/ [2] https://review.openstack.org/#/c/74917/ [3] https://review.openstack.org/#/c/91606/ [4] https://bugs.launchpad.net/openstack-ci/+bug/1316064 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [OpenStack-dev][QA] Does turbo-hipster fail in Nova?
Hi all, Does turbo-hipster fail in Nova? I rechecked and recommitted my patches[1][2], the gate jobs always fail. I check all the Nova patches on Gerrit[3] now, and found lots of nova patches fail caused by turbo-hipster. Does it meet some problems? Thanks. wingwj - [1] https://review.openstack.org/#/c/72554/ [2] https://review.openstack.org/#/c/79529/ [3] https://review.openstack.org/#/q/status:open+project:openstack/nova,n,z ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-dev][QA] Does turbo-hipster fail in Nova?
The information provided in patch[1] is like this: - gate-real-db-upgrade_nova_mysql_devstack_131007http://www.rcbops.com/turbo_hipster/results/72/72554/8/check/gate-real-db-upgrade_nova_mysql_devstack_131007/ddedd5a/131007_devstack_export.log SUCCESS in 9m 08s - gate-real-db-upgrade_nova_mysql_user_001http://www.rcbops.com/turbo_hipster/results/72/72554/8/check/gate-real-db-upgrade_nova_mysql_user_001/0ea217a/user_001.log WARNING - Migration 215-216 changed too many rows (264484) in 24m 45s - gate-real-db-upgrade_nova_percona_devstack_131007http://www.rcbops.com/turbo_hipster/results/72/72554/8/check/gate-real-db-upgrade_nova_percona_devstack_131007/423d4d7/131007_devstack_export.log SUCCESS in 8m 34s - gate-real-db-upgrade_nova_percona_user_001http://www.rcbops.com/turbo_hipster/results/72/72554/8/check/gate-real-db-upgrade_nova_percona_user_001/acb427c/user_001.log WARNING - Migration 215-216 changed too many rows (264484) in 24m 10s - gate-real-db-upgrade_nova_mysql_user_002http://www.rcbops.com/turbo_hipster/results/72/72554/8/check/gate-real-db-upgrade_nova_mysql_user_002/91951bb/user_002.log SUCCESS in 12m 28s - gate-real-db-upgrade_nova_percona_user_002http://www.rcbops.com/turbo_hipster/results/72/72554/8/check/gate-real-db-upgrade_nova_percona_user_002/2fffa29/user_002.log SUCCESS in 12m 40s - I checked the codes in 'nova/db/sqlalchemy/migrate_repo/versions/', the first file for db migration is '216_havana.py'. Thanks. --- [1] https://review.openstack.org/#/c/72554/ On Mon, Mar 24, 2014 at 5:42 PM, wu jiang win...@gmail.com wrote: Hi all, Does turbo-hipster fail in Nova? I rechecked and recommitted my patches[1][2], the gate jobs always fail. I check all the Nova patches on Gerrit[3] now, and found lots of nova patches fail caused by turbo-hipster. Does it meet some problems? Thanks. wingwj - [1] https://review.openstack.org/#/c/72554/ [2] https://review.openstack.org/#/c/79529/ [3] https://review.openstack.org/#/q/status:open+project:openstack/nova,n,z ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Getting close to RC1....
Hi Tracy, I've already updated the patch for bug/1195947 on https://review.openstack.org/#/c/38073/. Please review it. Thanks~ On Wed, Mar 19, 2014 at 5:31 AM, Tracy Jones tjo...@vmware.com wrote: Folks - we are getting close to RC next week and therefore will start closing down the churn. Bugs that are not merged by Monday @8am EDT (12pm UTC) will be moved out of RC1 and pushed to icehouse-rc-potential. Only those bugs which are a. regression b. highest priority issues (as decided by russellb) will be reviewed after that time. The current list for RC1 is Bug reportImportanceAssigneeStatus#1195947VM re-scheduler mechanism will cause BDM-volumes conflict https://bugs.launchpad.net/bugs/1195947https://launchpad.net/nova/+milestone/icehouse-rc1 Highwingwj https://launchpad.net/~wingwj In Progress#1246201Live migration fails when the instance has a config-drivehttps://bugs.launchpad.net/bugs/1246201https://launchpad.net/nova/+milestone/icehouse-rc1 HighMichael Still https://launchpad.net/~mikalstill In Progress#1269418nova rescue doesn't put VM into RESCUE status on vmwarehttps://bugs.launchpad.net/bugs/1269418https://launchpad.net/nova/+milestone/icehouse-rc1 HighGary Kotton https://launchpad.net/~garyk In Progress#1274129host-update --maintenance enable regression for vmware VCDriverhttps://bugs.launchpad.net/bugs/1274129https://launchpad.net/nova/+milestone/icehouse-rc1 HighGary Kotton https://launchpad.net/~garyk In Progress#1290403Hyper-V agent does not enable disk metrics for individual diskshttps://bugs.launchpad.net/bugs/1290403https://launchpad.net/nova/+milestone/icehouse-rc1 HighClaudiu Belu https://launchpad.net/~cbelu In Progress#1290540neutron_admin_tenant_name deprecation warning is wrong https://bugs.launchpad.net/bugs/1290540https://launchpad.net/nova/+milestone/icehouse-rc1 HighRobert Collins https://launchpad.net/~lifeless In Progress#1290807Resize on vCenter failed because of _VM_REFS_CACHEhttps://bugs.launchpad.net/bugs/1290807https://launchpad.net/nova/+milestone/icehouse-rc1 HighFeng Xi Yan https://launchpad.net/~yanfengxi In Progress#1294102VMware: get_object_properties may not return any objectshttps://bugs.launchpad.net/bugs/1294102https://launchpad.net/nova/+milestone/icehouse-rc1 HighGary Kotton https://launchpad.net/~garyk In Progress#1180040Race condition in attaching/detaching volumes when compute manager is unreachablehttps://bugs.launchpad.net/bugs/1180040https://launchpad.net/nova/+milestone/icehouse-rc1 MediumNikola Đipanov https://launchpad.net/~ndipanov In Progress The rest will be deferred to Juno. Please let me know if you have questions or comments Tracy ___ 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] 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/IRC ___ 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?
Hi Gary, Thanks for your information. I'll consult the BP in there. :) wingwj On Mon, Mar 3, 2014 at 4:34 PM, Gary Kotton gkot...@vmware.com wrote: Hi, This is the same channel as nova - that is #openstack-nova Thanks Gary From: wu jiang win...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Monday, March 3, 2014 10:11 AM To: OpenStack Development Mailing List 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [OpenStack-dev][Nova] Can we add one configuration item for cache-using in libvirt/hypervisor?
Hi all, Recently, I met one scenario which needs to close the cache on linux hypervisor. But some codes written in libvirt/driver.py (including suspend/snapshot) are hard-coded. For example: --- def suspend(self, instance): Suspend the specified instance. dom = self._lookup_by_name(instance['name']) self._detach_pci_devices(dom, pci_manager.get_instance_pci_devs(instance)) dom.managedSave(0) So, can we add one configuration item in nova.conf, like *DOMAIN_SAVE_BYPASS_CACHE*, to let operator can handle it? That would be improved flexibility of Nova. Thanks wingwj ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][EC2] attach and detach volume response status
Hi, I checked the AttachVolume in AWS EC2: http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-AttachVolume.html The status returned is 'attaching': AttachVolumeResponse xmlns=http://ec2.amazonaws.com/doc/2013-10-15/; requestId59dbff89-35bd-4eac-99ed-be587EXAMPLE/requestId volumeIdvol-1a2b3c4d/volumeId instanceIdi-1a2b3c4d/instanceId device/dev/sdh/device statusattaching/status attachTime-MM-DDTHH:MM:SS.000Z/attachTime /AttachVolumeResponse So I think it's a bug IMO.Thanks~ wingwj On Sat, Feb 15, 2014 at 11:35 AM, Rui Chen chenrui.m...@gmail.com wrote: Hi Stackers; I use Nova EC2 interface to attach a volume, attach success, but volume status is detached in message response. # euca-attach-volume -i i-000d -d /dev/vdb vol-0001 ATTACHMENT vol-0001i-000d detached This make me confusion, I think the status should be attaching or in-use. I find attach and detach volume interfaces return volume['attach_status'], but describe volume interface return volume['status'] Is it a bug? or for other considerations I do not know. Thanks ___ 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] modify_image_attribute() in ec2_api is broken in Nova
Hi Vish, thanks for your reply.
I've already registered it on launchpad:
https://bugs.launchpad.net/nova/+bug/1272844
Thanks~
On Thu, Feb 13, 2014 at 2:18 AM, Vishvananda Ishaya
vishvana...@gmail.comwrote:
This looks like a bug to me. It would be great if you could report it on
launchpad.
Vish
On Feb 11, 2014, at 7:49 PM, wu jiang win...@gmail.com wrote:
Hi all,
I met some problems when testing an ec2_api:'modify_image_attribute()' in
Nova.
I found the params send to Nova, are not suitable to match it in AWS api.
I logged it in launchpad: https://bugs.launchpad.net/nova/+bug/1272844
-
1. Here is the definition part of modify_image_attribute():
def modify_image_attribute(
self, context, image_id, attribute, operation_type, **kwargs)
2. And here is the example of it in AWS api:
https://ec2.amazonaws.com/?Action=ModifyImageAttributeImageId=ami-61a54008LaunchPermission.Remove.1.UserId=
-
3. You can see the value isn't suitable to match the defination in Nova
codes.
Therefore, Nova will raise the exception like this:
TypeError: 'modify_image_attribute() takes exactly 5 non-keyword
arguments (3 given)'
4. I printed out the params send to Nova via eucaTools.
The results also validate the conclusions above:
args={'launch_permission': {'add': {'1': {'group': u'all'}}},
'image_id': u'ami-0004'}
--
So, is this api correct? Should we need to modify it according to the
format of AWS api?
Best Wishes,
wingwj
___
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] Gamification and on-boarding ...
+1. This looks very interesting. :) On Thu, Feb 13, 2014 at 2:09 PM, Russell Bryant rbry...@redhat.com wrote: On 02/12/2014 11:35 AM, Ben Nemec wrote: On 2014-02-12 12:00, Sandy Walsh wrote: At the Nova mid-cycle meetup we've been talking about the problem of helping new contributors. It got into a discussion of karma, code reviews, bug fixes and establishing a name for yourself before screaming in a chat room can someone look at my branch. We want this experience to be positive, but not everyone has time to hand-hold new people in the dance. The informal OpenStack motto is automate everything, so perhaps we should consider some form of gamification [1] to help us? Can we offer badges, quests and challenges to new users to lead them on the way to being strong contributors? Fixed your first bug badge Updated the docs badge Got your blueprint approved badge Triaged a bug badge Reviewed a branch badge Contributed to 3 OpenStack projects badge Fixed a Cells bug badge Constructive in IRC badge Freed the gate badge Reverted branch from a core badge etc. These can be strung together as Quests to lead people along the path. It's more than karma and less sterile than stackalytics. The Foundation could even promote the rising stars and highlight the leader board. There are gamification-as-a-service offerings out there [2] as well as Fedora Badges [3] (python and open source) that we may want to consider. Thoughts? -Sandy [1] http://en.wikipedia.org/wiki/Gamification [2] http://gamify.com/ (and many others) [3] https://badges.fedoraproject.org/ +1 from me, if this can be done without a huge amount of ongoing maintenance for someone. I will admit that climbing the reviewstats leaderboard is good motivation for those days when I just don't feel like reviewing. Ditto for Launchpad karma. :-) I really like the badges idea. It sounds like a really fun way to encourage folks. It's a refreshing alternative to just looking at raw numbers all the time. -- 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
[openstack-dev] [Nova] modify_image_attribute() in ec2_api is broken in Nova
Hi all,
I met some problems when testing an ec2_api:'modify_image_attribute()' in
Nova.
I found the params send to Nova, are not suitable to match it in AWS api.
I logged it in launchpad: https://bugs.launchpad.net/nova/+bug/1272844
-
1. Here is the definition part of modify_image_attribute():
def modify_image_attribute(
self, context, image_id, attribute, operation_type, **kwargs)
2. And here is the example of it in AWS api:
https://ec2.amazonaws.com/?Action=ModifyImageAttributeImageId=ami-61a54008LaunchPermission.Remove.1.UserId=
-
3. You can see the value isn't suitable to match the defination in Nova
codes.
Therefore, Nova will raise the exception like this:
TypeError: 'modify_image_attribute() takes exactly 5 non-keyword arguments
(3 given)'
4. I printed out the params send to Nova via eucaTools.
The results also validate the conclusions above:
args={'launch_permission': {'add': {'1': {'group': u'all'}}}, 'image_id':
u'ami-0004'}
--
So, is this api correct? Should we need to modify it according to the
format of AWS api?
Best Wishes,
wingwj
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova]I want to add a hypervisor driver for Nova in icehouse
Hi all, I'm planing to commit a new hypervisor Driver for Huawei-FusionCompute in Icehouse. And I've already submitted a bp wiki to OpenStack. BP: https://blueprints.launchpad.net/nova/+spec/driver-for-huawei-fusioncompute Wiki: https://wiki.openstack.org/wiki/FusionCompute Now I'm not sure whether this is enough. So if you're interested, plz take a look. Any help will be truly appreciated. Thanks. Regards, wingwj ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-dev] How to modify a bug across multiple repo?
Hi Christopher, Thanks again for your answering. :) The issue I mentioned before, has already committed to Gerrit. So if you have time, please see here: https://review.openstack.org/#/c/62163/ P.S. Is it a good idea if I ask the contributor to participate in reviewing? Any help will be appreciated. wingwj On Fri, Dec 13, 2013 at 8:17 PM, Christopher Yeoh cbky...@gmail.com wrote: Hi wu jiang, On Wed, Dec 11, 2013 at 12:26 PM, wu jiang win...@gmail.com wrote: Hi Chris Rob, Thanks for your reply ,and sorry for my late response.. - I tested again. The modification won't effect tempest test because it's an optional argument, so I can commit it later in tempest. Lucky. - But the bug in Cinder exists at the API layer, so the modification will effect the CinderClient behavior.. :( So, that's quite a complex problem.. Any ideas? To help I think I'd need more details on the exact bug. Does the change that you need to make comply with the guidelines here https://wiki.openstack.org/wiki/APIChangeGuidelines ? Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Fwd: [OpenStack-dev] How to modify a bug across multiple repo?
Hi Chris Rob, Thanks for your reply ,and sorry for my late response.. - I tested again. The modification won't effect tempest test because it's an optional argument, so I can commit it later in tempest. Lucky. - But the bug in Cinder exists at the API layer, so the modification will effect the CinderClient behavior.. :( So, that's quite a complex problem.. Any ideas? wingwj On Fri, Dec 6, 2013 at 5:41 PM, Lingxian Kong anlin.k...@gmail.com wrote: -- Forwarded message -- From: Christopher Yeoh cbky...@gmail.com Date: 2013/12/3 Subject: Re: [openstack-dev] [OpenStack-dev] How to modify a bug across multiple repo? To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Hi, On Tue, Dec 3, 2013 at 7:21 PM, Robert Collins robe...@robertcollins.netwrote: No, you need to manually arrange to land your changes in first one repo then the other. -Rob On 3 December 2013 19:17, wu jiang win...@gmail.com wrote: Hi all, Recently, I found a bug at API layer in Cinder, but the modifications relate to CinderClient Tempest. So, I'm confused how to commit it. Can 'git --dependence' cross different Repo? Just to expand on what Rob mentioned - for situations like this its pretty common not to be able to just say make a change in cinder first because the tempest test will fail. And at the same time you can't make the final change in tempest first because the cinder change hasn't applied yet. If this is your situation what I'd suggest you do is: - Submit the cinder change, it will fail tempest, that's ok, you might want to leave a comment saying you are waiting on a tempest change to land first. - Submit a tempest change which disables the tempest tests which fail because of your change and in the commit message reference the gerrit url for the cinder change. Its very helpful, but not always necessary if you can get a cinder core to +1 this patch so the tempest cores know that the cinder team is happy with what is going on. - Once the tempest change has merged, the cinder change should be able to merge. - Submit a tempest change enabling the disabled test(s) and modifying it for the expected behaviour. Yes, it would be nice to be able to have cross project dependent patches :) Chris ___ OpenStack-dev mailing list 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.com; anlin.k...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [OpenStack-dev] How to modify a bug across multiple repo?
Hi all, Recently, I found a bug at API layer in Cinder, but the modifications relate to CinderClient Tempest. So, I'm confused how to commit it. Can 'git --dependence' cross different Repo? Any help would be much appreciated. Regards, wingwj ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
