work_mem check for nagios client

[Michal Novotny]

Hello,

I've noticed there is no work_mem check
https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/nagios_client/templates
that would test that working memory is inside allowed limits.

I've recently made the work_mem check but specific just to COPR:
https://clime.cz/0001-copr-fe-working-memory-monitoring.patch. It
raises a warning when working memory usage is higher than 80% and
criticial if it is higher than 90%.

Would it be worth to place this check alongside others in
https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/nagios_client/templates
so that it can be used for any host?

Thank you
clime
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

dist-git 1.10 release

[Michal Novotny]

Hello,

I've released a new version of dist-git 1.10
(https://github.com/release-engineering/dist-git). The main thing in
there is python2/3 compatibility. When deployed in Fedora, it uses
python3 now.
I've also fixed a small bug in post-receive hook when there were no
hooks to run in post-receive-chained.d and did a few fixes in tests.

You can see the updates here:
https://bodhi.fedoraproject.org/updates/?packages=dist-git

clime
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: FBR: Make clime be on the pager for COPR

[Michal Novotny]

Thanks! Finally, I will immediately know that Copr doesn't work.

On Sat, Oct 20, 2018 at 3:52 PM Patrick マルタインアンドレアス Uiterwijk <
puiterw...@redhat.com> wrote:

> Hi all,
>
> Can I get +1s for the patchset to allow clime to ack service and host
> issues in nagios, and to make the initial COPR notifs go to him?
>
> Patrick
>
>
> From 1994c662f8eabcec78f24a8d7b2edc155d25bac2 Mon Sep 17 00:00:00 2001
> From: Patrick Uiterwijk 
> Date: Sat, 20 Oct 2018 11:19:57 +0200
> Subject: [PATCH 1/3] Allow clime to ack services
>
> Signed-off-by: Patrick Uiterwijk 
> ---
>  roles/nagios_server/templates/nagios/configs/cgi.cfg.j2 | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/roles/nagios_server/templates/nagios/configs/cgi.cfg.j2
> b/roles/nagios_server/templates/nagios/configs/cgi.cfg.j2
> index 5929a6c78..b7992f168 100644
> --- a/roles/nagios_server/templates/nagios/configs/cgi.cfg.j2
> +++ b/roles/nagios_server/templates/nagios/configs/cgi.cfg.j2
> @@ -173,9 +173,9 @@ authorized_for_all_hosts=*
>
>  #authorized_for_all_service_commands=nagiosadmin
>  #authorized_for_all_host_commands=nagiosadmin
>
> -authorized_for_all_service_commands=averi,codeblock,kevin,nb,pfrields,puiterwijk,smooge,tibbs,pbrobinson,spot,pingou,tflink,mizdebsk,msimacek,stickster,bstinson,cverna
>
> +authorized_for_all_service_commands=averi,codeblock,kevin,nb,pfrields,puiterwijk,smooge,tibbs,pbrobinson,spot,pingou,tflink,mizdebsk,msimacek,stickster,bstinson,cverna,clime
>
>
> -authorized_for_all_host_commands=averi,codeblock,kevin,nb,pfrields,puiterwijk,smooge,tibbs,pbrobinson,spot,pingou,tflink,mizdebsk,msimacek,stickster,bstinson,cverna
>
> +authorized_for_all_host_commands=averi,codeblock,kevin,nb,pfrields,puiterwijk,smooge,tibbs,pbrobinson,spot,pingou,tflink,mizdebsk,msimacek,stickster,bstinson,cverna,clime
>
>  # STATUSMAP BACKGROUND IMAGE
>  # This option allows you to specify an image to be used as a
> --
> 2.17.1
>
>
> From 192e13613f1e68ad7dce2783fce1f18f73c95a6a Mon Sep 17 00:00:00 2001
> From: Patrick Uiterwijk 
> Date: Sat, 20 Oct 2018 11:22:01 +0200
> Subject: [PATCH 2/3] Add contact info for clime
>
> Signed-off-by: Patrick Uiterwijk 
> ---
>  .../nagios_server/files/nagios/contactgroups/copr.cfg |  6 ++
>  roles/nagios_server/files/nagios/contacts/clime.cfg   | 11 +++
>  2 files changed, 17 insertions(+)
>  create mode 100644 roles/nagios_server/files/nagios/contactgroups/copr.cfg
>  create mode 100644 roles/nagios_server/files/nagios/contacts/clime.cfg
>
> diff --git a/roles/nagios_server/files/nagios/contactgroups/copr.cfg
> b/roles/nagios_server/files/nagios/contactgroups/copr.cfg
> new file mode 100644
> index 0..c404e7f3e
> --- /dev/null
> +++ b/roles/nagios_server/files/nagios/contactgroups/copr.cfg
> @@ -0,0 +1,6 @@
> +define contactgroup {
> +contactgroup_name   copr
> +alias   COPR Notifications
> +members clime
> +
> +}
> diff --git a/roles/nagios_server/files/nagios/contacts/clime.cfg
> b/roles/nagios_server/files/nagios/contacts/clime.cfg
> new file mode 100644
> index 0..e33c4d007
> --- /dev/null
> +++ b/roles/nagios_server/files/nagios/contacts/clime.cfg
> @@ -0,0 +1,11 @@
> +define contact{
> +   contact_nameclime
> +   alias   clime
> +   service_notification_period 24x7
> +   host_notification_period24x7
> +   service_notification_optionsw,u,c,r
> +   host_notification_options   d,u,r
> +   service_notification_commands   notify-by-epager
> +   host_notification_commands  host-notify-by-epager
> +   pager   cl...@redhat.com
> +}
> --
> 2.17.1
>
>
> From 2ef75ed7be038996940b5145a1824f459cfa6d79 Mon Sep 17 00:00:00 2001
> From: Patrick Uiterwijk 
> Date: Sat, 20 Oct 2018 11:37:31 +0200
> Subject: [PATCH 3/3] Set COPR backend to send notifs to copr
>
> Signed-off-by: Patrick Uiterwijk 
> ---
>  roles/nagios_server/files/nagios/services/copr.cfg | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/roles/nagios_server/files/nagios/services/copr.cfg
> b/roles/nagios_server/files/nagios/services/copr.cfg
> index add302185..2f1f09824 100644
> --- a/roles/nagios_server/files/nagios/services/copr.cfg
> +++ b/roles/nagios_server/files/nagios/services/copr.cfg
> @@ -3,4 +3,5 @@ define service {
>  service_descriptionCheck Copr backend consecutive build failures
>  check_command  check_by_nrpe!check_copr_backend_failed
>  usedefaulttemplate
> +contact_groups copr
>  }
> --
> 2.17.1
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 

Re: Moving forward with Fedora's PDC

[Michal Novotny]

On Mon, Sep 24, 2018 at 2:43 PM Clement Verna  wrote:
>
>
>
> On Mon, 24 Sep 2018 at 11:30, Michal Novotny  wrote:
>>
>> Hello,
>>
>> could we use this?
>>
>> https://github.com/PostgREST/postgrest
>
>
> While I don't have a strong preference for one or the other, the main reason 
> we decided to use DRF is to be able to reuse some of code from PDC 
> (https://github.com/product-definition-center/product-definition-center). We 
> are currently working on the releases endpoint 
> (https://github.com/fedora-infra/fpdc) and to be fair we did not reuse to 
> much code so far, but I expect that it will be the case when working on 
> components and composes endpoint.

I guess it mainly depends on the people doing the work (that means you
and the rest of the pack).

clime

>
>
>>
>> we could trim down PDC to just db + REST API (+ git backend syncing
>> through hooks?)
>>
>> It's written in Haskell (!!) and it looks really like a useful piece
>> of technology.
>>
>> We could drop Django completely and have git for any write changes, which
>> means we will automatically get:
>>
>> - version control
>> - acls
>> - public interface
>>
>> for free without any future maintenance.
>>
>> Only the writeable/interesting parts of PDC would be in DistGit.
>>
>> I don't know what will be stored in PDC at this point but I think
>> just db + REST + git would be a suitable stack for a high-level
>> release-engineering-like settings.
>>
>> clime
>>
>> P.S. I would personally be happy to help with this setup.
>>
>> On Wed, Sep 12, 2018 at 8:57 PM Randy Barlow
>>  wrote:
>> >
>> > On 09/12/2018 04:01 AM, Clement Verna wrote:
>> > > [0] https://github.com/dhatim/python-license-check
>> >
>> > This looks useful, thanks for sharing!
>> >
>> > ___
>> > infrastructure mailing list -- infrastructure@lists.fedoraproject.org
>> > To unsubscribe send an email to 
>> > infrastructure-le...@lists.fedoraproject.org
>> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > List Archives: 
>> > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>> ___
>> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
>> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: Anitya 0.13.0 (release-monitoring) deployed on staging

[Michal Novotny]

On Thu, Sep 13, 2018 at 9:42 AM Michal Konečný  wrote:
>
> Hi everybody,
>
> I want to announce that the Anitya 0.13.0 was finally deployed on
> staging (https://stg.release-monitoring.org/)
>
> Feel free to test it.
>
> You can see the changelog here:
> https://github.com/release-monitoring/anitya/releases/tag/0.13.0

Thanks a lot!

>
> Regards,
> mkonecny
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: libravatar in Fedora OpenShift

[Michal Novotny]

On Sat, Aug 18, 2018 at 7:09 PM Mikolaj Izdebski 
wrote:

> Hi Michal,
>
> On 08/01/2018 08:07 AM, Michal Novotny wrote:
> > Hello,
> >
> > I would like to ask if anyone is willing to sponsor running libravatar (
> > https://git.linux-kernel.at/oliver/ivatar) in Fedora OpenShift per
> >
> https://docs.pagure.org/infra-docs/sysadmin-guide/sops/requestforresources.html
> .
> > I think we could use the automatic deployment options that OpenShift
> offers
> > (Git update -> OpenShift pod update) to our advantage. OpenShift is also
> > the platform where the current development instance runs
> > http://ivatar-ivatar.1d35.starter-us-east-1.openshiftapps.com/.
>
> If I remember correctly I read somewhere that libravatar is not being
> decommissioned after all. Is this RFR still relevant then? If yes then I
> can probably sponsor it.
>

Hello,

That would be cool! It's not going to be decommissioned but we are
still looking for a suitable place to run it. Right now, it is running on a
temporary VM. I will visit tomorrow's IRC of libravatar's working group :)
so there I will get more info if there is still interest to run it in
Fedora.
If so, I would very welcome your sponsorship.

Best regards!
M.


>
> --
> Mikolaj Izdebski
> Senior Software Engineer, Red Hat
> IRC: mizdebsk
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/6DP26HEZYEZTMTTH5WJZYAAU3KJ6CXHO/

Re: fedora messaging

[Michal Novotny]

On Fri, Aug 17, 2018 at 9:40 AM Jeremy Cline  wrote:

> On 08/16/2018 06:22 PM, Michal Novotny wrote:
> > On Thu, Aug 16, 2018 at 4:34 PM Jeremy Cline  wrote:
> >>
> >> So, am I right in saying your main objection is the Python package? Or
> >> do you object to then packaging that as an RPM?
> >>
> >
> > I don't really have any objections. I would just like to be able to read
> > messages as simple language-native structures and don't depend on
> > anything else than the base messaging framework when publishing or
> > receiving messages.
>
> Okay. You can do that now. There's a base Message class whose only
> schema restriction is that the message is a JSON object. You're free to
> use that and access the JSON directly, or to use an AMQP client directly
> (as long as you follow the same on-the-wire format).


Will the framework provide me with a way to automatically validate against
a schema that I have locally defined e.g.

my_locally_defined_schema_that_i_can_then_publish_in_docs = {
"type" : "object",
"properties" : {
"price" : {"type" : "number"},
"name" : {"type" : "string"},
},}

if I want to use just the base Message? It would be good if I could
pass the body_scheme to Message __init__ method and have
that validated by api.publish, which would then invoke e.g.
message.validate().
Would it be possible?

Just be aware that
> any messages you send that way will integrate poorly (or not at all)
> with services like notifications.
>

I would like it to integrate well if possible...


>
> I really don't recommend this approach since we've been down this path
> before and it's worked rather poorly


Okay, but the question is why it was working poorly. From what I've seen,
the problems with fedmsg-meta would be just solved just by the explicit
scheme
validation on publisher side, which is really a cool thing you are
introducing
and it will help a lot.

Another thing that it is quite unclear why that service just got completely
stuck
when it couldn't process a message. Normally, you would just collect what
you
can collect out of the incoming message and send what you have collected
(i.e.
with some fields not filled). It only constructed human-readable strings
for notifications,
right? I don't think that's so mission critical even though important.

But anyway, still, if we have validation on publisher built-in into the
framework, that's
enough to solve that problem. Why would we need anything else?
> Schema are Immutable

> Message schema should be treated as immutable. Once defined, they should
not be altered. Instead, define a new schema class, mark the old one as
deprecated, and remove it after an appropriate transition period.
I think that adding new fields into the json should be simply allowed.
That's not a backward incompatible change. The
consumer doesn't use those fields because they have been just introduced so
you can't break a consuming script like that.

> Finally, you must distribute your schema to clients. It is recommended
that you maintain your message schema in your application’s git repository
in a separate Python package. The package name should be
_schema.

What I was thinking about is to have the .json schema in a separate file
with recommendation that it contains URL to itself as ID (
https://pagure.io/copr/copr/raw/master/f/dist-git/my_schema.json). Given
that the schema can be self descriptive
(because there are the 'description' fields), then this should be
completely enough to even provide the documentation and at the same time,
that schema will be the actual schema publisher will use for validation.

I think this is much more chilled out approach which is, at the same time,
solving the problem with publisher sending something else than he/she
thinks he/she is sending. I think that was the main problem we were having,
no?


> --
> Jeremy Cline
> XMPP: jer...@jcline.org
> IRC:  jcline
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/5YSYWLA2VKYXXES2ZB5A4OTS6KL4O7GB/

Re: fedora messaging

[Michal Novotny]

On Thu, Aug 16, 2018 at 4:34 PM Jeremy Cline  wrote:

> On 08/16/2018 11:53 AM, Michal Novotny wrote:
> > On Thu, Aug 16, 2018 at 11:43 AM Jeremy Cline  wrote:
> 
>
> >> The current solution is fedmsg-meta-fedora-infrastructure, a central
> >> Python module where schema are poorly encoded by a series of if/else
> >> statements. It also regularly breaks when message schema change. For
> >> example, I have 2200 emails from the notifications system about how some
> >> Copr and Bodhi messages are unparsable. No one remembers to update the
> >> package, and it ultimately means their messages are dropped or arrive to
> >> users as incomprehensible JSON.
> >>
> >
> > Yup, on behalf of Copr, I am sorry for that. This was caused by some
> bugs in
> > our code. But these things would be captured by the publisher validation
> in
> > the new framework. By the way, we would also like to have validators like
> > "NEVRA" available, maybe in a library, maybe we can implement it
> ourselves.
> > In one of the instances, we weren't sending release (I think) and it
> broke
> > the
> > fedmsg-meta service. That service is kind of sensitive.
> >
>
> Yes, it is sensitive. And to be clear, I'm not pointing fingers here.
> It's just a good example of how what we're doing now doesn't work. I
> want to put the ability (and responsibility) to making a message
> readable and documented in the hands of app maintainers.
>
> >
> >>
> >> With the current approach, you can just implement a __str__ method on a
> >> class you keep in the same Git repo you use for your project. You can
> >> write documentation on the classes so users can see what messages your
> >> projects send. You can release it whenever you see fit, not when whoever
> >> maintains fedmsg-meta has time to make a release.
> >>
> >> It seems like your main objection is the Python package. Personally, I
> >> think making a Python package is a trivial amount of work for the
> >> benefit of being able to define an arbitrary Python API to work with
> >> your messages, but maybe that's not a widely-shared sentiment. If it's
> >> not and we decide the only thing we really want in addition to the
> >> message is a human-readable string, maybe we could include that in the
> >> message in a standard way.
> >
> >
> > Might be also a way.
>
> So, am I right in saying your main objection is the Python package? Or
> do you object to then packaging that as an RPM?
>

I don't really have any objections. I would just like to be able to read
messages as simple language-native structures and don't depend on
anything else than the base messaging framework when publishing or
receiving messages.


>
>
> --
> Jeremy Cline
> XMPP: jer...@jcline.org
> IRC:  jcline
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/ADBAJELLLYXU7SAHZFFHGJTOLD7OKRJF/

Re: fedora messaging

[Michal Novotny]

On Thu, Aug 16, 2018 at 11:43 AM Jeremy Cline  wrote:

> On 08/15/2018 01:53 PM, Michal Novotny wrote:>> 1. Make catching
> accidental schema changes as a publisher easy.
> >
> > So we can just solve this by registering the scheme with the publisher
> > first before any content gets published and based on the scheme, the
> > publisher
> > instance may check if the content intended to be sent conforms to
> > the scheme, which could catch some bugs before the content
> > is actually sent. If we require this to be done on publisher side, then
> > there is actually no reason to send the schema alongside the content
> > because the check has already been done so consumer already knows
> > the message is alright when it is received. What should be sent, however,
> > is a scheme ID, e.g. just a natural number. The scheme ID may be then
> > used to version the scheme, which would be available somewhere publicly
> > e.g. in the service docs the same way Github/Gitlab/etc publishes
> structures
> > of their webhook messages. It would be basically part of public API of
> > a service.
>
> Yes, the schema needs unique identifier. This is currently provided by
> the full Python path of the class, but could be done a different way, as
> you point out.
>
> >
> >> 2. Make catching mis-behaving publishers on the consuming side easy.
> >
> > By checking against the scheme on the publisher side, this
> > shouldn't be necessary. If someone somehow bypasses the
> > publisher check, at worst the message won't be parsable,
> > depending on how the message is being parsed. If someone
> > wants to really make sure the message is what it is supposed
> > to be, he/she can integrate the schema published on the service
> > site into the parsing logic but I don't think that's necessary
> > thing to do (I personally wouldn't do it in my code).
> >
>
> So most of the work in fedora-messaging is to make this as painless as
> possible. Checking the message on both the publisher side and consumer
> side is helpful for a few reasons. For example, the publisher changes
> the schema and fails to change the unique identifier for it (however
> that's being defined)?
>
> >> 3. Make changing the schema a painless process for publishers and
> >consumers.
> >
> > I think, the only way to do this is to send both content types
> > simultaneously
> > for some time, each message being marked with its scheme ID. It would be
> > good if consumer always specified what scheme ID it wants to consume.
> > If there is a higher scheme ID available in the message, a warning could
> be
> > printed
> > maybe even to syslog even so that consumers get the information. At the
> > same time it should
> > be communicated on the service site or by other means available. I don't
> > think it is possible
> > to make it any better than this.
>
> It's not the only way to do it, but it is one way to do it. It's all a
> matter of complexity and where you want to put that complexity. You can,
> for example, have a scheme where routing key (topic) includes the schema
> identity. With this approach, apps need to publish both for a while, and
> then drop the old topic at some point. That's fine.
>
> You can run an intermediate service that knows the various schema and
> publishes every version. That's fine, too.
>
> You can do what we opted to do and produce a schema, wrap it in a
> high-level API, and then change it without breaking that high-level API.
> This, of course, requires distributing that high-level API, thus the
> packaging. If this _isn't_ the route we go, the rule basically becomes
> "no changing your message schema ever, just make a new type".
>
> It all comes to the same thing in the end, it's just a matter of where
> you deal with compatibility changes. What I'm advocating for is not
> making the wire format (some JSON dictionary) the public API because
> that has worked very poorly for fedmsg. If the wire format was something
> like a protocol buffer, it has some of these ideas built in and is more
> reasonable to use directly (although in some cases of higher-level APIs
> can be useful).
>
> >
> > I fail to see what's the point of packaging the schemas.
> > If the message content is in json, then after receiving the message,
> > I would like to be able to just call json.loads(msg) and work with the
> > resulting structure
> > as I am used to.
> >
> > Actually, what I would do in python is that I would make it a munch and
> > then work
> > with it. Needing to install some additional package and instantiate some
>

new release: dist-git 1.8

[Michal Novotny]

Hello,

a new dist-git version has been released. Changes include:

   - fix python-grokmirror dep
   - add lookaside_dir option, deprecate cache_dir
   - defattr is not needed since rpm 4.2
   - add disable_group_check configuration option for upload script

Probably the most interesting one is that there is now option to disable
packager group check for uploading. By default the check is on and for
Fedora the check is enabled. This is intended for other distros (that e.g.
do not have the 'packager' group) to be able to use this package.

The update for EL7 is here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-c0a3cc60b1

clime
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/MAVPB3QH6DPJ2VXLOPBDTXD62H4QUVAC/

Re: fedora messaging

[Michal Novotny]

Oh yeah, protocol buffers are useful probably in strongly typed languages
with
lots of types to maintain that type information and being able to parse out
the
serialized content based on that type information. But in case we are
transferring
json, we send the type information in the content itself ({}, [], "",
) so we
don't need to know anything else except the content, we just need to decide
how we are going to transform the content into language-native structures.
It is just an additional thing that I've just realized but I am little bit
guessing here.
It might not be relevant. Forgive me if it is not.

On Wed, Aug 15, 2018 at 2:53 PM Michal Novotny  wrote:

> > Anyway, to summarize, I really really want this to be super easy to use
> and just work. I hope we can improve it further and I'd love to hear
> your thoughts. Do you think my problem statements and design goals are
> reasonable? Given those, do you still feel like sending the schema along
> is worthwhile?
>
> I actually no longer think it is worthwhile.
>
> > As a consumer, I can validate the JSON in a message matches the JSON
> schema
> in the same message, but what does that get me? It doesn't seem any
> different (on the consumer side) than just parsing the JSON outright and
> trying to access whatever deserialized object I get.
>
> I completely agree with this.
>
> Let's go through the problems you mentioned:
>
> 1. Make catching accidental schema changes as a publisher easy.
>
> So we can just solve this by registering the scheme with the publisher
> first before any content gets published and based on the scheme, the
> publisher
> instance may check if the content intended to be sent conforms to
> the scheme, which could catch some bugs before the content
> is actually sent. If we require this to be done on publisher side, then
> there is actually no reason to send the schema alongside the content
> because the check has already been done so consumer already knows
> the message is alright when it is received. What should be sent, however,
> is a scheme ID, e.g. just a natural number. The scheme ID may be then
> used to version the scheme, which would be available somewhere publicly
> e.g. in the service docs the same way Github/Gitlab/etc publishes
> structures
> of their webhook messages. It would be basically part of public API of
> a service.
>
> 2. Make catching mis-behaving publishers on the consuming side easy.
>
> By checking against the scheme on the publisher side, this
> shouldn't be necessary. If someone somehow bypasses the
> publisher check, at worst the message won't be parsable,
> depending on how the message is being parsed. If someone
> wants to really make sure the message is what it is supposed
> to be, he/she can integrate the schema published on the service
> site into the parsing logic but I don't think that's necessary
> thing to do (I personally wouldn't do it in my code).
>
> 3. Make changing the schema a painless process for publishers and
>consumers.
>
> I think, the only way to do this is to send both content types
> simultaneously
> for some time, each message being marked with its scheme ID. It would be
> good if consumer always specified what scheme ID it wants to consume.
> If there is a higher scheme ID available in the message, a warning could
> be printed
> maybe even to syslog even so that consumers get the information. At the
> same time it should
> be communicated on the service site or by other means available. I don't
> think it is possible
> to make it any better than this.
>
> I fail to see what's the point of packaging the schemas.
> If the message content is in json, then after receiving the message,
> I would like to be able to just call json.loads(msg) and work with the
> resulting structure
> as I am used to.
>
> Actually, what I would do in python is that I would make it a munch and
> then work
> with it. Needing to install some additional package and instantiate some
> high-level
> objects just seems clumsy to me in comparison.
>
> In other programming languages, this procedure would be pretty much the
> same,
> I believe as they all probably provide some json implementation.
>
> You mentioned:
>
> > In the current proposal, consumers don't interact with the JSON at all,
> but with a higher-level Python API that gives publishers flexibility
> when altering their on-the-wire format.
>
> Yes, but with the current proposal if I change the on-the-wire API, I need
> to make a new version of the schema, package it and somehow get it to
> consumers and make them use the correct version that correctly parses
> the new on-the-wire format and translates it correctly to what the
> consumers
> are used to consume?

Re: fedora messaging

[Michal Novotny]

ably just produce the content twice on a scheme change at
least for some time. "Deprecated by " flag on an incoming message
would be nice then. Of course, the producer would need to register the two
schemas and mark one of them as deprecated. The framework would then
send two messages simultaneously for him. This might be even easier
solution to the problem. The exact publisher (producer) interface would
need to be thought through.

> The big problem is that right now the majority of messages are not
formatted in a way that makes sense and really need to be changed to be
simple, flat structures that contain the information services need and
nothing they don't. I'd like to get those fixed in a way that doesn't
require massive coordinated changes in apps.

In Copr, for example, we take this as an opportunity to change our
format. If the messaging framework will support format deprecation,
we might go that way as well to avoid sudden change. But we don't
currently have many (or maybe any) consumers so I am not sure it is
necessary for us.

I am not familiar with protocol buffers but to me that thing
seems rather useful, if you want to send the content in a compact
binary form to save as much space as possible. If we will send content,
which can be interpreted as json already, then to make some
higher-level classes and objects on that seems already unnecessary.

I think we could really just take that already existing generic framework
you were talking about (RabbitMQ?) and just make sure we can
check the content against message schemas on producer side (which is
great for catching little bugs) and that we know how a message format can
get deprecated (e.g. by adding "deprecated_by: " field into each
message
by the messaging framework, which should somehow log warnings on
consumer side), also the framework could automatically
transform the messages into some language-native structures:
in python, the munches would probably be the most sexy ones.

The whole "let's package schemas" thing seems like something
we would typically do (because we are packagers) but not as something
that would solve the actual problems you have mentioned. Rather it
makes them more difficult to deal with if I am correct.

I think what you are doing is good but I think most people will
welcome less dependencies and simpler language-native structures.
So if we could make the framework go more into that direction,
that would be great.

clime

On Tue, Aug 14, 2018 at 10:55 AM Jeremy Cline  wrote:

> On 08/13/2018 10:20 PM, Michal Novotny wrote:
> > So I got to know on the flock that fedmsg is going to be replaced?
> >
> > Anyway, it seems that there is an idea to create schemas for the messages
> > and distribute them in packages? And those python packages need to be
> > present on producer as well as consumer?
> >> JSON schemas
> >
> >> Message bodies are JSON objects, that adhere to a schema. Message
> schemas
> > live in their own Python package, so they can be installed on the
> producer
> > and on the consumer.
> >
> > Could we instead just send the message schemas together with the message
> > content always?
>
> I considered this early on, but it seemed to me it didn't solve all the
> problems I wanted solved. Those problems are:
>
> 1. Make catching accidental schema changes as a publisher easy.
> 2. Make catching mis-behaving publishers on the consuming side easy.
> 3. Make changing the schema a painless process for publishers and
>consumers.
>
> Doing this would solve #1, but #2 and #3 are still a problem. As a
> consumer, I can validate the JSON in a message matches the JSON schema
> in the same message, but what does that get me? It doesn't seem any
> different (on the consumer side) than just parsing the JSON outright and
> trying to access whatever deserialized object I get.
>
> In the current proposal, consumers don't interact with the JSON at all,
> but with a higher-level Python API that gives publishers flexibility
> when altering their on-the-wire format.
>
> >
> > I would like to be able to parse any message I receive without some
> > additional packages installed. If I am about to start listening to a new
> > message type, I don't want to spend time to be looking up what i should
> > install to make it work. It should just work. Requiring to have some
> > packages with schemas installed on consumer and having to maintain them
> by
> > the producer does not seem that great idea. Mainly because one of the
> > raising requirements for fedmsg was that it should be made a generic
> > messaging framework easily usable outside of Fedora Infrastructure. We
> > should make it easy for anyone outside to be able to listen and
> understand
> > our messages so that they can react to them

Re: Introduction

[Michal Novotny]

On Mon, Aug 13, 2018 at 4:52 PM Michal Konečný  wrote:

> Hi everyone,
>
> I'm new in Fedora Infrastructure and will take care of Anitya and
> the-new-hotness apps.
>

Cool and welcome!

Could you, please, take a look at updating release-monitoring.org with
a newer version of Anitya. That service is still stuck on 0.11 from
Released February 08, 2017.

clime


> I will try to do my best to make these applications great and shiny.
>
> My IRC nick: mkonecny
> My Github nick: Zlopez
>
> Regards,
> Michal
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/JIRDMARF7QLVYMQRRGPDH3MCTT25DGNY/
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/IMID46LBAMAVXFMTR6DUMUQRMJNFULIT/

fedora messaging

[Michal Novotny]

So I got to know on the flock that fedmsg is going to be replaced?

Anyway, it seems that there is an idea to create schemas for the messages
and distribute them in packages? And those python packages need to be
present on producer as well as consumer?
> JSON schemas

> Message bodies are JSON objects, that adhere to a schema. Message schemas
live in their own Python package, so they can be installed on the producer
and on the consumer.

Could we instead just send the message schemas together with the message
content always?

I would like to be able to parse any message I receive without some
additional packages installed. If I am about to start listening to a new
message type, I don't want to spend time to be looking up what i should
install to make it work. It should just work. Requiring to have some
packages with schemas installed on consumer and having to maintain them by
the producer does not seem that great idea. Mainly because one of the
raising requirements for fedmsg was that it should be made a generic
messaging framework easily usable outside of Fedora Infrastructure. We
should make it easy for anyone outside to be able to listen and understand
our messages so that they can react to them. Needing to have some python
packages installed (how are they going to be distributed PyPI + fedora ?)
seems to be just an unnecessary hassle. So can we send a schema with each
message as documentation and validation of the message itself?

a) it will make our life easier

b) it will allow people outside of Fedora (that e.g. also don't tend to use
python) to consume our messages easily

c) what if I am doing a ruby app, not python app, do I need then provide
ruby schema as well as python schema? What if a consumer is a ruby app? We
should only need to write a consumer and producer parts in different
languages. The message schemes should not be bound to a particular
language, otherwise we are just adding us more work when somebody wants to
use the messaging system in another language than python.

clime
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/Y3R7TA33VRZHBNY7OK5MT7KP4QJDAR4H/

libravatar in Fedora OpenShift

[Michal Novotny]

Hello,

I would like to ask if anyone is willing to sponsor running libravatar (
https://git.linux-kernel.at/oliver/ivatar) in Fedora OpenShift per
https://docs.pagure.org/infra-docs/sysadmin-guide/sops/requestforresources.html.
I think we could use the automatic deployment options that OpenShift offers
(Git update -> OpenShift pod update) to our advantage. OpenShift is also
the platform where the current development instance runs
http://ivatar-ivatar.1d35.starter-us-east-1.openshiftapps.com/.

Thank you
clime
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/6FAIFD3QO6ASSRGRW5RM3KOVDVDMY3X4/

Re: is copr-be.cloud.fedoraproject.org DOWN?

[Michal Novotny]

I've cleaned up stale builder records and restarted copr-backend-service
because one of the subservices (copr-backend-log) was down due to failed
connection to local redis server.

clime

On Sun, Jun 24, 2018 at 11:29 PM Satish Patel  wrote:

> Thank you for your service!
>
> Sent from my iPhone
>
> > On Jun 24, 2018, at 1:06 PM, Kevin Fenzi  wrote:
> >
> >> On 06/24/2018 06:42 AM, Stephen John Smoogen wrote:
> >> It looks like the server was rebooted at the time of your email.
> >
> > That was me. I got home from some travels and noticed it was down and
> > rebooted it. I am not sure why it was unresponsive, sadly the logs were
> > corrupted.
> >
> > kevin
> > --
> >>
> >>> On 24 June 2018 at 06:21, Stephen John Smoogen 
> wrote:
> >>> The problem seems to have resolved itself as the server seems to
> >>> respond. There were no outages reported on the parts of the Fedora
> >>> cloud that we provide to COPR to run so I don't know
> >>>
>  On 24 June 2018 at 01:42, Satish Patel  wrote:
>  I am building some packages and failed on
> 
> https://copr-be.cloud.fedoraproject.org/results/thm/lxc2.0/epel-7-x86_64/
> 
>  is copr-be.cloud.fedoraproject.org down? if yes then do you know any
> ETA?
> 
>  ~S
>  ___
>  infrastructure mailing list -- infrastructure@lists.fedoraproject.org
>  To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/D27QQTSUTSY2EEVTOHM3EPLN6ACWRF6Y/
> >>>
> >>>
> >>>
> >>> --
> >>> Stephen J Smoogen.
> >>
> >>
> >>
> >
> >
> > ___
> > infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> > To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/IXQGPQXM3OVQQQLKIJAMCM2MAFJFHWNY/
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/2F4V6IEQQKTDMIYENRK2QFJMB3REI4CZ/
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/7XWPGKXIAPL67OAHUODOAXOQXAAL3BOU/

Re: Fedora and PDC

[Michal Novotny]

On Fri, Jun 8, 2018 at 8:58 AM, Lubomír Sedlář 
wrote:

> Pierre-Yves Chibon píše v Čt 07. 06. 2018 v 18:20 +0200:
> > Good Morning Everyone,
> >
> > So there has been a number of person who expressed in this topic.
> > The list I have so far is:
> > - Clime
> > - bowlofeggs
> > - cverna
> > - nirik
> > - lsedlar
> > - abompard
> > - cqi
> > - Ken Dreyer
> > - ralphbean
> > - mboddu
> >
> > I propose that we meet up next week on Monday at 14:00 UTC.
> >
> >
> > What do you prefer, IRC or video (bluejeans)?
> >
> >
> > What do you all think?
>

Time is ok. I very slightly prefer irc.

clime


> The time works for me, and I have no preference over irc or bluejeans.
>
> Lubomír
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/
> infrastructure@lists.fedoraproject.org/message/
> OP33GEBX2NQPZTREYSPOHPWSJHSEOKA2/
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/537ZVZIRLMPS7MZOFOQZSGFBTR3VWRJP/

Re: Slow Pagure.io

[Michal Novotny]

On Fri, May 4, 2018 at 4:36 PM, Vít Ondruch  wrote:

> If I go to pagure.io/login, I can get logged in, but then I can't access
> the issues again ...
>
>
I had those same exact issues yesterday immediatelly after new pagure
release.
When logged out I could access https://pagure.io/fedora-
infrastructure/issues,
I logged out and could no longer access it.

clime


>
> V.
>
>
> Dne 4.5.2018 v 16:34 Vít Ondruch napsal(a):
> > I removed cookies and the page can be loaded just fine, but it appears I
> > can't login now ...
> >
> > Vít
> >
> >
> > Dne 4.5.2018 v 16:29 Vít Ondruch napsal(a):
> >> Hi,
> >>
> >> Pagure.io is so slow for me to that point that I simple can't open
> >> ticket to report it. IOW, I am trying to load
> >> https://pagure.io/fedora-infrastructure/issues in my browser and it
> does
> >> not work, it just waits for response :/
> >>
> >> ~~~
> >>
> >> $ curl https://pagure.io/fedora-infrastructure/issues -o /dev/null
> >>   % Total% Received % Xferd  Average Speed   TimeTime Time
> >> Current
> >>  Dload  Upload   Total   SpentLeft
> >> Speed
> >> 100  107k  100  107k0 0  30755  0  0:00:03  0:00:03 --:--:--
> >> 30764
> >>
> >>
> >> $ traceroute pagure.io
> >> traceroute to pagure.io (152.19.134.147), 30 hops max, 60 byte packets
> >>  1  _gateway (192.168.0.1)  3.274 ms  4.385 ms  4.320 ms
> >>  2  * * *
> >>  3  ip-86-49-1-161.net.upcbroadband.cz (86.49.1.161)  22.197 ms  22.094
> >> ms  22.066 ms
> >>  4  cz-brn-pop40-ra2-vla2191.net.upc.cz (84.116.220.246)  121.057 ms
> >> 124.204 ms  124.182 ms
> >>  5  cz-brn-pop40-ra1-vla2110.net.upc.cz (84.116.221.41)  126.583 ms
> >> 126.456 ms  126.449 ms
> >>  6  cz-prg01a-ra4-vla2109.net.upc.cz (84.116.221.37)  126.402 ms
> >> 111.096 ms  116.115 ms
> >>  7  de-fra04a-rc1-ae33-0.aorta.net (84.116.135.5)  110.803 ms  137.982
> >> ms  137.875 ms
> >>  8  de-fra04d-rc1-ae26-0.aorta.net (84.116.138.238)  137.842 ms
> 137.777
> >> ms  137.724 ms
> >>  9  * * *
> >> 10  us-nyc01b-rd2-ae9-0.aorta.net (84.116.140.170)  138.336 ms  138.298
> >> ms  115.267 ms
> >> 11  us-nyc01b-ri2-ae3-0.aorta.net (84.116.137.194)  114.465 ms  112.698
> >> ms  110.019 ms
> >> 12  nyc2-brdr-01.inet.qwest.net (63.235.40.165)  136.127 ms  136.117
> ms
> >> 136.086 ms
> >> 13  dca-edge-23.inet.qwest.net (67.14.6.158)  159.519 ms  159.547 ms
> >> 161.527 ms
> >> 14  65.120.78.78 (65.120.78.78)  136.700 ms  135.992 ms  135.886 ms
> >> 15  uncmanning-to-rtp-ip-asr-gw.ncren.net (128.109.19.90)  132.844 ms
> >> 137.504 ms  136.760 ms
> >> 16  core-m-v1214.net.unc.edu (152.19.255.66)  135.283 ms  136.117 ms
> >> 138.533 ms
> >> 17  152.19.255.70 (152.19.255.70)  128.737 ms  128.655 ms  128.518 ms
> >> 18  152.19.255.166 (152.19.255.166)  147.476 ms  132.950 ms  137.336 ms
> >> 19  vmhost1-rsa.fedora.ibiblio.org (152.19.134.147)  126.626 ms !X
> >> 130.794 ms !X  121.215 ms !X
> >> ~~~
> >>
> >>
> >> The strange thing is that the pagure title page or the project overview
> >> can be loaded just fine and neither the tools above shows any suspicious
> >> behavior to me.
> >>
> >>
> >> Vít
> >>
> >>
> >> ___
> >> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> >> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
> > ___
> > infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> > To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Fedora and PDC

[Michal Novotny]

> * I kinda don't like the tree of files in git. It would work, but it
seems poor, like we don't know how to use a database. Along with just
strange to work with.

We could use Git repo of yaml files as the basis but import data upon
each commit for each branch into a locally mounted sqlite DB. Commits
would be rejected if the import could not be completed. Then setup just
a tiny API upon that sqlite DB served by some micro webapp.

Access control, versioning and write access would be handled by Git,
but user-friendly, fast, read-only data access would be handled by
the sqlite + http API pair.

The Git backend can also probably also added later.

I am writing this because I think it's an interesting option from the
technical perspective, not because I would be actually involved with
PDC at the moment. I just wanted to share the idea in case somebody
finds it applicable.

clime

On Mon, Apr 23, 2018 at 7:34 PM, Ken Dreyer  wrote:

> On Sun, Apr 22, 2018 at 2:23 AM, Stanislav Ochotnicky
>  wrote:
> > The difference is that PDC rpm-mappings API endpoint was result of two
> > sources:
> >  * Manual per-rpm mappings (overrides) - this is sort of suitable if you
> >have a product with just a couple source packages so it's manageable
> >this way (i.e Ceph case)
> >  * Results of compose metadata import - this is what Fedora/RHEL uses
> >because several thousands of source packages are not manageable
> >one-by-one by humans manually.
> >
> > You could still make a system that would create "PRs" for the generated
> > files for second case, but then querying the current state will still be
> > a bit tricky. I guess...
>
> Yeah, the fact that we have (at least) two different input and storage
> methods there is a lot of complexity. I'm not sure that's a good
> design in 2018.
>
> Regardless, you're right, I'm envisioning that we'd have a tool to
> generate the data commits and PRs (or just commit + push directly).
> PDC had included its own rudimentary form of version control for
> auditing and message bus integration. Git's experience is much richer.
>
> - Ken
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Fedora and PDC

[Michal Novotny]

* Stream branches, branch ownership, retirement dates?
- SLA/EOL are currently stored in PDC.
- Queried by releng scripts for retirement, fedrepo-req for new
branches,
  etc..
option #1
  git repo full of yaml file similar to the override repo
  compiled into a single JSON blob
  Single place for all retired packages
  This feels like the lowest tech option.
  git gives us change control for free... but people easily get lost in
the
  "UX" of navigating a gigantic git repo full of plaintext files.

I am all for this option because it makes everything public and it is
consistent
with the /tests/ and modules/ namespace approach that has been more recently
introduced. I think that option is actually even attractive.

Just noting...I am not a core developer in this subject but this comes to
mind
as a good way to implement the "branch meta-data storage app".

clime

On Fri, Apr 20, 2018 at 7:34 PM, Pierre-Yves Chibon 
wrote:

> Good Morning Everyone,
>
> We have been informed thst week at the upstream devs working on the
> product-definition-center (PDC) are moving away from the project and are
> going
> to leave it without a maintainer. Since we adopted PDC for a variety of
> data
> flows, this puts us in an awkward position. :(
>
> Ralph and I met up on Tuesday to brainstorm the list of things we actively
> use
> PDC for today and to come up with a contingency plan for how to handle
> them. One
> overarching option is for us (fedora-infra) to take ownership of the PDC
> codebase as a whole. We didn't fully explore this option, figuring that the
> codebase is large and contains lots of tables, endpoints, and codepaths
> that we
> didn't use nor which we plan to use.
>
> Instead, below we've got the four things we use PDC for and some options
> for
> what to do with each.
>
> With the exception of /modules/, one common pattern that we like is to
> investigate splitting out the "django apps" that make up PDC into their own
> projects.  We're calling these "pdc-lite", for fun. See more below.
>
> * Modules
> The data in the /modules/ PDC endpoint is *also* in the MBS db.
> Ralph's
> team is going to just use that and stop using pdc anything for modules.
> We're going to need to patch pungi, mbs for local builds, and a few
> other
> places.  This should be a relatively low-pain transition.
>
> * Stream branches, branch ownership, retirement dates?
> - SLA/EOL are currently stored in PDC.
> - Queried by releng scripts for retirement, fedrepo-req for new
> branches,
>   etc..
> option #1
>   git repo full of yaml file similar to the override repo
>   compiled into a single JSON blob
>   Single place for all retired packages
>   This feels like the lowest tech option.
>   git gives us change control for free... but people easily get lost
> in the
>   "UX" of navigating a gigantic git repo full of plaintext files.
> option #2
>   pagure's DB/API
>   pagure knows nothing about branches currently, so that would be
> bigger
>   lift
> option #3
>   PDC internally is composed of ~20 "django apps"
>   https://github.com/product-definition-center/product-
> definition-center/tree/master/pdc/apps
>   We could pick the 2 or 3 that comprise the branches feature, copy
> them
>   out, and turn them into their own service: the "branch definition
> center":
>   BDC.
>   That would be the "pdc-lite" approach mentionned above, ie: PDC with
> only
>   the "app" of interest
>
> * release/life-circle tracking?
> option #1:
>   PDC lite with just that app of interest
> option #2:
>   JSON/yaml file on the proxies
> option #3:
>   pkgdb-lite
> option #4:
>   ???
>   compose tracking?
> impacted: fedfind
> option #1:
>   PDC-lite with just that app of interest
> option #2:
>   Drop this entirely?
>   Adam probably really wants to keep the record of composes.
> option #3:
>   ???
>
> The "pdc-lite" options are attractive, across the board.  One thing we get
> from
> this is greater clarity when discussing things formerly in PDC.  If
> something is
> in the branch-definition-center, the compose-definition-center, or the
> release-definition-center.. you know what you're talking about.  Today,
> when
> talking about whether or not something should be or is in "PDC", it is
> easy to
> get confused.
>
> I propose we start the discussion on the list and plan for a meeting
> sometime
> late next week to discuss it further with the interested parties (please
> signal
> yourself)
>
>
> What do you think?
>
> Pierre and Ralph
>
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
>
___
infrastructure mailing list -- 

Re: Moving meeting time?

[Michal Novotny]

On Thu, Apr 19, 2018 at 2:29 PM, Michal Novotny <cl...@redhat.com> wrote:

> On Wed, Apr 18, 2018 at 11:31 PM, Kevin Fenzi <ke...@scrye.com> wrote:
>
>> Greetings.
>>
>> It was noted recently that our current meeting time (thursdays at 18UTC)
>> is a bit late/poorly timed for several of our European colleagues.
>>
>> Additionally, we sometimes have the go/no-go meeting at the same time
>> which can be inconvenient.
>>
>> What would everyone think of moving the meeting to 16UTC?
>> Or is there a better time for anyone?
>>
>
> Personally, I couldn't really attend at 16 UTC on Thursdays because that's
> the time I am travelling from work to home (I could attend but not really
> properly
> - only from cell-phone in a public transport :(). But that's just me (and
> I wasn't
> really pinpoint with the meetings lately but wanted to improve it).
>

I am located at UTC+1/UTC+2 (based on daylight savings).


>
>
>>
>> This weeks meeting we will keep the same, but we can discuss and see if
>> we want to move it starting next week.
>>
>> Thanks,
>>
>> kevin
>>
>>
>> ___
>> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
>> To unsubscribe send an email to infrastructure-le...@lists.fed
>> oraproject.org
>>
>>
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Moving meeting time?

[Michal Novotny]

On Wed, Apr 18, 2018 at 11:31 PM, Kevin Fenzi  wrote:

> Greetings.
>
> It was noted recently that our current meeting time (thursdays at 18UTC)
> is a bit late/poorly timed for several of our European colleagues.
>
> Additionally, we sometimes have the go/no-go meeting at the same time
> which can be inconvenient.
>
> What would everyone think of moving the meeting to 16UTC?
> Or is there a better time for anyone?
>

Personally, I couldn't really attend at 16 UTC on Thursdays because that's
the time I am travelling from work to home (I could attend but not really
properly
- only from cell-phone in a public transport :(). But that's just me (and I
wasn't
really pinpoint with the meetings lately but wanted to improve it).


>
> This weeks meeting we will keep the same, but we can discuss and see if
> we want to move it starting next week.
>
> Thanks,
>
> kevin
>
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Freeze Break Request: re-enable fedmsg hook on src

[Michal Novotny]

On Thu, Apr 19, 2018 at 2:07 AM, Kevin Fenzi  wrote:

> Odd. Somehow my patch was not my patch. ;(
>
> Here is the real one...
>
> > diff --git a/roles/git/hooks/files/post-receive-chained
> b/roles/git/hooks/files/post-receive-chained
> > index 5c74da4..99b5a2a 100755
> > --- a/roles/git/hooks/files/post-receive-chained
> > +++ b/roles/git/hooks/files/post-receive-chained
> > @@ -8,7 +8,7 @@ pee \
> >  /usr/share/git-core/post-receive-alternativearch \
> >  /usr/lib/python2.7/site-packages/pagure/hooks/files/default_hook.py
> \
> >  /usr/lib/python2.7/site-packages/pagure/hooks/files/pagure_hook.py
> \
> > -#/usr/lib/python2.7/site-packages/pagure/hooks/files/fedmsg_hook.py
> \
> > +/usr/lib/python2.7/site-packages/pagure/hooks/files/fedmsg_hook.py
> \
> >  "/usr/bin/grok-manifest -m /srv/git/grokmirror/manifest.js.gz -t
> /srv/git/repositories/ -n `pwd`"
> >
> >  # We used to send emails directly from the git hook here, but now we
> send to
> > diff --git a/roles/git/hooks/files/post-receive-chained-forks
> b/roles/git/hooks/files/post-receive-chained-forks
> > index 67565e6..6f0fd88 100755
> > --- a/roles/git/hooks/files/post-receive-chained-forks
> > +++ b/roles/git/hooks/files/post-receive-chained-forks
> > @@ -6,7 +6,6 @@
> >  pee \
> >  /usr/lib/python2.7/site-packages/pagure/hooks/files/default_hook.py
> \
> >  /usr/lib/python2.7/site-packages/pagure/hooks/files/pagure_hook.py
> \
> > -#   /usr/lib/python2.7/site-packages/pagure/hooks/files/fedmsg_hook.py
> \
>

This only removes the commented out line. We should actually fully revert
https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=dc86b22f9054bdcefd51e46db90433c03d54410c,

I believe.


> >  "/usr/bin/grok-manifest -m /srv/git/grokmirror/manifest.js.gz -t
> /srv/git/repositories/ -n `pwd`"
> >
> >  # We used to send emails directly from the git hook here, but now we
> send to
>
> kevin
>
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Freeze Break Request: re-enable fedmsg hook on src

[Michal Novotny]

+1

On Wed, Apr 18, 2018 at 7:21 PM, Kevin Fenzi  wrote:

> Greetings.
>
> Just before freeze in ansible commit
> dc86b22f9054bdcefd51e46db90433c03d54410c pingou disabled the fedmsg hook
> because there was a permissions problem reading the fedmsg key.
>
> In ansible commit 9cbf120b54a79ecb07931f3a3a1b059525d4d766 patrick fixed
> this perm issue via a facl.
>
> So, I would like to re-enable the hook on normal projects and remove it
> from forks. (I think we decided forks should only get the pagure hook,
> not the main fedmsg one).
>
> So, I'd like to apply:
>
> > diff --git a/roles/git/hooks/files/post-receive-chained
> b/roles/git/hooks/files/post-receive-chained
> > index 99b5a2a..5c74da4 100755
> > --- a/roles/git/hooks/files/post-receive-chained
> > +++ b/roles/git/hooks/files/post-receive-chained
> > @@ -8,7 +8,7 @@ pee \
> >  /usr/share/git-core/post-receive-alternativearch \
> >  /usr/lib/python2.7/site-packages/pagure/hooks/files/default_hook.py
> \
> >  /usr/lib/python2.7/site-packages/pagure/hooks/files/pagure_hook.py
> \
> > -/usr/lib/python2.7/site-packages/pagure/hooks/files/fedmsg_hook.py
> \
> > +#/usr/lib/python2.7/site-packages/pagure/hooks/files/fedmsg_hook.py
> \
> >  "/usr/bin/grok-manifest -m /srv/git/grokmirror/manifest.js.gz -t
> /srv/git/repositories/ -n `pwd`"
> >
> >  # We used to send emails directly from the git hook here, but now we
> send to
> > diff --git a/roles/git/hooks/files/post-receive-chained-forks
> b/roles/git/hooks/files/post-receive-chained-forks
> > index 5e0056d..67565e6 100755
> > --- a/roles/git/hooks/files/post-receive-chained-forks
> > +++ b/roles/git/hooks/files/post-receive-chained-forks
> > @@ -6,7 +6,7 @@
> >  pee \
> >  /usr/lib/python2.7/site-packages/pagure/hooks/files/default_hook.py
> \
> >  /usr/lib/python2.7/site-packages/pagure/hooks/files/pagure_hook.py
> \
> > -/usr/lib/python2.7/site-packages/pagure/hooks/files/fedmsg_hook.py
> \
> > +#   /usr/lib/python2.7/site-packages/pagure/hooks/files/fedmsg_hook.py
> \
> >  "/usr/bin/grok-manifest -m /srv/git/grokmirror/manifest.js.gz -t
> /srv/git/repositories/ -n `pwd`"
> >
> >  # We used to send emails directly from the git hook here, but now we
> send to
>
> Run the ansible playbook against pkgs,
> And then run the script to make sure all projects are set right.
>
> +1s?
>
> kevin
>
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Zchunk update

[Michal Novotny]

On Tue, Apr 17, 2018 at 4:20 PM, Jonathan Dieter <jdie...@gmail.com> wrote:

> On Tue, 2018-04-17 at 09:08 +0200, Michal Novotny wrote:
> > Hello Jonathan,
> >
> > On Mon, Apr 16, 2018 at 2:47 PM, Jonathan Dieter <jdie...@gmail.com>
> > wrote:
> > > It's been a number of weeks since my last update, so I thought I'd
> > > let
> > > everyone know where things are at.
> > >
> > > I've spent most of these last few weeks reworking zchunk's API to
> > > make
> > > it easier to use and more in line with what other compression tools
> > > use, and I'm mostly happy with it now.  Writing a simple zchunk
> > > file
> > > can be done in a few lines of code, while reading one is also
> > > simple.
> > > I've also added zchunk support to createrepo_c (see
> > > https://github.com/jdieter/createrepo_c), but I haven't yet created
> > > a
> > > pull request because I'm not sure if my current implementation is
> > > the
> > > best method.  My current effort only zchunks primary.xml,
> > > filelists.xml
> > > and other.xml and doesn't change the sort order.
> >
> > Once it is in createrepo_c, we could try employing it in Fedora COPR.
>
> Ok, done.  This copr currently has zchunk and createrepo_c in it.  I
> did have to disable the python tests for createrepo_c which means I
> probably wouldn't use the python bindings with this release.
>
> https://copr.fedorainfracloud.org/coprs/jdieter/zchunk/
>
> To enable zchunk creation, run createrepo_c --zck.  I've created
> dictionaries that are appropriate for Fedora's metadata at
> https://www.jdieter.net/downloads/zchunk-dicts, and they can be used
> with --zck-primary-dict, --zck-filelists-dict and --zck-other-dict.
>
> To make zchunk downloads efficient, the same dictionary must be used
> each time metadata is generated.  Dictionaries aren't mandatory, but
> they greatly reduce the size of the compressed metadata.
>

Alright, I will deploy it on staging. But we will need to get it into
Fedora's
DistGit first to be able to use it on COPR production instance afterwards...
Anyway, looking forward to start experimenting with it.

Thank you!


>
> Jonathan
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Zchunk update

[Michal Novotny]

Hello Jonathan,

On Mon, Apr 16, 2018 at 2:47 PM, Jonathan Dieter  wrote:

> It's been a number of weeks since my last update, so I thought I'd let
> everyone know where things are at.
>
> I've spent most of these last few weeks reworking zchunk's API to make
> it easier to use and more in line with what other compression tools
> use, and I'm mostly happy with it now.  Writing a simple zchunk file
> can be done in a few lines of code, while reading one is also simple.
>

> I've also added zchunk support to createrepo_c (see
> https://github.com/jdieter/createrepo_c), but I haven't yet created a
> pull request because I'm not sure if my current implementation is the
> best method.  My current effort only zchunks primary.xml, filelists.xml
> and other.xml and doesn't change the sort order.
>

Once it is in createrepo_c, we could try employing it in Fedora COPR.


>
> The one area of zchunk that still needs some API work is the download
> and chunk merge API, and I'm planning to clean that up as I add zchunk
> support to librepo.
>
> Some things I'd still like to add to zchunk:
>  * A python API
>  * GPG signatures in addition to (possibly replacing) overall data
>checksum
>  * An expiry field? (I'm obviously thinking about signed repodata here)
>  * Tests
>  * More tests
>  * Other arch testing (it's currently only tested on x86_64)
>
> I'd welcome any feedback or flames.
>
> Jonathan
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Libravatar shutting down on 2018-09-01

[Michal Novotny]

On Tue, Apr 10, 2018 at 10:47 AM, Till Maas  wrote:
> Hi
>
> On Tue, Apr 10, 2018 at 10:27:59AM +0200, Miroslav Suchý wrote:
>> Dne 5.4.2018 v 04:16 Neal Gompa napsal(a):
>> > The main problem, of course, is finding someone who wants to run it...
>>
>> Even if you find someone (not as big problem), that guy basically cannot do 
>> anything else. So basically strike out
>> something from our TODO list as CANNOT FIX.
>>
>> @Justin thank you for the notice, we are using it in Copr, I will migrate it 
>> to gravatar.
>
> the announcement was made about a week ago and they will shut down in
> about 6 months. There are also other people considering to continue this
> service. Therefore by migrating away from it prematurely you are also
> striking something else from your TODO even if someone will be
> continuing the service. IMHO it is good to be aware but there is also
> just enough time to let the dust settle and see where libravatar will
> go.

Right, I will try to set it up in the cloud and we will see where it can go.

clime

>
> Kind regards
> Till
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Fedora Infrastructure Authentication Roadmap

[Michal Novotny]

Currently, in COPR we talk to id.fedoraproject.org to authenticate users.
Will there be some change in the name or API for this service?

Will it be possible to do user registration and group creation remotely
through CAIAPI?

Thank you
clime


On Mon, Apr 2, 2018 at 7:38 PM, Kevin Fenzi  wrote:

> Greetings.
>
> Sorry it took so long to write this up and send it out, but here's our
> proposed plan for authentication moving forward.
>
> Please do feel free to comment or suggest changes/improvements here. Any
> mistakes are mine alone. :)
>
> Fedora Project Auth roadmap
>
> Background/History
>
>   The Fedora project created its own authentication/user/group
> management system at nearly the beginning of its existance. FAS (Fedora
> Account System) (version 1) and then a rewrite (FAS2). At each of these
> points other solutions were investigated and found unacceptable for
> various reasons. Over the last few years, several additional
> applications have been added next to FAS2 to provide additional
> functionality: ipisilon has been added as a identity provider, and
> FreeIPA has been added for kerberos authentication. FAS2 is still the
> authoritative source of authentication data. FAS2 is currently deployed
> on RHEL6 servers and won't run on RHEL7.
>
> Also during the last few years, a new FAS re-write has been slowly in
> the works. FAS3 is written in a modern framework and has a number of
> functionality and interface improvements over FAS2. Additionally it can
> run on RHEL7.
>
> Goals and Critera
>
>   Maintaining authentication applications is difficult and time
> consuming work, and it has always been a goal to try and move to more
> industry standard applications as much as possible given our goals and
> critera. The last time we looked, Some of those goals/critera include:
>
>   * User self service registration
>   * User self service password reset
>   * FPCA acceptance requirement
>   * Basset integration (may not be needed anymore)
>   * Allow Self Service groups with their own sponsors/admins
>   * Allow group requirements (other group first, etc)
>
> Plan:
>
>   On discussion with FreeIPA developers and looking at how things are
> setup now, we came up with a plan to get what we need, but reduce the
> footprint and maintance we need to do. Many of the features we were
> hoping to use in FAS3 have now been implemented upstream in
> FreeIPA (2fa, fasClient syncing better, etc).
>
> Basically we will:
>
> * A new small wrapper type project is written (Community Account
> Information API) or CAIAPI.
>   This small app provides the Critera listed above, talking at first to
> FAS2 on the backend then, later switching to talking to FreeIPA on the
> backend and providing a json API to consumers.
> * Switch anything we have using the direct FAS api to use CAIAPI instead.
> * Move to FreeIPA being the canonical source for authentication data.
>   This should just be a switch to CAIAPI, and no consumers should even
> notice.
> * FreeIPA still provides kerberos auth.
>   Note that kerberos will remain limited to use at ipsilon and koji.
> * Ipsilon provides identity auth for applications, preferably with OIDC
> (still provides others)
> * A new small website that uses the CAIAPI json to provide end user
> access / management. This thing would be in flask and needs a name still.
>
> Since https://fedoraproject.org/wiki/Infrastructure/fas_freeipa FreeIPA
> has matured and our understanding of the work required to make CAIAPI
> and a small web consumer has clarified.
>
> Pros:
>
>   * IPA handles all the storing of credentials, replication and such and
> we just use it.
>   * Our maint goes from needing to maintain FAS2 or FAS3 to just CAIAPI
> (a much smaller api) and a
> very small web application.
>   * Easier to audit 2 small apps.
>   * We can try and share the CAIAPI with other open source communities
> (Gnome? CentOS? others?)
> Open Source Communities already using FreeIPA would be easy to add
> this to.
>   * We can stop using fasClient in favor of ipa-client setup (no more
> heavy syncing)
>   * The heavy security aspects will be handled by upstreams we don't
> need to fully maintain
> (FreeIPA, sssd, ipsilon, etc).
>
> Cons:
>   * We still need to write the CAIAPI/webapp, although Patrick may have
> CAIAPI already somewhat implemented.
>   * It feels very sad to have spent so long on FAS3 and never deploy it,
> but sometimes
> thats just the way things go. ;(
>
>
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: FBR: Update pungi and install python3-modulemd and pdc-client on bodhi-backend

[Michal Novotny]

+1

On Wed, Mar 7, 2018 at 1:31 AM, Kevin Fenzi  wrote:

> +1 here.
>
> kevin
>
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Planned Outage: COPR BACKEND upgrade - 2018-01-16 09:00 UTC

[Michal Novotny]

 Planned Outage: COPR BACKEND upgrade - 2018-01-16 09:00 UTC

There will be an outage starting at 2018-01-16 09:00 UTC, which will last
approximately 0.5 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d
'2018-01-16 09:00 UTC'

Reason for outage:

Upgrade of copr-backend machine to f27

Affected Services:

copr-backend - https://copr-be.cloud.fedoraproject.org/


Ticket Link:

https://pagure.io/fedora-infrastructure/issue/6635

Contact Information:

Please join #fedora-admin or #fedora-buildsys in irc.freenode.net or add
comments to the ticket for this outage above.
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Need your collaboration to release fedpkg

[Michal Novotny]

Hello,

On Fri, Oct 27, 2017 at 5:27 AM, Chenxiong Qi  wrote:

> Hi all,
>
> New release of fedpkg includes two requested changes, one is to send
> namespace along with repo name to lookaside while new-sources[1] and
> another one is to clone from https:// anonymous URL instead of git://
> URL[2][3]. Both of these changes require update to configuration in
> infra. I think we need collaborate together in order to release fedpkg
> successfully.
>
> Current status is, as we talked in fedora-admin IRC channel, clime is
> working on patching dist-git, that will be reviewed, and then be
> deployed and update configuration in infra ansible. Meanwhile, it is
> still in Fedora 27 final freeze now (4 days remains though), therefor
> it is not recommended to modify configuration to allow build from
> git+https:// or https://.
>
> According to our talk in IRC, it looks all these should be done
> eventually after the final freeze. So, how about let us make a plan
> for the release? My proposal is
>
> - Revert to work with current lookaside upload.cgi script and clone
> from git:// so that packagers can still build package from an
> anonymous clone.
> - Finish review and deploy patched dist-git
> - Update necessary configuration in infra
> - Enable what reverted in the first step.
>
> As not all packagers will upgrade fedpkg at once, the configuration
> should be compatible with older version of fedpkg, that is how it
> works currently.
>
> BTW, I'm not much clear about which URL prefix is allow to build
> package in your plan, https:// or git+http://, or both? FYI,
> git+https:// is allowed previously, e.g.
> https://koji.fedoraproject.org/koji/taskinfo?taskID=19122540.
>
> @clime, we can test patched dist-git by using fedpkg-1.30-1.
>


We will probably need someone else here as well as I do not have permission
to run pkgs playbook, I think. Otherwise the new updated dist-git package
(1.4-3)
should already be in epel7-infra-stg repositories.


>
> That's it. Any thought? Please correct me if anything is not correct or
> missing.
>
> Relative links:
>
> [1] https://pagure.io/fedpkg/issue/130
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1188634
> [3] https://pagure.io/fedpkg/pull-request/120
> [4] Support namespaced module name in lookaside upload script -
> https://pagure.io/fedora-infrastructure/issue/6472
> [5] Please enable allow to build from git+https:// -
> https://pagure.io/fedora-infrastructure/issue/6468
>
> Thank you all!
>
> --
> Regards,
> Chenxiong Qi
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Restructuring hooks in dist-git

[Michal Novotny]

Looking further, this is probably unrelated now as the setup script from
the upstream dist-git is no longer used. Sorry for the fuss.

On Fri, Sep 15, 2017 at 8:13 AM, Michal Novotny <cl...@redhat.com> wrote:

> Hello,
>
> On Thu, Sep 14, 2017 at 11:24 AM, Pierre-Yves Chibon <pin...@pingoured.fr>
> wrote:
>
>> Good Morning Everyone,
>>
>> After some more testing and debugging in stg, these are the changes I
>> ended up
>> doing/running in stg.
>>
>>  [PATCH 1/3] Add pagure's hook to the post-receive hook and point to
>>  [PATCH 2/3] Fix the check-perms.py script/cron
>>  [PATCH 3/3] Fix the git-check-perms cron jobs
>>
>
> Sorry, where can I find those patches? Anyway some of it, could be probably
> incorporated into https://github.com/release-engineering/dist-git/blob/
> master/scripts/dist-git/setup_git_package.
>
> E.g. grok mirror hook support that Kevin mentioned is already there.
>
> I can adjust the setup script after the changes are in Ansible if needed,
> however.
>
>
>>
>> Worth pushing forward?
>>
>>
>> Thanks,
>> Pierre
>> ___
>> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
>> To unsubscribe send an email to infrastructure-le...@lists.fed
>> oraproject.org
>>
>
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Restructuring hooks in dist-git

[Michal Novotny]

Hello,

On Thu, Sep 14, 2017 at 11:24 AM, Pierre-Yves Chibon 
wrote:

> Good Morning Everyone,
>
> After some more testing and debugging in stg, these are the changes I
> ended up
> doing/running in stg.
>
>  [PATCH 1/3] Add pagure's hook to the post-receive hook and point to
>  [PATCH 2/3] Fix the check-perms.py script/cron
>  [PATCH 3/3] Fix the git-check-perms cron jobs
>

Sorry, where can I find those patches? Anyway some of it, could be probably
incorporated into
https://github.com/release-engineering/dist-git/blob/master/scripts/dist-git/setup_git_package
.

E.g. grok mirror hook support that Kevin mentioned is already there.

I can adjust the setup script after the changes are in Ansible if needed,
however.


>
> Worth pushing forward?
>
>
> Thanks,
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Congrats to Adam Miller

[Michal Novotny]

Congratulations, Adam!

On Sat, Sep 2, 2017 at 6:27 AM, InvalidPath  wrote:

> I might not know you, but grats Adam!
>
> On Fri, Sep 1, 2017 at 9:26 PM, Adam Miller  > wrote:
>
>> On Fri, Sep 1, 2017 at 10:28 AM, Kevin Fenzi  wrote:
>> > I'm happy to announce that We have approved Adam into the sysadmin-main
>> > group.
>> >
>> > This is the core group of trusted folks that high level access to most
>> > things. Adam has done great work rolling out and maintaining and working
>> > on the next generation of the Open Shift Build System and other work
>> > with releng.
>> >
>> > This should allow him to more easily roll out and provision new versions
>> > of OSBS.
>> >
>> > Congrats and use your powers for good! :)
>>
>> Thank you so very much, I earnestly consider this a high honor. I
>> originally applied as an infra-apprentice long long ago (jeez I'm old
>> now) when I was a college student and this is something I've hoped to
>> achieve for many years. I will do my best to serve well as a member of
>> the sysadmin-main order. :)
>>
>> Thank you again,
>> -AdamM
>>
>> >
>> > kevin
>> >
>> >
>> > ___
>> > infrastructure mailing list -- infrastructure@lists.fedoraproject.org
>> > To unsubscribe send an email to infrastructure-le...@lists.fed
>> oraproject.org
>> >
>> ___
>> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
>> To unsubscribe send an email to infrastructure-le...@lists.fed
>> oraproject.org
>>
>
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Fedora Infrastructure support for COPR

[Michal Novotny]

On Mon, Jul 31, 2017 at 7:03 PM, Michal Novotny <cl...@redhat.com> wrote:

>
>
> On Mon, Jul 31, 2017 at 4:46 PM, Matthew Miller <mat...@fedoraproject.org>
> wrote:
>
>> On Mon, Jul 31, 2017 at 10:16:16AM +0200, Michal Novotny wrote:
>> > COPR now operates with packages solely from official Fedora
>> repositories.
>>
>> \o/
>>
>> Nice!
>>
>> > I particularly like the idea of running COPR solely in OpenShift or in
>> RHOSP
>> > 10+ with having builders as OpenShift pods but this is not really my
>> > decision.
>>
>> I love this very very much. What would it take from the COPR development
>> side to make this happen?
>>
>>
> We would need to adjust builder spawning and termination. This is done by
> ansible
> playbooks. So they would use 'oc' command to communicate with OpenShift
> cloud
> controller. Everything else should work but there will likely be some
> software bugs.
>

I should probably mention we have an issue open for this:
https://pagure.io/copr/copr/issue/77.


>
>
>>
>> --
>> Matthew Miller
>> <mat...@fedoraproject.org>
>> Fedora Project Leader
>> ___
>> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
>> To unsubscribe send an email to infrastructure-le...@lists.fed
>> oraproject.org
>>
>
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Fedora Infrastructure support for COPR

[Michal Novotny]

On Mon, Jul 31, 2017 at 4:46 PM, Matthew Miller <mat...@fedoraproject.org>
wrote:

> On Mon, Jul 31, 2017 at 10:16:16AM +0200, Michal Novotny wrote:
> > COPR now operates with packages solely from official Fedora repositories.
>
> \o/
>
> Nice!
>
> > I particularly like the idea of running COPR solely in OpenShift or in
> RHOSP
> > 10+ with having builders as OpenShift pods but this is not really my
> > decision.
>
> I love this very very much. What would it take from the COPR development
> side to make this happen?
>
>
We would need to adjust builder spawning and termination. This is done by
ansible
playbooks. So they would use 'oc' command to communicate with OpenShift
cloud
controller. Everything else should work but there will likely be some
software bugs.


>
> --
> Matthew Miller
> <mat...@fedoraproject.org>
> Fedora Project Leader
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Fedora Infrastructure support for COPR

[Michal Novotny]

Hello,

COPR now operates with packages solely from official Fedora repositories.
This was requested in https://pagure.io/fedora-infrastructure/issue/5166 as
a condition to get the Fedora Infra support. I would like to ask for the
support now as this condition is finally satisfied \o/.

Perhaps this could be reflected in:
- the Service Level Expectations that are being prepared
- removing the user message on COPR homepage
- change of the domain back to fedoraproject.org (?)
- moving COPR to a platform where the support is actually possible

I particularly like the idea of running COPR solely in OpenShift or in RHOSP
10+ with having builders as OpenShift pods but this is not really my
decision.

I am happy this is finally going somewhere.

clime
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: FBR: Apply patch to FMN to resume

[Michal Novotny]

+1

On Wed, May 31, 2017 at 8:51 PM, Patrick Uiterwijk 
wrote:

> Hi all,
>
> Can I get +1s to apply the patch for
> https://patch-diff.githubusercontent.com/raw/fedora-infra/fedmsg_meta_
> fedora_infrastructure/pull/430.patch
> on prod, so that FMN can continue running?
>
> Thanks,
> Patrick
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: FBR: patched libgit2 on pagure.io

[Michal Novotny]

+1

On Sat, May 27, 2017 at 8:16 PM, Pierre-Yves Chibon 
wrote:

> On Sat, May 27, 2017 at 11:41:19AM -0600, Kevin Fenzi wrote:
> > Greetings.
> >
> > A while back Patrick made a patch for libgit2 that worked around some of
> > its performance and locking issues. When we upgraded pagure at the
> > beginning of the month we upgraded to the epel version without the patch.
> >
> > I'd like to apply the patch to the libgit2 on pagure.io and hopefully
> > this will fix the performance/lockups we have left.
> >
> > note that Patrick is working on more libgit2 fixes as well as these to
> > try and upstream them, so hopefully we don't have to carry these forever.
> >
> > +1s?
>
> +1 for me, thanks Patrick!
>
>
> Pierre
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: COPR and new chroot naming

[Michal Novotny]

On Tue, Feb 21, 2017 at 5:15 PM, Kevin Fenzi <ke...@scrye.com> wrote:

> On Tue, 21 Feb 2017 11:00:15 +0100
> Michal Novotny <cl...@redhat.com> wrote:
>
> > On Tue, Feb 21, 2017 at 10:28 AM, Vít Ondruch <vondr...@redhat.com>
> > wrote:
> >
> > > I honestly don't understand what is purpose of the f26 vs master.
> > > Why we have empty master currently (speaking of dist-git)? master
> > > should be the same as rawhide, as it is in Fedora.
> > >
> > Yes, I think that makes more sense as well.
> >
> >
> > P.S. Adding devel to the recipient list so that more people can
> > comment.
>
> Well, my thought was this would be a good way to clean out old stale
> projects. ie:
>
> right now we have f26 (rawhide), f25, f24
>
> once we branch f26, projects have f26, f25, f24 and if they like they
> can enable and rebuild for the now existing f27 (rawhide).
>
> When f24 goes eol and is disabled, look at projects that don't have any
> builds anymore and remove them.
>
> repeat each cycle. This means you need to pay attention and rebuild
> your coprs for new branches as they appear, but it also means if you
> don't the old project disappears.
>

That's true but maybe if we make sure the time of the latest build is
communicated
clearly to the user of the copr, it will be enough.


>
> Of course many projects also build for epel, so they would stick around
> for that reason for a long time.
>
> If we move back to having a rawhide/devel/master repo the problem
> becomes "which rawhide" ? if you build something in that branch a year
> ago, what are the chances it will still work?
>
>
Yeah, not very high chances. However, rawhide is still moving so people
probably
do expect the packages there not to have very wide 'it-works' lifespan.

If I consider a use-case of a package developer/maintainer that wants to
prepare
his or her package for next Fedora release, then I think that for those
COPR users
(I met one), rawhide naming is more intuitive and I would like to be good
to them.


> Just my thoughts...
>
>
Thank you, Kevin.


> kevin
>
>
>
> ___
> devel mailing list -- de...@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: COPR and new chroot naming

[Michal Novotny]

On Tue, Feb 21, 2017 at 10:28 AM, Vít Ondruch <vondr...@redhat.com> wrote:

> I honestly don't understand what is purpose of the f26 vs master. Why we
> have empty master currently (speaking of dist-git)? master should be the
> same as rawhide, as it is in Fedora.
>
Yes, I think that makes more sense as well.


P.S. Adding devel to the recipient list so that more people can comment.

> Vít
>
> Dne 21.2.2017 v 10:05 Michal Novotny napsal(a):
>
> Hello folks,
>
> We have quite recently changed naming of rawhide chroot to fXY in COPR and
> I would like to know your opinion about it.
>
> As branching is behind the door, I tried to consider it again and slightly
> changed my mind. The main problem with just fXY is that it is probably not
> very intuitive. "rawhide" tells clearly that rawhide repos are used whereas
> with just fXY, the repos used for the chroot need to be switched at
> branching (from rawhide to the fXY ones).
>
> We were probably trying to be too fancy here thinking that the follow-up
> features (all package rebuilding and chroot forking) will complement it
> well. These features can, however, work with both namings and the "rawhide"
> chroot just plays much better with mock and how it introduces the new
> chroot configs.
>
> We can go either way but to me the "just-call-it-rawhide" seems to be more
> simple now while also providing nicer user experience.
>
> clime
>
>
>
>
>
>
>
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
>
>
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

COPR and new chroot naming

[Michal Novotny]

Hello folks,

We have quite recently changed naming of rawhide chroot to fXY in COPR and
I would like to know your opinion about it.

As branching is behind the door, I tried to consider it again and slightly
changed my mind. The main problem with just fXY is that it is probably not
very intuitive. "rawhide" tells clearly that rawhide repos are used whereas
with just fXY, the repos used for the chroot need to be switched at
branching (from rawhide to the fXY ones).

We were probably trying to be too fancy here thinking that the follow-up
features (all package rebuilding and chroot forking) will complement it
well. These features can, however, work with both namings and the "rawhide"
chroot just plays much better with mock and how it introduces the new
chroot configs.

We can go either way but to me the "just-call-it-rawhide" seems to be more
simple now while also providing nicer user experience.

clime
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: COPR auto-rebuilds on pagure commits

[Michal Novotny]

On Mon, Nov 7, 2016 at 3:47 PM, Pierre-Yves Chibon <pin...@pingoured.fr>
wrote:

> On Mon, Nov 07, 2016 at 02:02:01PM +0100, Michal Novotny wrote:
> >Hey,
> >
> >I'd like to announce that we now support package auto-rebuilding on a
> new
> >commit(s) into a Pagure repository.  Apart from having your package
> repo
> >hosted in Pagure, you just need to enable firing of fedmsg
> notifications
> >for new commits by clicking a single checkbox in 'Hooks'
> section...well,
> >then you also need to save this setting and have auto-rebuilding
> enabled
> >for the copr package but that really is it, I promise :).
>
> Cool :)
>
> Is there any plan to look at doing this for PR as well like we do for the
> jenkins/CI integration?
>

Sounds like a nice idea.


> But awesome news and work :)
> clime++
>
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

COPR auto-rebuilds on pagure commits

[Michal Novotny]

Hey,

I'd like to announce that we now support package auto-rebuilding on a new
commit(s) into a Pagure repository.  Apart from having your package repo
hosted in Pagure, you just need to enable firing of fedmsg notifications
for new commits by clicking a single checkbox in 'Hooks' section...well,
then you also need to save this setting and have auto-rebuilding enabled
for the copr package but that really is it, I promise :).

clime
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: PROPOSAL: employ a variant of upstream dist-git package into FedoraInfra

[Michal Novotny]

Hello, I have finished the first version of the dist-git(-min) package.

If it was possible, I'd like to test it in the staging environment.
Differences from what I have locally are:
- nfs mounts on /srv/cache/lookaside
- fedmsg emitting
- integration with pagure (?)
- /repo/pkgs/upload.cgi under ssl

Attached is a patch to ansible that employs the package. It still a bit a
proof of concept.

Currently the code is hosted on GitHub (https://github.com/clime/dist-git)
but I plan to move to Pagure soon.

Thanks
clime

On Thu, Oct 13, 2016 at 2:35 PM, Pierre-Yves Chibon <pin...@pingoured.fr>
wrote:

> On Thu, Oct 13, 2016 at 02:04:04PM +0200, Michal Novotny wrote:
> >Hey,
> >
> >I'd like to propose employment of an upstream dist-git package for
> >deploying pkgs machines. This is the package I have in mind:
> >https://github.com/release-engineering/dist-git. This package
> contains
> >scripts and selinux policy for dist-git files.
>
> I am not sure we're using this, I believe all our work is in the ansible
> repo,
> afaik there is no dist-git repo/rpm.
>
> >I will collect all the other use-cases and ideally write a suite of
> >regression tests based on that. I know pkgs.fedoraproject.org is
> somehow
> >related to pagure but I need to additionally investigate this.
>
> We're hoping to use pagure as a front-end for the git repos in dist-git at
> one
> point, there are still a few issues to level first though.
>
>
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
From 4894b98e56ef70cd2d23038e4b2826d5f5bdb104 Mon Sep 17 00:00:00 2001
From: clime <cl...@redhat.com>
Date: Mon, 31 Oct 2016 15:25:14 +0100
Subject: [PATCH] employ dist-git-min

---
 roles/distgit/tasks/main.yml | 216 +--
 1 file changed, 25 insertions(+), 191 deletions(-)

diff --git a/roles/distgit/tasks/main.yml b/roles/distgit/tasks/main.yml
index b72f8a7..a264c8a 100644
--- a/roles/distgit/tasks/main.yml
+++ b/roles/distgit/tasks/main.yml
@@ -4,6 +4,10 @@
 # This is a bit complex, so I'm dividing it into sections.
 
 # -- Common --
+
+- name: install the dist-git package
+  shell: "dnf -y install /tmp/tito/noarch/dist-git-*0.13-1.git.1.4fefd7f.fc24.noarch.rpm"
+
 # This is very basic stuff that is needed by multiple of the next sections.
 - name: install the needed packages
   yum: pkg={{item}} state=present
@@ -17,20 +21,6 @@
   tags:
   - distgit
 
-- name: install the httpd config file
-  copy: src=pkgs.fedoraproject.org.conf dest=/etc/httpd/conf.d/pkgs.fedoraproject.org.conf
-  notify:
-  - reload httpd
-  tags:
-  - distgit
-
-- name: install the httpd config directory
-  file: dest=/etc/httpd/conf.d/pkgs.fedoraproject.org state=directory
-  notify:
-  - reload httpd
-  tags:
-  - distgit
-
 - name: install the mod_ssl configuration
   copy: src=ssl.conf dest=/etc/httpd/conf.d/ssl.conf
   notify:
@@ -38,17 +28,6 @@
   tags:
   - distgit
 
-- name: install the keytab
-  copy: src="{{ private }}/files/keytabs/{{env}}/pkgs"
-dest=/etc/httpd.keytab
-owner=apache
-group=apache
-mode=0600
-  notify:
-  - reload httpd
-  tags:
-  - distgit
-
 - name: allow httpd to access the files on NFS
   seboolean: name=httpd_use_nfs state=yes persistent=yes
   tags:
@@ -65,11 +44,6 @@
   - distgit
 
 # -- Dist Git 
-# This is the Git setup itself: group, root directory, scripts,...
-- name: create the distgit root directory (/srv/git)
-  file: dest=/srv/git state=directory mode=0755
-  tags:
-  - distgit
 
 - name: check the selinux context of the distgit root directory
   command: matchpathcon /srv/git
@@ -89,13 +63,8 @@
   - distgit
   - selinux
 
-- name: create the distgit root directory (/srv/git/repositories)
-  file: dest=/srv/git/repositories state=directory mode=2775 group=packager
-  tags:
-  - distgit
-
 # These should all map to pkgdb namespaces
-- name: create our namespace directories inside there..
+- name: create our namespace directories inside dist-git root directory
   file: dest=/srv/git/repositories/{{item}} state=directory mode=2775 group=packager
   with_items:
   - rpms
@@ -107,39 +76,31 @@
   tags:
   - distgit
 
-- name: install the distgit scripts
+- name: install pkgdb2 integration script
   copy: src={{item}} dest=/usr/local/bin/{{item}} owner=root group=root mode=0755
   with_items:
-- setup_git_package
-- mkbranch
-- mkbranch_branching
 - pkgdb2-clone
   tags:
   - config
   - distgit
 
-- name: install the Dist Git-related httpd config
-  copy: src=git-smart-http.conf dest=/etc/httpd/conf.d/pkgs.fedoraproject.org/git-sm

PROPOSAL: employ a variant of upstream dist-git package into FedoraInfra

[Michal Novotny]

Hey,

I'd like to propose employment of an upstream dist-git package for
deploying pkgs machines. This is the package I have in mind:
https://github.com/release-engineering/dist-git. This package contains
scripts and selinux policy for dist-git files.

Note however that I would like to make this package as compatible with the
infra dist-git as possible and that amounts to great deal of changes (main
one being usage of /srv/ to store repositories and tarballs). I have forked
the original repo into https://github.com/clime/dist-git and will continue
development from there.

The changes are going to be major so the main code-base could be e.g. here
https://pagure.io/group/Fedora-Infra in the end.

So far I have been testing only one use-case based on
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Import.2C_commit.2C_and_build_your_package
.

I will collect all the other use-cases and ideally write a suite of
regression tests based on that. I know pkgs.fedoraproject.org is somehow
related to pagure but I need to additionally investigate this.

I would like to hear the tribe now.
Thank you
clime
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: September status update for Fedora Infrastructure Apprentices

[Michal Novotny]

On Tue, Sep 6, 2016 at 6:48 PM, Kevin Fenzi  wrote:

> You are getting this email because you are in the 'fi-apprentice' group
> in the fedora account system (or are reading this on the
> infrastructure list).
>
> Feel free to reply just directly to me, or cc the infrastructure list
> for everyone to see and comment on.
>
> https://fedoraproject.org/wiki/Infrastructure_Apprentice
>
> At the first of every month(or so), I am going to be sending out an
> email like this one. I would like feedback on how things are going for
> you.
>
> I'd like to ask for everyone to send me a quick reply with the
> following data or anything related you can think of that might help us
> make the apprentice program more useful.
>
> 0. Whats your fedora account system login?
>

clime


> 1. Have you logged in and used your fi-apprentice membership to look at
> our machines/setup in the last month? Do you plan to?
>

I am mostly browsing the setup scripts locally and occassionally checking
things on batcave01.


> 2. Has it helped you decide any area you wish to focus on or contribute
> to more?
>

Well, I was more decided in the beginning than I am now :). Lots of good
stuff.


> 3. Have you looked at or been able to work on any of the fi-apprentice
> 'easyfix' tickets?
> https://fedorahosted.org/fedora-infrastructure/report/14
>

Yes.


> 4. Do you still wish to be a member of the group? If not (for whatever
> reason) could you provide any hints to help others down the road?
>

Yes, I really do.


> 5. Is there any help or communication or ideas you have that would help
> you do any of the above?
>

It pays off to try to setup some interesting infrastructure services in a
docker or a VM.


> 6. What do you find to be the hardest part of getting involved?
> Finding things to work on? Getting attention from others to help you?
> Finding tickets in your interest area?
>

Finding tickets is not that easy but I can manage.


> 7. Have you been able to make any weekly irc meetings? Do you find them
> helpful or interesting?
>

Yes, they are very interesting.


> 8. Have you logged into our Gobby instance and read/seen/added to our
> meeting agenda? https://fedoraproject.org/wiki/Gobby
>

Haven't added anything yet.


> 9. What is the furthest place you have ever traveled from your home?
>

India.


> Any other general feedback is also quite welcome, including
> improvements to this email, the wiki page, etc.
>

 Everything ok to me.
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org