https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# hobbyfarm
a
This message was deleted.
f
Sure thing. I can answer those hopefully
👍 1
m
ATM, there’s two options for adding webinterfaces: • Manual addition when you’re in the web interface • Pre-defined web interfaces My expectation would be that the manifest for the VMT would simply reference the pre-defined web interface. However, it looks like instead what happens is as follows: 1. You generate the pre-defined web interface via a manifest. 2. You must go into the admin interface to attach the pre-defined web interface to the VMT. 3. When the pre-defined web interface is attached to the VMT, the manifest isn’t updated to reference the pre-defined web interface manifest, but instead takes the information from it and adds to the webinterfaces key, adding to the manual web interfaces that have been created via the admin interface in the VMT. So, my questions are as follows: • What is the point of the pre-defined web interface resource? • Why wouldn’t the VMT manifest reference these instead of doing extra work to convert to JSON and patching the existing VMT manifest? • Why not create a pre-defined manifest whenever one is created manually in the VMT admin interface and reference it from the VMT manifest instead of using the JSON?
I ask, as I’m attempting to build some automation around specific tasks. It’s far simpler to create one or more pre-defined web interfaces and to have them referenced via the VMT manifest instead of having to convert them to JSON and inject them into the VMT manifest. The other problem is the lack of ability to actually attach the pre-defined manifest without having to do some extra work. I’d like to just have a field called 
preDefinedInterfaces
or something like that which I can list one or many of the existing pre-defined web interface manifests.
So, I’m just trying to best understand the logic so I can set expectations moving forward.
f
I get the point. Can I i give you the answer tomorrow? I think I do not have time today to answer all these.
m
Absolutely. There’s zero rush here. I have some stuff to demo for you guys after the holidays, which could also help explain the context of the work I’ve been doing.
As discussed previously, I’ve developed a Helm chart which can be used for populating all configurations instead of having to do it all manually via the web interface. So I’m trying to understand the limits of this approach.
f
That would be great. We can still improve the webinterfaces with things you mentioned.
👍 1
m
OK, have a great evening. I’ll touch base tomorrow or Friday. 🙂
👍 1
f
Okey so regarding the predefined webinterfaces: Yes it would be lovely if they could only be referenced by the VMT. I would not always create a predefined webinterface, this should only be used for webinterfaces that are shared for many VMTs and not if i need the webinterface for exactly one scenario. The initial implementation had no predefined webinterfaces, they were an addition to the webinterfaces that is why they can not be referenced right now. If we would rework this again we should build webinterfaces that can be inherited from the predefined webinterface.
as you mentioned automation would also be easier when predefined webinterfaces could be referenced
one problem that we would face is that the cloud init has to be calculated when a machine starts -> but this would also enable us to use variabless in cloud init data like the metadata.name of the VM etc.
m
@faint-optician-47536 Thanks for the feedback. After thinking about it for a bit, it seems that the logical approach would be to not have 
PredefinedInterfaces
at all, but just have a resource called 
Interfaces
which can store all interfaces, either pre-defined or ones that are created for a VMT on the fly. This would allow one or more 
Interfaces
to be used for the initial VMT, but also reusable across two or more VMTs. This would make the interfaces much more valuable, as I can create one time and reuse it as many times as needed over time. I’m thinking through the problem you stated regarding the cloud-init. Could you elaborate further? Wouldn’t you be able to poll this configuration regardless of what resource that is storing it prior to launching the virtual machine? I am also a big fan of the idea of defining additional variables that can be passed to the VM.
f
You could call them that. However we should ensure that a user is clear that if he adopts a interface, other VMTs are affected too
🤔 1
m
Can you elaborate what you mean by that? Logically, I think the problem is that if someone changes an interface, then any VMTs that are using that interface would be affected. Is that what you mean in this scenario?
f
correct.
m
AH, OK. We’re on the same page then.
f
for example we had docker installed with a specific version, now we update the version for one VMT and all others get updated and might break because they were not tested
m
Got it. I think of Interfaces more from the standpoint that they’re exposing a given port, but given that cloud-init exists, it can actually be more breaking than that.
Maybe the logic is to make the resources immutable?
For example, PVs can impact pods that make use of the PV, so modifying the PV would be breaking for all pods that make use of it. So, as a result, PVs are immutable?
f
i think we have to talk about this in the next meeting 😄
m
Absolutely! It’s a very, very interesting problem to solve for.
f
it is
m
I appreciate your consideration and time with me to talk it through.
f
sure! lets improve this 😄
🔥 1
m
I will be on Christmas holiday for the next two weeks, but I will try to make the call next week. Otherwise, we can discuss on January 2nd?
f
okey, i will also be on christmas holiday and unsure if i can make it next tuesday. I try to make it on the 2nd
👍 1
m
Awesome. Have a great holiday!
f
you too!
🎄 1
Open in Slack
PreviousNext
Powered by