[Container-tools] Nulecule-go and Project Atomic github org

Thu Aug 20 14:53:53 UTC 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Well, in a container age it seems to be appropriate if we deliver a
container and can provide its provenance, aint that one of our usp? [1]

So if we agree on that, it is basically up to the project how to build
the binary, as long as it is repeatable.

I would propose having another cycle on nulecule-go and figure out how
that upstream project fits in out build chain.

	//G

[1]
https://blog.docker.com/2015/01/dockercon-eu-trust-and-image-provenance/

On 08/20/2015 04:15 PM, Alec Benson wrote:
> Correct, we will only need to put the static binary inside the
> container to be able to use the program. The Nulecule-Go does
> import some additional Golang libraries like Logrus, go-yaml, and
> Codegangsta CLI. Dan Veillard's concern is that if users want to
> build from source, these dependent libraries are hard to get in RPM
> form in CentOS (However, they are available in Fedora).
> 
> But since, as you pointed out, the goal is to be able to ship this 
> binary statically in a container, I think that trying to get these 
> golang libraries into CentOS form creates more work for package 
> maintainers and doesn't provide much additional benefit. That is
> my opinion, but it sounds like if we do end up wanting to add
> these libraries to CentOS, we should be able to do that as well.
> 
> Alec
> 
> On 08/20/2015 09:54 AM, Daniel J Walsh wrote:
>> My goal with creating nulecule go version, was to be able to ship
>> a static go binary inside of a container.   And that would be the
>> only thing in the container.  I was hoping we could do this 
>> without an OS.  Their would be no RHEL/Fedora/Centos version.
>> 
>> Does nulecule need any other programs in the container?
>> 
>> On 08/19/2015 11:21 AM, Lokesh Mandvekar wrote:
>>> On Wed, Aug 19, 2015 at 01:30:14PM -0400, Alec Benson wrote:
>>>> CC Lokesh Mandvekar
>>>> 
>>>> On 08/18/2015 11:14 PM, Daniel Veillard wrote:
>>>>> I would be tempted to move it under Atomic indeed. My main
>>>>> question is about the deployment model, there is a number
>>>>> of dependencies, are they available in Fedora and CentOS, I
>>>>> would assume no, so this mean we need to ship it as a
>>>>> container for people to be able to start using it. I would
>>>>> say move to Atomic once we have that sorted out and don't
>>>>> leave the coming users to sort out how to install the deps.
>>>>> Because if they fail it's unlikely they will give it a
>>>>> second chance later.
>>> Users will never need to care about those deps unless they
>>> gotta care about actually building nulecule.
>>> 
>>> If needed, those deps can be gotten into CentOS pretty quickly.
>>> Jan Chaloupka has authored 'gofed' which takes care of a lot of
>>> things. Else, we could (dare I say, should) always use the
>>> bundled upstream deps (if upstream bundles them that is) :)
>>> 
>>> Others may (and probably will) disagree, but I strongly feel we
>>> should prefer using upstream bundled golang libs (whenever
>>> available) than depend on rpms. I feel golang-* rpms are just
>>> added labor which nobody (other than pkg owners) cares about
>>> and which provide little to no benefit as _all_ they end up
>>> doing is removing the bundled source and replacing it with the
>>> rpm installed sources. Though using rpm-ed golang deps sounds
>>> so amazing in principle, in reality there are some PITAs.
>>> Interesting read available here:
>>> https://fedorahosted.org/fpc/ticket/382
>>> 
>>>>> Daniel
>>>>> 
>>>>> On Tue, Aug 18, 2015 at 04:20:57PM +0200, Vaclav Pavlin
>>>>> wrote:
>>>>>> I forgot to add Alec to CC and paste a link to the repo: 
>>>>>> https://github.com/alecbenson/nulecule-go
>>>>>> 
>>>>>> Sorry:) V.
>>>>>> 
>>>>>> On Tue, Aug 18, 2015 at 4:17 PM, Vaclav Pavlin
>>>>>> <vpavlin at redhat.com> wrote:
>>>>>> 
>>>>>>> Hey,
>>>>>>> 
>>>>>>> Alec asked me if his golang implementation of Nulecule
>>>>>>> could be moved under Project Atomic github
>>>>>>> organization.
>>>>>>> 
>>>>>>> I haven't enough time to test it properly yet, but it
>>>>>>> might be worth discussing it on a cabal call tomorrow.
>>>>>>> 
>>>>>>> Any thoughts, objections?
>>>>>>> 
>>>>>>> Thanks, Vašek
>>>>>>> 
>>>>>>> -- Architect - Senior Software Engineer Developer
>>>>>>> Experience Brno, Czech Republic Phone: +420 739 666
>>>>>>> 824
>>>>>>> 
>>>>>> -- Architect - Senior Software Engineer Developer
>>>>>> Experience Brno, Czech Republic Phone: +420 739 666 824 
>>>>>> _______________________________________________ 
>>>>>> Container-tools mailing list Container-tools at redhat.com 
>>>>>> https://www.redhat.com/mailman/listinfo/container-tools
>>> 
>>> 
>>> _______________________________________________ Container-tools
>>> mailing list Container-tools at redhat.com 
>>> https://www.redhat.com/mailman/listinfo/container-tools
>> 
>> 
>> 
>> _______________________________________________ Container-tools
>> mailing list Container-tools at redhat.com 
>> https://www.redhat.com/mailman/listinfo/container-tools
> 
> 
> 
> _______________________________________________ Container-tools
> mailing list Container-tools at redhat.com 
> https://www.redhat.com/mailman/listinfo/container-tools
> 

- -- 
Principal Software Engineer - Systems Design & Engineering
Mobile: +49 171 2801345

Follow Us: https://twitter.com/RedHatRefArch
Plus Us: https://plus.google.com/u/0/b/114152126783830728030/
Like Us: https://www.facebook.com/rhrefarch

Red Hat GmbH, http://www.de.redhat.com/ Sitz: Grasbrunn,
Handelsregister: Amtsgericht München, HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham, Michael O'Neill,
Charles Peters
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV1eoBAAoJEKn71953Oyo0iHAP/3/XPsuMbNXyF/coCd6oDxNX
cv8vxnLqqV6ZBuKfaBkDEgpi4yHEK3i6Ncse5ip0dcQKphhnGeYcwSBmiD9hzfSw
UzNYD7QPg0M+x2xascDBf+lre2nUxSAbQBrF8q8qQU3Oo5QZKme7QnQZBnva4Qjd
4H8m84uGc4e+1UpGvCKhFsbvZtBZShc+d0LPEc6X+3xCuI8sqCWJIhicVgVHJUAV
v6srQXQ4+XAwYEvJ2Oae0VHsu+b3xkV5xFDZZUCwcnojLVobjDk9GlMFW1RJi9j0
owvPUbS1djo4FQGAH6EZy53FzZ+FqJzTB6zzJJRl/y5gSXRYMVafX15TZic9Qcz0
Mu7EnWC+uDl/I6WZcmS9tIEq5pBP5pm+/2yDfKkQsEmffpuPXoHRc21jX0vG5cYp
nlnb4R51EDFUUz8HjqE6mcDjJSNAiFUt9C7r2bYCnC3VJfgwa4cINmaqVYxgjwv6
U53zTo9xgvfBhDCL5WJqdoWvz+UEIIP1RgPeATFPF+MaaiJIVArSrUgsvrArWsPj
3X+6fDwIpMuKwxWbEY8VjsXdGE6kou99KUFvvgUjs0fkAZCzal4BkXOJNNjcl1MX
I7cBTjNV+5fEBwWsMeywKWJcOAW8SHjEbHOSoIIsYaaYztddcubOeM5cbnfGMvAr
/AC8k0FLNQ2pujKsK1kU
=KMOR
-----END PGP SIGNATURE-----