Our API has versioning and we already discussed moving towards V3, we are not using this mechanism and we should improve in that. Also we are close to 2.0 release and the API change could be additional reason for those who needs reasons to change major versions
Could you expand on this? I don’t see where the large number of objects in in the virtual proxy case?
I’m quite ok with the rest of what you wrote. I guess we need more developers now to chime in and express their preference.
And by developers, I also meant also upstream users and PMs (that represent the downstream users).
Right, I understand now. I thought the Virtual Proxies were per feature, but they are not.
Please disregard that row.
If we are changing the API for assigning proxy, I think we should change it to something better that “proxy group”. I like @iNecas’s idea about proxy group being just another kind of proxy. I think it does not matter if STI is used only for blank object hierarchy and all the logic is added via composition. But I see huge advantage of keeping “proxy” API for users who scripted or build new UI on top of our API. I’ve heard about such projects not only on this cfgmgmt camp.
If majority thinks it’s worth of changing API (-1 here) and we decide to change the API (even if that means v3) maybe we should rename the proxy to something more meaningful. A new object called e.g. Worker. Proxy group and Smart proxy would be just two implementations of Foreman’s Worker. Actually Worker would work quite well with Foreman name as Foreman usually have multiple workers who work on his/her orders
I strongly believe this API needs to change, it isn’t fit for purpose anymore.
I’ve spent almost a year writing this code and convincing people, only for people to agree in Ghent and change their mind a couple of weeks later.
Taking on technical debt and being unable to inovate is the biggest thing that will drive new & existing users away in equal measure. That’s exactly what the DevOps movement is all about for business.
I’m not saying we should not care about the past and blindly change things, I’m saying everything we change should be our best effort to meet users needs for today and tomorrow. We should provide migrations and deprecations and implement things exactly how we would if we were to start the project today.
Some bigger examples of this:
Pulp (who are creating Pulp 3)
CFEngine (who didn’t change, now look at Puppet & CFEngine’s userbase’s)
Netflix (they destroyed a whole industry)
Yes - you could argue that the STI approach does meet users needs, and it probably does, but it’s so complex and hacky that we will be unable (or hard to) to innovate after. Nor am I saying my approach is definitely the correct one, I am simply just saying that that API needs to change, it needs to allow for separate Routing than Foreman to Smart Proxies & Grouping of Smart Proxies. This is exactly how you configure systems outside of Foreman, using Hostnames, DNS & config files. Foreman should be no different. The fact it is is actually confusing to new users.
Taking on so much technical debt and being unable to innovative will slowly kill our upstream user base and downstream customer base. People don’t have any loyality, when something is better somewhere else they will move, our past should not stop us changing things.
My understanding in Ghent was to change API to start using “route_id” which to me was acceptable change as that is understandable for non HA users. Now IIUC we ended up with “proxy_group_id” which does not sound as a good aproach. Not because of the change itself, but because in API/hammer it won’t be easy to make it clear for users, who are not interested in HA. I see 2 options here, do a change of API, but make it friendly for non HA users, or don’t make a change and introduce STI. I call it STI but it doesn’t have to use rails STI.
So I’m going to summarize what I think we (@iNecas, @Marek_Hulan & I) have agreed, in an effort to get more feedback (+1 or -1 and why?) from other @Developers. Obviously guys correct me if anything I say is not correct.
We are going to create a new Route object that can be assigned to one or many Smart Proxies and hold a Hostname attribute that is used by clients to connect to the Smart Proxy(ies). This Route object will also be assigned to Hosts, Subnets and Domain in-place of the current Smart Proxy associations. So
puppet_proxy_id will become
- The way Foreman will communicate to Smart Proxies is unchanged.
- Where a Route has more than one Smart Proxy Foreman will orchestrate on all Smart Proxies providing that the features supports multiple nodes.
- We think Route is the best name for this. Kubernetes call it a Route, but don’t use it for DHCP where we don’t feel Route quite makes sense. Other suggestions are strongly encouraged unless it is
Thanks for the wrap-up. Names, hmmmm.
“Associate DHCP proxy route with the subnet…”
“Go to domains, open the domain, select appropriate DNS proxy route…”
What’s wrong with proxy group again? Other ideas:
Thanks for the suggestions @lzap I think they have the problem as
Group implies “more than 1” but this object isn’t just for routing attributes for “more than 1” Smart Proxy, its for every Smart Proxy weather it is part of a Group or not.
I think the name
Route shows how and what this object is used for in both scenarios (1 or many Smart Proxies), but like you say Route isn’t really correct for DHCP
+1 for the implementation. Bikeshedding on the name, I do agree Route feels weird. Set or Pool would feel more accurate to me, and I’ll note that my expectation of such objects is that it has “1 or more” members, not “more than 1”. We don’t enforce Hostgroups having at least two members, after all
Also kudos to the excellent discussion here. You’re all fantastic
@Marek_Hulan @iNecas Since you’re both looking for feedback from users directly, would one of you or someone else (@Gwmngilfen ?) spend 30 seconds asking users to come over to User Survey: Supporting HA Smart Proxies and voice an opinion during the next community demo?
I would volunteer myself, but I’m not really able to commit to being present, come demo time
I guess this could go in the April newsletter too @sean797?
Yes - AFAIC the more feedback we get the better.
@iNecas @Marek_Hulan So I’ve left it a month on the support/users forum section, User Survey: Supporting HA Smart Proxies, it doesn’t seem like anyone has been forthcoming with feedback, I’m not sure why maybe its because the subject is fairly complicated, maybe its because nobody cares
Anyway, I purpose we move ahead with this, I think it’s fair to say most are onboard with this implementation.
TBH, there are still some gaps in my understanding on how the re-designed version will look look, and especially, how the user interaction will look like.
Could you prepare a deep-dive, that would go again through the proposal, but focus at the differences in the workflow, both in UI and CLI, before and after the change. I’m interested in two scenarios:
- a user that wants to have the HA smart proxies
- a user that doesn’t want any HA
Looking at this from user perspective can hopefully put more lights at this also for the users to see what this proposal is about.
Okay, lets set something up. I think those and the minimum people that are required, obviously though anyone is welcome
One note while I am working on a customer request: Can we support IP addresses as smart proxy pool names? They have an environment without DNS and setting that up today is tricky. This could support it from the day one maybe. Just a thought.
Yes! That’s one of the nice things about smart proxy pools, they are no constrained. Smart Proxy URLs rightly have constraints because they are used for foreman <-> proxy communication, but smart proxy pools are free!
It’ll just require the certificate to validate it
subjectAltName = IP:10.0.0.10