Earlier  
Posted Nick Remark
#openstack-nova - 2018-03-08
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: 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

Earlier   Later