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