Tags and packages have been added to Koji, branching was done.
Many dependencies need to be built in the foreman-1.16-rhel7 tag.
As soon as the dependencies finish building, we can start building
the first RC and figuring out what are the blockers and must-haves
for this release. Tags | koji
> Hi all,
>
> Just a heads up on the status of all of the upcoming releases:
>
> - 1.15.4
> - After doing all the cherry-picks, 1.15.stable went red in Jenkins
> https://github.com/theforeman/foreman/pull/4827 fixes it, after
> that is merged we should be able to start the usual build
> tarballs/sign/release dance to release.
This was released 2 days ago.
>
> - 1.16.RC1
> - Tags and packages have been added to Koji, branching was done.
> Many dependencies need to be built in the foreman-1.16-rhel7 tag.
> As soon as the dependencies finish building, we can start building
> the first RC and figuring out what are the blockers and must-haves
> for this release.
> http://koji.katello.org/koji/tags
Koji is fine now. There was a problem on the cloning tags script that is
now fixed. I have started tagging and we should be getting the RC as
soon as packages are signed/tested and published.
>
> - 1.17.0
> - This should be the Rails 5 release. In addition to that, we need
> to find a way to skip parameters parsing, for ActiveJob and
> Katello to be more performant. As soon as this is merged we can
> move testing to be on Rails 5.
> https://github.com/Katello/katello/pull/6875
> If the CentOS team does not migrate rh-ror50 (software collection
> for Rails 5) to http://softwarecollections.org/, it sounds like we
> will have to do our own SCLo again.
Unsolved yet. We are thinking on moving directly to Rails 5.1 to avoid
having to change the SCL twice.
···
On 09/14, Daniel Lobato Garcia wrote:
Happy to help, give more details about any of these, or accept any
collaborators that want to nanny any of these to completion
> More updates on what's going on:
>
> > Hi all,
> >
> > Just a heads up on the status of all of the upcoming releases:
> >
> > - 1.15.4
> > - After doing all the cherry-picks, 1.15.stable went red in Jenkins
> > https://github.com/theforeman/foreman/pull/4827 fixes it, after
> > that is merged we should be able to start the usual build
> > tarballs/sign/release dance to release.
>
> This was released 2 days ago.
>
> >
> > - 1.16.RC1
> > - Tags and packages have been added to Koji, branching was done.
> > Many dependencies need to be built in the foreman-1.16-rhel7 tag.
> > As soon as the dependencies finish building, we can start building
> > the first RC and figuring out what are the blockers and must-haves
> > for this release.
> > http://koji.katello.org/koji/tags
>
> Koji is fine now. There was a problem on the cloning tags script that is
> now fixed. I have started tagging and we should be getting the RC as
> soon as packages are signed/tested and published.
>
No pressure - but any ETA?
···
On Wed, Sep 20, 2017 at 10:04 AM, Daniel Lobato Garcia wrote:
> On 09/14, Daniel Lobato Garcia wrote:
1.17.0
This should be the Rails 5 release. In addition to that, we need
to find a way to skip parameters parsing, for ActiveJob and
Katello to be more performant. As soon as this is merged we can
move testing to be on Rails 5. https://github.com/Katello/katello/pull/6875
If the CentOS team does not migrate rh-ror50 (software collection
for Rails 5) to http://softwarecollections.org/, it sounds like we
will have to do our own SCLo again.
Unsolved yet. We are thinking on moving directly to Rails 5.1 to avoid
having to change the SCL twice.
Happy to help, give more details about any of these, or accept any
collaborators that want to nanny any of these to completion
>
> > More updates on what's going on:
> >
> > > Hi all,
> > >
> > > Just a heads up on the status of all of the upcoming releases:
> > >
> > > - 1.15.4
> > > - After doing all the cherry-picks, 1.15.stable went red in Jenkins
> > > Refs #20098 - Remove save expectation for templates_used by dLobatog · Pull Request #4827 · theforeman/foreman · GitHub fixes it, after
> > > that is merged we should be able to start the usual build
> > > tarballs/sign/release dance to release.
> >
> > This was released 2 days ago.
> >
> > >
> > > - 1.16.RC1
> > > - Tags and packages have been added to Koji, branching was done.
> > > Many dependencies need to be built in the foreman-1.16-rhel7 tag.
> > > As soon as the dependencies finish building, we can start building
> > > the first RC and figuring out what are the blockers and must-haves
> > > for this release.
> > > Tags | koji
> >
> > Koji is fine now. There was a problem on the cloning tags script that is
> > now fixed. I have started tagging and we should be getting the RC as
> > soon as packages are signed/tested and published.
> >
>
> No pressure - but any ETA?
This was fixed on Thursday 21st IIRC - the issue is that when I cloned the tags from
nightly, Koji didn't clone the builds to the new tag.
I cloned all the latest builds and had to do some adjustments for some
that were not meant to be there.
The original problem could have been solved by this: https://github.com/theforeman/foreman-packaging/pull/1816
which we didn't know about as this argument was not required in previous
version of koji (the cli program I mean)
···
On 09/24, Ohad Levy wrote:
> On Wed, Sep 20, 2017 at 10:04 AM, Daniel Lobato Garcia > wrote:
> > On 09/14, Daniel Lobato Garcia wrote:
Koji is fine now. There was a problem on the cloning tags script that is
now fixed. I have started tagging and we should be getting the RC as
soon as packages are signed/tested and published.
No pressure - but any ETA?
This was fixed on Thursday 21st IIRC - the issue is that when I cloned the
tags from
nightly, Koji didn't clone the builds to the new tag.
I cloned all the latest builds and had to do some adjustments for some
that were not meant to be there.
The original problem could have been solved by this:
which we didn't know about as this argument was not required in previous
version of koji (the cli program I mean)
- 1.17.0
- This should be the Rails 5 release. In addition to that, we need
to find a way to skip parameters parsing, for ActiveJob and
Katello to be more performant. As soon as this is merged we can
move testing to be on Rails 5.
If the CentOS team does not migrate rh-ror50 (software
--
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an
···
On Sep 25, 2017 6:56 PM, "Daniel Lobato Garcia" <elobatocs@gmail.com> wrote:
On 09/24, Ohad Levy wrote:
On Wed, Sep 20, 2017 at 10:04 AM, Daniel Lobato Garcia < elobatocs@gmail.com> > wrote:
On 09/14, Daniel Lobato Garcia wrote:
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.
So far we've been wanting to include the foreman tasks as a service from
core rather than from foreman-tasks. As always we want that change to
first land in develop but we've been struggling with broken nightlies
for quite some time. It loked like it was fixed since the builds started
to pass aagin but we have no validation on the actual UI. Turns out
that's broken and we have no automated testing for this.
Would it be an option to ship 1.16 without dynflow service in the core
or would that break things?
···
On Sun, Nov 19, 2017 at 11:27:57AM +0200, Ohad Levy wrote:
So far we've been wanting to include the foreman tasks as a service from
core rather than from foreman-tasks. As always we want that change to first
land in develop but we've been struggling with broken nightlies for quite
some time. It loked like it was fixed since the builds started to pass
aagin but we have no validation on the actual UI. Turns out that's broken
and we have no automated testing for this.
Would it be an option to ship 1.16 without dynflow service in the core or
would that break things?
AFAIU - nothing uses it atm as we were uncertain if it can really be
used.. there is some code in core regarding that, so I'm not sure if that
matters... Daniel?
···
On Sun, Nov 19, 2017 at 10:35 PM, Ewoud Kohl van Wijngaarden < ewoud@kohlvanwijngaarden.nl> wrote:
On Sun, Nov 19, 2017 at 11:27:57AM +0200, Ohad Levy wrote:
--
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.
After bumping some dependencies and fixing some koji issues I can now
open the UI and end up without javascript compilation errors in the
console. Haven't verified much more than clicking through various pages
but this will allow us to start focussing on the needed packaging
changes (dynflow, Rails 5.1).
···
On Sun, Nov 19, 2017 at 09:35:04PM +0100, Ewoud Kohl van Wijngaarden wrote:
On Sun, Nov 19, 2017 at 11:27:57AM +0200, Ohad Levy wrote:
Can anyone shed some light on ETA for 1.16 GA?
I should have given an update earlier.
So far we've been wanting to include the foreman tasks as a service
from core rather than from foreman-tasks. As always we want that
change to first land in develop but we've been struggling with broken
nightlies for quite some time. It loked like it was fixed since the
builds started to pass aagin but we have no validation on the actual
UI. Turns out that's broken and we have no automated testing for this.
So far we've been wanting to include the foreman tasks as a service from
core rather than from foreman-tasks. As always we want that change to first
land in develop but we've been struggling with broken nightlies for quite
some time. It loked like it was fixed since the builds started to pass
aagin but we have no validation on the actual UI. Turns out that's broken
and we have no automated testing for this.
Would it be an option to ship 1.16 without dynflow service in the core or
would that break things?
AFAIU - nothing uses it atm as we were uncertain if it can really be
used.. there is some code in core regarding that, so I'm not sure if that
matters... Daniel?
It definitely can be used as proven by:
Not having a separate service to run Dynflow doesn't have many implications now
that nothing is using it.
If foreman-tasks still ships the service to start/stop the dynflow executor,
we're still fine (same as 1.15). Even without tasks, there's always a dynflow
executor running with Foreman
(https://github.com/theforeman/foreman/blob/1.16-stable/config/application.rb#L245)
but this one cannot be stopped or started without restarting Passenger too.
···
On 11/20, Ohad Levy wrote:
On Sun, Nov 19, 2017 at 10:35 PM, Ewoud Kohl van Wijngaarden < > ewoud@kohlvanwijngaarden.nl> wrote:
On Sun, Nov 19, 2017 at 11:27:57AM +0200, Ohad Levy wrote:
--
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.
So far we've been wanting to include the foreman tasks as a service from
core rather than from foreman-tasks. As always we want that change to first
land in develop but we've been struggling with broken nightlies for quite
some time. It loked like it was fixed since the builds started to pass
aagin but we have no validation on the actual UI. Turns out that's broken
and we have no automated testing for this.
After bumping some dependencies and fixing some koji issues I can now open
the UI and end up without javascript compilation errors in the console.
Haven't verified much more than clicking through various pages but this
will allow us to start focussing on the needed packaging changes (dynflow,
Rails 5.1).
great news, thanks :) just wondering, i assume we can now release 1.16
first (which imho is a higher prio dynflow, and rails 5.1?)
···
On Tue, Nov 21, 2017 at 11:02 AM, Ewoud Kohl van Wijngaarden < ewoud@kohlvanwijngaarden.nl> wrote:
On Sun, Nov 19, 2017 at 09:35:04PM +0100, Ewoud Kohl van Wijngaarden wrote:
On Sun, Nov 19, 2017 at 11:27:57AM +0200, Ohad Levy wrote:
--
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.
So far we've been wanting to include the foreman tasks as a service
from
core rather than from foreman-tasks. As always we want that change to
first
land in develop but we've been struggling with broken nightlies for
quite
some time. It loked like it was fixed since the builds started to pass
aagin but we have no validation on the actual UI. Turns out that's
broken
and we have no automated testing for this.
Would it be an option to ship 1.16 without dynflow service in the core
or
would that break things?
AFAIU - nothing uses it atm as we were uncertain if it can really be
used.. there is some code in core regarding that, so I'm not sure if that
matters... Daniel?
It definitely can be used as proven by:
Sorry - I didn't mean it like that - my point was that the packaging effort
is not resolved, hence we didn't merge or wanted to count on it to block
1.16 (nothing about the technical side of it).
Not having a separate service to run Dynflow doesn't have many
implications now
that nothing is using it.
If foreman-tasks still ships the service to start/stop the dynflow
executor,
we're still fine (same as 1.15). Even without tasks, there's always a
dynflow
executor running with Foreman
(https://github.com/theforeman/foreman/blob/1.16- stable/config/application.rb#L245)
but this one cannot be stopped or started without restarting Passenger too.
···
On Mon, Nov 20, 2017 at 2:36 PM, Daniel Lobato Garcia <elobatocs@gmail.com> wrote:
On 11/20, Ohad Levy wrote:
On Sun, Nov 19, 2017 at 10:35 PM, Ewoud Kohl van Wijngaarden < > > ewoud@kohlvanwijngaarden.nl> wrote:
On Sun, Nov 19, 2017 at 11:27:57AM +0200, Ohad Levy wrote:
--
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.
--
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.
So far we've been wanting to include the foreman tasks as a service
from
core rather than from foreman-tasks. As always we want that change to
first
land in develop but we've been struggling with broken nightlies for
quite
some time. It loked like it was fixed since the builds started to pass
aagin but we have no validation on the actual UI. Turns out that's
broken
and we have no automated testing for this.
Would it be an option to ship 1.16 without dynflow service in the core
or
would that break things?
AFAIU - nothing uses it atm as we were uncertain if it can really be
used.. there is some code in core regarding that, so I'm not sure if that
matters... Daniel?
It definitely can be used as proven by:
Not having a separate service to run Dynflow doesn't have many
implications now
that nothing is using it.
If foreman-tasks still ships the service to start/stop the dynflow
executor,
we're still fine (same as 1.15). Even without tasks, there's always a
dynflow
executor running with Foreman
(
)
but this one cannot be stopped or started without restarting Passenger too.
If we decide for releasing without that, we need to put the files back into
foreman tasks for 1.16:
I would definitely rather see this resolved properly. Anythink we can help
with?
-- Ivan
···
po 20. 11. 2017 v 13:36 odesílatel Daniel Lobato Garcia <elobatocs@gmail.com>
On 11/20, Ohad Levy wrote:
On Sun, Nov 19, 2017 at 10:35 PM, Ewoud Kohl van Wijngaarden < > > ewoud@kohlvanwijngaarden.nl> wrote:
On Sun, Nov 19, 2017 at 11:27:57AM +0200, Ohad Levy wrote:
--
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.
--
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.
I agree it's higher prio, but I can't judge if the current release could
be considered ready to release or if the dynflow change is halfway in
the migration. I'll let Daniel and Ivan discuss that further while I
work on getting dynflow in nightly.
···
On Tue, Nov 21, 2017 at 11:10:41AM +0200, Ohad Levy wrote:
On Tue, Nov 21, 2017 at 11:02 AM, Ewoud Kohl van Wijngaarden < >ewoud@kohlvanwijngaarden.nl> wrote:
On Sun, Nov 19, 2017 at 09:35:04PM +0100, Ewoud Kohl van Wijngaarden wrote:
On Sun, Nov 19, 2017 at 11:27:57AM +0200, Ohad Levy wrote:
Can anyone shed some light on ETA for 1.16 GA?
I should have given an update earlier.
So far we've been wanting to include the foreman tasks as a service from
core rather than from foreman-tasks. As always we want that change to first
land in develop but we've been struggling with broken nightlies for quite
some time. It loked like it was fixed since the builds started to pass
aagin but we have no validation on the actual UI. Turns out that's broken
and we have no automated testing for this.
After bumping some dependencies and fixing some koji issues I can now open
the UI and end up without javascript compilation errors in the console.
Haven't verified much more than clicking through various pages but this
will allow us to start focussing on the needed packaging changes (dynflow,
Rails 5.1).
great news, thanks :) just wondering, i assume we can now release 1.16
first (which imho is a higher prio dynflow, and rails 5.1?)
Right now we have verified it works on EL7 and are working on Debian.
When that works, we will merge it to nightly. IMHO it's up to Daniel to
make the call if we want to backport it to 1.16 since he's the release
manager.
···
On Mon, Nov 20, 2017 at 05:36:29PM +0000, Ivan Necas wrote:
po 20. 11. 2017 v 13:36 odesílatel Daniel Lobato Garcia <elobatocs@gmail.com>
napsal:
On 11/20, Ohad Levy wrote:
On Sun, Nov 19, 2017 at 10:35 PM, Ewoud Kohl van Wijngaarden < >> > ewoud@kohlvanwijngaarden.nl> wrote:
On Sun, Nov 19, 2017 at 11:27:57AM +0200, Ohad Levy wrote:
Can anyone shed some light on ETA for 1.16 GA?
I should have given an update earlier.
So far we've been wanting to include the foreman tasks as a service
from
core rather than from foreman-tasks. As always we want that change to
first
land in develop but we've been struggling with broken nightlies for
quite
some time. It loked like it was fixed since the builds started to pass
aagin but we have no validation on the actual UI. Turns out that's
broken
and we have no automated testing for this.
Would it be an option to ship 1.16 without dynflow service in the core
or
would that break things?
AFAIU - nothing uses it atm as we were uncertain if it can really be
used.. there is some code in core regarding that, so I'm not sure if that
matters... Daniel?
Not having a separate service to run Dynflow doesn't have many
implications now
that nothing is using it.
If foreman-tasks still ships the service to start/stop the dynflow
executor,
we're still fine (same as 1.15). Even without tasks, there's always a
dynflow
executor running with Foreman
(
https://github.com/theforeman/foreman/blob/1.16-stable/config/application.rb#L245 )
but this one cannot be stopped or started without restarting Passenger too.
If we decide for releasing without that, we need to put the files back into
foreman tasks for 1.16:
I would definitely rather see this resolved properly. Anythink we can help
with?
po 20. 11. 2017 v 13:36 odesílatel Daniel Lobato Garcia <
elobatocs@gmail.com>
napsal:
Can anyone shed some light on ETA for 1.16 GA?
I should have given an update earlier.
So far we've been wanting to include the foreman tasks as a service
from
core rather than from foreman-tasks. As always we want that change
to
first
land in develop but we've been struggling with broken nightlies for
quite
some time. It loked like it was fixed since the builds started to
pass
aagin but we have no validation on the actual UI. Turns out that's
broken
and we have no automated testing for this.
Would it be an option to ship 1.16 without dynflow service in the
core
or
would that break things?
AFAIU - nothing uses it atm as we were uncertain if it can really be
used.. there is some code in core regarding that, so I'm not sure if
that
matters... Daniel?
It definitely can be used as proven by:
Not having a separate service to run Dynflow doesn't have many
implications now
that nothing is using it.
If foreman-tasks still ships the service to start/stop the dynflow
executor,
we're still fine (same as 1.15). Even without tasks, there's always a
dynflow
executor running with Foreman
(
)
but this one cannot be stopped or started without restarting Passenger
too.
If we decide for releasing without that, we need to put the files back
into
foreman tasks for 1.16:
I would definitely rather see this resolved properly. Anythink we can help
with?
Right now we have verified it works on EL7 and are working on Debian.
When that works, we will merge it to nightly. IMHO it's up to Daniel to
make the call if we want to backport it to 1.16 since he's the release
manager.
Glad to hear things got moving
-- Ivan
···
On Fri, 24 Nov 2017 at 14:12, Ewoud Kohl van Wijngaarden < ewoud@kohlvanwijngaarden.nl> wrote:
On Mon, Nov 20, 2017 at 05:36:29PM +0000, Ivan Necas wrote:
On 11/20, Ohad Levy wrote:
On Sun, Nov 19, 2017 at 10:35 PM, Ewoud Kohl van Wijngaarden < > >> > ewoud@kohlvanwijngaarden.nl> wrote:
On Sun, Nov 19, 2017 at 11:27:57AM +0200, Ohad Levy wrote:
--
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.
