[01:29] needs-help-guy, What you need? :o === aaii_ is now known as aaii === aaii_ is now known as aaii === aaii__ is now known as aaii [13:57] I have this in my cloud-init conf: [13:57] https://www.irccloud.com/pastebin/opt2FxzR/ [13:57] nevertheless my ephemeral disk is getting formatted with 'vfat'. Is there a way I can tell cloud-init to do nothing with the volume rather than (as it seems to be doing now) default behavior? [14:15] andrewbogott: are you on Azure ? that's the only cloud that I know of that has default configuration for formatting an ephemeral disk; cloud-init doesn't have default values for those keys, rather they're omitted. on Azure, there's built-in cloud-config which includes those keys to configure the ephemeral disk. I think if you set them to something else, like disk_setup: disabled or such; that should replace the built-in [14:15] config when it merges and if the config isn't valid should ignore it. The default format of azure's ephemeral disk is NTFS formatted. [14:15] openstack [14:15] I will dry 'disabled' for my next test, thanks! [14:16] of course it's also possible that something other than cloud-init is formatting [14:16] ah, let me look at the openstack datasource, it too has some defaults for ephemeral formatting [14:17] oh, IIRC, the openstack metadata service typically includes config for the ephemeral disk as well; [14:23] smoser: quick question on growpart. I've read the whole file but I might be missing something: does this script is self contained? Does it use any other script in the repository? [14:24] the openstack metadata service typically includes a 'block-device-mapping' config which controls this, https://docs.openstack.org/nova/queens/user/block-device-mapping.html ; [14:26] andrewbogott: but, AFAIK, the ephemeral disk is already formatted and mountable; Azure is the only datasource which *reformats* the disk for linux since it's disk is NTFS formatted by default; so if you're getting VFAT on a disk, I suspect that's the cloud's doing. if you like, I can examine a cloud-init.log to see what happened. [14:27] rharper: thanks, I'll check the logs as well [14:29] * andrewbogott stops reading cloud-init docs and starts reading openstack docs [14:38] smoser: nevermind, I think I found my problem :-D [15:24] otubo: sorry, iddn't see. i think the answer is yes. it is self contained. [15:29] andrewbogott, rharper it hink that openstack might present a FAT filesystem based on configuration [15:30] smoser: looks like, although I can't figure out how to configure it so far [15:30] * smoser cloning source [15:30] somehow that got big! [15:32] I saw block-device-mapping has a v2 ... which is more interesting ... that'd be nice to support that in cloud-init [15:33] smoser: right, I suspect this is related to what block service configuration is used ... the classic cinder exposed a disk with ext(something) on it ... [15:34] https://github.com/openstack/nova/blob/9311f541499f711de064505fab3b24e20451d433/nova/conf/compute.py#L129 [15:36] i swear you can configure that on a image basis, but i dont see it. [15:38] maybe you can on launch? in the block device mapping... [15:38] nova/block_device.py: [15:38] sorry. paste fail [15:38] https://wiki.openstack.org/wiki/BlockDeviceConfig [15:40] I've done block-device-mapping, but you need to create the storage first (at least in cinder) and then map the cinder device to the VM (at launch or afterwards) [15:41] so maybe something other than cinder creates vfat devices by default [15:41] flavor lets me specify an ephemeral disk size, that's what I'm using. As far as I know it doesn't let me set anything beyond size though... [15:41] I'm thinking 'what to do with ephemeral storage' must be a cloud-wide setting [15:41] yeah, I wouldn't expect any controls; what block device provides ephemeral storage is likely a cloud-level config [15:41] right [15:42] troubling that default_ephemeral_format doesn't even take a 'vfat' setting and yet that's what I'm getting [15:42] one way to test is to allocate a new block device (from whatever block service you have) and attach it to a running instance, and then you can inspect the newly added disk for what fs is on it, etc ... [15:42] I'll try setting it to None and see what it does :) [15:43] Oh, newly created cinder volumes are definitely unformatted [15:43] And I have a bunch of code that supports that behavior (formatting in puppet later on) [15:43] it could be a portability setting ... cross OS filesystem [15:43] so I just want ephmeral volumes to be... also like that [15:44] well, that's counter to ephemeral volumes IIUC, they're always preformatted so they're mountable by default rather than waiting for (or requiring) the OS in the instance to do the work; [15:44] yeah. It happens that in our cloud we're only using them for this one particular case [15:45] But it might be that 'don't format' isn't supported on the backend, for the reason you just said [15:48] virt_mkfs = [] [15:48] (Multi-valued) Name of the mkfs commands for ephemeral device. [15:48] The format is = [15:48] https://docs.openstack.org/ocata/config-reference/compute/config-options.html [15:49] appears to be configurable on the compute side [15:57] you are way ahead of me [15:57] seems like virt_mkfs probably keys off of something else that specifies the format? [15:57] although I can break it on purpose [15:58] looks to me like it's a compute side config value, set on each compute node [15:59] I wonder if the flavor has an OS setting ? [16:00] it's a list of pairs, OS Type -> mkfs.foo ... so some OS value results in a mkfs.vfat ... I'd think that OS Type == Windows, is going to get you a mkfs.vfat .. where as OS Type == Linux should get you mkfs.ext4 or so ... [16:06] * andrewbogott nods [16:06] makes sense [16:10] I'm checking in with the affected user now, they might be happy with it just being ext4 instead of vfat (which is easy to fix, that's just default_ephemeral_format)