| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-26 | |||
| 16:51:19 | openstackgerrit | melanie witt proposed openstack/nova master: Count instances to check quota https://review.openstack.org/416521 | |
| 16:51:21 | openstackgerrit | melanie witt proposed openstack/nova master: Make Quotas object favor the API database https://review.openstack.org/410945 | |
| 16:51:21 | openstackgerrit | melanie witt proposed openstack/nova master: Add online migration to move quotas to API database https://review.openstack.org/410946 | |
| 16:51:27 | mriedem | cburgess: idk, it's probably worth starting to prime the pump for that session at the forum, | |
| 16:51:42 | mriedem | so we don't start a 40 minute session discussing all of the history and previously discussed options | |
| 16:51:56 | mriedem | and then find out we have 5 minutes left with nothing new to say | |
| 16:52:22 | cburgess | mriedem What I don't like about most of the solutions we have discussed is that if you forget to flag a flavor correctly then it could get placed on a compute node that doesn't want local storage. | |
| 16:52:36 | mriedem | cburgess: before starting a ML thread, | |
| 16:52:47 | mriedem | maybe i start an etherpad, which i'll need for the session anyway, | |
| 16:52:48 | cburgess | mriedem I feel like we need a method that ensures a compute node can assert that it can never ever host a local disk. | |
| 16:52:58 | mriedem | and we can start listing the use cases and options, and pros/cons for each option | |
| 16:53:01 | mgagne | maybe just list the use cases, we don't need to agree on the validity of the need, just list them, list associated workaround/limitations, etc. and start from there | |
| 16:53:07 | mriedem | *then* put that in the ML for discussion | |
| 16:53:08 | cburgess | mriedem Yeah.. lets start with an etherpad. Once we get it to an ok state we can post it to the ML. | |
| 16:53:14 | cburgess | mriedem I like it. | |
| 16:53:27 | cburgess | mgagne Right.. only rule out the most obviously insane ideas. | |
| 16:53:39 | mriedem | mgagne: cburgess: i'll create an etherpad after the cells meeting and report back here | |
| 16:53:47 | cburgess | mriedem Rainbows | |
| 16:53:47 | mgagne | we can list them and explain later why we can't or don't want to support them | |
| 16:54:09 | mgagne | so people don't come back later and ask why that one isn't listed | |
| 16:54:38 | mriedem | looks like the etherpads have started https://wiki.openstack.org/wiki/Forum/Boston2017 | |
| 16:54:43 | mriedem | which was on my todo list anyway | |
| 16:54:55 | cburgess | mgagne I'm only advocating ruling out things like "create a new top level openstack project" or other things of that level. | |
| 17:06:01 | mordred | cdent: what does placement use in the id field of its version doc? | |
| 17:08:37 | cdent | mordred: the min version | |
| 17:08:51 | cdent | which is a fudge | |
| 17:09:17 | cdent | it might make sense to split on '.' and use [0] | |
| 17:14:28 | mordred | cdent: ok. so it does have a value in id | |
| 17:14:48 | cdent | yeah, but it puts nothing in the url that indicates version and has no plan to | |
| 17:17:04 | sumedhdegaonkar | Hello all, this is my first review request, so please bear with me. I'd like to get your opinion/review of https://review.openstack.org/#/c/459794/ - It's just removing a restriction to use of 'sata' disk bus type for qemu and kvm. No change to default behavior or selection and hence in my opinion, no need to update test cases | |
| 17:30:18 | openstackgerrit | Rafael Folco proposed openstack/nova master: placement: Specific error for inventory in use https://review.openstack.org/460231 | |
| 17:31:10 | cdent | mriedem: way back in earlier conversation you mentioned a bug in gabbi with left hand side json path substitutions. I meant to link you to this: https://github.com/cdent/gabbi/issues/170 | |
| 17:31:30 | cdent | but also to ask: was that germane to what were talking about at the time, or just an observation? | |
| 17:32:15 | mriedem | it was related | |
| 17:32:23 | mriedem | i was also looking through the gabbits for an example of a response | |
| 17:32:24 | mriedem | to see the keys | |
| 17:33:37 | cdent | mriedem: I could fix that bug in the case you're talking about it is often easier to make the right hand side more complete (a structure instead of a string) | |
| 17:37:35 | mriedem | not a priority for me, i just noticed the comments in the gabbits about the limitation | |
| 17:37:43 | mriedem | api-ref is the priority, | |
| 17:37:49 | mriedem | because then i don't need to look at gabbits | |
| 17:38:23 | cdent | i regret slinging that name around | |
| 17:43:57 | openstackgerrit | Steven Webster proposed openstack/nova master: Improve comment for PCI port binding update https://review.openstack.org/460233 | |
| 17:51:02 | mriedem | mgagne: cburgess: johnthetubaguy: stackempty: here you go https://etherpad.openstack.org/p/BOS-forum-using-cinder-for-nova-ephemeral-storage | |
| 17:51:47 | cburgess | mriedem Are we open to having a 'short term' and a 'long term' set of goals and solutions? | |
| 17:52:12 | mriedem | i think you could tag things that way | |
| 17:52:24 | mriedem | i'm open to eating lunch | |
| 17:52:27 | mriedem | so bbiab | |
| 17:55:39 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Refactor encryptor attach and detach calls https://review.openstack.org/460243 | |
| 17:55:39 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Attach and detach encryptors during swap_volume https://review.openstack.org/460244 | |
| 17:57:51 | cburgess | mriedem Just doing that myself | |
| 18:04:37 | mgagne | cburgess: so there are 2 use cases? : 1) Provide a default BDM 2) Prevent/forbid source=local in BDM | |
| 18:05:19 | mgagne | in fact, destination=local | |
| 18:06:38 | dansmith | does anyone know if test_delete_server_while_in_building_state is known to be flaky at the moment? logstash doesn't seem to think it's spiking but I see plenty of failures that aren't in my patch, like even on periodic stable jobs | |
| 18:06:40 | dansmith | mriedem: sdague ^ | |
| 18:12:02 | mgagne | cburgess: what do you think about the idea of having a "default bdm" for flavor-root-disk-none ? If you provide no BDM, the root_gb size is used to create a volume for you for your root disk. (flavor could also provide default volume type) This means no 400 HTTP error by default as a sane behavior/default is provided. An other extra spec or flavor attribute could forbid destination=local so if BDM is provided, it still respect the no-local-dis | |
| 18:12:02 | mgagne | k policy. | |
| 18:12:46 | cburgess | mgagne Thats a decent idea. Pull size from root_gb and image_id from request spec. | |
| 18:12:52 | mgagne | yes | |
| 18:13:04 | mgagne | that's basically what we did on our side | |
| 18:13:44 | mgagne | also this could allow Horizon or dashboard to present appropriate UI (default to BFV view or something like that) | |
| 18:14:59 | mgagne | I also see 2 sub use cases: 1) flavor itself *never* support local disk. 2) specific compute nodes *never* want local disk. // One can be implemented without the other. | |
| 18:16:21 | cburgess | Right so #2 is my biggest concern and the biggest pain right now. Ensuring it can never happen. Because if it does happen you end up with data a user might care about living on a single local disk on a compute node, and thats very bad. | |
| 18:16:54 | mgagne | ok, can I take the liberty of splitting the use cases on etherpad? | |
| 18:17:02 | cburgess | mgagne Sure | |
| 18:17:33 | openstackgerrit | OpenStack Proposal Bot proposed openstack/os-vif master: Updated from global requirements https://review.openstack.org/451049 | |
| 18:17:40 | cburgess | mgagne I prefer that actually as I think there are 2 orthogonal needs 1) Making BDM/cinder integration better, 2) Making sure we can block local disk. | |
| 18:17:51 | mgagne | yes | |
| 18:18:21 | cburgess | mgagne #2 we should focus on a 1-2 cycle solution, for #1 we should take a step back and say whats need to really do this right (aka the cinder imagebackend). | |
| 18:18:35 | mgagne | 100% agree | |
| 18:19:04 | mgagne | what about ephemeral disks or swap? what's your take? | |
| 18:19:23 | cburgess | Personally I love the idea of a cinder imagebackend but to do that right I think its going to require first rewritting the existing backends to have a much more modular and cleaner seperation. | |
| 18:20:08 | mgagne | yes, I found the task to be near impossible without major refactor when I checked years ago, hence the middleware hack | |
| 18:20:14 | cburgess | mgagne I don't understand the use case for either of those. Honestly I would vote to remove them from nova entirely but I know that wouldn't fly. The question is should we require all backends to support them or should we make those optional. | |
| 18:20:39 | mordred | mgagne, cburgess: in the name of requesting absurd features from people while the local vs. remote disk discussion is taking place ... | |
| 18:20:59 | cburgess | mgagne Right. We also have cases where things like instance_path are used both for the imagebackend and for non-imagebackend things like console logs, libvirt xml etc. So we have to get a clean separation there as well. | |
| 18:21:12 | cburgess | mordred Yes......? | |
| 18:21:16 | mordred | no-local-disk is really useful in both keeping data protected and making sure live migration can happen well ... | |
| 18:21:29 | erhudy | is the goal to eventually turn over all responsibility for block storage to cinder and remove it from nova entirely? | |
| 18:21:40 | cburgess | erhudy Thats is not my goal. | |
| 18:21:55 | cburgess | erhudy My goal is to provide an improved integration between nova and cinder. | |
| 18:22:07 | mordred | but depending on workload, the user might also know "this node is part of an application-level high availablity set, killing it and its data rather than live-migrating it is fine" | |
| 18:22:38 | mordred | especially when for those things locally attached things that behave like ephemeral disk does today is nice becaues of the lack of network latency hop between the vm and disk | |
| 18:22:59 | mgagne | cburgess: So having the ability to split imagebackend/disk from "hypervisor" (logs, xml) files is something an operator should be able to do? | |
| 18:23:10 | cburgess | mordred Hmm hand't thought about that. data volume on cinder, but a local ephemeral disk for "fast" scratch. | |
| 18:23:14 | mordred | yah | |
| 18:23:27 | mordred | but as a user opt-in sort fo thing | |
| 18:23:40 | mordred | since it's definitely a choice witha tradeoff involved | |
| 18:23:43 | cburgess | mgagne Well.. I think the only way to truely make imagebackend modular enough to support cinder we would have to have that clean seperation since cinder isn't going to provide us a way of storing that data. | |
| 18:23:45 | erhudy | cburgess: that can be done now | |
| 18:24:02 | cburgess | erhudy Which thing? | |
| 18:24:07 | mgagne | cburgess: that's the use case I can think of, like on SSD or NVMe | |
| 18:24:18 | erhudy | data/root volumes on cinder with local storage ephemeral disk | |
| 18:24:46 | erhudy | what i keep coming back to as part of our architecture discussions here is wanting to be able to do something like AWS instance store volumes, which afaik doesn't really have an analogue in nova | |
| 18:24:53 | cburgess | erhudy Yes I'm aware. mordred was pointing out that my state of "kill ephemeral in a fire" didn't take into acount that very valid use case. | |
| 18:25:07 | mordred | cburgess: the mirror.*.openstack.org farm is a good example- the only things on the local disk are cache - everything else is stored somewhere else | |
| 18:25:13 | erhudy | you can pass whatever you like to nova in the BDM but unless it matches your flavor it gets rejected | |
| 18:26:00 | mordred | but we'd be totally fine with the datain the ephemeral going away for those nodes, and could opt-in at boot to that and _maybe_ that makes something better for someone somewhere | |
| 18:26:30 | mordred | "hey, we actually don't find the stuff in X precious, DNR" :) | |
| 18:26:34 | erhudy | "ephemeral" in nova-ese is different from "ephemeral" in AWS-ese anyway, which confused a lot of our users | |
| 18:26:35 | cburgess | mordred right. Its def a valid use case. We should make it possible for a user to request a local disk as well *if* the compute node supports it. | |