an experimental job.
- document clearly in the release notes the versions of dependancies
that we tested against in a given release: hypervisor versions (gate
and third party), etc etc
Sure, that sounds like a good thing to document in release notes.
--
Russell Bryant
on is a separate thing. You're
targeting coverage for a specific set of use cases, while this is a
flavor of the general CI coverage we're already doing, but with the
latest (not pegged) libvirt (and maybe qemu).
By all means, more testing is useful though.
--
Russell Bryant
happening, that would just clearly express that this is not
ready to land for release cycle / organizational reasons.
Thoughts?
That sounds much nicer than using code review -2.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev
itself.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 08/08/2014 09:06 AM, Russell Bryant wrote:
- instead implement a third party CI with the latest available
libvirt release [1]
As for the general idea of doing CI, absolutely. That was discussed
earlier in the thread, though nobody has picked up the ball yet. I can
work on it, though
participation in the development of a
solution if it's an important requirement. Until then, it feels like a
case of an open question of what do you want. Of course the answer is
a pony.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev
on downloading the source on every run.
IIRC, we can have nodepool build an image to use for these jobs that
includes the bits already installed.
I'll switch my efforts over to helping get the above completed.
--
Russell Bryant
___
OpenStack-dev mailing list
On 08/09/2014 12:33 PM, Jeremy Stanley wrote:
On 2014-08-08 09:06:29 -0400 (-0400), Russell Bryant wrote:
[...]
We've seen several times that building and maintaining 3rd party
CI is a *lot* of work.
Building and maintaining *any* CI is a *lot* of work, not the least
of which
On 08/11/2014 07:58 AM, Russell Bryant wrote:
On 08/11/2014 05:53 AM, Daniel P. Berrange wrote:
There is work to add support for this in devestack already which I
prefer since it makes it easy for developers to get an environment
which matches the build system:
https://review.openstack.org
On 08/11/2014 08:01 AM, Daniel P. Berrange wrote:
On Mon, Aug 11, 2014 at 07:58:41AM -0400, Russell Bryant wrote:
On 08/11/2014 05:53 AM, Daniel P. Berrange wrote:
There is work to add support for this in devestack already which I
prefer since it makes it easy for developers to get
On 08/11/2014 09:17 AM, Jeremy Stanley wrote:
On 2014-08-11 08:04:34 -0400 (-0400), Russell Bryant wrote:
Dang, I'd love to see those numbers. :-)
Me too. Now that I'm not travelling I'll see if I can find out what
he meant by that.
Understood. Some questions ... is building an image
.
That has been my interpretation and approach as well: we strongly prefer
functional testing for everything, but take a pragmatic approach and
evaluate proposals on a case by case basis. It's clear we need to be a
bit more explicit here.
--
Russell Bryant
think we're expecting the
procedure to be:
https://etherpad.openstack.org/p/nova-retrospective-veto-revert-policy
If it sounds reasonably sane, I can propose its addition to the
Development policies doc.
Looks reasonable to me.
--
Russell Bryant
On 08/12/2014 03:40 PM, Kashyap Chamarthy wrote:
On Mon, Aug 11, 2014 at 08:05:26AM -0400, Russell Bryant wrote:
On 08/11/2014 07:58 AM, Russell Bryant wrote:
On 08/11/2014 05:53 AM, Daniel P. Berrange wrote:
There is work to add support for this in devestack already which I
prefer since
.
In general I would like to think we can all just put on our big boy pants and
talk through contentious issues to find a resolution that everyone can live
with.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
new critera reaches consensus, it should be added there.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
within that 100 is certainly still a good thing.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
for the mid-cycle stuff and save the in-person
meetings for the existing twice-per-year summits.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
if not to the group as a
whole.
That sort of approach still sounds like an improvement to what we have
today, which is alack of good priority communication to direct general
review time.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
to
the list for discussion before decisions are made. That's not the way
things are trending here, and I think that's a problem.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman
On 08/13/2014 02:33 PM, Dan Smith wrote:
On 8/13/14 11:20 AM, Mike Bayer wrote:
On Aug 13, 2014, at 1:44 PM, Russell Bryant rbry...@redhat.com
wrote:
I disagree. IMO, *expecting* people to travel, potentially across
the globe, 4 times a year is an unreasonable expectation, and
quite
On 08/13/2014 04:01 PM, Doug Hellmann wrote:
On Aug 13, 2014, at 9:11 AM, Russell Bryant rbry...@redhat.com wrote:
On 08/13/2014 08:52 AM, Mark McLoughlin wrote:
On Tue, 2014-08-12 at 14:26 -0400, Eoghan Glynn wrote:
It seems like this is exactly what the slots give us, though. The core
On 08/13/2014 02:44 PM, Russell Bryant wrote:
On 08/13/2014 02:33 PM, Dan Smith wrote:
On 8/13/14 11:20 AM, Mike Bayer wrote:
On Aug 13, 2014, at 1:44 PM, Russell Bryant rbry...@redhat.com
wrote:
I disagree. IMO, *expecting* people to travel, potentially across
the globe, 4 times a year
. (You may need to
force-reload in your browser to see the change.)
Beautiful! Thank you so much to everyone involved.
+1! Love this.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
On 08/13/2014 07:27 PM, Michael Still wrote:
On Thu, Aug 14, 2014 at 3:44 AM, Russell Bryant rbry...@redhat.com wrote:
On 08/13/2014 01:09 PM, Dan Smith wrote:
Expecting cores to be at these sorts of things seems pretty reasonable
to me, given the usefulness (and gravity) of the discussions
:
https://wiki.openstack.org/wiki/Infrastructure/Conferencing
In theory it even supports basic video conferencing, though I haven't
tested it on this server yet.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
the Icehouse meetup is here:
http://lists.openstack.org/pipermail/openstack-dev/2014-February/027370.html
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
compatible with your system?
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
, as well as keep up talks they are giving, or even customer
meetings.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
, yeah... +10 :)
^2 :-)
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
to mean OpenStack. This is confusing and also incorrect[0].
...
I have seen OS for OpenStack from the start. Just look at the
environment variables that the CLI reads.
Yep, it's quite common and I think it's fine in the right context.
--
Russell Bryant
itself, the OpenStack
community, dev processes, tools, etc this has got to be extremely
far down the list of barriers to entry.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman
.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 08/15/2014 02:53 PM, Russell Bryant wrote:
On 08/15/2014 02:45 PM, Eric Windisch wrote:
I have proposed a _silent_ check for Nova for integration of the Docker
driver:
https://review.openstack.org/#/c/114547/
It has been established that this code cannot move back into Nova until
teapot
in tempest in tcup ... and that just gets confusing. :-)
[1] https://wiki.openstack.org/wiki/RefStack/TCup
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
out of the
current Tempest repository, into their own repo called
openstack-integration-tests or os-integration-tests.
Ooh, I like that idea! +1
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
On 08/18/2014 06:18 AM, Thierry Carrez wrote:
Doug Hellmann wrote:
On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@redhat.com wrote:
Let me try to say it another way. You seemed to say that it wasn't much
to ask given the rate at which things happen in OpenStack. I would
argue
.
It also addresses my primary concerns with the tensions between group
will and small groups no longer being able to self organize and push
things to completion without having to haggle through yet another process.
--
Russell Bryant
___
OpenStack-dev
. Having someone who
understands infra and QA quite well and is regularly on top of the
status of the project in the gate is helpful and quite important.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
On 08/22/2014 09:40 AM, Russell Bryant wrote:
Another area worth calling out is a gate czar. Having someone who
understands infra and QA quite well and is regularly on top of the
status of the project in the gate is helpful and quite important.
Oops, you said this one, too. Anyway, +1
.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
, remove is straight forward, but seems a bit odd to have without
add. I'm not sure there's much value to it.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
alternative proposals that would make a
better use of our 4 days, let me know.
+1 on the format. I think it sounds like a nice iteration on our setup
to try some new ideas.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
in a dynamic list.
Good point.
(*) we are getting rid of this conditional migration logic for juno anyway
Yay!
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
thus far.
I don't think we can afford to wait much longer without drastic change,
so let's make it happen.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
that the scheduler split is a non-starter without
stabilizing all of the relevant interfaces. I hope there's not much debate on
that high level point. Of course, identifying exactly what those interfaces
should be a bit more complicated, but I hope the focus can stay there.
--
Russell Bryant
as an obvious key pre-requisite to a split, and this cleanup
is what should be treated with urgency by those with a vested interest
in getting more autonomy around scheduler development.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev
on trust in a -core team member
judgement call.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
.
In summary, +1 to moving forward without the API proxy requirement.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
, figuring out what went wrong
when OpenStack breaks sucks. Others provided some good pointers to
several areas we can improve that area (better logs, tooling, ...) and I
hope we can make some real progress in this area in the coming cycle.
--
Russell Bryant
On Sep 10, 2014, at 2:03 PM, Joe Cropper cropper@gmail.com wrote:
I agree, Chris. I think a number of folks put in a lot of really great work
into the existing server groups and there has been a lot of interest on their
usage, especially given that the scheduler already has some
. It does policy
checking in the scheduler, and then has to re-do some policy checking at
launch time on the compute node. I'm afraid of making this any worse.
In any case, it's probably better to discuss this in the context of a
more detailed design proposal.
--
Russell Bryant
not
be in favor of a Juno branch with features that haven't landed in master.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
notice about
this once Kilo opens up.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
://lists.openstack.org/pipermail/openstack-dev/2014-August/044431.html
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 09/11/2014 05:01 PM, Jay Pipes wrote:
On 09/11/2014 04:51 PM, Matt Riedemann wrote:
On 9/10/2014 6:00 PM, Russell Bryant wrote:
On 09/10/2014 06:46 PM, Joe Cropper wrote:
Hmm, not sure I follow the concern, Russell. How is that any different
from putting a VM into the group when it’s
they have
a harder time submitting a session.
Once this is settled, as long as the wiki pages [1][2] reflect the
process and is publicized, it should be fine.
[1] https://wiki.openstack.org/wiki/Summit
[2] https://wiki.openstack.org/wiki/Summit/Planning
--
Russell Bryant
it clear that they were not completed.
There's a ton of useful info in them. Even if they get re-proposed,
it's still useful to see the difference in the proposal as it evolved
between releases.
--
Russell Bryant
___
OpenStack-dev mailing list
problems as a priority. I tried to avoid
getting into my concerns about testing in my mail on review team bottlenecks
since I think we should address the problems independantly / in parallel.
Agreed with this. I don't think we can afford to ignore either one of them.
--
Russell Bryant
On 09/17/2014 11:47 AM, Alex Leonhardt wrote:
hi,
how does one re-open a abandoned change / pull request ? it just timed
out and was then abandoned -
https://review.openstack.org/#/c/57834/
please let me know
I re-opened it. You should be able to update it now.
--
Russell Bryant
-upload the change, maintaining the same Change-Id line in the
commit message.
Gerrit will reject it if it's still abandoned. You have to restore it
first.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
on a host today. That's likely an enhancement
we could make to python-novaclient, similar to the evacuate all
instances on a host enhancement that was done in novaclient.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
a traditional message broker (qpidd or rabbitmq) ?
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 12/09/2013 05:16 PM, Gordon Sim wrote:
On 12/09/2013 07:15 PM, Russell Bryant wrote:
On 12/09/2013 12:56 PM, Gordon Sim wrote:
In the case of Nova (and others that followed Nova's messaging
patterns), I firmly believe that for scaling reasons, we need to move
toward it becoming the norm
to see what kind of support there is for this. We
really need clear support for it being in the tree before accepting the
ongoing maintenance and review burden.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
to think it over.
So ... if you really do feel that way, I'm not sure it makes a lot of
sense to merge it one way if there's already a plan emerging to re-do
it. We'd have to go through a painful deprecation cycle of the old code
where we're maintaining it in two places for a while.
--
Russell
... there isn't an existing example for you follow exactly,
so it's not obvious.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
/nova/+milestone/icehouse-2
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
as
it is a real life application\service.
There is a question to QA\Tempest teams, what do you think about using
pecan test framework in tempest for Pecan based applications?
I don't think that makes sense. Then we're not using the code like it
would be used normally (via HTTP).
--
Russell Bryant
important review contributions, but aren't necessarily
reviewing regularly enough to be whatever-core.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
, rather than as bugs after-the-fact. Would we rather have a -1
on a code review than a CVE?
This has been discussed quite a bit. We can't handle security patches
on gerrit right now while they are embargoed because we can't completely
hide them.
--
Russell Bryant
happen, let's talk about it.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
that generates a list of patches still
open that were previously approved:
http://russellbryant.net/openstack-stats/nova-openapproved.txt
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi
and decide whether I want to dive in and read the
rest. It happens very quickly, but that's roughly my thought process.
With whatever is left over: mark all as read. :-)
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
on
startup until nova-conductor is responding if they happened to be
brought up at the same time.
We could do something like this with a networking sanity check if
someone could define what that check should look like.
--
Russell Bryant
___
OpenStack-dev
/BugTags
3) Update https://wiki.openstack.org/wiki/Nova/BugTriage
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
scheduling because neutron has no network segment to
bind to. That is because the L2 agent on the host has not yet registered
itself with Neutron.
but not this one.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
other bugs as test cases and
confirmation:
https://bugs.launchpad.net/nova/+bug/1260440
Sounds good. I'm happy to do this in Nova, but we'll have to get the
Neutron API bit sorted out first.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack
, if you think an overhaul of the process is
necessary to get to the end goal of a more well triaged bug queue, then
I'm happy to entertain it.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org
-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
?
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
the status
of nova-network after the release of icehouse-2.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
and discuss.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
been a few messages on that thread this month, too.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
for glance image properties. Basically think of it as
a way to custom any image property per instance created.
That's a pretty nice idea. I like it.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
as the other engines.
Yeah, having instance.uuid nullable doesn't seem valuable to me, so this
seems OK.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
if they are
able.
Comments welcome, especially some acknowledgement that there are people
that would attend the alternate meeting time. :-)
Thanks,
[1] https://wiki.openstack.org/wiki/Meetings/Nova
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack
for notifications. We've had a
blueprint open for about a year, but AFAICT, nobody is actively working
on it.
https://blueprints.launchpad.net/nova/+spec/versioned-notifications
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev
the same bug that hasn't looked at the patch.
From a quick look, it seems likely that this fix is small and straight
forward enough that the clean new implementation is going to end up
looking very similar. Still, I think it's the right thing to do.
--
Russell Bryant
compatibility code each
release cycle.
Once we get the details worked out, I'd like to capture the process on
the release checklist wiki page for Nova.
https://wiki.openstack.org/wiki/Nova/ReleaseChecklist
Thoughts?
--
Russell Bryant
___
OpenStack-dev
No Nova meeting this week. We will resume on Thursday, January 2, at
21:00 UTC.
https://wiki.openstack.org/wiki/Meetings/Nova
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
urlresolvers importable without
the need for the #noqa tag.
Of course every project can add their own names there, depending what
they need.
Isn't that what import_exceptions is for? For example, we have this
in nova:
import_exceptions = nova.openstack.common.gettextutils._
--
Russell Bryant
On 01/03/2014 10:35 AM, Radomir Dopieralski wrote:
On 03/01/14 16:18, Russell Bryant wrote:
On 01/03/2014 10:10 AM, Radomir Dopieralski wrote:
I think that we can actually do a little bit better and remove many of
the #noqa tags without forfeiting automatic checking. I submitted a
patch
of making the thing run yet.
4) Is the aim of Gantt to provide a RESTful HTTP API in addition
to the RPC-based API that the existing Nova scheduler exposes?
In the short term the plan is to just replicate the rpc api, but I
think a REST api will be considered long term.
Yep.
--
Russell
it against the current scheduler and then we'll port it
over. I don't think we should do major work only in gantt until we're
ready to deprecate the current scheduler.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
) will have to wait. This is to make the transition as quick as
possible.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
migrations.
1) The VM state can be either ACTIVE and STOPPED for a resize operation
2) The VM state must be STOPPED for a cold migrate operation.
I'm not sure why would require different states here, though. ACTIVE
and STOPPED are allowed now.
--
Russell Bryant
state must be STOPPED for a cold migrate operation.
We just stop the VM them perform the migration.
I don't think we need to require its stopped first.
Am I missing something?
Don't think so ... I think we should leave it as is.
--
Russell Bryant
as possible
that they'll both directly participate in the day, as well as encourage
the rest of their project to do the same.
I'm in!
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman
-gate-issue-tracking
Please jump in if you can. We shouldn't wait for the gate bug day to
move on these. Even if others are already looking at a bug, feel free
to do the same. We need multiple sets of eyes on each of these issues.
--
Russell Bryant
1 - 100 of 779 matches
Mail list logo
