| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-08 | |||
| 07:53:56 | jichen | claudiub: hi, could you please point me the libvirt patch you mentioned in the PTG? | |
| 07:54:34 | openstackgerrit | Marcin Juszkiewicz proposed openstack/nova master: Allow to configure amount of PCIe ports https://review.openstack.org/545034 | |
| 08:03:02 | claudiub | jichen: hello. sure: https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/instance-live-resize | |
| 08:03:36 | jichen | claudiub: got it , thanks~ | |
| 08:04:13 | odyssey4me | mriedem dansmith we only hit the issue with the RPC versioning on master, not queens | |
| 08:22:09 | openstackgerrit | sahid proposed openstack/nova master: libvirt: slow live-migration to ensure network is ready https://review.openstack.org/497457 | |
| 09:06:50 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: nova-manage db archive_deleted_rows is not multi-cell aware https://review.openstack.org/507486 | |
| 09:10:52 | bauzas | good morning folks | |
| 09:12:25 | Spazmotic | Mornin bauzas | |
| 09:22:28 | openstackgerrit | Ritesh proposed openstack/nova master: Consider default_schedule_zone = None as None Type https://review.openstack.org/550418 | |
| 09:23:33 | tssurya | good morning bauzas; there is an easy doc change patch here : https://review.openstack.org/#/c/550600/ which if you have time could you have a look ? it has one +2 | |
| 09:23:46 | bauzas | tssurya: sure thing | |
| 09:23:57 | bauzas | stephenfin: gibi: FWIW, I'll be on PTO today afternoon | |
| 09:24:01 | tssurya | bauzas: thanks | |
| 09:24:09 | stephenfin | ack | |
| 09:24:11 | bauzas | stephenfin: guess for what... | |
| 09:24:18 | bauzas | :p | |
| 09:24:25 | stephenfin | bauzas: Day on the beach? | |
| 09:24:40 | stephenfin | ;) | |
| 09:24:54 | bauzas | ahah | |
| 09:25:11 | bauzas | yeah, taking the sun on the s/beach/mountain | |
| 09:26:48 | bauzas | just sayin' https://www.regus.fr/office-space/france/grenoble/grenoble-meylan | |
| 09:32:19 | hrw | Grenoble. wind city | |
| 09:32:46 | hrw | bauzas: can I ask you for a favour? | |
| 09:33:08 | bauzas | hrw: hell no, Grenoble is not a windy city | |
| 09:33:10 | hrw | bauzas: fridge magnet from Grenoble for my collection. Will paypal costs | |
| 09:33:28 | bauzas | hrw: heh, you wanna a fridge magnet ? | |
| 09:33:31 | hrw | bauzas: was there once. 2009 elc/e. was so windy that I came back home with terrible flu | |
| 09:33:40 | hrw | bauzas: have over 100 of them ;d | |
| 09:33:52 | hrw | bauzas: http://bit.ly/HrwMagnets | |
| 09:34:31 | bauzas | hrw: seriously? I'm surprised to know you had a windy time | |
| 09:34:38 | bauzas | because of the mountains | |
| 09:35:26 | hrw | bauzas: bad luck | |
| 09:35:43 | hrw | bauzas: but despite that I enjoyed a visit. | |
| 09:36:08 | hrw | 'je ne parle france' was my favorite sentence (as always in France) | |
| 09:36:30 | bauzas | hrw: we have a tech conf on January http://snowcamp.io | |
| 09:36:45 | bauzas | no travel budget for speakers, but you can propose something :) | |
| 09:38:04 | hrw | bauzas: first CfP have to start ;D | |
| 09:38:58 | hrw | bauzas: it may conflict with devconf.cz 2019 which is more important for me | |
| 09:39:11 | bauzas | yeah last time it conflicted | |
| 09:39:33 | bauzas | hrw: so you'd like a fridge magnet ? I'll see what I can do | |
| 09:40:37 | hrw | bauzas: https://photos.app.goo.gl/a0I4pZSPBhABIA9R2 is my fridge after SnowpenStack | |
| 09:40:50 | hrw | 101 magnets | |
| 09:41:21 | bauzas | wow | |
| 09:42:27 | hrw | and that's from places I was. on a side I have a few from places I was not but someone brought me magnet. | |
| 09:42:36 | bauzas | hrw: I guess next time you want a new kitchen, having the fridge being integrable is not something you'd accept :p | |
| 09:42:59 | hrw | bauzas: few layers of magnetic paint on a wall instead | |
| 09:49:43 | hrw | ok, mail about missing ones sent to next conference ml ;D | |
| 10:07:41 | gibi | bauzas: ack | |
| 10:21:32 | bhagyashris | johnthetubaguy: Hi, are you around? | |
| 10:29:56 | stephenfin | bauzas: Think you could push this one through? It's been around for a long time https://review.openstack.org/#/c/407173/ | |
| 10:30:45 | stephenfin | bauzas: ....and ideally look at the other one in the series, if you have a chance :) https://review.openstack.org/#/c/407174/ | |
| 10:35:47 | openstackgerrit | Stephen Finucane proposed openstack/nova master: crypto: Remove unused functions https://review.openstack.org/550772 | |
| 10:35:47 | openstackgerrit | Stephen Finucane proposed openstack/nova master: ca: Remove 'nova/CA' directory https://review.openstack.org/550773 | |
| 10:35:48 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Remove 'nova.crypto' opts https://review.openstack.org/550774 | |
| 10:39:38 | p_d | Can we check data on https packets by using wireshark?? | |
| 10:48:14 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Transform instance.exists notification https://review.openstack.org/403660 | |
| 10:58:48 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add CPUWeigher https://review.openstack.org/379525 | |
| 11:13:17 | openstackgerrit | Merged openstack/nova master: Update the nova-manage db archive_deleted_rows description https://review.openstack.org/550600 | |
| 11:26:08 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: nova-manage db archive_deleted_rows is not multi-cell aware https://review.openstack.org/507486 | |
| 11:35:50 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: cleanup evacuated instances not on hypervisor https://review.openstack.org/512623 | |
| 11:47:57 | openstackgerrit | Merged openstack/os-vif master: Update links in README https://review.openstack.org/548385 | |
| 11:52:04 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: nova-manage db archive_deleted_rows is not multi-cell aware https://review.openstack.org/507486 | |
| 12:31:54 | jaypipes | bauzas, melwitt, gibi, dansmith: seems like this is an easy one to approve: https://review.openstack.org/#/c/548903/2 | |
| 12:38:22 | tssurya | mriedem: does https://bugs.launchpad.net/nova/+bug/1753833 need a regression test case (meaning inside functional/regressions) or will a normal one do which checks if the exception is handling correctly or not? | |
| 12:38:23 | openstack | Launchpad bug 1753833 in OpenStack Compute (nova) queens "archive_deleted_rows --until-complete stops if api database is not configured" [Medium,Triaged] - Assigned to Surya Seetharaman (tssurya) | |
| 12:52:27 | gibi | jaypipes: I'm +1 on that spec, but I cannot approve it as I'm not in the spec-core group | |
| 12:53:35 | jaypipes | gibi: k, np, thanks for looking at it. | |
| 12:59:12 | alex_xu_ | gibi: for https://review.openstack.org/#/c/502306/15/specs/rocky/approved/bandwidth-resource-provider.rst@134, you can't check the port whether includes resource, since that is the case creating server with networks. | |
| 13:00:08 | gibi | alex_xu_: I mean checking the port _after_ nova created the port in the network | |
| 13:00:22 | gibi | alex_xu_: this of course means that the boot will fail in the compute | |
| 13:01:26 | alex_xu_ | gibi: ah, i see, that works except it really fail late | |
| 13:02:17 | gibi | alex_xu_: yes, it is late and that is not optimal. But the whole create the port in the compute is not optimal | |
| 13:02:42 | gibi | alex_xu_: I would say it is temporary until we move the port create to conductor | |
| 13:03:06 | alex_xu_ | gibi: yea, with port create to conductor that can be resolved | |
| 13:05:15 | alex_xu_ | gibi: another thing is about the upgrade case, if the check at nova-compute, the new node will failed to create, the old node will success | |
| 13:05:41 | alex_xu_ | but i think it is ok | |
| 13:09:09 | gibi | alex_xu_: yeah, that will be a bit strange too | |
| 13:09:30 | gibi | alex_xu_: but it is all due to not having information at scheduling time | |
| 13:09:41 | gibi | alex_xu_: which is again due to the port create beeing too late | |
| 13:17:13 | alex_xu_ | gibi: yea, agree | |
| 13:17:56 | gibi | alex_xu_: I'm planning to update the spec tomorrow to reflect the review comments so far | |
| 13:23:44 | stephenfin | jaypipes: Fancy getting this one through? https://review.openstack.org/#/c/407173/ | |
| 13:29:17 | jaypipes | stephenfin: did you see tetsuro and sean-k-mooney's suggestions on the exception message? I think those are good suggestions. | |
| 13:29:47 | stephenfin | jaypipes: I...did not :) I'll rework sharpish | |
| 13:30:26 | sean-k-mooney | jaypipes: stephenfin it was more of a nit form my perspective but tetsuro was correct regading where the limit comes form | |
| 13:30:37 | jaypipes | stephenfin: I am going to make another suggestion on the exception message... gimme a sec? | |
| 13:30:46 | stephenfin | jaypipes: Go for it | |
| 13:31:16 | sean-k-mooney | als its thrusday so dont need that away message anymore | |
| 13:36:41 | cdent | seems a sane summary jaypipes, thanks | |
| 13:38:53 | sean-k-mooney | jaypipes: gibi i taught of one edge case for bandwidth based schduling via placement that i dont think was discussed at the ptg or in the spec. | |
| 13:41:03 | sean-k-mooney | jaypipes: gibi today we dont have a way to require specific resouce classes to be claimed as a pair. e.g. we can enforce that an allocation from the vf inventory also allocates form the bandwith inventory. as such we might need to build on dansmith's prefilter work to enforce that somehow | |
| 13:42:16 | sean-k-mooney | maybe we can use a trait such as "requires_bandwidth" on the RP but we also dont have a required traits concept to allocate form a RP | |
| 13:42:25 | jaypipes | stephenfin: k, done | |
| 13:43:05 | jaypipes | sean-k-mooney: that's what efried's granular request groups stuff is all about. | |
| 13:43:37 | sean-k-mooney | jaypipes: yes but it wont prevent a request for just the vf from being allocated form the same rp without a request for bandwidth | |
| 13:43:50 | jaypipes | sean-k-mooney: sure it would. | |
| 13:44:11 | sean-k-mooney | how? | |
| 13:44:22 | jaypipes | sean-k-mooney: the request would just be for SRIOV_NET_VF and NET_INGRESS_BYTES_PER_SECOND in the same request group. | |
| 13:44:59 | sean-k-mooney | yes and how do i prevent a differnet instance form getting a vf by only requesting SRIOV_NET_VF | |