| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-06 | |||
| 07:31:59 | openstackgerrit | Wangpan proposed openstack/nova master: Handle glance exception during rotating instance backup https://review.openstack.org/523395 | |
| 07:34:20 | openstackgerrit | Wangpan proposed openstack/nova master: Handle glance exception during rotating instance backup https://review.openstack.org/523395 | |
| 07:47:23 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Fix a description for 'guest_format' https://review.openstack.org/525928 | |
| 08:20:49 | Rambo__ | Now the boot from volume 's instance of rebuild operation has a problem.For example,after the rebuild operation,the instance 's root disk is not replace. | |
| 08:20:50 | Rambo__ | To solve it,I plan to use CLI 's "metadata" option,to increase a key name "source_type".The "source_type" includes "snapshot" and "image".We can judge from "source_type".If the "source_type" is "snapshot",we can transform the given snapshot to a volume and attach this volume to instance.If the "source_type" is "image",we don't handle it. | |
| 08:20:50 | Rambo__ | I found the reason is that when we use the "_build_resources" function to prepare source,it obtains the block devices according to the previous instance 's uuid and attaches them to instance.So boot from volume 's instance of rebuild operation doesn't update data. | |
| 08:20:53 | Rambo__ | Can you give me some advice?Help in troubleshooting this issue will be appreciated. | |
| 08:25:33 | openstackgerrit | wanghongxu proposed openstack/nova master: Update cinder info when attach volume that attached https://review.openstack.org/525540 | |
| 08:43:54 | openstackgerrit | zhangyanxian proposed openstack/nova-specs master: Sriov-bond https://review.openstack.org/463526 | |
| 08:49:12 | openstackgerrit | zhangyanxian proposed openstack/nova-specs master: Sriov-bond https://review.openstack.org/463526 | |
| 08:51:30 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: [WIP] POC to use neutron port_list when filtering instance by ip https://review.openstack.org/525505 | |
| 08:55:42 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add abstract OVSDB API https://review.openstack.org/476612 | |
| 09:00:47 | openstackgerrit | Wangpan proposed openstack/nova master: Handle glance exception during rotating instance backup https://review.openstack.org/523395 | |
| 09:05:12 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: [WIP] POC to use neutron port_list when filtering instance by ip https://review.openstack.org/525505 | |
| 09:05:44 | openstackgerrit | Gyorgy Szombathelyi proposed openstack/nova stable/ocata: Use proper user and tenant in the owner section of libvirt.xml. https://review.openstack.org/525997 | |
| 09:17:53 | openstackgerrit | zhurong proposed openstack/nova master: Remove the unused request_id filter from api-paste.ini https://review.openstack.org/526001 | |
| 09:30:48 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add late server group policy check to rebuild https://review.openstack.org/525242 | |
| 09:32:59 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add late server group policy check to rebuild https://review.openstack.org/525242 | |
| 09:51:34 | openstackgerrit | Stephen Finucane proposed openstack/nova master: test: Store the OutputStreamCapture fixture https://review.openstack.org/515146 | |
| 09:51:35 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-status: Migrate to cliff https://review.openstack.org/515147 | |
| 09:51:35 | openstackgerrit | Stephen Finucane proposed openstack/nova master: trivial: Rename 'policy_check' -> 'policy' https://review.openstack.org/515148 | |
| 09:51:36 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-policy: Migrate to cliff https://review.openstack.org/515149 | |
| 10:12:41 | openstackgerrit | Merged openstack/python-novaclient master: Avoid tox_install.sh for constraints support https://review.openstack.org/524837 | |
| 10:30:27 | openstackgerrit | Merged openstack/python-novaclient master: Microversion 2.56 - Enable cold migration with target host https://review.openstack.org/406707 | |
| 10:43:15 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Migrate from 'ip' commands to 'pyroute2' https://review.openstack.org/484386 | |
| 10:49:18 | openstackgerrit | Merged openstack/nova master: Fail fast if changing image on a volume-backed server rebuild https://review.openstack.org/520660 | |
| 10:49:24 | openstackgerrit | Merged openstack/nova master: Updated from global requirements https://review.openstack.org/525386 | |
| 12:31:28 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Migrate from 'ip' commands to 'pyroute2' https://review.openstack.org/484386 | |
| 12:42:40 | openstackgerrit | Takashi NATSUME proposed openstack/python-novaclient master: Microversion 2.57 - List/Show all server migration types https://review.openstack.org/430839 | |
| 12:43:27 | openstackgerrit | Merged openstack/nova master: Genericify the instance_list stuff https://review.openstack.org/524253 | |
| 12:43:34 | openstackgerrit | Merged openstack/nova master: Split instance_list into instance and multi_cell https://review.openstack.org/524302 | |
| 13:04:16 | efried | Greetings cdent. How goes the grenade sleuthing? | |
| 13:04:35 | cdent | some progress at: https://review.openstack.org/#/c/525605/ | |
| 13:05:24 | cdent | gist is that grenade and devstack’s handing of placemen a bit out of wack: no stop from grenade, important config being erased by devstack | |
| 13:05:44 | efried | grisly. | |
| 13:05:49 | sean-k-mooney2 | bauzas: johnthetubaguy ye are both on the nova satable matainance team correct? can ye take a look at this trival change in os-vif https://review.openstack.org/#/c/488670/ we dont have a seperate release team so we use nova's | |
| 13:06:13 | cdent | efried: I think that because placement went wsgi before everything else, some later learnings didn’t get incorporated into its devstack handkling | |
| 13:06:34 | cdent | and because placement is managed in grenade as part of nova, despite being its own thing in devstack, caused some packet drops | |
| 13:17:56 | bauzas | sean-k-mooney2: lemme look | |
| 13:19:28 | mdbooth | Folks, has anybody else encountered MySQL-python FTB on Fedora 27? | |
| 13:19:47 | sean-k-mooney2 | bauzas: its just an update to the .gitreview but its been open for a few months now so would be good to merge | |
| 13:20:12 | mdbooth | This django bug shows the issue I hit: https://github.com/OWASP/django-DefectDojo/issues/407 | |
| 13:20:23 | bauzas | sean-k-mooney2: +2 | |
| 13:20:50 | sean-k-mooney2 | bauzas: thanks | |
| 13:28:50 | jaypipes | efried: welcome back | |
| 13:29:11 | jaypipes | cdent: any prog on that bug? | |
| 13:30:03 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: archive_deleted_instances is not atomic for insert/delete https://review.openstack.org/526065 | |
| 13:30:08 | cdent | jaypipes: yeah, it has fixes that need be merged, the tests underneath this are passing: https://review.openstack.org/#/c/525605/ there’s a dependent devstack change and a backport of that devstack change | |
| 13:30:19 | cdent | sdague, dansmith ^ | |
| 13:30:54 | cdent | jaypipes: it was a bit of an onion | |
| 13:31:03 | jaypipes | cdent: sounds like it indeed :( | |
| 13:34:06 | sdague | cdent: I approved the 2 devstack changes, I guess we are waiting on grenade results to come in? | |
| 13:34:29 | efried | jaypipes Howdy, thanks. I'm poring over emails to see where you got to with those patches. | |
| 13:34:30 | cdent | sdague: Yeah, I’ve been watrching zuul and the two main grenade changes have passed | |
| 13:34:50 | cdent | heat (non-voting) has vailed and ironic is being slow | |
| 13:34:50 | efried | jaypipes I didn't intend for you to have to do that stuff - I realized it had gotten pretty ugly at this point with all the stuff that changed underneath it. | |
| 13:35:19 | jaypipes | efried: well, I had to give up after f**king up the series in a failed rebase. | |
| 13:35:44 | cdent | vailed is a word I will use to mean something like “veiled in failure” | |
| 13:36:06 | jaypipes | efried: heh | |
| 13:36:18 | jaypipes | efried: https://review.openstack.org/#/c/385693/ is where I stopped after a revert of the rebase attempt. | |
| 13:36:18 | efried | cdent Or a verb related to an overpriced ski resort. | |
| 13:36:28 | cdent | that fails to satisfy | |
| 13:37:06 | jaypipes | I'm also at my wit's end w.r.t the REST API patch for nested resource providers. | |
| 13:37:25 | jaypipes | so much for trying to merge things quickly and tweak afterwards. | |
| 13:37:43 | sdague | cdent: is the heat one normally passing? | |
| 13:37:47 | jaypipes | let's bikeshed on shit some more, just for fun. | |
| 13:37:51 | efried | jaypipes What's the rub there? Are we just bikeshedding tree vs in_tree? | |
| 13:38:27 | jaypipes | efried: that, yes, and placement-api-ref weirdness. | |
| 13:39:02 | jaypipes | efried: I'm tired of the placement api ref docs crap, frankly. | |
| 13:39:09 | cdent | sdague: it’s hard to tell, there haven’t been many changes to grenade since zuul | |
| 13:39:15 | jaypipes | efried: in particular, these comments: https://review.openstack.org/#/c/384807/85/placement-api-ref/source/resource_provider.inc | |
| 13:39:29 | jaypipes | efried: the parameters are not required. they are optional. | |
| 13:39:31 | cdent | sdague: but this recent change passes: https://review.openstack.org/#/c/525720/ | |
| 13:39:58 | jaypipes | efried: but takashi wants to indicate that the *response* attributes will always be there, so insists I put required: true in the parameters file. | |
| 13:40:01 | efried | So I agree that in_tree would be clearer; else we're sorta giving the impression that a tree is an entity in its own right with a UUID. But super-meh. This is an API, and people are going to have to read the docs to figure out what it means regardless of whether it's called `tree` or `in_tree`. | |
| 13:40:29 | efried | WRT the docs, my *strong* preference at this point would be to merge what we have so we can get *code* going, and then follow up with docs tweaks. | |
| 13:41:05 | jaypipes | efried: that was my preference as well, but I've now attempted to comply with the review requests on the docs stuff and broken the api-ref build. | |
| 13:42:01 | efried | jaypipes Let me catch up on the review comments. I can take over fixing up the api-ref build if you're getting burned out. | |
| 13:42:16 | jaypipes | efried: I'm way burned out on this, yes. | |
| 13:42:43 | jaypipes | efried: and other than not wanting to go with "tree_member", I don't care about tree vs. in_tree. | |
| 13:43:05 | efried | jaypipes What's it at right now in the patch? | |
| 13:43:32 | jaypipes | tree | |
| 13:44:33 | jaypipes | efried: I'll fix it. gimme 10 mins | |
| 13:44:51 | efried | jaypipes cdent edleafe bauzas can we take a quick vote? Sounds like jaypipes is +1 on tree/in_tree and -1 on tree_member; I'm the same. | |
| 13:44:58 | jaypipes | efried: but you can do the rebase for your WIP patches above it. | |
| 13:45:05 | efried | jaypipes ight. | |
| 13:45:16 | jaypipes | efried: I'm +1 on just get this friggin done. | |
| 13:45:25 | efried | ++ | |
| 13:45:46 | efried | You have to respin the patch anyway; but renaming that query param is slightly nontrivial compared to fixing the doc build. | |
| 13:45:49 | cdent | -1 on tree_member, slight preference for in_tree over tree, but not enough to be upset if tree is the result | |
| 13:47:09 | cdent | brb | |
| 13:50:55 | bauzas | jaypipes: I agree with you on the fact it's just a verbiage problem, so a nit, but honestly, given it would be an API parameter, I prefer to make sure we discuss that | |
| 13:52:30 | jaypipes | bauzas: this patch is >1 year old. let's make a decision and do this. | |
| 13:52:35 | bauzas | exactly | |
| 13:52:38 | bauzas | so | |
| 13:52:42 | bauzas | tree, -1 for me | |
| 13:52:48 | bauzas | in_tree : +0 | |
| 13:53:04 | maciejjozefczyk | Hello Guys, im trying to debug why I've faced a problem with scheduling. My instances stucks in 'scheduling' state. After enabling debug on nova-scheduler I've found that a host was selected. On nova-compute side there were 0 info about building an instance. It could be possible that the failure point is nova-conductor? | |
| 13:53:11 | bauzas | tree_member : +1 | |
| 13:53:26 | bauzas | or tree_node | |