If you are still looking for new ideas for Foreman 2.0:
I don't know whether this is seen by you guys as a major change- but having a consistent API v2 in Foreman and Katello would be a very nice thing.
We are stumbling across some inconsistencies from time to time with our foreman/katello Ansible module work.
The issue [1] I am linking here is for Satellite and not Foreman, but problems like that are in Foreman as well.
E.g the searching works a bit different for Katello and Foreman entities [2]
Regarding Eric's suggestions:
" Pick your own config management (aka dropping Puppet as default within the application obviously stilled required for the installer)"
I don't think that is boring at all! ;)
Bernhard
[1]
https://bugzilla.redhat.com/show_bug.cgi?id=1264807
[2]
https://github.com/SatelliteQE/nailgun/issues
···
---
ATIX - The Linux & Open Source Company
https://www.atix.de
-----Original message-----
From: Eric D Helms <ericdhelms@gmail.com>
Sent: Wednesday 29th November 2017 18:18
To: foreman-dev <foreman-dev@googlegroups.com>
Subject: Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0
My two cents are that we shouldn't arbitrarily bump the version. Versions have and signal meaning to users. Especially when we are talking about the main line, core project. Fortunately or unfortunately, major version bumps signal either a major shift or change and/or a marketing opportunity. Further, major version changes should signal that plugins are also going to have to change to stay compliant. I'd suggest we stick with folks suggestions of finding some things to entirely deprecate and bump the version and/or adding some major support components so that 2.0 is a major change. Things I've head so far:
* Rails 5.1 and Ruby 2.4 support
* Remove API v1
* Vertical Nav
Some further, potentially more boring ideas as part of a "Foreman 2.0, new stack, new look" release:
* Pick your own config management (aka dropping Puppet as default within the application obviously stilled required for the installer)
* Updates to repository structure such as adding a client repository
* Tasks support in Core
This, based on comments, also sounds like a good time to visit a versioning policy so that we adhere to it and give plugins and users some predictability.
Eric
On Wed, Nov 29, 2017 at 12:07 PM, Eric D Helms <ericdhelms@gmail.com <mailto:ericdhelms@gmail.com> > wrote:
On Wed, Nov 29, 2017 at 8:49 AM, Bernhard Suttner <suttner@atix.de <mailto:suttner@atix.de> > wrote:
I also like the idea of a version 2.0 very much. Personally, I would be very happy to move bastion from katello to foreman so that it's possible to create modern, angular js components within foreman. One more reason to do this is, because I think foreman should be the structure, the base "framework" all other plugins like katello can live in. Just my thoughts...
This is not going to happen regardless. All net new UI is being created in React. Bastion is effectively in a critical bug fix state only. All React work is being done in Foreman core, or plugins directly (e.g. all new React work in Katello is going into Katello directly). You can consider the use of Angular within Foreman and Katello dead for all intents and purposes.
Eric
Best regards,
Bernhard Suttner
ATIX - The Linux & Open Source Company
https://www.atix.de
-----Ursprüngliche Nachricht-----
Von:Lukas Zapletal <lzap@redhat.com <mailto:lzap@redhat.com> >
Gesendet: Mittwoch 29 November 2017 14:18
An: foreman-dev <foreman-dev@googlegroups.com <mailto:foreman-dev@googlegroups.com> >
Betreff: Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0
Bikeshedding about SemVer aside, I'm good with doing a 2.0 release in
the near future, but *please* lets use it to deprecate / drop stuff we
no longer want to maintain. Otherwise there's no real point to it.
I agree we can take this "opportunity" to drop some deprecated things
like V1 API, but I don't see many other things. We are pretty good in
deprecating things using our "two releases" rule which should be
followed no matter if we bump major version or not.
Let's not block 2.0 with any feature, I wrote the reasons, if we fit
in some deprecation work why not. But's let's agree on 2.0 timeframe
regardless of any planning.
--
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+unsubscribe@googlegroups.com <mailto:foreman-dev%2Bunsubscribe@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+unsubscribe@googlegroups.com <mailto:foreman-dev%2Bunsubscribe@googlegroups.com> .
For more options, visit https://groups.google.com/d/optout.
--
Eric D. Helms
Red Hat Engineering
--
Eric D. Helms
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+unsubscribe@googlegroups.com <mailto:foreman-dev+unsubscribe@googlegroups.com> .
For more options, visit https://groups.google.com/d/optout.
If having 2.0 means just a change in number because y is now just too high
to remember, then it does not matter if we pick 1.17, 1.18 or 1.19. I agree
that bumping the major number signals a significant and possibly breaking
changes to users and should not be done arbitrarily.
If we want 2.0 with some major changes, then is vertical nav + Rails 5.1
significant enough to have 2.0 instead of 1.17?
O.
···
On Wed, Nov 29, 2017 at 11:54 PM, Bernhard Hopfenmüller < hopfenmueller@atix.de> wrote:
If you are still looking for new ideas for Foreman 2.0:
I don't know whether this is seen by you guys as a major change- but
having a consistent API v2 in Foreman and Katello would be a very nice
thing.
We are stumbling across some inconsistencies from time to time with our
foreman/katello Ansible module work.
The issue [1] I am linking here is for Satellite and not Foreman, but
problems like that are in Foreman as well.
E.g the searching works a bit different for Katello and Foreman entities
[2]
Regarding Eric's suggestions:
" Pick your own config management (aka dropping Puppet as default within
the application obviously stilled required for the installer)"
I don't think that is boring at all! ;)
Bernhard
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1264807
[2] https://github.com/SatelliteQE/nailgun/issues
---
ATIX - The Linux & Open Source Company
https://www.atix.de
-----Original message-----
*From:* Eric D Helms <ericdhelms@gmail.com>
*Sent:* Wednesday 29th November 2017 18:18
*To:* foreman-dev <foreman-dev@googlegroups.com>
*Subject:* Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0
My two cents are that we shouldn't arbitrarily bump the version. Versions
have and signal meaning to users. Especially when we are talking about the
main line, core project. Fortunately or unfortunately, major version bumps
signal either a major shift or change and/or a marketing opportunity.
Further, major version changes should signal that plugins are also going to
have to change to stay compliant. I'd suggest we stick with folks
suggestions of finding some things to entirely deprecate and bump the
version and/or adding some major support components so that 2.0 is a major
change. Things I've head so far:
* Rails 5.1 and Ruby 2.4 support
* Remove API v1
* Vertical Nav
Some further, potentially more boring ideas as part of a "Foreman 2.0, new
stack, new look" release:
* Pick your own config management (aka dropping Puppet as default within
the application obviously stilled required for the installer)
* Updates to repository structure such as adding a client repository
* Tasks support in Core
This, based on comments, also sounds like a good time to visit a
versioning policy so that we adhere to it and give plugins and users some
predictability.
Eric
On Wed, Nov 29, 2017 at 12:07 PM, Eric D Helms <ericdhelms@gmail.com> > wrote:
On Wed, Nov 29, 2017 at 8:49 AM, Bernhard Suttner <suttner@atix.de> >> wrote:
I also like the idea of a version 2.0 very much. Personally, I would be
very happy to move bastion from katello to foreman so that it's possible to
create modern, angular js components within foreman. One more reason to do
this is, because I think foreman should be the structure, the base
"framework" all other plugins like katello can live in. Just my thoughts...
This is not going to happen regardless. All net new UI is being created
in React. Bastion is effectively in a critical bug fix state only. All
React work is being done in Foreman core, or plugins directly (e.g. all new
React work in Katello is going into Katello directly). You can consider the
use of Angular within Foreman and Katello dead for all intents and
purposes.
Eric
Best regards,
Bernhard Suttner
ATIX - The Linux & Open Source Company
https://www.atix.de
-----Ursprüngliche Nachricht-----
Von:Lukas Zapletal <lzap@redhat.com>
Gesendet: Mittwoch 29 November 2017 14:18
An: foreman-dev <foreman-dev@googlegroups.com>
Betreff: Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0
Bikeshedding about SemVer aside, I'm good with doing a 2.0 release in
the near future, but *please* lets use it to deprecate / drop stuff
we
no longer want to maintain. Otherwise there's no real point to it.
I agree we can take this "opportunity" to drop some deprecated things
like V1 API, but I don't see many other things. We are pretty good in
deprecating things using our "two releases" rule which should be
followed no matter if we bump major version or not.
Let's not block 2.0 with any feature, I wrote the reasons, if we fit
in some deprecation work why not. But's let's agree on 2.0 timeframe
regardless of any planning.
--
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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Eric D. Helms
Red Hat Engineering
--
Eric D. Helms
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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Totally agree with that. Vert nav + Rails 5.1 + Drop support of APIv1 would be the best reason for 2.0 for sure
···
-----Ursprüngliche Nachricht-----
Von:Ondrej Prazak <oprazak@redhat.com>
Gesendet: Donnerstag 30 November 2017 09:08
An: foreman-dev@googlegroups.com
Betreff: Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0
If having 2.0 means just a change in number because y is now just too high to remember, then it does not matter if we pick 1.17, 1.18 or 1.19. I agree that bumping the major number signals a significant and possibly breaking changes to users and should not be done arbitrarily.
If we want 2.0 with some major changes, then is vertical nav + Rails 5.1 significant enough to have 2.0 instead of 1.17?
O.
On Wed, Nov 29, 2017 at 11:54 PM, Bernhard Hopfenmüller <hopfenmueller@atix.de <mailto:hopfenmueller@atix.de>> wrote:
If you are still looking for new ideas for Foreman 2.0:
I dont know whether this is seen by you guys as a major change- but having a consistent API v2 in Foreman and Katello would be a very nice thing.
We are stumbling across some inconsistencies from time to time with our foreman/katello Ansible module work.
The issue [1] I am linking here is for Satellite and not Foreman, but problems like that are in Foreman as well.
E.g the searching works a bit different for Katello and Foreman entities [2]
Regarding Erics suggestions:
" Pick your own config management (aka dropping Puppet as default within the application obviously stilled required for the installer)"
I dont think that is boring at all! ;)
Bernhard
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1264807">https://bugzilla.redhat.com/show_bug.cgi?id=1264807 <https://bugzilla.redhat.com/show_bug.cgi?id=1264807">https://bugzilla.redhat.com/show_bug.cgi?id=1264807>
[2] https://github.com/SatelliteQE/nailgun/issues">https://github.com/SatelliteQE/nailgun/issues <https://github.com/SatelliteQE/nailgun/issues">https://github.com/SatelliteQE/nailgun/issues>
---
ATIX - The Linux & Open Source Company
https://www.atix.de">https://www.atix.de <https://www.atix.de">https://www.atix.de>
-----Original message-----
From: Eric D Helms <ericdhelms@gmail.com <mailto:ericdhelms@gmail.com>>
Sent: Wednesday 29th November 2017 18:18
To: foreman-dev <foreman-dev@googlegroups.com <mailto:foreman-dev@googlegroups.com>>
Subject: Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0
My two cents are that we shouldnt arbitrarily bump the version. Versions have and signal meaning to users. Especially when we are talking about the main line, core project. Fortunately or unfortunately, major version bumps signal either a major shift or change and/or a marketing opportunity. Further, major version changes should signal that plugins are also going to have to change to stay compliant. Id suggest we stick with folks suggestions of finding some things to entirely deprecate and bump the version and/or adding some major support components so that 2.0 is a major change. Things Ive head so far:
* Rails 5.1 and Ruby 2.4 support
* Remove API v1
* Vertical Nav
Some further, potentially more boring ideas as part of a "Foreman 2.0, new stack, new look" release:
* Pick your own config management (aka dropping Puppet as default within the application obviously stilled required for the installer)
* Updates to repository structure such as adding a client repository
* Tasks support in Core
This, based on comments, also sounds like a good time to visit a versioning policy so that we adhere to it and give plugins and users some predictability.
Eric
On Wed, Nov 29, 2017 at 12:07 PM, Eric D Helms <ericdhelms@gmail.com <mailto:ericdhelms@gmail.com>> wrote:
On Wed, Nov 29, 2017 at 8:49 AM, Bernhard Suttner <suttner@atix.de <mailto:suttner@atix.de>> wrote:
I also like the idea of a version 2.0 very much. Personally, I would be very happy to move bastion from katello to foreman so that its possible to create modern, angular js components within foreman. One more reason to do this is, because I think foreman should be the structure, the base "framework" all other plugins like katello can live in. Just my thoughts...
This is not going to happen regardless. All net new UI is being created in React. Bastion is effectively in a critical bug fix state only. All React work is being done in Foreman core, or plugins directly (e.g. all new React work in Katello is going into Katello directly). You can consider the use of Angular within Foreman and Katello dead for all intents and purposes.
Eric
Best regards,
Bernhard Suttner
ATIX - The Linux & Open Source Company
https://www.atix.de">https://www.atix.de <https://www.atix.de">https://www.atix.de>
-----Ursprüngliche Nachricht-----
Von:Lukas Zapletal <lzap@redhat.com <mailto:lzap@redhat.com>>
Gesendet: Mittwoch 29 November 2017 14:18
An: foreman-dev <foreman-dev@googlegroups.com <mailto:foreman-dev@googlegroups.com>>
Betreff: Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0
Bikeshedding about SemVer aside, Im good with doing a 2.0 release in
the near future, but *please* lets use it to deprecate / drop stuff we
no longer want to maintain. Otherwise theres no real point to it.
I agree we can take this "opportunity" to drop some deprecated things
like V1 API, but I dont see many other things. We are pretty good in
deprecating things using our "two releases" rule which should be
followed no matter if we bump major version or not.
Lets not block 2.0 with any feature, I wrote the reasons, if we fit
in some deprecation work why not. Buts lets agree on 2.0 timeframe
regardless of any planning.
--
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+unsubscribe@googlegroups.com <mailto:foreman-dev%2Bunsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout">https://groups.google.com/d/optout <https://groups.google.com/d/optout">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+unsubscribe@googlegroups.com <mailto:foreman-dev%2Bunsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout">https://groups.google.com/d/optout <https://groups.google.com/d/optout">https://groups.google.com/d/optout>.
<br clear="all" />
--
Eric D. Helms
Red Hat Engineering
<br clear="all" />
--
Eric D. Helms
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+unsubscribe@googlegroups.com <mailto:foreman-dev+unsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout">https://groups.google.com/d/optout <https://groups.google.com/d/optout">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+unsubscribe@googlegroups.com <mailto:foreman-dev+unsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout">https://groups.google.com/d/optout <https://groups.google.com/d/optout">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+unsubscribe@googlegroups.com <mailto:foreman-dev+unsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout">https://groups.google.com/d/optout <https://groups.google.com/d/optout">https://groups.google.com/d/optout>.
