Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-10
17:34:54 diga cdent: thanks for your help
17:35:24 diga cdent: mriedem : will ping you if I need any help, will update you by tomorrow
17:38:25 cfriesen mdbooth: sorry, was off in a meeting. Yes, the initial spawn fails when the ephemeral disk is too big. I wonder if we could change the default based on size, to either use something else or just not format it instead of choking.
17:39:55 mdbooth cfriesen: I think it has to be considered part of the api. I think the only change we can make to it without a microversion bump is a minimal change to make it not fail.
17:40:21 mdbooth cfriesen: So we could, for eg, not format it at all, but only in the case that we know it would cause a failure to build.
17:41:52 cfriesen mdbooth: agreed. I'll open a bug and maybe propose a fix.
18:53:51 openstackgerrit melanie witt proposed openstack/nova master: Detach volume after deleting instance with no host https://review.openstack.org/340614
18:55:18 mriedem stvnoyes: finally got that multiattach snapshot test to pass http://logs.openstack.org/86/531386/7/check/tempest-full/2f25c03/job-output.txt.gz#_2018-01-10_02_15_35_840008
18:56:01 stvnoyes excellent. I've been working on libvirt 3.10. Finally got past the dependency issues working on getting stack up now
18:56:33 mriedem for the tempest patch, it's getting big, so i might need to think about splitting it up
18:56:40 mriedem mtreinish: how do you feel about this? https://review.openstack.org/#/c/266605/25/tempest/api/compute/volumes/test_attach_volume.py
18:56:53 melwitt is anyone willing to please review the local delete patch ^ if an instance with attached volumes etc goes into error state, when it's deleted the volumes and networks aren't disconnected from the instance and have to be manually disconnected in order to be used again
18:56:56 mriedem should i do the first patch with the config option and 1 test, then add the other tests in subsequent patches?
19:01:06 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: vSCSI volume driver https://review.openstack.org/526094
19:04:02 openstackgerrit Matt Riedemann proposed openstack/nova master: Add pagination and Changes-since filter support for os-migrations. https://review.openstack.org/330406
19:04:03 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix comment in MigrationSortContext https://review.openstack.org/532368
19:04:03 openstackgerrit Matt Riedemann proposed openstack/nova master: Add index(updated_at) on migrations table. https://review.openstack.org/531132
19:05:31 ameeda Hello, when I try to deploy overcloud on baremetal using undercloud "installed at vm" I got this error "No compute node record for host undercloud: ComputeHostNotFound_Remote: Compute host undercloud could not be found." from nova-compute.log file
19:05:43 ameeda what can I do with that ?
19:10:00 openstackgerrit Mark Goddard proposed openstack/nova master: Add get_traits() method to ComputeDriver https://review.openstack.org/532287
19:10:00 openstackgerrit Mark Goddard proposed openstack/nova master: WIP: Send traits to ironic on server boot https://review.openstack.org/508116
19:10:01 openstackgerrit Mark Goddard proposed openstack/nova master: Call get_traits() in the resource tracker https://review.openstack.org/532290
19:10:01 openstackgerrit Mark Goddard proposed openstack/nova master: Add support to scheduler client for setting traits https://review.openstack.org/532539
19:10:02 openstackgerrit Mark Goddard proposed openstack/nova master: Implement get_traits() for the ironic virt driver https://review.openstack.org/532288
19:10:45 rybridges Hey guys. Got another question for you today. Is there a way to update the user-data on an instance after it is in the build state during the boot flow? I have a hunch that it is not possible because once the instance is in the build state, the user-data and config driver stuff have already been written out onto the that instance's partition on the hypervisor. Meaning in order to update the user data
19:10:47 rybridges on the instance after it is built, we would need some api capable of modifying user data on the instance. does something like that exist?
19:19:11 melwitt I'm not sure if it's done yet but the plan was to allow user data to be provided during a rebuild
19:19:25 rybridges hmm
19:19:45 rybridges i am talking more from a coding point of view rather than from a user's point of view
19:19:51 rybridges like in the code of the boot flow
19:20:10 rybridges is there a way to update that user data after the instance has already been built
19:21:04 rybridges so for example
19:22:01 rybridges if you update the user data at this point https://github.com/OpenStack/nova/blob/stable/ocata/nova/compute/api.py#L944
19:22:09 rybridges which is before the instance is actually created on the HV
19:22:28 rybridges then when the instance is actually created on the HV, it will get your user data
19:22:55 rybridges but if you do it after that... I am thinking it wont update because updating would involve rewriting a file on the hypervisor
19:34:06 melwitt rybridges: so you're saying you want to modify the user data after it's been provided by the end user?
19:34:34 melwitt but it's not the end user themselves who want to update it?
19:35:03 melwitt it sounds like what you want is the vendor data stuff
19:41:34 melwitt https://docs.openstack.org/nova/latest/user/vendordata.html
19:48:49 rybridges eh.. not quite. That's okay. Thanks melwitt
19:52:12 mriedem he's looking for the server create hook
19:52:17 mriedem which has been deprecated forever
20:01:59 mtreinish mriedem: what do you want me to look at there?
20:04:16 mriedem mtreinish: so i've got the 3 tests in there passing,
20:04:26 mriedem but, that patch also has some setup stuff so it's getting large,
20:04:44 mriedem was thinking about changing that to just be the first test, and then put 1 patch per new test on top of that in a series
20:04:58 mriedem since there are a bunch of TODOs in there for more tests, i didn't want to hold that single patch for all of the tests
20:05:23 mtreinish mriedem: sure, that sounds like a sane way to handle it
20:05:26 mriedem ok
20:05:36 mriedem just wanted to make sure since it's going to be a bit of work
20:05:52 mtreinish I did quickly look at the tests the other day when you linked me to them and they seemed fine to me
20:06:22 mtreinish mriedem: I mean it's not that long a patch with the 3 tests in one. I'd be fine reviewing it as is too
20:06:23 mriedem the two patches below that one are ready to go
20:06:29 mtreinish it's really your call
20:06:33 mriedem yeah i knew you would probably, but for others
20:06:35 mriedem i'll split it up
20:06:43 mriedem plus then it will rock my tempest stats!
20:07:00 mtreinish heh, got to maintain your top 10 committer status :)
20:07:09 mriedem you know it
20:08:10 mriedem heh i didn't know that was still a thing http://stackalytics.com/?release=all&module=tempest&metric=commits
20:08:31 mriedem soon i can catch up with old man dague
20:09:30 mtreinish mriedem: heh, nice
20:20:48 sdague mriedem: yeh, well... you youngins
20:20:59 mriedem i can hear your fist shaking from here
20:52:50 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM driver: ovs vif https://review.openstack.org/422512
20:53:12 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: SEA https://review.openstack.org/523216
20:53:46 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: vSCSI volume driver https://review.openstack.org/526094
20:57:20 mriedem this was added in 2014: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L1022
20:57:26 mriedem seems it might be time to remove the get()
20:57:47 mriedem since the dfeault in cinder for new volumes is bootable=False
21:04:31 openstackgerrit Sylvain Bauza proposed openstack/nova master: libvirt: create vGPU for instance https://review.openstack.org/528832
21:04:32 openstackgerrit Sylvain Bauza proposed openstack/nova master: WIP: libvirt: Use only existing mdevs if kernel race https://review.openstack.org/531853
21:04:32 openstackgerrit Sylvain Bauza proposed openstack/nova master: libvirt : Force a specificly static UUID for a mediated device https://review.openstack.org/531752
21:04:54 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: vSCSI volume driver https://review.openstack.org/526094
21:39:03 mriedem ildikov: on the multiattach api patch, i've got the rest api controller tests done, added a happy path functoinal test for boot from volume and attach to an existing server, and now working on negative tests for the error conditions in the API code - that should wrap it up
21:39:31 mriedem then ill split up the tempest test patch tomorrow probably
21:40:09 ildikov mriedem: ack
21:40:33 ildikov mriedem: is there anything stvnoyes or me should/could do?
21:41:33 mriedem yeah, something on my todo list is we're going to need a CI job defined for multiattach, probably in the nova experimental queue
21:41:39 mriedem based on the devstack patches i have
21:41:40 mriedem https://review.openstack.org/#/c/531386/
21:42:20 mriedem i'm not sure if that job definition should live in nova with zuulv3, or if it should live in openstack-zuul-jobs since we'd want to run it on nova/cinder/tempest/devstack patches
21:42:32 mriedem mordred: ^ is there guidance on where a job should live if it's going to be run by multiple projects?
21:43:20 ildikov mriedem: ok
21:43:22 stvnoyes mriedem: i am testing multiattach on libvirt 3.10.. so far it's working ok. But I just noticed that one of the libvirt modules, libvirt-bin, is at 3.6. The Debian site says "This is a transitional package." Do you think it matters?
21:44:00 stvnoyes I'm having trouble finding a 3.10 version of that.
21:44:02 mriedem i don't know what a transitional package is
21:44:08 mriedem would probably have to ask zigo
21:45:13 ildikov stvnoyes: do you have bandwidth to look into the CI job too?
21:45:36 mordred mriedem: in general the idea is to have it live as close to the people who would be the most natural 'owners'
21:46:01 stvnoyes I left out the import note that followed - "This is a transitional package. You can safely remove it." That's why I was thinking it might not matter.
21:46:55 mriedem mordred: hmm, ok, i guess that is probably nova...
21:47:02 mriedem or...devstack
21:47:15 mordred mriedem: it's perfectly acceptable to make a nova-devstack-multiattach in the nova repo and then have cinder, devstack, tempest repos add it to their .zuul.yaml files
21:47:29 mriedem yeah i guess we'll just start with it in nova
21:47:32 mordred or it could totally go in devstack, or tempest :)
21:47:42 mriedem since the only tests so far are compute api tests in tempest
21:48:07 mriedem ildikov: stvnoyes: if one of you do start on that, the first nova patch for zuulv3 layout is https://review.openstack.org/#/c/514309/ so you'd likely build on that
21:48:13 stvnoyes mriedem ildikov: as for the CI job, I can take a look. I haven't played around with CI jobs before, but I can see how far I get

Earlier   Later