Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-09-04
08:02:26 bauzas brinzhang0: you want to know what was merged as a bugfix in the Ussuri cycle ?
08:02:36 brinzhang0 bauzas: yes
08:03:08 noonedeadpunk bauzas: sounds like I was dreaming:)
08:03:08 brinzhang0 I want to know which and how many bugs we fixed in Ussuri
08:03:45 brinzhang0 bauzas: I tried in launchpad by some way, but I can't get what I want :(
08:03:52 bauzas brinzhang0: you can't really see them by using Launchpad
08:04:08 bauzas .has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search&orderby=-datecreated&start=0
08:04:08 bauzas brinzhang0: you can look at all the closed bugs by https://bugs.launchpad.net/nova/?field.searchtext=&field.status%3Alist=FIXRELEASED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field
08:04:15 bauzas oh sec
08:04:55 bauzas brinzhang0: but maybe the better is just to use a gerrit query
08:05:38 bauzas brinzhang0: shorturl.at/cdCEQ
08:05:48 bauzas http://shorturl.at/cdCEQ
08:06:14 bauzas but like I said, a Gerrit query is better
08:06:31 brinzhang0 bauzas: I using https://bugs.launchpad.net/nova/+bugs?advanced=1 to filter, but nothing can get
08:07:23 bauzas brinzhang0: lemme provide you the Gerrit query
08:07:30 bauzas it's simple
08:07:38 brinzhang0 ack
08:26:45 bauzas brinzhang0: actually, this isn't as simple as I thought originally, you need to be a bit smart
08:27:18 bauzas there is a gerrit query for getting all bugs merged for all the releases : "is:merged project:openstack/nova message:"-Bug: #" branch:master"
08:27:31 bauzas https://review.opendev.org/#/q/is:merged+project:openstack/nova+message:%22-Bug:+%2523%22+branch:master,100
08:27:47 bauzas this will give you all the bugfixes that aren't cherry-picks
08:28:04 bauzas but then you need to limit the query to only get the stable/ussuri patches
08:28:08 brinzhang0 yeah, this way we just can get all bug fixes
08:28:26 bauzas unfortunately, gerrit isn't updating its search metadata when we branch
08:28:31 bauzas only the gerrit UI
08:28:35 brinzhang0 but it cannot seperate which bug is belongs to ussuri
08:28:44 bauzas so we can't ask for branch:stable/ussuri
08:28:49 bauzas and we can't ask for tags
08:29:07 brinzhang0 yes
08:29:24 bauzas but there are query arguments like before:'TIME'/until:'TIME' and after:'TIME'/until:'TIME'
08:29:26 bauzas this would work
08:29:38 bauzas whoops after:'TIME'/since:'TIME'
08:30:09 bauzas just verify the times using the above query and then provide the needed times
08:30:20 brinzhang0 like before:'TIME'/until:'TIME' and after:'TIME'/until:'TIME'
08:30:25 brinzhang0 you mean use gerrit?
08:31:41 brinzhang0 in launchpad, why the "Advanced search"（https://bugs.launchpad.net/nova/+bugs?advanced=1） is invalid?
09:02:16 gibi brinzhang0, bauzas: I would tackel that problem by seaching through git log between the train brancing point and ussuri branching point and grepping the Closes-Bug tag in the commit message
09:04:29 brinzhang0 gibi: the tag of closes-bug just show that patch is a bugfix, it also cannot which is belongs to ussuri, right?
09:05:26 luyao you get time? Thanks in advance. :)
09:05:26 openstack bug 1879878 in OpenStack Compute (nova) "VM become Error after confirming resize with Error info CPUUnpinningInvalid on source node " [Medium,In progress] https://launchpad.net/bugs/1879878 - Assigned to Stephen Finucane (stephenfinucane)
09:05:26 luyao @stephenfin : After several rounds of review and update, we addressed issues in the first 3 patches for vpmem-enhencement https://review.opendev.org/#/q/topic:bp/vpmem-enhancement+(status:open+OR+status:merged). And for the last one 'improve orphans tracking', FYI. I redefined those orphans in updated patch since previous version involved the bug #1879878, and alex told me you fixed it. Could you look at it if
09:06:29 brinzhang gibi:otherwise cherrp-pick the stable release
09:06:31 brinzhang sorry for disconnect..
09:07:15 gibi git log 19.0.0.0rc1..20.0.0.0rc1 --no-merges | grep Closes-Bug
09:07:43 gibi brinzhang: ^^ this only list commits between when stable/train was branched off master until stable/ussuri branched of master
09:08:06 brinzhang it looks make sense, in the stable branch, let me try
09:10:50 gibi this is full ussuri including backport to stable/ussuri 19.0.0.0rc1..stable/ussuri
09:11:54 brinzhang gibi: it makes sense, thanks ^
09:12:22 brinzhang bauzas: thanks too, this is a good way
09:12:59 brinzhang gibi: can you check this cherr-pick patch https://review.opendev.org/#/c/749701/
09:13:24 brinzhang it was backported to ussuri
09:13:26 bauzas gibi: yeah that's an alternative, I was thinking of looking directly at git
09:13:43 bauzas but then you need to just awk or some other script
09:13:49 bauzas just use* awk
09:17:24 brinzhang yes, if we want to get every project, if there is a script that will be better
09:18:38 brinzhang gibi: how to get this release number (19.0.0.0rc1)? form https://releases.openstack.org/ussuri/#nova seems cannot get it
09:20:35 gibi I sorry I mixed up the numbers 20 is train, 21 is ussuri
09:20:37 brinzhang s/form/from
09:21:02 gibi so you need 20.0.0.0rc1..stable/ussuri
09:21:12 brinzhang ack
09:21:18 gibi the rc1 tag is added when we branch out the release
09:21:34 gibi that is the point when master was separated from stable/ussuri
09:21:39 brinzhang so the train is 19.0.0.0rc1, the stein is 18.0.0.0rc1?
09:22:09 gibi train is 20, ussuri is 21
09:22:35 brinzhang yeah, rocky is 18, stein is 19, train is 20, ussuri is 21
09:22:39 gibi stein is 19
09:22:42 gibi yepp
09:23:12 brinzhang very thankful
09:23:45 gibi please note that every project has its own numbering as they had their first release at different cycle
09:23:56 gibi and also in the past openstack used different tag names
09:25:51 brinzhang yeah, I think https://releases.openstack.org/ussuri is correctly
09:26:25 brinzhang just need to change the realse name
09:26:35 brinzhang just need to change the realse name in the url
09:43:54 brinzhang gibi: I find we dont necessary to checkout to the stable/ussuri, in master branch, we also can get the bug
09:44:17 brinzhang of course, we should point the correct branch number
09:44:55 gibi brinzhang: yes, git allows to query the tree without checking out anything
09:45:08 brinzhang \o
11:11:48 noonedeadpunk folks, need some help with figuring out the best way to separate hosts. Let me describe scenario
11:13:29 noonedeadpunk We have group of hosts that have ephemeral storages saved on NFS (/var/lib/nova/instances eventually). And we have another group of hosts with ceph. And we want all new VMs to be created on these ceph hosts, while leave old ones to be operating normally for a while
11:14:29 noonedeadpunk I'm aware about isolate aggregates, but then we will need to hide all current flavors, set some metadata on them, and create new set of flavors
11:14:51 noonedeadpunk Which will result that ppl won't be able to do retype
11:15:25 noonedeadpunk Another thing that come up to mind were AZ. But again, newly created VMs won't be guaranteed not to move to old AZ
11:16:15 noonedeadpunk Didn't look into cells yet tbh, but we eventually want to get rid of first AZ pretty soon, so don't want to overcomplicate things
11:19:15 noonedeadpunk Not usre if setting default_schedule_zone will set AZ for all newly created instances
11:19:53 noonedeadpunk Ok, found it, disregard please:)
11:19:59 noonedeadpunk https://docs.openstack.org/nova/latest/admin/availability-zones.html#implications-for-moving-servers
11:36:30 lyarwood sean-k-mooney: think I've finally reproduced the focal detach issue btw
11:36:57 lyarwood sean-k-mooney: had to do a complete tempest run on a small 8gb devstack instance
11:50:23 sean-k-mooney oh ok
11:51:04 sean-k-mooney any idea what is the cause
11:51:16 sean-k-mooney lyarwood: ^
11:59:08 lyarwood sean-k-mooney: still working my way through the logs, honestly just feels like the guestOS is just too slow in detaching the device
12:03:33 lyarwood sean-k-mooney: I'm going to wire up the libvirt events for this and see if they show the disk eventually being detached later on or something
12:06:35 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP/DNM libvirt: Increase device detach wait times https://review.opendev.org/749827
12:06:36 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP/DNM libvirt: Start emitting DeviceRemovedEvent and DeviceRemovalFailedEvent events https://review.opendev.org/749929
12:07:21 sean-k-mooney lyarwood: i wonder if this is realted to the pc machine type too
12:07:38 sean-k-mooney lyarwood: we handel pci hotplug differently in q35
12:07:48 sean-k-mooney the virtio-block interfaces we use by default
12:08:07 lyarwood sean-k-mooney: the machine type should be the same as earlier releases no?
12:08:07 sean-k-mooney all are hotpulged and unpluged when we attach and detach them

Earlier   Later