Hi!
Sorry - we've been a bit busy and this got put on the back burner. I
believe that ttx has done some work over the last couple of weeks ...
Theirry, any updates from your end?
Github as an option is problematic for several reasons. The ones that
come to mind are that it's not opensource, it
proposals and
discussions - completely the opposite. I want them to connect to
developers and vice versa.
That's why I believe that GitHub worths trying.
-- Jarda
[1] http://www.invisionapp.com/
[2] http://www.invisionapp.com/
[3] http://www.govisually.com/
On 2013/19/06 03:49, Monty
On 05/13/2013 11:03 AM, Doug Hellmann wrote:
On Sat, May 11, 2013 at 5:48 PM, Anne Gentle a...@openstack.org
mailto:a...@openstack.org wrote:
On Sat, May 11, 2013 at 3:12 PM, Monty Taylor mord...@inaugust.com
mailto:mord...@inaugust.com wrote:
On 05/11
On 05/11/2013 08:58 PM, Anne Gentle wrote:
On Sat, May 11, 2013 at 6:43 PM, Monty Taylor mord...@inaugust..com
mailto:mord...@inaugust.com wrote:
On 05/11/2013 05:48 PM, Anne Gentle wrote:
On Sat, May 11, 2013 at 3:12 PM, Monty Taylor mord...@inaugust
into too much
trouble along the way.
Brad Knowles bknow...@momentumsi.com wrote:
On May 12, 2013, at 9:52 AM, Monty Taylor mord...@inaugust.com wrote:
I would really like to keep the marketing/business folks out of our
source code.
Most importantl, I would really like to keep the lawyers out
I have been arguing for:
mutnuaq
Granted, it takes a minute to learn how to type, but it's just a little
snarky, and it takes up the exact same number of letter. However, it
does screw with sorting. SO - what about:
qumutna
It's a little bit easier to wrap your head around, it's still clearly
On 05/11/2013 04:07 PM, Asher Newcomer wrote:
Or even better, just continue to call it openstack networking. The code
names only serve to confuse the uninitiated. They needlessly steepen the
learning curve and slow uptake.
The problem with OpenStack Networking (or getting rid of codenames)
Jeremy Stanly on IRC just suggested kumquat... but to that I respond:
qumkuat
Same benefits as qumutna - except it's more pronouncable.
On 05/11/2013 04:07 PM, Monty Taylor wrote:
I have been arguing for:
mutnuaq
Granted, it takes a minute to learn how to type, but it's just a little
Neat!
Have you seen any of the work around nova baremetal (which is
transitioning to be called ironic?) Related to that is a set of virtual
power drivers which allow for treating virtual machines like real
machines - so that you can use nova to pxe boot a kvm or a virtualbox or
a vmware instance.
On 05/11/2013 05:48 PM, Anne Gentle wrote:
On Sat, May 11, 2013 at 3:12 PM, Monty Taylor mord...@inaugust..com
mailto:mord...@inaugust.com wrote:
On 05/11/2013 04:07 PM, Asher Newcomer wrote:
Or even better, just continue to call it openstack networking. The
code
The Sprint 2013 TC Election has concluded. The at-large members elected are:
vishy
ttx
For a term of one year.
mikal
For a term of six months.
Congratulations.
http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_5af0b5341a01b892
___
Hey all!
186 of 618 voters have cast ballots in the TC election. Tomorrow is the
last day ... go vote now!
Monty
PS. Look for an email titled Poll: Spring 2013 OpenStack TC Election
and click the link
___
Mailing list:
I confirm that Thierry is eligible to run for a seat on the TC.
On 03/15/2013 11:32 AM, Thierry Carrez wrote:
Hi everyone,
I'd like to run for reelection to one of the Technical Committee
directly-elected seats.
For those who don't know me, I've been handling release management
duties
I confirm that Carl is eligible to run for a seat on the TC.
On 03/15/2013 07:08 PM, Carl Perry wrote:
Greetings -
I would like to run for a TC seat as well. My platform is a focus on
deployment and operations for OpenStack. I'm not going to mince words:
deploying OpenStack is hard.
I confirm that Chris is eligible to run for a seat on the TC.
On 03/18/2013 06:11 PM, Chris Behrens wrote:
Hi all,
I'd like to announce my candidacy for a seat on the OpenStack
Technical Committee.
- General background -
I have over 15 years of experience designing and building
I confirm that Eric is eligible to run for a seat on the TC.
On 03/18/2013 03:23 PM, Eric Windisch wrote:
Hello,
I'd like to run for a seat on the Technical Committee. I am a Principal
Engineer at Cloudscaling, but I am running as an individual.
For over two years, beginning with Bexar,
If you are an ATC, you should by this point have received a link that
will let you vote in the OpenStack TC election. You should vote.
If you read it, you will note that it says February 28 is the end date.
That is an error - March 28 is the end date.
I confirm that Michael is eligible to run for a seat on the TC.
On 03/15/2013 11:27 AM, Michael Still wrote:
Hi. I'd like to run for the TC Spring 2013 election. I am a senior
software engineer at Rackspace in their OpenStack group, and have
worked in a variety of cloud devops roles for the
I confirm that Chuck is eligible to run for a seat on the TC.
On 03/16/2013 12:59 PM, Chuck Thier wrote:
Hello all,
I would like to run for a seat on the TC. I am one of the original
developers of Rackspace Cloud Files which became Openstack Swift, and
was deeply involved with the
I confirm that Gary is eligible to run for a seat on the TC.
On 03/15/2013 02:13 PM, Gary Kotton wrote:
Hi,
I'd like to run for the Technical Committee in the up and coming elections.
I am a Principle Software Engineer at Red Hat. I have been actively
developing OpenStack since the Essex
I confirm that Vishvananda is eligible to run for a seat on the TC.
On 03/15/2013 05:41 PM, Vishvananda Ishaya wrote:
Hello all,
I would like to run for a seat on The Technical Comittee. I have been working
on Nova since it was a project as Nasa and I have been heavily involved in
The PTL elections for the Havana cycle have completed. The new PTL's are:
Nova: Russell Bryant
Ceilometer: Julien Danjou
Keystone: Dolph Matthews
Congratulations!
As a side note, we had over 50% participation in each of the three
elections, which I have been told is actually a really good
Now that the TC elections have ended, we now have three at-large seats open.
https://wiki.openstack.org/wiki/TC_Elections_Spring_2013
Mar 15 - 21: Open candidacy to directly-elected TC positions
Mar 22 - 28: TC elections
The persons ranking 1st and 2nd will get one-year seats on the TC,
If you are an ATC for a keystone, nova or ceilometer, you should have
now received in the mail your link to vote in the PTL election for that
project be sure to vote! The elections end March 14.
For the other projects, there was only one person standing for election,
so congratulations guys, you
On 03/04/2013 10:02 AM, Nirlay Kundu wrote:
Which tool would you use for configuration management geared towards
Openstack api : Chef, Puppet, Saltstack ? If anybody has experience with
Saltstack, please let me know the advantages , shortcomings.
I would use Heat to orchestrate thing WRT the
Hi everyone!
Spring is upon us, which means it's time to overthrow our leadership and
replace it with new (or the same) leadership!
First we elect PTL's, then we elect TC at-large members. So first things
first:
** PTL Candidacy Nomination Period is open from now until March 7 **
If you would
On 01/25/2013 12:54 PM, Thomas Goirand wrote:
On Fri Jan 25 2013 06:29:32 AM CST, Monty Taylor mord...@inaugust.com wrote:
f) Hood is only 4 letters. Think about that when you think about typing
hatfield a lot. Also, if we name it hatfield, we're going to have to
have the M summit somewhere
Hey all!
Here's my pitch for Hood:
a) It's the tallest mountain in Oregon, and honestly, it's a pretty
kick-ass mountain in general
b) Being in the pacific northwest, the mountain itself is quite
regularly in the clouds. That's gotta count for something.
c) It's actually a volcano.
d) Mount Hood
...@linux.vnet.ibm.com wrote:
On 01/24/2013 02:50 PM, Monty Taylor wrote:
Hey all!
Here's my pitch for Hood:
a) It's the tallest mountain in Oregon, and honestly, it's a pretty
kick-ass mountain in general
b) Being in the pacific northwest, the mountain
I vote for hoodies.
On 01/25/2013 09:28 AM, Doug Hellmann wrote:
Will we have hoodies instead of t-shirts for ODS attendees?
Doug
On Thu, Jan 24, 2013 at 2:50 PM, Monty Taylor mord...@inaugust.com
mailto:mord...@inaugust.com wrote:
Hey all!
Here's my pitch for Hood
Hi everybody!
I'd like to run for a seat on the Technical Committee.
- OpenStack Experience -
I run the CI and Developer Automation team for OpenStack. There hasn't
always been a team, but as long as there has been, I've been doing it.
Before there was a proper team, there was Soren and I, and
On 07/29/2012 07:47 PM, Monty Taylor wrote:
Hey!
This might be fairly tricky to fix properly given the design of the
devstack gate. I could be wrong, it might not be terrible now that we
can release new client lib versions to PyPI more quickly. The devstack
gate explicitly tests proposed
Hey!
This might be fairly tricky to fix properly given the design of the
devstack gate. I could be wrong, it might not be terrible now that we
can release new client lib versions to PyPI more quickly. The devstack
gate explicitly tests proposed change to trunk of one project against
tip of trunk
Hi!
You probably want to check out jclouds as well. It's extremely mature,
is in production all over the world and has support for openstack
compute and storage.
http://www.jclouds.org/
Monty
On 07/18/2012 08:50 AM, Jyothsna Padavala wrote:
Thanks Vincent for your reply.
I lean towards
On 07/12/2012 04:36 PM, Vishvananda Ishaya wrote:
On Jul 12, 2012, at 2:22 PM, Narayan Desai wrote:
I think that the long term maintenance or removal of nova-volume in
its existing form is orthogonal to the actual issue of continuity from
one release to the next.
Agreed. Discussion
On 07/10/2012 04:23 PM, Matt Ray wrote:
Bluntness appreciated, this process is already in motion.
http://opscode.com/openstack was launched 2 weeks ago and I promptly
left for conferences and vacation. I am consolidating GitHub repos
here:
Awesome.
On 07/03/2012 08:43 AM, Doug Hellmann wrote:
On Jul 2, 2012, at 6:40 PM, Monty Taylor mord...@inaugust.com
wrote:
Hey all!
One of the tasks from the last ODS was to implement a single
global dependency list. Turns out the more you think about it, the
more important it is... because
On 07/03/2012 10:09 AM, Eric Windisch wrote:
I have to agree with others that copying files around is not ideal, and
I can see the maintenance of this getting more involved as Nova becomes
more coupled with common.
Additionally, we'd make the copy only copy in the versions from
: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-
bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of
Monty Taylor
Sent: Tuesday, July 03, 2012 7:54 AM
To: Eric Windisch
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Single global
tl;dr - Screw the rules, I agree
Let's at least add it to the poll.
Also - I think we should further amend the rules such that we select the
NEXT release by the summit for the current release. That means two things:
At the g summit, we'd tell everyone where the next summit is:
At the g summit,
On 07/03/2012 05:07 PM, Duncan McGreggor wrote:
On Tue, Jul 3, 2012 at 5:39 PM, Dan Wendlandt d...@nicira.com wrote:
Lately, Quantum reviewers have been doing their best to enforce python style
guidelines above and beyond the programmatically enforced pep8 checks. This
has happened for many
On 07/03/2012 07:29 PM, Brian Waldon wrote:
On Jul 3, 2012, at 5:21 PM, Monty Taylor wrote:
tl;dr - Screw the rules, I agree
Let's at least add it to the poll.
Also - I think we should further amend the rules such that we select the
NEXT release by the summit for the current release
the circle of reviewers on these
centralized projects that have the power to block everyone yet are so
easy to ignore...
TOTALLY agree - especially on expanding the circle of reviewers.
All the best,
- Gabriel
-Original Message- From: Monty Taylor
[mailto:mord...@inaugust.com] Sent
Interestingly enough - gerrit supports submodules pretty well... and it
does exactly what Eric said below ... if both the project and
superproject are in gerrit, and a change is made to the project, gerrit
can automatically update the superproject reference.
Here's the thing though (and one of
On 07/03/2012 07:33 PM, James E. Blair wrote:
Brian Waldon brian.wal...@rackspace.com writes:
TL;DR - Screw the rules, let's call the next release 'Grizzly'
As California is rather lacking in the 'municipality names starting
with a G that we should use for an OpenStack release'
On 07/02/2012 06:46 AM, John Garbutt wrote:
Hi,
I noticed I can now run the pep8 tests like this (taken from Jenkins job):
tox -v -epep8
...
pep8: commands succeeded
congratulations :)
But the old way to run tests seems to fail:
./run-tests.sh -p
On 07/02/2012 05:14 AM, Daniel P. Berrange wrote:
I must say that this has been driving me mad this last week. IIUC, only
members of the core review team have permission to retrigger Jenkins,
but I feel it is putting too much burden on them to have to track every
patch with a bogus Jenkins
On 07/02/2012 06:02 AM, Leander Bessa Beernaert wrote:
Thanks, that let me see the real problem now:
./tools/with_venv.sh nosetests -svx nova
nose.config: INFO: Set working dir to /home/gsd/nova/nova/tests
nose.config: INFO: Working directory /home/gsd/nova/nova/tests is a
On 07/02/2012 06:46 AM, John Garbutt wrote:
Hi,
I noticed I can now run the pep8 tests like this (taken from Jenkins job):
tox -v -epep8
...
pep8: commands succeeded
congratulations :)
But the old way to run tests seems to fail:
./run-tests.sh -p
so i'm not sure what's happening there :s
global libvirt
if libvirt is None:
libvirt = __import__('libvirt')
Regards,
Leander
On Mon, Jul 2, 2012 at 1:27 PM, Monty Taylor mord...@inaugust.com
mailto:mord...@inaugust.com wrote:
On 07/02/2012 06:02 AM
to fix things.
Thanks for your help,
John
-Original Message-
From: Monty Taylor [mailto:mord...@inaugust.com]
Sent: 02 July 2012 1:28
To: John Garbutt
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] PEP8 checks
On 07/02/2012 06:46 AM, John Garbutt wrote:
Hi,
I
Run:
sudo pip install tox
And you will get the tox command.
Does ./run_tests.sh -N nova.tests.test_libvirt work fine when you
_don't_ have libvirt? It needs to skip the test if you don't have
libvirt installed, and it needs to run it and pass if you do.
Jenkins is going to run tox -v -epy27
Hey all!
One of the tasks from the last ODS was to implement a single global
dependency list. Turns out the more you think about it, the more
important it is... because of the way we use devstack as part of the
gate, we actually _currently_ have a de facto global dependency list,
it's just not
Hey all!
(It must be a busy day - I'm writing you all so many emails...)
A little while ago, after chatting with Anne Gentle, we started
publishing the sphinx documentation to
docs.openstack.org/developer/$project ... instead of to
$project.openstack.org. That went really well and we're happy
Hi!
We were doing some maintenance this afternoon on jenkins and gerrit -
you were unlucky enough to push right in the middle of that.
Try amending your commit (git commit --amend) and change the commit
message a little (put a space after the comma here:
lp:1019348,update and then run git review
Hey! I agree with most of this in general. A few comments about a
section I just happened to read:
On 06/27/2012 06:52 AM, Daniel P. Berrange wrote:
snip
Including external references
-
The commit message is primarily targetted towards human interpretation,
but
On 06/29/2012 04:06 AM, Alan Pevec wrote:
On Thu, Jun 28, 2012 at 9:56 PM, Monty Taylor mord...@inaugust.com wrote:
https://review.openstack.org/9109
Why is setuptools_git added in pip-requires, I thought that's for
run-time, not build-time dependencies?
Hey Alan!
We use pip-requires
isn't really
build-time vs. run-time as much as it has to do with our use of virtualenv.
HOWEVER - I think I just had an idea of how to make this slighly
cleaner. Let me poke at it.
On 6/29/12 4:06 AM, Alan Pevec ape...@gmail.com wrote:
On Thu, Jun 28, 2012 at 9:56 PM, Monty Taylor mord
On 06/29/2012 10:48 AM, Alan Pevec wrote:
On Fri, Jun 29, 2012 at 7:19 PM, Monty Taylor mord...@inaugust.com wrote:
We use pip-requires as part of building the virtualenvs. Once we start
using it, setuptools-git is pretty much required for running setup.py,
so many common actions in our
On 06/29/2012 10:48 AM, Alan Pevec wrote:
On Fri, Jun 29, 2012 at 7:19 PM, Monty Taylor mord...@inaugust.com wrote:
We use pip-requires as part of building the virtualenvs. Once we start
using it, setuptools-git is pretty much required for running setup.py,
so many common actions in our
On 06/28/2012 07:32 AM, Daniel P. Berrange wrote:
Today we face a situation where Nova GIT master fails to pass all
the libvirt test cases. This regression was accidentally introduced
by the following changeset
https://review.openstack.org/#/c/8778/
If you look at the history of
build_sphinx, right?
(if it was a gating spellcheck I'll be in big trouble :))
On Tue, Jun 26, 2012 at 4:02 PM, Monty Taylor mord...@inaugust.com wrote:
Hey guys!
We have all of the projects properly and consistently building and
uploading sphinx docs from in tree. This is pretty exciting
On 06/28/2012 12:05 PM, Vishvananda Ishaya wrote:
On Jun 28, 2012, at 8:13 AM, Monty Taylor wrote:
Which adds an additional testing environment that has system software
enabled and also installs additional optional things. With that
environment, we should be able to run a jenkins gate
Hey all!
Using quantum as a little bit of a guinea pig, we've been poking at
setuptools-git, which is a setuptools plugin which adds git vcs support
to setuptools. Why would we care? Well, setuptools itself has baked in
support for cvs and svn (yay! such future thought!) One of the nice bits
is
On 06/28/2012 01:49 PM, Dan Prince wrote:
- Original Message -
From: Monty Taylor mord...@inaugust.com To:
openstack@lists.launchpad.net Sent: Thursday, June 28, 2012
11:13:28 AM Subject: Re: [Openstack] Jenkins vs SmokeStack tests
Gerrit merge blockers
On 06/28/2012 07
Hey guys!
We have all of the projects properly and consistently building and
uploading sphinx docs from in tree. This is pretty exciting, because it
means one more resource we can expect to work.
So related to that, we were talking about putting in a gating job for
each project to prevent
Hi!
On 06/19/2012 09:43 AM, Alexey Ababilov wrote:
Hi!
Unfortunately, nova, keystone, and glance clients are very inconsistent.
A lot of code is copied between all these clients instead of moving it
to a common library. The code was edited without synchronization between
clients, so, they
We're trying to figure out how we release client libraries. We're really
close - but there are some sticking points.
First of all, things that don't really have dissent (with reasoning)
- We should release client libs to PyPI
Client libs are for use in other python things, so they should be
to manage it the same way.
On Mon, Jun 18, 2012 at 5:11 PM, Monty Taylor mord...@inaugust.com
mailto:mord...@inaugust.com wrote:
We're trying to figure out how we release client libraries. We're really
close - but there are some sticking points.
First of all, things that don't really
-versioning here:
https://review.openstack.org/#/c/8427/
We need to get (aiui) one thing landed to zuul so that we can
appropriately trigger on tag events... but that's the plan in my brain hole.
On Jun 18, 2012, at 2:11 PM, Monty Taylor wrote:
We're trying to figure out how we release client
We're trying to figure out how we release client libraries. We're really
close - but there are some sticking points.
First of all, things that don't really have dissent (with reasoning)
- We should release client libs to PyPI
Client libs are for use in other python things, so they should be
On 06/13/2012 10:58 AM, Juan J. Martinez wrote:
On 13/06/12 15:42, Dan Prince wrote:
Okay. It looks like Swift also still depends on swiftclient. Long term it
would be nice if we could build and unit test swift without relying on the
swiftclient package. Could we:
I can't see the
On 06/11/2012 12:04 PM, John Garbutt wrote:
Hi,
I am trying to run tests like test_xenapi and test_libvirt by themselves
do things like:
nosetests test_xenapi
But it does work, I get DB errors relating to missing tables. However, I can
successfully run all the tests.
The way I
On 06/11/2012 07:06 PM, Gabriel Hurley wrote:
I just thought I'd call out that Glance's swift storage module is
currently broken, and apparently this escaped the devstack gate even
though devstack actually fails to complete if swift is enabled. Are
we not testing with swift in the
Hey guys!
We just upgraded to a new version of gerrit. This is based on the new
upstream version 2.4, but in addition we've landed two additional
features on top of that - so there's tons of new toys to play with.
First of all, in 2.4 upstream has added a new button Rebase Change ...
which you
Hey guys!
In a fit of things coming together... today has been an unnaturally good
and productive day for us, so I thought I'd mention a bunch of stuff
(most things long-in-work and just sort of came together nicely today)
- builders are now updated to run precise - except for the python2.6
On 06/05/2012 07:54 AM, Gary Kotton wrote:
Hi Monty and Dan,
Background: A short while ago I started to port bug fixes for Quantum
from Folsom-1 to Stable Essex. Jenkins did not accept the patches due to
the fact that the automatic tests did not pass. The failures are due to
2 reasons:
1.
Hey guys!
One of the things that came out of ODS is the idea of having a single
global dependency list. There are two bits to that - the mechanics of
managing the list (which I think we may have sorted) and then, you know,
making the list. In compiling the list of what the current global list
is,
On 05/28/2012 04:32 PM, Paul Belanger wrote:
On 12-05-25 03:58 PM, Monty Taylor wrote:
Hey guys!
We just finished rolling out the first in a sequence of upcoming changes
to gerrit and jenkins based on needs described at the design summit.
We now have the basic jobs for all of the projects
Hey guys!
We just finished rolling out the first in a sequence of upcoming changes
to gerrit and jenkins based on needs described at the design summit.
We now have the basic jobs for all of the projects (except for horizon,
because it's slightly different and I want to spend a little more time
On 05/08/2012 09:56 PM, Thierry Carrez wrote:
Gabriel Hurley wrote:
Having worked with all three tools, I would strongly suggest Transifex,
particularly given that we as a community have to do almost no work to
maintain it, it's the only tool that supports OpenStack as a project hub
with
Honestly, I think we might want to delete write_requirements()
altogether. I don't think it's beneficial... asign this to me and I'll
get it fixed up.
On 05/04/2012 11:30 AM, Mark McLoughlin wrote:
Could do with more details here, I'm not sure I follow what the issue is
** Changed in:
On 05/03/2012 05:24 AM, Thierry Carrez wrote:
(snip things I pretty much agree with)
(I'm not sure gerrit is right for this. Why not just do it in
folk's github forks? I think all people are looking for is for
people to be more aware of feature branches. How about if you put
On 05/03/2012 08:50 AM, Mark McLoughlin wrote:
On Thu, 2012-05-03 at 16:46 +0100, Mark McLoughlin wrote:
Hey,
On Thu, 2012-05-03 at 14:24 +0200, Thierry Carrez wrote:
Mark McLoughlin wrote:
And how about feature branches?
- Feature branches are relatively short-lived (i.e. weeks or
On 04/27/2012 06:11 AM, Jim Meyering wrote:
Daniel P. Berrange wrote:
On Fri, Apr 27, 2012 at 12:04:34PM +0200, Thierry Carrez wrote:
To avoid Launchpad list slowness, we would run the new openstack-dev
list off lists.openstack.org. Given the potential hassle of dealing with
spam and
Hey everyone!
On 04/27/2012 05:04 AM, Thierry Carrez wrote:
To avoid Launchpad list slowness, we would run the new openstack-dev
list off lists.openstack.org. Given the potential hassle of dealing with
spam and delivery issues on mission-critical MLs, we are looking into
the possibility of
On 04/27/2012 09:44 AM, Duncan McGreggor wrote:
On Fri, Apr 27, 2012 at 8:46 AM, Monty Taylor mord...@inaugust.com wrote:
Hey everyone!
On 04/27/2012 05:04 AM, Thierry Carrez wrote:
To avoid Launchpad list slowness, we would run the new openstack-dev
list off lists.openstack.org. Given
Hey!
On 04/27/2012 06:20 PM, Loic Dachary wrote:
Hi,
I would like to create a repository ceilometer in
https://github.com/stackforge to host the code for the newborn Metering
project ( https://launchpad.net/ceilometer , first meeting held this thursday
Hey guys,
Quick follow up from the summit on things that should happen in projects
from the setup module of openstack common as I understand it. (to make
sure we're all on the same page)
There are currently 5 essential things in openstack.common.setup:
parse_requirements
parse_dependency_links
On 04/26/2012 10:14 AM, Sean Dague wrote:
On 04/25/2012 05:17 PM, Vishvananda Ishaya wrote:
The main issue is when the relevant tables are moved into a separate
service a la quantum or cinder. We can't keep referential integrity
across multiple databases, so the foreign keys in this case
On 04/24/2012 10:08 PM, Lorin Hochstein wrote:
On Apr 24, 2012, at 4:11 PM, Joe Gordon wrote:
Hi All,
I would like to propose a minimum required code coverage level per
file in Nova. Say 80%. This would mean that any new feature/file
should only be accepted if it has over 80% code
Barbara wrote:
If you let me know in a bit more detail what you're looking for, I can
probably whip something up. Email me direct?
Justin
On Wed, Apr 25, 2012 at 6:59 AM, Monty Taylor mord...@inaugust.com
mailto:mord...@inaugust.com wrote:
On 04/24/2012 10:08 PM, Lorin
I agree with Mark. In my world, all options should have sane defaults.
--
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/983734
Title:
Keystone fails badly if you miss one
On 04/13/2012 04:36 AM, Kiall Mac Innes wrote:
The new gerrit version also supports per user namespaces, if enabled.
These allow users to create private branches with full push privileges etc..
Have these been enabled?
They have not - we need to verify what the behavior looks like over
It should Just Workâ˘
On 04/11/2012 02:29 PM, Vishvananda Ishaya wrote:
Yay! Awesome work Dean!
Monty/Jim: Has the ci infrastructure been updated to use the stable/essex
branch for integration tests on the stable/essex merges?
Vish
On Apr 11, 2012, at 1:57 PM, Dean Troyer wrote:
The
On 04/09/2012 04:11 PM, Jay Pipes wrote:
On 04/09/2012 07:07 PM, Jorge Williams wrote:
On Apr 9, 2012, at 6:03 PM, Justin Santa Barbara wrote:
How about we discuss this further at the summit :-)
I think that's a sensible proposal. We're not likely to reach a good
conclusion here. I
Hi!
jclouds is an open source java library for connecting to clouds. As
such, it supports connecting to OpenStack based clouds. The OpenStack CI
team have been working with jclouds on both support for OpenStack as
well as a plugin for jenkins so that we can have more direct control of
build
- but you know - face to
face about this stuff often winds up being super-big win.
Yay for Open Source!
Monty
On Sun, Apr 8, 2012 at 6:37 PM, Monty Taylor mord...@inaugust.com
mailto:mord...@inaugust.com wrote:
Hi!
jclouds is an open source java library for connecting to clouds
8, 2012 at 6:37 PM, Monty Taylor mord...@inaugust.com
mailto:mord...@inaugust.com wrote:
Hi!
jclouds is an open source java library for connecting to clouds. As
such, it supports connecting to OpenStack based clouds. The
OpenStack CI
team have
On 04/05/2012 01:22 AM, Justin Santa Barbara wrote:
I've got Compute functionality working with the OpenStack Jenkins
plugin, so it can launch nova instances as on-demand slaves now, run
builds on them, and archive the results into swift. I'd like to open
GitHub issues to track your
1 - 100 of 201 matches
Mail list logo
