Re: [foreman-dev] Taking over plugins - do we need a policy?

2017-07-19 Thread Ewoud Kohl van Wijngaarden

On Wed, Jul 19, 2017 at 10:13:24AM +0200, Marek Hulán wrote:

On úterý 18. července 2017 13:15:22 CEST Greg Sutcliffe wrote:

Hi all,

I've been thinking for a while about plugins, and how to continue them
when original authors move on. It's only natural that developers will
come and go, so we need to think about how to deal with this. We've got
a few examples of this now, and have had others in the past.

1) I'm playing with Salt in my spare time at the moment, with a view to
(maybe) taking on the foreman_salt plugin, since Stephen is no longer
working on it. However, it's only chance that I know this fact -
there's no easy way for an author to mark a plugin as "orphaned".

2) Some plugins are awaiting changes but the author hasn't responded
(yet!). Foreman_bootdisk has some open PRs at the moment that fall into
this category (PRs 42, 43 for example), and default_hostgroup has pen
issues (oops!). Presumably we need a way to ping authors and find out
if they're just AFK or have stepped away from the plugin entirely.

3) Some plugins are definitely abandoned. I recall Chris Pisano taking
over the foreman_banner plugin last year and struggling to get in touch
with the original author at all.

For context, Fedora does have a policy for this that makes some sense:

https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintai
ners

That's quite heavy, but some of the points make sense. So, do we need
to add something to our docs about this. My gut feeling is:

* Yes, we do
* Only applies to plugins in "theforeman" GitHub repo
* We need to add extra maintainers to the Rubygems *before* the author
leaves - Chris had a real issue here. This could be a requirement of
getting aplugin packaged, for example.
* We need to allow authors to "abandon" a plugin clearly (something
like how the Arch User Repository does it maybe?)

Thoughts?
Greg


In general +1. I'm not sure if official policy changes anything, probably does
not do any harm either. It would be great if someone went over all plugins
under theforeman org on github, found projects with single owner and ask the
owner to extend the list. Or someone scritped a simple check so we would avoid
this situation in future. I think what Dmitri described is fair and should
become a common practice for new repos/gems in our org.


+1

--
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] Re: Syncing F26 external repo on Koji

2017-07-19 Thread Lukas Zapletal
So all is finally synced:

epel5-i386: Distribution updated (new: 5118, removed: 0)
epel5-x86_64: Distribution updated (new: 6428, removed: 0)
fedora26-x86_64: Distribution updated (new: 53912, removed: 516)

I was just about to add F26 to koji db, but noticed it's already there:

koji list-external-repos | grep fedora-26
fedora-26
file:///mnt/koji/external-repos/www/fedora26-$arch/RPMS.os/
fedora-26-updates
file:///mnt/koji/external-repos/www/fedora26-$arch/RPMS.updates/

So I guess my job is done then. Have fun.


On Tue, Jul 18, 2017 at 9:59 AM, Lukas Zapletal  wrote:
> Hey,
>
> Sync of Fedora 26 is not yet complete, I will report back when it's ready.
>
> Unfortunately EPEL5 was removed from the mirror we had mrepo
> configured to, it was deleted locally without any warning. I set a
> different mirror and resyncing EPEL5 once again.
>
> If you encounter any missing packages in external repos, ping me I
> have logs so we can resync what's missing.
>
> epel5-i386: Distribution updated (new: 0, removed: 15133) - resyncing now
> epel5-x86_64: Distribution updated (new: 0, removed: 18734) - resyncing now
> epel6-i386: Distribution updated (new: 468, removed: 21697) - looks
> like admin of the mirror deleted old versions of packages - ok
> epel6-x86_64: Distribution updated (new: 547, removed: 28310) - ditto
> epel7-x86_64: Distribution updated (new: 835, removed: 4662) - ditto
> centos6-x86_64: Distribution updated (new: 3185, removed: 0) - looks ok
> centos7-x86_64: Distribution updated (new: 3272, removed: 0) - looks ok
> qpidcopr-i386: Distribution updated (new: 0, removed: 99) - do we use
> that? not sure why it removed packages
> qpidcopr-x86_64: Distribution updated (new: 0, removed: 99) - ditto
>
> LZ
>
> On Mon, Jul 17, 2017 at 10:26 PM, Lukas Zapletal  wrote:
>> Hey,
>>
>> on pulp team request, I am adding external repository fedora26
>> (x86_64) into koji. Initiated the sync, tomorrow I will add that into
>> koji external repositories. For the record, I installed mrepo from
>> sources as it was not available in EPEL7 anymore.
>>
>> Foreman core team haven't decided yet if to carry on with building
>> against Fedora, version 24 might be the last one. I suggest to
>> postpone the final decision until bootstrap in COPR is complete, then
>> we can decide.
>>
>> We can run into space issues quickly on the new koji again as I am
>> unable to remove any existing external repo AFAIK. After F26 is
>> synced, we still have about 200GB space but that's reserved for our
>> builds.
>>
>> centos6-x86_64
>> centos7-x86_64
>> epel5-i386
>> epel5-x86_64
>> epel6-i386
>> epel6-x86_64
>> epel7-x86_64
>> fedora24-x86_64
>> fedora25-x86_64
>> jpackage-x86_64
>> puppetlabsf24-x86_64
>> puppetlabs6-x86_64
>> puppetlabs7-x86_64
>> qpidcopr-i386
>> qpidcopr-x86_64
>> rhel5-i386
>> rhel5-x86_64
>> rhel6-i386
>> rhel6-x86_64
>> rhel7-x86_64
>> rhscl-rhel6-x86_64
>> rhscl-rhel7-x86_64
>>
>> --
>> Later,
>>   Lukas @lzap Zapletal
>
>
>
> --
> Later,
>   Lukas @lzap Zapletal



-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [foreman-dev] Re: plugin configuration management

2017-07-19 Thread Fairouz el ouazi
HI, 
  I already use  NET::HTTP library but i want to know where to add my 
request on my new plugin wich file do i have to add require Net::https ...

Le mardi 18 juillet 2017 13:07:01 UTC+2, Marek Hulán a écrit :
>
> On úterý 18. července 2017 12:15:37 CEST Fairouz el ouazi wrote: 
> > HI, 
> >PLease howa can make  GET or Post request on my new plugin ? 
> > 
> > Le mercredi 12 juillet 2017 17:21:49 UTC+2, Fairouz el ouazi a écrit : 
> > > Hi , 
> > > 
> > > I want to know if foreman plugin (ansible or chef )   
> communicate 
> > > 
> > > with the configuration management server or platform (chef or ansible 
> ) 
> > > using theirs rest Api  ? 
> > > 
> > > Thanks 
>
> You can use any Ruby library but I would recommend using Rest client as 
> it's 
> used elsewhere already. See rest-client documentation [1] for more 
> details. 
> Alternatively you can use Net::HTTP library which is built-in Ruby stdlib 
> [2]. 
>
> However this is not Foreman related so I suggest you consult generic Ruby 
> related queries at Ruby support channels. 
>
> [1] https://github.com/rest-client/rest-client 
> [2] http://ruby-doc.org/stdlib-2.4.1/libdoc/net/http/rdoc/Net/HTTP.html 
>
> Hope this helps 
>
> -- 
> Marek 
>
>

-- 
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] Taking over plugins - do we need a policy?

2017-07-19 Thread Marek Hulán
On úterý 18. července 2017 13:15:22 CEST Greg Sutcliffe wrote:
> Hi all,
> 
> I've been thinking for a while about plugins, and how to continue them
> when original authors move on. It's only natural that developers will
> come and go, so we need to think about how to deal with this. We've got
> a few examples of this now, and have had others in the past.
> 
> 1) I'm playing with Salt in my spare time at the moment, with a view to
> (maybe) taking on the foreman_salt plugin, since Stephen is no longer
> working on it. However, it's only chance that I know this fact -
> there's no easy way for an author to mark a plugin as "orphaned".
> 
> 2) Some plugins are awaiting changes but the author hasn't responded
> (yet!). Foreman_bootdisk has some open PRs at the moment that fall into
> this category (PRs 42, 43 for example), and default_hostgroup has pen
> issues (oops!). Presumably we need a way to ping authors and find out
> if they're just AFK or have stepped away from the plugin entirely.
> 
> 3) Some plugins are definitely abandoned. I recall Chris Pisano taking
> over the foreman_banner plugin last year and struggling to get in touch
> with the original author at all.
> 
> For context, Fedora does have a policy for this that makes some sense:
> 
> https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintai
> ners
> 
> That's quite heavy, but some of the points make sense. So, do we need
> to add something to our docs about this. My gut feeling is:
> 
> * Yes, we do
> * Only applies to plugins in "theforeman" GitHub repo
> * We need to add extra maintainers to the Rubygems *before* the author
> leaves - Chris had a real issue here. This could be a requirement of
> getting aplugin packaged, for example.
> * We need to allow authors to "abandon" a plugin clearly (something
> like how the Arch User Repository does it maybe?)
> 
> Thoughts?
> Greg

In general +1. I'm not sure if official policy changes anything, probably does 
not do any harm either. It would be great if someone went over all plugins 
under theforeman org on github, found projects with single owner and ask the 
owner to extend the list. Or someone scritped a simple check so we would avoid 
this situation in future. I think what Dmitri described is fair and should 
become a common practice for new repos/gems in our org.

--
Marek

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