[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [atomic-devel] Atomic as Base OS for Standalone Appliance
- From: Scott McCarty <smccarty redhat com>
- To: "Shane O'Donnell" <sodonnell cree com>, "atomic-devel projectatomic io" <atomic-devel projectatomic io>
- Subject: Re: [atomic-devel] Atomic as Base OS for Standalone Appliance
- Date: Fri, 25 May 2018 16:34:57 -0400
Shane,
I see nobody has responded. To be honest, I read your email three
times, and I can't quite figure out your use case. I am guessing others
may be heads down working on the new Red Hat CoreOS and hence haven't
had time to dig into this. I am a product manager for Containers at Red
Hat so really interested in your use case to understand if it's
something applicable to others and hence something we might want to
capture longer term.
I understand OSTree decently well, but am wondering if some of these
changes wouldn't be better captured in an orchestration layer than in
customizing an OS with kernel parameters, or perhaps in some super
privileged containers that turn things on/off depending on scheduling,
etc. In fact, we just did a presentation at Red Hat Summit with Hitachi
because they had some similar requirements around sysctl variables...
I will be down in Raleigh on the afternoon/evening of June 5th and would
love to meet up and chat. Happy to meet up late afternoon, or early
evening. If you are around feel free to respond to me off list.
Best Regards
Scott M
On 05/21/2018 03:09 PM, Shane O'Donnell wrote:
Hey All –
We’re building an IoT edge device based on CentOS Atomic Host and as
seasoned sysadmins/developers, we’re trying to break ourselves of
“normal server admin” habits and trying to get more into the Atomic
flow. We’ve already stopped doing a lot of stupid things (e.g.,
remounting /usr rw), but some things still seem impossible.
As an example, we’re trying to follow the “transactional” nature of
Atomic, but we’re finding there’s no real “commit”. When we need to
change something in the OS itself, we end up stuck with a “hotfix”
flagged deployment that we can’t really “commit” to clear the flag,
which leaves us unable to make follow-on transactional changes.
We are also in the process of migrating our Ansible-based platform
customization and software-load (i.e., Docker containers managed via
Docker Compose) which seems somewhat unnatural in the Atomic world.
The docs seem pretty clearly focused on using Atomic as the OS for a
cluster, but our standalone deployments seem to leave us with a lot of
questions. I think the following list is a reasonable summary of the
big questions we haven’t really figured out yet:
* Is there a “commit” that would allow us to commit the current
“hotfix” to the current deployment?
* Once in “hotfix” mode, is there anyway to get out of it that
doesn’t toss the existing changes?
* All of our appliances start with a common base image. What’s the
recommended approach for changing kernel arguments so they appear
in the common base image?
* What am I not telling you that would be helpful in this case?
Note that we’re both invested and committed to using Atomic, and we’d
like to offer up a resource to help flesh out the “standalone” side of
the documentation so we both have some agreed upon contract between
users and core devs, as well as to better enable new users with this
use case.
Thanks in advance –
Shane O.
P.S. If you’re in the Raleigh, NC area, I’d happily buy lunch or a
beer (or both!) for a chance to pick someone’s brain on some of these
issues.
This e-mail message, including any attachments and previous email
messages sent with it, contains CONFIDENTIAL and PROPRIETARY
information of Cree, Inc. or its subsidiaries and may be legally
PRIVILEGED. You may not use, disclose, reproduce or distribute such
information without Cree's authorization. If you have received this
message in error, please notify the sender immediately and permanently
delete the original message, its attachments and any copies thereof.
--
Scott McCarty, RHCA
Technical Product Marketing: Containers
Email: smccarty redhat com
Phone: 312-660-3535
Cell: 330-807-1043
Web: http://crunchtools.com
When should you split your application into multiple containers?
http://red.ht/22xKw9i
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]