Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-03-11
20:38:08 fungi the author of that post is privately random e-mailing osf staff now trying to find out who has experience with it
20:42:46 melwitt fungi: maybe try KeithMnemonic
20:42:57 fungi thanks melwitt!
20:43:56 fungi granted they started out e-mailing the contact address for the openstack website, until several of us suggested they reach out to the openstack-discuss ml
20:44:05 fungi so i'm not sure i'd wish this on anyone
20:44:33 sean-k-mooney fungi well we did spend like 30 mins disucssing should we deprecated teh driver eailer
20:44:50 fungi that sounds like legitimate details to me ;)
20:45:28 sean-k-mooney http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-03-11.log.html#t2020-03-11T14:16:55
20:46:03 sean-k-mooney fungi: the issue is the vmware ci has not been running/passing for months and we dont actully know if it still works
20:46:14 melwitt yeah, I could see deprecating it. we deprecated the xen driver last year I think
20:46:23 sean-k-mooney fungi: we think it does but there is no one active that works on it
20:47:09 sean-k-mooney looking at https://wiki.openstack.org/wiki/ThirdPartySystems/VMware_CI
20:47:58 sean-k-mooney Salvatore Orlando and Sihan Wang were the main contacts
20:48:23 fungi yeah, i haven't seen either of then in irc in ages
20:48:30 sean-k-mooney but i dont think salv-orlando has been active for like 2+ years
20:48:39 fungi right, that matches my recollection
20:48:54 melwitt I have seen gkotton relatively recently I feel like ... on gerrit
20:51:23 melwitt and like https://review.opendev.org/#/q/project:openstack/oslo.vmware that's the only hints I see that there are people working on it
20:58:24 fungi thanks, passing all that along
21:00:50 dansmith fungi: glad to know that foundation staff are getting hounded
21:01:15 fungi we're usually the first folks who get contacted by users who don't know where to find contact information
21:01:16 mriedem gary left vmware
21:01:17 mriedem awhile back
21:01:18 mriedem fyi
21:01:29 dansmith fungi: not because I'm glad you're feeling the pain, but glad that it forms some justification that vmware isn't around to support it being in upstream
21:01:48 dansmith fungi: after that email went 5 days with no response I posted the deprecation patch
21:01:49 fungi in theory this is what a user committee is for, but...
21:01:57 dansmith fungi: which lo and behold had people out of the woodwork
21:02:18 fungi nobody out of the woodwork enough to answer the e-mail though
21:02:28 dansmith right
21:02:40 dansmith just out of the woodwork to beg to keep it in tree for marketing reasons (my embellishment)
21:02:44 fungi i just feel bad about it in part because i suggested they contact openstack-discuss
21:03:27 dansmith in this case, that's the right thing to do, they're trying to get upstream nova to work with upstream devstack
21:03:37 fungi yep
21:03:40 dansmith we can't really help them though, because we have no idea if it's even supposed to work
21:03:48 dansmith CI hasn't voted in ages, and last it did, it reported error
21:03:54 fungi oh, i totally agree
21:03:59 sean-k-mooney i could reply and ask them to provide the n-cpu log because there initall email was just "devstack failed because n-cpu did not start"
21:04:17 fungi more just sad that there are users who have been effectively abandoned by the folks who were maintaining the driver
21:04:33 sean-k-mooney but honestly i know almost nothing baout vmware so unless its a really really dumb error i wont be able to help
21:05:00 fungi sean-k-mooney: right, it's entirely possible the issue they're running into isn't even vmware-specific, but mentioning vmware in any question is a quick way to turn off most people's brains
21:05:30 dansmith well, I think it's more likely that one of the many virt-related changes lately have caused that driver to not even be able to report resources properly
21:05:32 mriedem sean-k-mooney: i need you for some other hardware acceleration related wild goose chases actually
21:05:39 sean-k-mooney well i did look at the main but it was just teh error you get whenever the compute service is not started properly
21:06:34 dansmith IMHO, the overstretched nova team doesn't need to be spending any time trying to maintain (and help users) for a driver we can't even test
21:06:38 sean-k-mooney mriedem: haha if someone offeres you enginering samples of hardware and will pay you to look at it run
21:06:42 dansmith we should be communicating clearly that we expect it's broken
21:06:49 sean-k-mooney pre alpha hardware sucks
21:07:10 dansmith fungi: feel free to comment: https://review.opendev.org/#/c/712101/
21:07:24 dansmith fungi: even if "even I was asked for help because clearly there's no resources for users"
21:08:01 fungi i'm trying to find nice ways to more or less say that in my reply to the private e-mail this user has sent me, without putting words in anyone's mouths and instead just linking to the currently available public resources
21:08:30 sean-k-mooney fungi: you could link to the irc logs of this conversation
21:08:32 dansmith fungi: link them to the patch saying "It looks like you shouldn't expect this to work, sorry, we're working on getting the messaging out... $link"
21:09:30 fungi dansmith: sean-k-mooney: yes, both of those things, thanks!
21:16:04 fungi though since xuel@vmware.com has volunteered in https://review.opendev.org/712101 to receive requests for assistance, i'll mention that in my reply
21:26:49 melwitt mriedem: ack, thanks didn't know that
21:28:20 melwitt hoo dang devstack worked the first time. yesss
21:29:23 sean-k-mooney melwitt: that normally works for me if i am using a clean vm and i have done an os update and rebooted first
21:29:36 melwitt *devstack with ceph plugin
21:29:42 sean-k-mooney ah
21:29:47 melwitt I had a hell of a time last time. this time all smooth
21:30:17 melwitt cause if it fails in the middle for any reason, restarting it didn't seem to work. just keeps tripping over itself
21:30:31 melwitt restarting meaning run ./stack.sh again
21:30:54 sean-k-mooney did you run clean.sh or unstack before runing stack again
21:31:05 melwitt I didn't
21:31:20 sean-k-mooney ya thats proably your issue
21:31:53 melwitt do those still work ok? that was why I hesitated, didn't want to make it worse. but, I ended up having to start all over from scratch anyway so I should have tried it
21:32:19 sean-k-mooney unstack works fine. clean more or less works fine but ocationally it misses files
21:32:31 melwitt ok, good to know
21:32:39 sean-k-mooney unstack is much safer to run
21:32:42 sean-k-mooney then clean
21:32:44 dansmith yeah I try to fix bugs in ./clean.sh when I find them
21:32:46 dansmith like in cyborg lately
21:33:41 sean-k-mooney if you just run stack twice you can get into weird race condition where agents are running but you recrate the db and things break
21:40:24 sean-k-mooney actully speaking of cyborg i should rebase my patch for there devstack plugin
#openstack-nova - 2020-03-12
00:44:20 brinzhang gmann: I already granular os-instance-actions GET API, you can review https://review.opendev.org/#/c/711791/3
01:29:18 gmann brinzhang: we need to add in same patch when adding the new defaults.
01:30:27 gmann like this -https://review.opendev.org/#/c/706672/7/nova/policies/attach_interfaces.py
01:31:09 brinzhang gmann: I was already separate, and the granular beased on this patch, does need I rollback?
01:32:50 brinzhang gmann: split it from the base patch, I think it's clear to me to know what happened
01:33:27 gmann brinzhang: yeah it will be easy for otherwise we endup doing half things per patches. also if you do in single patch we can see tests better way about what behavior is changed
01:34:40 brinzhang gmann: ok, I can combine them.
01:36:12 gmann thanks. because it end up changing the policy twice. first in default role patch and then again changing in new patch./
01:38:20 brinzhang gmann: about you comments of https://review.opendev.org/#/c/706470/10/nova/tests/unit/cmd/test_policy.py
01:38:53 brinzhang I think I should keep my changes, otherwise the policy seem cannot access request
01:42:18 gmann I do not think it will make any difference if so then something wrong which we need to debug
01:42:38 brinzhang gmann: ok, let me try
01:42:39 gmann because old rules should keep working as it is.
03:36:06 openstackgerrit Kevin Zhao proposed openstack/nova master: fix scsi disk unit number of the attaching volume when cdrom bus is scsi https://review.opendev.org/712607
04:24:57 openstackgerrit Brin Zhang proposed openstack/nova master: Add new default roles in os-instance-actions policies https://review.opendev.org/706470
04:40:06 openstackgerrit Brin Zhang proposed openstack/nova master: Add new default roles in os-instance-actions policies https://review.opendev.org/706470
04:46:13 brinzhang gmann: I was merged these patches, and leave comments in that failed case, would please review this after you online https://review.opendev.org/706470
05:57:51 openstackgerrit Kevin Zhao proposed openstack/nova master: fix scsi disk unit number of the attaching volume when cdrom bus is scsi https://review.opendev.org/712607
07:08:31 dSrinivas Hi All, i am getting this error http://paste.openstack.org/show/790571/ from March 3 in nova-compute logs in our CI FC HBA's are Online and Connectivity exists between vm and Storage
08:07:08 openstackgerrit Merged openstack/nova stable/queens: Add retry_on_deadlock to migration_update DB API https://review.opendev.org/712212
08:28:37 gibi morning
09:25:24 lyarwood https://review.opendev.org/#/q/status:open+topic:bug/1861071 - I'd appreciate reviews of this bugfix series from any non-RH cores with bandwidth if possible, there's a followup series on top of this as well as I'd like to backport this.
09:26:16 gibi lyarwood: ack, added to my growing review queue
09:27:42 lyarwood gibi: awesome thanks :) anything I can help with in return please let me know
09:28:52 gibi lyarwood: sure. I have two patch series to be backported furter, as soon I as I did the backport I will ping you

Earlier   Later