the backing network manager is and
the API is inconsistent in that regard, I might have some other hurdles
there but would at least like to get a POC going.
I guess I can do the POC before the question of blueprints/specs needs
to be answered...
[1] https://launchpad.net/b
[0] https://review.openstack.org/#/c/107552/21
On 8 August 2014 15:42, Matt Riedemann mailto:mrie...@linux.vnet.ibm.com>> wrote:
This came up while reviewing the fix for bug 1327406 [1]. Basically
the os-networks API behaves differently depending on your backing
network mana
an/listinfo/openstack-dev
Just thinking out loud, you could do something like a 2/3 majority vote
on the issue but that sounds too much like government, which is
generally terrible.
Otherwise maybe the PTL is the tie-breaker?
--
Thanks,
Matt Riedemann
s
going. You could argue for example that our failure to land many high
priority blueprints in Juno is because cores aren't acting in
coordinated a manner. So, we're attempting to come up with ways to
improve coordination.
Having mid-cycle meetups where only a subset of cores will a
t seeing the hits in logstash for some reason, which is odd.
[1] https://bugs.launchpad.net/keystone/+bug/1357652
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 8/17/2014 11:30 AM, Nathan Kinder wrote:
On 08/17/2014 09:18 AM, Nathan Kinder wrote:
On 08/17/2014 09:08 AM, Matt Riedemann wrote:
I'm seeing some nova stable/havana patches failing consistently on
keystone bug 1357652 [1], keystone won't start due to an import error.
I&#x
On 8/17/2014 3:36 PM, Alan Pevec wrote:
2014-08-17 22:25 GMT+02:00 Matt Riedemann :
The other thing I thought was we could cap the version of
python-keystoneclient in stable/havana, would that be bad? stable/havana is
going to be end of life pretty soon anyway.
No, we had cap on some
ght because the new flags being used aren't
defined in fakelibvirt:
https://github.com/openstack/nova/commit/26504d71ceaecf22f135d8321769db801290c405
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@list
stopping us from just removing fakelibvirt since
it's kind of useless now anyway, right?
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
rds/important-changes:review-inbox-dashboard
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
If you revert the change to require libvirt-python and try to run the
unit tests, it fails, see bug 1357437 [1].
[1] https://bugs.launchpad.net/nova/+bug/1357437
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 8/21/2014 11:37 AM, Clark Boylan wrote:
On Thu, Aug 21, 2014, at 09:25 AM, Matt Riedemann wrote:
On 8/21/2014 10:23 AM, Daniel P. Berrange wrote:
On Thu, Aug 21, 2014 at 11:14:33AM -0400, Solly Ross wrote:
(reply inline)
- Original Message -
From: "Daniel P. Berrange
On 8/21/2014 12:26 PM, Daniel P. Berrange wrote:
On Thu, Aug 21, 2014 at 12:23:12PM -0500, Matt Riedemann wrote:
On 8/21/2014 11:37 AM, Clark Boylan wrote:
On Thu, Aug 21, 2014, at 09:25 AM, Matt Riedemann wrote:
On 8/21/2014 10:23 AM, Daniel P. Berrange wrote:
On Thu, Aug 21, 2014
responsible for that in all projects affected, it
doesn't scale.
Maybe next time something like this comes up we get the PTLs to be the
ones assigning a person (Clark's Infra Czar?!?!) responsible for
coordinating these types of changes so they are ready.
--
Thanks,
Matt Riedemann
y Jones has a nice page created for Nova [1].
[1] http://54.201.139.117/nova-bugs.html
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
"Open reviews" section in the elastic-recheck status
page now:
http://status.openstack.org/elastic-recheck/
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
st replace with what generate_sample provides).
I think the docs team is also interested in seeing this happen...
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
e library.
9/4 and feature freeze seems like a decent target date.
[1] https://review.openstack.org/#/c/92390/
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
rs of oslo.db(Roman Podoliaka and Victor Sergeyev) are OK
with this.
Joe Gordon and Matt Riedemann are already signing up, so we need one
more vote from Core developer.
By the way a lot of core projects are using already oslo.db for a
while: keystone, cinder, glance, ceilometer, ironic, heat, neutro
ev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
t feeling productive.
But as noted, there is also a feeling right now of focusing on Juno to
get that out the door before anyone starts getting distracted with
reviewing Kilo specs. And I suppose once Juno is finished no one is
going to want to talk about Kilo for awhile due to burnout.
g/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Regards,
Daniel
Even if we split the virt drivers out, libvirt would still be the
default in the Tempest gate runs right?
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
t a
string and not a message?
Maybe I should just shut-up and email the openstack-i18n mailing list [2].
[1] https://review.openstack.org/#/c/118535/
[2] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
--
Thanks,
Matt Riedemann
__
On 8/29/2014 1:53 PM, Kyle Mestery wrote:
On Fri, Aug 29, 2014 at 1:40 PM, Matt Riedemann
wrote:
On 7/29/2014 4:12 PM, Kyle Mestery wrote:
On Tue, Jul 29, 2014 at 3:50 PM, Nader Lahouti
wrote:
Hi Kyle,
I have a BP listed in
https://blueprints.launchpad.net/python-neutronclient
and
pike-with-a-bash-command
--
John Schwarz,
Software Engineer, Red Hat.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Thanks, that might be what's causing this timeout/gate failure in the
nova unit tests
I think we're in dependency freeze or quickly approaching. What are the
plans from the Cinder team for doing a python-cinderclient release to
pick up any final features before Juno rc1?
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing
g/cgi-bin/mailman/listinfo/openstack-dev
Yeah the IBM DB2 third party CI is run from a team in China and they've
been blocked for a few weeks now.
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstac
org/pypi/python-memcached/
[6]
https://github.com/openstack/requirements/blob/master/global-requirements.txt#L108
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
27;ve been pinging a few projects
to do a final client release relatively soon. python-neutronclient has
a release this week and I think John was planning a python-cinderclient
release this week also.
--
Thanks,
Matt Riedemann
___
OpenStack-dev ma
n proposal.
This [1] is the hack you're referring to right?
[1]
http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/manager.py?id=2014.2.b3#n1297
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.ope
On 9/10/2014 11:08 AM, Kyle Mestery wrote:
On Wed, Sep 10, 2014 at 10:01 AM, Matt Riedemann
wrote:
On 9/9/2014 4:19 PM, Sean Dague wrote:
As we try to stabilize OpenStack Juno, many server projects need to get
out final client releases that expose new features of their servers.
While
lient? Are there plans to remove that?
I don't really care either way, but need to know for code reviews.
One example: [1]
[1] https://review.openstack.org/#/c/108942/
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
Ope
rg
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I'm not great with UIs either but would a dropdown of the affected
projects be helpful and then people can filter on their "favorite"
project and then the page is sorted by top offenders as we h
On 9/15/2014 12:57 PM, Matt Riedemann wrote:
On 9/10/2014 11:08 AM, Kyle Mestery wrote:
On Wed, Sep 10, 2014 at 10:01 AM, Matt Riedemann
wrote:
On 9/9/2014 4:19 PM, Sean Dague wrote:
As we try to stabilize OpenStack Juno, many server projects need to get
out final client releases that
e, I'm not sure how much of a factor that would have here.
Is there anything else unique about those jobs from the MySQL ones?
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack
On 9/18/2014 5:49 AM, Sean Dague wrote:
On 09/17/2014 11:50 PM, Clark Boylan wrote:
On Wed, Sep 17, 2014, at 06:48 PM, Clark Boylan wrote:
On Wed, Sep 17, 2014, at 06:37 PM, Matt Riedemann wrote:
On 9/17/2014 7:59 PM, Ian Wienand wrote:
On 09/18/2014 09:49 AM, Clark Boylan wrote:
Recent
up this same point in Icehouse, they were really
limited due to the eventlet workers issue in Keystone and once we
provided the option (backported) it increased their throughput by 20%.
We've been running with that in our internal Tempest runs (setting
workers equal to number of CPUs /
I came across this bug [1] in triage today and I thought this was fixed
already [2] but either something regressed or there is more to do here.
I'm mostly just wondering, are operators already running any kind of
script which purges old instance_faults table records before an instance
is delet
On 11/1/2018 7:22 PM, Kendall Nelson wrote:
We've made a lot of progress in StoryBoard-land over the last couple of
releases cleaning up bugs, fixing UI annoyances, and adding features
that people have requested. All along we've also continued to migrate
projects as they've become unblocked. Wh
On 11/2/2018 2:22 PM, Eric Fried wrote:
Based on a (long) discussion yesterday [1] I have put up a patch [2]
whereby you can set [compute]resource_provider_association_refresh to
zero and the resource tracker will never* refresh the report client's
provider cache. Philosophically, we're removing
On 11/4/2018 4:22 AM, Mohammed Naser wrote:
Just for information sake, a clean state cloud which had no reported issues
over maybe a period of 2-3 months already has 4 allocations which are
incorrect and 12 allocations pointing to the wrong resource provider, so I
think this comes does to committ
On 11/5/2018 5:52 AM, Chris Dent wrote:
* We need to have further discussion and investigation on
allocations getting out of sync. Volunteers?
This is something I've already spent a lot of time on with the
heal_allocations CLI, and have already started asking mnaser questions
about this el
There is not much news this week. There are several open changes which
add the base command framework to projects [1]. Those need reviews from
the related core teams. gmann and I have been trying to go through them
first to make sure they are ready for core review.
There is one neutron change
If you are seeing this error when implementing and running the upgrade
check command in your project:
Traceback (most recent call last):
File
"/home/osboxes/git/searchlight/.tox/venv/lib/python3.5/site-packages/oslo_upgradecheck/upgradecheck.py",
line 184, in main
return conf.command.ac
On 11/4/2018 10:17 PM, Chen CH Ji wrote:
Yes, this has been discussed for long time and If I remember this
correctly seems S PTG also had some discussion on it (maybe public Cloud
WG ? ), Claudiu has been pushing this for several cycles and he actually
had some code at [1] but no additional pro
On 11/2/2018 3:47 AM, Andreas Scheuring wrote:
Dear Nova Community,
I want to announce the new focal point for Nova s390x libvirt/kvm.
Please welcome "Cathy Zhang” to the Nova team. She and her team will be
responsible for maintaining the s390x libvirt/kvm Thirdparty CI [1] and any s390x
spec
This is a follow up to a dev ML email [1] where I noticed that some
implementations of the upgrade-checkers goal were failing because some
projects still use the oslo_i18n.enable_lazy() hook for lazy log message
translation (and maybe API responses?).
The very old blueprints related to this ca
On 11/5/2018 12:28 PM, Mohammed Naser wrote:
Have you dug into any of the operations around these instances to
determine what might have gone wrong? For example, was a live migration
performed recently on these instances and if so, did it fail? How about
evacuations (rebuild from a down host).
T
On 11/5/2018 1:17 PM, Matt Riedemann wrote:
I'm thinking of a case like, resize and instance but rather than
confirm/revert it, the user deletes the instance. That would cleanup the
allocations from the target node but potentially not from the source node.
Well this case is at least n
On 11/5/2018 1:36 PM, Doug Hellmann wrote:
I think the lazy stuff was all about the API responses. The log
translations worked a completely different way.
Yeah maybe. And if so, I came across this in one of the blueprints:
https://etherpad.openstack.org/p/disable-lazy-translation
Which says t
On 11/5/2018 10:43 AM, Matt Riedemann wrote:
If you are seeing this error when implementing and running the upgrade
check command in your project:
Traceback (most recent call last):
File
"/home/osboxes/git/searchlight/.tox/venv/lib/python3.5/site-packages/oslo_upgradecheck/upgradeche
On 11/6/2018 5:24 PM, Rochelle Grober wrote:
Maybe the fastest way to get info would be to turn it off and see where the
code barfs in a long run (to catch as many projects as possible)?
There is zero integration testing for lazy translation, so "turning it
off and seeing what breaks" wouldn'
After hacking on the PoC for awhile [1] I have finally pushed up a spec
[2]. Behold it in all its dark glory!
[1] https://review.openstack.org/#/c/603930/
[2] https://review.openstack.org/#/c/616037/
On 8/22/2018 8:23 PM, Matt Riedemann wrote:
Hi everyone,
I have started an etherpad for
No major updates this week, but there is some decent progress in more
projects getting their framework patch merged [1]. Thanks again to Rajat
and Akhil for their persistent effort. There are more open reviews
available for adding the framework to projects [2]. Some projects, like
cloudkitty [3
On 11/13/2018 4:45 AM, Chen CH Ji wrote:
Got it, this is what I am looking for .. thank you
Regarding that you can do with server create, I believe it's:
1. don't specify anything for networking, you get a port on the network
available to you; if there are multiple networks, it's a failure an
On 11/18/2018 6:51 AM, Alex Xu wrote:
Sounds make sense to me, and then we needn't fix this strange behaviour
also https://review.openstack.org/#/c/409644/
The same discussion was had in the spec for that change:
https://review.openstack.org/#/c/511825/
Ultimately it amounted to a big "meh, l
On 11/19/2018 3:17 AM, melanie witt wrote:
- Not directly related to the session, but CERN (hallway track) and
NeCTAR (dev ML) have both given feedback and asked that the
policy-driven idea for handling quota for down cells be avoided. Revived
the "propose counting quota in placement" spec to s
On 11/19/2018 9:32 PM, Rambo wrote:
I have an idea.Now we can't filter the special flavor according
to the property.Can we achieve it?If we achieved this,we can filter the
flavor according the property's key and value to filter the flavor. What
do you think of the idea?Can you tell me mo
ou
should go to the general mailing list:
https://wiki.openstack.org/wiki/Mailing_Lists#General_List
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
how to handle processing the result, but it's not ideal.
Does your solution take into account the nova virtapi's get_diagnostics
method?
[1]
http://lists.openstack.org/pipermail/openstack-dev/2013-October/016385.html
[2] https://review.openstack.org/#/c/51404/
--
Thanks,
Matt Riedeman
), so sending out a recap that everyone
can see in the mailing list is helpful to reset where things are at and
focus possibly various isolated investigations (as we saw happen this
week).
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
Ope
ystem
state alternative to that provided by OpenStack APIs.
May be we should reconsider our naming to avoid confusion and call
this Instrumentation API or something like that?
--
Best regards,
Oleg Gelbukh
On Wed, Nov 20, 2013 at 6:45 PM, Matt Riedemann
mailto
ame a problem). I would be
very interested in finding out why this caused a problem.
You can see frequencies for bugs with known signatures at
http://status.openstack.org/elastic-recheck/
Hope this helps.
Clark
___
OpenStack-dev mailing list
OpenSta
i-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I'm joining this thread a bit late but wanted to raise a few points for
cons
On Thursday, November 21, 2013 9:56:41 AM, Matt Riedemann wrote:
On 11/3/2013 5:22 AM, Joe Gordon wrote:
On Nov 1, 2013 6:46 PM, "John Garbutt" mailto:j...@johngarbutt.com>> wrote:
>
> On 29 October 2013 16:11, Eddie Sheffield
mailto:eddie.sheffi...@rackspace.com>
On Friday, November 22, 2013 5:52:17 PM, Russell Bryant wrote:
On 11/22/2013 06:01 PM, Christopher Yeoh wrote:
On Sat, Nov 23, 2013 at 8:33 AM, Matt Riedemann
mailto:mrie...@linux.vnet.ibm.com>> wrote:
...
21:51:42 i just hope that the version discovery mechanism
is
The question is, who wants their name in the box next to that tag for
owning triage?
[1]
https://wiki.openstack.org/wiki/Nova/BugTriage#Step_2:_Triage_Tagged_Bugs
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstac
On Saturday, November 23, 2013 3:28:28 PM, Robert Collins wrote:
Cool; also, if it's not, we should add that as an official tag so that
it type-completes in LP.
On 24 November 2013 10:21, Matt Riedemann wrote:
Going through nova bug triage today I noticed a pretty straight-forward
unt
ou don't have a special
environment variable set). Plus you don't get parallel execution of
the tests.
So I agree with the approach even though it's going to hurt me in the
short-term.
--
Thanks,
Matt Riedemann
___
OpenStack-
nsistent, so if 404 is OK, then I
think the V3 API should make ImageNotFound, FlavorNotFound and
KeypairNotFound return a 404 also.
Thoughts?
[1] https://review.openstack.org/#/c/54202/
[2] https://review.openstack.org/#/c/41863/
--
Thanks,
Matt Riedemann
d to run keystone and ceilometer CLI tests
for a nova virt driver?
If nothing else, I think we could firm up the wording on the wiki a bit
around the requirements and what that means for scope.
[1] https://github.com/openstack/tempest/blob/master/tox.ini#L33
--
Thanks,
Matt Riedemann
___
On Monday, November 25, 2013 4:37:29 PM, Russell Bryant wrote:
On 11/25/2013 05:19 PM, Matt Riedemann wrote:
I'll play devil's advocate here and ask this question before someone
else does. I'm assuming that the requirement of a 'full' tempest run
means running t
ty CI
for the various vendor-specific drivers and plugins, that's a
no-brainer for openstack to scale. I think it will just be very
interesting to see the kinds of results coming out of all of these
disconnected teams come icehouse-3.
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
eneral_List
The openstack-dev list is for development discussion topics.
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
nstack.org/#/c/58665/
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
best
so I'm OK with leaving it at that.
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.o
logging/serviceability standpoint, e.g. info/warning level message vs
debug.
[1] https://bugs.launchpad.net/nova/+bug/1257644
[2] https://review.openstack.org/#/c/52189/
[3] https://review.openstack.org/#/c/56224/
[4] https://bugs.launchpad.net/nova/+bug/1254872
[5] http://www.redhat.com/ar
ck.org/p/KeystoneTestsToTempest
- Brant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I'll ask the super obvious question, why not move the keystoneclient
tests to
orSupportMatrix/DeprecationPlan
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ova/blob/master/nova/compute/flavors.py#L57
(3:12:18 PM) mriedem: would think you could do the same for extra specs
I don't see any specific rules for extra_specs in the API docs or
validation happening in the code.
--
Thanks,
Matt Riedemann
still some objects blueprints in the works.
Here is a big one:
https://blueprints.launchpad.net/nova/+spec/compute-manager-objects
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstac
ndard auditing formats like in
ceilometer which might be related to what you're looking for.
[1]
http://lists.openstack.org/pipermail/openstack-dev/2013-October/016385.html
[2]
https://blueprints.launchpad.net/nova/+spec/support-standard-audit-formats
--
Thanks,
Matt
-bin/mailman/listinfo/openstack-dev
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ail/openstack-dev/2013-November/020280.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2013-November/019931.html
[3] https://wiki.openstack.org/wiki/ElasticRecheck
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.ope
-incubator git repository first. From there you sync the fix into
nova and cinder.
Peter,
FYI: https://wiki.openstack.org/wiki/Oslo#Syncing_Code_from_Incubator
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev
c/source/devref/drivers.rst
I'm also not sure where the cinder team is with 3rd party CI
requiements, but you'll want to at least read this also:
http://lists.openstack.org/pipermail/openstack-dev/2013-July/012557.html
--
Thanks,
Matt Riedemann
/nova/blob/master/nova/network/manager.py#L399
[4]
https://blueprints.launchpad.net/nova/+spec/rpc-major-version-updates-icehouse
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-b
1 at any time if it's the agreed upon solution, but looking for input
first because I don't want to make assumptions about what everyone
thinks here.
[1] https://blueprints.launchpad.net/nova/+spec/db2-database
[2] https://review.openstack.org/#/c/55572/
[3]
https://github.com/opensta
The question came up in this patch [1], how do we deprecate and remove
keys in the notification payload? In this case I need to deprecate and
replace the 'instance_type' key with 'flavor' per the associated blueprint.
[1] https://review.openstack.org/#/c/62430/
--
Tha
On 12/18/2013 9:42 AM, Matt Riedemann wrote:
The question came up in this patch [1], how do we deprecate and remove
keys in the notification payload? In this case I need to deprecate and
replace the 'instance_type' key with 'flavor' per the associated b
should avoid this. If you need the FK, then the pre-req is to make
the target column non-nullable. Think of the instances.uuid column in
nova for example.
Unless anyone has a strong objection to this, I'll update the review
checklist wiki with these items.
[1] https://wiki.openstack.org
, Dec 18, 2013 at 11:27 AM, Matt Riedemann
mailto:mrie...@linux.vnet.ibm.com>> wrote:
I've seen this come up a few times in reviews and was thinking we
should put something in the general review checklist wiki for it [1].
Basically I have three things I'd like to ha
On 12/18/2013 2:11 PM, Dan Prince wrote:
- Original Message -
From: "Matt Riedemann"
To: "OpenStack Development Mailing List (not for usage questions)"
Sent: Wednesday, December 18, 2013 12:27:49 PM
Subject: [openstack-dev] Adding DB migration items
ent within nova that this is the right way
to go before Gary spends a bunch of time on it - and I as the bp
sponsor spend a bunch of time reviewing it. :)
[1] https://wiki.openstack.org/wiki/Nova_VM_Diagnostics
--
Thanks,
Matt Riedemann
___
OpenSta
sentially halting feature development on
the nova baremetal driver I'd hold off on implementing get_diagnostics
there for now.
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-
s of
existing setUp with mox. However, even in the latter case you can
usually use mock after resetting the mox setup via self.mox.ResetAll()
in the new test case(s).
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev
the blurb here also to say 'in IRC' to nix any
confusion about the mailing list.
https://wiki.openstack.org/wiki/ReviewChecklist#Notes_for_Non-Core_Developers
--
Thanks,
Matt Riedemann
___
OpenStack-dev mailing list
OpenStack-dev@list
+2ers awake for the devstack-gate repos.
Chmouel.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
The bug to recheck against is 1263824.
--
Thanks,
Matt Riedemann
tabase changes and it has give me a –1….
Happy new year
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Thanks,
Matt Riedemann
___
1 - 100 of 2325 matches
Mail list logo
