Re: [openstack-dev] [Openstack-operators][nova]about live-resize down the instance
Hi, That's quite an old spec. :) It has quite a bit of history, and the general nova core opinions were "No, we're probably not going to do that" in the beginning, to "We should probably add that, if people are asking for it" during the last OpenStack PTG. It even had 2x +2s and ~11 +1s at one point. I'll repropose the blueprint again for Stein and rebase everything, if people want it. Implementation-wise, it's pretty much done, last time I was still doing some functional and unit tests for it. I had a tempest test for it too. I had some issues regarding notifications, but gibi helped me sort them out (thanks!). As far as functionality goes, I'm afraid that at the moment we're only going to add live-resize to a larger flavor (live-upsizing). There are a few concerns regarding live-downsizing, especially when it comes to the hypevisor support for something like this (not all of them supports this). Additionally, when it comes to live-downsizing the disk, AFAIK, there's also a data loss concern associated with it, if the disk was not freed and / or if the partition table wasn't shrunk beforehandm, etc. Additionally, some nova drivers don't support downsizing the disks at all, not even cold resize. There are a lot of discussions and debates on the spec you've linked, and you can also read the arguments regarding the question you've asked too. tl;dr version. During the last PTG, we've agreed to "approve" the blueprint with only live-upsizing the instance in-place as the first iteration of the feature, which any new additions to be discussed afterwards. Best regards, Claudiu Belu From: Rambo [li...@unitedstack.com] Sent: Monday, August 13, 2018 2:36 PM To: OpenStack Developmen Subject: [openstack-dev] [Openstack-operators][nova]about live-resize down the instance Hi,all I find it is important that live-resize the instance in production environment,especially live downsize the disk.And we have talked it many years.But I don't know why the bp[1] didn't approved.Can you tell me more about this ?Thank you very much. [1]https://review.openstack.org/#/c/141219/ Best Regards Rambo __ 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][PTLs] Community Goals for Rocky: Toggle the debug option at runtime
Interesting. I'll take a look as well (Winstackers). Just an FYI, SIGHUP doesn't exist in Windows, so for services like nova-compute, neutron-hyperv-agent, neutron-ovs-agent, ceilometer-polling we'd have to use something else. Best regards, Claudiu Belu From: Jean-Philippe Evrard [jean-phili...@evrard.me] Sent: Friday, March 16, 2018 11:02 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime Hello, For OpenStack-Ansible, we don't need to do anything for that community goal. I am not sure how we can remove our name from the storyboard, so I just inform you here. Jean-Philippe Evrard (evrardjp) On 28 February 2018 at 05:27, ChangBo Guo <glongw...@gmail.com> wrote: > Hi ALL, > > TC approved the goal [0] a week ago , so it's time to finish the work. we > also have a short discussion in oslo meeting at PTG, find more details in > [1] , > we use storyboard to check the goal in > https://storyboard.openstack.org/#!/story/2001545. It's appreciated PTL set > the owner in time . > Feel free to reach me( gcb) in IRC if you have any questions. > > > [0] https://review.openstack.org/#/c/534605/ > [1] https://etherpad.openstack.org/p/oslo-ptg-rocky From line 175 > > -- > ChangBo Guo(gcb) > Community Director @EasyStack > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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] [neutron] Prevent ARP spoofing
Hi, Indeed ARP spoofing is prevented by default, but AFAIK, if you want it enabled for a port / network, you can simply disable the security groups on that neutron network / port. Best regards, Claudiu Belu From: Татьяна Холкина [holk...@selectel.ru] Sent: Tuesday, March 13, 2018 12:54 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [neutron] Prevent ARP spoofing Hi, I'm using an ocata release of OpenStack where the option prevent_arp_spoofing can be managed via conf. But later in pike it was removed and it was decided to prevent spoofing by default. There are cases where security features should be disabled. As I can see now we can use a port_security option for these cases. But this option should be set for a particular port or network on create. The default value is set to True [1] and itt is impossible to change it. I'd like to suggest to get default value for port_security [2] from config option. It would be nice to know your opinion. [1] https://github.com/openstack/neutron-lib/blob/stable/queens/neutron_lib/api/definitions/port_security.py#L21 [2] https://github.com/openstack/neutron/blob/stable/queens/neutron/objects/extensions/port_security.py#L24 Best regards, Tatiana __ 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] About live-resize spec
Hello, I am willing to restart working on it, if it actually has a chance of getting approved. Last time, the spec got 2 x +2's and ~12 +1's [1]. I don't know how soon the capabilities thing can become a real thing, but IMO, we can go with Matt's suggestion of disabling the feature by default through policy. Restored and reproposed the spec for Queens btw. [1] https://review.openstack.org/#/c/141219/ Best regards, Claudiu Belu From: Chen CH Ji [jiche...@cn.ibm.com] Sent: Thursday, September 21, 2017 8:38 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] About live-resize spec ok, thanks, I will pick up and get Claudiu's help as well, the original spec is abandoned ,could you please help to restore it? Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com Phone: +86-10-82451493 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC [Inactive hide details for Matt Riedemann ---09/20/2017 09:11:39 PM---On 9/20/2017 12:16 AM, Chen CH Ji wrote: > spec [1] has be]Matt Riedemann ---09/20/2017 09:11:39 PM---On 9/20/2017 12:16 AM, Chen CH Ji wrote: > spec [1] has been there since 2014 and some patches propo From: Matt Riedemann <mriede...@gmail.com> To: openstack-dev@lists.openstack.org Date: 09/20/2017 09:11 PM Subject: Re: [openstack-dev] [nova] About live-resize spec On 9/20/2017 12:16 AM, Chen CH Ji wrote: > spec [1] has been there since 2014 and some patches proposed but > abandoned after that, can someone > please provide some info/background about why it's postponed or due to > some limitations that nova hasn't been implemented yet? > > some operators suggested that this is a valuable funcationality so > better to have it in the near feature... thanks > > > [1]:https://urldefense.proofpoint.com/v2/url?u=https-3A__blueprints.launchpad.net_nova_-2Bspec_instance-2Dlive-2Dresize=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=8URBCAs-AokrPQobkaJ801kitvJThbGRR-TJ4o-LcIE=_CAt9-g8ZEY5LXXo10rhhd-GMWz4B1YBQ28dhuFZnj0= > > Best Regards! > > Kevin (Chen) Ji 纪 晨 > > Engineer, zVM Development, CSTL > Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com > Phone: +86-10-82451493 > Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian > District, Beijing 100193, PRC > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=8URBCAs-AokrPQobkaJ801kitvJThbGRR-TJ4o-LcIE=anotHeOxKU8HE2ff2CnYn4rwT48cG1wkINchYamlckw= > We talked about this during the newton midcycle and from what I remember we wanted to make this depend on having the ability for users to know what they are capable of doing with their server instance in any given cloud. This has grown into the cross project capabilities API discussions that happen with the API work group. At this point, I don't think we have anyone working on doing anything for a capabilities API in nova, nor do we have cross project agreement on a perfect solution that will work for all projects. At the PTG in Denver I think we just said we care less about having a perfect guideline for all projects to have a consistent API, and more about actually documenting the APIs that each project does have, which we do a pretty good job of in Nova. So I think live resize would be fine to pick up again if you're just resizing CPU/RAM from the flavor and if we provide a policy rule to disable it in clouds that don't want to expose that feature. Cloudbase was originally driving it for Hyper-v so you might want to talk with Claudiu Belu. -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=8URBCAs-AokrPQobkaJ801kitvJThbGRR-TJ4o-LcIE=anotHeOxKU8HE2ff2CnYn4rwT48cG1wkINchYamlckw= __ 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] [relmgt] Libraries published to pypi with YYYY.X.Z versions
networking-hyperv is under the Winstackers governance [1], of which I am the PTL of, and you have my +1. :) [1] http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml#n4656 From: Thierry Carrez [thie...@openstack.org] Sent: Friday, September 01, 2017 10:51 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [relmgt] Libraries published to pypi with .X.Z versions Claudiu Belu wrote: > So, I believe the general consensus is that the easiest thing to do is to > unpublish the 2015.1.0 version from pypi, with which I also agree. > [...] Yes, for a first batch I propose we clean up the following: python-congressclient 2015.1.0 python-congressclient 2015.1.0rc1 python-designateclient 2013.1.a8.g3a2a320 networking-hyperv 2015.1.0 For the remaining (official) ones (mistral-extra, networking-odl, murano-dashboard, networking-hyperv, networking-midonet, sahara-image-elements, freezer-api, murano-agent, mistral-dashboard, sahara-dashboard) let's wait until we can get PTL signoff. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
So, I believe the general consensus is that the easiest thing to do is to unpublish the 2015.1.0 version from pypi, with which I also agree. Even if someone actually needs the Kilo version (it's a very old branch, very few people still use it, at most), it can still be done via [1]: pip install git+http://github.com/openstack/networking-hyperv@2015.1.0#networking-hyperv or pip install http://tarballs.openstack.org/networking-hyperv/networking_hyperv-2015.1.0-py2-none-any.whl If someone *actually* needs it on pypi, We could publish a 0.x.y version, but I don't think it will be necessary. Also, @Tony, using upper-constraints wouldn't work when installing networking-hyperv won't really help, as it isn't defined there. networking-hyperv is not a requirement in any project, it's only needed by neutron if the "hyperv" mechanism_driver is used. Thanks @all for your opinions! Best regards, Claudiu Belu From: Jeremy Stanley [fu...@yuggoth.org] Sent: Thursday, August 31, 2017 3:05 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [relmgt] Libraries published to pypi with .X.Z versions On 2017-08-31 15:21:19 +1000 (+1000), Tony Breeds wrote: [...] > I assume it's infra that needs to do the actual unpublish? We're the ones with the most consistent access to all of them, though in a majority of cases there's at least one other account with sufficient access to do the same (it just tends to vary by team and origination timeframe). So, yes, probably easiest to give the Infra team a list once it's been confirmed. -- Jeremy Stanley __ 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] [relmgt] Libraries published to pypi with YYYY.X.Z versions
Hello, As many of you know, during Kilo, the neutron vendor decomposition happened, which lead to the birth of many networking-* libraries, including networking-hyperv. When it was time for us to make a release for that cycle, pretty much every networking-* project followed the release version number at that time, which was 2015.1.0. After Kilo, the versioning changed to the current format. networking-hyperv currently contains the "hyperv" mechanism_driver, which is needed in order to bind neutron ports to Hyper-V compute nodes using neutron-hyperv-agent L2 agents. Now, my main issue is that networking-hyperv==2015.1.0 is currently on Pypi, and whenever someone upgrades networking-hyperv through pip (pip install -U networking-hyperv), it "upgrades" to 2015.1.0. And even if it isn't already installed, networking-hyperv==2015.1.0 is installed, as that is considered the "latest" version: (test) ubuntu@ubuntu:~$ pip freeze | grep networking-hyperv (test) ubuntu@ubuntu:~$ pip install networking-hyperv ... (test) ubuntu@ubuntu:~$ pip freeze | grep networking-hyperv networking-hyperv==2015.1.0 This is a common pitfall for people using pip to install / upgrade networking-hyperv. It's actually become a ritual for new developers to mistakenly install the "latest" version. :) Now, my question is: could we / should we unpublish the 2015.1.0 version? [1] Kolla using pip package "networking-hyperv>=5.0.0,<6.0.0" https://review.openstack.org/#/c/498409/1 [1] #openstack-release: http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2017-08-29.log.html#t2017-08-29T08:19:28 [2] #openstack-release: http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2017-08-29.log.html#t2017-08-29T13:20:36 Best regards, Claudiu Belu __ 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] [hyperv] No Hyper-V meeting on 05/10/2017
Hello, There won't be any Hyper-V meeting today, on May 5th, due to the OpenStack summit. If you are attending the Summit in Boston and wish to meetup and discuss any features or future plans for Hyper-V, you can reply and we'll schedule a meeting this week. Best regards, Claudiu Belu __ 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] [hyperv] No IRC meeting this week
Hello, Our team si currently attending the Atlanta PTG, so this week's meeting is cancelled, and we will resume the meetings starting next week. In the meanwhile, if you're in Atlanta attending the PTG and want to discuss Hyper-V / Windows related topics, feel free to drop an email, and we'll meet at the PTG. Best regards, Claudiu Belu __ 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] [winstackers][hyperv] Atlanta PTG meetup
Hello, Our team will be attending the Atlanta PTG next week. We don't have a dedicated session, but if you want to meet up and discuss about various Windows / Hyper-V related features in OpenStack projects (what has been done, what's in the pipeline, future plans, or what you'd like to see in future releases) you can simply drop me an email, or ping me on IRC (claudiub), and we'll schedule a meeting. We will also be attending other sessions on other projects as well. Best regards, Claudiu Belu __ 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] [winstackers][hyperv] IRC Hyper-V team meeting
Hello, We will resume the weekly Hyper-V meetings on Wednesdays, 13:00 UTC, on the #openstack-meeting-3 IRC channel, starting with tomorrow. Meeting details: https://wiki.openstack.org/wiki/Meetings/Hyper-V Feel free to join! Best regards, Claudiu Belu __ 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] FW: Your draft logo & a sneak peek
Hellou, I just received a draft version of our project logo, using the mascot we selected together. A final version (and some cool swag) will be ready for us before the Project Team Gathering in February. Before they make our logo final, they want to be sure we're happy with our mascot. We can discuss any concerns in Barcelona and you can also provide direct feedback to the designers: http://tinyurl.com/OSmascot Logo feedback is due Friday, Nov. 11. To get a sense of how ours stacks up to others, check out this sneak preview of several dozen draft logos from our community: https://youtu.be/JmMTCWyY8Y4 [cid:EC563D9E-68E0-4CD9-BFF2-2EB3239F4DCF] __ 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] [Winstackers][Hyper-V] 26.10.2016 Hyper-V IRC meeting cancelled
Hello! Just a heads-up, the 26.10.2016's Hyper-V IRC meeting is cancelled due to the OpenStack Summit. We do, however, have a Winstackers work session on Wednesday, October 26, 3:05pm-3:45pm at AC Hotel - P3 - Eixample. Feel free to join us then and there! For more details about the work session, follow the link [1]. [1] https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/17082/winstackers-work-session Best regards, Claudiu Belu __ 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] Non-priority feature freeze and FFEs
Hi, The Hyper-V implementation of the bp virt-device-role-tagging is mergeable [1]. The patch is quite simple, it got some reviews, and the tempest test test_device_tagging [2] passed. [3] [1] https://review.openstack.org/#/c/331889/ [2] https://review.openstack.org/#/c/305120/ [3] http://64.119.130.115/debug/nova/331889/8/04-07-2016_19-43/results.html.gz Best regards, Claudiu Belu From: Markus Zoeller [mzoel...@linux.vnet.ibm.com] Sent: Monday, July 04, 2016 2:24 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Non-priority feature freeze and FFEs On 01.07.2016 23:03, Matt Riedemann wrote: > We're now past non-priority feature freeze. I've started going through > some blueprints and -2ing them if they still have outstanding changes. I > haven't gone through the full list yet (we started with 100). > > I'm also building a list of potential FFE candidates based on: > > 1. How far along the change is (how ready is it?), e.g. does it require > a lot of change yet? Does it require a Tempest test and is that passing > already? How much of the series has already merged and what's left? > > 2. How much core reviewer attention has it already gotten? > > 3. What kind of priority does it have, i.e. if we don't get it done in > Newton do we miss something in Ocata? Think things that start > deprecation/removal timers. > > The plan is for the nova core team to have an informal meeting in the > #openstack-nova IRC channel early next week, either Tuesday or > Wednesday, and go through the list of potential FFE candidates. > > Blueprints that get exceptions will be checked against the above > criteria and who on the core team is actually going to push the changes > through. > > I'm looking to get any exceptions completed within a week, so targeting > Wednesday 7/13. That leaves a few days for preparing for the meetup. > FWIW, bp "libvirt-virtlogd" [1] is basically ready to merge. The two changes [2] and [3] did already get a lot of attention from danpb. References: [1] https://blueprints.launchpad.net/openstack/?searchtext=libvirt-virtlogd [2] https://review.openstack.org/#/c/334480/ [3] https://review.openstack.org/#/c/323765/ -- Regards, Markus Zoeller (markus_z) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][glance][qa] Test plans for glance v2 stack
Hello again, We've set use_glance_v1 nova config option to False on the Hyper-V CI. All good. [1] http://64.119.130.115/nova/278835/13/results.html.gz Best regards, Claudiu Belu From: Claudiu Belu [cb...@cloudbasesolutions.com] Sent: Wednesday, June 08, 2016 4:26 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova][glance][qa] Test plans for glance v2 stack Hello, Sounds good. We'll be testing glance v2 in the Hyper-V CI as well, but at the first glance, there doesn't seem to be any issues with this. We'll switch to glance v2 as soon as we're sure nothing will blow up. :) Best regards, Claudiu Belu From: Matt Riedemann [mrie...@linux.vnet.ibm.com] Sent: Tuesday, June 07, 2016 11:55 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [nova][glance][qa] Test plans for glance v2 stack I tested the glance v2 stack (glance v1 disabled) using a devstack change here: https://review.openstack.org/#/c/325322/ Now that the changes are merged up through the base nova image proxy and the libvirt driver, and we just have hyper-v/xen driver changes for that series, we should look at gating on this configuration. I was originally thinking about adding a new job for this, but it's probably better if we just change one of the existing integrated gate jobs, like gate-tempest-dsvm-full or gate-tempest-dsvm-neutron-full. Does anyone have an issue with that? Glance v1 is deprecated and the configuration option added to nova (use_glance_v1) defaults to True for compat but is deprecated, and the Nova team plans to drop it's v1 proxy code in Ocata. So it seems like changing config to use v2 in the gate jobs should be a non-issue. We'd want to keep at least one integrated gate job using glance v1 to make sure we don't regress anything there in Newton. -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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][glance][qa] Test plans for glance v2 stack
Hello, Sounds good. We'll be testing glance v2 in the Hyper-V CI as well, but at the first glance, there doesn't seem to be any issues with this. We'll switch to glance v2 as soon as we're sure nothing will blow up. :) Best regards, Claudiu Belu From: Matt Riedemann [mrie...@linux.vnet.ibm.com] Sent: Tuesday, June 07, 2016 11:55 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [nova][glance][qa] Test plans for glance v2 stack I tested the glance v2 stack (glance v1 disabled) using a devstack change here: https://review.openstack.org/#/c/325322/ Now that the changes are merged up through the base nova image proxy and the libvirt driver, and we just have hyper-v/xen driver changes for that series, we should look at gating on this configuration. I was originally thinking about adding a new job for this, but it's probably better if we just change one of the existing integrated gate jobs, like gate-tempest-dsvm-full or gate-tempest-dsvm-neutron-full. Does anyone have an issue with that? Glance v1 is deprecated and the configuration option added to nova (use_glance_v1) defaults to True for compat but is deprecated, and the Nova team plans to drop it's v1 proxy code in Ocata. So it seems like changing config to use v2 in the gate jobs should be a non-issue. We'd want to keep at least one integrated gate job using glance v1 to make sure we don't regress anything there in Newton. -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Nova Live Migration of rescued instances
Hello Paul, So, Hyper-V supports nova-rescue at the moment, the patch actually got in last week, thanks to Dan Smith and Jay Pipes. \o/ I've tested live-migration of rescued Hyper-V instances, and it works for both Generation 1 and Generation 2 VMs. I'm thinking that a tempest test for this scenario can be added, once you finish with your blueprint. :) Best regards, Claudiu Belu From: Paul Carlton [paul.carlt...@hpe.com] Sent: Wednesday, May 25, 2016 2:16 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Nova Live Migration of rescued instances On 25/05/16 11:59, Gary Kotton wrote: > Hi, > The VMware driver supports rescue. Live migration should be pretty simple > here as the rescue is only for the disk. So you can migrate the instance to > whatever host you want. The only concern with the VMware driver is that the > live migration patches are in review and I think that they require a spec or > blueprint (https://review.openstack.org/#/c/270116/) > Thanks > Gary > > On 5/25/16, 10:49 AM, "Paul Carlton" <paul.carlt...@hpe.com> wrote: > >> I'm working on a spec https://review.openstack.org/#/c/307131/ to permit >> the live migration of rescued instances. I have an implementation that >> works for libvirt and have addressed lack of support for this feature >> in other drivers using driver capabilities. >> >> I've achieved this for libvirt driver by simply changing how rescue and >> unrescue are implemented. In the libvirt driver rescue saves the current >> domain xml in a local file and unrescue uses this to revert the instance to >> its previous setup, i.e. booting from instance primary disk again rather >> than rescue image. However saving the previous state in the domain >> xml file is unnecessary since during unrescue the domain is destroyed >> and restarted. This is effectively a hard reboot so I just call hard reboot >> during the unrescue operation. Hard reboot rebuilds the domain xml > >from the nova database so the domain xml file is not needed. >> However I was wondering which other drivers support rescue, vmware >> and xen I think? Would it be possible to implement support for live >> migration of rescued instances for these drivers too? I'm happy to do >> the work to implement this, given some guidance from those with more >> familiarity with these drivers than I. >> >> Thanks >> >> -- >> Paul Carlton >> Software Engineer >> Cloud Services >> Hewlett Packard >> BUK03:T242 >> Longdown Avenue >> Stoke Gifford >> Bristol BS34 8QZ >> >> Mobile:+44 (0)7768 994283 >> Email:mailto:paul.carlt...@hpe.com >> Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 >> 1HN Registered No: 690597 England. >> The contents of this message and any attachments to it are confidential and >> may be legally privileged. If you have received this message in error, you >> should delete it from your system immediately and advise the sender. To any >> recipient of this message within HP, unless otherwise stated you should >> consider this message and attachments as "HP CONFIDENTIAL". >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev So vmware supports rescue but until this patch goes in it does not support live migration between compute nodes? So if my change lands before yours then you would need to amend the "supports_live_migrate_rescued" capabilities flag to True in your driver to permit live migration of instances in a rescued state? -- Paul Carlton Software Engineer Cloud Services Hewlett Packard BUK03:T242 Longdown Avenue Stoke Gifford Bristol BS34 8QZ Mobile:+44 (0)7768 994283 Email:mailto:paul.carlt...@hpe.com Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England. The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender. To any recipient of this message within HP
[openstack-dev] [Winstackers][Hyper-V] 27.07.2016 IRC meeting cancelled
Hey y'all! Tomorrow's Hyper-V IRC meeting (27.07.2016) is cancelled due to the OpenStack Summit. We do however have a Winstackers work session tomorrow at 9:00 AM (local time in Austin) in Boardroom 401. Feel free to join us then and there! Here's the event details and topics: https://www.openstack.org/summit/austin-2016/summit-schedule/events/9367 Best regards, Claudiu Belu __ 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] [Winstackers][Hyper-V] Newton Design Summit
Hello everyone, We are going to have a session in the upcomming Austin Design Summit about the upcoming features in OpenStack for Hyper-V / Windows / other Microsoft technologies. We have started writing an agenda for the Winstackers work session: https://etherpad.openstack.org/p/newton-winstackers-design-session You are welcome to join in and add your use cases, questions, challenges, and problems to the etherpad if you wish to discuss them during the session. Knowing the expectations of the community will help us focus our attention on the most desirable features. At the moment, our main topics will be: * Windows containers in Magnum. * New Windows Server 2016 networking stack vs OVS on Windows vs networking-hyperv. * Newton Nova Hyper-V features: Shielded VMs, Fibre Channel support, Hyper-V Cluster, etc. * Performance improvements. Hope to see you at the Summit! Best regards, Claudiu Belu __ 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] [tc][election][ec2-api][winstackers][stable] status of teams without PTL candidates
Hello everyone, My name is Claudiu Belu, the current PTL for the Winstackers team. I apologize for missing such an important matter. It is a new project / team, I didn't expect to go through elections this cycle. I will be more careful in the future. As for the os-win, the project has been actively evolving and it is currently used in several projects: nova, cinder, ceilometer, networking-hyperv, compute-hyperv (os-brick, not yet due to the Feature Freeze), and we've solved some non-trivial, long lasting issues, and improved the overall performance greatly. The team is quite small, but there are new people joining in and attending the weekly Hyper-V meetings. There are still things that can be done and there is still room for improvement. Which is why I would like to propose myself for the Winstackers PTL for Newton. We will be attending the OpenStack summit and we have one worksession. Again, I apologize for the inconvenience. Best regards, Claudiu Belu From: Mike Perez [thin...@gmail.com] Sent: Tuesday, March 22, 2016 5:33 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [tc][election][ec2-api][winstackers][stable] status of teams without PTL candidates On 12:33 Mar 21, Doug Hellmann wrote: > > > On Mar 21, 2016, at 12:03 PM, Alexandre Levine <alexandrelev...@gmail.com> > > wrote: > > > > Doug, > > > > Let me clarify a bit the situation. > > Before this February there wasn't such a project at all. EC2 API was > > a built-in part of nova so no dedicated PTL was required. The built-in part > > got removed and our project got promoted. We're a team of 3 developers > > which nevertheless are committed to this support for year and a half > > already. The reason I didn't nominate myself is solely because I'm new to > > the process and I thought that first cycle will actually start from Mitaka > > so I didn't have to bother. I hope it's forgivable and our ongoing support > > of the code to make sure it works with both OpenStack and Amazon will make > > up for it if a little. > > Yes, please don't take my original proposal as anything other than me > suggesting some "clean up" based on me not having all the info about the > status of EC2. If we need to clarify that all projects are expected to > participate in elections, that's something we can address. I'll look at > wording of the existing requirements in the next week or so. If the team has > a leader, you're all set and I'm happy to support keeping EC2 an official > team. Hope this cover things: https://review.openstack.org/#/c/295581 https://review.openstack.org/#/c/295609 https://review.openstack.org/#/c/295611 -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [hyper-v] oslo.privsep vs Windows
Hello, Thanks Dims for raising the concern and Angus for reaching out. :) Most of the time, python development on Windows is not too far off from Linux. But the two systems are quite different, which imply different modules (fcntl, pwd, grp modules do not exist in Windows) or different implementations of some modules (multiprocessing uses Popen instead of os.fork, os module is quite different) or some socket options and signals are different in Windows. 1.a. As I've said earlier, some modules do not exist in Windows. All, or at least most standard modules document the fact that they are strictly for Linux. [1][2][3] b. At the very least, running the unit tests in a Windows environment can at least detect simple problems (e.g. imports). Secondly, there is a Hyper-V / Windows CI running on some of the OpenStack projects (nova, neutron, networking_hyperv, cinder) that can be checked before merging. 2. This is a bit more complicated question. Well, for functions, you could have separate modules for Linux specific functions and Windows specific functions. This has been done before: [4] As for object-oriented implementations, I'd suggest having the system-specific calls be done in private methods, which will be overriden by Windows / Linux subclasses with their specific implementations. We've done something like this before, but solutions were pretty much straight-forward; it might not be as simple for oslo_privsep, since it is very Linux-specific. 3. Typically, the OpenStack services on Hyper-V / Windows are run with users that have enough privileges to do their job. For example, the nova-compute service is run with a user that has Hyper-V Admin privileges and is not necessarily in the "Administrator" user group. We haven't used rootwrap in our usecases, it is disabled by default, plus, oslo.rootwrap imports pwd, which doesn't exist in Windows. [1] https://docs.python.org/2/library/fcntl.html [2] https://docs.python.org/2/library/pwd.html [3] https://docs.python.org/2/library/grp.html [4] https://github.com/openstack/neutron/blob/master/neutron/agent/common/utils.py [5] https://github.com/openstack/oslo.rootwrap/blob/master/oslo_rootwrap/wrapper.py#L19 If you have any further questions, feel free to ask. :) Best regards, Claudiu Belu From: Angus Lees [g...@inodes.org] Sent: Tuesday, November 24, 2015 6:18 AM To: OpenStack Development Mailing List (not for usage questions); Claudiu Belu Subject: [hyper-v] oslo.privsep vs Windows Dims has just raised[1] the excellent concern that oslo.privsep will need to at least survive on Windows, because hyper-v. I have no real experience coding on windows (I wrote a windows C program once, but I only ever ran it under wine ;) and certainly none within an OpenStack/python context: 1) How can I test whatever I'm working on to see if I have mistakenly introduced something Linux-specific? Surely this is a challenge common across every project in the nova/oslo/hyper-v stack. 2) What predicate should I use to guard the inevitable Linux-specific or Windows-specific code branches? and I guess: 3) What does a typical OpenStack/hyper-v install even look like? Do we run rootwrap with some sudo-like-thing, or just run everything as the superuser? What _should_ oslo.privsep do for this environment? [1] https://review.openstack.org/#/c/244984<https://review.openstack.org/#/c/244984/1> - Gus __ 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] [neutron][hyper-v] Instance can't get fixed ip on hyper-v compute node
Hello, ml2 conf file looks fine. nova logs look fine. neutron logs also seem fine, but this worries me a bit: 2015-06-24 20:45:18.556 4116 DEBUG hyperv.neutron.security_groups_driver [req-3786da36-6b03-433d-941e-00327839603c ] Creating port 3 rules prepare_port_filter C:\Program Files (x86)\Cloudbase Solutions\OpenStack\Nova\Python27\lib\site-packages\hyperv\neutron\security_groups_driver.py:54 Can you run this in powershell? # if you have multiple instances spawned. Get-VMNetworkAdapterExtendedAcl -VMName instance-... | ? Action -eq Allow # only one instance Get-VMNetworkAdapterExtendedAcl | ? Action -eq Allow Can you provide the output into a pastebin as well? Now, since you have security groups enabled, there should be a rule that allow DHCP. It should look like this: ParentAdapter : Microsoft.HyperV.PowerShell.VMNetworkAdapter Direction : Inbound Action : Allow LocalIPAddress : ANY RemoteIPAddress: 10.0.0.2 (this might be different for you) LocalPort : 68-68 RemotePort : ANY Protocol : udp Weight : 65480 Stateful : True IdleSessionTimeout : 0 IsolationID: 0 ToRemove : False All the security group rules the Hyper-V Neutron Agent are received from Neutron. This DHCP rule should be amoung them as well by default. If it is not, well, there the issue lies elsewhere, in neutron. Worst case scenario, you can just add the rule: neutron security-group-rule-create --direction ingress --ethertype IPv4 --protocol udp --port-range-min 68 --port-range-max 68 --remote-ip-prefix 10.0.0.2 sg_id Introducing that rule rule should allow DHCP traffic. If that still doesn't solve the issue, the problem might not be the security groups. You could try restarting the neutron-hyperv-agent with enable_security_group=false in the neutron_hyperv_agent.conf file and check if the instances are able to receive an IP. I assume you've checked the troubleshooting section of the page I've linked last time, but just to make sure.. can you check if DHCP is enabled in the subnet the instance was created in? neutron subnet-show subnet_id Then, considering that you went with the 3 NIC Controller and 2 NIC compute node like this: Controller: eth0 - mangement eth1 - vm-data eth2 - external Compute Node: eth0 - management eth1 - vSwitch - vm-data Can you confirm that the Controller eth1 and the Compute Node vSwitch (eth1) are in the same network? Also, Controller eth1, is it promiscuous mode? At this point, we will have to get our hands dirty and do some networking troubleshooting. :) On the Hyper-V Node, run: # $INSTANCE_NAME will be instance- Get-VM -VMName $INSTANCE_NAME | Get-VMConsole In the VM Console, login, and: ifconfig # no assinged IP? then assign it manually (value from OpenStack Controller): sudo ifconfig eth0 $ASSIGNED_IP netmask $NETWORK_NETMASK up ping $DHCP_IP # let it run. On the Controller, run: # both ICMP echo request and ICMP echo reply must be visible, for all commands. sudo tcpdump -vv -eni eth1 icmp sudo tcpdump -vv -eni br-int icmp #get the tap device name sudo ip netns exec qdhcp-$NET_ID ifconfig sudo ip netns exec qdhcp-$NET_ID tcpdump -vv -ni $TAP_NAME If on the first tcpdump you do not see any ping echo request, the traffic is not getting to the Controller. If you see a ping echo request but no ping echo reply, it means that the traffic gets to the Controller, but there is reply sent back. The next commands should reveal where the reply traffic stops. The last tcpdump is the DHCP network namespace. Ideally, there will be both the request and reply messages. Hope this helps find the issue! Best regards, Claudiu Belu From: Lily.Sing [lily.s...@gmail.com] Sent: Thursday, June 25, 2015 8:02 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][hyper-v] Instance can't get fixed ip on hyper-v compute node Hi Alessandro and Claudiu, Thank you for your quick reply. The version I am running is kilo. Yes I use networking-hyperv. And the windows version is Windows Server 2012 R2. Below are the output for the commands mentioned: Get-VMSwitch Name SwitchType NetAdapterInterfaceDescription -- -- Intel(R) Ethernet Controller X540-AT2 #3 - Virtual Switch External Intel(R) Ethernet Controller X540-AT2 #3 Get-VM | Get-VMNetworkAdapter Name IsManagementOs VMNameSwitchName -- ---- f7d8c327-606b-49cd-b740-ccaef468d535 False instance-000a Intel(R) Ethernet Controller X540-AT2 #3 - Vir... And nova-compute.log and neutron-hyperv-agent.log are pasted as below: http://pastebin.com/idXuhs8a nova
Re: [openstack-dev] [neutron][hyper-v] Instance can't get fixed ip on hyper-v compute node
Hello, From what I can see in the trace you included, it seems to be either Kilo or master (it uses networking-hyperv, which was introduced in Kilo). Also, it might be useful to know if you are using Windows Server 2012 or Windows Server 2012 R2. Running this in Powershell should yield the OS version: [environment]::OSVersion.Version 6.2 is Windows Server 2012 6.3 is Windows Server 2012 R2 As for port binding, neutron-hyperv-agent, if it fails to bind a port, it will retry to bind it. Which means that even if you see that trace, it doesn't mean that the binding failed at all. If you run Get-VM | Get-VMNetworkAdapter in Powershell, you can see that ports have been bound to the vSwitch. Also, I don't know if your environment has been properly configured, but I can tell that you have set the hyperv Mechanism Driver on your Controller node in the /etc/neutron/plugins/ml2/ml2_conf.ini and you are using a network type compatible with Hyper-V. Otherwise, neutron would flag the port with something like port binding failed and neutron-hyperv-agent wouldn't attempt to bind it. A good start would be taking a look at: http://www.cloudbase.it/quantum-hyper-v-plugin/ The linked page contains all the configuration you would need plus some troubleshooting steps that can help. Also, as Alessandro said, copies of C:\OpenStack\Log\nova-compute.log and C:\OpenStack\Log\neutron_hyperv_agent.log and the neutron server's neutron.conf file can be useful. Also, setting debug=True in the Hyper-V's neutron_hyperv_agent.conf can be useful until the issue has been solved. [DEFAULT] debug = True Let us know how it goes. Best regards, Claudiu Belu From: Alessandro Pilotti Sent: Wednesday, June 24, 2015 5:20 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Claudiu Belu Subject: Re: [openstack-dev] [neutron][hyper-v] Instance can't get fixed ip on hyper-v compute node Hi Lily, What version are you running, Icehouse, Juno, Kilo or master? A full copy of the nova-compute.log and neutron_hyperv_agent.log on a pastebin might be helpful. Additionally, your neutron.conf from the neutron server could help along with your neutron network configuration. Finally, the output of Get-VMSwitch on the Hyper-V node could provide some insight on your visrtual switch configuration. This question is deployment related and at this stage not a development topic, so IMO a more suitable location to continue the discussion would be: https://ask.openstack.org Thanks, Alessandro On 24 Jun 2015, at 10:02, Lily.Sing lily.s...@gmail.com wrote: Hi, I setup an openstack env as one controller + network node on OL7.1 and two compute node on windows 2012 server with cloudbase hyper-v compute node driver. Every compute node has two nics. I created a vswitch on the second one and use it to connect to instances. Below is my neutron_hyper_agent.conf: [DEFAULT] verbose=true control_exchange=neutron policy_file=C:\Program Files (x86)\Cloudbase Solutions\OpenStack\Nova\etc\policy.json rpc_backend=neutron.openstack.common.rpc.impl_kombu logdir=C:\OpenStack\Log\ logfile=neutron-hyperv-agent.log [AGENT] polling_interval=2 physical_network_vswitch_mappings=*:Intel(R) Ethernet Controller X540-AT2 #3 - Virtual Switch enable_metrics_collection=false [SECURITYGROUP] firewall_driver=neutron.plugins.hyperv.agent.security_groups_driver.HyperVSecurityGroupsDriver enable_security_group=true [oslo_messaging_rabbit] rabbit_host=rabbit_host rabbit_port=5672 rabbit_userid=stackrabbit rabbit_password=admin After launching an instance, I can check from OpenStack UI that a fixed IP is given, but when connecting the instance from hyper-v manager, no fixed ip is bound to any port. And below is the error message I got from neutron-hyper-agent.log: 2015-06-23 22:59:15.954 3552 INFO hyperv.neutron.hyperv_neutron_agent [req-a0577427-04e9-481d-94f0-027cc57eb26a ] Provisioning network 6d5ee4aa-19e2-404e-9523-cc501b20f081 2015-06-23 22:59:22.088 3552 ERROR hyperv.neutron.hyperv_neutron_agent [req-a0577427-04e9-481d-94f0-027cc57eb26a ] Error in agent event loop 2015-06-23 22:59:22.088 3552 TRACE hyperv.neutron.hyperv_neutron_agent Traceback (most recent call last): 2015-06-23 22:59:22.088 3552 TRACE hyperv.neutron.hyperv_neutron_agent File C:\Program Files (x86)\Cloudbase Solutions\OpenStack\Nova\Python27\lib\site-packages\hyperv\neutron\hyperv_neutron_agent.py, line 356, in daemon_loop 2015-06-23 22:59:22.088 3552 TRACE hyperv.neutron.hyperv_neutron_agent sync = self._process_network_ports(port_info) 2015-06-23 22:59:22.088 3552 TRACE hyperv.neutron.hyperv_neutron_agent File C:\Program Files (x86)\Cloudbase Solutions\OpenStack\Nova\Python27\lib\site-packages\hyperv\neutron\hyperv_neutron_agent.py, line 332, in _process_network_ports 2015-06-23 22:59:22.088 3552 TRACE hyperv.neutron.hyperv_neutron_agent resync_a = self
Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side
Hello, So, AFAIK, there is currently a problem with this. If you make a request for, let's say v2.2 microversion, you will want to execute: nova --os-compute-api-version 2.2 keypair-list But, from my experience, that does not work as expected. Instead of the plugins/v3/ module, it is executed the old contrib/ module, which is not expected. (Also, I've checked, the request header contains X-OpenStack-Compute-API-Version, it is ignored) The only way to get it right (at least in devstack) is to execute: nova --service-type computev21 --os-compute-api-version 2.2 keypair-list So, if I understand Jay correctly, only service-type 'compute' should exist and if any microversion is requested, that particular microversion should be executed. Currently, it doesn't behave like this... so.. Houston, we have a problem. :) Best regards, Claudiu From: Jay Pipes [jaypi...@gmail.com] Sent: Sunday, April 19, 2015 3:45 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side Andrey, thanks for posing these important questions. My thoughts inline. On 04/10/2015 07:30 AM, Andrey Kurilin wrote: Hi all! I working on implementation of support microversions in novaclient. Patches are ready for review, but there is one opened question: what we should do with v2.1 endpoint(computev21 service type)? compute is a default value of service type and keystone returns v2 api endpoint for it(at least in devstack), so version header will be ignored on API side. On the one hand, each deployment can have it's own configuration of service catalog and endpoints, so default value of service type should be strict and support as much deployments as we can. On the other hand, dependency of service type for microversion feature is not good and end-users should not take care about choice of correct service type when they want to execute simple command. Correct. Possible solutions: 1. leave everything as is: use --service-type computev21 for each microversioned command It was a mistake to put any version information in *any* of the service types. The service type should be compute and only compute. The version negotiation should be handled entirely separately via the X-OpenStack-Compute-API-Version HTTP header sent from the client. 2. move default value of service type to environment variables(default value is hardcoded in novaclient code now) I don't see any reason to do that, no. 3. add additional option --compute-api-type. Proposed etherpad by Christopher Yeoh https://etherpad.openstack.org/p/novaclient_microversions_design . Implementation is already finished - https://review.openstack.org/#/c/167577/ . This proposal still requires addition cli option, but compute-api-type looks more user-friendly -1. There should be no additional option. The API microversion should be negotiated via the X-OpenStack-Compute-API-Version HTTP header and only via that. The existing --os-compute-api-version CLI option should be made to take: * 2 * \d+.\d+ * latest And nothing else. Best, -jay Current implementation uses compute as default value for service type. Patches are pass all gates, except stable branches and ready for review: * https://review.openstack.org/#/c/169378/ - deprecate v1.1 and remove references to v3 in code * https://review.openstack.org/#/c/152569/ - Implements 'microversions' api type - Part 1 (usage of nova.api.openstack.api_version_request:APIVersionRequest class with https://review.openstack.org/#/c/169292/ ) * https://review.openstack.org/#/c/167408/ - Implements 'microversions' api type - Part 2 (adds new decorators and substitution mechanism using nova.api.openstack.versioned_method ) * https://review.openstack.org/#/c/136458/ - Implementation of 2.2 microversion -- Best regards, Andrey Kurilin. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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] what's the merge plan for current proposed microversions?
Hello. I've talked with Christopher Yeoh yesterday and I've asked him about the microversions and when will they be able to merge. He said that for now, this commit had to get in before any other microversions: https://review.openstack.org/#/c/159767/ He also said that he'll double check everything, and if everything is fine, the first microversions should be getting in soon after. Best regards, Claudiu Belu From: Alexandre Levine [alev...@cloudscaling.com] Sent: Tuesday, March 03, 2015 4:22 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] what's the merge plan for current proposed microversions? Bump. I'd really appreciate some answers to the question Sean asked. I still have the 2.4 in my review (the very one Sean mentioned) but it seems that it might not be the case. Best regards, Alex Levine On 3/2/15 2:30 PM, Sean Dague wrote: This change for the additional attributes for ec2 looks like it's basically ready to go, except it has the wrong microversion on it (as they anticipated the other changes landing ahead of them) - https://review.openstack.org/#/c/155853 What's the plan for merging the outstanding microversions? I believe we're all conceptually approved on all them, and it's an important part of actually moving forward on the new API. It seems like we're in a bit of a holding pattern on all of them right now, and I'd like to make sure we start merging them this week so that they have breathing space before the freeze. -Sean __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Feature Freeze Exception request for x509 keypairs
Hello. I would like to ask for a FFE for the x509 keypairs blueprint: https://blueprints.launchpad.net/nova/+spec/keypair-x509-certificates This blueprint is split up into 3 commits: [1] Database migration: previously merged, but had to be reverted because of a small issue. Everything is fixed, original reverter Johannes Erdfelt gave his +1, currently the commit has a +2. https://review.openstack.org/#/c/150800/ [2] Nova-API change: It uses the microversioning API and it has been decided to be the first microversioning commit, since it is closest to merge. Christopher Yeoh reviewed helped with this commit. https://review.openstack.org/#/c/140313/ [3] X509 keypair implementation: Simple commit, it had a +2 on a previous commit. https://review.openstack.org/#/c/136869/ I also want to point out that this blueprint targets all the drivers, not just Hyper-V. This blueprint targets all the users that desire to deploy instances with Windows guests and desire password-less authentication, the same way users can ssh into Linux-type guests. Best regards, Claudiu Belu __ 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] Feature Freeze Exception for hyper-v unit tests refactoring
Hello. I would like to request a FFE for the Hyper-V unit tests refactoring blueprint: https://blueprints.launchpad.net/nova/+spec/hyper-v-test-refactoring The point of the blueprint was to get rid of the ancient test_hypervapi.py tests, that use mox, as they prove more and more difficult to maintain, especially when adding new features or fixing bugs. Those tests would be replaced with mock unit tests, per Ops class. There were 11 commits in total, 6 already merged, 5 remain. Out of these 5, the last 2 are trivial: [1] https://review.openstack.org/#/c/138934/ [2] https://review.openstack.org/#/c/139796/ [3] https://review.openstack.org/#/c/139797/ [4] https://review.openstack.org/148980 - unit tests for methods that have 1 instruction each. Just to have coverage on all the modules. [5] https://review.openstack.org/139798 - just removes test_hypervapi.py The commits have been reviewed, already have a couple of +1s. Note: this blueprint is limited to the Hyper-V unit tests and does not change the functionality of the Driver in any way. It is barely worthy of the name blueprint and I consider it more of a bug, rather than a blueprint. This will improve maintainability, readability and coverage for the Hyper-V classes. Best regards, Claudiu Belu __ 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] Feature Freeze Exception request for x509 keypairs
Hello. I would like to ask for a FFE for the x509 keypairs blueprint: https://blueprints.launchpad.net/nova/+spec/keypair-x509-certificates This blueprint is split up into 3 commits: [1] Database migration: previously merged, but had to be reverted because of a small issue. Everything is fixed, original reverter Johannes Erdfelt gave his +1, currently the commit has a +2. https://review.openstack.org/#/c/150800/ [2] Nova-API change: It uses the microversioning API and it has been decided to be the first microversioning commit, since it is closest to merge. Christopher Yeoh reviewed helped with this commit. https://review.openstack.org/#/c/140313/ [3] X509 keypair implementation: Simple commit, it had a +2 on a previous commit. https://review.openstack.org/#/c/136869/ I also want to point out that this blueprint targets all the drivers, not just Hyper-V. This blueprint targets all the users that desire to deploy instances with Windows guests and desire password-less authentication, the same way users can ssh into Linux-type guests. Best regards, Claudiu Belu __ 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] Feature Freeze Exception for hyper-v unit tests refactoring
Hello. I would like to request a FFE for the Hyper-V unit tests refactoring blueprint: https://blueprints.launchpad.net/nova/+spec/hyper-v-test-refactoring The point of the blueprint was to get rid of the ancient test_hypervapi.py tests, that use mox, as they prove more and more difficult to maintain, especially when adding new features or fixing bugs. Those tests would be replaced with mock unit tests, per Ops class. There were 11 commits in total, 6 already merged, 5 remain. Out of these 5, the last 2 are trivial: [1] https://review.openstack.org/#/c/138934/ [2] https://review.openstack.org/#/c/139796/ [3] https://review.openstack.org/#/c/139797/ [4] https://review.openstack.org/148980 - unit tests for methods that have 1 instruction each. Just to have coverage on all the modules. [5] https://review.openstack.org/139798 - just removes test_hypervapi.py The commits have been reviewed, already have a couple of +1s. Note: this blueprint is limited to the Hyper-V unit tests and does not change the functionality of the Driver in any way. It is barely worthy of the name blueprint and I consider it more of a bug, rather than a blueprint. This will improve maintainability, readability and coverage for the Hyper-V classes. Best regards, Claudiu Belu __ 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] How to handle API changes in contrib/*.py
Bump. Also, added to CC Alex Xu and Chris Yeoh. Cheers! Claudiu Belu From: Claudiu Belu [cb...@cloudbasesolutions.com] Sent: Tuesday, February 03, 2015 12:51 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [nova][api] How to handle API changes in contrib/*.py Hello! There have been some discussion on what nova-api should return after a change in the API itself. So, the change that generated this discussion is an API change to 2.2 is: https://review.openstack.org/#/c/140313/23 - **2.2** Added Keypair type. A user can request the creation of a certain 'type' of keypair (ssh or x509). If no keypair type is specified, then the default 'ssh' type of keypair is created. Currently, this change was done on plugins/v3/keypairs.py, so now, the 2.2 version will also return the keypair type on keypair-list, keypair-show, keypair-create. Microversioning was used, so this behaviour is valid only if the user requests the 2.2 version. Version 2.1 will not accept keypair type as argument, nor will return the keypair type. Now, the main problem is contrib/keypairs.py, microversioning cannot be applied there. The current commit filters the keypair type, it won't be returned. But there have been reviews stating that returning the keypair type is a back-compatible change. Before this, there was a review stating that keypair type should not be returned. So, finally, my question is: how should the API change be handled in contrib/keypairs.py? Best regards, Claudiu Belu __ 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] How to handle API changes in contrib/*.py
I have failed to add Chris Yeoh. Hope it's fine now.. From: Claudiu Belu [cb...@cloudbasesolutions.com] Sent: Wednesday, February 04, 2015 5:10 PM To: OpenStack Development Mailing List (not for usage questions) Cc: x...@linux.vnet.ibm.com Subject: Re: [openstack-dev] [nova][api] How to handle API changes in contrib/*.py Bump. Also, added to CC Alex Xu and Chris Yeoh. Cheers! Claudiu Belu From: Claudiu Belu [cb...@cloudbasesolutions.com] Sent: Tuesday, February 03, 2015 12:51 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [nova][api] How to handle API changes in contrib/*.py Hello! There have been some discussion on what nova-api should return after a change in the API itself. So, the change that generated this discussion is an API change to 2.2 is: https://review.openstack.org/#/c/140313/23 - **2.2** Added Keypair type. A user can request the creation of a certain 'type' of keypair (ssh or x509). If no keypair type is specified, then the default 'ssh' type of keypair is created. Currently, this change was done on plugins/v3/keypairs.py, so now, the 2.2 version will also return the keypair type on keypair-list, keypair-show, keypair-create. Microversioning was used, so this behaviour is valid only if the user requests the 2.2 version. Version 2.1 will not accept keypair type as argument, nor will return the keypair type. Now, the main problem is contrib/keypairs.py, microversioning cannot be applied there. The current commit filters the keypair type, it won't be returned. But there have been reviews stating that returning the keypair type is a back-compatible change. Before this, there was a review stating that keypair type should not be returned. So, finally, my question is: how should the API change be handled in contrib/keypairs.py? Best regards, Claudiu Belu __ 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
