On Tue, Dec 4, 2018 at 2:16 PM Dan Prince <dprince@redhat.com> wrote:
On Tue, 2018-12-04 at 12:08 +0100, Flavio Percoco wrote:
Greetings,
I've been working on a tool that requires creating CoreOS nodes on OpenStack. Sadly, I've hit the user data limit, which has blocked the work I'm doing.
One big difference between CoreOS images and other cloud images out there is that CoreOS images don't use cloud-init but a different tool called Ignition[0], which uses JSON as its serialization format.
The size of the configs that I need to pass to the instance is bigger than the limit imposed by Nova. I've worked on reducing the size as much as possible and even generating a compressed version of it but the data is still bigger than the limit (144 kb vs 65kb).
I'd like to understand better what the nature of the limit is (is it because of the field size in the database? Is it purely an API limit? Is it because it causes problems depending on the vendor? As far as I can tell the limit is just being enforced by the API schema[1] and not the DB as it uses a MEDIUMTEXT field.
I realize this has been asked before but I wanted to get a feeling of the current opinion about this. Would the Nova team consider increasing the limit of the API considering that more use cases like this may be more common these days?
I think EC2 only gives you 1/4 of what Nova does (16KB or so). So it would seem Nova is already being somewhat generous here.
Yeah, I checked before sending this and I thought that regardless of what EC2 is doing, I think it'd be nice for us to consider the use case.
I don't see any harm in increasing it so long as the DB supports it (no DB schema change would be required).
I wonder if pairing userdata with a token that allowed you to download the information from another (much larger) data source would be a better pattern here though. Then you could make it as large as you needed.
This is the current solution, which has allowed me to move forward with the work I'm doing. Regardless, I would like us to discuss this. I'd rather have the limit in Nova increased than adding a dependency on another service that would, very likely, only be used for this specific use case. Flavio