17:00:33 #startmeeting ironic 17:00:34 Meeting started Mon Feb 23 17:00:33 2015 UTC and is due to finish in 60 minutes. The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:37 The meeting name has been set to 'ironic' 17:00:43 hi all! 17:00:44 \o/ 17:00:48 hellooo! 17:00:49 o/ 17:00:50 o/ 17:00:53 o/ 17:00:55 o/ 17:00:55 hi all.. 17:01:12 as usual, our agenda's on the wiki - https://wiki.openstack.org/wiki/Meetings/Ironic 17:01:13 hi 17:01:23 hi 17:01:24 o/ 17:01:41 light agenda today 17:01:54 o/ 17:01:55 #topic announcements 17:02:31 feature freeze is coming up, and while we got a lot done at the sprints the last few weeks, we've got A TONNE to review ... 17:02:48 :) 17:02:51 oh yeah 17:03:12 feature proposal (ie specs) freeze is March 5. Feature freeze (code) is March 19? 17:03:27 https://wiki.openstack.org/wiki/Kilo_Release_Schedule 17:03:32 rloo: sounds right 17:04:01 we're sticking to that, but practically, it means we need to stay on top of our priorities 17:04:04 which brings me to 17:04:10 last week I was pretty sick and was only sort of here for the meeting 17:04:40 at the SF meetup, we talked about how we're tracking our priorities 17:04:48 :) /me hopes deva is feeling better 17:04:55 * dtantsur too 17:04:59 * BadCub_ too 17:05:02 and BadCub_ volunteered to help me - mostly to help around communicating and keeping launchpad up to date 17:05:14 since I don't check on it often enough 17:05:23 so I wanted to (re)announce that :) 17:05:32 that's all from me - any other announces? 17:05:32 :) Thank you BadCub_ :) 17:05:45 * BadCub_ will be digging deeper into that this week :-) 17:06:09 ok - moving on 17:06:13 #topic status report 17:06:19 deva, some of the approved specs are not on kilo3 launchpad yet 17:06:47 wanyen: yes, BadCub_ is aware. please ping him (after the meeting) to update those 17:06:47 wanyen: can we #link thouse to BadCub_ 17:07:00 will do 17:07:44 #link https://etherpad.openstack.org/p/IronicWhiteBoard <- for status reports 17:08:11 jroll, JayF: quick update on IPA - I was at the tripleo sprint for a couple days last week, and hope that I made it clear we're switching to IPA 17:08:25 the only blocker for them was iSCSI-based deploy support 17:08:45 I think ya'll were working with lucas on that -- so if/when that lands, let's make sure to let #tripleo folks know 17:08:51 devananda: that's almost done afaik, lucas has been working on it 17:08:52 which lucas has been working on 17:08:56 that's part of the switch to IPA 17:08:57 ok 17:09:01 yea 17:09:15 we aren't switching without that, so it's not really a blocker 17:09:34 i mean that is what blocked tripleo from switching 17:09:47 o/ 17:09:53 o/ 17:09:57 #link https://review.openstack.org/#/c/155727/ 17:10:05 lucasagomes, we've assigned everything to you, thanks 17:10:07 iscsi/ipa review ^ 17:10:09 lucasagomes: ohhai! I was just talking about adding iSCSI support to IPA 17:10:21 lucasagomes: how is the iscsi support for IPa going? 17:10:25 sorry I'm late, was looking into a problem here 17:10:36 NobodyCam, devananda jroll so it works :) but we need to bump the memory on gate 17:10:48 ya 17:10:51 * jroll reviews 17:11:00 lucasagomes: ah right. in the tempest serial job 17:11:01 lucasagomes: what do we need to bump to 17:11:03 there's only on problem, as we are using the same PXE config file for both IPA and normal ramdisk 17:11:14 I had to remove the rootfstype=ramfs from the PXE 17:11:24 lucasagomes: that puts us in a pickle -- we'll have to have support for DIB for the tempest parallel job, then 17:11:26 but that makes it use tempfs and the default ramdisk will need more ram too :( 17:11:43 devananda, yeah, I was thinking about passing that option to the parallel job 17:11:50 as append_pxe_config_option 17:12:00 and document that the it can be done for the bash ramdisk 17:12:10 devananda, and run the parallel job with the bash ramdisk 17:12:36 seems reasonable to me 17:12:53 I'd like to know core team's status of iRMC review, https://review.openstack.org/#/c/146803/ and https://review.openstack.org/#/c/134865/ 17:13:02 still bothers me that we don't have a means to drop support for the bash ramdisk if we keep the parallel job 17:13:20 but let's do it, because we already test both, and this is still better 17:13:24 devananda, yeah :/ I don't have a solution for that, it have to go to infra 17:13:41 BadCub_: can you add naohirot's links there to the hey-lets-get-some-reviews list? 17:13:43 is there any plan to add ubuntu support for ipa dib element 17:14:06 wanyen: I believe (but may be wrong) that the goal is to drop DIB 17:14:19 wanyen, not from me, but IPA is just a service like any other. It could be added 17:14:27 jroll, I'm not assuming that, not yet at least 17:14:31 devananda: both updated more than 20 times each and there is no issue to be discussed remained. 17:14:39 lucasagomes: maybe that's just my goal :) 17:14:55 jroll, heh yeah, I mean, the tool that builds the ramdisk is at the end not very relevant for us 17:14:57 jroll: we're not necessarily dropping DIB itself - just its init-style ramdisk 17:15:04 right, right 17:15:06 jroll: there are still folks who care about DIB as a tool 17:15:18 and folks care about using iSCSi as a deploy mechanism. 17:15:33 right, ok 17:15:35 dtantsur, lol just read ur message now. Oh noes everything is too much :) 17:15:53 * jroll digresses 17:15:59 devananda, just a point here 17:16:05 we still using ISCSI with IPA 17:16:31 I think that's important because that's the only way to deploy without using swift 17:16:39 so it should continue 17:16:45 lucasagomes: yes 17:16:45 IMHO 17:16:49 yes 17:17:02 totally agree 17:17:14 lucasagomes: oh, we are definitley NOT removing the iscsi-based deploy mechanism 17:17:25 cool :) just making sure 17:17:32 if i wasn't clear, I'll restate 17:17:47 we need the iSCSI-based deploy as one option, and the fetch-from-swift as another 17:17:53 +1 17:17:57 :) 17:18:06 there are users/operators who want to use coreos to build the ramdisk, and others who want to use DIB 17:18:06 NobodyCam, devananda so if any changes required in DIB for any ironic features they will be considered/supported? 17:18:09 so yeah, I have to rebase the patchs in Ironic for IPA. It's now failing gate due the memory problem I pointed 17:18:12 we should allow both to continue 17:18:40 but should be good. We need this merged: /me getting the link 17:18:43 however - the particular "init" style ramdisk which is built by diskimage-builder/ramdisk-image-create -- no one has any particular feelings for that _tool_ 17:18:59 #link https://review.openstack.org/#/c/158251/ 17:19:12 Nisha: that's very vague. can you be more specific? 17:19:43 BadCub_: please add lucasagomes' link to the list too :) 17:20:03 NobodyCam will do! 17:20:03 devananda, like for secure boot it requires changes in DIB to build signed iso and images 17:20:10 devananda: There are DIB changes required to iso element in DIB to support secure boot. Would that be upported? 17:20:12 lucasagomes: ack, ty. I'll look later. would also like to get adam_g to weigh in on that 17:20:30 devananda, cool yeah I've added u and adam_g to the reviewer list 17:20:32 this is going fairly off-topic, but as a note, if we can figure out a good way to pass an authenticated glance URL to the agent, we could consider dropping iscsi deploys (not sure what other implications there may be) 17:20:55 Nisha: signed instance image? or signed deploy image? 17:21:08 jroll: nope. we need to keep iscsi-based deploys. 17:21:14 jroll, keystone v3 trusts 17:21:15 signed deploy iso 17:21:15 devananda: Signed instance images 17:21:16 jroll: that's waaay off topic, btw 17:21:26 Nisha: stendulker: which is it? :) 17:21:28 jroll, but also we are making glance optional by only requiring a http url 17:21:33 so that would do that too 17:21:43 devananda: I know it's off topic, let's talk later; just thinking out loud 17:21:49 devananda: https://review.openstack.org/#/c/153987/ 17:22:00 Nisha: stendulker: also I did not say anything about dropping DIB support, so I dont understand why you're both asking this 17:22:17 let's not go too off-topic, we're still in subteam reports 17:22:24 yea ... 17:22:31 and we're over our 10 minute cap for that 17:22:43 also, it didn't seem like we actually had any subteam reports. *shrug* 17:22:50 devananda: We felt its support getting dropped... my mistake. 17:23:01 #topic K3 priorities 17:23:16 who put this on the agenda? there's no name or link ... 17:23:27 oh sorry that was me 17:23:32 just before the meeting 17:23:39 I mean, we should talk about it, but I wasn't prepared 17:23:47 deva, I addded iLO driver status 17:23:47 it was last minute 17:23:48 nor I 17:23:49 NobodyCam: oh you ninja'd it :p 17:23:52 we can punt on it 17:24:02 #undo 17:24:03 Removing item from minutes: 17:24:08 I would like to take about open spec reviews 17:24:10 #topic chassis discovery tool 17:24:12 I wanted to know if there were any specs that were K3 priorities, to get approved before the deadline 17:24:13 I just think from now til end of cycle we should cover priorities and see where we're at 17:24:32 let's honor the meeting format 17:24:38 and get to K3 priorities at the end 17:24:42 lol we can come back to that in OD 17:24:45 sandhya: hi! 17:24:57 hi devananda... 17:25:23 sandhya: do you have a summary prepared? 17:25:37 sandhya: if not, I can try to type fast 17:25:44 I added the chassis discovery tool blueprint discussion to 17:25:49 #link https://review.openstack.org/#/c/134866/ 17:26:20 The blueprint started with a plan initially. And then certain complexities came forth and we decided to do it as a tool 17:26:31 I like the tool approach 17:26:45 ... in it's own repo 17:26:49 but I think we need a separate directory for vendor contributed tools 17:27:02 dtantsur: actually, no 17:27:07 so separate dir or repo..? 17:27:18 I think I'm fine with any, but we need to extend the test support to tools/ 17:27:25 we can't run unittests on that dir in the moment 17:27:27 from a packager's perspective, it's going to be awkward if all the tools are in one (or more) separate projects 17:27:34 we need some plumbing 17:27:44 lucasagomes: right. and tools/* is currently for our project mgmt tooling 17:27:49 like building config files and such 17:27:50 from a packager perspective we need a proper CLI installed by setup.py 17:27:51 yes 17:27:53 i'd rather put it in contrib/ 17:27:56 which we dn't have 17:28:02 dtantsur: yup 17:28:02 lucasagomes: I'm not sure we can test all of these types of tools 17:28:13 we could do unittest 17:28:19 So we create a ironic/contrib dir 17:28:20 yeah, maybe adding a new dir which we could run unittests agains the scripts in the new dir 17:28:23 that would be fine 17:28:25 dtantsur: except not everyone will want them 17:28:26 so shall we create it and try pushing our patch there..? 17:28:33 I'm skeptical that we want user-contributed scripts packaged in distros, idk 17:28:40 devananda, we won't for example 17:28:43 dtantsur: and upstream doesn't claim the're supported or tested -- because, frankly, we can't 17:28:44 NobodyCam, I see, maybe not all. But, the chassis one is a python script right? 17:28:54 NobodyCam, we should have some test for it 17:29:01 let's be concrete and think about what other tools might end up in there... deployment tools? management tools? etc 17:29:10 devananda, why are we adding it then? what prevents us from having it separately? 17:29:15 lucasagomes: yes but requires hardware to support it 17:29:23 dtantsur: for non-default, not-everyone-wants-them pyhton scripts, what's wrong with contrib/* and NOT having them installed on the system? 17:29:27 NobodyCam, not for unittests 17:29:34 and not putting even more reviews of unknown stuff on folks? 17:29:41 jroll: tools for chassis discovery of different kinds of hardware 17:29:45 lucasagomes: ++ very true! 17:29:50 devananda, we have to review thing we don't understand and don't care about 17:29:54 jroll: tools for automating some operations that aren't part of our standard 17:30:05 (we = some subset of core team) 17:30:21 right, ok. 17:30:22 dtantsur: well. nothing prevents anyone from putting up a separate repo with their tooling in it today 17:30:47 devananda, that's what I did for ironic-discoverd, and that's why I feel strange now 17:30:48 dtantsur: for some reason, sandhya &co want it to be in the main repo. propbably because they think it'll be easier for users to find it that way 17:31:25 oh yeah, people read stackforge like "experimental, unsupported and not Official OpenStack (tm)" 17:31:38 I am in favor of a contrib type folder, if for nothing more that they make great examples of how people are using ironic 17:31:54 dtantsur: I know ... and I want to move discoverd off of stackforge as soon as reasonably possible 17:31:56 devananda, but I believe if we bring it under openstack/ namespace and mention it in docs, people will easily discover them 17:32:00 devananda: do you think that anything that goes in the proposed /contrib need to be reviewed like the rest of the ironic code? 17:32:11 thou I do agree that unit tests should be enabled 17:32:12 devananda, I'm ready at any moment (and I wanted to talk to you about it) 17:32:14 :) 17:32:23 dtantsur: the difference being discoverd should be official, supported, tested in the gate, and is widely applicable 17:32:36 dtantsur: this, on the other hand, is a vendor-contributed tool for a very narrow set of users 17:32:42 and not testable i nthe gate 17:32:47 it makes me sad that people won't use things just because it's in stackforge :( 17:32:48 (aside from unit tests) 17:32:53 jroll: ++ me too 17:33:05 jroll, I have problems even here at RH :( 17:33:10 ugh 17:33:12 dtantsur: that's really sad :( 17:33:26 dtantsur: fwiw, I'm constantly telling people about discoverd 17:33:29 yeah, it's def a big misconception about it 17:33:33 oh thanks 17:33:36 if unittests are the only concerns, we can put that as part of the patch being proposed too..We can add unittests as well for the tool... 17:33:40 Yes. Unit tests will be enabled. A fake discovery driver that can be plugged in for the tool to run. 17:33:44 So contrib/XXXXX/some_file.py Should there be an XXXXXX and if so, would need a naming convention. 17:34:33 random thought: would this fit into discoverd? 17:34:35 * jroll ducks 17:34:39 contrib/ sounds a tiny bit better, though I still won't feel easy approving changes 17:34:41 jlvillal: are you thinking XXXXX is per vendor? 17:34:52 jlvillal: so you mean a spec for the naming convention.. 17:34:54 jroll, I don't have vendor drivers there for now :) 17:34:55 NobodyCam: That was my first thought. But not sure. 17:35:03 NobodyCam: let's *not* put vendor names in our repo :/ 17:35:16 I never want "rackspace" to show up in the ironic tree 17:35:16 that what I was thinking 17:35:23 * 43UABVQBF wonders why do we have chassis concept in Ironic 17:35:33 good question arrived ^^^ 17:35:38 heh yea 17:35:43 43UABVQBF, to group nodes, but yeah we are not actually using it very well yet 17:35:45 I've been suggesting we remove it for >6mo 17:35:49 I've heard it's useful for blades as well 17:35:52 <43UABVQBF> lucasagomes: it was me 17:35:57 I'd be fine with removing it 17:36:01 43UABVQBF: who's you? 17:36:06 <43UABVQBF> oh it's me rameshg87. for some reason name is not coming 17:36:11 lol 17:36:12 heh 17:36:13 heh 17:36:14 wow 17:36:16 ahh 17:36:17 hi ramesh :) 17:36:27 <43UABVQBF> hello devananda :) 17:36:33 so, I'd _love_ to remove chassis entirely from ironic 17:36:45 however we need to provide some mechanism to group nodes 17:36:51 and no one's done that work yet 17:36:53 ... do we? why? 17:37:02 yeah why? I mean I would rather extend it's use 17:37:02 what about having tags? 17:37:09 dtantsur: ++ 17:37:19 we're also now pretty far off topic 17:37:22 node.extra works well for us to do things like "which rack is this in" 17:37:24 oh yeah 17:37:32 so back to topic 17:37:42 I'll summarize 17:37:54 - we have the concept of chassis in tree today, but aren't actually using it anywhere 17:38:18 this tool can / will make use of this concept 17:38:39 people will beat me up now, but can we bump it to L? with the decision of whether we're dropping chassis or not... 17:38:40 what NobodyCam said :) 17:38:40 I like the idea of a contrib folder 17:39:05 - we don't have a designated place for vendors, or anyone else ,to contribute "useful" tools 17:39:08 The concern I do have is ATC statuc for it 17:39:13 (for some definition of useful that is not clear) 17:39:33 I would like to exclude atc status for that folder.. .if such could be done 17:39:43 NobodyCam: interesting. so if we put it in a repo on stackforge, AND said that repo is part of ironic, the net effect is the same 17:39:49 NobodyCam: nope. can't be done 17:39:58 ahh 17:40:04 do we actually care about atc status things? :| 17:40:07 NobodyCam: th eonly way to do that is to push it to stackforge and NOT say it is part of hte ironic project 17:40:18 my concern is review throughput 17:40:21 jroll: I do. but I also think this _should_ grant ATC status. 17:40:28 which would MORE harmfull imho 17:40:31 ++ with dtantsur 17:40:33 huh, ok 17:40:47 this is clearly coming from a team of people who use and contribute regularly to ironic 17:40:51 * naohirot what is ATC? 17:40:54 I'm afraid of getting more and more reviews of stuff I don't remotely understand... 17:40:55 why on earth would we want to exclude that from ATC? 17:41:08 naohirot: active technical contributor. it means you have voting rights in elections and a free pass t othe design summit 17:41:13 naohirot, active technical contributor 17:41:20 :-p 17:41:24 thanks :) 17:41:30 dtantsur: ahhh. so we need to trust driver authors to know their own code 17:41:39 dtantsur: and driver authors need to start ponying up third-party CI 17:42:05 dtantsur: if the core team doesn't trust driver authors, we have huge problems as a community 17:42:15 devananda: so if we trust driver authors to know their own code, there isn't any need to review their patches? 17:42:16 devananda: ++ 17:42:19 devananda, if we don't really review it, what's the use of having in-tree? 17:42:31 dtantsur: also we're absolutely going to get more drivers being contributed for hardware that none of us remotely understand 17:42:32 yeah, we still have to review it for code styles etc 17:42:35 like Cray supercomputers 17:42:51 devananda, drivers are necessary evil IMO 17:42:57 lucasagomes: that's a job for computers :/ 17:43:07 dtantsur: they're not evil. they are the reason I'm working on this 17:43:13 jroll, we can add a lot of hacking rules :D 17:43:18 my understanding is that reviews for this folder would have a less strick review criteria 17:43:34 vendors can abstract most of their hardware related stuff in their own module and leave little to ironic 17:43:39 I mean, we still have to look at the code, idk, I don't wanna blind merge it. I want to see if there's something malicious 17:43:44 rameshg87_, ++ 17:43:47 or a dependncy on a non f/oss tool 17:43:54 The tool will be generic. I can probably push the code for it. It will have a base discovery class that can be implemented by drivers. 17:44:02 lucasagomes: right 17:44:08 whoa 17:44:17 sandhya, which drivers? I don't see real opportunity for now (maybe FUJITSU?) 17:44:21 sandhya: eh? 17:44:27 now we're talking about a contrib plugin framework? 17:44:27 whoaaa. 17:44:36 no frameworks please 17:44:41 * devananda is in the whooooaa boat with jroll 17:44:55 if we're going to have plugins for contrib tools, we'd go insane soon 17:45:00 this screams separate repo to me at this point 17:45:08 yeah for a generic thing 17:45:13 either driver vendor passthru 17:45:18 since it already abstract it per driver 17:45:22 if we're talking about a generic mechanism, let's introduce an API in L cycle (or vendor passthru now) 17:45:22 or a separated repo 17:45:31 sandhya: if you're going to make it general enough to have a plugin framework for additional drivers, it's really much more than I had thought 17:45:55 wait is this a simple tool or a framwork. 17:46:01 I need to time box this discussion 17:46:01 devananda, driver vendor passthru? It's already kinda like a abstraction for driver specific code 17:46:09 its a framework.. 17:46:09 since we have 15 minutes left and two more large topics 17:46:14 * dtantsur votes for vendor passthru 17:46:29 ok move on then 17:46:31 * jroll votes for voting on gerrit 17:46:37 jroll, +1 17:46:42 lucasagomes: devananda: ++ move on and come back 17:46:43 #action devananda to re-review the chassis discovery tool code in depth 17:46:50 Yes, it is a generic framework. I will push the code... 17:46:59 sandhya: thanks. I'll take a look today 17:47:02 will vendor passthrough let mw enroll a new server in ironic.. if so, we will look into it and come-back... 17:47:11 #topic passing capabilities from nova to ironic 17:47:16 i am here 17:47:18 this is regarding how capabilities can be passed to Ironic with the current changes in nova that got recently merged 17:47:21 i know this has been discussed many times in last week, and hardware/driver capabilities will be attempted in a better way in L release 17:47:27 this is just a proposal on how it can be done for kilo with the nova patch that got merged with minimal/no changes 17:47:31 i have put up a small spec for it - https://review.openstack.org/#/c/158243/ 17:47:35 we may ask deployers to configure and use the capabilities in the way mentioned in the spec for K release 17:47:38 all please have a look at spec 17:47:48 #link https://review.openstack.org/#/c/158243 17:47:52 mainly wanted to bring out this much. ready to take more questions :) 17:48:11 * lucasagomes adds to his todo list 17:48:20 rameshg87_: iiuc, we had originally approved a spec whereby nova would pass only a small set of rules to ironic, but then the code which landed in nova passes EVERYTHING down 17:48:31 rameshg87_: so now ironic has to take on the responsibility of parsing that 17:48:34 rameshg87_: is that correct? 17:48:35 devananda: yeah. 17:48:40 wondering why this spec isn't a developer doc 17:48:41 devananda, yes 17:48:46 rameshg87_: do you have the link to the nova spec that landed 17:48:48 devananda: but in my opinion ironic doesn't need to actually care about parsing everything 17:48:57 rameshg87_: ok, i see 17:48:59 NobodyCam: it's within the ironic spec 17:49:06 devananda: i have put out my reasons in the spec. 17:49:07 ack 17:49:19 #link https://review.openstack.org/#/c/141012/ 17:49:25 that's the nova code which landed 17:49:29 devananda: it is more of an agreement from ironic on how they can make use of capabilities for scheduling with the changing in K release 17:49:40 thank you devananda :) 17:49:41 rameshg87_: great, thanks for bringing it up! 17:49:50 rloo: I think turning this into a dev doc might be the goal 17:50:11 *10 minutes* 17:50:12 ok, moving on 17:50:18 yeah, i would contents of this spec will land into docs 17:50:23 #topic K3 priorities 17:50:57 first off, I know that LP doesn't match the list of approved specs 17:51:10 BadCub_ and I will sort that out soon (today I hope) 17:51:17 Not to bring it up as a topic now. but I would folks to think about maybe moving the FF deadline up next cycle 17:51:29 NobodyCam: yea... I agree 17:51:46 I'll bring that up with ttx at the summit (and he'll probably see the ping here too) 17:51:54 :) 17:51:55 as a suggestion for the general timeline 17:51:56 proposal freeze or feature freeze? 17:52:08 (I would like the former to be moved) 17:52:13 devananda that sounds good 17:52:23 if the latter is moved, the former should probably be too 17:52:38 dtantsur: maybe both. but I see PF for sure 17:52:40 proposal freeze definitely should be sooner, like K2 17:52:52 so a question for everyone 17:52:56 devananda: ++ 17:53:02 last cycle, I used a google spreadsheet towards the end of the cycle 17:53:11 to coordinate what we were reviewing 17:53:15 how'd that work? should I do that again? 17:53:15 my two cents: code freezes make me sad 17:53:18 #link https://docs.google.com/spreadsheets/d/1Hxyfy60hN_Fit0b-plsPzK6yW3ePQC5IfwuzJwltlbo/edit#gid=1604970109 17:53:37 devananda: ++ it worked for me... 17:53:41 jroll: coordinated release makes me sad 17:53:45 worked for me too 17:53:48 devananda: ++ 17:54:04 devananda, ++ 17:54:04 also, yeah, I seem to remember that doc being helpful 17:54:12 jroll: what if services were released like clients -- when ever we want? 17:54:39 devananda: then things would be more sane, and also infra would ragequit 17:54:41 :P 17:54:46 ok - so BadCub_ and I will work on updating the spreadsheet 17:54:48 heh 17:54:48 #link https://docs.google.com/spreadsheets/d/1Hxyfy60hN_Fit0b-plsPzK6yW3ePQC5IfwuzJwltlbo 17:55:05