On Mon, May 22, 2017 at 12:30 PM, Lukas Zapletal <l...@redhat.com> wrote:
> Hey, > > I brought an interesting topic about RHEV support in Foreman, Ori > pointed out that RHEV v3 API is going to be deprecated soon (rumors > are 4.2 which is very soon) and since we are still using v3 via > rbovirt, it's the time to start dicussion in moving towards v4. > > We switched to discussing the idea to implement RHEV v4 support via > newly created API that would allow us easily creating new CR > providers, Fog based or non-Fog based. Concerns were obvious - we do > not want to rewrite Fog or big part of it, on the other hand Marek > pointed out we want very simple API which will be pure Ruby (and not > XML hell) as minimal as it can be. > Which XML hell do you currently have? granted v3 of ovirt api uses XML, but that's surely not related to fog. > Marek pointed out that our API could include things like memory sizes, > pool sizes and other lists (OS lists) which are spread around in Fog, > but we want consistent UX. Our API could be a chance to unify these. > Also our approach can increase performance as we not always need all > flags and data. > > Shim brought an idea to use Facets for the new CR (CRNG - new > generation) which would allow to run multiple versions of compute > resources easily which is something we will need to do for RHEV (we > still want to support oVirt 3.x for some time). > that would be nice, especially if we can separate workers (and not load all into every process memory). > > He also raised concern in going too far in unification, Marek answered > that we should only unify internal things and primarily data (memory). > Greg added that UI is added value and not core goal. He also mentioned > that Fog project lost its momentum a bit and it is not very relevant > to us these days. > > I would disagree around UI, IMHO we need to strive and improve are UI, imho most people who leave foreman do so because of a poor UX, or lack of relevance in new set of techonologies ( cloud born companies, containers only etc). > I brought an idea to solve our long-standing request to proxy CR > communication through proxy, we should keep that in mind when > designing the new API. Which should be definitely as minimal as > possible to allow writing non-Fog providers. Also one problem we could > tackle is to stop doing long HTTP requests from web request thead, we > could consider using Rails Jobs or Foreman Tasks for tasks. > TBH I do believe that fog actually supports proxy (excon and rest client do which imho are the majority of http connections). > > We agreed that we are not getting rid of Fog anytime soon, but we > would love to have the possibility not to use Fog in the future. This > is a good candidate for RFC and we are running out of time thank to > RHEV v3 API deprecation. > 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 > > -- > Later, > Lukas @lzap Zapletal > > -- > 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.
