Self Introduction: Lalatendu Mohanty
by Lalatendu Mohanty
Hi All,
Before I respond to any mail, I thought of doing self introduction as it
will help other to know about me.
I mostly do scripting in (bash, Python) for my day job. I did Perl
programming for some years previously. In Fedora, I am one of the
packager for GlusterFS and contributes to GlusterFS project. I also
package maintainer of GlusterFS for CentOS storage SIG.
Atomic and Docker looks interesting to me and I am interested to learn
these stuff and contribute to it.
Thanks,
Lala
#lalatenduM on freenode
9 years, 7 months
Updated Atomic alpha w/Bash update(s)?
by Joe Brockmeier
Hi all,
It occurs to me that the bash update isn't going to be available for the
Atomic image(s) since the users can't install new packages.
What do we need to do to get new images spun up and get a new tree for
people to grab with rpm-ostree update?
My understanding is this is manual now, how much lifting do we have yet
to do to make this automatic?
Thanks,
jzb
--
Joe Brockmeier | Principal Cloud & Storage Analyst
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
9 years, 7 months
Atomic / Fedora Infrastructure Meeting 23 September 2014
by Joe Brockmeier
A bit late getting these out, sorry about that!
===============
#atomic Meeting
===============
Meeting started by jzb at 18:02:06 UTC. The full logs are available at
http://meetbot.fedoraproject.org/atomic/2014-09-23/atomic.2014-09-23-18.0...
.
Meeting summary
---------------
* dgilmore is short on time today due to F21 release tasks leftover,
will have to defer to next week (stickster, 18:14:33)
* Compose scripts (stickster, 18:16:17)
* Fedora mainline compose scripts don't have the capability to be run
locally; tools are the same, but configuration may not allow someone
to actually make images (stickster, 18:20:16)
* highest priority goal is a cloud image that boots in at least KVM
and OpenStack and an ostree repo with a mirrorlist that we can pull
updates from (stickster, 18:25:43)
* ACTION: jzb figure out who's got the ball with mirrormanager. (jzb,
18:39:24)
* ACTION: oddshocks will look into Mirrormanager changes and report
back (jzb, 18:45:48)
* jzb thanks oddshocks profusely (jzb, 18:45:58)
* ACTION: oddshocks to send note to cloud(a)lists.fedoraproject.org when
AMIs are ready (jzb, 18:50:32)
Meeting ended at 18:51:34 UTC.
Action Items
------------
* jzb figure out who's got the ball with mirrormanager.
* oddshocks will look into Mirrormanager changes and report back
* oddshocks to send note to cloud(a)lists.fedoraproject.org when AMIs are
ready
Action Items, by person
-----------------------
* jzb
* jzb figure out who's got the ball with mirrormanager.
* oddshocks
* oddshocks will look into Mirrormanager changes and report back
* oddshocks to send note to cloud(a)lists.fedoraproject.org when AMIs
are ready
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* stickster (42)
* walters (29)
* jzb (27)
* dgilmore (22)
* oddshocks (15)
* smooge (6)
* geppetto (5)
* centbot (4)
* zodbot (4)
* jbrooks (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
Joe Brockmeier | Principal Cloud & Storage Analyst
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
9 years, 7 months
2014-09-24 @ 16:00 UTC ** F21 Blocker Review
by Mike Ruckman
# F21 Blocker Review meeting
# Date: 2014-09-24
# Time: 16:00 UTC (12:00 EDT, 09:00 PDT)
# Location: #fedora-blocker-review on irc.freenode.net
Well now that we've finally kicked Alpha out the door, it's time to do some
Beta blocker review. You might think, "Oh, hey - that'll be easy, we just
started!" However, you'd be wrong. We've been tracking beta and final blockers
as well this whole time :) With that said, we have a total of 25 proposed
blockers to go through. So be prepared to get comfortable for the meeting.
If you want to take a look at the accepted blockers, the full list can be found
here: https://qa.fedoraproject.org/blockerbugs/milestone/21/beta/buglist
We'll be evaluating these bugs to see if they violate the Beta
Release Criteria and warrant the blocking of a release if they're not
fixed. Information on the release criteria for F21 can be found on the
wiki [0]. Product specific plans are still being solidified, but that
should be sorted quickly.
For more information about the Blocker and Freeze exception process,
check out these links:
- https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
- https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
And for those of you who are curious how a Blocker Review Meeting
works - or how it's supposed to go and you want to run one - check out the SOP
on the wiki:
- https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
See you tomorrow!
[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
--
// Mike
--
Fedora QA
freenode: roshi
http://roshi.fedorapeople.org
9 years, 7 months
Fwd: Running mesos-slave in Docker container (Atomic Discussion)
by Tim St. Clair
Scott -
When you mentioned running in "privileged mode" mode, what does that mean? Could you provide more details.
Cheers,
Tim
----- Original Message -----
> From: "Tim Chen" <tim(a)mesosphere.io>
> To: user(a)mesos.apache.org, "Gabriel Monroy" <gabriel(a)opdemand.com>
> Sent: Tuesday, September 23, 2014 2:41:17 AM
> Subject: Re: Running mesos-slave in Docker container
> Hi Grzegorz,
> To run Mesos master|slave in a docker container is not straight forward
> because we utilize kernel features therefore you need to explicitly test out
> the features you like to use with Mesos with slave/master in Docker.
> Gabriel during the Mesosphere hackathon has got master and slave running in
> docker containers, and he can probably share his Dockerfile and run command.
> I believe one work around to get cgroups working with Docker run is to mount
> /sys into the container (mount -v /sys:/sys).
> Gabriel do you still have the command you used to run slave/master with
> Docker?
> Tim
> On Tue, Sep 23, 2014 at 12:24 AM, Grzegorz Graczyk < gregory90(a)gmail.com >
> wrote:
> > I'm trying to run mesos-slave inside Docker container, but it can't start
> > due
> > to problem with mounting cgroups.
>
> > I'm using:
>
> > Kernel Version: 3.13.0-32-generic
>
> > Operating System: Ubuntu 14.04.1 LTS
>
> > Docker: 1.2.0(commit fa7b24f)
>
> > Mesos: 0.20.0
>
> > Following error appears:
>
> > I0923 07:11:20.921475 19 main.cpp:126] Build: 2014-08-22 05:04:26 by root
>
> > I0923 07:11:20.921608 19 main.cpp:128] Version: 0.20.0
>
> > I0923 07:11:20.921620 19 main.cpp:131] Git tag: 0.20.0
>
> > I0923 07:11:20.921628 19 main.cpp:135] Git SHA:
> > f421ffdf8d32a8834b3a6ee483b5b59f65956497
>
> > Failed to create a containerizer: Could not create DockerContainerizer:
> > Failed to find a mounted cgroups hierarchy for the 'cpu' subsystem; you
> > probably need to mount cgroups manually!
>
> > I'm running docker container with command:
>
> > docker run --name mesos-slave --privileged --net=host -v
> > /var/run/docker.sock:/var/run/docker.sock -v
> > /var/lib/docker:/var/lib/docker
> > -v /usr/local/bin/docker:/usr/local/bin/docker gregory90/mesos-slave
> > --containerizers=docker,mesos --master=zk://localhost:2181/mesos
> > --ip=127.0.0.1
>
> > Everything is running on single machine.
>
> > Everything works as expected when mesos-slave is run outside docker
> > container.
>
> > I'd appreciate some help.
>
--
Cheers,
Timothy St. Clair
Red Hat Inc.
9 years, 7 months
Cloud SIG Meeting Minutes (2014-09-19)
by Joe Brockmeier
=======================
#fedora-meeting Meeting
=======================
Meeting started by jzb at 17:01:43 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2014-09-19/fedora-meeting...
.
Meeting summary
---------------
* Atomic Image Test Days / Cloud Test Days (jzb, 17:06:05)
* https://openstack.redhat.com/RDO_test_day_Juno_milestone_3 (jzb,
17:07:33)
* Working Group Composition (jzb, 17:13:19)
* ironic vote taken, passes (jzb, 17:18:01)
* ACTION: mattdm will follow up on wg composition with list of
suggestions. (jzb, 17:18:58)
*
http://meetbot.fedoraproject.org/fedora-meeting/2014-09-05/fedora-meeting...
(jzb, 17:22:11)
* generate comps, spin kickstart and environments changes (jzb,
17:24:14)
* Automatic Smoketests on Image Build (jzb, 17:27:27)
* ACTION: roshi or agrimm update ticket on smoketests (jzb, 17:31:51)
* Article for Fedora Magazine on "state of cloud SIG/product" for alpha
release (jzb, 17:31:57)
* https://fedorahosted.org/cloud/ticket/75 (jzb, 17:32:10)
* ACTION: jzb take feedback and finish article for Tuesday or
Wednesday next week (jzb, 17:34:58)
* ACTION: jzb add info on cloud-init / virt manager (jzb, 17:37:24)
* look at virt-sysprep for cloud-init
http://rwmj.wordpress.com/2013/08/02/new-in-virt-sysprep-set-root-and-use...
(jzb, 17:40:33)
* start communication/collaboration on cloud image updates (jzb,
17:42:49)
* https://fedorahosted.org/cloud/ticket/51 (jzb, 17:42:59)
* respin for base image agreed ~1 month + any security/major bugfix
(jzb, 17:48:51)
* new business (jzb, 17:52:54)
* ACTION: agrimm start thread to decide which security updates trigger
rebuild (jzb, 17:56:00)
* ACTION: jzb start change page for F22 on cloud-init (jzb, 18:07:31)
* ACTION: jzb move discussion on cloud-init to mailing list. (jzb,
18:07:46)
* Docker Image for F21 Alpha (jzb, 18:08:35)
* ACTION: mattdm connect with base wg, lsm5, docker, rel-eng about
docker base image upload to registry (mattdm, 18:14:00)
* ACTION: jzb file RFE for zodbot on actions during meeting (jzb,
18:15:33)
Meeting ended at 18:16:57 UTC.
Action Items
------------
* mattdm will follow up on wg composition with list of suggestions.
* roshi or agrimm update ticket on smoketests
* jzb take feedback and finish article for Tuesday or Wednesday next
week
* jzb add info on cloud-init / virt manager
* agrimm start thread to decide which security updates trigger rebuild
* jzb start change page for F22 on cloud-init
* jzb move discussion on cloud-init to mailing list.
* mattdm connect with base wg, lsm5, docker, rel-eng about docker base
image upload to registry
* jzb file RFE for zodbot on actions during meeting
Action Items, by person
-----------------------
* agrimm
* roshi or agrimm update ticket on smoketests
* agrimm start thread to decide which security updates trigger rebuild
* jzb
* jzb take feedback and finish article for Tuesday or Wednesday next
week
* jzb add info on cloud-init / virt manager
* jzb start change page for F22 on cloud-init
* jzb move discussion on cloud-init to mailing list.
* jzb file RFE for zodbot on actions during meeting
* mattdm
* mattdm will follow up on wg composition with list of suggestions.
* mattdm connect with base wg, lsm5, docker, rel-eng about docker base
image upload to registry
* roshi
* roshi or agrimm update ticket on smoketests
* zodbot
* jzb file RFE for zodbot on actions during meeting
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* jzb (147)
* mattdm (45)
* roshi (42)
* dustymabe (36)
* number80 (30)
* agrimm (23)
* zodbot (21)
* dgilmore (20)
* kushal (13)
* imcleod (5)
* jsmith (5)
* oddshocks (2)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
Joe Brockmeier | Principal Cloud & Storage Analyst
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
9 years, 7 months
security criteria for cloud image updates
by Andy Grimm
In today's Cloud WG meeting, we discussed our cloud base image update
policy, and generally agreed on "~1 month + any security/major
bugfix". Major bugfix can remain pretty fluid, but we'd like to
tighten up the security criteria. The cloud base image is small, but
it still has dozens of packages, so saying we'll respin for "any"
security update is probably too much.
My thought: our commitment should be that the base image cannot be
exploited at the following points:
1) during the boot process
2) by attacking a service running by default on a publicly-accessible port
3) during the package update process
So our list becomes something like:
kernel
glibc
systemd
python
cloud-init (and its python deps)
openssl
openssh
yum (dnf?)
and so on. Specifically, I think we need not worry about minor
security bugfixes to userspace tools, unless they can be exploited in
the normal course of system initialization.
Thoughts? Additions?
Thanks.
--Andy
9 years, 7 months
[DRAFT] State of the Cloud Product Fedora 21 Alpha
by Joe Brockmeier
Thoughts, comments, flames? Please add your comments to the tracking ticket:
https://fedorahosted.org/cloud/ticket/75
State of the Cloud Product
The first alpha for Fedora 21 is out (hooray!) and the Cloud Working
Group is excited to see that the [Cloud Base and Atomic
image](http://stg.fedoraproject.org/en/get-prerelease#cloud) are now out
in the wild for your testing pleasure. Let's take a few minutes to walk
through these offerings and where we're at with the Cloud product, and
where we're going. And, to pique the buzzword crowd's interest, here's a
spoiler – we'll be talking about Docker.
First, let's take a look at what you're getting with the alpha. We have
the base image, which isn't entirely new. We've offered a cloud image
suitable for deployment on EC2, OpenStack, etc. for a while now. It was
a "first-class citizen" in Fedora 20, and (once again) it's a major
focus for the release effort.
The base image is a tailored set of packages that are specially targeted
at the cloud environment. These images should be an excellent base for
developing and deploying services and applications in an IaaS
environment like Amazon Web Services (AWS) or private clouds like
OpenStack and Apache CloudStack.
## Atomic Base Image
What's totally new in Fedora 21 is the Atomic Base Image. What's this
Atomic business, you may well ask?
A few months ago, [Project Atomic](http://www.projectatomic.io/) was
unveiled as a community of practice to develop a platform for running
Docker containers. This means having a tailored platform build from an
existing operating system (e.g., Fedora), that allows "atomic" updates
and has just the tools you need to run and orchestrate Docker
containers. (It also should make a nifty platform for developing
containers as well!)
The idea is that a lot of folks now want to build apps and services
using containers, but they still use general purpose OSes for many
existing applications. Also, the components we need to build the Docker
host OS exist in Fedora (or CentOS, or RHEL), so there's no reason to
re-create the wheel in building the Docker host.
Atomic uses rpm-ostree to create the Fedora Atomic image, and then
allows users or admins to use rpm-ostree for updates. An update is an
"atomic" unit that can rolled back in the event there's a bug or issue
that impacts deployed applications. RPM is a great technology for
packages, but it was only envisoned to go one way – forward. The
beauty of rpm-ostree is that it lets you revert to a previous state of
the host OS with a single command. It also offers some interesting
additional features, like switching between trees for two different
systems, but we're not offering those kinds of updates/options **yet**.
The Atomic image will also feature Kubernetes, Cockpit and other
orchestration tools. Those aren't quite baked for the alpha yet, but we
hope to have them in by Fedora 21 final in a usable state.
## Docker, Docker, Docker?
It bears mentioning that the Docker base image has been split out from
the Cloud Working Group to the Base Working Group, though (obviously)
we'll still be making heavy use of it in cloud environments. A big kudos
to the Base Working Group folks who've taken that on and are doing great
work in getting it into shape for Fedora 21.
The big take-away on Docker, though, is that the Fedora 21 release will
have an "official" Docker image. You can use the Fedora 21 Atomic base
image with the F21 Docker image to test Docker features, or use Atomic
to run Docker to test your containerized applications.
## Where We're At, Where We're Going - Join Us!
As you can see, there's a lot of exciting stuff going on in the Cloud
territory. However, we still have a lot of work to do on testing,
packaging, and developing documentation for best practices.
We'll have a Test Day on 1 and 2 October to kick the tires and so on,
and we'd love to have a ton of Fedorans helping find bugs and problems.
Have questions? Ask us on the cloud mailing list
(cloud(a)lists.fedoraproject.org), or in #fedora-cloud on Freenode. Or
just poke one of the [Working Group
Members](http://fedoraproject.org/wiki/Cloud/Governance) and ask how you
can get started.
--
Joe Brockmeier | Principal Cloud & Storage Analyst
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
9 years, 7 months
Test Days for Alpha / Cloud Image
by Joe Brockmeier
Hi all,
So - the alpha is go for next week! Now we need to set up Test Days for
that...
First thing - let's pick dates. Any objections to 24 and 25 September?
Is that too soon? The RDO folks are doing 1 and 2 October. We *could*
overlap with those days, or maybe we want to avoid them. Thoughts?
We should try to make sure there's at least one or two people in IRC
throughout the day to help with questions, file bugs, etc. Ideally folks
will file their own bugs/tickets, but we might get testers who kind of
"drive-by" and give useful feedback, but aren't all set up with
bugzilla/Trac accounts.
We need to beef up the Atomic test cases/etc., but I think we're OK with
the base image. Is that correct?
Thoughts, comments?
Best,
jzb
--
Joe Brockmeier | Principal Cloud & Storage Analyst
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
9 years, 7 months
