Re: [openstack-dev] Building Openstack Trove Images
As Amrith stated, you need to look at the Neutron logs as the message about port binding suggests: PortBindingFailed: Binding failed for port 26b727dd-52b4-4b34-b484-6ea3fd571c8d, please check neutron logs for more information. On Mon, Nov 13, 2017 at 8:22 AM, Debojyoti Das wrote: > Hi All, > > Please help us regarding the Openstack Issue, we are facing the following > error in our Openstack Environment, and we had tried almost every solution > found at internet but not able to resolve the issue. > > we have added one compute node to our Openstack controller which is > showing in the openstack dashboard however the when we launch any VM, the > VM goes into error state. We have gone through most of the things available > on the internet but nothing sorts it out. Below are the logs for the error: > > > > ERROR nova.compute.manager [instance: 054229be-3467-490d-b407-dc256a8747c8] > File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", > line 984, in _update_ports_for_instance > > 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance: > 054229be-3467-490d-b407-dc256a8747c8] port_client, instance, port_id, > port_req_body) > > 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance: > 054229be-3467-490d-b407-dc256a8747c8] File > "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line > 445, in _update_port > > 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance: > 054229be-3467-490d-b407-dc256a8747c8] _ensure_no_port_binding_failur > e(port) > > 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance: > 054229be-3467-490d-b407-dc256a8747c8] File > "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line > 191, in _ensure_no_port_binding_failure > > 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance: > 054229be-3467-490d-b407-dc256a8747c8] raise > exception.PortBindingFailed(port_id=port['id']) > > 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance: > 054229be-3467-490d-b407-dc256a8747c8] PortBindingFailed: Binding failed > for port 26b727dd-52b4-4b34-b484-6ea3fd571c8d, please check neutron logs > for more information. > > > > > Can you throw some light or give us some guidance on this as it has halted > the implementation of our Production Openstack Pike. > > Your support and co-operation is highly appreciated. > > > FYI: Controller and compute node are running CentOS7. > > On Mon, Nov 13, 2017 at 6:41 PM, Debojyoti Das < > debojyoti@indusnet.co.in> wrote: > >> Hi Amrith, >> >> Please throw some light to the issue, we have stuck at a serious point of >> our Production migration from Cloudstack to Openstack. So Please help us, >> you co-operation is highly appreciated. >> >> On Mon, Nov 13, 2017 at 6:10 PM, Debojyoti Das < >> debojyoti@indusnet.co.in> wrote: >> >>> Hi Amrith, >>> >>> Please throw some light to the issue, we have stuck at a serious point >>> of our Production migration from Cloudstack to Openstack. So Please help >>> us, you co-operation is highly appreciated. >>> >>> On Mon, Nov 13, 2017 at 1:29 PM, Ritesh Vishwakarma < >>> ritesh.vishwaka...@indusnet.co.in> wrote: >>> Hi Amirth, Many thanks for your response coz of which I was able to build a MySQL image from Ubuntu Xenial. However, I am facing another obstacle now, we have added one compute node to our Openstack controller which is showing in the openstack dashboard however the when we launch any VM, the VM goes into error state. We have gone through most of the things available on the internet but nothing sorts it out. Below are the logs for the error: ERROR nova.compute.manager [instance: 054229be-3467-490d-b407-dc256a8747c8] File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 984, in _update_ports_for_instance 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance: 054229be-3467-490d-b407-dc256a8747c8] port_client, instance, port_id, port_req_body) 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance: 054229be-3467-490d-b407-dc256a8747c8] File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 445, in _update_port 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance: 054229be-3467-490d-b407-dc256a8747c8] _ensure_no_port_binding_failure(port) 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance: 054229be-3467-490d-b407-dc256a8747c8] File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 191, in _ensure_no_port_binding_failure 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance: 054229be-3467-490d-b407-dc256a8747c8] raise exception.PortBindingFailed(port_id=port['id']) 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance: 054229be-34
Re: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API removal
The Keystone v2 removal also broke Trove's gate. Trove's functional and scenario tests had Keystone v2 hard codings and also relied on a > 4 year old 'compat' client package in the python-troveclient that did not have V3 support. Both cases required a lot of scrambling find all the v2 hard codings and add in v3 support. I'm completely behind the V2 removal and am glad we've finally crossed that bridge. The one thing that I think could have been handled better was a longer amount of time between making devstack use V3 by default and the actual removal of the V2 auth APIs. There were 8 days between these two commits. It may have been better to switch devstack to use v3 a half cycle or full cycle before removing the v2 APIs to allow teams that had impacts more time to react. On Sun, Oct 22, 2017 at 1:01 PM, Clint Byrum wrote: > Excerpts from Jeremy Stanley's message of 2017-10-21 13:37:01 +: >> On 2017-10-20 22:50:53 + (+), Fox, Kevin M wrote: >> [...] >> > Ideally, there should be an OpenStack overarching architecture >> > team of some sort to handle this kind of thing I think. >> >> There was one for a while, but it dissolved due to lack of community >> participation. If you'd like to help reboot it, Clint B. can >> probably provide you with background on the previous attempt. >> > > I'd be in support of reviving the Architecture Working Group (SIG?). > > Would need to see more people commit to it though. It mostly felt like > a place for Thierry and me to write down our ideas, and a title to put > on a room at the PTG so we could have cross-project discussions about > our ideas. > > That said, there is a cross-project process that works pretty well when > one project needs to ask for changes from other projects: > > https://docs.openstack.org/project-team-guide/cross-project.html > > I believe the Keystone team followed this process despite some fumbles > early in the v3 story. > >> > Without such an entity though, I think the TC is probably >> > currently the best place to discuss it though? >> >> Contrary to the impression some people seem to have, the TC is not >> primarily composed of cloud architects; it's an elected body of >> community leaders who seek informed input from people like you. I've >> personally found no fault in the process and timeline the Keystone >> team followed in this situation but I'm also not the primary >> audience for their software, so it's good to hear from those who are >> about ways to improve similar cases in the future. However, I also >> understand that no matter how widely and carefully changes are >> communicated, there's only so much anyone can do to avoid surprising >> the subset of users who simply don't pay attention. > > Right, the TC is more or less a legislative body. They can set policy > but they don't actually make sure the vision is implemented directly. > > I made an argument that there's a need for an executive branch to get > hard things done here: > > http://fewbar.com/2017/02/open-source-governance-needs-presidents/ > > Without some kind of immediate executive that sits above project levels, > we'll always be designing by committee and find our silos getting deeper. > > All of that said, I believe the Keystone team did a great job of getting > something hard done. As Morgan states, it was a 100% necessary evolution > and required delicate orchestration. Well done Keystone team! > > __ > 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] [all][infra] Zuul v3 rollout, the sequel returns
Thanks. I will try to fix the legacy-trove-functional.
On Sat, Oct 14, 2017 at 12:58 AM, Andreas Jaeger wrote:
> On 2017-10-14 03:30, Sam Matzek wrote:
>> The legacy-trove-functional-dsvm-mysql and
>> legacy-trove-legacy-functional-dsvm-mysql jobs are running the wrong
>> post_test_hook and have the trove-integration project in $PROJECTS.
>
> Looking at zuul/layout.yaml the change
> trove-legacy-functional-dsvm-mysql should only run on stable/newton -
> but trove-functional-dsvm-mysql on anything newer.
> done with https://review.openstack.org/511997 Fix trove
> legacy-trove-legacy-functional-dsvm-mysql
>
>> As such they will always vote -1. The functional integration tests
>> moved into Trove proper in Ocata. I've added more details and links
>> to the zuulv3-issues etherpad.
>>
>> I'm not familiar enough with the job definitions to be able to work on
>> the fix reviews for these but would like to learn.
>
> Those are in openstack-zuul-jobs, the file is
> http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/playbooks/legacy/trove-functional-dsvm-mysql/run.yaml.
>
> Do you want to fix it yourself and sync with the v2 version that is in
> project-config/jenkins/jobs/trove.yaml?
>
> Andreas
> --
> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>
__
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] Zuul v3 rollout, the sequel returns
The legacy-trove-functional-dsvm-mysql and legacy-trove-legacy-functional-dsvm-mysql jobs are running the wrong post_test_hook and have the trove-integration project in $PROJECTS. As such they will always vote -1. The functional integration tests moved into Trove proper in Ocata. I've added more details and links to the zuulv3-issues etherpad. I'm not familiar enough with the job definitions to be able to work on the fix reviews for these but would like to learn. Sam Matzek On Fri, Oct 13, 2017 at 2:57 PM, Jeremy Stanley wrote: > The tl;dr is that we're planning to roll forward out of our partial > Zuul v3 rollback starting at 22:00 UTC on Sunday October 15 (this > weekend), so expect some CI downtime and all of the benefits (though > hopefully none of the drawbacks!) you witnessed when we tried the > first time. At that time, v2 jobs reported by the "Jenkins" account > will cease to be relevant, and v3 jobs reported by the "Zuul" > account will be used to determine whether your changes can merge. > > As Monty noted earlier in the week, our plans to roll forward onto > Zuul v3 were halted by a number of unrelated infrastructure fires > which demanded our immediate attention as a team, so we reluctantly > postponed. Following a (brief) hiatus yesterday, check pipeline > processing has been readded to zuulv3.openstack.org for all projects > so you can get fresh results back on v3 jobs between now and our > maintenance if you happen to be around testing it out. We also still > have an expedited priority "infra-check" pipeline on zuulv3 for > changes to the project-config repository so that emergency fixes > for legacy jobs can be merged quickly, and we'll be keeping this for > some time after the transition until it ceases to be necessary. > > We anticipate an outage for the CI system of somewhere between 30-60 > minutes starting at 22:00 UTC on Sunday October 15. In the meantime, > if you've been digging into recent legacy job failures for your > projects you should consider trying to bring them to our attention > as soon as possible (in #openstack-infra on the Freenode IRC > network, or replying on-list to this announcement) and work on > fixing them if you're familiar enough with the failures to do so > yourself. It also helps to get them onto the triage list we have > been maintaining here: > > https://etherpad.openstack.org/p/zuulv3-issues > > We're assembling a sort of FAQ in the migration guide > here: > > https://docs.openstack.org/infra/manual/zuulv3.html > > ...and we also have some more content in progress at: > > https://etherpad.openstack.org/p/zuulv3-migration-faq > > Here's to the week ahead! > -- > 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 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] [infra][devstack][congress] zuul3 transition surfaced error: The following LIBS_FROM_GIT were not installed correct: python-congressclient
This is also one of several errors hitting the Trove gate. This review should workaround the issue for now. https://review.openstack.org/#/c/508344/3 On Mon, Oct 2, 2017 at 1:44 PM, Eric K wrote: > Since the transition to zuul3, this error began and prevents the devstack > setup from finishing on Congress gate jobs. I've been working to diagnose > it but so far without success. > > Any suggestions and tips much appreciated! > > http://logs.openstack.org/58/493258/5/check/legacy-congress-dsvm-api-mysql/ > cfb57ff/logs/devstacklog.txt.gz#_2017-10-01_23_46_16_449 > > ./stack.sh:1392:check_libs_from_git > /opt/stack/new/devstack/inc/python:404:die > [ERROR] /opt/stack/new/devstack/inc/python:404 The following LIBS_FROM_GIT > were not installed correct: python-congressclient > Error on exit > > > Note: previous to the transition to zuul3, it was already a problem on > python3 devstack setup at gate but never on python2. For example, see > these results run pre-zuul3: https://review.openstack.org/#/c/498996/ > > > > __ > 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] Could you tell me the best way to develop openstack in Windows?
For reading the code I use Eclipse Mars with PyDev installed on Windows 7. This allows me to CTRL-click on methods calls to link to their source, etc. I also use this for some amount of code modification and can run some amount of unit tests after pip installing a lot of dependencies. This is more of a convenience method though. For real development where you will contribute back I suggest running Linux VM on Windows where you can then use command line git and tox. On Mon, May 2, 2016 at 6:53 AM, Anita Kuno wrote: > On 05/02/2016 04:20 AM, 박준하 wrote: >> Hi forks, >> >> >> >> I’m beginner about Openstack developments. I’ve been really interested in >> to know about Openstack and wanted to modify and test it. >> >> >> >> But I’m using PyCharm in the Windows 7 but, It’s very hard to programming >> and testing when I tried to change code little bit. >> >> >> >> I hope you guys are the best developer about opensources especially >> Openstack. Could tell me your environment for developing on the Windows? >> >> >> >> >> >> Thanks. >> >> >> >> >> >> Jun-ha, Park >> >> Freshman of Cloud Technical Group KINX corp., Korea >> >> >> >> >> __ >> 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 >> > > The optimum environment for developing open source code consists of open > source tools. > > The majority of the open source development community uses open source > tools for development. The community is best able to offer support for > use of open source tools. > > If you need help accessing, and finding ways to learn how to use, open > source tools, please do ask. > > Thank you, > Anita. > > __ > 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 hooks - document & test or deprecate?
On Wed, Mar 2, 2016 at 8:25 PM, Adam Young wrote: > On 02/29/2016 01:49 PM, Andrew Laski wrote: >> >> >> On Mon, Feb 29, 2016, at 01:18 PM, Dan Smith wrote: Forgive my ignorance or for playing devil's advocate, but wouldn't the main difference between notifications and hooks be that notifications are asynchronous and hooks aren't? >>> >>> The main difference is that notifications are external and intended to >>> be stable (especially with the versioned notifications effort). The >>> hooks are internal and depend wholly on internal data structures. >>> In the case of how Rdo was using it, they are adding things to the injected_files list before the instance is created in the compute API. You couldn't do that with notifications as far as I know. >>> >>> Nope, definitely not, but I see that as a good thing. Injecting files >>> like that is likely to be very fragile and I think mostly regarded as >>> substantially less desirable than the alternatives, regardless of how it >>> happens. >>> >>> I think that Laski's point was that the most useful and least dangerous >>> thing that hooks can be used for is the use case that is much better >>> served by notifications. > > > I did the original proof-of-concept for this prior to the impl using the > hooks, just by modifying the metadata. > > http://adam.younglogic.com/2013/09/register-vm-freeipa/ > > That works for a CLI based approach, but not for auto-registering VMs > created from the WebUI, and also only works if the user crafts the Metadata > properly. It was not a secure approach. > > What we need is a way to be able to generate a secret and share that between > the new VM and the enrolling server. The call does not strictly have to be > synchronous. The enrolling server can wait if the VM is not up, and the VM > can wait if the enrolling server does not have the secret when the VM is > ready to enroll. > > We had discussed having a seperate service listen to notifications on the > bus and inject the data necessary into the IdM server. The hooks were a > much better solution. > > I had seriously thought about using the Keystone token as the symmetric > shared secret. It is a horrible solution, but so are all the rest. > > There is no security on the message bus at the moment, and until we get > some, we can't put a secret on the bus. > > So, don't deprecate until you have a solution. All you will be doing is > putting people in a tight spot where they will have to fork the code base, > and that is downright antisocial. > > Let's plan this out in the Newton Summit and have a plan moving forward. Deprecate isn't the same as remove unless I'm missing something on how this works. I think we want to deprecate it to discourage further use, to gather current use cases, and to drive approved specs for those use cases. Hooks should not be removed from tree until we have the replacements in tree. One other way to do this that I haven't seen mentioned in the thread yet, is create your own middleware code and put it in the wgsi pipeline in Nova api-paste. For the shared secret / injected file case you could process the create server request after keystone but before Nova API proper, do your synchronous call outs, and then add your files to the injected files part of the Nova request body. > > > > >> Yep. My experience with them was things like updating an external cache >> on create/delete or calling out to a DNS provider to remove a reverse >> DNS entry on instance delete. Things that could easily be handled with >> notifications, and use cases that I think we should continue to support >> by improving notifications if necessary. >> >> >>> So, if file injection (and any other internals-mangling that other >>> people may use them for) is not a reason to keep hooks, and if >>> notifications are the proper way to trigger on things happening, then >>> there's no reason to keep hooks. >>> >>> --Dan >>> >>> >>> __ >>> 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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openst
Re: [openstack-dev] [nova] nova-compute blocking main thread under heavy disk IO
For what it's worth Glance API also has to deal with file I/O blocking all greenthreads and has CooperativeReaders/Writers that yield around the file I/O to mitigate starvation. A while ago I hit an issue with 5 concurrent VM snapshots starving Nova compute eventlets due to the excessive file IO of reading the snapshot file to upload. This could be remedied by taking the cooperative reader from Glance API and using it in glanceclient [1]. It's not perfect but something similar could help out the glance image download issues without needing to tweak the OS. [1] https://bugs.launchpad.net/python-glanceclient/+bug/1327248 On Mon, Feb 22, 2016 at 1:13 PM, Chris Friesen wrote: > On 02/22/2016 11:20 AM, Daniel P. Berrange wrote: >> >> On Mon, Feb 22, 2016 at 12:07:37PM -0500, Sean Dague wrote: >>> >>> On 02/22/2016 10:43 AM, Chris Friesen wrote: > > But the fact remains that nova-compute is doing disk I/O from the main thread, and if the guests push that disk hard enough then nova-compute is going to suffer. Given the above...would it make sense to use eventlet.tpool or similar to perform all disk access in a separate OS thread? There'd likely be a bit of a performance hit, but at least it would isolate the main thread from IO blocking. >>> >>> >>> Making nova-compute more robust is fine, though the reality is once you >>> IO starve a system, a lot of stuff is going to fall over weird. >>> >>> So there has to be a tradeoff of the complexity of any new code vs. what >>> it gains. I think individual patches should be evaluated as such, or a >>> spec if this is going to get really invasive. >> >> >> There are OS level mechanisms (eg cgroups blkio controller) for doing >> I/O priorization that you could use to give Nova higher priority over >> the VMs, to reduce (if not eliminate) the possibility that a busy VM >> can inflict a denial of service on the mgmt layer. Of course figuring >> out how to use that mechanism correctly is not entirely trivial. > > > The 50+ second delays were with CFQ as the disk scheduler. (No cgroups > though, just CFQ with equal priorities on nova-compute and the guests.) > This was with a 3.10 kernel though, so maybe CFQ behaves better on newer > kernels. > > If you put nova-compute at high priority then glance image downloads, > qemu-img format conversions, and volume clearing will also run at the higher > priority, potentially impacting running VMs. > > In an ideal world we'd have per-VM cgroups and all activity on behalf of a > particular VM would be done in the context of that VM's cgroup. > > Chris > > > __ > 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] Nova + Glance_v2 = Love
On Fri, Jan 8, 2016 at 11:54 AM, Sam Matzek wrote: > On Fri, Jan 8, 2016 at 8:31 AM, Flavio Percoco wrote: >> On 29/12/15 07:41 -0600, Sam Matzek wrote: >>> >>> On Thu, Dec 24, 2015 at 7:49 AM, Mikhail Fedosin >>> wrote: >>>> >>>> Hello, it's another topic about glance v2 adoption in Nova, but it's >>>> different from the others. I want to declare that there is a set of >>>> commits, >>>> that make Nova version agnostic and allow to work with both glance apis. >>>> The >>>> idea of the solution is to determine the current api version in the >>>> beginning and make appropriate requests after. >>>> (https://review.openstack.org/#/c/228578/, >>>> https://review.openstack.org/#/c/238309/, >>>> https://review.openstack.org/#/c/259097/) >>>> >>>> Indeed, it requires some additional (and painful) work, but now all >>>> tempest >>>> tests pass in Jenkins. >>>> >>>> Note: this thread is not about xenplugin, there is another topic, called >>>> 'Xenplugin + Glance_v2 = Hate' >>>> >>>> Here the main issues we faced and how we've solved them: >>>> >>>> 1. "changes-since" filter for image-list is not supported in v2 api. >>>> Steve >>>> Lewis made a great job and implemented a set of filters with comparison >>>> operators https://review.openstack.org/#/c/197388/. Filtering by >>>> 'changes-since' is completely similar to 'gte:updated_at'. >>>> >>>> 2. Filtering by custom properties must have prefix 'property-'. In v2 >>>> it's >>>> not required. >>>> >>>> 3. V2 states that all custom properties must be image attributes, but >>>> Nova >>>> assumes that they are included in 'properties' dictionary. It's fixed >>>> with >>>> glanceclient's method 'is_base_property(prop_name)', that returns False >>>> in >>>> case of custom property. >>>> >>>> 4. is_public=True/False is visibility="public"/"private" respectively. >>>> >>>> 5. Deleting custom image properties in Nova is performed with >>>> 'purge_props' >>>> flag. If it's set to True, then all prop names, that are not included in >>>> updated data, will be removed. In case of v2 we have to explicitly >>>> specify >>>> prop names in the list param 'remove_props'. To implement this behaviour, >>>> if >>>> 'purge_props' is set, we make additional 'get' request to determine the >>>> existing properties and put in 'remove_prop' list only those, that are >>>> not >>>> in updated_data. >>>> >>>> 6. My favourite: >>>> There is an ability to activate an empty image by just providing 'size = >>>> 0': >>>> https://review.openstack.org/#/c/9715/, in this case image will be a >>>> collection of metadata. Glance v2 doesn't support this "feature" and >>>> that's >>>> why we have to implement a very dirty workaround: >>>> * v2 requires, that disk_format and container-format must be set >>>> before >>>> the activation. if these params are not provided to 'create' method then >>>> we >>>> hardcode it to 'qcow2' and 'bare'. >>>> * we call 'upload' method with empty data (data = '') to activate >>>> image. >>>> Me (and the rest glance team) think that this image activation with >>>> zero-size is inconsistent and we won't implement it in v2. So, I'm going >>>> to >>>> ask if Nova really needs this feature and maybe it's possible to make it >>>> work without it. >>> >>> >>> Nova uses this functionality when it creates snapshots of volume >>> backed instances, that is, instances that only have Cinder volumes >>> attached and do not have an ephemeral disk. >>> In this case Nova API creates Cinder snapshots for the Cinder volumes >>> and builds the block_device_mapping property with block devices that >>> reference the Cinder snapshots. Nova activates this image with size=0 >>> because this image does not have a disk and simply refers to the >>&g
Re: [openstack-dev] [Nova][Glance] Nova + Glance_v2 = Love
On Fri, Jan 8, 2016 at 8:31 AM, Flavio Percoco wrote: > On 29/12/15 07:41 -0600, Sam Matzek wrote: >> >> On Thu, Dec 24, 2015 at 7:49 AM, Mikhail Fedosin >> wrote: >>> >>> Hello, it's another topic about glance v2 adoption in Nova, but it's >>> different from the others. I want to declare that there is a set of >>> commits, >>> that make Nova version agnostic and allow to work with both glance apis. >>> The >>> idea of the solution is to determine the current api version in the >>> beginning and make appropriate requests after. >>> (https://review.openstack.org/#/c/228578/, >>> https://review.openstack.org/#/c/238309/, >>> https://review.openstack.org/#/c/259097/) >>> >>> Indeed, it requires some additional (and painful) work, but now all >>> tempest >>> tests pass in Jenkins. >>> >>> Note: this thread is not about xenplugin, there is another topic, called >>> 'Xenplugin + Glance_v2 = Hate' >>> >>> Here the main issues we faced and how we've solved them: >>> >>> 1. "changes-since" filter for image-list is not supported in v2 api. >>> Steve >>> Lewis made a great job and implemented a set of filters with comparison >>> operators https://review.openstack.org/#/c/197388/. Filtering by >>> 'changes-since' is completely similar to 'gte:updated_at'. >>> >>> 2. Filtering by custom properties must have prefix 'property-'. In v2 >>> it's >>> not required. >>> >>> 3. V2 states that all custom properties must be image attributes, but >>> Nova >>> assumes that they are included in 'properties' dictionary. It's fixed >>> with >>> glanceclient's method 'is_base_property(prop_name)', that returns False >>> in >>> case of custom property. >>> >>> 4. is_public=True/False is visibility="public"/"private" respectively. >>> >>> 5. Deleting custom image properties in Nova is performed with >>> 'purge_props' >>> flag. If it's set to True, then all prop names, that are not included in >>> updated data, will be removed. In case of v2 we have to explicitly >>> specify >>> prop names in the list param 'remove_props'. To implement this behaviour, >>> if >>> 'purge_props' is set, we make additional 'get' request to determine the >>> existing properties and put in 'remove_prop' list only those, that are >>> not >>> in updated_data. >>> >>> 6. My favourite: >>> There is an ability to activate an empty image by just providing 'size = >>> 0': >>> https://review.openstack.org/#/c/9715/, in this case image will be a >>> collection of metadata. Glance v2 doesn't support this "feature" and >>> that's >>> why we have to implement a very dirty workaround: >>> * v2 requires, that disk_format and container-format must be set >>> before >>> the activation. if these params are not provided to 'create' method then >>> we >>> hardcode it to 'qcow2' and 'bare'. >>> * we call 'upload' method with empty data (data = '') to activate >>> image. >>> Me (and the rest glance team) think that this image activation with >>> zero-size is inconsistent and we won't implement it in v2. So, I'm going >>> to >>> ask if Nova really needs this feature and maybe it's possible to make it >>> work without it. >> >> >> Nova uses this functionality when it creates snapshots of volume >> backed instances, that is, instances that only have Cinder volumes >> attached and do not have an ephemeral disk. >> In this case Nova API creates Cinder snapshots for the Cinder volumes >> and builds the block_device_mapping property with block devices that >> reference the Cinder snapshots. Nova activates this image with size=0 >> because this image does not have a disk and simply refers to the >> collection of Cinder snapshots that collectively comprise the binary >> image. Callers of Glance outside of Nova may also use the APIs to >> create "block device mapping" images as well that contain references >> to Cinder volumes to attach, blank volumes to create, snapshots to >> create volumes from, etc during the server creation. Not having the >> ability
Re: [openstack-dev] [Nova][Glance] Nova + Glance_v2 = Love
On Thu, Dec 24, 2015 at 7:49 AM, Mikhail Fedosin wrote: > Hello, it's another topic about glance v2 adoption in Nova, but it's > different from the others. I want to declare that there is a set of commits, > that make Nova version agnostic and allow to work with both glance apis. The > idea of the solution is to determine the current api version in the > beginning and make appropriate requests after. > (https://review.openstack.org/#/c/228578/, > https://review.openstack.org/#/c/238309/, > https://review.openstack.org/#/c/259097/) > > Indeed, it requires some additional (and painful) work, but now all tempest > tests pass in Jenkins. > > Note: this thread is not about xenplugin, there is another topic, called > 'Xenplugin + Glance_v2 = Hate' > > Here the main issues we faced and how we've solved them: > > 1. "changes-since" filter for image-list is not supported in v2 api. Steve > Lewis made a great job and implemented a set of filters with comparison > operators https://review.openstack.org/#/c/197388/. Filtering by > 'changes-since' is completely similar to 'gte:updated_at'. > > 2. Filtering by custom properties must have prefix 'property-'. In v2 it's > not required. > > 3. V2 states that all custom properties must be image attributes, but Nova > assumes that they are included in 'properties' dictionary. It's fixed with > glanceclient's method 'is_base_property(prop_name)', that returns False in > case of custom property. > > 4. is_public=True/False is visibility="public"/"private" respectively. > > 5. Deleting custom image properties in Nova is performed with 'purge_props' > flag. If it's set to True, then all prop names, that are not included in > updated data, will be removed. In case of v2 we have to explicitly specify > prop names in the list param 'remove_props'. To implement this behaviour, if > 'purge_props' is set, we make additional 'get' request to determine the > existing properties and put in 'remove_prop' list only those, that are not > in updated_data. > > 6. My favourite: > There is an ability to activate an empty image by just providing 'size = 0': > https://review.openstack.org/#/c/9715/, in this case image will be a > collection of metadata. Glance v2 doesn't support this "feature" and that's > why we have to implement a very dirty workaround: > * v2 requires, that disk_format and container-format must be set before > the activation. if these params are not provided to 'create' method then we > hardcode it to 'qcow2' and 'bare'. > * we call 'upload' method with empty data (data = '') to activate image. > Me (and the rest glance team) think that this image activation with > zero-size is inconsistent and we won't implement it in v2. So, I'm going to > ask if Nova really needs this feature and maybe it's possible to make it > work without it. Nova uses this functionality when it creates snapshots of volume backed instances, that is, instances that only have Cinder volumes attached and do not have an ephemeral disk. In this case Nova API creates Cinder snapshots for the Cinder volumes and builds the block_device_mapping property with block devices that reference the Cinder snapshots. Nova activates this image with size=0 because this image does not have a disk and simply refers to the collection of Cinder snapshots that collectively comprise the binary image. Callers of Glance outside of Nova may also use the APIs to create "block device mapping" images as well that contain references to Cinder volumes to attach, blank volumes to create, snapshots to create volumes from, etc during the server creation. Not having the ability to create these images with V2 is a loss of function. The callers could supply 1 byte of junk data, like a space character, but that would result in a junk image being stored in Glance's default backing store for the image. It would also give the impression that a real disk image exists for the image in a backing store which could be fetched, which is incorrect. If I remember correctly Glance V2 lets you transition an image from queued to active state with size = 0 if the image is using an external backing store such as http. The store is then called to fetch the size. Would it be possible to allow Glance to consider images with size = 0 and the block_device_mapping property to be "externally sourced" and allow the transition? > > In conclusion, I want to congratulate you with this huge progress and say > there is a big chance that we can deprecate glance v1 in Mitaka cycle. > > Hooray! > And Merry Christmas! > > -- > Best regards, > Mikhail Fedosin > > __ > 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
Re: [openstack-dev] [nova] Volume attachment APIs CRUD inconsistencies
Thanks. So it looks like os_volume-attachments has now been linked
into the 2.1 doc. The lack of documentation for the PUT / update
attachment doc was also noted on the etherpad. So my only remaining
questions revolve around the dual and differing API implementations of
the read volume attachments operation. More info is placed inline.
On Fri, Dec 11, 2015 at 8:41 PM, Anne Gentle
wrote:
>
>
> On Fri, Dec 11, 2015 at 8:38 PM, Anne Gentle
> wrote:
>>
>>
>>
>> On Fri, Dec 11, 2015 at 7:33 PM, Matt Riedemann
>> wrote:
>>>
>>>
>>>
>>> On 12/11/2015 1:48 PM, Sam Matzek wrote:
>>>>
>>>> The CRUD operations for Nova volume attachments have inconsistencies
>>>> between documentation and implementation. Additionally, the read/get
>>>> operation is implemented twice under different URIs. What is Nova's
>>>> direction for volume attachment APIs and how should the following
>>>> discrepancies be resolved?
>>>>
>>>> The current state of affairs is:
>>>> CREATE (volume attach) is documented twice under two different URIs: [1]
>>>> and [2], but only os-volume_attachments [1] is implemented [3].
>>
>>
>> Matt, can you look a little deeper into what happened to
>> os-volume_attachments? I'm worried we've missed one of the extensions.
>>
>> As for the docs, I thought we put in redirects from v2 to v2.1 but I need
>> to investigate.
>>
>
> And to answer my own question, yes, line 226 of the Etherpad indicates that
> doc is missing. Easy enough to add if anyone wants to grab a low-hanging
> (read:easy) patch.
>
> I'm going to hold off on the redirects until much more of that Etherpad
> indicates cleanup.
>
> Anne
>
>>
>> Anne
>>
>>>>
>>>> Attach volume as an action on the servers URI appears to have been part
>>>> of the Nova V3 API, but its implementation no longer exists.
>>>> Is it the future direction to have volume attach and detach done as
>>>> server actions?
>>>>
>>>> READ is implemented twice and documented twice under two different URIs:
>>>> os-volume_attachments [5] and server details [6]
>>>> The two implementations do not return the same information and the only
>>>> bit of information that is common between them is the volume ID.
>>>> Why do we have two implementations and is one preferred over the other?
>>>> Should one be deprecated and eventually removed with all enhancements
>>>> going into the other?
What if anything, should we do about the competing read
implementations? I think they should be made to have some amount of
common source and return the same information for volume attachments.
GET /v2.1/{tenant_id}/servers/{server_id} returns this, which includes
the delete_on_termination flag with microversion 2.3:
...
"os-extended-volumes:volumes_attached": [
{"id": "f350528f-408d-4ac6-8fe3-981c0aef3dc8",
"delete_on_termination": true}
], ...
GET /v2.1/{tenant_id}/servers/{server_id}/os-volume_attachments
{
"volumeAttachments": [
{"device": "/dev/sda",
"bootIndex": 0,
"serverId": "15f2acd0-e254-4ce6-b490-f70154fbd481",
"id": "f350528f-408d-4ac6-8fe3-981c0aef3dc8",
"volumeId": "f350528f-408d-4ac6-8fe3-981c0aef3dc8"
}
]
}
>>>>
>>>> UPDATE is implemented [4] but not documented.
>>>>
>>>> DELETE (detach) only appears to be implemented and documented once: [7]
>>>>
>>>> A blueprint proposal exists [8] to enhance the attach and update APIs to
>>>> set and modify the delete_on_termination flag. The discrepancies in the
>>>> create and read operations calls into question whether the update change
>>>> should be on the PUT /servers API to match the server's read [6] or if
>>>> the os-volume_attachments update API should be modified to line up with
>>>> os-volume_attachments read.
>>>>
>>>>
>>>> [1]
>>>> http://developer.openstack.org/api-ref-compute-v2-ext.html#attachVolume
>>>> [2] http://developer.openstack.org/api-ref-compute-v2.1.html#attach
>>>> [3]
>>>>
>>>> https://ask.openstack.org/en/question/85242/the-api-action-attach-is-missing/
>>>> [4]
>>>>
>>>> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/volumes.py#L318
>>>> [5]
>>>> http://developer.openstack.org/api-ref-c
[openstack-dev] [nova] Volume attachment APIs CRUD inconsistencies
The CRUD operations for Nova volume attachments have inconsistencies between documentation and implementation. Additionally, the read/get operation is implemented twice under different URIs. What is Nova's direction for volume attachment APIs and how should the following discrepancies be resolved? The current state of affairs is: CREATE (volume attach) is documented twice under two different URIs: [1] and [2], but only os-volume_attachments [1] is implemented [3]. Attach volume as an action on the servers URI appears to have been part of the Nova V3 API, but its implementation no longer exists. Is it the future direction to have volume attach and detach done as server actions? READ is implemented twice and documented twice under two different URIs: os-volume_attachments [5] and server details [6] The two implementations do not return the same information and the only bit of information that is common between them is the volume ID. Why do we have two implementations and is one preferred over the other? Should one be deprecated and eventually removed with all enhancements going into the other? UPDATE is implemented [4] but not documented. DELETE (detach) only appears to be implemented and documented once: [7] A blueprint proposal exists [8] to enhance the attach and update APIs to set and modify the delete_on_termination flag. The discrepancies in the create and read operations calls into question whether the update change should be on the PUT /servers API to match the server's read [6] or if the os-volume_attachments update API should be modified to line up with os-volume_attachments read. [1] http://developer.openstack.org/api-ref-compute-v2-ext.html#attachVolume [2] http://developer.openstack.org/api-ref-compute-v2.1.html#attach [3] https://ask.openstack.org/en/question/85242/the-api-action-attach-is-missing/ [4] https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/volumes.py#L318 [5] http://developer.openstack.org/api-ref-compute-v2-ext.html#attachVolume [6] http://developer.openstack.org/api-ref-compute-v2.1.html#listDetailServers [7] http://developer.openstack.org/api-ref-compute-v2-ext.html#deleteVolumeAttachment [8] https://blueprints.launchpad.net/nova/+spec/delete-on-termination-modification __ 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
