Wednesday, 2021-06-02

*** whoami-rajat has quit IRC00:20
*** LinPeiWen has joined #openstack-nova00:44
*** rloo has quit IRC00:46
melwittgmann: I added a very late reply on https://review.opendev.org/c/openstack/nova/+/762013 if you could look at your convenience this week00:57
gmannmelwitt: sure, will check tomorrow.00:58
*** LinPeiWen has quit IRC00:58
*** LinPeiWen has joined #openstack-nova00:58
melwittcool thx00:59
*** LinPeiWen has quit IRC00:59
*** LinPeiWen has joined #openstack-nova00:59
*** LinPeiWen has quit IRC01:00
*** LinPeiWen has joined #openstack-nova01:00
*** LinPeiWen has quit IRC01:14
*** LinPeiWen has joined #openstack-nova01:14
opendevreviewnorman shen proposed openstack/nova master: Saving security group to info_cache  https://review.opendev.org/c/openstack/nova/+/78634801:34
*** abhishekk has joined #openstack-nova04:39
*** abhishekk has quit IRC04:41
*** abhishekk has joined #openstack-nova04:41
*** hemanth_n has joined #openstack-nova04:58
*** bhagyashris_ has joined #openstack-nova05:03
*** bhagyashris has quit IRC05:10
*** vishalmanchanda has joined #openstack-nova05:14
*** bhagyashris_ has quit IRC05:47
*** ralonsoh has joined #openstack-nova06:10
opendevreviewYongli He proposed openstack/nova master: Smartnic support - cyborg drive  https://review.opendev.org/c/openstack/nova/+/77136206:11
opendevreviewYongli He proposed openstack/nova master: smartnic support - new vnic type  https://review.opendev.org/c/openstack/nova/+/77136306:11
opendevreviewYongli He proposed openstack/nova master: smartnic support  https://review.opendev.org/c/openstack/nova/+/75894406:12
opendevreviewYongli He proposed openstack/nova master: smartnic support - reject server move and suspend  https://review.opendev.org/c/openstack/nova/+/77991306:12
opendevreviewYongli He proposed openstack/nova master: smartnic support - functional tests  https://review.opendev.org/c/openstack/nova/+/78014706:12
*** bhagyashris has joined #openstack-nova06:15
*** luksky has joined #openstack-nova06:44
*** dklyle has quit IRC06:49
*** alex_xu has joined #openstack-nova07:04
*** andrewbonney has joined #openstack-nova07:19
*** bhagyashris has quit IRC07:23
*** bhagyashris has joined #openstack-nova07:23
yongliheHi, gibi, alex_xu, sean, smartnic patch set is revised, to make your day easy, here is a change list since last review:07:24
*** abhishekk has quit IRC07:24
yonglihecurrent change set:   1) drop one unnecessary cyborg call(get_arq_device_rp_uuid)07:24
yonglihe2) clean up arq: there is possible arq not bind to instance or port.07:24
yongliheaddressed in both compute and conductor stages07:24
yongliheprevious change set1:07:25
yonglihe * put the device_profile into reqeust_net(API stage), then we elimate one neutron call.07:25
yonglihe * add cyborg ARQ clean up for all sorts of failure07:25
yonglihe * clean up code logic for 2 kind of ARQ: port requested ARQ and flavor reqeust ARQ.07:25
yonglihe * functional tests07:25
yonglihe * bump compute service version number07:25
yonglihe * reject create smatnic port attached server while migration in progress07:25
alex_xuyonglihe: planning to review next around07:26
*** bhagyashris_ has joined #openstack-nova07:38
*** bhagyashris has quit IRC07:44
*** mgariepy has quit IRC07:46
*** kaisers has joined #openstack-nova08:03
*** lucasagomes has joined #openstack-nova08:14
*** nightmare_unreal has joined #openstack-nova08:16
*** lucasagomes has quit IRC08:19
*** icey has joined #openstack-nova08:20
*** derekh has joined #openstack-nova08:21
*** lucasagomes has joined #openstack-nova08:26
*** lucasagomes has quit IRC08:27
*** lucasagomes has joined #openstack-nova08:56
*** lucasagomes has quit IRC08:58
*** Luzi has joined #openstack-nova09:10
*** mgoddard_ has joined #openstack-nova09:15
lyarwoodmelwitt: https://bugs.launchpad.net/nova/+bug/1930406 - btw when you're around later can we chat about this and any workarounds you're aware of?09:17
opendevmeetLaunchpad bug 1930406 in OpenStack Compute (nova) "parallel volume-attachment requests might starve out nova-api for others" [Undecided,New]09:17
* lyarwood isn't great with uwsgi configs09:17
*** mgoddard_ is now known as mgoddard09:18
lyarwoodbut tbh I've wanted to drop the offending RPC call for a while and this might be the report that finally pushes me to remove it09:18
lyarwoodbehind a microversion09:18
lyarwoodas it changes what we return to the caller09:18
*** mgariepy has joined #openstack-nova09:19
*** abhishekk has joined #openstack-nova09:19
*** lucasagomes has joined #openstack-nova09:34
*** lucasagomes has quit IRC09:37
*** lucasagomes has joined #openstack-nova09:42
*** nightmare_unreal has quit IRC09:43
*** lucasagomes has quit IRC09:44
*** jangutter_ has joined #openstack-nova10:01
*** jangutter has quit IRC10:08
sean-k-mooney lyarwood  is it just doing the rpc for the device name which we dont even garentee inside the guest10:09
lyarwoodyeah we also create the bdm during the same call10:09
lyarwoodvia the conductor so it takes a little longer10:09
sean-k-mooneyshould we make this an async api and just make it a cast10:10
sean-k-mooneywe have been talking about rpc version compatiablity downstream for a while on an off10:12
lyarwoodwe need the BDM creation to be sync to avoid races but we can do that on the api10:12
lyarwoodand then move this device assignment behind the already async part10:12
sean-k-mooneyone thing i have been debating in my mind is shoudl we be removing all direct calls to the compute from the api10:13
lyarwoodcasts are still fine right?10:13
lyarwoodor move everything behind conductor tasks10:14
lyarwoodthe latter is lots of work10:14
sean-k-mooneyi was thinking evenutally everything goes though conductor but cast might be ok10:14
sean-k-mooneythe reasonign was so that the api does not need to speak the compute node rpc version10:15
sean-k-mooneybut ya thats a larger change then you need10:15
sean-k-mooneyhaving the api create the bdms and then cast to do the rest async shoudl be fine in this case10:16
*** ralonsoh has quit IRC10:17
gibimelwitt: when you are up, I managed to make CI green on https://review.opendev.org/c/openstack/nova-specs/+/788243 (and get bauzas +2)10:17
*** ralonsoh has joined #openstack-nova10:17
*** jangutter_ is now known as jangutter10:20
*** jangutter has quit IRC10:21
*** jangutter has joined #openstack-nova10:21
*** jangutter_ has joined #openstack-nova10:24
opendevreviewElod Illes proposed openstack/nova stable/wallaby: [stable-only] Fix ceph install in live migration hook  https://review.opendev.org/c/openstack/nova/+/79400010:25
sean-k-mooneymelwitt: gibi: quick question about consumer types. will there be an api that allows me to list all allocation by consumer types and optionall filter that10:26
sean-k-mooneyfor filtering i was thinking by host, project and maybe consumer/vm id10:27
sean-k-mooneythe reason im asking is the mailing list thread related to premptible instnaces.10:28
sean-k-mooneyone of the suggtions i had was to explore using a "premptible" consumer type for premtiable instances10:29
sean-k-mooneyinitally if we had a query api it would allow and external service to esaisly determing what instance could be killed via a placment query10:30
*** jangutter has quit IRC10:30
sean-k-mooneybut i coudl imaging later extending plamcnet so that it coudl optionalling include the capsity used by preamtiable instance in its allocation candates set with a new micorverion and query arg10:31
*** lucasagomes has joined #openstack-nova10:32
sean-k-mooneynot that im going to work on that any time soon but i just taught that would enable and intersting desgin direction to explore10:33
jkuliklyarwood, sean-k-mooney: wouldnt "having the api create the bdms" mean, that we need distributed locking between the apis, so we don't run into races while creating those?10:37
lyarwoodWe'd need rely on the DB ensuring there's only ever one active BDM for a given instance UUID and volume ID combo10:38
sean-k-mooneyjkulik: we are creating them in the db so we can do a db level lock if we needed too10:38
jkulikis multi-attach possible for the same VM?10:38
lyarwoodnot for the same instance no10:38
sean-k-mooneyjkulik: within the same vm no10:38
sean-k-mooneyif we need a lock we can take a row level lock on the instance uuid  or instance and volumne uuid pair10:39
lyarwoodtbh a constraint should be enough10:40
lyarwoodat least that's what was agreed on in the past when this came up10:40
lyarwoodbut that was in the context of us creating duplicate BDMs on failure10:41
lyarwood*failure to attach10:41
lyarwoodthat hasn't been an issue for a while now10:41
sean-k-mooneyya there is no index in the bdm that we need to worry about is there10:41
jkuliklyarwood: "for a while" - which version do I need to upgrade to? :D10:41
lyarwoodjkulik: this was way back in Kilo I think and only reported by one customer downstream10:42
lyarwoodI've never seen it since10:42
lyarwood-> lunch brb10:42
jkulikhm ... I'm on rocky and need to investigate why there are like 10 bdm entries (pretty much empty) and one filled with connection_info in my DB for multiple VMs10:42
jkuliksame (volume_id, instance_uuid)10:43
sean-k-mooneythe uniqe constrati on rocky is just the bdm uuid10:44
sean-k-mooneyhttps://github.com/openstack/nova/blob/stable/rocky/nova/db/sqlalchemy/models.py#L58710:44
sean-k-mooneythats also the case for master10:45
sean-k-mooneylyarwood: ^10:45
stephenfinbauzas: Friendly reminder that the 'instance_type' cleanup series is still waiting your attention, if you have some time https://review.opendev.org/q/topic:%2522compute_rpc_6.0%2522+status:open10:45
sean-k-mooneyso the uniqe constraint in the db i currently not enough to prevent duplicats10:45
lyarwoodjkulik: yeah the others are marked as soft deleted (deleted=id etc)10:45
lyarwoodsean-k-mooney: yup this is a new constraint I'm talking about10:45
*** martinkennelly has joined #openstack-nova10:45
sean-k-mooneyoh ok10:46
jkulikno. they're not soft-deleted10:46
sean-k-mooneywell currently the could be not marked as soft deleted10:46
sean-k-mooneyyou can have duplicate entries with the current schema10:46
lyarwoodright but that's the race I was saying we hadn't seen reported for a while10:46
sean-k-mooneyah ok10:47
lyarwoodjkulik:  what does `openstack server volume list $instance` show?10:47
*** lucasagomes has quit IRC10:47
lyarwoodjkulik:  the same duplicates?10:47
sean-k-mooneywell backportbale way to fix this is to add a db trigger on insert to enforce the constraint then on master update the uniqe constratint10:48
jkuliklyarwood: let me find such an instance again. I cleaned them up already for the customer to continue10:48
*** whoami-rajat has joined #openstack-nova10:49
lyarwoodjkulik: ah if this is outside of the instance creation flow there have been known and now resolved issues with things like live migration rollbacks etc that could cause this10:49
lyarwoodand/or volume attach flows I should say10:49
jkulikwe're on VMware, so no live-migration via Nova for us in rocky afaik. might be volume-attach flows then10:50
*** lucasagomes has joined #openstack-nova10:51
jkulikif they're fixed, I'll have a look through the commits. let's see what I can dig up. thank you10:51
stephenfinlyarwood: Replied on https://review.opendev.org/c/openstack/nova/+/794006 I wasn't hitting the code path you're expecting because I wasn't booting from volume10:52
opendevreviewsean mooney proposed openstack/nova-specs master: Add no user token when get Cyborg client  https://review.opendev.org/c/openstack/nova-specs/+/78717810:53
stephenfinthat's evidently a far less common request than boot from volume, which explains why nobody has (based on reports, anyway) hit this before10:53
jkuliklyarwood: I didn't even know "server volume list" was a thing. cool. it shows both bdm entries for the instance I found10:54
sean-k-mooneystephenfin: boot from volumen is often an optimasation fo boot form exsiting volume10:56
lyarwoodjkulik: cool, and `openstack server event list $instance` shows just attaching the volume etc?10:56
sean-k-mooneyi would expect the latter to maybe be more common for heat or horizon users where you are less likely to typo the uuid due to the indirection10:56
*** artom has quit IRC10:57
sean-k-mooneystephenfin: booting form an existing volume used to be common if you were creating the volum using an iso10:57
jkuliklyarwood: hm ... hard to say. k8s instance with lot's of attachments going on. but it looks like in this case the volume is in state error10:57
sean-k-mooneystephenfin: where boot form volume the normal way will not do what you want it too10:58
stephenfinsean-k-mooney: tbc, I'm not doing boot from volume here. I'm booting from an image and attaching an additional volume10:58
stephenfinso that's the unusual path, I think10:58
lyarwoodgood old k8s, kk then this could be an issue with the vmware driver not cleaning up correctly on failure10:58
sean-k-mooneynot really i do that all the time10:58
stephenfini.e. 'server create --image IMAGE --block-device BDM ...'10:58
sean-k-mooneythat is proably the most common use of cinder10:59
*** icey has quit IRC10:59
stephenfinclearly you're fastidious when it comes to your use of UUIDs so :)10:59
lyarwoodyeah that's a common use case, I wouldn't say the most common but it's up there10:59
sean-k-mooneyi never use the bdms direclly10:59
*** artom has joined #openstack-nova10:59
lyarwoodk8s etc boots and then attaches for example10:59
sean-k-mooneyi used to use --volume10:59
lyarwoodanyway stephenfin I think this was just missed tbh11:00
stephenfinsean-k-mooney: --volume is for a boot device though11:00
lyarwoodI got slightly confused by some output you posted in here11:00
sean-k-mooneyno its not11:00
stephenfinat least in OSC11:00
stephenfinit sets boot_index to 011:00
lyarwoodyeah --volume is shorthand for bfv in osc11:00
sean-k-mooneyok i normally use horizon for this but im pretty sure i used --volume for this too11:01
sean-k-mooneythat a pretty bad design choice then11:01
stephenfinYeah, I'm not a fan either11:01
stephenfinit should be the equivalent of '--network' and '--port', which are shorthand for various permutations of '--nic'11:01
lyarwooddidn't you have a change up to move that to --boot-volume?11:01
stephenfinnot me, that I recall11:02
lyarwoodokay I thought someone did11:02
*** belmoreira has joined #openstack-nova11:02
lyarwoodI'd be fine with that but I'm not sure how you could then reuse --volume without breaking people11:02
sean-k-mooney--bfv was porposed at one point11:02
stephenfinI guess you could consider ordering and use 'parsed_args.volumes[0]' is 'parsed_args.image_uuid' was unset?11:03
sean-k-mooneylyarwood: given osc is ment to work the same acroos multiple clouds and this would not be a micorverison change11:03
stephenfins/is/if/11:03
sean-k-mooneywe coudl only resue --volume after a major version bump11:03
stephenfinnot really, iirc using '--volume' and '--image' together currently is illegal11:04
stephenfinso we'd be loosening restrictions, not adding new ones11:04
*** mgariepy has quit IRC11:04
stephenfinif it's not it probably should be, since I can't see how specifying an image_uuid and a BDM with a boot_index of 0 would be allowed by the server11:05
sean-k-mooneyyou can use --image and --boot-from-volume <size> today that is the short hand for that11:05
* stephenfin tests11:05
stephenfinyeah, that's not what I'm describing though and it's a different thing11:05
sean-k-mooneybut i tought we could use --image and --volume today to boot form image and attach data volumes11:05
stephenfinthat'll create a new volume iirc11:06
sean-k-mooneycan we add --data-volumn11:06
stephenfinthat's kind of ugly11:06
sean-k-mooneywell if we cant reclaim --volume then its kind of the best we can do11:07
sean-k-mooneysom of the osc optionts are kind of questionable11:07
sean-k-mooneyfor example --image-property11:07
stephenfin$ openstack server create --flavor m1.tiny --image cirros-0.5.1-x86_64-disk --network private --volume test-volume test-server11:08
stephenfinopenstack server create: error: argument --volume: not allowed with argument --image11:08
stephenfinyeah, as expected you can't do that currently11:08
stephenfinso we could add it easily11:08
stephenfinif image is not specified, the first volume specified gets boot_index of 0 and the rest get -1; if it *is* specified, all volumes get boot_index of -111:09
sean-k-mooneyno11:09
sean-k-mooneyif volume and image as sprecifed the root disk is created form the image11:10
sean-k-mooneyso that has boot index 011:10
stephenfinthat would mean overwriting whatever's already on the volume, no?11:10
stephenfinthat doesn't seem like something you'd want to happen automatically11:11
sean-k-mooneyno because we would be generating the bdm11:11
sean-k-mooneyits  the only thing i would add to be honest11:11
sean-k-mooneyi dont think i would ever use what you proposed11:11
stephenfinI don't understand what you're asking for though11:12
lyarwoodsean-k-mooney: tbh I think that's pretty confusing UX11:12
lyarwoodif you provide both --image and --volume you end up with an image based volume?11:12
sean-k-mooneyno11:12
sean-k-mooneyyou end up with a image based root disk not on cinder and a data volume11:12
lyarwoodah11:13
lyarwoodsorry I misunderstood something you said above11:13
stephenfinI think I did too11:13
stephenfinsean-k-mooney: the data volume would have a boot_index of -1, no?11:13
stephenfinsince it's a data volume, not a boot volume11:13
* stephenfin assumes -1 == auto11:13
lyarwoodhaha I don't think it does11:14
sean-k-mooneywell it typically would not be set as bootable in cinder at all11:14
* lyarwood checks11:14
stephenfinso would you just not set it?11:14
sean-k-mooneyi dont know11:14
stephenfinso instead of:11:14
stephenfinif image is not specified, the first volume specified gets boot_index of 0 and the rest get -1; if it *is* specified, all volumes get boot_index of -111:14
stephenfinI should say:11:14
sean-k-mooneyi assumed -1 means last possibel11:14
sean-k-mooneyor not bootable11:14
lyarwood`To disable a device from booting, set the boot index to a negative value or use the default boot index value, which is None.`11:14
lyarwoodI've always just left it as None11:15
stephenfinif image is not specified, the first volume specified gets boot_index of 0 and the rest get nothing; if it *is* specified, no volume gets a boot_index11:15
sean-k-mooneyyes11:15
sean-k-mooneythat would work11:15
lyarwoodyup11:15
stephenfinso 'server create --image IMAGE --volume VOLUME ...' -> boot from image with an attached data volume (2 block devices)11:15
sean-k-mooneyyes11:15
stephenfinso 'server create --volume VOLUME ...' -> boot from volume (1 block devices)11:16
stephenfins/so/and/11:16
sean-k-mooneyyep11:16
lyarwoodstephenfin: does the first one use BDMs for both block devices or just the volume?11:16
stephenfinokay, cool. That's what I was thinking all along but clearly didn't word it well. That should be easily doable11:16
lyarwoodstephenfin: and provide the image via imageRef11:16
stephenfinprobably just the volume with a separate imageRed11:16
stephenfin*f11:16
lyarwoodcool11:16
stephenfinseeing as it's easier11:17
stephenfinpresumably11:17
lyarwoodI was going to say if it did bdms for both we could nuke that11:17
sean-k-mooneylyarwood: is there an advantate to use the bdm and setting the image one to local11:17
lyarwoodas yeah it's easier to use imageRef11:17
lyarwoodsean-k-mooney: no IMHO, given how weird osc already is about this stuff I was just checking it wasn't using them11:17
sean-k-mooneyack11:18
stephenfinsean-k-mooney: as for your concerns RE: --image-property: I share them https://github.com/openstack/python-openstackclient/blob/master/openstackclient/compute/v2/server.py#L812-L81411:18
stephenfinit's on the chopping block11:19
stephenfinor will be soon11:19
sean-k-mooneywell my concern was actully that we approved overriding image properties on the command line in the pass at the spec stage11:19
sean-k-mooneybut it never got implemented11:20
sean-k-mooneyso that really should not exist because if we ever revived that it would be a problem11:20
stephenfinyou really do need to play around with this stuff to realize the ugliness of some of the interactions11:20
stephenfinlots of good stuff there but so many rough edges too11:20
stephenfinsean-k-mooney: agreed11:20
sean-k-mooneyare you going to add --ephemeral11:20
stephenfinit's already there11:21
sean-k-mooneyhttps://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/virt-image-props-boot-override.html just in case people were not aware of this11:21
stephenfinI added it last cycle11:21
stephenfinOSC is effectively feature complete from a nova perspective now, IMO. The only thing I haven't done is the host evacuate commands11:22
sean-k-mooneyoh not in in the version i have installed locally then11:22
stephenfinyou need 5.5.011:22
stephenfinwhich should have been 6.0.0, since we removed stuff /o\11:22
sean-k-mooneyi just installed the latest release11:23
stephenfinthat ship has sailed though11:23
sean-k-mooneyi had 5.4.011:23
sean-k-mooneystephenfin: you could revert that and do a 5.5.111:23
stephenfingood point11:24
stephenfinI'll discuss in the SDK team meeting tomorrow11:24
sean-k-mooneystephenfin: looking at my old history it looks like i have been doing it in 3  commands volume create, boot and attach11:26
sean-k-mooneywhen i dont do it one go in horizon11:26
sean-k-mooneyoh  by the way my cloud should be back runnign for people to use again later this week11:27
sean-k-mooneyit technicall is already deployed now with ceph but i have not tweek it form the default or configure the flaovr/networkign yet11:28
*** icey has joined #openstack-nova11:33
*** lucasagomes has quit IRC11:35
*** luksky has quit IRC11:36
opendevreviewMerged openstack/nova-specs master: Add no user token when get Cyborg client  https://review.opendev.org/c/openstack/nova-specs/+/78717811:36
*** luksky has joined #openstack-nova11:37
*** lucasagomes has joined #openstack-nova11:37
*** martinkennelly_ has joined #openstack-nova11:47
*** martinkennelly has quit IRC11:51
*** kaisers has quit IRC11:52
*** kaisers has joined #openstack-nova11:54
*** lucasagomes has quit IRC11:55
gibisean-k-mooney: I think the current consumer type impl only suggest a basic usage summary per type https://review.opendev.org/c/openstack/placement/+/679441/18/placement/tests/functional/gabbits/consumer-types-1.37.yaml#13012:00
gibisean-k-mooney: and of course consumer type is now visible in the allocation12:01
*** lucasagomes has joined #openstack-nova12:01
gibisean-k-mooney: so right now the client would need to list all the allocation then filter it on the client side by the consumer type / host / project12:01
gibisean-k-mooney: I don't think it is hard to add those filters to the placement API if one needs it12:01
*** nightmare_unreal has joined #openstack-nova12:03
nightmare_unrealis there a way to find kernel version of hyperviser through openstack command ?12:04
gibinightmare_unreal: I don't think so12:07
*** nightmare_unreal has quit IRC12:07
*** bhagyashris_ is now known as bhagyashris12:09
sean-k-mooneygibi: ya i dont think it would be hard to do either12:12
*** kaisers has quit IRC12:12
sean-k-mooneygibi: what do you think about the idea of a premtiable consumer type with a prefilter that just looks for and extra spec and changes it12:13
sean-k-mooneyagain im not planning to work on that this cycle but eventually i think it would be a nice feature to support12:14
sean-k-mooneyim partly using this as a tought experiment to reason about addtional usecase fo consumer types12:14
*** abhishekk has quit IRC12:15
gibisean-k-mooney: I see that the external service needs to determine which instance can be preempted. I don't get why this needs to be a placement query. It can be a nova query as well.12:16
gibithe external service want to find servers to delete12:17
gibinova api deals with servers12:17
sean-k-mooneywe dont currently have a way to list nova instance by flavor extra spec do we?12:17
gibiso for me it fits nova API better12:17
sean-k-mooneyor by server property12:17
gibisean-k-mooney: I don't think so, that query also needed12:17
sean-k-mooneyi mean john and co proved you can do it already with the poc they did so ya you can do it vai nova12:19
gibiif the external service try to preempt any kind of allocation not just servers then I would vote for extending the placement api12:20
sean-k-mooneyya i remember talking to jay an cdent about possible evoltuion of placment to supprot timed allcoation for blazar reservations at one point12:21
sean-k-mooneythe concensous at the time was blazar shoudl manage the timing itself at least for now12:22
sean-k-mooneybut i have wondered if we ever woudl want to have differnt type fo allcoation in the futrue that had semantic meanign to placemnt12:22
sean-k-mooneyconsumer types while not an alocation type would provide a way to do that without placment knowing about it12:23
gibisean-k-mooney: is timed allocation ~= reservation?12:23
sean-k-mooneygibi: yes12:23
gibiyeah that would be an interesting thought experiment12:23
gibiI don't know how alive blazar is these days12:24
sean-k-mooneyfor now i think im going to leave it there and instead look at your reparenting spec then i need to get back to the smartnic one12:24
gibithere are soo many interesting things to work on :)12:26
gibithanks for looking at re-parenting12:26
*** mgariepy has joined #openstack-nova12:26
*** kaisers has joined #openstack-nova12:26
sean-k-mooneygibi: for timed allocation to work i think you would need some kind of web hook callback in placment that could call our external events api to tell us it expired but ye i should focus on thing that people are actully working on for a bit12:27
gibisean-k-mooney: that would be a bit similar to the external event that neutron sends us when a bound port is deleted. nova then unplugs the vif12:28
sean-k-mooneyyep that was exactly what i was thinking of12:28
gibisean-k-mooney: so basically placement would tell us that the allocation is expired and nova would ~delete~ the instaance12:28
sean-k-mooneyyep12:28
sean-k-mooneyor tell balzar if that is the endpoint you regestred12:29
gibithe delete would be a bit harsh but maybe shelve offload or snapshot would be ok12:29
gibisnapshot + delete12:29
sean-k-mooneybasically i was thinging you would pass a url to call back an a payload to send whne cratign the payload12:30
* bauzas disappears for a bit12:30
sean-k-mooney*alloction12:30
sean-k-mooneygibi: not sure if that is a good idea or not but for nova we would make the payload be an extrenal event payload allocation-exired-event possible with an acction or encode the action in a flavor extra spec or image property12:31
sean-k-mooneyi had not fully tought though the full semantics but ya that was the general thing i had in mind12:32
gibisean-k-mooney: yeah these sounds like a workable set of ideas12:33
sean-k-mooneygibi: by the way i hope you dont mind i fast appoved the cyborg admin client spec i notice that you went and fixed the blueprint12:35
sean-k-mooneygiven the time zone differece i did not think the nits justifed asking them to respin or submit a followup12:36
gibisean-k-mooney: no problema12:38
gibisean-k-mooney: I did not notice the missing bp until I tried to approve the bp after I saw the spec merged12:38
*** martinkennelly has joined #openstack-nova12:39
opendevreviewStephen Finucane proposed openstack/os-vif stable/ussuri: [Stable Only] Drop lower constraints testing  https://review.opendev.org/c/openstack/os-vif/+/79421012:40
opendevreviewStephen Finucane proposed openstack/os-vif stable/train: [Stable Only] Drop lower constraints testing  https://review.opendev.org/c/openstack/os-vif/+/79421112:41
stephenfingibi: lyarwood: Would appreciate eyes on those to unblock the other patches in os-vif ^12:41
stephenfinthat's what we agreed last week, iirc12:41
stephenfinalso, sean-k-mooney: ^12:41
* lyarwood clicks12:42
gibion it12:42
sean-k-mooneymore or less although i didnt end put trying to fix it beyond victoria12:42
gibistephenfin: note that I have no +2 rights :)12:44
stephenfinoh, lovely12:44
* stephenfin still thinks that's madness and we really should change that :-\12:44
stephenfinso I guess I need to poke elodilles ?12:45
sean-k-mooneywell actully i forgot to bring this up12:46
sean-k-mooneyanyone agaisnt me creating an os-vif-release team for stable12:46
sean-k-mooneyi would like to be able to do stable review there too12:47
sean-k-mooneyi can bring it up on the next nova meeting12:47
sean-k-mooneyi ment to do it last week and forgot this week12:47
stephenfinI'd just add core to stable-core, personally. Probably something for the next meeting12:47
gibiI'm not against it, we need agreemet from stable cores though :)12:48
sean-k-mooneyi could i wanted to add a new group to not need to add people to nova-stable-maint for os-vif stable12:48
lyarwoodyup I'm not against that12:48
sean-k-mooneygibi: im +2 on the reparenting spec too but i did not give +w to allow melwitt and other to review12:50
gibisean-k-mooney: ack, thanks12:50
sean-k-mooneystephenfin: should you have not cherry picked the stable train patch form stable ussuri12:56
stephenfinno point. It was just merge conflict hell and they're stable only12:57
sean-k-mooneywell normally stable only patches would be cherry picked12:58
sean-k-mooneybut ok12:58
sean-k-mooneyif its generally effectivly a rewrite then ill change the -1 to +112:59
*** rloo has joined #openstack-nova13:13
*** Luzi has quit IRC13:21
opendevreviewLee Yarwood proposed openstack/nova master: libvirt: Do not destroy volume secrets during _hard_reboot  https://review.opendev.org/c/openstack/nova/+/79346313:29
*** abhishekk has joined #openstack-nova13:31
*** abhishekk is now known as akekane|home13:32
*** akekane|home is now known as abhishekk13:32
*** lucasagomes has quit IRC13:38
sean-k-mooneyoh ok13:45
sean-k-mooneyi guess its ok to not destroy the secreat for had reboot13:46
sean-k-mooney*hard13:46
sean-k-mooneysoft reboot calls hard reboot also by the way if it does not soft reboot after a time out13:46
*** lucasagomes has joined #openstack-nova13:48
*** tosky has joined #openstack-nova13:54
*** hemanth_n has quit IRC13:57
*** hemna has quit IRC14:16
*** hemna has joined #openstack-nova14:28
*** opendevreview has quit IRC14:38
mdboothsean-k-mooney: Incidentally, I've always felt that was a misfeature. Soft and hard reboots are quite different things. If the user asks for a soft reboot and it doesn't work, they should get an error (asynchronously, obvs).14:47
sean-k-mooneymdbooth: i think its configurable in the nova config14:49
sean-k-mooneyhttps://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.reboot_timeout14:49
sean-k-mooneyso by default we dont14:50
sean-k-mooneybut it can be enabled14:50
*** Gue______ is now known as jamesdenton14:51
sean-k-mooneywhich is config driveen api behavior which is awesome...14:51
sean-k-mooneymdbooth: i would much prefer a reboot --gradual or somehting like that to contol that14:51
*** dklyle has joined #openstack-nova14:53
*** david-lyle has joined #openstack-nova14:57
*** dklyle has quit IRC14:57
*** david-lyle is now known as dklyle15:00
*** hemna has quit IRC15:07
*** luksky has quit IRC15:09
*** hemna has joined #openstack-nova15:19
*** opendevreview has joined #openstack-nova15:19
opendevreviewLee Yarwood proposed openstack/nova master: libvirt: Do not destroy volume secrets during _hard_reboot  https://review.opendev.org/c/openstack/nova/+/79346315:19
opendevreviewLee Yarwood proposed openstack/nova master: virt: Add destroy_secrets kwarg to destroy and cleanup  https://review.opendev.org/c/openstack/nova/+/79425215:19
melwittlyarwood: added a comment on the launchpad bug wrt wsgi config15:21
lyarwoodmelwitt: thanks15:21
melwittsean-k-mooney: the current proposal is to reflect the allocations indirectly via /usages https://review.opendev.org/c/openstack/placement/+/679441/18/api-ref/source/usages.inc and you can filter by project and user15:32
melwittgibi: ack, will look15:33
gibimelwitt: thanks15:33
sean-k-mooneymelwitt: i see ok15:33
opendevreviewMerged openstack/nova master: Honor [neutron]http_retries in the manual client  https://review.opendev.org/c/openstack/nova/+/79351215:33
bauzassean-k-mooney: gibi: oh, just saw your discussion about reservations15:36
bauzasfwiw, blazar already supports timed reservations15:36
bauzasso, the concern here is that we duplicate allocations into blazar-like reservations15:36
bauzaswhile an idea could be to add timed allocations in placement15:36
bauzasbut that's a massive change15:37
sean-k-mooneyyes im aware15:37
bauzasthe other issue is with quotas15:37
sean-k-mooneyyep15:37
sean-k-mooneyunified limits would have to understand consumer types and allow qutos per consumer type not just projects15:38
bauzasthat's the problem15:38
bauzasblazar would need to support quotas for resources that are different from current quotas15:39
melwittI'm working on consumer types this cycle fwiw15:39
melwittjust behind on updating the PS from last feedback15:39
bauzasjust explaining one of the usecases15:39
bauzasif I have quota for 10 vCPUs15:40
bauzascould I reserve 20 vCPUs over time provided I only start 10 concurrently?15:40
bauzasI could honesly overload resource usage by this15:40
bauzasI could ask for 1000000 vCPUs provided I only have reservations for 10 by once15:41
sean-k-mooneyyep i know there are many issue15:42
sean-k-mooneythat is why i was suggesting to belmoreira  that we proably dont have the design bandwith this cycle for premtibel instances15:43
sean-k-mooneybut i think we should consider it for a future cycle and maybe have a sub team to figure this out15:43
bauzaspreemptible instances are way simplier to design15:44
bauzassince we don't have reservations15:44
bauzasthere are just prioritized instances and non-priortized ones15:44
*** david-lyle has joined #openstack-nova15:45
*** dklyle has quit IRC15:45
opendevreviewMerged openstack/os-vif stable/ussuri: [Stable Only] Drop lower constraints testing  https://review.opendev.org/c/openstack/os-vif/+/79421015:54
*** alex_xu has quit IRC15:57
*** rm_work has joined #openstack-nova16:04
rm_workhaving an issue with the osc-placement==3.0.0 breaking `openstack completion`, is this the place, or does placement have their own channel, or would an sdk/client channel be better? :D16:05
rm_workhttp://paste.openstack.org/show/806280/16:07
sean-k-mooneyrm_work: ish16:10
sean-k-mooneyah you are using py 3.9.516:10
sean-k-mooneytechinially that not supported yet16:10
rm_workah ok, think it's related?16:11
rm_workI can test with 3.816:11
sean-k-mooney return self.session.request(url, method,16:11
sean-k-mooneyAttributeError: 'NoneType' object has no attribute 'request16:11
sean-k-mooneyi wonder if requests has moved somehing in 3.916:11
rm_workwill try with 3.8.916:11
rm_workwell, that implies self.session == None16:12
rm_workright?16:12
rm_workwhich almost makes sense, why would there be a session (or even need to be one) just to get a command list?16:12
sean-k-mooneyyes i gues it does16:12
*** lucasagomes has quit IRC16:13
sean-k-mooneythe erro is startin gin the client cache16:14
sean-k-mooneyhttps://github.com/openstack/osc-lib/blob/master/osc_lib/clientmanager.py#L4516:14
sean-k-mooneywhcih is a mixin16:14
rm_workhmm yeah most of this code hasn't changed in years16:14
sean-k-mooneythe sessin comes form the instance passed ot make_client https://github.com/openstack/osc-placement/blob/master/osc_placement/plugin.py#L29-L4316:17
sean-k-mooneyi wonder if this is a gregression in the api microversion auto negociation code16:17
sean-k-mooneysince the failure is comming form inside  self.negotiate_api_version(api_version)16:18
sean-k-mooneythe auto complete code likely doe snot actully connect to the cloud16:19
sean-k-mooneywell it should not connect ot the cloud16:19
sean-k-mooneyso the auto complete code will need to handel that16:19
sean-k-mooneystephenfin: gibi ^16:19
sean-k-mooneyi would gues that OSC itself is passing None for the session to osc_placment16:21
rm_workthat'd make sense I guess -- not sure what else it could reasonably pass16:24
rm_workand it'd expect the client to deal with that in this case but placement made a different assumption16:24
rm_workthough again, not a change on the placement side I think?16:24
rm_worksince I can't find any code in osc-placement that has changed since like 2019 lol16:24
rm_workmaybe should bring this up in thee client channel16:25
sean-k-mooneywe merged that auto negocaation code about last week or the week before16:25
rm_workoh, k16:25
rm_workwait where is that16:26
*** bhagyashris_ has joined #openstack-nova16:26
sean-k-mooneyso this is causing the get to rfail https://github.com/openstack/osc-placement/blob/37e47afc88b188a338e3cb70adcf87bac513d4ef/osc_placement/version.py#L14216:27
sean-k-mooneythe allocation endpoing and like all the rest is chanck the api version and seeing if it supprot things16:28
sean-k-mooneyFile "/Users/rm_work/.pyenv/versions/3.9.5/envs/osc2/lib/python3.9/site-packages/osc_placement/resources/allocation.py", line 90, in get_parser16:28
sean-k-mooney    required=self.compare_version(version.ge('1.8'))16:28
sean-k-mooneyso the allocation class is using the compare_version mixin16:28
gibirm_work, sean-k-mooney: I've just confirmed locally that 3.0.0 break the completion, while 2.2.0 still works16:28
gibiso it is pretty likely that the microversion negotiation break it as that is the only thing we merged in 3.0.016:29
sean-k-mooneydoing obj.app.client_manager.placement.api_version tries to actully connect to placement to do the version negocation16:29
sean-k-mooneywhich cant work since bash completion will not have your auth details16:29
sean-k-mooneywell not the auth deatials but it wont have the cloud endpoint16:30
sean-k-mooneyform cloud.yaml16:30
rm_workyeah ideally it should work completely offline (same as "help")16:30
sean-k-mooneythis would proably work if you exproted the env vars for the keystone endpoint16:30
sean-k-mooneylike the openrc did16:30
sean-k-mooneyrm_work: yes it should16:31
sean-k-mooneyso here we catrch AttributeError16:31
sean-k-mooneyhttps://github.com/openstack/osc-placement/blob/37e47afc88b188a338e3cb70adcf87bac513d4ef/osc_placement/version.py#L14316:31
sean-k-mooneybut we are rasing exceptions.PluginAttributeError16:32
sean-k-mooneyhttps://github.com/openstack/osc-lib/blob/master/osc_lib/clientmanager.py#L4916:32
*** david-lyle is now known as dklyle16:33
*** mgariepy has quit IRC16:33
sean-k-mooneyreally we should just check if we have a session and if not returnt true16:33
*** bhagyashris has quit IRC16:34
sean-k-mooneywell16:34
sean-k-mooneyif not obj.app.client_manager.session: return SUPPORTED_VERSIONS[0]16:35
sean-k-mooneyhere https://github.com/openstack/osc-placement/blob/master/osc_placement/version.py#L14116:35
sean-k-mooneyactully maybe SUPPORTED_VERSIONS[-1] would be better16:36
sean-k-mooneywe have a choice of assume oldest or newest microversion for completion16:36
sean-k-mooneynewset might be best16:36
sean-k-mooneygibi: do you think ^ is a vaild approch16:36
gibisean-k-mooney: agree, for completion just assume the newest supported16:37
sean-k-mooneyrm_work: you could proably work around this by changing the complation command used in bash16:38
sean-k-mooneyto pass --os-placment-api-version or whatever that flag is to the openstack client16:38
sean-k-mooneyas a tempory hack16:38
sean-k-mooneygibi: actully if you just run "openstack complete" you get "ould not clean up: 'ClientManager' object has no attribute 'sdk_connection'"16:40
sean-k-mooneyat the end16:40
gibithat last error comes from 2.2.0 as well16:41
gibibut it does not break completion I think16:41
gibior is it?16:41
rm_workyeah i've noticed that for a long time, not sure if that's placement related16:44
rm_workand no, it didn't break completion16:44
sean-k-mooneycorrect it does not but it does point to the fact that this is a general problem with the complete command16:45
sean-k-mooneyin at least the cleanup path its trying to unconditonally clean up the sdk connection that is never established16:45
rm_workyeah16:46
*** tosky has quit IRC16:48
sean-k-mooneyrm_work: can you try invoking complete but passing --os-cloud16:49
rm_workuhh sure16:49
rm_workI do have OS_CLOUD exported, FWIW16:49
sean-k-mooneyoh in that case never mind16:49
rm_workand yeah no difference16:50
sean-k-mooneyi was wondering if we told it what cloud to sue woudl the normal auth kick in16:50
*** bhagyashris_ is now known as bhagyashris16:50
rm_workwhat is an example `--os-placment-api-version` i could try btw16:50
rm_workwell, typed a random number and it works16:50
rm_work`openstack complete --os-placement-api-version 1.2`16:51
sean-k-mooneyya caus its disabling the negocation16:51
rm_workyep16:51
rm_workjust confirming your theory for that too16:51
sean-k-mooneythats the workaround for now more or less16:51
rm_workok, LMK if there's something I can help review :)16:52
sean-k-mooneyim just going to push something quickly16:52
rm_worki can test whatever locally16:52
opendevreviewsean mooney proposed openstack/osc-placement master: [WIP] default to max version when no session  https://review.opendev.org/c/openstack/osc-placement/+/79427616:56
rm_worksome other client actually IS trying to do auth I think... i have to yubi-key to do `openstack complete` lol16:57
opendevreviewmelanie witt proposed openstack/nova stable/wallaby: Honor [neutron]http_retries in the manual client  https://review.opendev.org/c/openstack/nova/+/79418616:57
opendevreviewsean mooney proposed openstack/osc-placement master: [WIP] default to max version when no session  https://review.opendev.org/c/openstack/osc-placement/+/79427616:57
sean-k-mooneyrm_work: ya as i said you would have to specificaly code for this with auto negociation16:59
rm_workhmmm16:59
rm_work`ValueError: invalid version number '1'`16:59
rm_workwith your patch16:59
rm_worknot sure exactly why16:59
rm_workhttp://paste.openstack.org/show/806286/17:00
rm_worklogically your fix seems right17:00
sean-k-mooneyhttps://github.com/openstack/osc-placement/blob/master/osc_placement/version.py#L1817:00
sean-k-mooneyit is getting that17:00
sean-k-mooneybecause of https://github.com/openstack/osc-placement/blob/master/osc_placement/version.py#L5217:00
sean-k-mooneylet me try MAX_VERSION_NO_GAP17:00
rm_workOH yeah I see17:01
opendevreviewsean mooney proposed openstack/osc-placement master: [WIP] default to max version when no session  https://review.opendev.org/c/openstack/osc-placement/+/79427617:01
rm_workI misread SUPPORTED_MICROVERSIONS as SUPPORTED_VERSIONS17:01
sean-k-mooneyya so did i when i wrote it17:02
sean-k-mooneyi ment to get the last supported microveris17:02
rm_workk looks good17:02
sean-k-mooneyi might change it back to SUPPORTED_MICROVERSIONS[-1] but does that seam to fix it17:03
rm_workthis seems like it accomplishes your goal pretty explicitly17:03
rm_worksince you wanted ... that17:03
rm_workmax version17:03
*** kaisers_ has joined #openstack-nova17:04
melwittstephenfin: are you interested in +W-ing the placement re-parenting spec? https://review.opendev.org/c/openstack/nova-specs/+/78824317:04
opendevreviewBalazs Gibizer proposed openstack/nova master: Detect extended_resource_request neutron API extension  https://review.opendev.org/c/openstack/nova/+/79361817:04
opendevreviewBalazs Gibizer proposed openstack/nova master: Reject server create with extended resource req  https://review.opendev.org/c/openstack/nova/+/79361917:04
opendevreviewBalazs Gibizer proposed openstack/nova master: [func test] neutron fixture for extended resource request  https://review.opendev.org/c/openstack/nova/+/79430617:04
sean-k-mooneyrm_work: ok well i can see if we can turn that into a proper patch with some tests17:04
rm_workwell I +1'd17:05
rm_worklol17:05
sean-k-mooneywell it work but i want to put a unit test that asssert we dont call the thing that explode when session is None17:05
*** kaisers has quit IRC17:06
rm_workyep, makes sense17:06
opendevreviewBalazs Gibizer proposed openstack/nova master: Reject server operations with extended resource req  https://review.opendev.org/c/openstack/nova/+/79362017:06
*** derekh has quit IRC17:06
opendevreviewBalazs Gibizer proposed openstack/nova master: Add same_subtree field to RequestLevelParams  https://review.opendev.org/c/openstack/nova/+/79150317:08
*** erbarr has joined #openstack-nova17:09
opendevreviewBalazs Gibizer proposed openstack/nova master: Bump min placement microversion to 1.36  https://review.opendev.org/c/openstack/nova/+/79150417:13
opendevreviewBalazs Gibizer proposed openstack/nova master: Support same_subtree in allocation_canadidate query  https://review.opendev.org/c/openstack/nova/+/79150517:13
opendevreviewBalazs Gibizer proposed openstack/nova master: Support the new port resource_request format  https://review.opendev.org/c/openstack/nova/+/78720817:16
*** ralonsoh has quit IRC17:17
opendevreviewBalazs Gibizer proposed openstack/nova master: Transfer RequestLevelParams from ports to scheduling  https://review.opendev.org/c/openstack/nova/+/79150617:18
opendevreviewBalazs Gibizer proposed openstack/nova master: [func test] ports with both bw and pps resources  https://review.opendev.org/c/openstack/nova/+/79239417:21
opendevreviewBalazs Gibizer proposed openstack/nova master: [func test] move unshelve test to the proper place  https://review.opendev.org/c/openstack/nova/+/79362117:22
*** abhishekk has quit IRC17:30
opendevreviewsean mooney proposed openstack/osc-placement master: default to max version when no session  https://review.opendev.org/c/openstack/osc-placement/+/79427617:30
rm_work\o/17:33
sean-k-mooneylol i broke the docs because thre app is non17:35
sean-k-mooney  File "/home/zuul/src/opendev.org/openstack/osc-placement/osc_placement/version.py", line 141, in get_version17:35
sean-k-mooney    if obj.app.client_manager.session is None:17:35
sean-k-mooneyAttributeError: 'NoneType' object has no attribute 'client_manager'17:35
*** mgariepy has joined #openstack-nova17:37
opendevreviewsean mooney proposed openstack/osc-placement master: default to max version when no session  https://review.opendev.org/c/openstack/osc-placement/+/79427617:37
sean-k-mooneyrm_work: ok ^ should be the final patch unless peopel ask for feedback17:38
sean-k-mooneywell provide feedback17:38
sean-k-mooneygibi: can you add https://review.opendev.org/c/openstack/osc-placement/+/794276 to your review queue17:38
rm_workwould docs not also want latest?17:39
sean-k-mooneymaybe17:39
rm_workbut, starts to be hard to code for every little case like that when you're basically making an inference about the caller17:39
sean-k-mooneybut they were previouly getting the oldest17:39
rm_worknot "if for_docs:"17:40
rm_workyeah...17:40
sean-k-mooneyi can do this a different way17:40
sean-k-mooneyi can catch the other error type17:40
sean-k-mooneyPluginAtributeERROR17:40
sean-k-mooneybut i dont like that since it actully trys to connect the cloud17:41
stephenfinmelwitt: Won't have a chance now (I'm just finishing up) but I think I didn't have any concerns of my own, so if you're happy to +W then go for it :)17:41
melwittcool, thanks stephenfin17:42
sean-k-mooneyrm_work: let me see what the docs are using it for17:42
*** erlon has joined #openstack-nova17:44
sean-k-mooneyrm_work: its from cliff/sphinxext.py17:48
*** andrewbonney has quit IRC17:49
*** dklyle has quit IRC17:49
rm_workso not the client auto-doc stuff?17:49
rm_workor that is it17:49
*** dklyle has joined #openstack-nova17:49
sean-k-mooneywell kind of17:49
sean-k-mooneyits form _generate_nodes_per_command17:49
sean-k-mooneyso it is the auto generation of docs for cliff commands17:50
sean-k-mooneypreviously that was raising an atribute error but we were catching it and returning the oldest version17:50
sean-k-mooneyrm_work: lol i may have missed that comment https://review.opendev.org/c/openstack/osc-placement/+/794276/5/osc_placement/version.py#14617:55
sean-k-mooneythat is why the try is there17:55
rm_workheh yeah17:56
rm_workI would say "let's use the maximum one" but that's just me17:56
opendevreviewMerged openstack/nova master: Error anti-affinity violation on migrations  https://review.opendev.org/c/openstack/nova/+/78416617:57
sean-k-mooneyya that would be my prefernce too17:57
rm_workmight be a bigger change than just "bugfix regression on bash completion"17:58
opendevreviewMerged openstack/nova-specs master: Allow provider re-parenting in placement  https://review.opendev.org/c/openstack/nova-specs/+/78824317:58
sean-k-mooneyrm_work: ya for now im not going to chagne it17:59
sean-k-mooneybut i left a review comment17:59
rm_workyep, left a reply too :D18:00
opendevreviewElod Illes proposed openstack/nova stable/wallaby: [stable-only] Fix ceph install in live migration hook  https://review.opendev.org/c/openstack/nova/+/79400018:31
opendevreviewRodrigo Barbieri proposed openstack/nova stable/wallaby: Error anti-affinity violation on migrations  https://review.opendev.org/c/openstack/nova/+/79432818:35
*** luksky has joined #openstack-nova19:05
*** luksky has quit IRC19:05
*** luksky has joined #openstack-nova19:05
*** belmoreira has quit IRC19:11
*** vishalmanchanda has quit IRC19:13
*** kaisers_ has quit IRC19:15
*** kaisers has joined #openstack-nova19:16
*** tosky has joined #openstack-nova19:23
*** slaweq has quit IRC20:34
*** rloo has quit IRC20:36
*** rloo has joined #openstack-nova20:36
*** jparker has joined #openstack-nova21:16
*** david-lyle has joined #openstack-nova21:18
*** dklyle has quit IRC21:18
*** jamesdenton has quit IRC21:21
*** Gues_____ has joined #openstack-nova21:23
*** kaisers has quit IRC21:47
opendevreviewmelanie witt proposed openstack/nova stable/wallaby: zuul: Replace grenade and nova-grenade-multinode with grenade-multinode  https://review.opendev.org/c/openstack/nova/+/79434522:13
toskymelwitt: crossing fingers :)22:32
melwitt:)22:33
*** luksky has quit IRC22:35
*** tosky has quit IRC23:25

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!