[01:29] <aaii_> needs-help-guy, What you need? :o
[13:57] <andrewbogott> I have this in my cloud-init conf:
[13:57] <andrewbogott> https://www.irccloud.com/pastebin/opt2FxzR/
[13:57] <andrewbogott> 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] <rharper> 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] <rharper> 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] <andrewbogott> openstack
[14:15] <andrewbogott> I will dry 'disabled' for my next test, thanks!
[14:16] <andrewbogott> of course it's also possible that something other than cloud-init is formatting
[14:16] <rharper> ah, let me look at the openstack datasource, it too has some defaults for ephemeral formatting
[14:17] <rharper> oh, IIRC, the openstack metadata service typically includes config for the ephemeral disk as well;
[14:23] <otubo> 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] <rharper> 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] <rharper> 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] <andrewbogott> rharper: thanks, I'll check the logs as well
[14:29]  * andrewbogott stops reading cloud-init docs and starts reading openstack docs
[14:38] <otubo> smoser: nevermind, I think I found my problem :-D
[15:24] <smoser> otubo: sorry, iddn't see. i think the answer is yes. it is self contained.
[15:29] <smoser> andrewbogott, rharper  it hink that openstack might present a FAT filesystem based on configuration 
[15:30] <andrewbogott> smoser: looks like, although I can't figure out how to configure it so far
[15:30]  * smoser cloning source
[15:30] <smoser> somehow that got big!
[15:32] <rharper> I saw block-device-mapping has a v2 ... which is more interesting ... that'd be nice to support that in cloud-init 
[15:33] <rharper> 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] <smoser> https://github.com/openstack/nova/blob/9311f541499f711de064505fab3b24e20451d433/nova/conf/compute.py#L129
[15:36] <smoser> i swear you can configure that on a image basis, but i dont see it.
[15:38] <smoser> maybe you can on launch? in the block device mapping... 
[15:38] <smoser>  nova/block_device.py:
[15:38] <smoser> sorry. paste fail
[15:38] <smoser>  https://wiki.openstack.org/wiki/BlockDeviceConfig
[15:40] <rharper> 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] <rharper> so maybe something other than cinder creates vfat devices by default 
[15:41] <andrewbogott> 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] <andrewbogott> I'm thinking 'what to do with ephemeral storage' must be a cloud-wide setting
[15:41] <rharper> yeah, I wouldn't expect any controls; what block device provides ephemeral storage is likely a cloud-level config 
[15:41] <rharper> right
[15:42] <andrewbogott> troubling that default_ephemeral_format doesn't even take a 'vfat' setting and yet that's what I'm getting
[15:42] <rharper> 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] <andrewbogott> I'll try setting it to None and see what it does :)
[15:43] <andrewbogott> Oh, newly created cinder volumes are definitely unformatted
[15:43] <andrewbogott> And I have a bunch of code that supports that behavior (formatting in puppet later on)
[15:43] <rharper> it could be a portability setting ... cross OS filesystem 
[15:43] <andrewbogott> so I just want ephmeral volumes to be... also like that
[15:44] <rharper> 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] <andrewbogott> yeah.  It happens that in our cloud we're only using them for this one particular case
[15:45] <andrewbogott> But it might be that 'don't format' isn't supported on the backend, for the reason you just said
[15:48] <rharper> virt_mkfs = [] 	
[15:48] <rharper> (Multi-valued) Name of the mkfs commands for ephemeral device.
[15:48] <rharper> The format is <os_type>=<mkfs command>
[15:48] <rharper> https://docs.openstack.org/ocata/config-reference/compute/config-options.html 
[15:49] <rharper> appears to be configurable on the compute side 
[15:57] <andrewbogott> you are way ahead of me
[15:57] <andrewbogott> seems like virt_mkfs probably keys off of something else that specifies the format?
[15:57] <andrewbogott> although I can break it on purpose
[15:58] <rharper> looks to me like it's a compute side config value, set on each compute node 
[15:59] <rharper> I wonder if the flavor has an OS setting ? 
[16:00] <rharper> 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] <andrewbogott> makes sense
[16:10] <andrewbogott> 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)