Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-13
13:57:40 mriedem like, copy openstack-tox-py27 and tweak but not extend
13:57:51 finucannot Ohh, I guess we could do that, yeah
13:58:58 finucannot I think openstack-tox-py27 is run by default though. I'm not sure how/if we can disable that
13:59:11 mriedem it's run because of the "openstack-python-jobs" usage in project-config
13:59:17 finucannot i.e. it's defined in openstack/project-config or the likes
13:59:18 finucannot yup
13:59:47 finucannot *openstack-infra/project-config
13:59:47 mriedem which runs:
13:59:48 mriedem - openstack-tox-py27
13:59:48 mriedem - openstack-tox-pep8
14:00:17 mriedem yeah so if we defined our own job, we'd have to list openstack-tox-pep8 in our own .zuul.yaml along with nova-tox-py27, but that seems ok,
14:00:30 mriedem and we'd have to backport it to all stable branches before removing the template usage from project-config
14:00:54 mriedem trivial but time consuming
14:01:10 finucannot Hmm. Can zuulv3 not support this use case?
14:01:32 mriedem i don't know why you can't extend an existing job and override attributes of it, like irrelevant-files
14:01:36 mriedem if we could do that, we'd be set
14:02:14 finucannot That sounds like a more effective use of time, if we can do it. I wonder if mordred is around?
14:02:25 mriedem i'm asking again in -infra,
14:02:32 mriedem but last time this came up there were lots of words in the ML
14:02:45 mriedem my head exploded, and i moved on
14:03:58 mriedem just sucks that we have to wait 2+ hours for a 15 min job
14:04:22 mriedem heh, maybe i should be asking, why is this taking nearly 2 hours
14:04:23 mriedem tempest-full-py3SUCCESS in 1h 50m 17s
14:04:49 fried_rice mriedem: How long does it take when you run it locally? Did you say you can run the whole thing in 15m?
14:05:07 mriedem fried_rice: i just mean the unit test job takes 15 minutes
14:05:17 mriedem and that's all we care about in this unit test only patch
14:05:25 fried_rice ah, I see.
14:05:46 fried_rice Well, I know I've seen special cases where what you've changed influences which jobs are run.
14:05:59 fried_rice Can't remember specifically for sure, but I think e.g. if you only change docs, only docs jobs are run.
14:06:05 fried_rice So there's a precedent for it.
14:06:32 mriedem yes that's how things used to all work when the jobs were centralized in project-config, pre-zuulv3
14:06:46 mriedem looking at http://logs.openstack.org/90/561190/1/check/tempest-full-py3/41adeca/controller/logs/stackviz/#/stdin/timeline some of the tempest tests are taking over 7 minutes
14:07:18 mriedem maybe that's all related to meltdown/spectre fallout...
14:07:19 mriedem slow nodes
14:07:37 mriedem alright, i'll take my cup o coffee and go back into my old man hole now
14:25:49 mordred finucannot: uhoh
14:25:53 mordred finucannot: what did I do this time?
14:26:04 mriedem alex_xu: bauzas: per https://review.openstack.org/#/c/554159/ - this is doing the same thing that 2.47 does with showing embedded flavors with extra specs in GET /servers/{server_id}
14:26:48 fried_rice mordred: Da boyz were noodling whether/how we could make certain jobs conditional.
14:27:01 finucannot mordred: It's mriedem you've to worry about. He's mad about not being able to override 'irrelevant-files' on our tox-py27 job
14:27:22 fried_rice mordred: E.g. https://review.openstack.org/#/c/561190/ changed only a UT file, so it would be nice if we didn't bother running all the tempest suites, and we could merge the sucker in 15 minutes instead of 2h.
14:27:38 mordred totallly understand
14:27:57 bauzas mriedem: so it's using a same policy rule for that ?
14:28:19 mriedem bauzas: see my reply to alex_xu in https://review.openstack.org/#/c/554159/ just now
14:28:27 bauzas lemme check the code but I need to disappear in like 2 mins
14:29:06 bauzas mriedem: okay, lemme change my vote, but it'll require a docfix
14:29:29 bauzas that's the other option I had in mind, so it was a soft -1
14:29:37 mordred I would actually think that just adding a nova-specific openstack-tox-py35 variant with some additional irrelevant-files added would work
14:29:51 mordred I'm assuming y'all have tried that already?
14:30:41 bauzas mriedem: +W'd with a comment asking for a followup
14:32:58 mriedem bauzas: thanks
14:33:03 mriedem i replied to more of the inline stuff too
14:38:51 mriedem mordred: already talked about that above, and the implications of doing so
14:39:01 mriedem mordred: tl;dr is i know it's trivial to do, just time consuming
14:39:07 mriedem given backports to stable and changes to project-config
14:39:40 mriedem it would help e-r to have project-specific tox jobs again http://status.openstack.org/elastic-recheck/data/integrated_gate.html#openstack-tox-py35
14:42:57 Shilpa mriedem: Hi, i was going thorugh https://review.openstack.org/#/c/511965/1 >> Spec for volume-backed flavors, any reason why workflow is -1 here
14:43:17 mordred mriedem: I tink we're collecting enough metadata so that elastic recheck could know job + project - we sohuld probably update it to use the data
14:46:39 mriedem Shilpa: because it's complicated and mostly a brain dump to docs for something we've talked about sporadically when we have meetups (PTG, Forum, etc)
14:46:50 mriedem it's not something i'm actively pursuing for Rocky
14:47:21 leakypipes mriedem, mdbooth, superdan: so, question coming from one of our ops teams... is it possible to (live) migrate from a host using ceph for ephemeral disk storage to a host that uses local disk storage (this is temporarily during an upgrade procedure)
14:47:50 superdan leakypipes: with block migration maybe
14:48:05 superdan I'm not an expert there, I'd ask mdbooth when he gets off a call in 13 mins
14:48:12 leakypipes superdan: cool, thx
14:48:28 superdan leakypipes: also please see channel topic
14:48:34 mriedem it's going from an ephemeral ceph to a non-ceph ephemeral?
14:48:43 Shilpa mriedem: ok, one more thing pl confirm, specs not talikng @ to have root_gb=0 for flavor `volume_backed=True`
14:49:00 mriedem i know our live migration job tests ceph with ephemeral imagebackend and with volume-backed
14:49:11 mriedem but it's ceph on both sides, not changing image types for the ephemeral case
14:49:39 mriedem Shilpa: can you rephrase the question?
14:50:04 melwitt mriedem, superdan, leakypipes: just remembered we need to propose forum topics today (deadline is sunday april 15) https://etherpad.openstack.org/p/YVR-nova-brainstorming
14:50:27 melwitt I see cdent already proposed a couple of placement-related ones
14:50:33 superdan mdbooth: I added a thing in there
14:51:16 leakypipes melwitt: ack. (I won't be at the forum, but will try to add items)
14:51:29 mriedem Shilpa: based on https://review.openstack.org/#/c/511965/1/specs/queens/approved/volume-backed-flavors.rst@74 - you couldn't have volume_backed=True and root_gb=0
14:51:34 mriedem because that would result in creating a 0gb vlume
14:51:36 mriedem *volume
14:51:44 melwitt leakypipes: :( to not being there, k thanks
14:51:48 mriedem which i'm pretty sure cinder doesn't allow, volumes have to be at least size>=1
14:51:58 openstack Launchpad bug 1469179 in OpenStack Compute (nova) "instance.root_gb should be 0 for volume-backed instances" [Medium,In progress] - Assigned to Dan Smith (danms)
14:51:58 Shilpa mriedem: actually root_gb should be 0 for volume-backed instances (LP bug https://bugs.launchpad.net/nova/+bug/1469179), so here in specs we are marking ``volume_backed=True` for volume-backed instance
14:53:16 leakypipes melwitt: a certain money-lending institution isn't getting their Friday dues.
14:53:32 melwitt lol
14:53:34 mriedem Shilpa: then i think you're looking for https://review.openstack.org/#/q/topic:fix-bfv-boot-resources+(status:open+OR+status:merged)
14:53:44 leakypipes there she is :)
14:54:14 mriedem Shilpa: feel free to comment on the spec as a reminder, but as noted, it's not something i'm actively pursuing
14:56:52 Shilpa mriedem: yes iam looking for https://review.openstack.org/#/q/topic:fix-bfv-boot-resources+(status:open+OR+status:merged) , is spec resolves this?
14:59:41 mriedem Shilpa: no, it's unrelated
15:00:10 mriedem Shilpa: think of that spec basically like the 'get me a network' feature in the 2.37 microversion, but like 'get me a volume-backed instance'
15:00:15 mriedem simply the bdm_v2 stuff the user has to do
15:00:18 mriedem *simplify
15:00:40 mriedem and allow operators to easily define volume-backed flavors globally
15:01:34 mriedem Shilpa: btw, root_gb=0 doesn't mean volume-backed per se, https://developer.openstack.org/api-ref/compute/#create-flavor
15:01:42 mriedem "The size of the root disk that will be created in GiB. If 0 the root disk will be set to exactly the size of the image used to deploy the instance. However, in this case filter scheduler cannot select the compute host based on the virtual image size. Therefore, 0 should only be used for volume booted instances or for testing purposes."
15:02:16 mriedem root_gb=0 and server.image_id = '' would definitely indicate volume-backed
15:02:29 jgwentworth oh, that reminds me of a bug I wanted to ask people about
15:03:42 openstack Launchpad bug 1763039 in OpenStack Compute (nova) "evacuate instance documentation not mentioning host-evacuate" [Undecided,New]
15:03:42 mriedem superdan: heh you'll like this https://bugs.launchpad.net/nova/+bug/1763039
15:04:25 openstack Launchpad bug 1758278 in OpenStack Compute (nova) "disk_available_least become a negative value unexpectedly" [Undecided,New]
15:04:25 jgwentworth this one, issues with 0 GB disk flavor + image-based instance https://bugs.launchpad.net/nova/+bug/1758278

Earlier   Later