Wednesday, 2021-06-16

opendevreviewnorman shen proposed openstack/nova master: Saving security group to info_cache  https://review.opendev.org/c/openstack/nova/+/78634800:03
opendevreviewMerged openstack/nova master: libvirt: Set driver_iommu when attaching virtio devices to SEV instance  https://review.opendev.org/c/openstack/nova/+/79463900:53
opendevreviewmelanie witt proposed openstack/nova master: Add test coverage for API version headers in CORS  https://review.opendev.org/c/openstack/nova/+/79658002:19
opendevreviewmelanie witt proposed openstack/nova master: Add test coverage for API version headers in CORS  https://review.opendev.org/c/openstack/nova/+/79658002:19
kevinzHi lyarwood, would be really appreciated if you can help to review this for live migrate on Arm64: https://review.opendev.org/c/openstack/nova/+/763928, the patch has been updated06:17
opendevreviewBalazs Gibizer proposed openstack/os-resource-classes master: Add packet rate related resource classes  https://review.opendev.org/c/openstack/os-resource-classes/+/79659106:56
gibistephenfin: do you have an example how to backport db migrations with alembic?06:58
*** rpittau|afk is now known as rpittau07:15
opendevreviewBalazs Gibizer proposed openstack/placement master: Bump os-resource-classes deps to 1.0.0  https://review.opendev.org/c/openstack/placement/+/79659307:28
gibistephenfin, melwitt: it is a trivial bump to keep the modules in sync ^^07:31
opendevreviewBalazs Gibizer proposed openstack/placement master: Bump os-resource-classes requirements  https://review.opendev.org/c/openstack/placement/+/79659507:36
opendevreviewYongli He proposed openstack/nova master: smartnic support - reject server move and suspend  https://review.opendev.org/c/openstack/nova/+/77991307:45
opendevreviewYongli He proposed openstack/nova master: smartnic support - functional tests  https://review.opendev.org/c/openstack/nova/+/78014707:45
yonglihegibi, alex_xu had reviewed the smart nic patch set several rounds, and  about to review another round, just after i add more functional/unit test.07:47
gibiyonglihe: OK. I will try to look at the patches as promised on the meeting yesterday07:58
yonglihethanks.07:59
*** elodilles is now known as elodilles_afk08:10
opendevreviewliujiong proposed openstack/nova master: Do not create attachment for old root volume  https://review.opendev.org/c/openstack/nova/+/79595008:20
gibilyarwood: FYI limestone is now disabled https://review.opendev.org/c/openstack/project-config/+/796590 due to mirror issues. We only saw https://review.opendev.org/c/openstack/project-config/+/796590 from limestone so that issue hopefuly removed from the active gate faliures08:42
gibiI wanted to link to the bug https://bugs.launchpad.net/nova/+bug/193186408:43
opendevreviewLee Yarwood proposed openstack/nova stable/wallaby: libvirt: Set driver_iommu when attaching virtio devices to SEV instance  https://review.opendev.org/c/openstack/nova/+/79660708:44
stephenfingibi: alembic is a bit different. You don't need placeholders since the migrations don't have to be applied linearly. Each migration encodes its predecessor inline, so you could backport the new migration and simply rework the other migrations either side08:54
stephenfinI haven't spent a long time thinking about it though. We haven't backported a migration in 4 or 5 years now, iirc08:55
gibistephenfin: I got a pointer from slaweq how neutron did it supporting a downstream backport in https://review.opendev.org/c/openstack/neutron/+/601336/92/neutron/db/migration/alembic_migrations/versions/xena/expand/d863c3bdc0c5_add_active_allowed_address_pairs.py08:57
gibistephenfin: so they needed to prepare the patch on master to be conditional08:57
gibii.e. not to fail on if the change already applied08:57
gibiI have to run now but we can talk about it later08:58
stephenfinokay, no worries. We'll just have to document it, I suppose08:58
* stephenfin was planning to bug zzzeek if this ever actually came up :)08:58
opendevreviewStephen Finucane proposed openstack/nova master: db: Remove dead code  https://review.opendev.org/c/openstack/nova/+/78629109:12
opendevreviewStephen Finucane proposed openstack/nova master: db: Remove 'nova.db.sqlalchemy.utils'  https://review.opendev.org/c/openstack/nova/+/78629209:12
opendevreviewStephen Finucane proposed openstack/nova master: db: Remove unused DB methods  https://review.opendev.org/c/openstack/nova/+/78629309:12
opendevreviewStephen Finucane proposed openstack/nova master: db: Use module-level imports for sqlalchemy  https://review.opendev.org/c/openstack/nova/+/78629509:12
opendevreviewStephen Finucane proposed openstack/nova master: db: Fold in indexes  https://review.opendev.org/c/openstack/nova/+/78629609:12
opendevreviewStephen Finucane proposed openstack/nova master: db: Fold in ForeignKey constraints  https://review.opendev.org/c/openstack/nova/+/78629709:12
opendevreviewStephen Finucane proposed openstack/nova master: db: Remove 'nova.db.base' module  https://review.opendev.org/c/openstack/nova/+/78629809:13
opendevreviewStephen Finucane proposed openstack/nova master: db: Copy docs from 'nova.db.*' to 'nova.db.sqlalchemy.*'  https://review.opendev.org/c/openstack/nova/+/78629909:13
opendevreviewStephen Finucane proposed openstack/nova master: db: Synchronize function signatures  https://review.opendev.org/c/openstack/nova/+/78630009:13
opendevreviewStephen Finucane proposed openstack/nova master: db: Clean up migration code  https://review.opendev.org/c/openstack/nova/+/78630109:13
opendevreviewStephen Finucane proposed openstack/nova master: db: Use module-level imports for sqlalchemy (for real)  https://review.opendev.org/c/openstack/nova/+/79651909:13
opendevreviewLee Yarwood proposed openstack/nova stable/victoria: libvirt: Set driver_iommu when attaching virtio devices to SEV instance  https://review.opendev.org/c/openstack/nova/+/79661109:19
opendevreviewLee Yarwood proposed openstack/nova stable/ussuri: libvirt: Set driver_iommu when attaching virtio devices to SEV instance  https://review.opendev.org/c/openstack/nova/+/79661809:44
kashyapsean-k-mooney[m]: Hey, remind me again: do you think we can set a different display device based on guest's capabilities?  E.g. if the guest has a virtio-gpu driver, use "virtio-vga" and so on09:49
stephenfinlyarwood, gibi: bauzas is out for all of this week, right? Could I ask you to work through that DB series before it goes into merge conflict again. It's very trivial, if that helps (mostly moving things around in prep for alembic)10:06
bauzasno, I'm here 10:06
alex_xugibi: I reviewed few around on first three patches, since the major logic on the the thrid one. 10:07
bauzasI was just having a conflict for the upstream meeting10:07
stephenfinbauzas: oh, sorry /o\ in that case, I might ask you to take a look also, if you can :)10:07
bauzasstephenfin: yup, I can do it10:07
stephenfingreat, ty10:08
* bauzas will have some PTOs in July, that's it ;)10:08
stephenfinelodilles_afk: lyarwood: melwitt: Now that we have the cherry-pick check to prevent us backporting a change out-of-order, would it make sense to start approving a whole series of backports at once and relying on said check to prevent out-of-order merges?10:10
*** bhagyashris_ is now known as bhagyashris10:27
lyarwoodstephenfin: sorry was on a call, happy to help with the DB series. We can but until the parent branch changes have landed the SHAs can still change but I guess that's the case either way. I'd be happy justifying +W'ing something if the parent is already W'd tbh.10:29
stephenfindoesn't the cherry-pick script take care of that?10:29
stephenfinthe SHAs10:29
lyarwoodYeah checking them, it doesn't automatically update anything10:29
lyarwoodI was agreeing that we may as well ACK things all the way down and rely on the script10:30
stephenfinah, okay, yeah, that's my thinking10:30
bauzasin general, we prefer to hold stable changes until master merges10:30
bauzasas indeed SHA1s can change 10:30
lyarwoodright stephenfin's point is after that on stable10:30
stephenfinoh, I'm not arguing for approving before master is merged10:30
lyarwoodinstead of waiting for each branch to merge10:30
stephenfinwe should definitely wait for that10:30
lyarwoodthere is a potential race at that point stephenfin 10:31
lyarwoodthe older branches having less CI10:31
bauzasstephenfin: sorry if i misunderstood, your concern is about a series ?10:31
lyarwoodwill fail first 10:31
lyarwoodbecause the newer branches haven't merged the required change10:31
stephenfinbauzas: I'm suggesting if you have a patch backported from stable/wallaby to stable/train, we can approve all of them at once and rely on the pep8 job to ensure they go in in the correct order10:32
opendevreviewSylvain Bauza proposed openstack/nova-specs master: Add generic mdevs to Nova  https://review.opendev.org/c/openstack/nova-specs/+/79279610:32
lyarwoodI'm fine with it, it's just going to take a few rechecks still 10:32
bauzasstephenfin: ah that10:33
stephenfinah yeah, there's going to be a recheck anyway10:33
lyarwoodwhat's life without 20 rechecks10:33
stephenfinsince the pep8 job will fail on everything older than stable/wallaby10:33
lyarwoodyup10:33
bauzaswell, in general, I'm holding approvals until the original branch merges10:33
stephenfinbut it's easy to recheck one by one10:33
bauzasas they can be races10:33
bauzasthere*10:33
stephenfincertainly easier than asking stable cores every few days to review the latest stable branch10:34
stephenfinbauzas: again, no issues holding off on approving (or even reviewing) backports until the master change has landed10:34
stephenfinbut the pep8 job means that e.g. a stable/train change simply can't land before the stable/ussuri one now10:35
stephenfineven if +Wd10:35
bauzasoh, I see your point10:35
bauzaswell, then sure10:35
stephenfinI just want to avoid having to continuously poll stable cores as each stable branch lands, particularly since I'm typically going back to Train (so that's four instances of polling, at a minimum :))10:36
lyarwoodthe only issue I have personally is that it breaks my review dashboards10:36
lyarwoodas they rely on reviews being +1'd10:37
lyarwoodbut I guess someone is asking us to review a given topic here making it easier10:37
lyarwoodand/or change-id10:37
stephenfinyeah, I'd like it if we could use something other than the verified label for this10:38
stephenfinlike a Parent-Merged label, without which zuul wouldn't merge the patch (so like Verified in that way). I don't know how hard that is though. I don't know if a zuul job can set a label other than verified10:39
stephenfinhowever, as things stand, the dashboard is already broken so nothing has changed, right lyarwood?10:40
stephenfinbecause of the pep8 fail10:40
lyarwoodyeah correct things are hidden10:41
lyarwoodtinyurl.com/f9y6vr6d for example10:41
lyarwoodtbh I could just change them to drop the +1 requirement10:42
lyarwoodbut then it gets a little mad10:42
stephenfinI can imagine10:42
lyarwoodI still use https://review.opendev.org/q/project:openstack/nova+branch:%5Estable/.*+status:open from time to time to check everything10:43
* stephenfin tries to figure out what causes zuul to set the Verified label as opposed to something else10:43
stephenfinoh, zuul itself10:44
stephenfinhttps://opendev.org/zuul/zuul/src/branch/master/doc/source/examples/pipelines/gerrit-reference-pipelines.yaml10:44
stephenfinso we'd need a new pipeline10:44
lyarwoodit would be nice to have something else the script could set tbh10:44
stephenfinthe other option is to have a separate "CI" running that particular job, so you could filter on that instead10:45
stephenfini.e. -1 by $PEP8_CI10:46
stephenfinagain, no idea how difficult that is. I suspect that name is global to the deployment10:46
stephenfinoh, we could just move it to a separate job in the gate queue?10:48
stephenfininstead of the check queue10:48
lyarwoodyeah I'm cool with that10:51
lyarwoodwell it would have to be non-voting, slightly defeating the purpose of the script10:51
stephenfinwould it? The check job would now report +1 but the gate job would -2 if the parent wasn't merged10:52
lyarwoodAh sorry I see what you're suggesting now10:53
lyarwoodOkay yeah that could work well in that case10:53
opendevreviewStephen Finucane proposed openstack/nova master: Move 'check-cherry-picks' test to gate  https://review.opendev.org/c/openstack/nova/+/79662611:04
stephenfinlyarwood: ^11:04
sean-k-mooneykashyap: no we cant know the guest capablites in advance11:05
kashyapsean-k-mooney: Hmm, okay; I have a couple more questions.  But I'm on a call, will come back to them in a bit.11:06
sean-k-mooneykashyap: the closest thing w have to that is libosinfo but that is not a greate approch in my view11:06
sean-k-mooneyack11:06
kashyapRight; 'libosinfo' was what I was thinking; why isn't it feasible?  Do outline your thoughts here; will come back and read11:07
sean-k-mooneywe have libosinfo "support"  today but its not machine type aware and it does not know if you have the driver avaiable11:09
sean-k-mooneythey also can change the hardware modeles over time which has broken us in the past11:09
sean-k-mooneyand it currently missues the image propety fields11:09
sean-k-mooneyit forches you to put the version in the os name field ignoring the os_version field11:10
sean-k-mooneyso have to do os_name rhel8 not os_name rhel os_version 811:10
sean-k-mooneyso it breaks the standard usage of that attribute11:10
sean-k-mooneythe lib osinfo devs assume that the xml will be persisted so its ok for them to break compatiablity and change the resules in later versions11:11
sean-k-mooneythat is not how openstack works11:11
sean-k-mooneylibosinfo also has no awareness of the libvirt verison installed on the system as far as i am aware so it does not know if the models are supported by the libvirt/qemu installed11:12
lyarwoodstephenfin: LGTM11:12
sean-k-mooneythis is why i recommend that no one ever use this feature and why i have suggested removing it in the past11:12
lyarwoodstephenfin: wait, the `deps =` line in the tox env isn't a mistake is it?11:14
* lyarwood can't recall if that's just ignored11:15
sean-k-mooneylyarwood: i belive that ill install no deps11:16
sean-k-mooneywhich in this case is fine11:16
sean-k-mooneywe just need bash11:16
lyarwoodyeah wasn't sure if tox would bork at it tis all11:17
sean-k-mooneywell the ci will tell us11:17
sean-k-mooneylyarwood: stephenfin  why are we doing this by the way11:18
sean-k-mooneyi agree we can do this but i dont expect this to really save much time in the gate11:18
lyarwoodsean-k-mooney: it should save at least one check run per backport11:19
lyarwoodsean-k-mooney: but really this is more about allowing stable cores to see acceptable backports earlier11:19
lyarwoodsean-k-mooney: so instead of them getting -1'd by the cherry pick script they just get held by the gate11:19
sean-k-mooneyya so reading the commit message im not sure i buy that11:19
sean-k-mooneybut the 1 recheck i guess makes sense11:20
sean-k-mooneyalthoguh we are loosing one thing that would be nice to keep11:20
sean-k-mooneywhich is check that backports to stable acutlly are a backport or have stable only11:20
lyarwoodwe still get that, it's just in the gate now11:20
sean-k-mooneyyep which is too late11:21
lyarwoodtbh we could make this non voting in the check queue11:21
sean-k-mooneyit should tell author that are unfamilar with our policy in check11:21
sean-k-mooneythis new job11:21
sean-k-mooneythat would work for me11:21
lyarwoodyeah11:21
lyarwoodstephenfin: ^ is that okay?11:21
sean-k-mooneyit lest you know if it will fail but no need to recheck it11:21
admin1where is the live_migration_downtime   defined ? 11:59
admin1is it on kvm or in nova ? 11:59
sean-k-mooneyadmin1: nova has options that we pass to libvirt which then modulates the qemu downtime12:01
sean-k-mooneyadmin1: https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_downtime12:01
sean-k-mooneyadmin1: nova is not direcly involved in managing the vm during the livemigration12:01
sean-k-mooneywe invoke libvirt wiht a set of parmaters and then wait for ti to complete12:02
sean-k-mooneymelwitt: i think this is all you need to fix in the backports for bionic by the way https://review.opendev.org/c/openstack/nova/+/795433/1/roles/run-evacuate-hook/tasks/main.yaml#4412:04
sean-k-mooneywell and lines 67-6912:05
sean-k-mooneythe version of libvirt in bionic does not support socket activation so we just need to remove the socket lines12:05
admin1sean-k-mooney, so i just need to add those lines in nova.conf, restart the compute service ( systemctl ) and thats it ? 12:11
admin1are those lines only needed in the actual compute nodes, or in the whole cluster  ( nova scheduler, api etc ) ? 12:11
sean-k-mooneythey are used on the source compute i think12:12
sean-k-mooneyso all the comptues that you want to tune12:12
admin1do they go under libvirt or under default ? 12:12
sean-k-mooneybut i do not think they are used by any other services12:13
sean-k-mooneythey are in the libvirt section12:13
admin1libvirt. ( dot ) means its under libvirt i guess12:13
sean-k-mooneyyes12:13
sean-k-mooneyit does12:13
sean-k-mooneyso update the configs on the computes restart compute services and it will take effect12:13
admin1does these value make sense:   live_migration_downtime: 5000  # ( default 500) && live_migration_downtime_steps: 20  # default (10)       && live_migration_completion_timeout: 8000    # (default 800) 12:20
admin1don't want to corrupt the  instance , ram etc 12:21
opendevreviewLee Yarwood proposed openstack/nova stable/train: libvirt: Set driver_iommu when attaching virtio devices to SEV instance  https://review.opendev.org/c/openstack/nova/+/79664212:28
*** elodilles_afk is now known as elodilles13:04
opendevreviewStephen Finucane proposed openstack/nova stable/train: Reproduce bug 1897528  https://review.opendev.org/c/openstack/nova/+/79211613:13
opendevreviewStephen Finucane proposed openstack/nova stable/train: Ignore PCI devices with 32bit domain  https://review.opendev.org/c/openstack/nova/+/79211713:13
ozzzoThe topic in this channel is a bit unfriendly, and gives bad advice. Nobody is answering questions in #openstack, and this is the correct place to ask Nova questions. Can we change the topic?13:40
opendevreviewLee Yarwood proposed openstack/nova master: Add check job for FIPS  https://review.opendev.org/c/openstack/nova/+/79051914:08
sean-k-mooneyozzzo: the topic is intentional14:21
ozzzoi don't doubt that, but it is still bad advice14:21
sean-k-mooneyin the past we have had some user be quite unresonable and demand support form upstream for there sepcific thing14:21
lyarwoodstephenfin / gibi ; https://review.opendev.org/c/openstack/nova/+/796523 easy review if you have time14:21
sean-k-mooneyozzzo: #openstack is inteded to be for general quetions14:22
ozzzoit's true that there are idiots on irc, but asking questions in #openstack is a waste of time because nobody who knows any answers is watching there14:22
sean-k-mooneybut ill admign i dont tend to have it open14:22
ozzzoI try to help out sometimes but I don't know much14:22
sean-k-mooneyi do not monitor it i used to have it open by default but i only responded if i was pingged 14:22
sean-k-mooneyi shoudl set back up my default chanlles list after the mvoe14:23
sean-k-mooneyozzzo: did you have a question by the way14:23
sean-k-mooneyozzzo: we proably could just remove for support bit14:23
ozzzoI don't, but the other day someone was fruitlessly asking questions in #openstack, and I sent him here, but the message scared him off14:23
sean-k-mooneyand just not this is for development mainly14:24
ozzzo*nova questions14:24
opendevreviewLee Yarwood proposed openstack/nova master: tests: Allow bindep and test-setup.sh to run successfully on RHEL  https://review.opendev.org/c/openstack/nova/+/79642814:25
sean-k-mooneyits hard to express what type of questions are ok here in a way that is aprochable to new commer but also provides a safty net for peopel to fall back on when peopel are lookign for upstream to provide support for free14:25
sean-k-mooneyyou know that most of use are happy to help, at least to a point14:26
opendevreviewLee Yarwood proposed openstack/nova master: DNM - Test bindep and test-setup.sh changes against centos8  https://review.opendev.org/c/openstack/nova/+/79668414:31
lyarwoodstephenfin: ^ 14:32
gansolyarwood, melwitt: thanks for the +2+W on the wallaby one! if you could please take a look at the victoria backport now when you have a minute: https://review.opendev.org/c/openstack/nova/+/79554214:43
gansobauzas also as reviewed the original patch ^14:43
gansothanks in advance14:43
bauzasganso: ack, opening a new tab14:44
opendevreviewStephen Finucane proposed openstack/nova master: Move 'check-cherry-picks' test to gate, n-v check  https://review.opendev.org/c/openstack/nova/+/79662614:52
stephenfinlyarwood: sean-k-mooney: ^14:53
lyarwoodstephenfin: awesome thanks14:54
sean-k-mooneylooks good to me14:56
sean-k-mooneywe had the env varable beforefore for downstream?14:56
sean-k-mooneyor was it there for another reason14:56
sean-k-mooneyhaving it be a different tox enve removes the need for it but just wondering14:57
lyarwooddownstream14:57
sean-k-mooneyack, thats what i tought but was not sure14:58
lyarwoodbut I never got around to replacing the original hackaround with it14:58
lyarwoodthe original being to truncate the file14:58
lyarwood\o/14:58
opendevreviewMerged openstack/nova master: tests: Merge flavor tests  https://review.opendev.org/c/openstack/nova/+/78366215:07
opendevreviewMerged openstack/nova master: tests: Remove useless mocks  https://review.opendev.org/c/openstack/nova/+/77873015:08
admin1if vms ( backed up by ceph) fail to live migrate, is a pause + migrate enough .. or they need to be shutdown and then migrated ? 15:10
admin1i used this setting:    live_migration_downtime: 10000 ; live_migration_downtime_steps: 20 ; live_migration_downtime_delay: 100 ;    live_migration_completion_timeout: 1500015:11
admin1which helped 8 stuck instances to migrate .. 2 fail to migrate no matter what15:11
opendevreviewLee Yarwood proposed openstack/nova master: tests: Allow bindep and test-setup.sh to run on EL distros  https://review.opendev.org/c/openstack/nova/+/79642815:41
opendevreviewLee Yarwood proposed openstack/nova master: DNM - Test bindep and test-setup.sh changes against centos8  https://review.opendev.org/c/openstack/nova/+/79668415:41
opendevreviewMerged openstack/nova master: Allow X-OpenStack-Nova-API-Version header in CORS  https://review.opendev.org/c/openstack/nova/+/79631915:49
opendevreviewMerged openstack/nova master: tests: Remove duplicate policy tests  https://review.opendev.org/c/openstack/nova/+/77873115:49
melwittganso: ack will do15:50
sean-k-mooneyadmin1: you can jsut do a cloud migrate15:51
sean-k-mooneyno need to pause15:51
melwittsean-k-mooney: ack thanks for the hint15:52
sean-k-mooneyor you can do a live migrate with a force complete call15:52
sean-k-mooneyforce-complete will pause the vm15:52
admin1oh .. ok15:52
admin1openstack server migrate  --help .. there is no such parameter ( force-complete) 15:53
sean-k-mooneyhttps://docs.openstack.org/api-ref/compute/?expanded=force-migration-complete-action-force-complete-action-detail#force-migration-complete-action-force-complete-action15:54
sean-k-mooney"openstack server migration force complete" is the comand15:55
sean-k-mooneysean@p50:~$ openstack help server migration force complete15:55
sean-k-mooneyusage: openstack server migration force complete [-h] <server> <migration>15:55
sean-k-mooneyForce an ongoing live migration to complete. This command requires ``--os-compute-api-version`` 2.22 or greater.15:55
sean-k-mooneypositional arguments:15:56
sean-k-mooney  <server>     Server (name or ID)15:56
sean-k-mooney  <migration>  Migration (ID)15:56
sean-k-mooneyso basically you have to start the live migration15:56
sean-k-mooneythen you can get the migration id and then force the completeion of the live migation15:56
sean-k-mooneymelwitt: sorry dont rememebr the context of that but if the hint? helpped im glad15:57
sean-k-mooneyoh15:57
sean-k-mooneymelwitt: the socket activation?15:58
melwittsean-k-mooney: haha yeah the fixing for bionic thing15:58
melwittstephenfin, lyarwood, bauzas: I'm meh about approving older branches before the newer one merges, I don't think it solves the ping problem. in my case it's just I don't always remember to review all the older versions and I don't often like to do them all at the same time anyway16:00
stephenfinI figured it would solve the ping problem, or at least significantly reduce it16:01
stephenfinin theory, if all branches were approved, one could get them merged by a simple recheck16:01
opendevreviewStephen Finucane proposed openstack/nova master: tests: Speed up 'servers' API tests  https://review.opendev.org/c/openstack/nova/+/77873216:05
melwittyeah. I guess one potential thing that could happen is if the author/rechecker doesn't realize they can't merge out of order and they go on a recheck loop in the wrong order. I have seen that before anyway but I'd imagine it's more tempting when you see the shiny +W on there16:05
admin1sean-k-mooneythanks .. it worked 16:10
*** rpittau is now known as rpittau|afk16:11
opendevreviewMerged openstack/nova master: Retry lvm volume and volume group query  https://review.opendev.org/c/openstack/nova/+/79626916:22
opendevreviewStephen Finucane proposed openstack/nova stable/wallaby: Retry lvm volume and volume group query  https://review.opendev.org/c/openstack/nova/+/79670716:31
stephenfinle sigh https://storyboard.openstack.org/#!/story/200854916:59
stephenfin"I set the state of my shelved offloaded instance to active and it broke things"17:00
lyarwoodlol17:01
melwittlol17:01
melwittwe need a required option on set state like --I-acknowledge-this-might-break-something17:02
* melwitt loves the --yes-i-really-mean-it option in ceph17:02
lyarwood-i-really-know-what-im-doing-and-if-this-breaks-anything-i-am-to-blame17:03
melwitt😂 yeah the longer the option, the better17:03
melwittrealistically, we should put a big fat warning in the set state help that says something similar. if there already is one, then ... :|17:05
lyarwoodI think there might be in the api-ref but yeah osc could say more17:06
stephenfinmelwitt: lyarwood: 9670717:12
stephenfin<stephenfin> le sigh https://storyboard.openstack.org/#!/story/200854917:12
stephenfin<stephenfin> "I set the state of my shelved offloaded instance to active and it broke things"17:12
stephenfin* derekh has quit (Quit: Leaving)17:12
stephenfinwhoops17:12
stephenfinlyarwood: melwitt: https://review.opendev.org/c/openstack/python-openstackclient/+/79671317:12
stephenfin(HexChat copies whatever you highlight to the clipboard)17:12
melwittsweet17:15
lyarwoodstephenfin: that could've been so much worse ^_^17:20
opendevreviewMerged openstack/nova stable/victoria: Error anti-affinity violation on migrations  https://review.opendev.org/c/openstack/nova/+/79554217:30
opendevreviewMerged openstack/placement master: Bump os-resource-classes deps to 1.0.0  https://review.opendev.org/c/openstack/placement/+/79659317:31
sean-k-mooneyadmin1: useing force complete cool17:39
sean-k-mooneyadmin1: that makes it a semi live migration17:40
sean-k-mooneythe vm does not restart or anythng but it proably will notice its clock is wrong and or drop packets17:40
sean-k-mooneyso normally we avoid that but its good to know its an option when you really need to move soemthing and is still friendlier then a cold migrate17:41
sean-k-mooneywhy is that in story board17:41
sean-k-mooneyand ya we had a downstream issue to the same effect recently17:42
sean-k-mooneymelwitt: i wonder if we should actully consier blocking that in the api17:42
sean-k-mooneyits never valide to reset state form shelve offloaded to any other state then error17:43
sean-k-mooneylyarwood: stephenfin melwitt  by the way we still have a todo item somehwer to extend the reset state api to allow more states and to allow settign the task_state too17:45
sean-k-mooneyif we do that we should harden the allowed state transations IMO17:46
melwittsean-k-mooney: yeah... conflicted about that because reset state is kind of a wild west api call to make but on the other hand if we can block something that's guaranteed to be invalid, that makes sense too17:46
sean-k-mooneye.g. ERROR we woudl allow to go to any sate as an escape hatch. but any none ERROR state should not be changable arbitrailly17:46
sean-k-mooneymelwitt: im pretty sure it can result in data lose17:47
sean-k-mooneyif you do resetstat form shelve offloaded and then do either hard reboot or a migration i cant rememebr which17:48
melwitt?17:48
sean-k-mooneywe had a customer do that with ceph recently17:48
sean-k-mooneyand they lost the snapshot17:48
melwittI guess I'm not realizing how that happens. if it's shelved offloaded there's no guest to reboot17:49
*** ricolin_ is now known as ricolin17:49
sean-k-mooneyyes so if i rememebr correctly unshleve failed so the reset state then hard rebooted17:49
sean-k-mooneythat failed because no host 17:50
sean-k-mooneythe then reset state again and tired to shleve i think? this is where my memory is blank17:50
sean-k-mooneywhen we got the bz they had tried some cobination of that several times17:51
sean-k-mooneyand the rbd volume was nolonger preset for the vm root disk17:51
melwittah ok, so you're saying if we prevent that path from even starting, it can avoid whatever future thing they managed to do to lose the data17:52
sean-k-mooneyyes17:52
melwittyeah ok17:52
opendevreviewRodrigo Barbieri proposed openstack/nova stable/ussuri: Error anti-affinity violation on migrations  https://review.opendev.org/c/openstack/nova/+/79671917:58

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!