Tuesday, 2019-04-16

*** tetsuro has joined #openstack-placement00:17
*** e0ne has joined #openstack-placement04:53
*** e0ne has quit IRC04:56
*** e0ne has joined #openstack-placement05:21
*** e0ne has quit IRC05:25
*** prometheanfire has joined #openstack-placement05:59
prometheanfireso... do I need to do anything to migrate from nova_placement to standalone placement (rocky -> stein)05:59
prometheanfirefound docs06:01
prometheanfireI notice that there's no way to migrate postgres?06:18
*** vdrok has quit IRC06:28
*** belmoreira has joined #openstack-placement06:31
*** belmoreira has quit IRC06:56
*** vdrok has joined #openstack-placement06:58
*** belmoreira has joined #openstack-placement06:58
*** belmoreira has quit IRC06:58
*** belmoreira has joined #openstack-placement07:00
prometheanfiredumped nova-api and imported one at a time, a note that would have been nice to know is to not run the db_sync on initial install if migrating07:00
*** e0ne has joined #openstack-placement07:06
*** e0ne has quit IRC07:09
*** e0ne has joined #openstack-placement07:16
*** tssurya has joined #openstack-placement07:29
*** helenafm has joined #openstack-placement07:40
*** e0ne has quit IRC07:52
*** e0ne has joined #openstack-placement07:58
*** e0ne has quit IRC07:59
*** e0ne has joined #openstack-placement08:10
*** ttsiouts has joined #openstack-placement08:21
openstackgerritPawel Baclawski proposed openstack/osc-placement master: Add support for 1.22 microversion  https://review.openstack.org/65178308:32
*** belmoreira has quit IRC08:41
*** belmoreira has joined #openstack-placement08:43
bauzasmmm, silly question maybe but do we have a way in placement to say 'preferred trait' and not required ?09:23
bauzasI only see 'required' but I wasn't really paying attention whether someone worked on the preferred trait thing09:24
bauzashttp://specs.openstack.org/openstack/nova-specs/specs/stein/approved/placement-mixing-required-traits-with-any-traits.html gives me what I want09:29
*** ttsiouts has quit IRC10:23
*** ttsiouts has joined #openstack-placement10:24
*** ttsiouts has quit IRC10:28
*** belmoreira has quit IRC10:35
*** cdent has joined #openstack-placement10:39
*** belmoreira has joined #openstack-placement10:51
*** ttsiouts has joined #openstack-placement11:02
*** tetsuro has quit IRC11:37
*** belmoreira has quit IRC11:41
*** cdent has quit IRC11:42
*** belmoreira has joined #openstack-placement11:43
*** nguyenhai has joined #openstack-placement11:47
*** nguyenhai has quit IRC11:52
*** cdent has joined #openstack-placement12:23
*** belmoreira has quit IRC12:28
*** belmoreira has joined #openstack-placement12:33
*** belmoreira has quit IRC12:59
*** mriedem has joined #openstack-placement13:21
*** egonzalez has quit IRC13:30
*** egonzalez has joined #openstack-placement13:30
*** efried_pto is now known as efried13:31
efriedcdent: Did you see stuff from prometheanfire ~7.5h ago?13:32
efriedprometheanfire: If your experience suggests improvements to the docs, please do propose same.13:32
cdentefried: i did not no13:33
* cdent looks at logs13:33
cdenthmm, interesting13:34
cdent[t cNNb]13:34
purplerbot<prometheanfire> I notice that there's no way to migrate postgres? [2019-04-16 06:18:46.671440] [n cNNb]13:34
cdentpostgres is mentioned in https://docs.openstack.org/placement/latest/upgrade/to-stein.html13:35
*** belmoreira has joined #openstack-placement13:35
cdentprometheanfire: if/when you come back, a bit more detail on where things went wrong would be most welcome13:36
cdentIf I'm not here, a storyboard story in openstack/placement would also be welcome13:37
openstackgerritsean mooney proposed openstack/os-traits master: add libvirt image metadata traits  https://review.openstack.org/65299613:43
sean-k-mooneyim not sure if i have everting right in terms of tracking in ^13:44
sean-k-mooneybut its on the correct topic branch for the nova spec/bluprint and i have the os-tratis story and task added13:45
cdentsean-k-mooney: If it's not right, someone will notice and say so and it will get fixed eventually, nbd13:45
sean-k-mooneyi just noticed os-tratis apprently has unit tests? do you alway need to add test for new traits? i assume not13:46
cdentsean-k-mooney: they can be useful as a sanity check, but we've not been strict about requiring them13:54
sean-k-mooneyok the new traits i was defiening are just constants so i was wondering wny they were needed beyond a generic set13:55
cdentsean-k-mooney: see: https://review.openstack.org/#/c/648147/ where the first patch, had it unit tests, would have caught the problem that I caught in review13:58
cdenthowever, I did catch it in review, so not a serious issue13:59
* cdent will be back later14:01
sean-k-mooneyok if people are ok with the general name im chossing i can add some. it would be nice if there was a test or a tox env to print all the traits jsut so you can do a visual inspection simpely14:01
cdentthat's a good idea14:01
*** cdent has quit IRC14:01
sean-k-mooneyi might write one14:01
sean-k-mooneylike the nova/oslo object tests14:02
sean-k-mooneythen when you add a new trait just adde it to the expect set14:02
sean-k-mooneyand that way you can be sure the name is correct14:02
*** amodi has joined #openstack-placement14:05
*** belmoreira has quit IRC14:13
*** belmoreira has joined #openstack-placement14:16
*** ttsiouts has quit IRC14:23
*** ttsiouts has joined #openstack-placement14:24
*** ttsiouts has quit IRC14:27
*** ttsiouts has joined #openstack-placement14:28
*** dklyle has quit IRC14:49
*** dklyle has joined #openstack-placement14:50
*** helenafm has quit IRC14:57
*** cdent has joined #openstack-placement15:05
*** e0ne has quit IRC15:31
*** belmoreira has quit IRC15:35
cdentdansmith, melwitt: Since you've both expressed some interest/concern in the topic of partitioning placement in various ways, if you get a chance to comment in the threads starting at http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004721.html and http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004720.html that would be extra good15:51
melwittcdent: ack, been meaning to reply but haven't gotten around to it yet15:52
cdentcool, thank15:52
*** ttsiouts has quit IRC15:59
*** ttsiouts has joined #openstack-placement15:59
*** ttsiouts has quit IRC16:04
dansmithcdent: done16:23
*** tssurya has quit IRC16:47
*** e0ne has joined #openstack-placement17:32
*** dklyle has quit IRC17:45
*** e0ne has quit IRC17:49
cdentdansmith: thanks for staying on that allocation/consumer-type stuff. I can probalby come up with more to say but I'm going to wait on jaypipes to weigh in with whatever opinions he's got. generall, yeah, seems alright17:58
prometheanfirecdent: I missed that link ( https://git.openstack.org/cgit/openstack/placement/plain/tools/postgresql-migrate-db.sh ), heh, hope I migrated fine by hand (I initialized the placement DB then dumped the nova_api DB, only importing the tables found in the placement DB from the dump)18:10
cdentprometheanfire: that ought to work just fine, assuming services were down18:10
cdentis there a place where we can make things more clear?18:10
prometheanfirecdent: I don't think so, it was just late late night so I didn't ctrl+f on the page18:11
cdentI know how that can be18:11
jaypipescdent: I'm on board with dansmith's opinions.18:12
jaypipesdansmith: excellent point about the migrations. I totally forgot about that.18:13
prometheanfiredecided to start upgrade/installing stein at about midnight, finished at about 2AM18:13
cdentjaypipes: the main question I had was with regard to different deployments of nova using different consumer types. that feels potentially icky18:13
prometheanfirethere was one column missing in a placement db table that was in a nova_api one though18:13
cdentprometheanfire: which one was that?18:14
jaypipescdent: are you asking whether I think we should define a set list of consumer types or leave it as a free-form text field? :)18:17
prometheanfireand since I initialized the placement db I had to delete some defaults that were diferent in nova_api18:18
cdentjaypipes: that is the root yes18:18
prometheanfirelookin up, forget offhand18:18
jaypipescdent: my general preference is for cleanliness and consistency, so I would prefer a set list of consumer types. that said, I can understand dansmith's trepidation about encoding such things early on.18:18
jaypipesI'm torn :)18:19
cdentjaypipes: or from a different if the concept of an 'instance' type consumer is independent of "nova"18:19
dansmithjaypipes: yeah, I know, but I'm thinking about how we end up with open-ended resource classes in ironic, which makes me hesitate to go the enum route18:19
jaypipesdansmith: ack18:19
dansmithcdent: since nova already has two of its own types, I would say nova != instance18:20
jaypipesdansmith: as in "ironic instance" and "VM instance" or do you mean "instance" vs. "migration"?18:20
dansmithalso, nova's resources for an instance, and ironic's accounting of things it has promised to nova (which could be used for an instance or not) would be different18:20
cdentdansmith: that's not quite what I meant. it's more can two different things (a nova and something else): create an "instance"18:21
dansmithjaypipes: in the nova case I mean instance vs migration18:21
prometheanfirecdent: can_host column in resource_providers18:21
cdentprometheanfire: ah yeah, that's an orphan that just sort of got aged out18:21
dansmithcdent: well, if I'm using bifrost and I want to call it an instance, it's very very similar to what nova calls an instance18:21
prometheanfireyep, this is an OLD install18:21
jaypipesprometheanfire: heh, yeah, you can ignore that.18:21
jaypipesprometheanfire: that's edleafe's fav field.18:22
prometheanfireI did ignore it18:22
cdentdansmith: yes, but if it is about controlling quota does overlap matter? there were questions along those lines earlier in the thread18:22
dansmithcdent: well, assuming the owner is doing the quota enforcement, I think it's up to that service18:23
dansmithcdent: it's why I think it's important for the provider sharding to be different18:23
cdent(as in, why do we even care if this vcpu is a nova instance or not, if the user has vcpu quota, isn't that global)18:23
dansmithcdent: because they would almost definitely have different quota for nova-provided vcpu quota than something else,18:24
dansmithlike if something like oVirt was also using placement to track basically the same type of thing,18:24
dansmithbut the cost (and thus quota) is very different18:24
dansmithsame thing for PCPU provided by nova vs. ironic18:24
cdentso if keystone is a limits provider, it has to know about consumer types too?18:25
cdentwhy not?18:25
dansmiththe limits are interpreted by the services18:25
prometheanfiremy only suggestion for the migration docs is to note that you should not initialize the placement db before running them (as it sets up defaults which have to be manually cleared before the tables import)18:25
dansmithnot every quota limit maps directly (or even indirectly) to a resource in placement18:26
cdentdansmith: but we're saying there are different limits for different types18:26
dansmith(nor should it)18:26
dansmithcdent: right, but they're translated through a service between keystone and placement18:26
cdentdansmith: I know, I'm asking "how would the that intermediate service distinguish?"18:26
dansmiththose limits are scoped by region right?18:27
cdentprometheanfire: would fantabulous if you could create a story in https://storyboard.openstack.org/#!/project/openstack/placement and tag it docs18:27
cdentso we're saying you have to be in a different region to have two different types of vcpu limit?18:28
cdent(which maybe is fine)18:28
dansmithfor two distinct novas you *would* be a different region by definition, so .. yeah I think so18:28
prometheanfirecdent: k, I'll do so18:28
dansmithbut even still, I'd say how the service decides to count the quotas based on usage within its shard of placement is it's deal18:29
cdentprometheanfire: thanks very much18:29
cdentdansmith: yeah, the scenario I'm trying to understand more fully or if it even is a scenario is one shard with N>1 services that want to count similar (or even) the same thing18:31
dansmithto be in the same shard, I think they'd need to be collaborative and non-overlapping, like nova+neutron+cinder+ironic18:33
cdentwfm. I'm just trying to be sure we don't walk it an "oh damn we forgot ... " corner18:34
*** irclogbot_0 has quit IRC18:39
*** irclogbot_0 has joined #openstack-placement18:41
prometheanfirecdent: https://storyboard.openstack.org/#!/story/2005465 there you go, a bug based on my bad memory of being up too late18:41
cdentawesome, thanks18:41
melwittcdent: your reply "In any given deployment, collaborating services (like nova, neutron, ironic, cinder) would need to agree on how they are not overlapping." makes the idea of having enums in somewhere in placement more appealing19:25
cdentmelwitt: I thought it might19:25
cdentbut I was trying to reflect the above chat with dansmith as close as possible19:25
melwitton the ability to specify more than one consumer type for a /usages query, yes please for quotas. or in the rollup response to have different consumer types differentiated would work too19:26
dansmithI'm replying about that right now19:26
cdentplease feel free to join the thread, I'm going to disappear from irc pretty soon and we've got plenty of time to flesh things out19:26
melwittcdent: yeah, I think you did. just saying when I read it I was like "oh"19:26
cdent(I've moved on to the rp sharing thread and then need to be more engaged at home)19:27
melwittwill do19:27
dansmithmelwitt: if placement codifies that enum, it just means that any new arrangement of services has to be "blessed" by placement, unless we want yet another magic CUSTOM_ prefix namespace19:27
melwittyeah. guess there's some downsides either way19:28
*** dklyle has joined #openstack-placement19:58
*** ttsiouts has joined #openstack-placement20:44
* cdent waves20:50
*** cdent has quit IRC20:50
*** ttsiouts has quit IRC22:10
*** ttsiouts has joined #openstack-placement22:11
*** ttsiouts has quit IRC22:12
prometheanfirewell, nova is having problems with the new placement it looks like, not sure if I should post here or there23:36
prometheanfire2019-04-16 18:38:51.253 15418 INFO placement.requestlog [req-ab04a65e-c2b0-49dc-a3e0-40954257b351 e589d5a63cf245f381869ee8cb7ca092 48ddb9bf27c342e8a9640fe4e526519f - default default] "PUT /traits/COMPUTE_NET_ATTACH_INTERFACE" status: 400 len: 402 microversion: 1.623:39
prometheanfirebottom section, maybe missing traits for stein? https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html23:42

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!