Re: [foreman-dev] Release process & permissions

2017-09-28 Thread Eric D Helms 
Related to Dmitri's point, and I've thrown this question out with Katello
releases at least every other release, do all the components that are
currently released "together" need to be so these days? That is to say, can
any of the "versioned together components" be released more independently
but within the version stream? For example, say we are approaching 1.17
release, that is a good time to cut puppet releases, installer and
potentially smart proxy but do they need to be released together? Does
Foreman 1.17.1 necessitate a 1.17.1 installer? Or reverse it, does an
installer update have to wait on a Foreman 1.17.1 release?

Katello used to do this practice with a lot of repositories (e.g.
katello-agent, katello-selinux) and were at times releasing projects "just
because" without any real changes. After moving away from that, to let
katello-agent, katello-selinux and hammer-cli-katello more independently
release the process got a lot simpler. Further, I'd argue that each project
got a bit more focused and more thought put into maintenance and release.

Food for thought and discussion.

E


On Thu, Sep 28, 2017 at 2:29 PM, Dmitri Dolguikh 
wrote:

> Why not distribute the release process? Each component can have (probably
> already does) multiple maintainers who are capable of doing most of the
> leg-work. The role of the release nanny then becomes coordinating the
> effort, making public announcements and such. Such an approach would help
> avoid overly broad permissions too.
>
> -d
>
> On Thu, Sep 28, 2017 at 3:23 AM, Ewoud Kohl van Wijngaarden <
> ew...@kohlvanwijngaarden.nl> wrote:
>
>> To release a gem to rubygems I'd recommend looking at how voxpupuli
>> implemented this using Travis[1]. The same can be done for puppet[2]. That
>> means you can push a tag to git and the release is there.
>>
>> There are also tools that help you bump. For puppet there is
>> puppet-blacksmith[3]. How to do annotated tags is in my notes[3]. A more
>> generic script is bump2version[5] and I'm sure there are similar tools in
>> the ruby world.
>>
>> IMHO these tools should be suggested in the plugin templates.
>>
>> [1]: https://github.com/voxpupuli/modulesync/blob/e53079030501756
>> fc4111511fb9b6a239ffcb2a3/.travis.yml#L18-L27
>> [2]: https://github.com/voxpupuli/puppet-nginx/blob/fc363114e509f
>> 439b51ea22723a996ffca8a107d/.travis.yml#L48-L58
>> [3]: https://github.com/voxpupuli/puppet-blacksmith
>> [4]: http://pad-katello.rhcloud.com/p/releasing-modules
>> [5]: https://github.com/c4urself/bump2version
>>
>> On Wed, Sep 27, 2017 at 08:08:46AM -0700, Daniel Lobato wrote:
>>
>>> For foreman-docker I had a process:
>>>
>>> https://github.com/theforeman/foreman-docker/blob/master/rel
>>> ease/RELEASE.md
>>> https://github.com/theforeman/foreman-docker/blob/master/rel
>>> ease/rollout-release
>>>
>>> which I planned to implement in all theforeman org plugins ideally.
>>> It didn't happen but it's a similar thing.
>>>
>>> On Wednesday, September 27, 2017 at 4:56:51 PM UTC+2, Timo Goebel wrote:
>>>

 ... isn‘t continuous delivery old these days? Why aren‘t we doing it?
 I vote in favor of automating this. This ensures predictable results and
 hopefully makes this process easier. To be honest: The current process
 scares me.
 Same for plugin releases. They also are way too manual right now.

 Timo

 > On 27. Sep 2017, at 16:46, Daniel Lobato Garcia  wrote:
 >
 > Hi devs,
 >
 > After a few releases, and now that I'm trying to help someone else to
 > take over in case it's needed, I found a roadblock.
 >
 > Whoever is doing the release, needs to have **many** permissions.
 >
 > Otherwise, it doesn't make much sense for a person to take over
 release
 > responsibilities. For example, if Ondrej has to do 1.15.5, he would
 need
 > the following permissions (see at the end of the email).
 >
 > Of course there are alternatives:
 >
 > 1 is to have the release nanny be supervised by people who have
 'earned'
 > these permissions. This is a bad idea because some of the tasks just
 > cannot be 'supervised'. The nanny would have to ask someone to tag
 > repositories, modify jenkins jobs, upload GPG signatures, post to the
 > mailing list, tag new builds in Koji...
 >
 > 2 is to extend http://ci.theforeman.org/view/Release%20pipeline/ and
 > make it a real pipeline from 0 to release completed. At this moment,
 > releases that are not the first RC1 are mostly automated by
 > https://github.com/dlobatog/foreman_release and
 > https://github.com/theforeman/tool_belt.
 >
 > My proposal is to go forward with 2. Give Jenkins permissions to do
 all
 > of the actions needed, and whoever is the release nanny, ideally only
 > has to make sure all of the steps are moving forward. If something
 > breaks, figure out how to

Re: [foreman-dev] Building an Infra/Deployment/Platform Roadmap

2017-09-28 Thread Eric D Helms 
This has been out for about a week with some comments and discussion so far
on the etherpad. I want to give a round of mention and discussion via -dev
list as well since sometimes etherpad is not obvious for updates. I have
copied the etherpad here. I will leave this thread open for around a week,
at which point, based on discussions that have occurred, take this and copy
it out to a more stable location and begin to give updates routinely on
these items over time.


High Level Needs

   - Rails 5.X


   - need rh-ror50 or custom built SCL


   - consider whether we introduce a new SCL (e.g. tfm-ruby23) to separate
   RPMs built against old SCL vs. new


   - comment mmoll: We would need to upgrade Ruby (to 2.4 or 2.5) later,
   but I'd expect Rails 5.0 and even 5.1 to fully work also on Ruby 2.2


   - commend ekohl: if package names remained equal then it would simplify
   the installer/docs


   - should we jump to 5.1.latest and build the SCL instead? rh-ror50 is
   the last Rails SCL from RHSCL team


   - comment mmoll: with a little help from core and plugin devs, a move to
   Rails 5.1 for 1.17 feels achievable.


   - dlobatog: +1 - introducing the SCL to retire it quite soon will be a
   pain for upgrades and 5.1 for 1.17 doesn't seem that far off.


   - Jenkins Migration


   - Migrate Jenkins master to EL7


   - add https interface to Jenkins


   - Jenkins Job Updates


   - Migrate jobs to pipelines


   - What is the benefit for this effort?


   - modern approach, more secure, provides more efficient jobs, jobs that
   are protected against crashes and restarts


   - Move all jobs into JJB


   - Update JJB code location within git for discoverability


   - Update jobs to run tests with all plugins installed


   - Update hammer core tests to run tests also for the major plugins (at
   least foreman and katello)


   - Add job for running hammer integration tests against live
   foreman/katello


   - Running Container Stack


   - address Github issues created from initial merge


   - remove current hacks in deployment


   - build up test suite for verifying container stack


   - add Jenkins job to build containers nightly


   - find way to continuously test container deployment


   - Merging katello-packaging to foreman-packaging


   - develop and agree on strategy for moving packages


   - move packages


   - any chance of moving Katello tags into foreman-plugins directly?


   - yes, but we need to solve other problems first:


   - updated yum repository structure (see below)


   - individual package release pipelines


   - Release automation


   - Using tool_belt & foreman_release to do the
   cherry_picking/tagging/building/signing automatically


   - Update
   http://projects.theforeman.org/projects/foreman/wiki/Release_Process to
   document how it should work


   - Moving Katello puppet modules to foreman


   - move modules to theforeman Organization


   - add puppet modules to foreman-installer-modulesync


   - Merging katello and foreman installers


   - Move all checks/hooks


   - Add katello modules


   - Move bin/{foreman-proxy-certs-generate,katello-certs-check}


   - Migrate scenarios


   - Sort out the packaging


   - Add deprecation notices to katello-installer / wipe master branch


   - Updated yum repository structure


   - Email thread discussing re-structure of repositories


   - agree on layout


   - re-factor mash scripts for new deployment


   - re-factor sync scripts to yum/deb repositories


   - update foreman release RPM for new repositories


   - Move package building from Koji to Copr


   - Phase 1: Submit builds in paralel - only rubygems and nodejs


   - Phase 2: Submit builds in paralel - foreman-core packages


   - Phase 3: Migrate to Copr


   - Multi-server service deployment


   - Migration off of Openshift V2


   - Redmine


   - prprocessor


   - etherpad


On Tue, Sep 19, 2017 at 8:24 AM, Eric D Helms  wrote:

>
>
> On Tue, Sep 19, 2017 at 5:10 AM, Greg Sutcliffe 
> wrote:
>
>> So, +1 to this idea, we've been lacking in direction for a bit, and a
>> "community roadmap" has been on my agenda for a while. Whilst that's
>> not 1:1 the same as what you're saying, it's related, and planning is a
>> good idea.
>>
>> On Mon, 2017-09-18 at 11:21 -0400, Eric D Helms wrote:
>> >
>> > [1] http://pad-katello.rhcloud.com/p/infra-deployment-roadmap
>>
>> Two things - firstly, isn't this hosted on Openshift v2, which is going
>> away soon? Secondly, are you aware of http://projects.theforeman.org/pr
>> ojects/foreman/wiki/Infrastructure_Updates
>> 
>> on the wiki?
>>
>
> First, yep which I mentioned in the thread related to Openshift V2
> migrations. Second, I am aware of that as thats where I got some of the
> items in the list. When this is all said and done, I can move it to the
> wiki (or somewhere

Re: [foreman-dev] Release process & permissions

2017-09-28 Thread Dmitri Dolguikh 
Why not distribute the release process? Each component can have (probably
already does) multiple maintainers who are capable of doing most of the
leg-work. The role of the release nanny then becomes coordinating the
effort, making public announcements and such. Such an approach would help
avoid overly broad permissions too.

-d

On Thu, Sep 28, 2017 at 3:23 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> To release a gem to rubygems I'd recommend looking at how voxpupuli
> implemented this using Travis[1]. The same can be done for puppet[2]. That
> means you can push a tag to git and the release is there.
>
> There are also tools that help you bump. For puppet there is
> puppet-blacksmith[3]. How to do annotated tags is in my notes[3]. A more
> generic script is bump2version[5] and I'm sure there are similar tools in
> the ruby world.
>
> IMHO these tools should be suggested in the plugin templates.
>
> [1]: https://github.com/voxpupuli/modulesync/blob/e53079030501756
> fc4111511fb9b6a239ffcb2a3/.travis.yml#L18-L27
> [2]: https://github.com/voxpupuli/puppet-nginx/blob/fc363114e509f
> 439b51ea22723a996ffca8a107d/.travis.yml#L48-L58
> [3]: https://github.com/voxpupuli/puppet-blacksmith
> [4]: http://pad-katello.rhcloud.com/p/releasing-modules
> [5]: https://github.com/c4urself/bump2version
>
> On Wed, Sep 27, 2017 at 08:08:46AM -0700, Daniel Lobato wrote:
>
>> For foreman-docker I had a process:
>>
>> https://github.com/theforeman/foreman-docker/blob/master/rel
>> ease/RELEASE.md
>> https://github.com/theforeman/foreman-docker/blob/master/rel
>> ease/rollout-release
>>
>> which I planned to implement in all theforeman org plugins ideally.
>> It didn't happen but it's a similar thing.
>>
>> On Wednesday, September 27, 2017 at 4:56:51 PM UTC+2, Timo Goebel wrote:
>>
>>>
>>> ... isn‘t continuous delivery old these days? Why aren‘t we doing it?
>>> I vote in favor of automating this. This ensures predictable results and
>>> hopefully makes this process easier. To be honest: The current process
>>> scares me.
>>> Same for plugin releases. They also are way too manual right now.
>>>
>>> Timo
>>>
>>> > On 27. Sep 2017, at 16:46, Daniel Lobato Garcia >>
>>> > wrote:
>>> >
>>> > Hi devs,
>>> >
>>> > After a few releases, and now that I'm trying to help someone else to
>>> > take over in case it's needed, I found a roadblock.
>>> >
>>> > Whoever is doing the release, needs to have **many** permissions.
>>> >
>>> > Otherwise, it doesn't make much sense for a person to take over release
>>> > responsibilities. For example, if Ondrej has to do 1.15.5, he would
>>> need
>>> > the following permissions (see at the end of the email).
>>> >
>>> > Of course there are alternatives:
>>> >
>>> > 1 is to have the release nanny be supervised by people who have
>>> 'earned'
>>> > these permissions. This is a bad idea because some of the tasks just
>>> > cannot be 'supervised'. The nanny would have to ask someone to tag
>>> > repositories, modify jenkins jobs, upload GPG signatures, post to the
>>> > mailing list, tag new builds in Koji...
>>> >
>>> > 2 is to extend http://ci.theforeman.org/view/Release%20pipeline/ and
>>> > make it a real pipeline from 0 to release completed. At this moment,
>>> > releases that are not the first RC1 are mostly automated by
>>> > https://github.com/dlobatog/foreman_release and
>>> > https://github.com/theforeman/tool_belt.
>>> >
>>> > My proposal is to go forward with 2. Give Jenkins permissions to do all
>>> > of the actions needed, and whoever is the release nanny, ideally only
>>> > has to make sure all of the steps are moving forward. If something
>>> > breaks, figure out how to fix it for the next release.
>>> >
>>> > This would mean making a few extra jobs before and after the current
>>> > release pipeline. In my opinion, it's the way to go to ensure anyone
>>> can
>>> > take over this responsibility.
>>> >
>>> > At this moment, we are in a situation where only people who
>>> > mostly have permissions everywhere can successfully do a release
>>> without
>>> > asking many people for favors.
>>> >
>>> > Personally if we complete this, I see it as a big win as it would dwarf
>>> > our bus factor for release managers & allow us to release at any pace
>>> we
>>> > desire (right now it's slow because we can't truly release things from
>>> > one day to the next due to the work involved).
>>> >
>>> > Thoughts?
>>> >
>>> > Here's the list of permissions:
>>> >
>>> > 
>>> >
>>> > Github:
>>> >  - Push in foreman, foreman-selinux, foreman-installer,
>>> >smart-proxy, foreman-infra, foreman-packaging
>>> >
>>> > Transifex -
>>> >  - Allow to change the auto-update URL to point to latest -stable
>>> >branch
>>> >
>>> > Redmine -
>>> >  - Create new "Found in Release" version
>>> >
>>> > Jenkins -
>>> >  - Modify jobs
>>> >  - Run jobs
>>> >
>>> > Koji -
>>> >  - Create tags
>>> >  - SSH access to update the mash scripts
>>> >  - Create

Re: [foreman-dev] Requesting discovery test for core PRs

2017-09-28 Thread Evgeni Golov 
On Wed, Sep 27, 2017 at 7:26 PM, Timo Goebel  wrote:
> ... have you considered using some kind of a CDN for downloads, e.g. 
> cloudflare, if traffic is a concern?

fastly.com is usually happy to sponsor bandwidth for FOSS projects, if
you ask nicely (they sponsor one half of deb.debian.org, for example,
the other half is sponsored by AMZN).

I could talk to the relevant people if that is something we want.

Evgeni Golov
Software Engineer

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander

-- 
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] Release process & permissions

2017-09-28 Thread Ewoud Kohl van Wijngaarden 
To release a gem to rubygems I'd recommend looking at how voxpupuli 
implemented this using Travis[1]. The same can be done for puppet[2]. 
That means you can push a tag to git and the release is there.


There are also tools that help you bump. For puppet there is 
puppet-blacksmith[3]. How to do annotated tags is in my notes[3]. A 
more generic script is bump2version[5] and I'm sure there are similar 
tools in the ruby world.


IMHO these tools should be suggested in the plugin templates.

[1]: 
https://github.com/voxpupuli/modulesync/blob/e53079030501756fc4111511fb9b6a239ffcb2a3/.travis.yml#L18-L27
[2]: 
https://github.com/voxpupuli/puppet-nginx/blob/fc363114e509f439b51ea22723a996ffca8a107d/.travis.yml#L48-L58
[3]: https://github.com/voxpupuli/puppet-blacksmith
[4]: http://pad-katello.rhcloud.com/p/releasing-modules
[5]: https://github.com/c4urself/bump2version

On Wed, Sep 27, 2017 at 08:08:46AM -0700, Daniel Lobato wrote:

For foreman-docker I had a process:

https://github.com/theforeman/foreman-docker/blob/master/release/RELEASE.md
https://github.com/theforeman/foreman-docker/blob/master/release/rollout-release

which I planned to implement in all theforeman org plugins ideally.
It didn't happen but it's a similar thing.

On Wednesday, September 27, 2017 at 4:56:51 PM UTC+2, Timo Goebel wrote:


... isn‘t continuous delivery old these days? Why aren‘t we doing it?
I vote in favor of automating this. This ensures predictable results and
hopefully makes this process easier. To be honest: The current process
scares me.
Same for plugin releases. They also are way too manual right now.

Timo

> On 27. Sep 2017, at 16:46, Daniel Lobato Garcia  wrote:
>
> Hi devs,
>
> After a few releases, and now that I'm trying to help someone else to
> take over in case it's needed, I found a roadblock.
>
> Whoever is doing the release, needs to have **many** permissions.
>
> Otherwise, it doesn't make much sense for a person to take over release
> responsibilities. For example, if Ondrej has to do 1.15.5, he would need
> the following permissions (see at the end of the email).
>
> Of course there are alternatives:
>
> 1 is to have the release nanny be supervised by people who have 'earned'
> these permissions. This is a bad idea because some of the tasks just
> cannot be 'supervised'. The nanny would have to ask someone to tag
> repositories, modify jenkins jobs, upload GPG signatures, post to the
> mailing list, tag new builds in Koji...
>
> 2 is to extend http://ci.theforeman.org/view/Release%20pipeline/ and
> make it a real pipeline from 0 to release completed. At this moment,
> releases that are not the first RC1 are mostly automated by
> https://github.com/dlobatog/foreman_release and
> https://github.com/theforeman/tool_belt.
>
> My proposal is to go forward with 2. Give Jenkins permissions to do all
> of the actions needed, and whoever is the release nanny, ideally only
> has to make sure all of the steps are moving forward. If something
> breaks, figure out how to fix it for the next release.
>
> This would mean making a few extra jobs before and after the current
> release pipeline. In my opinion, it's the way to go to ensure anyone can
> take over this responsibility.
>
> At this moment, we are in a situation where only people who
> mostly have permissions everywhere can successfully do a release without
> asking many people for favors.
>
> Personally if we complete this, I see it as a big win as it would dwarf
> our bus factor for release managers & allow us to release at any pace we
> desire (right now it's slow because we can't truly release things from
> one day to the next due to the work involved).
>
> Thoughts?
>
> Here's the list of permissions:
>
> 
>
> Github:
>  - Push in foreman, foreman-selinux, foreman-installer,
>smart-proxy, foreman-infra, foreman-packaging
>
> Transifex -
>  - Allow to change the auto-update URL to point to latest -stable
>branch
>
> Redmine -
>  - Create new "Found in Release" version
>
> Jenkins -
>  - Modify jobs
>  - Run jobs
>
> Koji -
>  - Create tags
>  - SSH access to update the mash scripts
>  - Create packages
>  - Tag builds
>
> Repository servers
>  - ssh in deb.theforeman.org
>  - ssh in yum.theforeman.org
>
> Announcements -
>  - Post to foreman-announce
>  - Merge access in theforeman.org
>  - Change IRC message
>  - Publish in Twitter, G+
>
> ---
>
> --
> Daniel Lobato Garcia
>
> @dLobatog
> blog.daniellobato.me
> daniellobato.me
>
> GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30
> Keybase: https://keybase.io/elobato
>
> --
> 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...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.




--
You received this message because you are subscribed to the Google Groups

Re: [foreman-dev] Release process & permissions

2017-09-28 Thread Ewoud Kohl van Wijngaarden 
While I agree we should automate a lot, I agree with Eric. Doing a 
Foreman release should involve a human to keep the end-to-end quality. 
Just giving permissions is wrong.


For example in Foreman 1.15.5 the installer was tagged and released 
before I could push in my changes. That communication failure might have 
been partly my fault but IMHO the job of a release manager is to 
communicate with all the maintainers if everything is in place for a 
release.


Now you state it as a problem that you need a lot of people, but you 
need to communicate with them anyway. Yes, the tagging and releasing 
should be scripted but planning a release will require humans.


Like Eric I think we should start by documenting. Right now it's a huge 
black box for most people, let's start there.


On Wed, Sep 27, 2017 at 09:19:10PM -0400, Eric D Helms wrote:

There are two considerations that I'd like to put forth as we think about
this:

1) Instead of adding jobs, we re-think and re-write the release job in
Pipeline syntax similar to my starter here --
https://github.com/theforeman/foreman-infra/pull/323
2) We don't automate all the things as there are some tasks that should be
done by a human. The tedious, repetitive bits we should automate. The
aspects that require some human foresight, approval or double checking of
we should either require a releaser to "yes" to a job over or to perform
semi-automated in that the user uses tooling but ultimately has input. For
example, cherry picking should be 90% automated but 10% human input to
ensure nothing seems off since our issue-to-change is not flawless.

While we have some automation already in place, from my experience I would
recommend one of the following approaches.

1) create a flow chart of every action that has to happen using something
like plantuml with parallel actions where possible
2) Create a new release job, starting either from the beginning or the end
of the process and add each next step to it


Eric

On Wed, Sep 27, 2017 at 10:46 AM, Daniel Lobato Garcia 
wrote:


Hi devs,

After a few releases, and now that I'm trying to help someone else to
take over in case it's needed, I found a roadblock.

Whoever is doing the release, needs to have **many** permissions.

Otherwise, it doesn't make much sense for a person to take over release
responsibilities. For example, if Ondrej has to do 1.15.5, he would need
the following permissions (see at the end of the email).

Of course there are alternatives:

1 is to have the release nanny be supervised by people who have 'earned'
these permissions. This is a bad idea because some of the tasks just
cannot be 'supervised'. The nanny would have to ask someone to tag
repositories, modify jenkins jobs, upload GPG signatures, post to the
mailing list, tag new builds in Koji...

2 is to extend http://ci.theforeman.org/view/Release%20pipeline/ and
make it a real pipeline from 0 to release completed. At this moment,
releases that are not the first RC1 are mostly automated by
https://github.com/dlobatog/foreman_release and
https://github.com/theforeman/tool_belt.

My proposal is to go forward with 2. Give Jenkins permissions to do all
of the actions needed, and whoever is the release nanny, ideally only
has to make sure all of the steps are moving forward. If something
breaks, figure out how to fix it for the next release.

This would mean making a few extra jobs before and after the current
release pipeline. In my opinion, it's the way to go to ensure anyone can
take over this responsibility.

At this moment, we are in a situation where only people who
mostly have permissions everywhere can successfully do a release without
asking many people for favors.

Personally if we complete this, I see it as a big win as it would dwarf
our bus factor for release managers & allow us to release at any pace we
desire (right now it's slow because we can't truly release things from
one day to the next due to the work involved).

Thoughts?

Here's the list of permissions:



Github:
  - Push in foreman, foreman-selinux, foreman-installer,
smart-proxy, foreman-infra, foreman-packaging

Transifex -
  - Allow to change the auto-update URL to point to latest -stable
branch

Redmine -
  - Create new "Found in Release" version

Jenkins -
  - Modify jobs
  - Run jobs

Koji -
  - Create tags
  - SSH access to update the mash scripts
  - Create packages
  - Tag builds

Repository servers
  - ssh in deb.theforeman.org
  - ssh in yum.theforeman.org

Announcements -
  - Post to foreman-announce
  - Merge access in theforeman.org
  - Change IRC message
  - Publish in Twitter, G+

---

--
Daniel Lobato Garcia

@dLobatog
blog.daniellobato.me
daniellobato.me

GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30
Keybase: https://keybase.io/elobato

--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving

Re: [foreman-dev] SmartOS (Solaris 11), Joyent cloud

2017-09-28 Thread Greg Sutcliffe 
On Wed, 2017-09-27 at 12:24 -0700, Dmitriy Morozovsky wrote:
> Hello dear team.
> I see you support Solaris 8,10 what about Solaris 11 or SmartOS
> Our big infrastructure based on Joyent Cloud and we looking for
> support of Foreman on Solaris 11

As with much of the OS support in Foreman, the Solaris handling we have
today was contributed by the community. I don't know anyone who's
currently using it / working on it, so unless someone volunteers to
take it on, I don't think this will happen.

Obviously, if anyone does want to work on this, the people on this list
will help where we can ;)

Greg

-- 
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] Requesting discovery test for core PRs

2017-09-28 Thread Greg Sutcliffe 
On Wed, 2017-09-27 at 19:26 +0200, Timo Goebel wrote:
> ... have you considered using some kind of a CDN for downloads, e.g.
> cloudflare, if traffic is a concern?
> 
> > I'll see what I can do. The Rackspace billing does provide an
> > extensive CSV of all charges (several MB, which for CSV is
> > impressive :P), so I may well be able to pull something from that.

So yes, it's our package mirror:

Total bandwidth charge last month: $723.15
Bandwidth charges for web02: $706.79

What's harder to tell is who's consuming it - i.e. is it our users, or
just the repeated runs of the installer etc in BATS?

In any case, yes, some kind of offloading of this would give us vastly
more capability in the CI area.

Greg

-- 
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.

[foreman-dev] SmartOS (Solaris 11), Joyent cloud

2017-09-28 Thread Dmitriy Morozovsky 
Hello dear team.
I see you support Solaris 8,10 what about Solaris 11 or SmartOS
Our big infrastructure based on Joyent Cloud and we looking for support of 
Foreman on Solaris 11
Thanks.

-- 
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.