FAD Goals and deliverables

Mon May 11 20:56:52 UTC 2015

On Mon, May 11, 2015 at 1:06 PM, Dennis Gilmore <dennis at ausil.us> wrote:
> On Monday, May 11, 2015 12:18:41 PM Adam Miller wrote:
>> On Sun, May 10, 2015 at 1:28 PM, Dennis Gilmore <dennis at ausil.us> wrote:
>> > Hi all,
>> >
>> > As we get closer to the FAD we need to nail down the deliverables and what
>> > we want to achieve by the end of the FAD.  I am going to list some of the
>> > things I think we need to have done. feel free to discuss and add things.
>> >  at the ned we will update the wiki with the deliverables.
>>
>> +1
>>
>> > 1) working pungi 4.
>>
>> I'm curious what all this entails? I was thinking we should try to at
>> least make some notes on success criteria, requirements for what
>> pungi4 will bring to the table, etc. for a couple reasons 1) Just to
>> have for posterity  ... 2) For newcomers looking from the outside to
>> have perspective on what exactly pungi4 is and what improvements at a
>> high level it will bring.
> pungi-koji --target-dir=/mnt/tealc/compose/ --nightly --
> config=/home/dennis/code/pungi-fedora/fedora-21.conf
> None
> Exception: Release: Field 'name' has invalid type: <type 'NoneType'>
> Traceback (most recent call last):
>   File "/bin/pungi-koji", line 327, in <module>
>     main()
>   File "/bin/pungi-koji", line 172, in main
>     compose_dir = pungi.compose.get_compose_dir(opts.target_dir, conf,
> compose_type=compose_type, compose_label=opts.label)
>   File "/usr/lib/python2.7/site-packages/pungi/compose.py", line 92, in
> get_compose_dir
>     ci.dump(os.path.join(work_dir, "composeinfo-base.json"))
>   File "/usr/lib/python2.7/site-packages/productmd/common.py", line 160, in
> dump
>     self.serialize(parser)
>   File "/usr/lib/python2.7/site-packages/productmd/composeinfo.py", line 152,
> in serialize
>     self.release.serialize(data["payload"])
>   File "/usr/lib/python2.7/site-packages/productmd/composeinfo.py", line 417,
> in serialize
>     self.validate()
>   File "/usr/lib/python2.7/site-packages/productmd/common.py", line 115, in
> validate
>     method()
>   File "/usr/lib/python2.7/site-packages/productmd/composeinfo.py", line 359,
> in _validate_name
>     self._assert_type("name", list(six.string_types))
>   File "/usr/lib/python2.7/site-packages/productmd/common.py", line 82, in
> _assert_type
>     raise TypeError("%s: Field '%s' has invalid type: %s" %
> (self.__class__.__name__, field, type(value)))
> TypeError: Release: Field 'name' has invalid type: <type 'NoneType'>
>
> is what I get currently so working for me is able to run successfully and
> produce a usable compose .  it brings us being able to do parts of the compose
> process on builders in koji, this means we can distribute the workload across
> more machines, enabling us to parallelise the compose and dramatically speed
> it up. additionally enabling us to be more visable and public about what is
> going on in a compose.
>
>> > 2) integrated ability to make atomic installer and pxe to live in pungi
>> > 3) mash ported to createrepo_c
>> > 4) rawhide looking like a TC/RC
>> > 5) bodhi2 able to trigger atomic installer and pxe to live as part of the
>> > update push process.
>> > 6) livemedia-creator koji integration
>> > 7) koji able to manage the url line in kickstarts so that we can do real
>> > builds
>> > 8) run-root plugin configured
>> > 9) Secondary arches working exactly teh same as primary
>> > 10) port pungi to dnf
>> > 11) make headway and plan to port to python 3
>> >
>> > Before the FAD, we need to work with infrastructure and have a plan for
>> > the
>> > support of pagure for git repo hosting.
>>
>> Another thing I would like to do is try and sort out requirements of
>> the stage koji environment so that it can be something we have at our
>> disposal for the FAD in whatever capacity everyone feels it is needed
>> and would be useful. There was a thread started about it in the
>> Infrastructure list by nirik[0] but didn't seem to get too far, I was
>> hoping mentioning it here would bring some attention to it.
> Having a working stage or dev koji will be needed to let us test some pieces.
> I setup a dev koji with ssl cert auth in about an hour at home yesterday.  we
> will definitely need to have a working environment for testing

tl;dr - I was introduced to kojak[0] ("Koji in a box") and it's
awesome and I might have crazy ideas that follow as a side effect. :)

So I tried this a while back and it took me an entire day and I was
mostly lost, it was the first time I had ever tried it though so I'm
sure it's something that would get easier with time. However, I was
talking about the idea of an ansbile playbook to deploy an all-in-one
type koji environment just for testing in #fedora-releng and opuk
pointed me to kojak[0] which is a project from someone on his team and
it basically made my day. I love the idea of having a development
environment for koji that can actually be tested against without
rocking the boat for the whole team. I'm now mulling over the idea of
using the Fedora OpenStack Cloud for some cloud image creation of
"Koji in a Box" based off some development branch... will try to
manifest this into something real and write it all up but in the mean
time I had to pass this along.

-AdamM

[0] - https://github.com/sbadakhc/kojak

>
>> -AdamM
>>
>> [0] -
>> https://lists.fedoraproject.org/pipermail/infrastructure/2015-April/016121.
>> html
>> > A big thing we must have to support being flexible in delivery going
>> > forward is bodhi 2.  Without it we can not deliver atomic in the way that
>> > atomic desires.
>
>
> _______________________________________________
> rel-eng mailing list
> rel-eng at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/rel-eng