> cool. seems like we got most of the way there but never integrated it
> into atomic host? Is it in any shipped version of atomic host that we
> produce?
It was more of a POC. If we want to get this into Fedora, it
might be worth integrating into the projectatomic/atomic
codebase, rather than a s
The atomic WG had a discussion about ref naming for rawhide/f26 [1]
and decided to change from
`fedora-atomic/rawhide/x86_64/docker-host`
to
`fedora/rawhide/x86_64/atomic-host`
for the ref that we follow in the ostree repo. I just merged a PR [2]
that does this in the pagure/fedora-atomic rep
On 02/24/2017 12:22 PM, Jonathan Lebon wrote:
>> - pre-loading containers on system startup
>> * there is a need for being able to load containers on system
>> startup into the container runtime. I think jlebon already
>> worked on something like this maybe. Either way the idea is
On 02/24/2017 11:27 AM, Micah Abbott wrote:
> On 02/23/2017 11:32 PM, Dusty Mabe wrote:
>>
>> Spent the day chatting with a bunch of Fedora Atomic users today.
>>
>> Some pain points that came out of todays discussions:
>>
>> - kubernetes versions
>> * sometimes we have lagged behind upstream
> - pre-loading containers on system startup
> * there is a need for being able to load containers on system
> startup into the container runtime. I think jlebon already
> worked on something like this maybe. Either way the idea is that
> we have a service that looks in a cert
On 02/23/2017 11:32 PM, Dusty Mabe wrote:
Spent the day chatting with a bunch of Fedora Atomic users today.
Some pain points that came out of todays discussions:
- kubernetes versions
* sometimes we have lagged behind upstream in Fedora and this has
caused some pain. They are on boar
jasonbrooks added a new comment to an issue you are following:
``
@dustymabe How about this: why should fedora do it differently than rhel? RHEL
AH has had the same tree through all docker upgrades, through all kube
upgrades, through half of kube being removed, across 7.1, 7.2, 7.3. They
suppor
dustymabe added a new comment to an issue you are following:
``
> I'm not sure I understand. If you want a new unified repo to be brand new,
> that's fine w/ me. I just want to get rid of the separate refs for each major
> version / required rebase nonsense.
>
I'm just saying that I don't real
dustymabe added a new comment to an issue you are following:
``
>@jberkus
> Agreed, but if we're not supporting the older OSTree in any way, we've
> effectively given users a very short time limit on when they need to
> rebase/upgrade, with the possibility of being forced into it when the older
Just two comments:
Would be awesome to stress out that people MUST override labels, otherwise they
will end up with labels from base image which would result into incorrect
metadata.
I haven't actually tried this, but would it make sense to do?
FROM $FGC/httpd
Well written, Honzo!
Tomas
10 matches
Mail list logo
