[foreman-dev] [RFC] Combine Katello and Bastion UI projects

[Walden Raines]

Hey y'all,

I have just created an RFC to combine the UI code from Katello and Bastion.  
Please review and add comments to the PR [1] .

Thanks,
Walden

[1] https://github.com/theforeman/rfcs/pull/13

-- 
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.

Re: [foreman-dev] Re: RFC for foreman_api_v3

[David Davis]

It’s Y2K all over again.


David

On Mon, Aug 29, 2016 at 9:23 AM, Justin Sherrill 
wrote:

> On 08/28/2016 01:49 AM, Joseph Magen wrote:
>
>
> On Fri, Aug 26, 2016 at 10:47 AM, Dominic Cleal  wrote:
>
>> On 26/08/16 06:58, Joseph Magen wrote:
>> > I created a RFC for a plugin called foreman_api_v3
>> > 
>> and
>> > the initial repo at github.com/isratrade/foreman_api_v3
>> > . If the community
>> accepts,
>> > I am happy to move this repo to theforeman/foreman_api_v3
>> >
>> > I choose to make this a plugin rather than a PR so it is optional for
>> > users and doesn't affect the core code.
>>
>> Please consider calling it something else that won't cause confusion for
>> users with Foreman's own API versioning.
>>
>
> I can rename the plugin to *foreman_jsonapi* and change to version to v21
> (meaning v2.1 since it inherits from v2), so it would look like this
>
> GET api/api/v21/hosts
>
>
> what happens when we get to version 21 of the api which in my calculations
> will occur around 2325?  :)
>
>
>
> What do you think?
>
>
>
>
>> --
>> Dominic Cleal
>> domi...@cleal.org
>>
>
>
> On Fri, Aug 26, 2016 at 11:36 PM, Tomas Strachota <
> tstrach...@redhat.com> wrote:
>
>> On 08/26/2016 07:58 AM, Joseph Magen wrote:
>>
>>> Hi all,
>>>
>>> I created a RFC for a plugin called foreman_api_v3
>>> 
>>> and
>>> the initial repo at github.com/isratrade/foreman_api_v3
>>> . If the community accepts,
>>> I am happy to move this repo to theforeman/foreman_api_v3
>>>
>>> I choose to make this a plugin rather than a PR so it is optional for
>>> users and doesn't affect the core code. The initial repo only includes
>>> the GET `index` and `show` actions. The PUT/PATCH/POST/DELETE actions
>>> need to be added. Also, there are currently no functional tests in the
>>> repo, so a lot more work needs to be done.
>>>
>>> Note that I inherited V2 so that V3 controllers look like this
>>>
>>> module Api
>>>   module V3
>>> class DomainsController < V2::DomainsController
>>>
>>> but the response is changed.
>>>
>>>   def index
>>> super
>>> render json: @domains,
>>>fields: @fields_hash,
>>>include: @include_array,
>>>each_serializer: DomainSerializer
>>>   end
>>>
>>> For some background, the Foreman API v2 is more than 3 years old. When I
>>> implemented v2, I used conventions that I thought were good at the time.
>>> The katello had some slightly different conventions, and we weren't
>>> always in sync. This created some challenges for Satellite6 as a single
>>> RH product.
>>>
>>> The goal of JSON API is to create a standardization that is *Flexible,
>>> Consistent, and Fast *-- we can all agree with these goals.
>>>
>>>
>> Thanks for sending that, Joseph. Jsonapi.org is nice specification and I
>> like how it structures the data. The ability to include additional
>> resources into the response is very handy and making the katello and
>> foreman api consistent would be good too. But that alone wouldn't be enough
>> to make switch to jsonapi. In my opinion main painpoints of the current api
>> v2 are elsewhere. Firstly I miss adding associated resources without having
>> to send all what's currently included. Second main issue is inconsistent
>> error responses (we've improved with that but it's still not ideal).
>> Jsonapi.org has cures for both [1] [2], so I'm not against at all that
>> but we mustn't stop just at changing the output format.
>>
>
> Please explain the other pain points in v2 besides [1] [2]
>
> Speaking about the format change, since getting consistent with katello is
>> one of motivations for the change, I'd like to hear from somebody with
>> expertise in that field how difficult would be to bend the UI code to use
>> the new format.
>
> Just to make sure we actually won't unintentionally put more obstacles in
>> katello's way.
>>
>
> I assume you mean using RABL to generate the new output format when
> keeping the same v2 controllers. IMHO, this would be a bigger headache for
> both Koreman and Katello. This would still lead to v3 since there are
> breaking changes. Maybe I don't understand your question fully.
>
>
>
>> If we decide that jsonapi is the way to go for v3 I think it would be
>> better to implement it as part of the foreman core. We can clearly mark it
>> as devel preview with no guarantees, let it evolve alongside with v2 and
>> freeze when we're happy with it.
>>
>
> I don't see the advantage of implementing a new api as part of core until
> if/when it is stable and has community adoption.
>
>
>
>>
>> [1] http://jsonapi.org/format/#crud-updating-relationships
>> [2] http://jsonapi.org/format/#errors
>>
>> Here's some more links that 

Re: [foreman-dev] Re: RFC for foreman_api_v3

[Justin Sherrill]

On 08/28/2016 01:49 AM, Joseph Magen wrote:


On Fri, Aug 26, 2016 at 10:47 AM, Dominic Cleal > wrote:


On 26/08/16 06:58, Joseph Magen wrote:
> I created a RFC for a plugin called foreman_api_v3
>
>
and
> the initial repo atgithub.com/isratrade/foreman_api_v3

> >. If the community
accepts,
> I am happy to move this repo to theforeman/foreman_api_v3
>
> I choose to make this a plugin rather than a PR so it is
optional for
> users and doesn't affect the core code.

Please consider calling it something else that won't cause
confusion for
users with Foreman's own API versioning.


I can rename the plugin to *foreman_jsonapi* and change to version to 
v21 (meaning v2.1 since it inherits from v2), so it would look like this


GET api/api/v21/hosts


what happens when we get to version 21 of the api which in my 
calculations will occur around 2325?  :)




What do you think?


--
Dominic Cleal
domi...@cleal.org 



On Fri, Aug 26, 2016 at 11:36 PM, Tomas Strachota 
> wrote:


On 08/26/2016 07:58 AM, Joseph Magen wrote:

Hi all,

I created a RFC for a plugin called foreman_api_v3
>
and
the initial repo at github.com/isratrade/foreman_api_v3

>. If the
community accepts,
I am happy to move this repo to theforeman/foreman_api_v3

I choose to make this a plugin rather than a PR so it is
optional for
users and doesn't affect the core code. The initial repo only
includes
the GET `index` and `show` actions. The PUT/PATCH/POST/DELETE
actions
need to be added. Also, there are currently no functional
tests in the
repo, so a lot more work needs to be done.

Note that I inherited V2 so that V3 controllers look like this

module Api
  module V3
class DomainsController < V2::DomainsController

but the response is changed.

  def index
super
render json: @domains,
   fields: @fields_hash,
   include: @include_array,
   each_serializer: DomainSerializer
  end

For some background, the Foreman API v2 is more than 3 years
old. When I
implemented v2, I used conventions that I thought were good at
the time.
The katello had some slightly different conventions, and we
weren't
always in sync. This created some challenges for Satellite6 as
a single
RH product.

The goal of JSON API is to create a standardization that is
*Flexible,
Consistent, and Fast *-- we can all agree with these goals.


Thanks for sending that, Joseph. Jsonapi.org is nice specification
and I like how it structures the data. The ability to include
additional resources into the response is very handy and making
the katello and foreman api consistent would be good too. But that
alone wouldn't be enough to make switch to jsonapi. In my opinion
main painpoints of the current api v2 are elsewhere. Firstly I
miss adding associated resources without having to send all what's
currently included. Second main issue is inconsistent error
responses (we've improved with that but it's still not ideal).
Jsonapi.org has cures for both [1] [2], so I'm not against at all
that but we mustn't stop just at changing the output format.


Please explain the other pain points in v2 besides [1] [2]

Speaking about the format change, since getting consistent with
katello is one of motivations for the change, I'd like to hear
from somebody with expertise in that field how difficult would be
to bend the UI code to use the new format. 


Just to make sure we actually won't unintentionally put more
obstacles in katello's way.


I assume you mean using RABL to generate the new output format when 
keeping the same v2 controllers. IMHO, this would be a bigger headache 
for both Koreman and Katello. This would still lead to v3 since there 
are breaking changes. Maybe I don't understand your question fully.


If we decide that jsonapi is the way to go for v3 I think 

Re: [foreman-dev] Re: RFC for foreman_api_v3

[Tom McKay]

On Mon, Aug 29, 2016 at 7:33 AM, Tomas Strachota 
wrote:


>> If we decide that jsonapi is the way to go for v3 I think it would
>> be better to implement it as part of the foreman core. We can
>> clearly mark it as devel preview with no guarantees, let it evolve
>> alongside with v2 and freeze when we're happy with it.
>>
>>
>> I don't see the advantage of implementing a new api as part of core
>> until if/when it is stable and has community adoption.
>>
>>
> I think that it can actually attract the community more when it's in the
> core and users/devs can start experimenting with it just by changing the
> version in url. The result is more or less the same. The only difference is
> in entry barriers (installing a plugin vs. changing number in url).
>

Personally I like the API being a plugin that's treated like core in terms
of tests-must-pass, etc. The benefits I can think of at a quick glance:
+ all changes to routes and parameters in one uncluttered place
(uncluttered meaning not a mix of other "core" PRs)
+ all changes to json body output format in one uncluttered place (big
headache currently when data relied on changes)
+ plugin github ack/nack/mergers dedicated devs committed to not breaking
api (these devs know the space and mission statement)


Negatives are:
+ have to submit two PRs, one to foreman one to api plugin, when changes
impacting both
+ would other plugins (katello, rex, etc.) be encouraged/required to have
separate github repo for their APIs too?

Writing a new api via a plugin is not a new idea as several of the
katello/Satellite-6 devs/users/customers have thought about doing this for
some time. I know Joseph's plugin arises from his work but it's great to
see this. I also like that it's based on jsonapi.org which would act as the
arbitrer of disagreements in style and such. Thanks Joseph for starting
this work!

-- 
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.

Re: [foreman-dev] Re: RFC for foreman_api_v3

[Tomas Strachota]

On 08/28/2016 07:49 AM, Joseph Magen wrote:


On Fri, Aug 26, 2016 at 10:47 AM, Dominic Cleal > wrote:

On 26/08/16 06:58, Joseph Magen wrote:
> I created a RFC for a plugin called foreman_api_v3
>
>
and
> the initial repo at github.com/isratrade/foreman_api_v3

> >. If the community
accepts,
> I am happy to move this repo to theforeman/foreman_api_v3
>
> I choose to make this a plugin rather than a PR so it is optional for
> users and doesn't affect the core code.

Please consider calling it something else that won't cause confusion for
users with Foreman's own API versioning.


I can rename the plugin to *foreman_jsonapi* and change to version to
v21 (meaning v2.1 since it inherits from v2), so it would look like this

GET api/api/v21/hosts

What do you think?




--
Dominic Cleal
domi...@cleal.org 



On Fri, Aug 26, 2016 at 11:36 PM, Tomas Strachota > wrote:

On 08/26/2016 07:58 AM, Joseph Magen wrote:

Hi all,

I created a RFC for a plugin called foreman_api_v3
>
and
the initial repo at github.com/isratrade/foreman_api_v3

>. If the community
accepts,
I am happy to move this repo to theforeman/foreman_api_v3

I choose to make this a plugin rather than a PR so it is
optional for
users and doesn't affect the core code. The initial repo only
includes
the GET `index` and `show` actions. The PUT/PATCH/POST/DELETE
actions
need to be added. Also, there are currently no functional tests
in the
repo, so a lot more work needs to be done.

Note that I inherited V2 so that V3 controllers look like this

module Api
  module V3
class DomainsController < V2::DomainsController

but the response is changed.

  def index
super
render json: @domains,
   fields: @fields_hash,
   include: @include_array,
   each_serializer: DomainSerializer
  end

For some background, the Foreman API v2 is more than 3 years
old. When I
implemented v2, I used conventions that I thought were good at
the time.
The katello had some slightly different conventions, and we weren't
always in sync. This created some challenges for Satellite6 as a
single
RH product.

The goal of JSON API is to create a standardization that is
*Flexible,
Consistent, and Fast *-- we can all agree with these goals.


Thanks for sending that, Joseph. Jsonapi.org is nice specification
and I like how it structures the data. The ability to include
additional resources into the response is very handy and making the
katello and foreman api consistent would be good too. But that alone
wouldn't be enough to make switch to jsonapi. In my opinion main
painpoints of the current api v2 are elsewhere. Firstly I miss
adding associated resources without having to send all what's
currently included. Second main issue is inconsistent error
responses (we've improved with that but it's still not ideal).
Jsonapi.org has cures for both [1] [2], so I'm not against at all
that but we mustn't stop just at changing the output format.


Please explain the other pain points in v2 besides [1] [2]


That was all. I can't think of anything else at the moment besides the 
inconsistency that you mentioned.




Speaking about the format change, since getting consistent with
katello is one of motivations for the change, I'd like to hear from
somebody with expertise in that field how difficult would be to bend
the UI code to use the new format.

Just to make sure we actually won't unintentionally put more
obstacles in katello's way.


I assume you mean using RABL to generate the new output format when
keeping the same v2 controllers. IMHO, this would be a bigger headache
for both Koreman and Katello. This would still lead to v3 since there
are breaking changes. Maybe I don't understand your question fully.



I didn't mean anything about implementation side of the api (rabl vs. 
serializers vs. 

[foreman-dev] Change in host/managed possibly affecting your plugin

[oprazak]

Hi everyone,
if you are a plugin developer/maintainer and your plugin has host_extension 
that adds inheritable attributes to host, then read on. In a recently 
merged bugfix [1], there has been a change that possibly breaks your plugin.
I have already submitted PRs to katello [2] and foreman_openscap [3], but 
if your plugin uses :alias_method_chain for set_hostgroup_defaults method, 
you will need to make a minor change.

O.

[1] https://github.com/theforeman/foreman/pull/3612 
[2] https://github.com/Katello/katello/pull/6280
[3] https://github.com/theforeman/foreman_openscap/pull/195/files


-- 
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.

Re: [foreman-dev] Call for help: Installer changes for UEFI

[Lukas Zapletal]

> > I think, we should not depend on downloads from the (evil/firewalled) 
> > internet.
> 
> I agree, but it does not appear to be present in Debian repos.

I actually found a way how to build EFI grub from modules, updated the
description:

http://projects.theforeman.org/issues/12635

Looks like some decent Puppet code needs to be written :-)

-- 
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.

Re: [foreman-dev] Call for help: Installer changes for UEFI

[Lukas Zapletal]

> I think, we should not depend on downloads from the (evil/firewalled) 
> internet.

I agree, but it does not appear to be present in Debian repos.

> What do you think of packaging this?

Not so keen about it. But it's an option for sure.

> We should at least make the mirror url configurable.

Absolutely.

-- 
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.