A week or two back, I sent out a gathered Roadmap of tasks in
Infra/Deployment/Platform. The following is a report of updates on some of
those endeavors until I can move this to a better location for facilitating
updates and tracking.
- Rails 5.X
- Updates
- Discussion on vendorizin
Thanks for the update Michael. I just want to point interested parties to
the RPM side of the discussions that are on going over in
https://groups.google.com/forum/#!topic/foreman-dev/xJyxMx1lXy4
On Tue, Oct 17, 2017 at 4:32 PM, Michael Moll wrote:
> Hi,
>
> while the original plan was to switch
Plugins do present the most complicated part of this process given they
would each potentially be requiring a few independent gems separate from
the core stack and we would not want bloat. Seems we'd need either:
1) a single gem stack that plugins contribute to and is renegenrated with
all them e
> Today we package all required rubygems as RPMs and utilize a thirdparty
> Software Collection (SCL) for both the Ruby (rh-ruby22) and Rails stack
> (sclo-ror42). The team that manages the RHSCLs has already released Ruby
> 2.3 and RUby 2.4 SCLs and will continue to do so. However, there are no
>
Hi,
while the original plan was to switch to Rails 5.0 soon and then begin
5.1 work, it's a major downside that RPMs would be broken for a
potentially longer period, so I closed
https://github.com/theforeman/foreman/pull/4867 and like to draw the
attention of interested parties to
https://github.c
On 10/16/2017 04:36 AM, Michael Moll wrote:
> I don't really have stakes in RPMs, but I'd try to stick with option 1
> and I even expect that there's some demand for Rails SCLs at least in
> the RHEL/CentOS world by other projects, too.
>
> Regards
I would suggest the decision be made based on th
Hey,
I have a couple of slide decks about Foreman, mostly recycled
material. At OSS Europe in Prague I am giving "the standard" talk
about Foreman on Monday, will edit the latest version of the slides
but I was wondering - do we have a place to put those OpenOffice.org
files in?
If not, shall we
I have just re-enabled this.
-- bk
On 10/17/2017 09:51 AM, Lukas Zapletal wrote:
> I would like to know what was the reason to do that. It used to work
> fine for discovery so far.
>
> I just pushed updated POT into git, I am about to branch off 10.0
> tomorrow. You told me you are going to re-
I would like to know what was the reason to do that. It used to work
fine for discovery so far.
I just pushed updated POT into git, I am about to branch off 10.0
tomorrow. You told me you are going to re-enable this again? Thanks
LZ
On Thu, Oct 5, 2017 at 4:18 PM, Lukas Zapletal wrote:
> Bryan,
Thanks,
I removed ruby 2.0.0 from configuration matrix of the jenkins jobs
relavant to hammer. And created two redmine issues for removing the
old compatibility code:
* http://projects.theforeman.org/issues/21359
* http://projects.theforeman.org/issues/21360
T.
On Tue, Oct 10, 2017 at 2:44 PM, An
Tried lower cased v2 as well. Still the same.
--
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 ht
Based on the understanding from following documentation’s v2 should work. Any
other ideas?
https://theforeman.org/manuals/1.15/index.html#5.1.6APIVersioning
https://theforeman.org/api/1.15
https://access.redhat.com/documentation/en-us/red_hat_satellite/6.0/html/api_guide/chap-foreman_tasks
-
On Mon, Oct 16, 2017 at 11:39:56AM -0700, Evgeny Vasilchenko wrote:
I'd like to share an idea for provisioning of VMware guest VM's with
Foreman.
The idea required programming new type of Foreman proxy - unfortunately, I
neither have time or enough skills for that.
*The goal:*
- Allow config
On Mon, 2017-10-16 at 22:15 -0700, rajesh.eras...@gmail.com wrote:
> # curl --user sledge:hammer -H "Content-Type:application/json" -k htt
> ps://ind2q00katello01.qa.local/foreman_tasks/api/V2/tasks/3574500b-
> 0394-4a94-9f86-8ff1890ceadb
I think this is a character-case issue - it's *v2* not *V2*
I'm ok with the vendorizing approach, as long as it makes the release
process more
effective than it is right now.
Could you expand more on how the core dependencies, plugins and
plugin-dependencies work?
Perhaps this is something we could align with the debian packaging as well to
address some of
I agree with Tomer here, ditto.
On the other hand, the way how rubygems are being packaged makes
package patches (RPM patch file sets) really hard (in short - it's a
hack). Since I also touch packaging work here and there, I know how
much work is to maintain full stack like Ruby on Rails. So I can
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
>
>
Thanks for bringing up the discussion!
As one who has been bitten multiple times by the issue of building RPMs for
node modules, a definite +1 (or more like +1000) from me to vendoring the
entire node_modules directory.
This will save a lot of time and effort on the part of maintainers that
will n
EPEL is not great place to be for Rails or Node components. You should
not bump versions in EPEL7 (major relase should go into EPEL8).
On Tue, Oct 17, 2017 at 12:01 AM, Eric D Helms wrote:
>
>
> On Oct 16, 2017 5:17 PM, "Sean O'Keeffe" wrote:
>
> Why dont we ask the maintainer to pkg a new versi
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
20 matches
Mail list logo
