I'm happy to announce the foreman-tasks 0.7.1 with dynflow 0.8.1 are ready to be pushed live [1].
I'm writing this email for various reasons. First of all, I'm excited about the the big step forward on
the backend side:
we no longer limit the number of executors (the processes doing the work) to one.
Although we are running mutiple threads in each executor, and when written well, one
executor is just what one needs, there are two cases where more executors will be better:
large multi-host deployments, and HA setups. Also, as the usage of the foreman-tasks grows,
more and more compute power is expected for it to provide.
we no longer use unix sockets for the communication. For now, we switched to use
database for exchanging the data: we support all RDBS Foreman supports, but the
best uesr experience is expected to be on postgres database, where we use the listen/notify
feature to make the message exchanges as fast as possible. As with everything in Dynflow,
we've build an abstraction over the concepts of persistence, connectors, coordinators [2],
which allows to replace particular layer with more suitable technology for the job, when needed.
On the other hand, we've seen to many hypes over the years to lock us in the the next cool
thing. Our motto is: write an adapter and prove us the tool is worth it.
we moved to concurrent-ruby [3] gem from our custom implementation of concurrent abstractions:
Over the past two years (what a long time…:), we (big kudos to Pitr-ch) build quite robust
infrastructure around concurrent-abstractions, especially the actors model. However, we knew
it's not the best to keep maintenance of that stuff in our code base. Last year, we discovered
beautiful concurrent-ruby gem, that from the beginning looked as a perfect fit for us. What
we did (again, Pitr-ch is the one to blame:) is extracting the code that we had in Dynflow
and other projects, and put that into the concurrent-ruby. Thanks to the very responsive attitude
of the maintainers and CR community (Pitr himself becoming a maintainer pretty soon),
the code was accepted and enhanced a lot.
We are excited about this move, because we now have even more abstractions at our hand now, as well
as better performance and broader possibilities (such as potential JRuby support), and also
great community behind that: we are also not alone in trusting the concurrent-ruby: Rails will most probably
also move to it for some features.
As much as we're excited about this release, and despite our extensive testing (we've been in development
of this for over 8 months now, although not continuously, and past few months were were just polishing
the stuff), it's still a lot of new code we ship, and as everyone in software development knows,
nobody tests the code better than the others.
Therefore, if you hit some issues with running foreman-tasks/dynflow, please don't hesitate to file
an issue [4]: we will be tracking that closely to make sure to address potential issues sooner rather
than later, or just reach to us on the #theforeman-dev IRC channel
Plugin developers: foreman-tasks-0.7.1 and dynflow 0.8.1 are most probably going to be shipped
with foreman 1.9 release. There should be not breaking changes in this releases (unless you
relied on the limit of the one executor running, as we in Katello did [5]), so just make sure
to update your version dependencies accordingly.
PS: I apologize to Katello folks to break the RPM builds temporarily with this: apparently there is not
an easy way to make this a flawless process (unless messing around with the build tag overrides),
anyway, after [5] is in everything should be back in normal.
In particular, we'll need updated releases of foreman_chef and
foreman_salt in order to ship and publish foreman-tasks 0.7.x, due to
pinning (Stephen, Michael, Marek). A PR for foreman_chef's already up.
···
On 03/07/15 22:35, Ivan Necas wrote:
> I'm happy to announce the foreman-tasks 0.7.1 with dynflow 0.8.1 are ready to be pushed live [1].
> [..]
> Plugin developers: foreman-tasks-0.7.1 and dynflow 0.8.1 are most probably going to be shipped
> with foreman 1.9 release. There should be not breaking changes in this releases (unless you
> relied on the limit of the one executor running, as we in Katello did [5]), so just make sure
> to update your version dependencies accordingly.
0.7.x are in the nightly plugin repos now, so as and when you want, we
can republish down to 1.9. Debian packages are straightforward, and for
RPMs we'll just have to bring the new dependencies down too and retag.
···
On 06/07/15 13:24, Dominic Cleal wrote:
> On 03/07/15 22:35, Ivan Necas wrote:
>> I'm happy to announce the foreman-tasks 0.7.1 with dynflow 0.8.1 are ready to be pushed live [1].
>> [..]
>> Plugin developers: foreman-tasks-0.7.1 and dynflow 0.8.1 are most probably going to be shipped
>> with foreman 1.9 release. There should be not breaking changes in this releases (unless you
>> relied on the limit of the one executor running, as we in Katello did [5]), so just make sure
>> to update your version dependencies accordingly.
>
> In particular, we'll need updated releases of foreman_chef and
> foreman_salt in order to ship and publish foreman-tasks 0.7.x, due to
> pinning (Stephen, Michael, Marek). A PR for foreman_chef's already up.
> >> I'm happy to announce the foreman-tasks 0.7.1 with dynflow 0.8.1 are ready
> >> to be pushed live [1].
> >> […]
> >> Plugin developers: foreman-tasks-0.7.1 and dynflow 0.8.1 are most probably
> >> going to be shipped
> >> with foreman 1.9 release. There should be not breaking changes in this
> >> releases (unless you
> >> relied on the limit of the one executor running, as we in Katello did
> >> [5]), so just make sure
> >> to update your version dependencies accordingly.
> >
> > In particular, we'll need updated releases of foreman_chef and
> > foreman_salt in order to ship and publish foreman-tasks 0.7.x, due to
> > pinning (Stephen, Michael, Marek). A PR for foreman_chef's already up.
>
> All done, thanks folks.
>
> 0.7.x are in the nightly plugin repos now, so as and when you want, we
> can republish down to 1.9. Debian packages are straightforward, and for
> RPMs we'll just have to bring the new dependencies down too and retag.
Let's take that to 1.9. Katello is now foreman-tasks 0.7 ready as well
– Ivan
···
----- Original Message -----
> On 06/07/15 13:24, Dominic Cleal wrote:
> > On 03/07/15 22:35, Ivan Necas wrote:
Sure, done. RPMs retagged and Debian packages are building.
···
On 08/07/15 13:32, Ivan Necas wrote:
>
>
> ----- Original Message -----
>> On 06/07/15 13:24, Dominic Cleal wrote:
>>> On 03/07/15 22:35, Ivan Necas wrote:
>>>> I'm happy to announce the foreman-tasks 0.7.1 with dynflow 0.8.1 are ready
>>>> to be pushed live [1].
>>>> [..]
>>>> Plugin developers: foreman-tasks-0.7.1 and dynflow 0.8.1 are most probably
>>>> going to be shipped
>>>> with foreman 1.9 release. There should be not breaking changes in this
>>>> releases (unless you
>>>> relied on the limit of the one executor running, as we in Katello did
>>>> [5]), so just make sure
>>>> to update your version dependencies accordingly.
>>>
>>> In particular, we'll need updated releases of foreman_chef and
>>> foreman_salt in order to ship and publish foreman-tasks 0.7.x, due to
>>> pinning (Stephen, Michael, Marek). A PR for foreman_chef's already up.
>>
>> All done, thanks folks.
>>
>> 0.7.x are in the nightly plugin repos now, so as and when you want, we
>> can republish down to 1.9. Debian packages are straightforward, and for
>> RPMs we'll just have to bring the new dependencies down too and retag.
>
> Let's take that to 1.9. Katello is now foreman-tasks 0.7 ready as well
