Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-10
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
21:48:23 stvnoyes ok I'll take a look at that
21:48:26 mriedem stvnoyes: it's mostly copy and tweak
21:48:53 mriedem we just need it to set this devstack variable https://review.openstack.org/#/c/531386/7/stackrc
21:48:57 mgagne mriedem: when deprecating a rule name in oslo.policy, will the generator create an alias for the old name? My concern is with Horizon which might/will still use the legacy name until updated.
21:49:20 mordred mriedem: this could be your first nova zuulv3-native job :)
21:49:23 mriedem like https://review.openstack.org/#/c/514309/10/playbooks/legacy/nova-lvm/run.yaml@33
21:49:27 stvnoyes mriedem: kk, btw, is there any specific test you'd like to see with libvirt 3.10? So far, attach & detach are working ok. Was their a particular scenario that was failing?
21:49:29 mriedem mordred: that i did?
21:50:04 mriedem stvnoyes: the tempest patch is testing attach/detach to 2 servers, boot from volume with 1 server, and boot from volume and snapshot that volume-backed server
21:50:23 ildikov stvnoyes: thanks much!
21:50:27 mriedem stvnoyes: i think we also need testing for resize/cold migrate and swap volume
21:50:50 stvnoyes all manual for now I presume?
21:50:58 mriedem stvnoyes: sure, until we write tempest patches
21:51:18 mriedem stvnoyes: if you want to add a resize test on top of the tempest patch https://review.openstack.org/#/c/266605/ go ahead
21:51:20 mriedem should be pretty simple
21:51:36 stvnoyes kk I'll do that
21:51:41 mriedem swap volume gets tricky b/c that's an admin-only operation so i think that has to live in a different tree structure in tempest
21:51:50 mriedem tempest/api/compute/admin/
21:52:19 mriedem would live in here somewhere https://github.com/openstack/tempest/blob/master/tempest/api/compute/admin/test_volume_swap.py

Earlier   Later