=== cpaelzer_ is now known as cpaelzer [09:36] smoser: So I'm looking at /sys, and I can't see how to find the logical sector size of a block device. [10:26] Is it possible to make cloud-init run an abitrary script after it has gone through it's other sources? [13:11] Odd_Bloke: I don't know about /sys, but this works, I think: blockdev --getbsz /dev/sda [13:16] larsks: Yep, blockdev would do it; we're trying to avoid forking if we can. [13:17] It's just calling the BLKBSZGET ioctl. I guess you could do that natively in python w/ the 'fcntl' module... [13:19] Odd_Bloke, i put iot in my comments. [13:20] oh carp. looks like i didn't hit 'submit' on some comments. [13:21] but anyway, its /sys/class/block//qeueu/logical_block_size [13:21] and physical_block_size [13:22] ndonegan, yes. just send script as user-data . if it starts with '#!' it gets executed. [13:22] sucks that i lost that comment. [13:22] Odd_Bloke, i had also rquessted that we round reasonably well (to 1MB or 4MB) increments so we land on fs alignment. and also start at 1MB in. [13:23] smoser: Having issues with a certain meta data provider, hence why I want to be able to run a script after which verifies stuff happened. [13:23] smoser: If {logical,physical}_block_size are actually sector sizes, why is there also hw_sector_size? [13:24] well, i dont know. in my tests, logical and physical match up with what i fed through qemu-system-x86 [13:25] and qemu calls them 'logical_block_size' and 'physical_block_size' [13:26] so i'm justified in my assumption (as those names line up). but i admittedly did make an assumption :) [13:26] ndonegan, i dont really follow. [13:27] smoser: Having great fun with metadata proxy where it occasionally sends back crap. [13:28] As an example, the request it should be sending to nova-metadata-api gets sent as the resonse to the client. [13:28] So looking for some way to try and very that some valid data was sent back [13:29] *verify [13:30] ndonegan: You're looking to change the image in order to do this, or configure cloud-init to do it from outside the instance? [13:31] Odd_Bloke: Exploring any option, including edits to the image, to see if there's some way to verify that what comes back from the metadata service is correct. [13:31] ndonegan, as in openstack ? [13:31] yeah. [13:32] It would actually be better if the proxy just failed entirely and timed out. That way I can have the "None" data source as a fallback, and let it write a raw userdata [13:32] However, it sends back just enough before screwing up that the Ec2 source doesn't fail outright. [13:32] smoser: Openstack with Contrail. [13:32] right. [13:32] And it's Contrail that's the issue. [13:32] 2 things you could try [13:32] a.) cirros [13:33] b.) if you can enable config drive in launching... then you can probably avoid cloud-init hitting the md so you can get in and debug from there. [13:34] ie, launch with 'config_drive=1'. [13:34] i suggest cirros because it will time out faster and you can log in with password : cirros/cubswin:) [13:44] smoser: So, looking at the kernel source, hw_sector_size is the same value as... logical_block_size. [13:45] We already have a base image we use everywhere (mini Centos setup for our environment). [13:45] ConfigDrive might be a good option. [13:45] Odd_Bloke, i would not have thoguth that :) [13:53] smoser: I updated the PR to ensure we're on Scaleway when using the datasource, let me know if it's ok for you. I'll add unit test asap [13:54] mwak, and sign cla ? [13:55] mwak, the tewst there is fine, and does help some. [13:55] but.. we'd like to avoid hitting a network service if we can [13:56] as any connection to a network service might hang indefinitely [13:56] smoser: OK, the BLKSSZGET ioctl calls bdev_logical_block_size, which calls queue_logical_block_size which is also called for the logical_block_size sysfs entry. [13:56] ie, in many environments a 'wget http://169.254.169.254/' will just block due to firewall rules and the like. [13:56] smoser: So it looks like we can use /sys/.../logical_block_size. :) [13:57] Odd_Bloke, i'd like to fall back if that file isnt present. you plan on that , right ? [13:57] smoser: Yeah, that was the plan. [13:58] ok. the other thing i didnt' say, that got lost in my browser. [13:59] if we can start first partition at 1MB and only use 1MB units in sizes, that'd be good. [13:59] i'm tempted to use 4MB units. [13:59] https://bugs.launchpad.net/maas/+bug/1502259 [14:00] lvm uses 4MB extents by default. [14:01] morning [14:03] smoser: yep sign the cla too [14:04] hey [14:05] mwak, so does that make sense above ^ [14:05] is there any way that we can determine "am i on scaleway" without hitting a network resource ? [14:05] hey. it is time for cloud-inti 2.0 meeting [14:05] smoser: not really [14:05] o/ [14:05] * Odd_Bloke is in a partner meeting, so is MIA. [14:06] channel topic links need to be updated w/ new gerrit paths [14:06] ie - https://review.openstack.org/#/q/project:openstack/cloud-init+status:open,n,z [14:06] ah. yeah, i'll do that natorious [14:07] ok. so looking at that fine url that natiorisou added. [14:08] lol [14:08] a couple that i shoudl grab quickly [14:08] as they address the namespace change. [14:08] natorious, had you made any more progress on yours? [14:09] was just looking over harlowja's comments [14:09] k [14:10] ideally it would be nice if we had a utils.execute or similar shared subprocess call for exec [14:11] natorious, yeah. there is a fairly good one in cluod-init [14:11] utils.subp [14:12] in 0.7 [14:12] that i'd suggest we pull forward [14:14] k [14:14] assuming it is compatible with windows and all [14:15] ah. yeah, it would need some windows work likely. [14:15] it wrapps subprocess. [14:15] subprocess.popen [14:15] but i'd guess we could address anything non windows specific there [14:15] @smoser | ie, in many environments a 'wget http://169.254.169.254/' will just block due to firewall rules and the like. >> do you think we should add a timeout for the test? [14:16] that can easily be done with requests [14:16] niluje, for tests ? [14:16] to check the server's is on scaleway [14:16] (I'm working with mwak there) [14:17] yes, for sure. [14:17] timeouts suck [14:17] we thought about it for a while, and doing something else than a network test didn't seem straightforward [14:17] because you're either safe (meaning unnecessary long wait) or aggressive (meaning your endpoint might not return in time) [14:18] yes, I agree [14:18] niluje, are you in a place wehere you could feed some dmi data to the guest ? [14:18] it seems like generally good practice to identify your platform in such a way [14:19] wrt timeouts... i dont want to enable a datasource by default that could block boot as it waits. I'd *like* to change EC2 to not do that. [14:19] but EC2 was "first" so i'm ok giving them a legacy grandfather-in. [14:20] I totally understand your point of view :) === jgrimm is now known as jgrimm-brb [14:21] unfortunately, at the moment, we can't really rely on something else than network resource and if we do, we won't be sure the test will still work in a few months/years [14:22] we prefered to add this not-so-good-test rather than a better test that might not work in a while [14:22] however if that's a blocker, we'll think about another solution === jgrimm-brb is now known as jgrimm [14:25] smoser: any ideas on windows configdrive detection? [14:26] natorious, i might look at how cloudbase has done it. [14:26] i think they read the device with bsd tar [14:26] ! [14:26] you cant make that stuff up :) [14:27] but at least at one point that was what alexpilloti settled on. [14:27] (honestly, i wuldnt mind having a vfat and iso9660 filesystem reader in pure python) [14:27] oh wow, lol [14:27] yeah, looked at ctypes methods a bit [14:28] should be universal but alot less readable [14:28] i suspect also faster than 'mount ... read ... unmont' for the amount of data we're pulling. [14:28] uni to windows that is [14:30] k, I'll see how their doing it and go from there === cliles_ is now known as cliles === shardy is now known as shardy_afk === pratikma_ is now known as pratikmallya === gondoi is now known as zz_gondoi === shardy_afk is now known as shardy === jgrimm is now known as jgrimm-afk === jgrimm-afk is now known as jgrimm