| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-08 | |||
| 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: ca: Remove 'nova/CA' directory https://review.openstack.org/550773 | |
| 10:35:47 | openstackgerrit | Stephen Finucane proposed openstack/nova master: crypto: Remove unused functions https://review.openstack.org/550772 | |
| 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 | |
| 13:45:06 | sean-k-mooney | without NET_INGRESS_BYTES_PER_SECOND | |
| 13:45:17 | jaypipes | sean-k-mooney: forbidden traits maybe? | |
| 13:45:39 | sean-k-mooney | jaypipes: what would you forbid? | |
| 13:45:58 | jaypipes | sean-k-mooney: probably the CUSTOM_PHYSNET_BLAH traits. | |
| 13:46:00 | edleafe | sean-k-mooney: wouldn't that be an operator decision? I.e., don't create flavors without both together? | |
| 13:46:01 | alex_xu_ | gibi: cool, thanks for the update | |
| 13:46:27 | sean-k-mooney | edleafe: the request is comeing from the neutron port not the flavor | |
| 13:46:44 | sean-k-mooney | jaypipes: that would prevent the SRIOV_NET_VF and NET_INGRESS_BYTES_PER_SECOND requst from working | |
| 13:48:50 | jaypipes | sean-k-mooney: not sure I follow you... | |
| 13:49:14 | sean-k-mooney | jaypipes: one way to support this would be to introduce a new concept the placement api which allow you per RP to discibe a set of resouces from its invenotries that would be allocated to gether. | |
| 13:49:35 | sean-k-mooney | let me start over | |
| 13:49:48 | openstackgerrit | Bence Romsics proposed openstack/osc-placement master: New dict format of allocations (v1.11, v1.12) https://review.openstack.org/542819 | |
| 13:49:49 | openstackgerrit | Bence Romsics proposed openstack/osc-placement master: Add nested resource providers (v1.14) https://review.openstack.org/546675 | |
| 13:49:49 | openstackgerrit | Bence Romsics proposed openstack/osc-placement master: Transactionally update allocations (v1.13) https://review.openstack.org/546674 | |
| 13:49:50 | openstackgerrit | Bence Romsics proposed openstack/osc-placement master: Allocation candidates parameter: required (v1.17) https://review.openstack.org/548326 | |
| 13:49:50 | openstackgerrit | Bence Romsics proposed openstack/osc-placement master: Limit allocation candidates (v1.15, v1.16) https://review.openstack.org/548043 | |
| 13:50:03 | sean-k-mooney | we have 1 RP with 2 inventories SRIOV_NET_VF and NET_INGRESS_BYTES_PER_SECOND | |
| 13:50:58 | sean-k-mooney | to allow minium bandwith gurantees i need to ensure that vf for the SRIOV_NET_VF are only allocated if NET_INGRESS_BYTES_PER_SECOND allocation are also made | |
| 13:51:33 | sean-k-mooney | if i dont i can over subsribe on bandwith as the bandwith for the extra vf are not tracked by placement | |
| 13:53:07 | jaypipes | sean-k-mooney: this is kind of why I said that I preferred allocations to be done atomically... | |
| 13:54:29 | sean-k-mooney | jaypipes: but the issue is that the 2 allocation on for SRIOV_NET_VF and NET_INGRESS_BYTES_PER_SECOND and the second for SRIOV_NET_VF are two different boot requests | |
| 13:55:03 | gibi | sean-k-mooney: did this section answers your question? https://review.openstack.org/#/c/502306/15/specs/rocky/approved/bandwidth-resource-provider.rst@260 | |
| 13:55:41 | gibi | nova meeting starts in 5 minutes | |
| 13:55:55 | sean-k-mooney | gibi: not quite as there is noting in placement to prevent a request with no traits but SRIOV_NET_VF comming from that RP | |
| 13:56:30 | sean-k-mooney | gibi: basically we would need to tag RP with reqiured traits. not have a per request required traits paramater | |
| 13:56:35 | gibi | `CUSTOM_GUARANTEED_BW_ONLY` and `CUSTOM_BEST_EFFORT_BW_ONLY` to the network | |
| 13:56:35 | gibi | sean-k-mooney: The Neutron agent can put traits, like | |
| 13:56:38 | gibi | RPs to indicate which physical port belongs to which group. Neutron can offer | |