Re: [foreman-dev] Nominating additional maintainers in foreman-core

[Adam Ruzicka]

+1 to both

-- Adam

On Wed, Dec 6, 2017 at 1:40 PM, Tomer Brisker  wrote:

> Hello,
> ​As many of you may have noticed, foreman-core open PR​ count has been in
> the area of 100-110 for most of the last few months. There are only a few
> people with merge access that actively review PRs, so that the time it
> takes for changes to be accepted can take long. I would like to propose
> granting merge access to two more members of the community:
>
> Shimon Shtein - has 75 merged commits [1] and has taken part in the
> reviews of 64 merged commits[2].
> Michael Moll - has 71 merged commits [3] and has taken part in the reviews
> of 130 merged commits[4]. He is also already a long time maintainer of
> several of our other repos and has proven to be a responsible maintainer.
>
> Please send +1/-1 either to the list or to me in private if you prefer.
> Per our process, unless I receive any objections within a week, I will
> request one of the organization owners to grant them access.
>
> [1] https://github.com/theforeman/foreman/pulls?q=is%3Apr+
> author%3Ashimshtein+is%3Aclosed
> [2] https://github.com/theforeman/foreman/pulls?utf8=%E2%9C%93;
> q=is%3Apr+-author%3Ashimshtein+commenter%3Ashimshtein+is%3Aclosed+
> ​[3] https://github.com/theforeman/foreman/pulls?utf8=%E2%9C%93;
> q=is%3Apr+author%3Ammoll+is%3Aclosed+
> [4]​ https://github.com/theforeman/foreman/pulls?utf8=%E2%9C%93;
> q=is%3Apr+-author%3Ammoll+commenter%3Ammoll+is%3Aclosed+
>
> --
> Have a nice day,
> Tomer Brisker
> Red Hat Engineering
>
> --
> 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.

Re: [foreman-dev] foreman_tasks V1 endpoint works but V2 returns 404

[Adam Ruzicka]

Hello,
as far as I know there is no v1 API for foreman-tasks. So the one you're
reaching with the first curl is actually the v2. I agree it is not
intuitive to have v2 api at the regular /api endpoint, but that's the way
it is.

-- Adam

On Tue, Oct 17, 2017 at 7:15 AM,  wrote:

> Hi,
>
> If I
>
> *#* curl --user admin:changeme -H "Content-Type:application/json" -k
> https://katelloserver/foreman_tasks/api/tasks/3574500b-0394-
> 4a94-9f86-8ff1890ceadb
>
> I get the expected response back. But if I send the request to V2 of the
> api as follows
>
> *#* curl --user sledge:hammer -H "Content-Type:application/json" -k
> https://ind2q00katello01.qa.local/foreman_tasks/api/*V2*/
> tasks/3574500b-0394-4a94-9f86-8ff1890ceadb
> *OR*
> *#* curl --user sledge:hammer -H "Content-Type:application/json" -H
> "Accept:application/json,*version=2*" -k https://ind2q00katello01.qa.
> local/foreman_tasks/api/tasks/3574500b-0394-4a94-9f86-8ff1890ceadb
>
>
> I basically get a 404 resource not found error.
>
>
> Installed foreman_tasks core package is on 0.1.4 and foreman_tasks package
> is on 0.9.4.
>
> Any suggestions, what I am missing here? Thanks in advance.
>
> --
> 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.

Re: [foreman-dev] How to compute resource

[Adam Ruzicka]

Hello,
the Compue Resource part of How to create a plugin on Foreman's wiki[1]
might be a good place to start. Also taking a look at sources of existing
compute resources and/or plugins adding some might provide a bit of insight.

1 -
http://projects.theforeman.org/projects/foreman/wiki/How_to_Create_a_Plugin#Compute-resources

Hope this helps

Adam

On Tue, May 9, 2017 at 9:33 AM, lovi  wrote:

> Hello,
>
> Where could I find the documentation to understand how to create a new
> compute resource ?
>
> Regards
>
> --
> 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.

Re: Re: [foreman-dev] Revert removal of @host.params for host_param

[Adam Ruzicka]

I'm with Marek on this one. Anything giving us more breathing space
is a good thing in the long run, even if the immediate effect might be a
bit negative.
A migration for community-templates would be nice though.

The mentioned REX issue was just a minor inconvenience. It just stopped the
tests
for a few days.


Adam

On Fri, Jan 13, 2017 at 7:09 PM, Marek Hulan  wrote:

> I don't think it causes any problems. I don't see the reason why the whole
> commit should be reverted. If something then perhaps deprecation warning
> could be removed. I'd still prefer communuty-templates using macros instead
> of internal objects.
>
> --
> Marek
>
> Odesláno pomocí AquaMail pro Android
> http://www.aqua-mail.com
>
> Dne 13. ledna 2017 18:27:13 "Sean O'Keeffe"  napsal:
>
>> Maybe the best thing to do for now it to revert it and send a PR to the
>> RFC repo for a proper discussion?
>>
>> On Fri, Jan 13, 2017 at 2:26 PM, Daniel Lobato Garcia <
>> elobat...@gmail.com> wrote:
>>
>>> On 01/12, Marek Hulán wrote:
>>>  > >
>>> > > > I strongly disagree that this does not have big benefits. Using
>>> internal
>>> > > > Foreman objects in templates is a bad practice. It blocks us from
>>> > > > improving
>>> > > > our code. Therefore it's very important to build a DSL that users
>>> can use
>>> > > > in templates and keep that compatible. We can then later change the
>>> > > > implementation of host_param_true method without any templates
>>> changing.
>>> > > > Think
>>> > > > of this as a templating API.
>>> > > >
>>> > > > Another less significant benefit is that for plugins it's easier to
>>> > > > wrap/alias
>>> > > > the template method rather than manipulating something that's used
>>> > > > internally in @host. Still not ideal but that should be solved by
>>> > > > https://github.com/ theforeman/foreman/pull/3701
>>> > > >
>>> > > > Of course it will require users to migrate to new template helpers
>>> which
>>> > > > is
>>> > > > why we move there slowly and hopefully with proper deprecations. I
>>> was
>>> > > > hoping to do the update for community-templates since it's very
>>> easy
>>> > > > migration.
>>> > > >
>>> > > > If you think it's too complicated for users we could provide rake
>>> task or
>>> > > > migration. But please don't revert this.
>>> > >
>>> > > Yes, if you provided a migration it would be much better.  That
>>> doesn't
>>> > > really solve the problem with people using the foreman_templates
>>> plugin
>>> > > who will have those changes reverted, but I guess it's better than
>>> nothing.
>>> > >
>>> > > There's still dozens of other things allowed for @host in the Jail
>>> that
>>> > > aren't covered by these macros.   What's the plan for those?
>>> >
>>> > Whenever we have a chance, we should move from internal objects to
>>> macros. The
>>> > more macros we have the higher the chance is that we can keep templates
>>> > compatible.
>>>
>>> Sorry but I oppose this. Some internal objects are quite stable, in
>>> fact people rely upon them successfully - but we break the compatibility
>>> for apparent advantages that IMO are not worth the hassle.
>>>
>>> @host.operatingsystem, @host.architecture, etc... and @host.params, are
>>> very stable objects that can safely be called from templates and expect
>>> that will work for a long time. Not only our users do it. We also relied
>>> upon these internal objects for years.
>>>
>>> The first community templates PRs which are 4 years old used
>>> @host.params, @host.operatingsystem, etc.. Those are stable enough to
>>> not warrant writing a macro for them
>>>
>>> What we did on #16740 is basically renaming things around and deprecating
>>> params for macros that don't do anything but calling @host.params
>>> themselves.
>>>
>>> I would argue for the opposite way of thinking. When we change how
>>> these internal APIs work, we should deprecate them. If these APIs
>>> remain stable, don't change anything as it provides no value, and brings
>>> headaches and wastes time. Time wasted on writing this thread, on the
>>> people who write and review PRs in the project and associated ones
>>> (templates, the migration to new macros, fixing anything that might
>>> break,
>>> and adding more LOC which complicate our codebase).
>>>
>>> >
>>> > > I still think this provides more headaches than any benefits.
>>> >
>>> > I hope that following helps
>>> > * https://github.com/theforeman/community-templates/pull/343
>>> > * https://github.com/theforeman/foreman/pull/4187
>>> > * https://gist.github.com/ares/5435226ef0317613535101765404d3f5
>>> >
>>> > --
>>> > Marek
>>> >
>>> > >
>>> > >
>>> > > - Stephen
>>> > >
>>> > > > --
>>> > > > Marek
>>> > > >
>>> > > > --
>>> > > > 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.
>>> >