| *** dklyle has joined #openstack-placement | 00:30 | |
| *** mriedem has quit IRC | 00:41 | |
| *** bhagyashris has joined #openstack-placement | 00:58 | |
| *** ttsiouts has joined #openstack-placement | 01:29 | |
| *** tetsuro has joined #openstack-placement | 01:49 | |
| openstackgerrit | Tetsuro Nakamura proposed openstack/placement stable/stein: Skip _exclude_nested_providers() if not nested https://review.opendev.org/659200 | 02:00 |
|---|---|---|
| *** ttsiouts has quit IRC | 02:02 | |
| *** tetsuro_ has joined #openstack-placement | 02:37 | |
| *** tetsuro has quit IRC | 02:39 | |
| *** tetsuro has joined #openstack-placement | 02:42 | |
| *** tetsuro_ has quit IRC | 02:46 | |
| *** tetsuro has quit IRC | 03:50 | |
| *** tetsuro has joined #openstack-placement | 03:52 | |
| *** alex_xu has joined #openstack-placement | 03:53 | |
| *** ttsiouts has joined #openstack-placement | 03:59 | |
| *** ttsiouts has quit IRC | 04:31 | |
| *** tetsuro has quit IRC | 04:37 | |
| *** e0ne has joined #openstack-placement | 05:05 | |
| *** e0ne has quit IRC | 05:08 | |
| *** alex_xu has quit IRC | 05:26 | |
| *** ttsiouts has joined #openstack-placement | 06:29 | |
| *** e0ne has joined #openstack-placement | 06:35 | |
| *** alex_xu has joined #openstack-placement | 06:53 | |
| *** ttsiouts has quit IRC | 07:02 | |
| *** alex_xu has quit IRC | 07:05 | |
| *** alex_xu has joined #openstack-placement | 07:06 | |
| *** tssurya has joined #openstack-placement | 07:07 | |
| *** helenafm has joined #openstack-placement | 07:18 | |
| *** ttsiouts has joined #openstack-placement | 07:30 | |
| *** ttsiouts has quit IRC | 08:34 | |
| *** bhagyashris has quit IRC | 09:56 | |
| *** ttsiouts has joined #openstack-placement | 10:31 | |
| *** ttsiouts has quit IRC | 11:04 | |
| *** cdent has joined #openstack-placement | 12:16 | |
| *** mriedem has joined #openstack-placement | 12:23 | |
| tssurya | cdent: around ? | 12:49 |
| cdent | yes, hello | 12:49 |
| tssurya | remember http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005897.html ? | 12:49 |
| tssurya | we talked about making the consumer type "unknown" or something by default | 12:50 |
| tssurya | in the consumers table | 12:50 |
| * cdent nods | 12:50 | |
| tssurya | when I was updateing the spec I realaised the way placement usually maps coulmns is through ids | 12:50 |
| tssurya | so what I was initially proposing was that the consumer_type_id is what would be in the consumers table | 12:51 |
| tssurya | like most of the placement tables | 12:51 |
| * cdent nods | 12:51 | |
| tssurya | but for the sake of the default value in this case it would the actual key that goes in | 12:51 |
| tssurya | unless we define an "unknown" consumer type | 12:51 |
| tssurya | explicitly | 12:51 |
| cdent | why's that? wouldn't you create... yeah that | 12:51 |
| tssurya | oh so the later okay ? | 12:52 |
| cdent | I think so, yes | 12:52 |
| tssurya | cool then :) | 12:52 |
| cdent | :) | 12:52 |
| tssurya | sorry to keep bothering you with the petty details | 12:52 |
| cdent | no problem at all, I think it is better that we talk this stuff out as much as required | 12:52 |
| *** ttsiouts has joined #openstack-placement | 13:01 | |
| *** artom has quit IRC | 13:14 | |
| *** ttsiouts has quit IRC | 13:35 | |
| cdent | mriedem, efried, edleafe: based on all this hullabaloo about os-traits at the moment, I'm thinking it probably makes sense to have some additional cores on os-traits and os-resource-classes in the class of "I care about names and I also know about hardware". I do not consider myself in that class and would like to have some delegates | 14:08 |
| edleafe | cdent: I care about names, but know next to nothing about hardware | 14:09 |
| cdent | that's a start | 14:09 |
| cdent | and I would think enough of one | 14:09 |
| cdent | sean-k-mooney and kashyap clearly care about this sort of stuff too | 14:10 |
| efried | cdent: I don't mind adding cores, but I'm not sure it would further the issues we're facing right now. | 14:11 |
| efried | documentation would do a better job | 14:11 |
| efried | but that would entail "architects" sitting down and deciding what we do and do not want standard traits/RCs to be. | 14:11 |
| sean-k-mooney | i do care about os-traits. and os-resource classes to a degree also | 14:12 |
| cdent | efried: I'm not saying it would help with the issues, rather that the existence of the issues points out need for multiple voices in the discussion | 14:12 |
| sean-k-mooney | but im missing context so ill read back | 14:12 |
| sean-k-mooney | oh this is in relation to the trait for the vulnerablities and cpu feature | 14:13 |
| mriedem | cdent: is there not a separate core team for os-traits? because dansmith is who i'd delegate to about traits | 14:14 |
| mriedem | ok i guess it's just placement-core https://review.opendev.org/#/admin/projects/openstack/os-traits,access | 14:15 |
| cdent | mriedem: not at the moment, but I'm thinking there should be | 14:15 |
| cdent | sean-k-mooney: that discussion inspired the idea, but isn't the whole deal | 14:15 |
| mriedem | i haven't really been following said hullabaloo | 14:16 |
| mriedem | i agree with dansmith though that it's not nova's job to report that kind of information | 14:16 |
| mriedem | i.e. you've patched your system or whatever | 14:16 |
| sean-k-mooney | we have stated as a mater of policy in the past that this was out of scope | 14:16 |
| mriedem | external tooling can detect and tack on a custom trait if that's something you care about monitoring in your cloud | 14:17 |
| sean-k-mooney | it came up the first time i suggsted adding tratis for secure boot | 14:17 |
| sean-k-mooney | in that we decied it was not nova job to report if the sytem used secure boot or not | 14:17 |
| sean-k-mooney | in that case we pointed to https://github.com/openstack/nova/blob/c6218428e9b29a2c52808ec7d27b4b21aadc0299/doc/source/contributor/policies.rst#metrics-gathering vaguly as the basis for that | 14:19 |
| sean-k-mooney | in that we consider reporting if secure boot was enabled on the host to be a similar plathfor confugration metric/feature that was out of scope of nova to report/expose | 14:20 |
| sean-k-mooney | i think the vulnerablits fall into the same catagory | 14:20 |
| efried | secure boot and metrics don't seem like related issues at all. I think the objection to metrics was that we don't want traits used to track "state". At least for certain values of "state" that tend to be very dynamic... | 14:23 |
| efried | IMO secure boot seems like a perfectly reasonable thing to use a trait for. | 14:24 |
| sean-k-mooney | efried: they dont but that specifc policy was cited in the firt ptg in denver as to why it was out of socpe to do it | 14:24 |
| sean-k-mooney | i remember because i also taught it was unrelated at the time | 14:24 |
| efried | It's been something of a religious war the whole time. I'm on the liberal side personally. | 14:25 |
| sean-k-mooney | but i think the meaning was there were external things that could track that and more over jay did not want to see state tracked as tratis in placement | 14:25 |
| sean-k-mooney | so supprot secure boot was fine | 14:25 |
| sean-k-mooney | sucure boot was enable which was the second half was not | 14:25 |
| openstackgerrit | Surya Seetharaman proposed openstack/placement master: Spec: Support Consumer Types https://review.opendev.org/654799 | 14:26 |
| sean-k-mooney | the socund half was the metrics/monitor tie in in that nova was monitoring th econfiguration of the system on agent start to determin if it was configerd | 14:26 |
| *** artom has joined #openstack-placement | 14:27 | |
| sean-k-mooney | efried: and yes support uefi secure boot is a preferctly resonable ting to have as a trait | 14:27 |
| openstackgerrit | Surya Seetharaman proposed openstack/placement master: Spec: Support Consumer Types https://review.opendev.org/654799 | 14:28 |
| efried | Traits are cheap, and the API is robust, so we should use them anywhere it makes sense to identify a characteristic of a resource provider. | 14:28 |
| efried | IMO it still doesn't make sense to track very dynamic things (core temps or whatever), but that's because API traffic and rtt makes it impractical for things that need to be close to "realtime", not because there's some architectural or ethical problem with that being done with a trait. | 14:28 |
| efried | So I have no problem with a trait for "metrics gathering enabled". But I don't think it makes sense to be storing the metrics themselves in placement in any form. | 14:29 |
| efried | cdent: At what scale do you think trait profusion would actually become problematic for the infrastructure? | 14:29 |
| sean-k-mooney | ya i felt similar in that thing that only change when you reboot like bios options were ok but the issue with that is if you had feature X enabled. schulded a vms that required it and then your in troble if you disabel it again | 14:30 |
| openstackgerrit | Surya Seetharaman proposed openstack/placement master: Spec: Support Consumer Types https://review.opendev.org/654799 | 14:30 |
| efried | I have to imagine it would be tens or hundreds of thousands at least. | 14:30 |
| * cdent catches up | 14:30 | |
| efried | perhaps the issue is more with the usability side. Humans doing rp trait list on the CLI don't want to see pages and pages of them? Not sure how much I care about that aspect tbh. That's what grep is for. | 14:31 |
| cdent | I agree that tens or hundreds of thousands ought to be workable | 14:32 |
| cdent | i think that boundary of what is or isn't a trait is essentially "this would be better as a key value pair" | 14:32 |
| sean-k-mooney | efried: well if you model state in placement via tratis and then you have a vme that requries State X if that change to state Y all allocation that required State X are now invalid | 14:32 |
| cdent | so TEMP_HOT is easier to consider than TEMP_100 | 14:33 |
| sean-k-mooney | yes but even with TEMP_HOT | 14:33 |
| cdent | but because TEMP_100 is not a good idea, it influences the sense that TEMP_HOT is also not a good idea | 14:33 |
| sean-k-mooney | what do you do if you have a vm the has trait:TEMP_HOT=forbidin | 14:33 |
| sean-k-mooney | do you migrate it off the compute node | 14:33 |
| efried | I could see that being a future feature. | 14:34 |
| efried | probably not something nova should orchestrate | 14:34 |
| cdent | a vm would not have a trait, its host would... | 14:34 |
| sean-k-mooney | auto migration based on chagnes in tratis | 14:34 |
| cdent | (to be pedantic) | 14:34 |
| sean-k-mooney | isnt that how kuberntes lables work kind of | 14:34 |
| efried | cdent: I think sean-k-mooney is saying the VM's db record has, in its flavor/image/whatever, a trait:TEMP_HOT=forbidden | 14:35 |
| sean-k-mooney | if you add or remvoe k8s lables to node it will schudler/evict workload based on there requirements | 14:35 |
| sean-k-mooney | efried: yes | 14:35 |
| sean-k-mooney | if the vm has | 14:35 |
| efried | Anyway, the fact that it's not appropriate for nova to orchestrate that flow doesn't mean we should disallow it from being a standard trait. | 14:35 |
| sean-k-mooney | trait:TEMP_HOT=forbidden in the flaovr or image and after it has been booted the virt driver or what ever adds it technically that would cause rebuild to fail | 14:36 |
| sean-k-mooney | yes but you could also have CUSTOM_VULNERABLITY_MAGIC_UNICORN that that external CVE monitoring tool applies and that a poloicy engen then takes corrective action on | 14:37 |
| * edleafe reads back after emerging from meetings | 14:49 | |
| edleafe | I think that there is a big difference between what is appropriate in os-traits, and what any individual deployment might want to do | 14:49 |
| edleafe | If someone wants to create CUSTOM_TEMP_100, that's up to them | 14:50 |
| edleafe | But I wouldn't want to see anything like that added to os-traits | 14:50 |
| sean-k-mooney | yep although i would praobly model termal domain via aggrate rather then traits but we have CUSTOM_ traits for usecases like this | 14:51 |
| sean-k-mooney | that said i also dont think we should avoid add new standard traits if they are generaly reusable | 14:52 |
| sean-k-mooney | actully when i have considerd modeling termal domain as aggrate in the past it was more this set of host is on one cooling system that is idepend fo this other set of host | 14:54 |
| sean-k-mooney | e.g. modeling the fault domains | 14:54 |
| sean-k-mooney | rather then this thign is hot | 14:54 |
| sean-k-mooney | by the way modeling power as capasity as a sharing resouce provide with traits for if tis is ups back or desile backed is a usecase that came up in the past that i dont think we ever tracked as a futrue use of placemetn | 14:59 |
| cdent | sounds workable | 15:04 |
| cdent | although with all these dynamic power consumption tools, placement's relatively static approach may not reflect reality well | 15:04 |
| sean-k-mooney | yes perhaps although the usecase was based aroudn the idea of worst case power useage and fault tolerance so haveing rough metric of 3W per core and a static allocaiton in the falvor for that worst case vaule was suffient for this usecase | 15:12 |
| sean-k-mooney | this was a converstion i had almost 2 years ago at this point and we recommend modeling the falut domains as nova AZs and left teh capasity based scudling as an open questoin at that time | 15:14 |
| sean-k-mooney | a static aproach like we do for bandwith based scudling can get you a long way | 15:14 |
| cdent | if strict adherence to reality doesn't matter, then it ought to work just fine | 15:14 |
| cdent | jinxish | 15:14 |
| sean-k-mooney | :) | 15:14 |
| cdent | bauzas, sean-k-mooney : I recall one or both of you talking about devstack not cleaning up after itself properly and thus making placement-api (amongst other things) appear to not start. Did either of you ever make a patch or bug to devstack? | 15:17 |
| sean-k-mooney | cdent: no i didnt | 15:17 |
| bauzas | cdent: well, it was coming from an upgrade | 15:18 |
| bauzas | AFAIR | 15:18 |
| sean-k-mooney | and its still a thing | 15:18 |
| sean-k-mooney | it comes from switch branchs | 15:18 |
| bauzas | AFAIR, apache files were remaining | 15:18 |
| cdent | yes, that's what I recall too | 15:18 |
| sean-k-mooney | if you deploy an older barnch e.g. rocky and then change to master we change the name of the wsgi script | 15:18 |
| sean-k-mooney | but we did not regenerate teh apache config to point to the new one | 15:18 |
| sean-k-mooney | so we should basically always nuke the virtual host config for palcement on each stack and generate it cleanly | 15:19 |
| sean-k-mooney | i belive the current code only create the file if it does not exist or somthing like that | 15:19 |
| sean-k-mooney | that said this would seam to imply that is what it would do | 15:21 |
| *** cdent has quit IRC | 15:28 | |
| sean-k-mooney | looking at the devstack code i think it should be clean up after iteself but the issue might be that we are not restrating apache or somthing similar | 15:28 |
| *** cdent has joined #openstack-placement | 15:29 | |
| sean-k-mooney | so this https://github.com/openstack/devstack/blob/a5176e6f921f0aaa1493e146fee31f28bf6bdd64/lib/placement#L156-L162 might be the issue | 15:29 |
| cdent | sean-k-mooney: I think it is more that https://github.com/openstack/devstack/blob/a5176e6f921f0aaa1493e146fee31f28bf6bdd64/lib/placement#L64 either never gets called, or if it does, needs to remove nova-placement-api.conf | 15:30 |
| sean-k-mooney | i think we do somting weird in devstack where we still use apache for tls termination then delegate to uwsgi | 15:30 |
| sean-k-mooney | hum its called in clean but not in unstack | 15:31 |
| sean-k-mooney | but even so i think we shoudl be updating the file correctly on stack but we dont restart apatch so it never picks it up if we are usign uwsgi | 15:31 |
| cdent | run_process, when uwsgi is involved, sets up the systemd unit file and the necessary apache config. what the code you're pointing at is for when uwsgi is not used (which you have to try really hard to accomplish and isn't advise) | 15:32 |
| *** ttsiouts has joined #openstack-placement | 15:32 | |
| cdent | the error I've seen more recently is that nova-placement-api.conf isn't removed and taked precedence | 15:32 |
| cdent | anyway, I think there are multiple fixups that could happen | 15:33 |
| *** helenafm has quit IRC | 15:33 | |
| sean-k-mooney | ya i think so too | 15:33 |
| *** cdent has quit IRC | 15:35 | |
| openstackgerrit | Merged openstack/placement stable/stein: Skip _exclude_nested_providers() if not nested https://review.opendev.org/659200 | 15:36 |
| *** cdent has joined #openstack-placement | 15:41 | |
| efried | cdent: I'm asking Draven if she would be willing to draw an openstack-themed Australian magpie garçon | 15:47 |
| cdent | woot! | 15:47 |
| efried | cdent: But I thought openstack had someone who did that for us | 15:48 |
| efried | Like, when we did the powervm one, we found an image on google (of a real silverback) and sent it over, and they did the rest. | 15:49 |
| *** ttsiouts has quit IRC | 15:50 | |
| *** e0ne has quit IRC | 15:50 | |
| *** e0ne has joined #openstack-placement | 15:50 | |
| cdent | when I've asked about I get directed to existing stickers | 15:51 |
| cdent | so I figured ask around | 15:51 |
| efried | hmph | 16:12 |
| sean-k-mooney | placement project sticker/logo? | 16:26 |
| sean-k-mooney | or something else | 16:26 |
| *** dklyle has quit IRC | 16:31 | |
| *** dklyle has joined #openstack-placement | 16:37 | |
| *** e0ne has quit IRC | 17:07 | |
| *** dklyle has quit IRC | 17:29 | |
| openstackgerrit | Merged openstack/os-resource-classes master: Replace git.openstack.org URLs with opendev.org URLs https://review.opendev.org/658519 | 17:32 |
| *** ttsiouts has joined #openstack-placement | 17:35 | |
| *** tssurya has quit IRC | 17:47 | |
| *** dklyle has joined #openstack-placement | 17:49 | |
| *** dklyle has quit IRC | 17:56 | |
| *** e0ne has joined #openstack-placement | 18:10 | |
| *** e0ne has quit IRC | 18:13 | |
| *** dklyle has joined #openstack-placement | 18:20 | |
| openstackgerrit | Matt Riedemann proposed openstack/osc-placement stable/queens: Migrate legacy-osc-placement-dsvm-functional job in-tree https://review.opendev.org/556635 | 18:27 |
| *** ttsiouts has quit IRC | 18:27 | |
| *** ttsiouts has joined #openstack-placement | 18:43 | |
| *** ttsiouts has quit IRC | 18:48 | |
| *** dklyle has quit IRC | 19:01 | |
| *** cdent has quit IRC | 19:02 | |
| *** tssurya has joined #openstack-placement | 19:02 | |
| *** e0ne has joined #openstack-placement | 19:17 | |
| efried | sean-k-mooney: yeah, placement project sticker/mascot/logo, see ML. | 19:40 |
| *** e0ne has quit IRC | 19:56 | |
| *** e0ne has joined #openstack-placement | 19:59 | |
| *** e0ne has quit IRC | 20:28 | |
| *** dklyle has joined #openstack-placement | 20:39 | |
| *** ttsiouts has joined #openstack-placement | 20:45 | |
| *** dklyle has quit IRC | 21:14 | |
| *** ttsiouts has quit IRC | 21:16 | |
| *** dklyle has joined #openstack-placement | 21:29 | |
| *** dklyle has quit IRC | 22:00 | |
| *** takashin has joined #openstack-placement | 22:01 | |
| *** artom has quit IRC | 22:11 | |
| *** ttsiouts has joined #openstack-placement | 22:32 | |
| *** mriedem has quit IRC | 22:51 | |
| *** ttsiouts has quit IRC | 23:06 | |
| *** tssurya has quit IRC | 23:32 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!