No meeting today.... ?
by Robyn Bergeron
I'm going to be travelling, and a lot of other folks are at red hat summit
as well, or at devopsday - but if anyone wants to gather in about an hour
in #fedora-meeting, please feel free :)
Cheers,
-robyn
11 years, 5 months
Re: [Openstack] centos 6 images
by Pádraig Brady
On 05/22/2012 05:51 PM, Scott Moser wrote:
> On Tue, 22 May 2012, Pádraig Brady wrote:
>
>> On 05/22/2012 03:39 PM, Andy Grimm wrote:
>>> On Tue, May 22, 2012 at 9:38 AM, Pádraig Brady <P(a)draigbrady.com> wrote:
>>>> On 05/22/2012 04:07 AM, Jason Ford wrote:
>>>>> I am trying to put together an image for centos 6 that works like cloud-init on ubuntu does. Currently I have ssh keys getting imported but having some problems getting the disk to dynamically resize to the flavor template as well as the hostname set in horizon to be pushed into the image. Does anyone have any howtos or suggestions on how to get this done? Is there cloud-init for centos just like ubuntu? I would also be interested in how to do this with debian as well.
>>>>
>>>> Well I notice there is no cloud-init package for EPEL.
>>>> I took a quick stab at it here:
>>>> http://pbrady.fedorapeople.org/cloud-init-el6/
>>>
>>> I've already responded in IRC, but it wouldn't hurt to have a response
>>> in the mail archive. In short, the reason there isn't already a
>>> cloud-init for EL6 (or EL5, for that matter) is that upstream has been
>>> using python 2.7-only calls for a while now. In particular, a couple
>>> of calls to subprocess.check_output need to be replaced, and I think
>>> there are a few other issues as well. I don't think it's a huge
>
> It would help if you'd bring that up with upstream :)
> I'm interested in cloud-init working in the most places it can. I'll try
> to pull in the sysvinit scripts that Pádraig added and grab other changes
> that are there.
Excellent.
I'll submit as much as I can upstream anyway after some more testing.
cheers,
Pádraig.
11 years, 5 months
overnight, unable to ssh into fc17 ami instance
by Erik Blankinship
Last night I was happy hacking on my new fc17 instance.
This morning I cannot ssh in any more.
*ssh -i fc17_test_key.pem -l ec2-user
ec2-23-22-xxx-xx.compute-1.amazonaws.com -v*
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options *for* *
debug1: Connecting to ec2-23-22-xxx-xx.compute-1.amazonaws.com
[23.22.xxx-xx] port 22.
debug1: Connection established.
debug1: identity file fc17_test_key.pem type -1
debug1: identity file fc17_test_key.pem-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9
debug1: match: OpenSSH_5.9 pat OpenSSH*
debug1: Enabling compatibility mode *for* protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'ec2-23-22-xxx-xx.compute-1.amazonaws.com' is known and
matches the RSA host key.
debug1: Found key in /Users/jedi/.ssh/known_hosts:6
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can *continue*:
publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: publickey
debug1: Trying *private* key: fc17_test_key.pem
debug1: read PEM *private* key done: type RSA
debug1: Authentications that can *continue*:
publickey,gssapi-keyex,gssapi-with-mic
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
I posted details here:
https://forums.aws.amazon.com/thread.jspa?threadID=98312
Is there something I am missing?
Thanks
11 years, 5 months
RFC: Cloud Interop FAD
by Garrett Holmstrom
Hi, Everyone,
Now that a lot of cloud software is in or on its way into Fedora, I
wonder how easy it is to actually make use of it. We seem to have
installation guides, but not much about how to actually employ the cloud
to do something useful. For instance, now that OpenShift is on the
feature list, Fedora's Cloud Guide could use some recipes for OpenShift
images on, say, OpenStack and Eucalyptus.
So in the interest of Getting Things Done, I suggest that we gather for
a high-bandwidth Fedora Activity Day to work on recipes for making the
various bits of cloud software in Fedora work in concert (i.e. for
making $PaaS work on $IaaS), and fix whatever bugs we encounter during
the process.
Which of you are interested in attending such an event? What would you
like to work on there? Specific goals are the most important thing to
have when planning a FAD to make the day the most likely to result in
something useful.
What do you all think?
--
Garrett Holmstrom
11 years, 5 months
Cloud SIG meeting minutes: 2012-06-22
by Robyn Bergeron
Thanks for coming, have a lovely weekend, folks!
-Robyn
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting/2012-06-22/cloud_sig.2012...
Log:
http://meetbot.fedoraproject.org/fedora-meeting/2012-06-22/cloud_sig.2012...
==========================
#fedora-meeting: Cloud SIG
==========================
Meeting started by rbergeron at 19:01:50 UTC. The full logs are
available at
http://meetbot.fedoraproject.org/fedora-meeting/2012-06-22/cloud_sig.2012...
.
Meeting summary
---------------
* Who's around? (rbergeron, 19:02:02)
* OpenShift (rbergeron, 19:04:11)
* OpenShift = some updates to wiki, mostly bookkeeping right now;
passenger work is still plugging away (rbergeron, 19:07:05)
* openshift upstream is workign on a way to easily set up a scaled
env. with the different components on different nodes/machines, if
desired (rbergeron, 19:11:03)
* moved from a two-week release cycle to a three-week release cycle
(rbergeron, 19:11:19)
* a ruby 1.9 cartridge under heavy development -
https://github.com/openshift/crankcase/tree/master/cartridges/ruby-1.9
(rbergeron, 19:12:07)
* trying to sort out how to do 3-week release cycles and make it work
in a fedora packaging world (rbergeron, 19:14:16)
* ACTION: tdawson to bring up the "how often are we going to bump the
fedora release andhow many old versions do we want to keep around"
question in the openshift community (rbergeron, 19:18:31)
* Other business? (rbergeron, 19:28:22)
* good luck to our euca friends as they get a nice flossy 3.1 out the
door (rbergeron, 19:28:57)
* Euca install is coming along - hw is all in a row, but not installed
yet; arrangements are being made (rbergeron, 19:31:28)
* skvidal will share a timeline once there is a timeline (rbergeron,
19:31:43)
* goal is to provide isolated instances to folks and for us to more
easily migrate around. skvidal is excited for the hw to show up and
be installated. yay! (rbergeron, 19:37:08)
* ACTION: skvidal to test out gregdek's theory by filing the CC/CLC
naming convention bug at euca (rbergeron, 19:38:17)
* PLEASE READ AND RESPOND:
http://lists.fedoraproject.org/pipermail/cloud/2012-June/001530.html
<--- Cloud Interop FAD topic, let's get this puppy planned
(rbergeron, 19:39:30)
Meeting ended at 19:47:08 UTC.
Action Items
------------
* tdawson to bring up the "how often are we going to bump the fedora
release andhow many old versions do we want to keep around" question
in the openshift community
* skvidal to test out gregdek's theory by filing the CC/CLC naming
convention bug at euca
Action Items, by person
-----------------------
* gregdek
* skvidal to test out gregdek's theory by filing the CC/CLC naming
convention bug at euca
* skvidal
* skvidal to test out gregdek's theory by filing the CC/CLC naming
convention bug at euca
* tdawson
* tdawson to bring up the "how often are we going to bump the fedora
release andhow many old versions do we want to keep around" question
in the openshift community
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* rbergeron (82)
* skvidal (41)
* maxamillion (32)
* gholms (21)
* strace (13)
* tdawson (12)
* gregdek (6)
* wwoods (4)
* zodbot (3)
* blentz (1)
* jsmith (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
11 years, 5 months
Cloud SIG Meeting today, 1900 UTC
by Robyn Bergeron
Hey cloudy peeps.
There's a meeting today, in about an hour:
When: 1900 UTC (3pm US Eastern, 12pm US Pacific)
Where: #fedora-meeting on irc.freenode.net
I'm lacking in agenda today, but if anyone (openstack? openshift? euca?)
has any updates for the universe, we're happy to hear them.
-Robyn
11 years, 5 months
OpenStack Folsom feature for F18 & questions
by Robyn Bergeron
Hi folks,
With my lovely Program Manager hat on, I sent this over to FESCo for
approval in next week's meeting:
https://fedoraproject.org/wiki/Features/OpenStack_Folsom
That said, a few questions:
* Are there any significant new features / inclusions planned for this
release? It's hard to tell from the feature page - I sent it on
through to FESCo (with my PM hat on) because technically it's a
complete page (I'm willing ot let the release notes section be empty
for a bit since I know they'll come along from upstream) - but with
my, uh, Marketing Team hat on (I should really have a closet just for
hats) there's not much I can say other than "newer stuff, probably
with bugfixes." I know there's been some work around novnc and some
various python-y things - are those worth mentioning at all in the
feature page?
* I noticed in the latest status report that swift wasn't among the
packages updated to Folsom - are we not expecting any changes there?
* I know that Matt Domsch has raised the question of ongoing support
for older releases and the intersection with EPEL on the mailing list,
with no answer -
http://lists.fedoraproject.org/pipermail/cloud/2012-May/001494.html -
is it possible we could move this topic forward, mostly right now WRT
openstack, but also keeping in mind that there are other IaaS-y things
on the horizon for Fedora and a more broad policy might be useful?
* There are a few bulletpoints in the feature page in the scope
section listed as possiblys - including postgresql support, yum
groupinstall, upgrades from essex - I'm not clear on if those are just
random ideas, or decisions made upstream in openstack land, but I
haven't really seen any discussion on these (I'm also known to miss a
lot of things, so take that with a grain of salt).
But I know there are plenty of folks who have commit/approve/owner
access to openstack packages and I do wonder what their thoughts are
(mostly wrt upgrades from essex and groupinstall), since the feature
page wasn't really advertised before it got submitted (and I say that
with my nicest "meritocracy means those doing the work get to make
decisions" hat on, but if people don't know the work is being
planned....). Can you clarify what the plans/ideas/decision points are
for those bulletpoints going forward? :D
-robyn
11 years, 5 months
Re: [python-quantumclient] Add conflict with python-quantum 2012.1 since site-packages/quantum is no longer provided.
by Robert Kukura
[I'm adding the fedora cloud list to this thread to solicit feedback on
whether the Conflicts statement I've added to the latest rawhide
python-quantumclient spec file is justified. I agree with Alan that
Requires is preferred in general over Conflicts, but I'm not seeing how
Requires could be used to resolve the issue. As background, note that
the 2012.1 release of python-quantum had a dependency on the some
"common" code that was provided by the 2012.1 release of
python-quantumclient. This dependency did not exist in the 2011.3
releases of these packages and will no longer exist in the 2012.2
releases, so therefore I've asserted that the 2012.2 version (and
higher) version of python-quantumclient conflicts with the 2012.1
version python-quantum to prevent upgrading python-quantumclient from
breaking python-quantum.]
On 06/18/2012 07:31 AM, Alan Pevec wrote:
>> +# The essex release of python-quantum dependend on
>> +# python-quantumclient to provide %%{python_sitelib}/quantum, which is
>> +# no longer provided. Users will have to upgrade both simultaneously.
>> +Conflicts: python-quantum = 2012.1
>
> It is preferred to use Requires instead of Conflicts
> http://fedoraproject.org/wiki/Packaging:Conflicts
Alan, thanks very much for looking at this. If there is a better
approach, I will fix this.
I think the conflict is the only workable solution in this case. I'm
trying to prevent an upgrade of python-quantumclient from essex (2012.1)
to folsom (2012.2) from breaking an existing installation of essex
python-quantum (2012.1). I can't go back and add "Requires
python-quantumclient = 2012.1" to the python-quantum 2012.1 package,
since there is no guarantee people would upgrade their essex
installation of python-quantum before trying to upgrade to folsom
python-quantumclient.
I think this usage is justified under the clause: "Keep in mind that
implicit conflicts are NEVER acceptable. If your package conflicts with
another package, then you must either resolve the conflict, or mark it
with Conflicts:." The implicit conflict does exist, since the upgrade of
python-quantumclient to 2012.2 would remove stuff the 2012.1 version of
python-quantum depends on.
>
> What about this: folsom version of python-quantum should have
> Requires: python-quantumclient >= 2012.2
> and here in python-quantumclient Requires: python-quantum >= 2012.2
> ?
The whole point of the upstream change was to decouple python-quantum
and python-quantumclient. In folsom, neither depends on the other
upstream, so I'd strongly prefer not to have either folsom fedora
package require the other.
Any other ideas? I did include an explanation in the spec file as
required by the packaging guidelines when the conflicts is used. Or is
this OK?
Thanks,
-Bob
>
> Alan
>
11 years, 5 months
Packaging upstream splits/reorgs WAS Re: [python-quantumclient] Add conflict with python-quantum 2012.1...
by Alan Pevec
On Mon, Jun 18, 2012 at 4:27 PM, Robert Kukura <rkukura(a)redhat.com> wrote:
...
> On 06/18/2012 07:31 AM, Alan Pevec wrote:
>> What about this: folsom version of python-quantum should have
>> Requires: python-quantumclient >= 2012.2
>> and here in python-quantumclient Requires: python-quantum >= 2012.2
>
> The whole point of the upstream change was to decouple python-quantum
> and python-quantumclient. In folsom, neither depends on the other
> upstream, so I'd strongly prefer not to have either folsom fedora
> package require the other.
>
> Any other ideas? I did include an explanation in the spec file as
> required by the packaging guidelines when the conflicts is used. Or is
> this OK?
If you don't want new python-quantumclient to have a hard dependency
on python-quantum, they, yeah, there isn't other way than conflict.
Otherwise, Requires as I proposed should produce the same result after
yum update.
I'd like to use the opportunity to discuss what is everybody's
expected behavior on upgrade when upstream splits or reorganizes. I'd
like to ensure "least surprise" for the user i.e. yum update should
produce a system with the same functionality.
For example, in Swift 1.5.0 S3 emulation was removed from the core and
split as a new plugin project http://github.com/fujita/swift3
When packaging this, I made openstack-swift require new package
openstack-swift-plugin-swift3 otherwise user would be left w/o S3
emulation.
Of course, configuration files (or rather paste-deploy which is more
code than config) need to be edited, replacing egg:swift#swift3 with
egg:swift3#swift3 but we don't have a solution for that in RPM-world,
except to provide .rpmnew and leave to the administrator to merge
configuration changes.
Best would be if all paste-deploy is moved out of files marked %config
and located under /usr/share/ where it can be safely updated.
Cheers,
Alan
11 years, 5 months
