[openstack-dev] [nova] Stein summit forum sessions and presentations of interest
Howdy all, We've made a list of cross-project forum sessions and nova-related sessions/presentations that you might be interested in attending at the summit and added them to our forum etherpad: https://etherpad.openstack.org/p/nova-forum-stein The "Cross-project Forum sessions that should include nova participation" section contains a list of community sessions where it would be nice to have a nova representative in attendance. Please feel free to add your name to sessions you think you could attend and bring back any interesting info to the team. Let know if I've missed any cross-project sessions or nova-related sessions/presentations and I can add them. Looking forward to seeing you all at the summit! Cheers, -melanie __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Announcing new Focal Point for s390x libvirt/kvm Nova
On Fri, 2 Nov 2018 09:47:42 +0100, Andreas Scheuring wrote: Dear Nova Community, I want to announce the new focal point for Nova s390x libvirt/kvm. Please welcome "Cathy Zhang” to the Nova team. She and her team will be responsible for maintaining the s390x libvirt/kvm Thirdparty CI [1] and any s390x specific code in nova and os-brick. I personally took a new opportunity already a few month ago but kept maintaining the CI as good as possible. With new manpower we can hopefully contribute more to the community again. You can reach her via * email: bjzhj...@linux.vnet.ibm.com * IRC: Cathyz Cathy, I wish you and your team all the best for this exciting role! I also want to say thank you for the last years. It was a great time, I learned a lot from you all, will miss it! Cheers, Andreas (irc: scheuran) [1] https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI Thanks Andreas, for sending this note. It has been a pleasure working with you over these years. We wish you the best of luck in your new opportunity! Welcome to the Nova community, Cathy! We look forward to working with you. Please feel free to reach out to us on IRC in the #openstack-nova channel and on this mailing list with the [nova] tag to ask questions and share info. Best, -melanie __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] no meeting the next two weeks
Howdy all, This is a heads up that we will not hold a nova meeting next week November 15 because of summit week. And we will also not hold a nova meeting the following week November 22 because of the US holiday of Thanksgiving, as we're unlikely to find anyone to run it during the 2100 UTC time slot. Meetings will resume on November 29 at 1400 UTC. I'm looking forward to seeing all of you at the summit next week! Cheers, -melanie __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Stein forum session notes
Hey all, Here's some notes I took in forum sessions I attended -- feel free to add notes on sessions I missed. Etherpad links: https://wiki.openstack.org/wiki/Forum/Berlin2018 Cheers, -melanie TUE --- Cells v2 updates - Went over the etherpad, no objections to anything - Not directly related to the session, but CERN (hallway track) and NeCTAR (dev ML) have both given feedback and asked that the policy-driven idea for handling quota for down cells be avoided. Revived the "propose counting quota in placement" spec to see if there's any way forward here Getting users involved in the project = - Disconnect between SIGs/WGs and project teams - Too steep a first step to get involved by subscribing to ML - People confused about how to participate Community outreach when culture, time zones, and language differ - Most discussion around how to synchronize real-time communication considering different time zones - Best to emphasize asynchronous communication. Discussion on ML and gerrit reviews - Helpful to create weekly meeting agenda in advance so contributors from other time zones can add notes/response to discussion items WED --- NFV/HPC pain points === Top issues for immediate action: NUMA-aware live migration (spec just needs re-approval), improved scheduler logging (resurrect cfriesen's patch and clean it up), distant third is SRIOV live migration BFV improvements - Went over the etherpad, no major objections to anything - Agree: we should expose boot_index from the attachments API - Unclear what to do about post-create delete_on_termination. Being able to specify it for attach sounds reasonable, but is it enough for those asking? Or would it end up serving no one? Better expose what we produce = - Project teams should propose patches to openstack/openstack-map to improve their project pages - Would be ideal if project pages included a longer paragraph explaining the project, have a diagram, list SIGs/WGs related to the project, etc Blazar reservations to new resource types = - For nova compute hosts, reservations are done by putting reserved hosts into "blazar" host aggregate and then a special scheduler filter is used to exclude those hosts from scheduling. But how to extend that concept to other projects? - Note: the nova approach will change from scheduler filter => placement request filter Edge use cases and requirements === - Showed the reference architectures again - Most popular use case was "Mobile service provider 5G/4G virtual RAN deployment and Edge Cloud B2B2X" with seven +1s on the etherpad Deletion of project and project resources = - What is wanted: a delete API per service that takes a project_id and force deletes all resources owned by it with --dry-run component - Challenge to work out the dependencies for the order of deletion of all resources in all projects. Disable project, then delete things in order of dependency - Idea: turn os-purge into a REST API and each project implement a plugin for it Getting operators' bug fixes upstreamed === - Problem: operator reports a bug and provides a solution, for example, pastes a diff in launchpad or otherwise describes how to fix the bug. How can we increase the chances of those fixes making it to gerrit? - Concern: are there legal issues with accepting patches pasted into launchpad by someone who hasn't signed the ICLA? - Possible actions: create a best practices guide tailored for operators and socialize it among the ops docs/meetup/midcycle group. Example: guidance on how to indicate you don't have time to add test coverage, etc when you propose a patch THU --- Bug triage: why not all the community? == - Cruft and mixing tasks with defect reports makes triage more difficult to manage. Example: difference between a defect reported by a user vs an effective TODO added by a developer. If New bugs were reliably from end users, would we be more likely to triage? - Bug deputy weekly ML reporting could help - Action: copy the generic portion of the nova bug triage wiki doc into the contributor guide docs. The idea/hope being that easy-to-understand instructions available to the wider community might increase the chances of people outside of the project team being capable of triaging bugs, so all of it doesn't fall on project teams - Idea: should we remove the bug supervisor requirement from nova to allow people who haven't joined the bug team to set Status and Importance? Current state of volume encryption == - Feedback: public clouds can't offer encryption because keys are stored in the cloud. Telco
Re: [openstack-dev] [nova] Stein forum session notes
On Mon, 19 Nov 2018 17:19:22 +0100, Surya Seetharaman wrote: On Mon, Nov 19, 2018 at 2:39 PM Matt Riedemann <mailto:mriede...@gmail.com>> wrote: On 11/19/2018 3:17 AM, melanie witt wrote: > - Not directly related to the session, but CERN (hallway track) and > NeCTAR (dev ML) have both given feedback and asked that the > policy-driven idea for handling quota for down cells be avoided. Revived > the "propose counting quota in placement" spec to see if there's any way > forward here Should this be abandoned then? https://review.openstack.org/#/c/614783/ Since there is no microversion impact to that change, it could be added separately as a bug fix for the down cell case if other operators want that functionality. But maybe we don't know what other operators want since no one else is at multi-cell cells v2 yet. I thought the policy check was needed until the "propose counting quota in placement" has been implemented as a workaround and that is what the "handling down cell" spec also proposed, unless the former spec would be implemented within this cycle in which case we do not need the policy check. Right, I don't think that anyone _wants_ the policy check approach. That was just the workaround, last resort idea we had for dealing with down cells in the absence of being able to count quota usage from placement. The operators we've discussed with (CERN, NeCTAR, Oath) would like quota counting not to depend on cell databases, if possible. But they are understanding and will accept the policy-driven workaround if we can't move forward with counting quota usage from placement. If we can get agreement on the count quota usage from placement spec (I have updated it with new proposed details), then we should abandon the policy-driven behavior patch. I am eager to find out what everyone thinks of the latest proposal. Cheers, -melanie __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] StarlingX gap analysis to converge with OpenStack master
On Wed, 21 Nov 2018 12:11:50 -0600, Miguel Lavalle wrote: One of the key goals of StarlingX during the current cycle is to converge with the OpenStack projects master branches. In order to accomplish this goal, the Technical Steering Committee put together a gap analysis that shows the specs and patches that need to merge in the different OpenStack projects by the end of Stein. The attached PDF document shows this analysis. Although other projects are involved, most of the work has to be done in Nova, Neutron and Horizon. Hopefully all the involved projects will help StarlingX achieve this important goal. It has to be noted that work is still on-going to refine this gap analysis, so there might be some updates to it in the near future. Thanks for sending this out. I'm going to reply about what I know of the status of nova-related planned upstream features. On NUMA-aware live migration, it was identified as the top priority issue in the NFV/HPC pain points forum session [1]. The spec has been approved before in the past for the Rocky cycle, so it's a matter of re-proposing it for re-approval in Stein. We need to confirm with artom and/or stephenfin whether one of them can pick it up this cycle. I don't know as much about the shared/dedicated vCPUs on a single host or the shared vCPU extension, but the cited spec [2] has one +2 already. If we can find a second approver, we can work on this too in Stein. The vTPM support spec was merged about two weeks ago and we are awaiting implementation patches from cfriesen. The HPET support spec was merged about two weeks ago and the implementation patch is under active review in a runway with one +2 now. For vCPU model, I'm not aware of any new proposed spec for Stein from the STX community as of today. Let us know if/when the spec is proposed. For disk performance fixes, the specless blueprint patch is currently under active review in a runway. The extra spec validation spec [3] is under active review now. For the bits that will be addressed using upstream features that are already available, I assume the STX community will take care of this. Please reach out to us in #openstack-nova or on the ML if there are questions/issues. For the bugs, again feel free to reach out to us for reviews/help. Cheers, -melanie [1] https://etherpad.openstack.org/p/BER-nfv-hpc-pain-points [2] https://review.openstack.org/555081 [3] https://review.openstack.org/618542 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] StarlingX gap analysis to converge with OpenStack master
On Wed, 21 Nov 2018 21:23:51 +0100, Melanie Witt wrote: On Wed, 21 Nov 2018 12:11:50 -0600, Miguel Lavalle wrote: One of the key goals of StarlingX during the current cycle is to converge with the OpenStack projects master branches. In order to accomplish this goal, the Technical Steering Committee put together a gap analysis that shows the specs and patches that need to merge in the different OpenStack projects by the end of Stein. The attached PDF document shows this analysis. Although other projects are involved, most of the work has to be done in Nova, Neutron and Horizon. Hopefully all the involved projects will help StarlingX achieve this important goal. It has to be noted that work is still on-going to refine this gap analysis, so there might be some updates to it in the near future. Thanks for sending this out. I'm going to reply about what I know of the status of nova-related planned upstream features. On NUMA-aware live migration, it was identified as the top priority issue in the NFV/HPC pain points forum session [1]. The spec has been approved before in the past for the Rocky cycle, so it's a matter of re-proposing it for re-approval in Stein. We need to confirm with artom and/or stephenfin whether one of them can pick it up this cycle. Turns out this spec has already been re-proposed for Stein as of Sep 4: https://review.openstack.org/599587 and is under active review now. Apologies for missing this in my previous reply. I don't know as much about the shared/dedicated vCPUs on a single host or the shared vCPU extension, but the cited spec [2] has one +2 already. If we can find a second approver, we can work on this too in Stein. The vTPM support spec was merged about two weeks ago and we are awaiting implementation patches from cfriesen. The HPET support spec was merged about two weeks ago and the implementation patch is under active review in a runway with one +2 now. For vCPU model, I'm not aware of any new proposed spec for Stein from the STX community as of today. Let us know if/when the spec is proposed. For disk performance fixes, the specless blueprint patch is currently under active review in a runway. The extra spec validation spec [3] is under active review now. For the bits that will be addressed using upstream features that are already available, I assume the STX community will take care of this. Please reach out to us in #openstack-nova or on the ML if there are questions/issues. For the bugs, again feel free to reach out to us for reviews/help. Cheers, -melanie [1] https://etherpad.openstack.org/p/BER-nfv-hpc-pain-points [2] https://review.openstack.org/555081 [3] https://review.openstack.org/618542 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] python-novaclient: uses deprecated keyring.backend.$keyring
On Nov 24, 2013, at 7:37 AM, Thomas Goirand wrote: > Someone sent a bug report against the python-novaclient package: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728470 > > Could someone take care of this? FYI to the thread, this patch is now up for this issue: https://review.openstack.org/#/c/58364 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] Summit summary
On Nov 19, 2014, at 11:38, Everett Toews wrote: > Does anybody know what happened to the Etherpad? It’s completely blank now!!! > > If you check the Timeslider, it appears that it only ever existed on Nov. 15. > Bizarre. I see it as blank now too, however I can see all of the previous revisions and content when I drag the timeslider back. melanie (melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Versioned objects cross project sessions next steps
On Nov 24, 2014, at 13:06, Jay Pipes wrote: > That said, I don't think it's wise to make oslo-versionedobjects be a totally > new thing. I think we should use nova.objects as the base of a new > oslo-versionedobjects library, and we should evolve oslo-versionedobjects > slowly over time, eventually allowing for nova, ironic, and whomever else is > currently using nova/objects, to align with an Oslo library vision for this. > > So, in short, I also think a) is the appropriate path to take. +1 I'd like to see oslo-versionedobjects start out with nova.objects as the implementation, with the ability to add support for protobuf later. melanie (melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] bug 1334398 and libvirt live snapshot support
On Dec 8, 2014, at 13:12, Jeremy Stanley wrote: > I'm dubious of this as it basically says "we know this breaks > sometimes, so we're going to stop testing that it works at all and > possibly let it get even more broken, but you should be safe to rely > on it anyway." +1, it seems bad to enable something everywhere *except* the gate. I prefer the original suggestion to include a config option that is by default disabled that a user can enable if they want. From what I understand, the feature works "most of the time" and I don't see why a user is guaranteed not to encounter the same conditions that happen in the gate. For that reason I think it makes sense to be an experimental, opt-in by config, feature. melanie (melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] nova-manage db archive_deleted_rows broken
Hi everybody, At some point, our db archiving functionality got broken because there was a change to stop ever deleting instance system metadata [1]. For those unfamiliar, the 'nova-manage db archive_deleted_rows' is the thing that moves all soft-deleted (deleted=nonzero) rows to the shadow tables. This is a periodic cleaning that operators can do to maintain performance (as things can get sluggish when deleted=nonzero rows accumulate). The change was made because instance_type data still needed to be read even after instances had been deleted, because we allow admin to view deleted instances. I saw a bug [2] and two patches [3][4] which aimed to fix this by changing back to soft-deleting instance sysmeta when instances are deleted, and instead allow read_deleted="yes" for the things that need to read instance_type for deleted instances present in the db. My question is, is this approach okay? If so, I'd like to see these patches revive so we can have our db archiving working again. :) I think there's likely something I'm missing about the approach, so I'm hoping people who know more about instance sysmeta than I do, can chime in on how/if we can fix this for db archiving. Thanks. [1] https://bugs.launchpad.net/nova/+bug/1185190 [2] https://bugs.launchpad.net/nova/+bug/1226049 [3] https://review.openstack.org/#/c/110875/ [4] https://review.openstack.org/#/c/109201/ melanie (melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] nova-specs and python-novaclient
On Apr 23, 2014, at 17:15, Michael Still wrote: > I don't think we should block the possibility of there being a > novaclient specific BP sometime in the future. When we think of a good > reason for one, let's just put it in a subdirectory. I agree. For example, this blueprint is about improving novaclient tests: https://blueprints.launchpad.net/python-novaclient/+spec/httpretty-testing We weren't sure how reviewing and approving novaclient blueprints will work now with the new nova-specs process. signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient
On May 6, 2014, at 15:22, Jamie Lennox wrote: > If there are concerns with this process please respond here and/or on the > review. This sounds like it would be a fix for a bug affecting clients that I was looking at recently: https://bugs.launchpad.net/python-novaclient/+bug/1154809 If so, maybe we can add a note in the bug linking to this work. signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] locked instances and snaphot
Hi all, Recently a nova bug [1] was opened where the user describes a scenario where an instance that is locked is still able to be snapshotted (create image and backup). In the case of Trove, instances are locked "...to ensure integrity and protect secrets which are needed by the resident Trove Agent." However, the end-user can still take a snapshot of the instance to create an image while it's locked, and restore the image later. The end-user then has access to the restored image. During the patch review, a reviewer raised a concern about the purpose of instance locking and whether prevention of snapshot while an instance is locked is appropriate. From what we understand, instance lock is meant to prevent unwanted modification of an instance. Is snapshotting considered a logical modification of an instance? That is, if an instance is locked to a user, they take a snapshot, create another instance using that snapshot, and modify the instance, have they essentially modified the original locked instance? I wanted to get input from the ML on whether it makes sense to disallow snapshot an instance is locked. Thanks, melanie [1] https://bugs.launchpad.net/nova/+bug/1314741 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] locked instances and snaphot
On Jun 16, 2014, at 13:56, Michael Still wrote: > It is certainly my belief that the lock functionality for instances is > about avoiding accidental changes to the instance itself, not the > contents of the instance. I personally think that snapshots aren't a > change to the instance and therefore should be allowed, but I'd be > interested in other people's thoughts on this. Thank you for sharing your view. I'm also interested in hearing other thoughts -- if the consensus is to allow snapshot of a locked instance, I can close the loop on the lp bug for the reporter. If anyone else has some input on snapshotting locked instances, please chime in! signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Manila] ./run_tests issue
On Sep 21, 2014, at 23:31, Deepak Shetty wrote: > Even better, whenever ./run_tests fail... maybe put a msg stating the > following C libs needs to be installed, have the user check the > same..something like that would help too. I don't think it should be a human-maintained list, otherwise it's prone to fall out of date or be incomplete in some way. FWIW, simply typing the error message in google and taking the first result e.g. "fatal error: my_config.h: No such file or directory" solves these obstacles in seconds, at least for me. signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Support the Ada Initiative: A Challenge to the OpenStack Communtiy
On Oct 6, 2014, at 15:15, Anne Gentle wrote: > You got it Mike! Donating now! > > This is awe-inspiring. Male allies are what we need, and you are delivering. +1, and thank you Mike for sharing information about the Ada Initiative with us. signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On Nov 4, 2014, at 0:32, Doug Hellmann wrote: >>> I think this is reasonable, though do we actually support setting >>> the same key twice ? > > Yes, if it is registered in different groups. I have found that for a MultiStrOpt, the same key can be set multiple times even in the same group, and the result is a list of values for that option [0]. [0] https://github.com/openstack/oslo.config/blob/11ecf18/oslo/config/cfg.py#L1011 signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] locked instances and snaphot
On Jun 17, 2014, at 13:34, Andrew Laski wrote: > It appears that locking was added in 2010 > (8aea573bd2e44e152fb4ef1627640bab1818dede), at which time commit messages > weren't nearly as clear and helpful as they now are so there's not much > insight from that. But the lock checking methods added at that time have a > docstring that includes "decorator used for preventing action against locked > instances". So the original intent seems to be that API actions would not be > allowed against locked instances. From that point of view snapshotting > should be disallowed. That's what I was going on initially too. I was ignorant about what locking instances is really for and didn't find documentation about it other than some anecdotal things in ML archive. > Having said that, the main reason that I've heard for locks being used is to > prevent accidental deletes. And I've heard requests for locks that only > prevent deletes. So in my experience users want more granular locks, not > more inclusive locking. So I wouldn't consider it a bug that snapshots are > allowed while an instance is locked. That's interesting and good to know. > But getting back to the original issue, I'm not sure locking snapshots is > going to help. The intent seems to be keeping users from gaining access to > data that's within the instance. But locks don't keep a user from seeing > what's on the instance, or doing something like an LVM snapshot of the data > from within the instance. That's true and underscores why locking as a security measure doesn't make much sense. There are too many ways to get around it that you end up with a quite incomplete lockdown. I think we have consensus that instance locking to protect content isn't an appropriate use of the feature and anyway isn't a complete solution to that problem. Instance locking prevents accidental changes/deletion of an instance by way of the api. And in Michael's example scenario of having to unlock (and risk accidental change/delete) in order to take a snapshot of an important instance, disabling snapshot of a locked instance would actively disrupt the expected use case of instance locking. Thanks all for the discussion -- I learned a lot about this feature and I'll be updating the lp bug (not a bug) and review. signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] locked instances and snaphot
On Jun 19, 2014, at 13:27, Michael Still wrote: > It might be a good idea to add a comment to the RPC layer for the > snapshot call explaining why we haven't implemented a lock check. That > would reduce future confusion as well. I think that's a good idea -- will do that. signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [hacking] rules for removal
On Jun 20, 2014, at 11:07, Sean Dague wrote: > H402 - 1 line doc strings should end in punctuation. The real statement > is this should be a summary sentence. A sentence is not just a set of > words that end in a period. Squirel fast bob. It's something deeper. > This rule thus isn't really semantically useful, especially when you are > talking about at 69 character maximum (79 - 4 space indent - 6 quote > characters). +1 > H803 - First line of a commit message must *not* end in a period. This > was mostly a response to an unreasonable core reviewer that was -1ing > people for not having periods. I think any core reviewer that -1s for > this either way should be thrown off the island, or at least made fun > of, a lot. Again, the clarity of a commit message is not made or lost by > the lack or existence of a period at the end of the first line. +1 > H305 - Enforcement of libraries fitting correctly into stdlib, 3rdparty, > our tree. This biggest issue here is it's built in a world where there > was only 1 viable python version, 2.7. Python's stdlib is actually > pretty dynamic and grows over time. As we embrace more python 3, and as > distros start to make python3 be front and center, what does this even > mean? The current enforcement can't pass on both python2 and python3 at > the same time in many cases because of that. I also find the grouping useful for knowing the scope of a module at a glance. But I definitely see the problem with not being able to fit python 2 and 3 at the same time. If Clint's suggestion of algorithm to sort it out wouldn't be too difficult to add, it would be nice. I'm also strongly for commit messages that make sense and explain what's changing and why, and reference related bugs and docs whenever possible. signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Meeting this week?
On Jun 29, 2014, at 17:01, Michael Still wrote: > Hi. The meeting this week would be on the 3rd of July, which I assume > means that many people will be out of the office. Do people think its > worth running the meeting or shall we give this week a miss? July 3 is a company holiday where I am, so I'm also +1 on skipping this week. signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][libvirt] why use domain destroy instead of shutdown?
Hi all, I noticed in nova/virt/libvirt/driver.py we use domain destroy instead of domain shutdown in most cases (except for soft reboot). Is there a special reason we don't use shutdown to do a graceful shutdown of the guest for the stop, shelve, migrate, etc functions? Using destroy can corrupt the guest file system. Thanks, Melanie signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][libvirt] why use domain destroy instead of shutdown?
On Jul 4, 2014, at 3:11, "Day, Phil" wrote: > I have a BP (https://review.openstack.org/#/c/89650) and the first couple of > bits of implementation (https://review.openstack.org/#/c/68942/ > https://review.openstack.org/#/c/99916/) out for review on this very topic ;-) Great, I'll review and add my comments then. I'm interested in this because I have observed a problematic number of guest file system corruptions when migrating RHEL guests because of the hard power off. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] fastest way to run individual tests ?
On Jul 9, 2014, at 13:51, Matt Riedemann wrote: > I've been beating my head against the wall a bit on unit tests too this week, > and here is another tip that just uncovered something for me when python -m > testtools.run and nosetests didn't help. > > I sourced the tox virtualenv and then ran the test from there, which gave me > the actual error, so something like this: > > source .tox/py27/bin/activate > python -m testtools.run > > Props to Matt Odden for helping me with the source of the venv tip. This is awesome, thank you for sharing. signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][bugs] request to add user hudson-openstack to nova-bugs team
Hi Nova Bug Wranglers, There have been some issues where the gerrit hook script is unable to link a review to a launchpad bug e.g. no comment is posted to launchpad when a fix has been proposed, even when the submitter has included the appropriate text "Closes-Bug: #" in the commit message. This leads to confusion as potential bug fixers come to a bug and see it's not assigned to anyone and no fix proposed, yet in reality a patch is up for review. Jeremy Stanley mentioned in this bug about the issue [1], that the gerrit hook script cannot *reassign* a bug unless it's a member of the bug supervisor group, in this case, nova-bugs. An example problem scenario would be if someone proposes a fix before assigning the bug to themselves. The bug would then remain unassigned and no comment would be posted on it by the hudson-openstack user showing that a fix has been proposed. The hudson-openstack user is not a member of nova-bugs [2] at present. Does anyone how to add a user to the team? I see the owner is the OpenStack Administrators team. Can any member of the OpenStack Administrators add hudson-openstack please? Melanie [1] https://bugs.launchpad.net/python-novaclient/+bug/1326503/comments/5 [2] https://launchpad.net/~nova-bugs signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][bugs] request to add user hudson-openstack to nova-bugs team
On Jul 14, 2014, at 16:53, "Michael Still" wrote: > Jeremy helped me with this on IRC, and the hudson bot is now a member > of that group. Wonderful -- thank you both! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Disable async network allocation
On Oct 23, 2013, at 5:56 PM, Aaron Rosen wrote: > I believe he's referring to: > https://github.com/openstack/nova/blob/master/nova/network/model.py#L335 > https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L1211 I found some more background on the feature (not configurable) which might help in trying revert it for testing. https://blueprints.launchpad.net/nova/+spec/async-network-alloc There was also addition of config option 'network_allocate_retries' which defaults to 0: https://review.openstack.org/#/c/34473/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Disable async network allocation
On Oct 24, 2013, at 7:47 AM, "Day, Phil" wrote: > Yep, that was the feature I was referring to. > > As I said I don't have anything defiant that shows this to be not working > (and the code looks fine) - just wanted to try and simplify the world a bit > for a while. Of course. That's what I meant, that you might be able to use the info to revert it locally in your environment to help you track down the Neutron issue you're investigating. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] XML Support for Nova v3 API
Me too, that was sort of awesome. I also wish we could get rid of XML but that might be primarily because I find it awkward to work with the way it is now. As was mentioned before, I think the main thing is making it easier to support. The autogeneration idea is great. On Jun 20, 2013, at 4:10 AM, Davanum Srinivas wrote: > You had me going there for a minute, Jay! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] security groups extension for Nova v3 API
On Jun 20, 2013, at 5:36 PM, Christopher Yeoh wrote: > The management of security groups can be handled through the > project-formerly-known-as-quantum, but the (dis)association of security > groups to instances does I think need to be handled by Nova. So we'll need > the SecurityGroupActionController and SecurityGroupsOutputController > > So if you're willing to clean up the v3 port you've done and get it merged, > that would be very helpful. Makes sense. I'll update my patch and submit it for review. Thanks for the heads up. Melanie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Termination of the title line of commit messages
On Jun 24, 2013, at 2:50 PM, Mark McLoughlin wrote: > > Unlike other nitpicking I tend to do with commit messages, I previously > never thought this was worth even mentioning to committers but if some > reviewers were going to start -1ing people for the *correct* style then > I figured it was best to clear it up. I too have never thought it worth mentioning, similar to capitalizing the first word of the first line of the commit message or not. I thought any way works, as long as the first line is brief so it shows up nicely browsing on github. Personally, I treat the first line like you mention the subject line of an email, which I never capitalize or use a period at the end. Melanie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] security_groups extension in nova api v3
Hi All, I did the initial port of the security_groups api extension to v3 and have been testing it out in devstack while adding the expected_errors decorator to it. The guidance so far on network-related extensions in v3 is not to duplicate actions that can be accomplished through the neutron api and assuming nova-network deprecation is imminent. So, the only actions left in the extension are the associate/disassociate security group with instance. However, when security_group_api = neutron, all associate/disassociate will do is call the neutron api to update the port for the instance (port device_id == instance uuid) and append the specified security group. I'm wondering if this falls under the nova proxying we don't want to be doing and if associate/disassociate should be removed from the extension for v3. If removed, it would leave the extension only providing support for server_create (cyeoh has a patch up for review). Any opinions? Thanks, Melanie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] security_groups extension in nova api v3
On Aug 13, 2013, at 2:11 AM, Day, Phil wrote: > If we really want to get clean separation between Nova and Neutron in the V3 > API should we consider making the Nov aV3 API only accept lists o port ids in > the server create command ? > > That way there would be no need to every pass security group information into > Nova. > > Any cross project co-ordination (for example automatically creating ports) > could be handled in the client layer, rather than inside Nova. Server create is always (until there's a separate layer) going to go cross project calling other apis like neutron and cinder while an instance is being provisioned. For that reason, I tend to think it's ok to give some extra convenience of automatically creating ports if needed, and being able to specify security groups. For the associate and disassociate, the only convenience is being able to use the instance display name and security group name, which is already handled at the client layer. It seems a clearer case of duplicating what neutron offers. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] v3 api remove security_groups extension (was Re: security_groups extension in nova api v3)
On Aug 13, 2013, at 3:35 PM, Melanie Witt wrote: > On Aug 13, 2013, at 2:11 AM, Day, Phil wrote: > >> If we really want to get clean separation between Nova and Neutron in the V3 >> API should we consider making the Nov aV3 API only accept lists o port ids >> in the server create command ? >> >> That way there would be no need to every pass security group information >> into Nova. >> >> Any cross project co-ordination (for example automatically creating ports) >> could be handled in the client layer, rather than inside Nova. > > Server create is always (until there's a separate layer) going to go cross > project calling other apis like neutron and cinder while an instance is being > provisioned. For that reason, I tend to think it's ok to give some extra > convenience of automatically creating ports if needed, and being able to > specify security groups. > > For the associate and disassociate, the only convenience is being able to use > the instance display name and security group name, which is already handled > at the client layer. It seems a clearer case of duplicating what neutron > offers. Thinking about this more, it seems like the security_groups extension should probably be removed in the v3 api. Originally, we considered not porting it to v3 because it's a network-related extension whose actions can be accomplished through neutron directly. Then, it seemed associate/disassociate the with instance would be needed in nova, and those actions alone were ported. However, looking into the code more I found that's simply a neutron port update (append security group to port). Server create is similar. It seems like the extension isn't really needed in v3. Does anyone have any objection to removing it? Melanie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] v3 api remove security_groups extension (was Re: security_groups extension in nova api v3)
On Aug 15, 2013, at 1:13 PM, Joe Gordon wrote: > +1 from me as long as this wouldn't change anything for the EC2 API's > security groups support, which I assume it won't. Correct, it's unrelated to the ec2 api. We discussed briefly in the nova meeting today and there was consensus that removing the standalone associate/disassociate actions should happen. Now the question is whether to keep the server create piece and not remove the extension entirely. The concern is about a delay in the newly provisioned instance being associated with the desired security groups. With the extension, the instance gets the desired security groups before the instance is active (I think). Without the extension, the client would receive the active instance and then call neutron to associate it with the desired security groups. Would such a delay in associating with security groups be a problem? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] python-novaclient 2.32.0 not working with rackspace
Hi everyone, We have an issue [1] in python-novaclient 2.32.0 where it's not working with rackspace cloud. It's caused by a commit [2] that changed the default requested compute API version from "latest" to "client supported latest", a specific version. We have some logic in the discover_version method that does comparisons between a user-specified version and the server version. For rackspace, we get a "null" server version because the version list API isn't exposed. The discover_version falls back on compute API 2.0 when requested version is "latest" and server version is "null" but raises an error when requested version is "user-specified" and server version is "null". So more work is needed there to handle cases where version API isn't exposed. Should we revert [2] for now? Any other thoughts? Thanks, -melanie (irc: melwitt) [1] https://bugs.launchpad.net/python-novaclient/+bug/1508244 [2] https://review.openstack.org/#/c/230024/ signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Proposal to add Alex Xu to nova-core
On Nov 6, 2015, at 7:32, John Garbutt wrote: > Hi, > > I propose we add Alex Xu[1] to nova-core. > > Over the last few cycles he has consistently been doing great work, > including some quality reviews, particularly around the API. > > Please respond with comments, +1s, or objections within one week. > > Many thanks, > John > > [1]http://stackalytics.com/?module=nova-group&user_id=xuhj&release=all > > __ > 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 +1 -melanie (irc: melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Proposal to add Sylvain Bauza to nova-core
On Nov 6, 2015, at 7:32, John Garbutt wrote: > Hi, > > I propose we add Sylvain Bauza[1] to nova-core. > > Over the last few cycles he has consistently been doing great work, > including some quality reviews, particularly around the Scheduler. > > Please respond with comments, +1s, or objections within one week. > > Many thanks, > John > > [1] > http://stackalytics.com/?module=nova-group&user_id=sylvain-bauza&release=all > > __ > 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 +1 -melanie (irc: melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] nova-manage db archive_deleted_rows broken
On Nov 20, 2015, at 6:18, Sean Dague wrote: > instance_actions seems extremely useful, and at the ops meetups I've > been to has been one of the favorite features because it allows and easy > interface for "going back in time" to figure out what happened. Agreed, we're using it because it's such a quick and easy way to see what actions have been taken on an instance when users need support. We're not yet collecting notifications from the queue -- we do have them being dumped to the logs that are splunk searchable. So far, it hasn't been "easy" to look at instance action history that way. > I'd suggest the following: > > 1. soft deleting and instance does nothing with instance actions. > > 2. archiving instance (soft delete -> actually deleted) also archives > off instance actions. > > 3. update instance_actions API so that you can get instance_actions for > deleted instances (which I think doesn't work today). +1 I kept trying to craft a reply to this thread and fortunately I waited long enough that someone else said exactly what I was trying to say. -melanie (irc: melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]New Quota Subteam on Nova
On Nov 26, 2015, at 9:36, John Garbutt wrote: > A suggestion in the past, that I like, is creating a nova functional > test that stress tests the quota code. > > Hopefully that will be able to help reproduce the error. > That should help prove if any proposed fix actually works. +1, I think it's wise to get some data on the current state of quotas before choosing a redesign. IIRC, Joe Gordon described a test scenario he used to use to reproduce quota bugs locally, in one of the launchpad bugs. If we could automate something like that, we could use it to demonstrate how quotas currently behave during parallel requests and try things like disabling reservations. I also like the idea of being able to verify the effects of proposed fixes. -melanie (irc: melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]New Quota Subteam on Nova
-@openstack On Dec 1, 2015, at 11:45, Vilobh Meshram wrote: > If you can share the details of the bug that Joe mentioned, to reproduce > quota bugs locally, it would be helpful. Here's the bug comment I was thinking of, #15 by jogo on the script he used to make quotas go out of sync while restarting nova-api during the test [1]. Thanks to mriedem for finding it. On the parallel request bug [2], if you check out alaski's comment #3, he mentions the keypairs and security groups apis check quota without using the reservation system. We should investigate why they don't and whether we can convert them to use the reservation system. I think that would provide a lot of improvement. Bug [2] implies there aren't issues with exceeding quotas for apis other than the keypairs and security groups, so I'm curious if other apis are affected. It would be another useful set of functional tests to do parallel requests per api and see which apis can exceed quota in that scenario. -melanie [1] https://bugs.launchpad.net/nova/+bug/1284424 [2] https://bugs.launchpad.net/nova/+bug/1301532 signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] upgrade connection_info when Ceph mon IP changed
On Wed, 18 May 2016 14:30:00 -0500, Matt Riedemann wrote: While convenient as a workaround, I'm not in favor of the idea of adding something to the REST API so a user can force refresh the connection info - this is a bug and leaks information out of the API about how the cloud is configured. If you didn't have volumes attached to the instance at all then this wouldn't matter. I think in an earlier version of the patch it was reloading and checking the connection info every time the BDM list was retrieved for an instance, which was a major issue for normal operations where this isn't a problem. Since it's been scoped to just start/reboot operations, it's better, and there are comments in the patch to make it a bit more efficient also (avoid calling the DB multiple times for the same information). I'm not totally opposed to doing the refresh on start/reboot. We could make it configurable, so if you're using a storage server backend where the IP might change, then set this flag, but that's a bit clunky. And a periodic task wouldn't help us out. I'm open to other ideas if anyone has them. I was thinking it may be possible to do something similar to how network info is periodically refreshed in _heal_instance_info_cache [1]. The task interval is configurable (defaults to 60 seconds) and works on a queue of instances such that one is refreshed per period, to control the load on the host. To avoid doing anything for storage backends that can't change IP, maybe we could make the task return immediately after calling a driver method that would indicate whether the storage backend can be affected by an IP change. There would be some delay until the task runs on an affected instance, though. -melanie [1] https://github.com/openstack/nova/blob/9a05d38/nova/compute/manager.py#L5549 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Proposing Andrey Kurilin for python-novaclient core
On Wed, 13 Apr 2016 12:53:12 -0500, Matt Riedemann wrote: I'd like to propose that we make Andrey Kurilin core on python-novaclient. He's been doing a lot of the maintenance the last several months and a lot of times is the first to jump on any major issue, does a lot of the microversion work, and is also working on cleaning up docs and helping me with planning releases. His work is here [1]. Review stats for the last 4 months (although he's been involved in the project longer than that) [2]. Unless there is disagreement I plan to make Andrey core by the end of the week. [1] https://review.openstack.org/#/q/owner:akurilin%2540mirantis.com+project:openstack/python-novaclient [2] http://stackalytics.com/report/contribution/python-novaclient/120 +1 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [devstack] Adding example "local.conf" files for testing?
On Thu, 14 Apr 2016 13:17:48 -0500, Dean Troyer wrote: My only real concern is you've implied a structure that will potentially have many combinations of configurations and those will bitrot. How different are x86 and s390 arch in local.conf? (I've never seen an s390 local.conf!) I do know there are few, if any, differences between most ubuntu and fedora configs, we abstract most of that out in the scripts. I wonder if the grouping of configs might be better suited along usa-case lines? nova-net vs neutron, single- vs multi-node, etc. +1. This already exists to some extent in the devstack documentation but it's a bit scattered [1][2] and I rummage around to find it when I need it. For multi-node I have also gone to find a recent multi-node tempest job run to copy some devstack local.conf settings before. So, I agree it would be helpful to have some use-case based samples in an easy to navigate place. -melanie [1] http://docs.openstack.org/developer/devstack/configuration.html#multi-node-setup [2] http://docs.openstack.org/developer/devstack/configuration.html#neutron __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Nova commands
On Tue, 19 Apr 2016 19:31:04 +0800, Kenny Ji-work wrote:
I have installed openstack mitaka, when I execute any nova's commands
with the result displayed below:
[root@devstack scripts]# nova list
*ERROR (AttributeError): 'unicode' object has no attribute 'get'*
I installed openstack as
the http://docs.openstack.org/mitaka/install-guide-rdo/ shows. Is there
somebody who encountered the issue? Thank you for answering!
This sounds like
https://bugs.launchpad.net/python-novaclient/+bug/1559072 and the fix is
included in python-novaclient 3.4.0.
What version of python-novaclient do you have ('nova --version')?
-melanie
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [neutron] the nova network facade that isn't
On Tue, 19 Apr 2016 10:02:46 -0400, Sean Dague wrote: Right, I think in the Havana timeframe, things were very different. Part of the rationale for full parity was that applications would be written against nova-network, and smoothly transition to neutron. But with over 90% neutron, assuming someone is writing to the nova-network API and not realizing it's the odd ball, I think is the wrong assumption. The APIs that work, they are what they are, but we should not make any more work. I think this sounds reasonable. Don't deprecate nova-network, let it be what it is and look at deprecating the neutron proxying (other than what occurs during the server create flow). It doesn't seem helpful at this point to have neutron users call through nova to do things with neutron. We could run this idea by for operator feedback to see if there are issues with it we haven't considered. -melanie __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] [Nova] continuing the "multiple compute host" discussion
On Dec 10, 2015, at 15:57, Devananda van der Veen wrote: > So, at this point, I think we need to accept that the scheduling of > virtualized and bare metal workloads are two different problem domains that > are equally complex. > > Either, we: > * build a separate scheduler process in Ironic, forking the Nova scheduler as > a starting point so as to be compatible with existing plugins; or > * begin building a direct integration between nova-scheduler and ironic, and > create a non-virtualization-centric resource tracker within Nova; or > * proceed with the plan we previously outlined, accept that this isn't going > to be backwards compatible with nova filter plugins, and apologize to any > operators who rely on the using the same scheduler plugins for baremetal and > virtual resources; or > * keep punting on this, bringing pain and suffering to all operators of bare > metal clouds, because nova-compute must be run as exactly one process for all > sizes of clouds. Speaking only for myself, I find the current direction unfortunate, but at the same time understandable, given how long it’s been discussed and the need to act now. It becomes apparent to me when I think about the future picture, if I imagine what the Compute API is should look like for all end users of vm/baremetal/container. They should be able to call one API to create an instance and the cloud will do the right things. I can see Nova being that API (entrypoint + scheduling, then handoff via driver to vm/baremetal/container API). An alternative would be a separate, new frontend API that hands off to a separate scheduling API (scheduler break out) that hands off to the various compute APIs (vm/baremetal/container). I realized that if we were able to do a 1:1 ratio of nova-compute to Ironic node, everything would work fine as-is. But I understand the problems with that as nova-compute processes can’t be run on the inventory nodes themselves, so you’re left with a ton of processes that you would have to find a place to run and it’s wasteful. Ironic doesn’t “fit in” to the model of 1:1 nova-compute to resource. My concern with the current plan is the need to sync constructs like aggregates and availability zones from one system (Nova) to the other (Ironic) in perpetuity. Users will have to set them up in both systems and keep them in sync. The code itself also has to be effectively duplicated along with filters and kept in sync. Eventually each of Nova and Ironic would be separate standalone systems, I imagine, to avoid having the sync issues. I’d rather we provided something like a more generic “Resource View API” in Nova that allows baremetal/container/clustered hypervisor environments to report resources via a REST API, and scheduling would occur based on the resources table (instead of having resource trackers). Each environment reporting resources would provide corresponding in-tree Nova scheduler filters that know what to do with resources related to them. Then scheduling would select a resource and lookup the compute host responsible for that resource, and nova-compute would delegate the chosen resource to, for example, Ironic. This same concept could exist in a separate scheduler service instead of Nova, but I don’t see why it can’t be in Nova. I figure we could either enhance Nova and eventually forklift the virtualization driver code out into a thin service that manages vms, or we could build a new frontend service and a scheduling service, and forklift the scheduling bits out of Nova so that it ends up being a thin service. The end result seems really similar to me, though one could argue that there are other systems that want to share scheduling code that aren’t provisioning compute, and thus scheduling would have to move out of Nova anyway. With the current direction, I see things going separate standalone with duplicated constructs and then eventually refactored to use common services down the road if and when they exist. I would personally prefer a direction toward something like a Resource View API in Nova that generalizes resources to avoid compute services, like Ironic, having to duplicate scheduling, aggregates, availability zones, etc. -melanie signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Next CellsV2 meeting is Jan 13 at 2100UTC
On Jan 6, 2016, at 11:41, Andrew Laski wrote: > As explained in > http://lists.openstack.org/pipermail/openstack-dev/2016-January/083216.html a > recurring calendar event based on alternating weeks will now be incorrect. I > had to fix my calendar and I expect others will want to do the same. Ah, I got caught up in this today with my calendar events -- thanks for the explanation. -melanie signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][testing] How to run a subset of py34 unit tests
Hi everyone,
I noticed because of the way we run the py34 tests in tox.ini, I'm not able to
specify a filter regex the way I normally do as a positional arg, for example:
'tox -epy34 nova.tests.unit.network' doesn't filter and it runs everything.
('tox -epy27 nova.tests.unit.network' will only run tests that match
nova.tests.unit.network).
I couldn't figure out how we could add something to tox.ini to make it work --
we're calling ostestr with the --blacklist_file option. I'm not completely
clear on what 'ostestr --blacklist_file --regex ' does but I
couldn't get it to do what I want. From the documentation [1], it adds --regex
to the regex created from the --blacklist_file. The regex from the blacklist
file looks something like this '^((?!blacklistedstuff).)*$' and if I can only
append to it, the best I could do was a positive lookbehind but that can't
match at the beginning of a line. (For example, I tried "ostestr
--blacklist_file tests-py3.txt --regex '(?<=network)'" and it matched all the
non-blacklisted tests that ended with the word "network"). It seems like what I
would need is for --regex to do another re.search() and match the line only if
the previous regex from the blacklist also matched.
As a workaround to run only network tests, I did:
source .tox/py34/bin/activate
OS_TEST_PATH=./nova/tests/unit/network ostestr --blacklist_file tests-py3.txt
Does anyone know a better way?
Thanks,
-melanie
[1] http://docs.openstack.org/developer/os-testr/ostestr.html#test-selection
signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][testing] How to run a subset of py34 unit tests
On Jan 22, 2016, at 19:14, Matthew Treinish wrote: > Although, now that I look at the list it definitely looks like this one, > which I had forgotten about: > > https://bugs.launchpad.net/os-testr/+bug/1506215 > > It sounds like that bug proposes a direction so if you could patch os-testr > to give that a try and see if that fixes your issue. If it does then we can > just land that in os-testr. Thanks!! That's indeed the same problem and removing the '$' from the exclude_regex worked for me. (ostestr --blacklist_file tests-py3.txt --regex "nova.tests.unit.network" ran all non-blacklisted network tests) > However, I'm wondering if it makes more sense to change how the selection > actually works with os-testr. This regex generation approach does get pretty > unwieldy and seems very error prone. I'm thinking it might make more sense to > generate a test-list and then have os-testr filter that list itself and then > pass the pruned list to --load-list in testr run. I could see that because conceptually the test selection has two stages: produce a list of non-blacklisted tests, then filter that list further as desired. Personally, using --blacklist_file and --regex seemed straightforward to me since I could specify the filter regex as I'm used to doing. It worked in my case but there might be cases I can't think of where the append method won't be able to give the desired result. -melanie signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][testing] How to run a subset of py34 unit tests
On Jan 25, 2016, at 17:57, melanie witt wrote: > Thanks!! That's indeed the same problem and removing the '$' from the > exclude_regex worked for me. (ostestr --blacklist_file tests-py3.txt --regex > "nova.tests.unit.network" ran all non-blacklisted network tests) Argh, I spoke too soon, removing '$' stops it from excluding tests in the blacklist. I had gotten mixed up when I looked at the output of the ostestr --list with the difference in the exclude_regex. For example: testr list-tests '^((?!nova.tests.unit.volume.test_cinder.CinderApiTestCase).)*' will *include* all of the nova.tests.unit.volume.test_cinder.CinderApiTestCase tests. Whereas: testr list-tests '^((?!nova.tests.unit.volume.test_cinder.CinderApiTestCase).)*$' will exclude the nova.tests.unit.volume.test_cinder.CinderApiTestCase tests. :( -melanie signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Status of identity v3 support
Hi Everyone, Recently I have started reviewing the patch series about nested quotas in nova [1] and I'm having trouble understanding where we currently are with identity v3 support in nova. From what I read in a semi recent proposal [2] I think things mostly "just work" if you configure to run with v3, but there are some gaps. Nested quotas use the concept of parent/child projects in keystone v3 to allow parent projects to delegate quota management to subprojects. This means we'd start getting requests with a token scoped to the parent project to modify quota of a child project. With keystone v3 we could get requests with tokens scoped to parent projects that act upon child project resources for all APIs in general. The first patch in the series [3] removes the top-level validation check for context.project_id != project_id in URL, since with v3 it's a supported thing for a parent project to act on child project resources. (I don't think it's completely correct in that I think it would allow unrelated projects to act on one another) Doing this fails the keypairs and security groups tempest tests [4] that verify that one project cannot create keypairs or security group rules in a different project. Question: How can we handle project_id mismatch in a way that supports both keystone v2 and v3? Do we augment the check to fall back on checking if "is parent of" using keystone API if there's a project_id mismatch? Question: Do we intend to, for example, allow creation of keypairs by a parent on behalf of child being that the private key is returned to the caller? Basically, I feel stuck on these reviews because it appears to me that nova doesn't fully support identity v3 yet. From what I checked, there aren't yet Tempest jobs running against identity v3 either. Can anyone shed some light on this as I'm trying to see a way forward with the nested quotas reviews? Thanks, -melanie (irc: melwitt) [1] https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nested-quota-driver-api,n,z [2] https://review.openstack.org/#/c/103617/ [3] https://review.openstack.org/182140/ [4] http://logs.openstack.org/40/182140/12/check/check-tempest-dsvm-full/8e51c94/logs/testr_results.html.gz signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cross-project] "Admin" ness not properly scoped
On Jul 23, 2015, at 7:35, Adam Young wrote: > What this means is the if a user is assigned "admin" on any project, they are > assigned admin for everything. > > Fixing this is going to require a change to how we write policy. > > Each policy rule needs to have two parts: > > 1. Match the scoped of the token (project for everything that is not > Keystone, project or domain for Keystone). > > 2. Match the role. Thanks for bringing this up. If I understand correctly, you're saying we can fix this by modifying policy.json alone, right? There aren't any code changes required? So far, for me it has worked fine for "admin" role to grant "admin" everywhere for the system administrators (no one else has "admin" role). But with the prospect of nested quota in nova, I think we would have a new rule for quota update that is, for example: "quota_admin_rule": "role:quota_admin and project_id:%(project_id)s" "admin_or_quota_admin": "role:admin or rule:quota_admin_rule" "compute_extension:quotas:update": "rule:admin_or_quota_admin", "compute_extension:quotas:delete": "rule:admin_or_quota_admin", "os_compute_api:os-quota-sets:update": "rule:admin_or_quota_admin", "os_compute_api:os-quota-sets:delete": "rule:admin_or_quota_admin", "os_compute_api:os-quota-sets:detail": "rule:admin_or_quota_admin", if I want system administrators and designated quota administrators of a project to be able to update quota. In keystone the quota admins will have the role "quota_admin" only in their projects. Is that an example of the right way to scope "admin" in your view? -melanie (irc: melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] contextlib.nested and Python3 failing
On Aug 19, 2015, at 16:51, Sylvain Bauza wrote: > Ideas appreciated. Instead of using the nested context managers, a way I like is to decorate a nested function in the test and call it, for example: def test_thing(self): @mock.patch(...) @mock.patch(...) @mock.patch(...) def do_test(..., ..., ...): ... do_test() -melanie (irc: melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] should we combine a set of minor microversion bump needed fix into one microversoin bump?
On Aug 20, 2015, at 5:40, Alex Xu wrote: > So user may wrote client like this: > > if response.status == 500 and ‘OverQuota’ in response.message: > ….. I thought we're not supporting that type of case. My understanding is that we should never be returning 500 and if we are, it's a bug fix to change it to an appropriate error status code without version bumps. I find it in the documentation [1][2] too. -melanie (irc: melwitt) [1] http://docs.openstack.org/developer/nova/api_microversion_dev.html#when-do-i-need-a-new-microversion [2] http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] feedback from the ops mid cycle summit
Hi Everyone, I attended the ops mid cycle summit on Tuesday and Wednesday and here are brief notes on the feedback I heard related to nova. Please feel free to add your comments or correct me if I got anything wrong. Large Deployments Session [1]: - There's a Neutron spec [2] for adding the capability to model an L3 network which is composed of L2 networks that are routed together, and this project will require cooperation from the nova side - Cells v2 not coming along as quickly as expected. Cells v1 issues around compat between versions, understood it's not supported but it's been a problem - Hierarchical multi-tenancy isn't yet supported (quotas) Upgrades Session Report: - Good linking of features to documentation is important - Inter-service changes are important to call out - Flavor migration is an example of something done well Other general notes: - Event capture is a choice between two bad options - Information divided between events and logs. Have to capture both or you lose the whole picture - Hard to trace RPC calls - Race conditions with scheduling and quotas - The state of Nova and NUMA is not understood - Glance v2 is not being used. From what I understand, we can't move to it because images created by v1 can't be read by v2, for example? All of the etherpads from the event are linked here: https://etherpad.openstack.org/p/PAO-ops-meetup Thanks, -melanie (irc: melwitt) [1] https://etherpad.openstack.org/p/PAO-ops-large-deployments [2] https://review.openstack.org/#/c/196812/ signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] API v2.1 reference documentation
Hi All, With usage of v2.1 picking up (devstack) I find myself going to the API ref documentation [1] often and find it lacking compared with the similar v2 doc [2]. I refer to this doc whenever I see a novaclient bug where something broke with v2.1 and I'm trying to find out what the valid request parameters are, etc. The main thing I notice is in the v2.1 docs, there isn't any request parameter list with descriptions like there is in v2. And I notice "create server" documentation doesn't seem to exist -- there is "Create multiple servers" but it doesn't provide much nsight about what the many request parameters are. I assume the docs are generated from the code somehow, so I'm wondering how we can get this doc improved? Any pointers would be appreciated. Thanks, -melanie (irc: melwitt) [1] http://developer.openstack.org/api-ref-compute-v2.1.html [2] http://developer.openstack.org/api-ref-compute-v2.html signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Design Summit Topics for Nova
On Sep 11, 2015, at 10:15, John Garbutt wrote: > To make it easier to know who submitted what, we are going to try out > google forms for the submissions: > http://goo.gl/forms/D2Qk8XGhZ6 > > If that does not work for you, let me know, and I can see what can be done. Today I was informed that google forms are blocked in China [1], so I wanted to mention it here so we can consider an alternate way to collect submissions from those who might not be able to access the form. -melanie (irc: melwitt) [1] http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-09-15-20.02.log.html#l-102 signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [glance][nova] how to upgrade from v1 to v2?
Hi All, I have been looking and haven't yet located documentation about how to upgrade from glance v1 to glance v2. From what I understand, images and snapshots created with v1 can't be listed/accessed through the v2 api. Are there instructions about how to migrate images and snapshots from v1 to v2? Are there other incompatibilities between v1 and v2? I'm asking because I have read that glance v1 isn't defcore compliant and so we need all projects to move to v2, but the incompatibility from v1 to v2 is preventing that in nova. Is there anything else preventing v2 adoption? Could we move to glance v2 if there's a migration path from v1 to v2 that operators can run through before upgrading to a version that uses v2 as the default? Thanks, -melanie (irc: melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] how to address boot from volume failures
On Sep 30, 2015, at 14:45, Andrew Laski wrote: > > I have a slight preference for #1. Nova is not buggy here novaclient is so I > think we should contain the fix there. > > Is using the v2 API an option? That should also allow the 3 extra parameters > mentioned in #2. +1. I have put up https://review.openstack.org/229669 in -W mode in case we decide to go that route. -melanie __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] novaclient functional test failures
On Oct 12, 2015, at 12:14, Kevin L. Mitchell wrote: > http://logs.openstack.org/77/232677/1/check/gate-novaclient-dsvm-functional/2de31bc/ > (For review https://review.openstack.org/232677) > > http://logs.openstack.org/99/232899/1/check/gate-novaclient-dsvm-functional/6d6dd1d/ > (For review https://review.openstack.org/232899) > > The first review does some stuff with functional tests, but the second > is a simple global-requirements update, and both have the same failure > signature. I noticed in the trace, novaclient is calling a function for keystone v1 auth [1][2]. It had been calling v2 auth in the past and I think this commit [3] in devstack that writes the clouds.yaml specifying v3 as the identity API version is probably responsible for the change in behavior. It used to use the $IDENTITY_API_VERSION variable. The patch merged on Oct 7 and in logstash I find the failures start on Oct 8 [4] Novaclient looks for "v2.0" in the auth url and creates a request based on that. If it doesn't find "v2.0" it falls back generating a v1 request. And it doesn't yet have a function for generating a v3 request. -melanie (irc: melwitt) [1] http://logs.openstack.org/99/232899/1/check/gate-novaclient-dsvm-functional/6d6dd1d/console.html.gz#_2015-10-09_16_01_24_088 [2] https://github.com/openstack/python-novaclient/blob/147a1a6ee421f9a45a562f013e233d29d43258e4/novaclient/client.py#L601-L622 [3] https://review.openstack.org/#/c/220846/ [4] http://goo.gl/5GxiiF signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] novaclient functional test failures
On Oct 14, 2015, at 13:50, Matt Riedemann wrote: > Well we at least have a bug to track against now: > > https://bugs.launchpad.net/python-novaclient/+bug/1506103 Thanks. I just proposed a possible fix [1] which is hacking the clouds.yaml for only the functional test job in the post test hook. The issue is devstack is now creating clouds.yaml configured for openstackclient using keystone v3. Novaclient relies on having "v2.0" in the auth_url and for the functional test jobs, it comes from clouds.yaml. It doesn't seem right to change clouds.yaml on the devstack side, otherwise openstackclient won't work right during stack.sh. The other option I thought of is if we put a workaround in novaclient/tests/functional/base.py to append/replace "v2.0" in the auth_url from clouds.yaml. I didn't want to do that because it would force all clouds.yaml (even running locally) to be modified while running functional tests instead of modifying it only for the build job. Let me know if there's a better way to solve this. -melanie (irc: melwitt) [1] https://review.openstack.org/#/c/236160/ signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Low Hanging Fruit etherpad
Hi All, I have started an etherpad for tracking "low hanging fruit" work in Nova: https://etherpad.openstack.org/p/nova-low-hanging-fruit I have linked it on the Nova Mentoring wiki [1] and populated it with a bit of information about the remaining work that needs to be done to convert the rest of the code base to objects. Please feel free to expand the etherpad with other work and information that would help contributors to Nova. [1] https://wiki.openstack.org/wiki/Nova/Mentoring#What_should_I_work_on.3F Thanks, -melanie (irc: melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?
On Feb 12, 2016, at 14:49, Jay Pipes wrote: > This would be my preference as well, even though it's technically a > backwards-incompatible API change. > > The idea behind get-me-a-network was specifically to remove the current > required complexity of the nova boot command with regards to networking > options and allow a return to the nova-net model where an admin could > auto-create a bunch of unassigned networks and the first time a user booted > an instance and did not specify any network configuration (the default, sane > behaviour in nova-net), one of those unassigned networks would be grabbed for > the troject, I mean prenant, sorry. > > So yeah, the "opt-in to having no networking at all with a --no-networking or > --no-nics option" would be my preference. +1 to this, especially opting in to have no network at all. It seems most friendly to me to have the network allocation automatically happen if nothing special is specified. This is something where it seems like we need a "reset" to a default behavior that is user-friendly. And microversions is the way we have to "fix" an undesirable current default behavior. While I get that a backward-incompatible change may appear to "sneak in" for a user specifying a later microversion to get an unrelated feature, it seems reasonable to me that a user specifying a microversion would consult the documentation for the version delta to get a clear picture of what to expect once they specify the new version. This of course hinges on users knowing how microversions work and being familiar with consulting documentation when changing versions. I hope that is the case and I hope this change will come with a very clear and concise release note with a link to [1]. -melanie [1] http://docs.openstack.org/developer/nova/api_microversion_history.html signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] solving API case sensitivity issues
On Feb 25, 2016, at 8:35, Michał Dulko wrote: > We've faced similar issues in Cinder and as solution we've moved > filtering to Python code. Like in for example [1] or [2]. But no, we > haven't had UNIQUE constraint on the DB column in these cases, only on IDs. This is an interesting option. I see how option 1 (API case fold) is appealing, since our underlying storage (in the mysql case), is case insensitive. And when I think about it, I could see how for example "abc" is essentially the same thing as "ABC" and would be resilient to end users making differences in capitalization of metadata keys (imagine a typo of "DriveType" vs "Drivetype" where a user expects to set a value for the key and they are treated as different keys). The only concern I have about the case folding is when the data is visible to the user. That is, if a user sets a value for "DriveType" and they do 'nova aggregate-details' and see "drivetype" displayed, different than they specified or expected. In the case of aggregate metadata it doesn't seem too impactful since nova is supposed to be the only consumer of the metadata. But are we considering this as the consistent behavior across all APIs? -melanie signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
On Mar 15, 2016, at 10:59, Tim Bell wrote: > The risk I see is that we are missing input to the development process in > view of the complexity of submitting those requirements. Clearly, setting the > bar too low means that there is no clear requirement statement etc. However, > I think the combination of tools and assumption of knowledge of the process > means that we are missing the opportunity for good quality input. > > Many of these are low hanging fruit improvements which could be used to bring > developers into the community if we can find a good way to get the input and > match it with the resource to implement. Agreed. I think Wishlist bugs have had value but I'll admit the value is small compared to the total number of Wishlist bugs. The thing I like about them is that they're easy for anyone to open and people can pile on and say "me too" so we get some indication of how much interest there is in a feature/idea (the launchpad bug heat increases). I have seen this work well in a couple of cases where I don't think we could have found out people were interested in something otherwise. Digging up examples: * Several novaclient users would like it if tenant ids were validated against keystone [1] (Look how many duplicates and the bug heat!). It has since evolved into a spec [2] and blueprint [3]. I didn't think this would be as popular as it is, but I know it from the number of bugs people have opened that I have marked as duplicates of a Wishlist bug. * Several nova users are interested in the capability to detach the root device volume of an instance, when in shutoff state [4]. This one, I had no idea about until I saw the bug. I think the spec process is heavy for a person who just wants to communicate a feature ask and it requires that other people be able to find that spec to +1 it before it potentially goes into the abandoned state once spec freeze happens. I can't imagine users finding a spec being that they're not searchable. I feel like you have to "be in the know" to vote on a spec. With the Wishlist bugs, users can search to find things they're interested in and add comments. Triagers can see duplicates and mark them as such, which bubbles up popular asks via bug heat. It's a lot of manual work, though. -melanie [1] https://bugs.launchpad.net/nova/+bug/1118066 [2] https://review.openstack.org/#/c/92507/ [3] https://blueprints.launchpad.net/nova/+spec/validate-project-with-keystone [4] https://bugs.launchpad.net/nova/+bug/1396965 signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] working on bug reports; what blocks you?
On Mar 17, 2016, at 9:41, Markus Zoeller wrote: > What are the various reasons which block you to work on bug reports? The number one reason for me is lack of information. The main things I want to know are, what version, what commands/API calls did you do, what was the behavior, what behavior did you expect, and show what the error/output was and a log excerpt of any error related to it. Other than that, really old bug reports I tend to just pass over because it's uncertain if anything I look into will be relevant. -melanie signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][infra] revert new gerrit
On Mar 18, 2016, at 9:50, Andrew Laski wrote: > I've adapted to the new interface and really like some of the new > capabilities it provides, but having the page jump around while I'm > commenting has been a huge annoyance. I may have found a workaround for the scroll jumping after reading through the upstream issue comments [1]: use the "Slow" setting in the preferences for Render. Click the gear icon in the upper right corner of the diff view and click the Render switch to "Slow" and then Apply. It seems to be working for me so far. -melanie [1] https://code.google.com/p/gerrit/issues/detail?id=3252#c8 signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][infra] revert new gerrit
On Mar 23, 2016, at 16:56, melanie witt wrote: > I may have found a workaround for the scroll jumping after reading through > the upstream issue comments [1]: use the "Slow" setting in the preferences > for Render. Click the gear icon in the upper right corner of the diff view > and click the Render switch to "Slow" and then Apply. It seems to be working > for me so far. I realized Apply only works for the current screen, you must use Save to make the setting stick for future screens [2]. -melanie [2] https://gerrit-review.googlesource.com/Documentation/user-review-ui.html#diff-preferences signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Nominating Melanie Witt for python-novaclient-core
On Feb 4, 2015, at 16:31, Michael Still wrote: > Its been a week, so I have now added Melanie to this group. Welcome aboard! Thank you! I am honored by the nomination and all of your votes. It is my great pleasure to join python-novaclient-core. :) melanie (melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] release request for python-novaclient
On Feb 6, 2015, at 8:17, Matt Riedemann wrote: > We haven't done a release of python-novaclient in awhile (2.20.0 was released > on 2014-9-20 before the Juno release). > > It looks like there are some important feature adds and bug fixes on master > so we should do a release, specifically to pick up the change for keystone v3 > support [1]. > > So can this be done now or should this wait until closer to the Kilo release > (library releases are cheap so I don't see why we'd wait). Thanks for bringing this up -- there are indeed a lot of important features and fixes on master. I agree we should do a release as soon as possible, and I don't think there's any reason to wait until closer to Kilo. melanie (melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] release request for python-novaclient
On Feb 9, 2015, at 19:55, Michael Still wrote: > The previous policy is that we do a release "when requested" or when a > critical bug fix merges. I don't see any critical fixes awaiting > release, but I am not opposed to a release. That's right. I think the keystone v3 support is important and worth putting out there. > The reason I didn't do this yesterday is that Joe wanted some time to > pin the stable requirements, which I believe he is still working on. > Let's give him some time unless this is urgent. Yes, of course. I should have been clearer. I meant after that's done, we should do a release. melanie (melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] release request for python-novaclient
On Feb 19, 2015, at 11:52, Terry Wilson wrote: > Unfortunately, the new novaclient release ended up completely breaking the > neutron gate. The v1_1 deprecation broke our (voting) pylint test: > https://jenkins04.openstack.org/job/gate-neutron-pylint/1383/console > > 2015-02-19 18:37:06.932 | Module neutron.notifiers.nova[0m > 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' > (no-name-in-module) > 2015-02-19 18:37:06.932 | No name 'contrib' in module > 'novaclient.v1_1'(no-name-in-module) > 2015-02-19 18:37:06.932 | Module neutron.plugins.cisco.l3.service_vm_lib > 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' > (no-name-in-module) Hi Terry, Sorry to hear about this. I looked into this and the problem is pylint can't parse the backward-compatibility we have for the v1_1 deprecation: https://review.openstack.org/#/c/149006/13/novaclient/v1_1/__init__.py,cm The actual code should work but pylint static checking will fail to follow it. So far, the options I see to handle it are to either patch s/novaclient.v1_1/novaclient.v2/ in neutron or suppress the specific pylint check that's failing (if it's not too broad). Do you find either of these options acceptable, or have another idea? Thanks, melanie (melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] release request for python-novaclient
On Feb 19, 2015, at 12:48, Dan Smith wrote: > Either convince neutron pylint not to care, or just convert the > uses in neutron to v2. In pylint, E0611 is the check which could be disabled to ignore this case. http://pylint-messages.wikidot.com/messages:e0611 melanie (melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] release request for python-novaclient
On Feb 19, 2015, at 13:38, Terry Wilson wrote: > We've currently just disabled the pylint gate tests, and I've posted a patch > for neutron to resolve the issue. Looks like there was a similar patch > already up for review as well, though it only catches one of our uses of > novaclient. There's still a bit of an issue that there is no version-neutral > way to import the 'contrib' stuff like there is for 'client'. So: > > from novaclient.v1_1.contrib import server_external_events > > has to become > > from novaclient.v2.contrib import server_external_events > > which doesn't work on previous versions of novaclient. It's possible to hack > around it using importutils, but it's pretty ugly. Thanks, Terry. I'm glad you brought up the lack of version-neutral way to import 'contrib' modules. That's something we'll look to improve. melanie (melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] gate is fubar (again)
On Feb 19, 2015, at 17:54, Matt Riedemann wrote: > Regarding the novaclient change, the plan is to get either the devstack cells > exercise job voting on novaclient changes again (which it was at some point > prior to the 2.21 release and should have caught this problem), or get a > functional test in novaclient that hits the bash completion problem - then we > can revert the revert and make that work with the current code on master. I have put up a review to reinstate the devstack cells exercise job on novaclient: https://review.openstack.org/#/c/157661/ And I think jogo is already working on functional tests that would cover this, if not the bash completion then the volume-attach functionality (technically the volume-attach succeeds but the call made by the bash completion cache write fails). > I might have missed something but figured it'd be good to get this out so > people are aware that things are busted, again. Thanks for writing this up. melanie (melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] novaclient functional test guidelines
On Feb 24, 2015, at 9:47, Sean Dague wrote: > I'm happy if there are other theories about how we do these things, > being the first functional test in the python-novaclient tree that > creates and destroys real resources, there isn't an established pattern > yet. But I think doing all CLI calls in CLI tests is actually really > cumbersome, especially in the amount of output parsing code needed if > you are going to setup any complicated resource structure. I think I'm in agreement with the pattern you describe. I imagine having a set of functional tests for the API, that don't do any CLI calls at all. With that we test that the API works properly. Then have a separate set for the CLI, which only calls CLI for the command being tested, everything else to set up and tear down the test done by API calls. This would be done with the rationale that because the entire API functionality is tested separately, we can safely use it for setup/teardown with the intent to isolate the CLI test to the command being tested and avoid introducing side effects from the CLI commands. But I suppose one could make the same argument for using CLI everywhere (if they are all tested, they can also be trusted not to introduce side effects). I tend to favor using the API because it's the most bare bones setup/teardown we could use. At the same time I understand the idea of performing an entire test using the CLI, as a way of replicating the experience a real user might have using the CLI, from start to end. I don't think I feel strongly either way. For the --poll stuff, I agree the API should have it and the CLI uses it. And with and without "poll" functionality should be tested separately, API and CLI. melanie (melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] H302 considered harmful
On Feb 25, 2015, at 10:51, Duncan Thomas wrote: > Is there anybody who'd like to step forward in defence of this rule and > explain why it is an improvement? I don't discount for a moment the > possibility I'm missing something, and welcome the education in that case A reason I can think of would be to preserve namespacing (no possibility of function or class name collision upon import). Another reason could be maintainability, scenario being: Person 1 imports ClassA from a module to use, Person 2 comes along later and needs a different class from the module so they import ClassB from the same module to use, and it continues. If only the module had been imported, everybody can just do module.ClassA, module.ClassB instead of potentially multiple imports from the same module of different classes and functions. I've also read it doesn't cost more to import the entire module rather than just a function or a class, as the whole module has to be parsed either way. melanie (melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?
On Mar 9, 2015, at 13:14, Sean Dague wrote: > So possibly another way to think about this is our prior signaling of > what was supported by Nova was signaled by the extension list. Our code > was refactored into a way that supported optional loading by that unit. > > As we're making things less optional it probably makes sense to evolve > the API code tree to look more like our REST resource tree. Yes, that > means servers.py ends up being big, but it is less confusing that all > servers related code is in that file vs all over a bunch of other files. > > So I'd agree that in this case server tags probably should just be in > servers.py. I also think long term we should do some "plugin collapse" > for stuff that's all really just features on one resource tree so that > the local filesystem code structure looks a bit more like the REST url tree. I think this makes a lot of sense. When I read the question, "why is server tags being added as an extension" the answer that comes to mind first is, "because the extension framework is there and that's how things have been done so far." I think the original thinking on extensions was, make everything optional so users can enable/disable as they please, operators can disable any feature by removing the extension. Another benefit is the ability for anyone to add a (non-useful to the community at-large) feature without having to patch in several places. I used to be for extensions for the aforementioned benefits, but now I tend to think it's too flexible and complex. It's so flexible that you can easily get yourself into a situation where your deployment can't work with other useful tools/libraries/etc which expect a certain contract from the Nova API. It doesn't make sense to let the API we provide be so arbitrary. It's certainly not friendly to API users. We still have the ability to disable or limit features based on policy -- I don't think we need to do it via extensions. The only problem that seems to be left is, how can we allow people to add un-upstreamable features to the API in their internal deployments? I know the ideal answer is "don't do that" but the reality is some things will never be agreed upon upstream and I do see value in the extension framework for that. I don't think anything in-tree should be implemented as extensions, though. melanie (melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [python-novaclient] Better wording for secgroup-*-default-rules? help text
On Mar 10, 2015, at 7:32, Chris St. Pierre wrote:
> I've just filed a bug on the confusing wording of help text for the
> secgroup-{add,delete,list}-default-rules? commands:
> https://bugs.launchpad.net/python-novaclient/+bug/1430354
>
> As I note in the bug, though, I'm not sure the best way to fix this. In an
> unconstrained world, I'd like to see something like:
>
> secgroup-add-default-rule Add a rule to the set of rules that will be
> added to the 'default' security group in a newly-created tenant.
>
> But that's obviously excessively verbose. And the help strings are pulled
> from the docstrings of the functions that implement the commands, so we're
> limited to what can fit in a one-line docstring. (We could add another source
> of help documentation -- e.g., `desc = getattr(callback, "help",
> callback.__doc__) or ''` on novaclient/shell.py line 531 -- but that seems
> like it should be a last resort.)
>
> How can we clean up the wording to make it clear that "the default security
> group" is, in fact, not "the 'default' security group" or "the security group
> which is default," but rather another beast entirely which isn't even
> actually a security group?
>
> Naming: still the hardest problem in computer science. :(
I don't think your suggestion for the help text is excessively verbose. There
are already longer help texts for some commands than that, and I think it's
important to accurately explain what commands do. You can use a multiline
docstring to have a longer help text.
Why do you say "the default security group" isn't actually a security group?
The fact that it's per-tenant and therefore not necessarily consistent?
melanie (melwitt)
signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [python-novaclient] Better wording for secgroup-*-default-rules? help text
On Mar 10, 2015, at 19:28, Chris St. Pierre wrote: > Ah, look at that! In some other projects, flake8 complains about a docstring > whose first line doesn't end in a period, so I didn't think it'd be possible. > If you don't think that's excessively verbose, there'll be a patch in > shortly. Thanks! Oh, right -- I wasn't thinking about that. Probably it's not a restriction in novaclient because documentation is generated from the docstrings. > That's precisely the confusion -- the security group name 'default' is, of > course, a security group. But "the default security group," as referenced by > the help text for these commands, is actually a sort of meta-security-group > object that is only used to populate the 'default' security group in new > tenants. It is not, in and of itself, an actual security group. That is, > adding a new rule with 'nova secgroup-add-default-rules' has absolutely no > effect on what network traffic is allowed between guests; it only affects new > tenants created afterwards. Got it. I learned a lot about the "default security group" in nova-network because of your email and bug. It's actually generated if it doesn't exist for a tenant when a server is created. If it's found, it's reused and thus won't pick up any default rules that had been added since it was created. And then you could get into particulars like deleting the 'default' group, then you would get all freshest default rules next time you create a server, even if your tenant isn't new. Really not easy to understand. melanie (melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] novaclient 'stable-compat-jobs-{name}' broken
Thanks all who responded. I have put up a patch to remove the jobs: https://review.openstack.org/#/c/173547/ And then next we need to get some stable branches cut and get some guidance from infra on how we can run stable-compat-jobs only on changes proposed to stable branches for novaclient. signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] novaclient 'stable-compat-jobs-{name}' broken
On Apr 14, 2015, at 12:03, Jeremy Stanley wrote: > Our regular integration testing jobs do this by default. When a > change is proposed to a stable branch of a project, devstack-gate > checks out the same branch name for the other projects being tested > with it and updates requirements based on the global requirements > list for that branch. > > The backward-compatibility jobs were a workaround for the fact that > by default changes proposed to the master branch of a project are > only tested with the master branches of other projects. Oh, that makes it easy then! Thanks Jeremy. -melanie (irc: melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Proposal to add Melanie Witt to nova-core
On May 8, 2015, at 10:15, John Garbutt wrote: > Melanie, welcome to nova-core :) Thank you everyone, for your generous support. I am truly humbled. I am thrilled to join nova-core and excited to work with all of you. :) -melanie (irc: melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Bug heads up: Significant increase in DB connections with cells since Newton
Hey Folks, I wanted to give everyone a heads up that we have found and fixed a bug [1] on master where the number of database connections had increased so much that we were starting to hit a "OperationalError (pymysql.err.OperationalError) (1040, u'Too many connections')" in the gate on some work-in-progress patches. The problem of an increased number of database connections goes all the way back to Newton, based on when the cell database connecting code was written along with a report from at least one operator who has upgraded to Newton. Upon investigation, we found that the way we were establishing connections to cell databases was effectively "leaking" connections and we have merged a fix on master and have backports to Ocata and Newton in progress [2]. Once we have merged the backports, we'll be releasing new versions from stable/newton and stable/ocata with the fix ASAP. Thanks, melanie [1] https://bugs.launchpad.net/nova/+bug/1691545 [2] https://review.openstack.org/#/q/topic:bug/1691545 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] [nova][cinder] Is there interest in an admin-api to refresh volume connection info?
On Thu, 8 Jun 2017 08:58:20 -0500, Matt Riedemann wrote: Nova stores the output of the Cinder os-initialize_connection info API in the Nova block_device_mappings table, and uses that later for making volume connections. This data can get out of whack or need to be refreshed, like if your ceph server IP changes, or you need to recycle some secret uuid for your ceph cluster. I think the only ways to do this on the nova side today are via volume detach/re-attach, reboot, migrations, etc - all of which, except live migration, are disruptive to the running guest. I believe the only way to work around this currently is by doing a 'nova shelve' followed by a 'nova unshelve'. That will end up querying the connection_info from Cinder and update the block device mapping record for the instance. Maybe detach/re-attach would work too but I can't remember trying it. I've kicked around the idea of adding some sort of admin API interface for refreshing the BDM.connection_info on-demand if needed by an operator. Does anyone see value in this? Are operators doing stuff like this already, but maybe via direct DB updates? We could have something in the compute API which calls down to the compute for an instance and has it refresh the connection_info from Cinder and updates the BDM table in the nova DB. It could be an admin action API, or part of the os-server-external-events API, like what we have for the 'network-changed' event sent from Neutron which nova uses to refresh the network info cache. Other ideas or feedback here? We've discussed this a few times before and we were thinking it might be best to handle this transparently and just do a connection_info refresh + record update inline with the request flows that will end up reading connection_info from the block device mapping records. That way, operators won't have to intervene when connection_info changes. At least in the case of Ceph, as long as a guest is running, it will continue to work fine if the monitor IPs or secrets change because it will continue to use its existing connection to the Ceph cluster. Things go wrong when an instance action such as resize, stop/start, or reboot is done because when the instance is taken offline and being brought back up, the stale connection_info is read from the block_device_mapping table and injected into the instance, and so it loses contact with the cluster. If we query Cinder and update the block_device_mapping record at the beginning of those actions, the instance will get the new connection_info. -melanie __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] git review -d + git rebase changing author?
On Tue, 18 Jul 2017 09:22:31 +0900, Ghanshyam Mann wrote: Yes, this is same case when we do fetch patch set using git checkout, i do not think its something to do with gite review -d. Doing that shouldn't change the author, at least in my experience. I constantly 'git fetch' or 'git review -d ' to fetch a patch, update it, and push a new revision. When I do that, the author stays the same but it shows me as the "Committer". I have seen the behavior Matt describes happen to other people though and I would guess it has something to do with the rebase. Though I feel like I've also rebased other people's changes and it didn't change the Author, it only changed the Committer to me. -melanie __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Proposing Balazs Gibizer for nova-core
On Tue, 22 Aug 2017 20:18:18 -0500, Matt Riedemann wrote: So to the existing core team members, please respond with a yay/nay and after about a week or so we should have a decision (knowing a few cores are on vacation right now). +1 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling
On Thu, 7 Sep 2017 14:57:24 -0500, Matt Riedemann wrote: Some more background information is in the ironic spec here: https://review.openstack.org/#/c/500429/ Also, be aware of these release notes for Pike related to baremetal scheduling: http://docs-draft.openstack.org/77/501477/1/check/gate-nova-releasenotes/1dc7513//releasenotes/build/html/unreleased.html#id2 In Pike, nova is using a combination of VCPU/MEMORY_MB/DISK_GB resource class amounts from the flavor during scheduling as it always has, but it will also check for the custom resource_class which comes from the ironic node. The custom resource class is optional in Pike but will be a hard requirement in Queens, or at least that was the plan. The idea being that long-term we'd stop consulting VCPU/MEMORY_MB/DISK_GB from the flavor during scheduling and just use the atomic node.resource_class since we want to allocate a nova instance to an entire ironic node, and this is also why the Exact* filters were used too. There are more details on using custom resource classes for scheduling here: https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/custom-resource-classes-in-flavors.html Nisha is raising the question about whether or not we're making incorrect assumptions about how people are using nova/ironic and they want to use the non-Exact filters for VCPU/MEMORY_MB/DISK_GB, which as far as I have ever heard is not recommended/supported upstream as it can lead to resource tracking issues in Nova that eventually lead to scheduling failures later because of the scheduler thinking a node is available for more than one instance when it's really not. This came up in the Nova PTG room yesterday and I wanted to reply on the thread with what I understood about it, for those who weren't in the session. In general, it's recommended to use the exact filters (1 flavor per Ironic node hardware config) as there's no concept of partially claiming a baremetal node. But, with the old non-exact filters, you _could_ get away with creating fewer flavors than you have hardware configs and get "fuzzy matching" on Ironic nodes, to get nodes whose configs are "close enough" but not exact. This might be helpful in situations where you have some oddball configs you don't want to have separate flavors for. I was thinking, if it's possible to assign more than one resource class to an Ironic node, maybe you could get similar behavior to the old non-exact filters. So if you have an oddball config, you could tag it as multiple resource classes that it's "close enough" to for a match. But I'm not sure whether it's possible for an Ironic node to be tagged with more than one resource class. -melanie __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] [nova][ironic] Concerns over rigid resource class-only ironic scheduling
On Thu, 14 Sep 2017 11:15:26 -0600, Ed Leafe wrote: On Sep 14, 2017, at 10:30 AM, melanie witt wrote: I was thinking, if it's possible to assign more than one resource class to an Ironic node, maybe you could get similar behavior to the old non-exact filters. So if you have an oddball config, you could tag it as multiple resource classes that it's "close enough" to for a match. But I'm not sure whether it's possible for an Ironic node to be tagged with more than one resource class. On the placement side, having an ironic node with two resource classes such as RC1 and RC2, would mean that the ResourceProvider (the ironic node) would have two inventory records: one for RC1, and another for RC2. When a request for a flavor specifying one of these classes is handled, only the one class’s inventory would be consumed. Placement would think that the node still had one of the other resource class available, and would include that if another request for that class is received, which would then fail as the node is already in use. Okay, so it's not possible to have one Ironic node with one inventory record be classified as two different resource classes. Never mind that idea then. Thanks for pointing that out. -melanie __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Is there any reason to exclude originally failed build hosts during live migration?
On Wed, 20 Sep 2017 13:47:18 -0500, Matt Riedemann wrote: Presumably there was a good reason why the instance failed to build on a host originally, but that could be for any number of reasons: resource claim failed during a race, configuration issues, etc. Since we don't really know what originally happened, it seems reasonable to not exclude originally attempted build targets since the scheduler filters should still validate them during live migration (this is all assuming you're not using the 'force' flag with live migration - and if you are, all bets are off). Yeah, I think because an original failure to build could have been a failed claim during a race, config issue, or just been a very long time ago, we shouldn't continue to exclude those hosts forever. If people agree with doing this fix, then we also have to consider making a similar fix for other move operations like cold migrate, evacuate and unshelve. However, out of those other move operations, only cold migrate attempts any retries. If evacuate or unshelve fail on the target host, there is no retry. I agree with doing that fix for all of the move operations. -melanie __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Did you know archive_deleted_rows isn't super terrible anymore?
On Fri, 29 Sep 2017 13:49:55 -0500, Matt Riedemann wrote: For awhile now actually. Someone was asking about when archive_deleted_rows would actually work, and the answer is, it should since at least mitaka: https://review.openstack.org/#/q/I77255c77780f0c2b99d59a9c20adecc85335bb18 And starting in Ocata there is the --until-complete option which lets you run it continuously until its done, rather than the weird manual batching from before: https://review.openstack.org/#/c/378718/ So this shouldn't be news, but it might be. So FYI. True that. However, I want to give people a heads up about something I learned recently (today actually). I think problems with archive can arise if you've restarted your database after archiving, and attempt to do a future archive. The InnoDB engine in MySQL keeps the AUTO_INCREMENT counter only in memory, so after a restart it selects the maximum value and adds 1 to use as the next value [1]. So if you had soft-deleted rows with primary keys 1 through 10 in the main table and ran archive_deleted_rows, those rows would get inserted into the shadow table and be hard-deleted from the main table. Then, if you restarted the database, the primary key AUTO_INCREMENT counter would be initialized to 1 again and the primary keys you had archived would be reused. If those new rows with primary keys 1 through 10 were eventually soft-deleted and then you ran archive_deleted_rows, the archive would fail with something like, "DBDuplicateEntry: (pymysql.err.IntegrityError) (1062, u"Duplicate entry '1' for key 'PRIMARY'")". The workaround would be to delete or otherwise move the archived rows containing duplicate keys out of the shadow table. -melanie [1] https://dev.mysql.com/doc/refman/5.7/en/innodb-auto-increment-handling.html#innodb-auto-increment-initialization __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Race in FixedIP.associate_pool
On Fri, 15 Dec 2017 18:38:00 -0800, Arun Sag wrote: Here are the sequence of actions happen in nova-network 1. allocate_for_instance calls -> allocate_fixed_ips 2. FixedIPs are successfully associated (we can see this in the log) 3. allocate_for_instance calls get_instance_nw_info, which in turn gets the fixedip's associated in step 2 using objects.FixedIPList.get_by_instance_uuid, This raises FixedIPNotFound exception We remove the slave and just ran with just single master, the errors went away. We also switched to using semi-synchronous replication between master and slave, the errors went away too. All of this points to a race between write and read to the DB. Does openstack expects synchronous replication to read-only slaves? No, synchronous replication to read-only slaves is not expected. The way this is handled is that oslo.db has the notion of an "async reader" which is safe to use on an asynchronously updated slave database and a regular "reader" which is only safe to use on a synchronously updated slave database, else the master database will be used [1]. In nova, we indicate to oslo.db whether a database API method is safe for use on an asynchronously updated slave database using decorators [2][3]. There are few methods decorated this way. The method you're seeing the race with, fixed_ip_get_by_instance [4] is decorated with the "reader" decorator, indicating that it's only safe for a synchronously updated slave database, else it will use the master. So, this query should *not* be going to an asynchronously updated slave database. If you're using asynchronous replication, it should be going to the master. Have you patched any nova/db/sqlalchemy/api method decorators or patched oslo.db at all to use the "async reader" for more methods? If not, then it's possible there is a bug in oslo.db or nova related to "async reader" state leaking across green threads. Which reminds me of a fairly recent bug [5] we ran into when doing a concurrent scatter-gather to multiple cell databases. You might try the patch [6] locally to see if it changes the behavior when you have asynchronous replication enabled. We had thought only scatter-gather was affected (which was introduced in pike) but it's possible the async slave database read might also be affected. If you could try that patch, please let me know whether it helps and we will backport it. Thanks, -melanie [1] https://github.com/openstack/oslo.db/blob/0260f0e/oslo_db/sqlalchemy/enginefacade.py#L44-L59 [2] https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L214-L219 [3] https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L272 [4] https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L1469-L1470 [5] https://bugs.launchpad.net/nova/+bug/1722404 [6] https://review.openstack.org/#/c/511651 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] zuulv3 log structure and format grumblings
On Thu, 4 Jan 2018 08:46:38 -0600, Matt Riedemann wrote: The main issue is for newer jobs like tempest-full, the logs are under controller/logs/ and we lose the log analyze formatting for color, being able to filter on log level, and being able to link directly to a line in the logs. I also noticed we're missing testr_results.html.gz under controller/logs/, which was handy for seeing a summary of the tempest test results. I hope there's a way to get that back and if any infra peeps can point me in the right direction, I'm happy to help with it. -melanie __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] zuulv3 log structure and format grumblings
On Fri, 05 Jan 2018 10:43:59 -0800, Clark Boylan wrote: To expand a bit more on that what we are attempting to do is port the log handling code in devstack-gate [0] to zuul v3 jobs living in tempest [1]. The new job in tempest itself relies on the ansible process-test-results role which can be found here [2]. Chances are something in [1] and/or [2] will have to be updated to match the behavior in [0]. [0]https://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/functions.sh#n524 [1]https://git.openstack.org/cgit/openstack/tempest/tree/playbooks/post-tempest.yaml#n8 [2]http://git.openstack.org/cgit/openstack-infra/zuul-jobs/tree/roles/process-test-results Thanks for the pointer. So far, I can't tell what's going wrong but I noticed that none of the items in post-tempest.yaml are making it to controller/logs/. The tempest.conf is missing under controller/logs/etc, the tempest.log is missing, accounts.yaml is missing, along with testr_results.html. The job-output shows that the post-tempest.yaml is being executed [1] but the results aren't making it to logs/. [1] http://logs.openstack.org/95/523395/14/gate/tempest-full/ea04d53/job-output.txt.gz#_2018-01-10_19_15_27_228060 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata
Hello Stackers, This is a heads up to any of you using the AggregateCoreFilter, AggregateRamFilter, and/or AggregateDiskFilter in the filter scheduler. These filters have effectively allowed operators to set overcommit ratios per aggregate rather than per compute node in <= Newton. Beginning in Ocata, there is a behavior change where aggregate-based overcommit ratios will no longer be honored during scheduling. Instead, overcommit values must be set on a per compute node basis in nova.conf. Details: as of Ocata, instead of considering all compute nodes at the start of scheduler filtering, an optimization has been added to query resource capacity from placement and prune the compute node list with the result *before* any filters are applied. Placement tracks resource capacity and usage and does *not* track aggregate metadata [1]. Because of this, placement cannot consider aggregate-based overcommit and will exclude compute nodes that do not have capacity based on per compute node overcommit. How to prepare: if you have been relying on per aggregate overcommit, during your upgrade to Ocata, you must change to using per compute node overcommit ratios in order for your scheduling behavior to stay consistent. Otherwise, you may notice increased NoValidHost scheduling failures as the aggregate-based overcommit is no longer being considered. You can safely remove the AggregateCoreFilter, AggregateRamFilter, and AggregateDiskFilter from your enabled_filters and you do not need to replace them with any other core/ram/disk filters. The placement query takes care of the core/ram/disk filtering instead, so CoreFilter, RamFilter, and DiskFilter are redundant. Thanks, -melanie [1] Placement has been a new slate for resource management and prior to placement, there were conflicts between the different methods for setting overcommit ratios that were never addressed, such as, "which value to take if a compute node has overcommit set AND the aggregate has it set? Which takes precedence?" And, "if a compute node is in more than one aggregate, which overcommit value should be taken?" So, the ambiguities were not something that was desirable to bring forward into placement. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Fix evaluation of host disk usage by volume-backed instances
I am working on a POC with this approach and will test all possible scenarios (boot, resize, reboot, compute service stop/start, shelved-unshelved etc). Please let me know your opinion about the same or you have any other solution in mind. Hi Abhishek, FWIW, I'm working on a patch to propose soon for the bug [1] as we had discussed on the review [2]. I'm currently testing it out locally. Best, melanie [1] https://bugs.launchpad.net/nova/+bug/1469179 [2] https://review.openstack.org/#/c/200870 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Race in FixedIP.associate_pool
> On Jan 29, 2018, at 16:45, Arun SAG wrote: > > If anyone is running into db race while running database in > master-slave mode with async replication, The bug has been identified > and getting fixed here > https://bugs.launchpad.net/oslo.db/+bug/1746116 Thanks for your persistence in tracking down the problem and raising the bug. If you get a chance, do please test the proposed patch in your environment to help ensure there aren’t any loose ends left. Once the fix is merged, I think we should propose backports to stable/pike and stable/ocata, do .z releases for them, and bump oslo.db in upper-constraints.txt in the openstack/requirements repo for the stable/pike and stable/ocata branches. That way, operators running from stable can get the fix by upgrading their oslo.db packages to those .z releases. -melanie __ 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
