| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-05 | |||
| 18:56:38 | openstackgerrit | Michael Still proposed openstack/nova master: Move execs of touch to privsep. https://review.openstack.org/489190 | |
| 18:56:38 | prometheanfire | mriedem: that's a quick git-review you have there (or rebase maybe) | |
| 18:56:39 | openstackgerrit | Michael Still proposed openstack/nova master: Move libvirts dmcrypt support to privsep. https://review.openstack.org/490737 | |
| 18:56:39 | openstackgerrit | Michael Still proposed openstack/nova master: Move blkid calls to privsep. https://review.openstack.org/500398 | |
| 18:56:41 | openstackgerrit | Michael Still proposed openstack/nova master: Move execs of tee to privsep. https://review.openstack.org/489438 | |
| 18:56:53 | prometheanfire | bah, meant that for michael | |
| 18:57:41 | openstackgerrit | Merged openstack/nova master: Updated from global requirements https://review.openstack.org/500011 | |
| 18:57:46 | efried | prometheanfire git restack, yo. | |
| 18:58:09 | prometheanfire | what that come from? | |
| 18:58:22 | efried | It's a thing, hold on... | |
| 18:59:19 | efried | prometheanfire I think you install it with `pip install git-restack` | |
| 18:59:44 | efried | It's a git plugin maintained by stackers | |
| 19:00:49 | mriedem | prometheanfire: looks like this is the regression https://github.com/openstack/os-xenapi/commit/755876c19f7c47eaa773f835a68dcf93c3d6b50d | |
| 19:01:14 | efried | prometheanfire You say `git restack <commit-before-the-bottom-of-the-pile>`. Then you can choose to edit whichever ones in the chain via an edit file that looks kinda like when you rebase -i. It auto rebases everything in the pile. Then when you're done, you can `git review` and it pushes the whole pile (anything that has been changed, including rebases) | |
| 19:01:55 | prometheanfire | mriedem: k, so nova needs to update it's tests? | |
| 19:02:08 | prometheanfire | efried: I'll probably just stick to the classic rebase then | |
| 19:02:55 | mriedem | prometheanfire: not sure if it's that or if os-xenapi is regressed | |
| 19:03:02 | mriedem | i can start with reporting a bug | |
| 19:03:27 | prometheanfire | k | |
| 19:03:35 | prometheanfire | I'll hold that back for now then | |
| 19:03:41 | mriedem | thanks | |
| 19:05:09 | efried | jaypipes I'll have the same question about the "multiple resources, same class, different traits" syntax (in what state of maturity is this idea?) | |
| 19:08:24 | mriedem | prometheanfire: https://bugs.launchpad.net/nova/+bug/1715217 | |
| 19:08:24 | openstack | Launchpad bug 1715217 in OpenStack Compute (nova) "nova xenapi unit tests fail with os-xenapi 0.3.0" [Undecided,New] | |
| 19:09:17 | prometheanfire | thanks | |
| 19:13:26 | openstackgerrit | Jackie Truong proposed openstack/nova master: Add trusted_certs to instance_extra https://review.openstack.org/457711 | |
| 19:17:28 | artom | How are our man pages generated? Am I understanding correctly that https://review.openstack.org/#/c/475810/ has nothing to do with man pages? | |
| 19:17:36 | artom | stephenfin ^^, since you're the patch author :) | |
| 19:24:10 | mriedem | artom: https://github.com/openstack/nova/blob/master/doc/source/conf.py#L113 | |
| 19:24:14 | mriedem | part of the sphinx build | |
| 19:24:41 | mriedem | and yes https://review.openstack.org/#/c/475810/ has nothing to do with man pages | |
| 19:24:57 | artom | mriedem, and those all come from the doc/source/cli directory? | |
| 19:25:13 | mriedem | yeah | |
| 19:25:23 | artom | Thanks :) | |
| 19:25:31 | mriedem | did i win? | |
| 19:25:46 | artom | My eternal indifference | |
| 19:26:06 | artom | (It's 2 steps up from seething hatred) | |
| 19:49:28 | openstackgerrit | Lee Yarwood proposed openstack/nova-specs master: Libvirt: Native LUKS file and host device decryption by QEMU https://review.openstack.org/490824 | |
| 19:53:53 | jaypipes | efried: I don't know how to structure a request that would impart the required information for this query :( | |
| 19:54:27 | efried | jaypipes Well, shit, if YOU can't do it.... | |
| 19:54:32 | efried | Adding to list. | |
| 19:54:42 | jaypipes | efried: we would essentially need to replicate child-parent information in the request for resources. in other words, the requestor must know that a VF is a child of a PF is a child of a compute host. | |
| 19:55:06 | jaypipes | efried: and we can't ask the user to know that relationship... | |
| 19:55:44 | efried | jaypipes But the alternative is making them separate resource classes. Which doesn't seem right at all. | |
| 19:55:58 | jaypipes | efried: no, that doesn't work either... | |
| 19:56:12 | jaypipes | efried: because their not separate resource classes. they're separate providers. | |
| 19:56:35 | jaypipes | efried: just imagine for a second how one might ask AWS for such a thing. | |
| 19:56:55 | jaypipes | efried: you can't. | |
| 19:57:06 | efried | uhm | |
| 19:57:10 | jaypipes | efried: you need a more complicated DSL like CloudFormation or TOSCA | |
| 19:57:32 | efried | So how are we planning to model e.g. asking for more than one cinder volume? | |
| 19:57:36 | jaypipes | efried: and an orchestrator that would take one of those request templates and produce multiple requests to EC2 APIs. | |
| 19:58:09 | jaypipes | efried: we don't. that's the very reason why we've pushed back on having the compute API be an orchestration system. | |
| 19:58:35 | mriedem | prometheanfire: i think i've got these xenapi unit tests fixed | |
| 19:58:38 | mriedem | should have a patch up shortly | |
| 19:58:43 | prometheanfire | cool | |
| 19:58:44 | jaypipes | efried: you want >1 cinder volumes? then create them in cinder and attach them to your compute instance. | |
| 19:58:59 | prometheanfire | if that merges today then the xenapi change can go in tomorrow via bot update | |
| 19:59:04 | jaypipes | efried: there is absolutely no "atomically create 10 volumes in Cinder" command. | |
| 19:59:38 | mriedem | there isn't?! | |
| 19:59:40 | jaypipes | efried: and these kinds of requests that the VNFM would be making are essentially that: requests for a set of related resources to be created as an atomic unit. | |
| 20:00:14 | efried | jaypipes Seems like there should be a way to specify multiple `resources=` keys in a single request, kind of thing. | |
| 20:00:18 | mriedem | how about i request 10 VMs with block_device_mapping_v2 in the request, of size 10, for each entry with different device names so nova creates the volumes! | |
| 20:00:29 | jaypipes | incidentally, this is why there's no atomicity guarantees that *any* orchestrator provides. not k8s, not heat, not IBM "smart" cloud orchestrator. not any of them. | |
| 20:00:47 | mriedem | does sco still exist? | |
| 20:00:56 | jaypipes | heh, no idea. | |
| 20:01:03 | smcginnis | mriedem: I hear they own the copyright to OpenStack. | |
| 20:01:04 | efried | only as a lawsuit troller | |
| 20:01:18 | mriedem | they do have a snapshot api for vmware instances | |
| 20:01:22 | mriedem | which is different from os-createImage | |
| 20:01:27 | mriedem | different, and superior | |
| 20:02:03 | efried | Yeah, less concerned about atomicity at the moment. | |
| 20:02:22 | efried | I mean, what if I want two different GPUs with different specialties? | |
| 20:03:04 | efried | / capabilities | |
| 20:03:11 | mriedem | ask cyborg | |
| 20:03:52 | efried | I don't know what that means | |
| 20:04:13 | mriedem | https://wiki.openstack.org/wiki/Cyborg | |
| 20:04:33 | mriedem | https://review.openstack.org/#/c/448228/ | |
| 20:04:59 | mriedem | jaypipes: is Roman Dobosz still around? | |
| 20:05:09 | mriedem | oh nvm | |
| 20:05:10 | mriedem | no | |
| 20:05:13 | jaypipes | mriedem: no | |
| 20:05:21 | mriedem | he was osic? | |
| 20:05:36 | jaypipes | no | |
| 20:05:47 | jaypipes | just got moved to a super-special-secret internal Intel project | |
| 20:06:04 | efried | Okay, so IIRC, it's legal in HTTP for a query param key to be repeated, and show up on the server side as a list of values. | |
| 20:06:28 | jaypipes | efried: show me an EC2, GCE, or Azure ability to request an instance that has multiple GPUs that are different. | |
| 20:06:37 | jaypipes | efried: yes. | |
| 20:06:44 | efried | What, because they can't do it, we shouldn't? | |
| 20:07:09 | efried | I mean, I'm at a clear disadvantage here, having no experience with any of those things. | |
| 20:07:13 | jaypipes | efried: no, because they can't do it is a pretty good indication that it's not something we should spend a shit-ton of time trying to do ;) | |
| 20:07:32 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Make xen unit tests work with os-xenapi>=0.3.0 https://review.openstack.org/500968 | |
| 20:07:36 | efried | What if it's not a shit-ton of time? | |
| 20:07:50 | jaypipes | efried: if it wasn't, you'd have done it already. | |
| 20:08:03 | mriedem | prometheanfire: https://review.openstack.org/500968 | |
| 20:08:20 | efried | Mebbe I will. | |
| 20:08:26 | efried | But - okay - will put this down for now as "stated acceptable limitation". | |
| 20:09:09 | jaypipes | efried: all of these feature requests are basically for NFV use cases, anyway... which is hardware-defined software as I've said before. It's not cloud in as much as it's not abstraction. It's basically just automating the installation of \a very specific hardware environment. | |
| 20:10:47 | efried | jaypipes So can I have a VM on more than one network? | |
| 20:11:03 | jaypipes | efried: you can do that *now*... | |