Earlier  
Posted Nick Remark
#openstack-nova - 2017-10-04
14:05:53 sahid libvirt have a pci device manager, and it's a bad idea to just ignore it
14:05:53 dansmith yep, it's a first step to get us basic support, as stated above
14:07:00 sahid but it's a hack, no need ot RP or anything to provide that basic support
14:09:49 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add support for Windows network commands https://review.openstack.org/487405
14:13:40 openstackgerrit Eric Berglund proposed openstack/nova master: WIP(5): PowerVM driver: ovs vif https://review.openstack.org/422512
14:13:51 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add Port Profile info to VIF objects Linux Bridge plugin https://review.openstack.org/490829
14:15:08 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add VersionedObjectPrintable mixin https://review.openstack.org/493082
14:18:47 openstackgerrit Takashi NATSUME proposed openstack/nova master: Fix test_get_volume_config method https://review.openstack.org/489467
14:20:39 openstackgerrit Balazs Gibizer proposed openstack/nova master: factor out compute service start in ServerMovingTest https://review.openstack.org/503037
14:20:39 openstackgerrit Balazs Gibizer proposed openstack/nova master: Test resource allocation during soft delete https://review.openstack.org/495159
14:23:10 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove unused get_all_instance_*metadata methods https://review.openstack.org/508299
14:23:11 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove old compat code from servers ViewBuilder._get_metadata https://review.openstack.org/508326
14:23:11 openstackgerrit Matt Riedemann proposed openstack/nova master: Stop joining on system_metadata when listing instances https://review.openstack.org/508335
14:23:12 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove system_metadata loading in Instance._load_flavor https://review.openstack.org/508357
14:24:57 dansmith jaypipes: bauzas: stephenfin: easy +W on this cleanup: https://review.openstack.org/#/c/508299/2
14:25:40 jaypipes dansmith: finito
14:26:03 dansmith jaypipes: ${thanks_in_some_fancy_language}
14:26:14 jaypipes :)
14:35:21 mriedem whew, got my aussy visitor visa
14:36:27 dansmith um I believe it's "aussie"
14:56:11 cdent anybody able to sail this gabbi test addition, already has jay’s +2: https://review.openstack.org/#/c/485209/
14:57:19 gibi cdent: looking...
14:57:28 cdent thanks
14:58:12 gibi dansmith was faster
14:58:36 cdent thanks danpawlik
14:58:45 cdent oh noes! thanks dansmith
14:58:54 danpawlik cdent: lol
14:58:56 danpawlik :D
14:59:04 danpawlik cdent: I was wondering why you thanks me :D
14:59:23 cdent danpawlik: I’m sure you’ve done something worth being thanked for? Thanks for existing.
14:59:24 gibi danpawlik: now you have to do someting for cdent :)
15:00:26 danpawlik gibi: In that case, Im going to work!
15:00:34 danpawlik cdent: :D
15:10:40 melwitt mriedem: I started looking at the ceph job last night and something weird is happening where keystone can't start. still researching how to fix it
15:11:31 mriedem ok, but it's still a smoldering pile despite that
15:19:56 openstackgerrit Matt Riedemann proposed openstack/nova master: Modernize set_vm_state_and_notify https://review.openstack.org/499799
15:19:56 openstackgerrit Matt Riedemann proposed openstack/nova master: Pass migration from API to conductor for evacuate https://review.openstack.org/500176
15:26:05 melwitt mriedem: I see now, the keystone thing must have been from getting zuul'd. the failures I see now are from a 404 from cinder api test, like you said last time
15:26:47 smcginnis melwitt: Anything you need us to look at?
15:27:06 mriedem there was a long-standing change in cinder for ceph,
15:27:16 mriedem that jbernard thought would help stabilize some things
15:27:55 mriedem https://review.openstack.org/#/c/281550/
15:28:45 mriedem and there was an alternative proposed https://review.openstack.org/#/c/432326/
15:29:50 mriedem as far as i can tell, something something locks
15:30:37 mriedem there are some newer volume snaphot tests in tempest that are failing at a pretty high rate, globally, so those are probably not helping the situation
15:30:37 melwitt smcginnis: not yet sure. there's a couple of cinder api tempest tests failing on only our ceph job (for a long time) and I'm starting to look at it
15:31:05 mriedem and by "the situation", yes, i mean this guy http://pmcdeadline2.files.wordpress.com/2014/03/mike-the-situation__140331172717.jpg
15:32:01 openstackgerrit Merged openstack/nova-specs master: List/show all server migration types https://review.openstack.org/489029
15:32:54 openstackgerrit Matt Riedemann proposed openstack/nova master: What is the meaning of....recreate? https://review.openstack.org/508190
15:38:51 mriedem sdague: dansmith: grenade creates a vm and leaves it running through the upgrade so it can ping it on the other side right?
15:39:02 dansmith mriedem: yeah
15:39:10 mriedem ok, i guess nova supports accessible upgrades then!
15:39:12 mriedem yay more tags
15:39:52 dansmith is that what that tag means?
15:40:03 dansmith because there was "no-impact-upgrades" proposed at one point that covered that bit
15:40:16 cdent nobody is ever sure
15:40:36 cdent smcginnis tried to kill the accessible tag but then someone came along and said, but wait, nova and cinder match that one
15:40:57 mriedem there are like 5-6 upgrade tags
15:41:12 mriedem i didn't know what a "controlled resource" was in reading the description,
15:41:14 mriedem assumed it was a VM,
15:41:25 mriedem but without examples in the tag descriptions it's hard to know what the author intended
15:42:04 mriedem i know what it means to the ATF...
15:42:06 cdent in nova’s case it does mean that running vm survives and can be worked with (accessed) through an upgrade
15:42:21 mriedem so what is "no-impact-upgrades"?
15:42:22 cdent but yeah, it’s entirely unclear
15:42:27 cdent dunno! :)
15:42:31 cdent I don’t like tags
15:42:33 mriedem weeeeeeeee
15:42:44 mriedem i don't either really, but probably for slightly different reasons
15:43:08 cdent i cannot say, since I dont know why you don’t like
15:43:19 mriedem no one in the dev teams probably thinks about tags
15:43:25 mriedem e.g. there is no bi-annual audit
15:43:39 mriedem i do'nt know what stick or carrot exists for us to care about tags
15:44:09 mriedem and i do'nt know if people consuming openstack are really giving them much weight, but maybe they are depending on project,
15:44:22 mriedem e.g. if there are 3 monitoring type projects, you'd care about what tags are applied to those
15:44:25 cdent the stick or carror aspect is part of my concerns
15:46:53 sdague mriedem: a bunch of them were going to be purged
15:47:16 sdague mriedem: there is a distinction somewhere about 0 api downtime
15:47:23 sdague which is important for things like keystone
15:47:35 sdague because, if keystone is out, operations fail randomly
15:51:22 mriedem i think that's the zero-downtime-upgrade one
15:51:34 mriedem the zero-impact-upgrade one is about performance during upgrade, as my understanding
15:51:46 mriedem so there are subtle differences
15:51:47 dansmith yeah something
15:51:58 mriedem replied to the ML thread on this,
15:52:16 mriedem but i'd think zero-impact-upgrade re perf would be something like strain on the network doing live migrations while upgrading compute hosts
15:52:56 mriedem but i'm not sure how nova would really have anything to do with that, it seems like a deployment topology decision
15:53:45 mriedem let's put that tag on openstack public clouds :)
15:54:46 mriedem onto another topic, sounds like cern would like to be able to pass user_data to rebuild...
15:55:05 mriedem sounds like they rely on rebuild pretty heavily
16:01:26 cfriesen does anyone know why AggregateImagePropertiesIsolation and AggregateInstanceExtraSpecsFilter behave differently? It's confusing...
16:11:09 bauzas cfriesen: the reason is "historical"
16:11:22 bauzas in other words, two efforts made by two teams
16:15:43 cfriesen bauzas: why am I not surprised. :)
16:16:23 bauzas the problem is that changing a filter behaviour is something tricky
16:17:00 bauzas I'd prefer providing a new filter that would do both image and flavor checks with the same behaviour, and in the meantime deprecate the old two filters
16:17:22 bauzas so we would be super clear that the behaviour is changing
16:17:40 bauzas keep those filters for a couple of releases, and then remove them from the tree
16:17:49 bauzas if people want to keep them out-of-tree, I'm fine
16:18:02 bauzas cfriesen: fancy proposing that ? :)

Earlier   Later