On Tue, May 23, 2017 at 10:07 AM, Ivan Necas <ine...@redhat.com> wrote: > Timo Goebel <m...@timogoebel.name> writes: > >>> On 22. May 2017, at 12:27, Ohad Levy <ohadl...@gmail.com> wrote: >>> >>> Since we get a lot of lift from fog, especially for popular providers (e.g. >>> ec2) IMHO its not a good idea to remove fog, which means that we balance >>> between community contributions to fog (e.g. stuff we won't "enjoy" as we >>> will not corporate) vs other benefits mentioned above. >>> >>> I for one, is not convinced the effort to not run with fog is less work >>> then adding / updating a fog provider. >>> >>> Ohad >> >> I do agree with Ohad here. I'd focus on improving the fog-providers and not >> trying to reinvent the weel. >> I think, "cloud" topics like focussing on real server orchestration (think >> hostgroup as an auto scaling group) adds more benefits for a user. A user >> usually doesn't care about the library used. Using foreman as a tool to >> setup a cloud or container environment on bare metal does add value. >> >> Fog doesn't do any network orchestration, yet. If we add this (e.g. >> provision a vlan on a switchport or some SDN), that would be a valid >> point imho to switch the library. > > > I think what's missing is not well-defined layer between Foreman and > Fog, and we perhaps over-use the Fog as the unification layer. > > I feel quite a lot of risk in connecting the migration between oVirt v3 > vs. v4 with introduction of new layer into the Foreman to serve better > for our purposes, that would not use the Fog. Especially when the APIv4 > is pretty close. > > If we make fog oVirt provider use APIv4, we still have chance that the > code will be used outside of Foreman, that will make the implementation > better: from the past - did we experience this happening in oVirt or > other providers? (my feeling is that they did, but not monitoring that > that much) > > Long story short: > > 1. I agree we should not expose Fog as THE layer we use in the UI/API, > to add the entry points that are interesting for use but not for fog > that much
+1 for adding a layer between our UI/API and fog or potentially some other library we might decide to use (or write) in future. I think it's an important step, regardless of whether we decide to use fog for oVirt v4 api or not. > > 2. we should continue with fog-ovirt to use APIv4 > > Even though it looks compelling to connecting this two, I would rather > take it independent steps. > > -- Ivan > >> >> - Timo >> >> -- >> You received this message because you are subscribed to the Google Groups >> "foreman-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to foreman-dev+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
