Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-09-29
14:04:18 bauzas lemme ask infra
14:04:20 gibi sure
14:04:21 dansmith hmm, I thought there was some way
14:04:31 gibi what I did before is that I exported the old state and copied that back
14:05:37 bauzas fungi is looking at restoring
14:05:41 gibi ack
14:05:43 bauzas folks, don't touch now
14:05:49 dansmith sweet
14:06:01 bauzas dansmith: thanks for having identified this
14:06:39 lyarwood ah ffs I think that was me
14:06:59 lyarwood I was editing and my dock crashed
14:07:12 lyarwood and then I couldn't reconnect to the pad
14:08:13 lyarwood yeah my items were the last on there
14:08:28 lyarwood https://etherpad.opendev.org/p/nova-yoga-ptg/timeslider#8272
14:09:07 lyarwood not entirely sure how my laptop dock (and thus network) crashing caused this tbh
14:09:58 gibi an interesting untested edge case in the etherpad code :)
14:13:08 fungi bauzas: gibi: dansmith: i've rolled it back to revision 8272
14:13:19 fungi lyarwood: ^
14:13:20 dansmith looks good, thanks fungi !
14:13:23 bauzas fungi: with all my love
14:13:36 fungi cool, just making sure it's looking like you needed
14:13:50 lyarwood thanks for that and apologies all
14:13:56 fungi we do also back up the db behind it daily, worst case
14:14:04 bauzas fungi: it is, all the colors
14:14:07 gibi fungi: awesome thanks
14:14:10 fungi no problem, glad we could recover it
14:14:28 bauzas and yeah, interesting edge case
14:14:47 bauzas a docking issue with a network problem swallows an etherpad
14:16:07 fungi those aren't so bad. in the past there have also been bugs which clients somehow tickled to make the pads completely unusable
14:16:46 fungi and the most we can do in those cases is dump an earlier text copy with the api and stick that into a new pad, but it loses all the attribution and history
14:17:40 fungi and formatting
14:18:55 bauzas fungi: thanks, gtk
14:19:23 bauzas gmann: i know you're busy with all those devstack and grenade stuff
14:19:50 bauzas gmann: but tell me when you think it would be a good opportunity for the x-p PTG session between oslo and nova re: policy
14:22:14 gmann bauzas: give me 10 min, currently internal meeting
14:22:19 bauzas gmann: nah, no rush
14:34:38 lyarwood https://review.opendev.org/c/openstack/nova/+/811118/ is passing with just the master grenade fix that's in the gate FWIW
14:35:40 gibi \o/
14:52:19 bauzas lyarwood: https://media.giphy.com/media/HTjcWZwMtHpyhuCGKZ/giphy-downsized-large.gif?cid=ecf05e47cwkexzrwaxwlkbicd2ppy22bb1l52sg7yoa8sk9x&rid=giphy-downsized-large.gif&ct=g
14:52:49 bauzas but that's lasting 0.1sec and then I say "meh"
14:53:58 fungi if you used a matrix client with the matrix-oftc bridge to join this channel, you and other matrix users could share inline media while irc users would just see a url to it in-channel
15:04:32 bauzas fungi: what I said, "meh" :p
15:05:24 fungi heh
15:05:30 gmann lyarwood: perfect then I will say it was late night thing which thought that Xena fix is needed :)
15:07:17 gmann bauzas: for PTG oslo sessions, is it possible on Tuesday Oct 19th between 13-15 UTC
15:14:18 opendevreview melanie witt proposed openstack/nova stable/train: Reject open redirection in the console proxy https://review.opendev.org/c/openstack/nova/+/791807
15:14:19 opendevreview melanie witt proposed openstack/nova stable/train: address open redirect with 3 forward slashes https://review.opendev.org/c/openstack/nova/+/806629
15:19:44 gmann bauzas: and as per current topic I need only 30 min unless there is more things to discuss from anyone else
15:20:34 bauzas gmann: sorry, I'm on a meeting but I guess we could run a meeting after 1400UTC as we have a cyborg x-p session first
15:22:10 gmann bauzas: on tuesday right?
15:22:35 bauzas gmann: on the 19th of October, yes
15:22:56 gmann bauzas: perfect, sounds good. thanks
15:23:10 bauzas https://etherpad.opendev.org/p/nova-yoga-ptg L47 tells me the 14-15:00UTC slot is already taken
15:24:12 gmann bauzas: that is 'Cyborg-Nova: Tuesday (19th Oct) 13:00 UTC - 14: 00 UTC:'
15:24:24 bauzas my bad, yeah
15:24:44 bauzas again, wfm for a oslo x-p session on Oct-19 14:00UTC
15:24:53 gmann +1, thanks again
15:24:58 lyarwood gmann: ^_^ no issues thanks for working on it so late
15:25:04 bauzas gmann: all good
15:25:36 gmann lyarwood: np!, and for stable backport we can wait for neutron team opinion so I agree on 'no hurry for those' .
15:25:45 lyarwood awesome
16:12:53 bauzas artom: honestly, I'm torn with https://review.opendev.org/c/openstack/nova/+/808474
16:13:00 bauzas that's an behavioural change
16:13:10 opendevreview Balazs Gibizer proposed openstack/nova master: Enable min pps tempest testing in nova-next https://review.opendev.org/c/openstack/nova/+/811748
16:13:18 bauzas operators suppose a plugoff when delete
16:13:38 bauzas now, we'll first try to shutdown the guest for every instance
16:13:46 bauzas including other drivers but libvirt
16:14:20 melwitt that is my concern as well. maybe it could be conditional on bfv that is not "delete on termination"?
16:15:18 melwitt is that the only case where this would be desired?
16:15:22 melwitt or rather, is there any gain in doing it for non bfv non delete on termination?
16:15:58 dansmith generally you don't want that :)
16:16:07 melwitt maybe also shared storage is another case
16:16:08 dansmith the only real case for non-bfv volumes is for precious data
16:16:53 melwitt but precious data on a local disk that's going to be deleted anyway? I must be missing something
16:17:15 dansmith sorry, thought you were talking about delete-on-termination for non-bfv cinder volumes
16:17:23 artom melwitt, "is there any gain in doing it for non bfv non delete on termination?" None that I can see
16:17:33 artom Well, no, any volume, really
16:17:41 artom Doesn't have to be bfv
16:17:50 melwitt oh, yeah attached volumes. I wasn't thinking of that. yeah
16:18:02 dansmith that's my point, delete-on-termination should only be useful for bfv volumes we created with non-precious data from an image
16:18:05 artom It's still attached and mounted in the guest, and would ideally be flushed correctly if it's not delete_on_termination=True
16:18:38 artom I need to run an errand quickly, can this be carried over to the gerrit review?
16:18:44 artom And thanks for looking into it :)
16:19:22 artom And yeah, so bauzas's point, the compute manager/driver division of labour here is pretty muddy
16:19:32 melwitt my bad for not looking at the change yet. if it's targeted to only instance with volume(s) cases I think that makes a lot more sense
16:19:38 gibi is it really a gracefull shutdown via openstack server stop and then a openstack server delete?
16:19:56 dansmith gibi: stop + delete should be graceful
16:20:20 gibi so my point is this can already done with our APIs
16:20:23 melwitt just saying I don't think we should be doing it for everything, for things where the data is going to be blown away anyway
16:21:01 dansmith gibi: for sure. I assume the goal is to make nova do the graceful behavior if volumes are attached, but to do it properly really requires some higher-level orch, like a stop...timeout...destroy kind of thing
16:21:24 dansmith "do the graceful behavior *automatically*" I should have said
16:21:36 gibi OK I see
16:21:49 melwitt yeah that is my understanding as well
16:22:10 dansmith I'm a bit torn, because unless you're running with unsafe cache, I would think that fast destroy is fine.. might have a journal to replay when you use the volume later, but...
16:22:11 gibi it make sense for data consistency but it also makes delete slower so I think this should be opt in
16:23:16 melwitt dansmith: yeah it's weird, the user is experiencing volume gets corrupted and no longer usable when they delete without stopping first
16:23:23 melwitt we had thought just deleting should be fine but it's behaving in a way we didn't expect
16:23:34 melwitt not sure why
16:23:37 dansmith destroy of a running vm is the same as pulling the plug.. if you're using a precious volume, you wouldn't do that to a physical server, so...
16:24:27 artom dansmith, so the "real" problem is https://bugzilla.redhat.com/show_bug.cgi?id=1965081

Earlier   Later