Re: [openstack-dev] [OpenStack][InstanceGroup] metadetails and metadata in instance_group.py

2014-08-11 Thread Dan Smith
As the person who -2'd the review, I'm thankful you raised this issue on the ML, Jay. Much appreciated. The metadetails term isn't being invented in this patch, of course. I originally complained about the difference when this was being added:

Re: [openstack-dev] [nova] Retrospective veto revert policy

2014-08-12 Thread Dan Smith
Looks reasonable to me. +1 --Dan signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][core] Expectations of core reviewers

2014-08-13 Thread Dan Smith
I'm not questioning the value of f2f - I'm questioning the idea of doing f2f meetings sooo many times a year. OpenStack is very much the outlier here among open source projects - the vast majority of projects get along very well with much less f2f time and a far smaller % of their

Re: [openstack-dev] [nova][core] Expectations of core reviewers

2014-08-13 Thread Dan Smith
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 uncharacteristic of open source projects. If we

Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit

2014-08-13 Thread Dan Smith
You may have noticed that this has merged, along with a further change that shows the latest results in a table format. (You may need to force-reload in your browser to see the change.) Friggin. Awesome. Thanks again to Radoslav Gerganov for writing the original change. Thanks to all

Re: [openstack-dev] [nova] Review priorities as we approach juno-3

2014-08-14 Thread Dan Smith
== Move Virt Drivers to use Objects (Juno Work) == I couldn't actually find any code out for review for this one apart from https://review.openstack.org/#/c/94477/, is there more out there? This was an umbrella one to cover a bunch of virt driver objects work done early in the cycle. Much of

Re: [openstack-dev] OS or os are not acronyms for OpenStack

2014-08-15 Thread Dan Smith
OS or os is operating system. I am starting to see some people us OS or os to mean OpenStack. This is confusing and also incorrect[0]. Except in the nova API code, where 'os' means 'openstack'. I too think that policing the use of abbreviations is silly. It's a confusing abbreviation, but

Re: [openstack-dev] Enabling silent Docker tests for Nova?

2014-08-15 Thread Dan Smith
Feature freeze is only a few weeks away (Sept 4). How about we just leave it in experimental until after that big push? That seems pretty reasonable. Joe just proposed dropping a bunch of semi-useless largeops runs. Maybe that leaves room to sneak this in? If the infra team is okay with it,

Re: [openstack-dev] [nova] requesting an FFE for SRIOV

2014-09-04 Thread Dan Smith
The main sr-iov patches have gone through lots of code reviews, manual rebasing, etc. Now we have some critical refactoring work on the existing infra to get it ready. All the code for refactoring and sr-iov is up for review. I've been doing a lot of work on this recently, and plan to see

Re: [openstack-dev] [Nova][FFE] Feature Freeze exception for juno-slaveification

2014-09-05 Thread Dan Smith
All the other patches from this blueprint have merged, the only remaining patch really just needs a +W as it has been extensively reviewed and already approved previously. This may be an easy candidate since Andrew Laski, Jay Pipes and Dan Smith have reviewed and +2'd

Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

2014-09-08 Thread Dan Smith
The last few days have been interesting as I watch FFEs come through. People post explaining their feature, its importance, and the risk associated with it. Three cores sign on for review. All of the ones I've looked at have received active review since being posted. Would it be bonkers to

Re: [openstack-dev] On an API proxy from baremetal to ironic

2014-09-10 Thread Dan Smith
As far as I understand it, though, that's a patch for a read-only mode. It seems bizzare, and possibly dangerous, to proxy read commands, but not write commands. It gives the impression that everything's fine until it's not fine (because someone tried to use an existing script to do a

Re: [openstack-dev] On an API proxy from baremetal to ironic

2014-09-10 Thread Dan Smith
1) Is this tested anywhere? There are no unit tests in the patch and it's not clear to me that there would be any Tempest coverage of this code path. Providing this and having it break a couple of months down the line seems worse than not providing it at all. This is obviously fixable

Re: [openstack-dev] [Nova][Docker] Environment variables

2013-12-16 Thread Dan Smith
eg use a 'env_' prefix for glance image attributes We've got a couple of cases now where we want to overrides these same things on a per-instance basis. Kernel command line args is one other example. Other hardware overrides like disk/net device types are another possibility Rather than

Re: [openstack-dev] [Nova] Future meeting times

2013-12-18 Thread Dan Smith
I am fine with this, but I will never be attending the 1400 UTC meetings, as I live in utc-8 I too will miss the 1400UTC meetings during the majority of the year. During PDT I will be able to make them, but will be uncaffeinated. --Dan ___

Re: [openstack-dev] [Nova] Live upgrades and major rpc versions

2013-12-20 Thread Dan Smith
Using this approach I think we can support live upgrades from N-1 to N while still being able to drop some backwards compatibility code each release cycle. Agreed. We've been kinda slack about bumping the RPC majors for a while, which means we end up with a lot of cruft and comments like

Re: [openstack-dev] [Nova] Detect changes in object model

2014-01-10 Thread Dan Smith
If an object A contains another object or object list (called sub-object), any change happened in the sub-object can't be detected by obj_what_changed() in object A. Well, like the Instance object does, you can override obj_what_changed() to expose that fact to the caller. However, I think

Re: [openstack-dev] [Nova] Detect changes in object model

2014-01-10 Thread Dan Smith
Sounds good to me. The list base objects don't have methods to make changes to the list - so it would be a case of iterating looking at each object in the list. That would be ok. Hmm? You mean for NovaObjects that are lists? I hesitate to expose lists as changed when one of the objects

Re: [openstack-dev] The extra_resource in compute node object

2014-01-13 Thread Dan Smith
This patch set makes the extra_resources a list of object, instead of opaque json string. How do you think about that? Sounds better to me, I'll go have a look. However, the compute resource object is different with current NovaObject, a) it has no corresponding table, but just a field in

Re: [openstack-dev] [Nova] Detect changes in object model

2014-01-13 Thread Dan Smith
ObjectListBase has a field called objects that is typed fields.ListOfObjectsField('NovaObject'). I can see methods for count and index, and I guess you are talking about adding a method for are any of your contents changed here. I don't see other list operations (like append, insert, remove,

Re: [openstack-dev] [Nova] Detect changes in object model

2014-01-14 Thread Dan Smith
Hi Dan, are you going to cook a patch to expand the base class? Or we can do that ourselves? Yeah, I'll try to get to that today. --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

2014-01-29 Thread Dan Smith
Effective immediately, I would like to unfreeze nova-network development. I fully support this plan, while also agreeing that Neutron is the future of networking for OpenStack. As we have seen with recent performance-related gate failures, we cannot continue to ignore nova-network while the

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

2014-01-29 Thread Dan Smith
I was thinking for the upgrade process that we could leverage the port attach/detach BP done by Dan Smith a while ago. This has libvirt support and there are patches pending approval for Xen and Vmware. Not sure about the other drivers. If the guest can deal with the fact that the nova port

Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse and beyond

2014-01-30 Thread Dan Smith
If necessary the tasks work could be done solely as an extension, but I would really prefer to avoid that so I'll get this ball rolling quickly. I agree that doing it as a bolt-on to v3 would be significantly less favorable than making it an integrated feature of the API. IMHO, if a server

Re: [openstack-dev] [Nova][Scheduler] Will the Scheuler use Nova Objects?

2014-01-30 Thread Dan Smith
I'm of the opinion that the scheduler should use objects, for all the reasons that Nova uses objects, but that they should not be Nova objects. Ultimately what the scheduler needs is a concept of capacity, allocations, and locality of resources. But the way those are modeled doesn't need to

Re: [openstack-dev] [Nova] do nova objects work for plugins?

2014-02-03 Thread Dan Smith
Basically, if object A has object B as a child, and deserialization finds object B to be an unrecognized version, it will try to back port the object A to the version number of object B. Right, which is why we rev the version of, say, the InstanceList when we have to rev Instance itself, and

Re: [openstack-dev] [nova] massive number of new errors in logs with oslo.messaging

2014-02-04 Thread Dan Smith
And the error messages, which look like this: Returning exception Unexpected task state: expecting [u'scheduling', None] but the actual state is deleting to caller don't make sense -- at least in the English language. It's missing some grouping operator to help with order of operations.

Re: [openstack-dev] [nova] massive number of new errors in logs with oslo.messaging

2014-02-04 Thread Dan Smith
The inner exception is a thing and the outer pieces are a thing. The inner means that some instance update was attempted, but should be aborted if the instance state is not what we think it is. And looking a little closer, I think it means that the messaging.expected_exceptions decorator isn't

Re: [openstack-dev] [nova][ceilometer] ceilometer unit tests broke because of a nova patch

2014-02-04 Thread Dan Smith
Whats the underlying problem here? nova notifications aren't versioned? Nova should try to support ceilometer's use case so it sounds like there is may be a nova issue in here as well. Oh you're far from it. Long story short, the problem is that when an instance is detroyed, we need to

Re: [openstack-dev] [nova][ceilometer] ceilometer unit tests broke because of a nova patch

2014-02-05 Thread Dan Smith
We don't have to add a new notification, but we have to add some new datas in the nova notifications. At least for the delete instance notification to remove the ceilometer nova notifier. A while ago, I have registered a blueprint that explains which datas are missing in the current nova

Re: [openstack-dev] [Ironic] [TripleO] Goal setting // progress towards integration

2014-02-13 Thread Dan Smith
I would also like to see CI (either third party or in the gate) for the nova driver before merging it. There's a chicken and egg problem here if its in the gate, but I'd like to see it at least proposed as a review. Yeah, I think that the existing nova-baremetal driver is kinda frozen in a

Re: [openstack-dev] Db interaction: conductor vs objects vs apis

2014-02-18 Thread Dan Smith
- fat model approach - put the db interaction in objects If it's just DB interaction, then yes, in the object for sure. - put the db interactions in the conductor itself There is a reasonable separation between using conductor for mechanics (i.e. API deferring a long-running activity to

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Dan Smith
- We want to make backwards incompatible changes to the API and whether we do it in-place with V2 or by releasing V3 we'll have some form of dual API support burden. IMHO, the cost of maintaining both APIs (which are largely duplicated) for almost any amount of time outweighs the cost of

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Dan Smith
The API layer is a actually quite a very thin layer on top of the rest of Nova. Most of the logic in the API code is really just checking incoming data, calling the underlying nova logic and then massaging what is returned in the correct format. So as soon as you change the format the cost of

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Dan Smith
So the deprecation message in the patch says: LOG.warning(_('XML support has been deprecated and will be removed in the Juno release.')) perhaps that should be changed :-) Maybe, but I think we can continue with the plan to rip it out in Juno. In the past when we've asked,

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Dan Smith
onSharedStorage = True on_shared_storage = False This is a good example. I'm not sure it's worth breaking users _or_ introducing a new microversion for something like this. This is definitely what I would call a purity concern as opposed to usability. Things like the twenty different datetime

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Dan Smith
I thought micro versioning was so we could make backwards compatible changes. If we make breaking changes we need to support the old and the new for a little while. Adding a new field alongside an old one in a structure that we return is not a breaking change to me, IMHO. We can clean up the

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Dan Smith
I think we need to find an alternative way to support the new and old formats, like Accepts Headers, and retro-fitting a version to extensions so we can easily advertise new attributes, to those parsers that will break when they encounter those kinds of things. Agreed. Now I am tempted to

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Dan Smith
+1, seems would could explore for another cycle just to find out that backporting everything to V2 isn't going to be what we want, and now we've just wasted more time. If we say it's just deprecated and frozen against new features, then it's maintenance is just limited to bug fixes right?

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Dan Smith
Yeah, so objects is the big one here. Objects, and everything else. With no-db-compute we did it for a couple cycles, then objects, next it will be retooling flows to conductor, then dealing with tasks, talking to gantt, etc. It's not going to end any time soon. So what kind of reaction are

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Dan Smith
This would reduce the amount of duplication which is required (I doubt we could remove all duplication though) and whether its worth it for say the rescue example is debatable. But for those cases you'd only need to make the modification in one file. Don't forget the cases where the call

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Dan Smith
So I was thinking about this and Ken'ichi has basically said pretty much the same thing in his reply to this thread. I don't think it makes client moves any easier though - this is all about lowering our maintenance costs. So, in the other fork of this thread, I think you said we can't

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Dan Smith
We may need to differentiate between breaking the API and breaking corner-case behavior. Totally agreed. In one case you force everyone in the ecosystem to adapt (the libraries, the end user code). In the other you only (potentially) affect those that were not following the API correctly.

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Dan Smith
Users actually care about the latter. If the API accepts 'red' as a valid UUID then that is part of the implicit contract. Yeah, but right now, many of those things are would fail on postgres and succeed on mysql (not uuids necessarily, but others). Since we can't honor them in all cases, I

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Dan Smith
So if we make backwards incompatible changes we really need a major version bump. Minor versions don't cut it, because the expectation is you have API stability within a major version. I disagree. If the client declares support for it, I think we can very reasonably return new stuff. If we

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-27 Thread Dan Smith
So I think once we start returning different response codes, or completely different structures (such as the tasks change will be), it doesn't matter if we make the change in effect by invoking /v2 prefix or /v3 prefix or we look for a header. Its a major api revision. I don't think we should

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-27 Thread Dan Smith
Sure, but that's still functionally equivalent to using the /v2 prefix. So we could chuck the current /v3 code and do: /v2: Current thing /v3: invalid, not supported /v4: added simple task return for server create /v5: added the event extension /v6: added a new event for cinder to the

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-27 Thread Dan Smith
I do think client headers instead of urls have some pragmatic approach here that is very attractive. Will definitely need a good chunk of plumbing to support that in a sane way in the tree that keeps the overhead from a review perspective low. Aside from some helper functions to make this

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-27 Thread Dan Smith
So whilst we still have extensions (and that's a separate debate) we need versioning on a per extension basis. Otherwise people are forced to upgrade their extensions in lockstep with each other. I think that some people would argue that requiring the extensions to go together linearly is a

Re: [openstack-dev] [Nova] What is the currently accepted way to do plugins

2014-03-04 Thread Dan Smith
In a chat with Dan Smith on IRC, he was suggesting that the important thing was not to use class paths in the config file. I can see that internal implementation should not be exposed in the config files - that way the implementation can change without impacting the nova users/operators

Re: [openstack-dev] [Nova] What is the currently accepted way to do plugins

2014-03-04 Thread Dan Smith
How about using 'unstable' as a component of the entrypoint group? E.g., nova.unstable.events… Well, this is a pretty heavy way to ensure that the admin gets the picture, but maybe appropriate :) What I don't think we want is the in-tree plugins having to hook into something called unstable.

Re: [openstack-dev] [Nova] Concrete Proposal for Keeping V2 API

2014-03-04 Thread Dan Smith
What I'd like to do next is work through a new proposal that includes keeping both v2 and v3, but with a new added focus of minimizing the cost. This should include a path away from the dual code bases and to something like the v2.1 proposal. I think that the most we can hope for is

Re: [openstack-dev] [Nova] FFE request: clean-up-legacy-block-device-mapping

2014-03-05 Thread Dan Smith
Why accept it? * It's low risk but needed refactoring that will make the code that has been a source of occasional bugs. * It is very low risk internal refactoring that uses code that has been in tree for some time now (BDM objects). * It has seen it's fair share of reviews Yeah, this has

Re: [openstack-dev] [nova] Conductor support for networking in Icehouse

2014-03-10 Thread Dan Smith
However, when attempting to boot an instance, the Nova network service fails to retrieve network information from the controller. Adding the the database keys resolves the problem. I'm using the 2014.1~b3-0ubuntu1~cloud0 packages on Ubuntu 12.04. Can you file a bug with details from the logs?

Re: [openstack-dev] [nova] Conductor support for networking in Icehouse

2014-03-10 Thread Dan Smith
https://bugs.launchpad.net/nova/+bug/1290568 Thanks. Note that the objects work doesn't really imply that the service doesn't hit the database. In fact, nova-compute stopped hitting the database before we started on the objects work. Anyway, looks like there are still some direct-to-database

Re: [openstack-dev] [nova] Conductor support for networking in Icehouse

2014-03-12 Thread Dan Smith
Hmm... I guess the blueprint summary led me to believe that nova-network no longer needs to hit the database. Yeah, using objects doesn't necessarily mean that the rest of the direct database accesses go away. However, I quickly cooked up the rest of what is required to get this done:

Re: [openstack-dev] [Nova] FFE Request: Ephemeral RBD image support

2014-03-12 Thread Dan Smith
I'm confused as to why we arrived at the decision to revert the commits since Jay's patch was accepted. I'd like some details about this decision, and what new steps we need to take to get this back in for Juno. Jay's fix resolved the immediate problem that was reported by the user. However,

Re: [openstack-dev] [nova] [neutron] Top Gate Race - Bug 1248757 - test_snapshot_pattern fails with paramiko ssh EOFError

2014-03-13 Thread Dan Smith
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here is the latest marked fail - http://logs.openstack.org/28/79628/4/check/check-tempest-dsvm-neutron/11f8293/ So, looking at this a little bit, you can see from the n-cpu log that it is getting failures when talking to neutron. Specifically,

Re: [openstack-dev] OpenStack vs. SQLA 0.9

2014-03-13 Thread Dan Smith
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Because of where we are in the freeze, I think this should wait until Juno opens to fix. Icehouse will only be compatible with SQLA 0.8, which I think is fine. I expect the rest of the issues can be addressed during Juno 1. Agreed. I think we

Re: [openstack-dev] [nova] An analysis of code review in Nova

2014-03-14 Thread Dan Smith
Just to answer this point, despite the review latency, please don't be tempted to think one big change will get in quicker than a series of little, easy to review, changes. All changes are not equal. A large change often scares me away to easier to review patches. Seems like, for Juno-1, it

Re: [openstack-dev] [nova] Backwards incompatible API changes

2014-03-20 Thread Dan Smith
If we managed to break Horizon, its likely we've broken (or will break) other people's scripts or SDKs. The patch was merged in October (just after Icehouse opened) and so has been used in clouds that do CD for quite a while. After some discussion on IRC I think we'll end up having to leave

Re: [openstack-dev] [nova] nova-compute not re-establishing connectivity after controller switchover

2014-03-24 Thread Dan Smith
Any ideas on what might be going on would be appreciated. This looks like something that should be filed as a bug. I don't have any ideas off hand, bit I will note that the reconnection logic works fine for us in the upstream upgrade tests. That scenario includes starting up a full stack, then

Re: [openstack-dev] Rolling upgrades in icehouse

2014-03-24 Thread Dan Smith
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Where can I obtain more information about this feature? - From the blog post that I've yet to write :D Does above imply that database is upgraded along with control service update as well? Yes, but only for the services that interact directly

[openstack-dev] [Nova] PTL Candidacy

2014-03-28 Thread Dan Smith
Hi all, I would like to run for the OpenStack Compute (Nova) PTL position. Qualifications - I have been working almost exclusively on Nova since mid-2012, and have been on the nova-core team since late 2012. I am also a member of nova-drivers, where I help to target and

Re: [openstack-dev] Decorator behavior

2014-03-31 Thread Dan Smith
At run time there are decorators that behave in an unexpected manner. For instance, in nova/compute/manager.py when ComputeManager's resize_instance method is called, the migration positional argument is somehow added to kwargs (paired with the migration key) and is stripped out of the args

Re: [openstack-dev] [nova][powervm] my notes from the meeting on powervm CI

2013-10-10 Thread Dan Smith
4. What is the max amount of time for us to report test results? Dan didn't seem to think 48 hours would fly. :) Honestly, I think that 12 hours during peak times is the upper limit of what could be considered useful. If it's longer than that, many patches could go into the tree without a

Re: [openstack-dev] [Hyper-V] Havana status

2013-10-11 Thread Dan Smith
We could either have a single repo: openstack/nova-extra-drivers This would be my preference for sure, just from the standpoint of additional release complexity otherwise. I know it might complicate how the core team works, but presumably we could get away with just having driver

Re: [openstack-dev] [Hyper-V] Havana status

2013-10-11 Thread Dan Smith
I think that all drivers that are officially supported must be treated in the same way. Well, we already have multiple classes of support due to the various states of testing that the drivers have. If we are going to split out drivers into a separate but still official repository then we

Re: [openstack-dev] [Hyper-V] Havana status

2013-10-11 Thread Dan Smith
My only request here is that we can make sure that new driver features can land for other drivers without necessarilky having them implemented for libvirt/KVM first. We've got lots of things supported by the XenAPI drivers that aren't supported by libvirt, so I don't think this is a problem

Re: [openstack-dev] [Hyper-V] Havana status

2013-10-12 Thread Dan Smith
If the idea is to gate with nova-extra-drivers this could lead to a rather painful process to change the virt driver API. When all the drivers are in the same tree all of them can be updated at the same time as the infrastructure. Right, and I think if we split those drivers out, then we do

Re: [openstack-dev] [Hyper-V] Havana status

2013-10-12 Thread Dan Smith
From the user perspective, splitting off the projects seems to be focussing on the ease of commit compared to the final user experience. I think what you describe is specifically the desire that originally spawned the thread: making the merging of changes to the hyper-v driver faster by

Re: [openstack-dev] [Hyper-V] Havana status

2013-10-12 Thread Dan Smith
4) Periodically, code from the new project(s) must be merged into Nova. Only Nova core reviewers will have obviously +2a rights here. I propose to do it on scheduled days before every milestone, differentiated per driver to distribute the review effort (what about also having Nova core

Re: [openstack-dev] Hyper-V meeting Minutes

2013-10-15 Thread Dan Smith
The last thing that OpenStack needs ANY more help with is velocity. I mean, let's be serious - we land WAY more patches in a day than is even close to sane. Thanks for saying this -- it doesn't get said enough. I find it totally amazing that we're merging 34 changes in a day (yesterday) which

Re: [openstack-dev] Hyper-V meeting Minutes

2013-10-16 Thread Dan Smith
+1 - I think we really want to have a strong preference for a stable api if we start separating parts out So, as someone who is about to break the driver API all to hell over the next six months (er, I mean, make some significant changes), I can tell you that making it stable is the best way

Re: [openstack-dev] [Nova] VMWare Mine Sweeper, Congrats!

2013-10-17 Thread Dan Smith
This system is running tempest against a VMWare deployment and posting the results publicly. This is really great progress. It will go a long way in helping reviewers be more confident in changes to this driver. This is huge progress, congrats and thanks to the VMware team for making this

Re: [openstack-dev] Fwd: Change in openstack/nova[master]: Moved quota headroom calculations into quota_reserve

2013-10-20 Thread Dan Smith
As I don't see how to keep it in the review, I'll copy to openstack-dev. Just keep making your comments in Gerrit. That way all the discussion related to a specific patch is preserved with proper linkage in case we ever need to go back to it. OK, I think I see what I need to do to do to not

Re: [openstack-dev] [Nova] Blueprint review process

2013-10-24 Thread Dan Smith
In the last meeting we discussed an idea that I think is worth trying at least for icehouse-1 to see if we like it or not. The idea is that *every* blueprint starts out at a Low priority, which means best effort, but no promises. For a blueprint to get prioritized higher, it should have 2

Re: [openstack-dev] RFC - Icehouse logging harmonization

2013-10-24 Thread Dan Smith
Example 1: == n-conductor log in tempest/devstack - http://logs.openstack.org/70/52870/3/check/check-tempest-devstack-vm-full/f46b756/logs/screen-n-cond.txt.gz Total log lines: 84076 Total non DEBUG lines: 61 Question: do we need more than 1 level of

Re: [openstack-dev] RFC - Icehouse logging harmonization

2013-10-24 Thread Dan Smith
If we had DEBUG and DEBUG2 levels, where one of them would only be seen at the higher debug level, would that be useful? I'm fine with not seeing those for devstack runs, yeah. --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [OpenStack-dev][Nova][Discussion]Blueprint : Auto VM Discovery in OpenStack for existing workload

2013-10-30 Thread Dan Smith
1) I agree with Russell that Nova should not try to manage VMs it didn't create. Me too. A lot. --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] Some initial code copying for db/migration

2013-11-01 Thread Dan Smith
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L420 https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L43 This API and these models are what we are trying to avoid exposing to the rest of nova. By wrapping these in our NovaObject-based

Re: [openstack-dev] [Solum] Some initial code copying for db/migration

2013-11-08 Thread Dan Smith
1) Using objects as an abstraction for versioned data: This seems like a good direction overall, especially from the point-of-view of backwards compatibility of consumers of the object. However, after looking through some of the objects defined in nova/objects/, I am not sure if I

Re: [openstack-dev] [style] () vs \ continuations

2013-11-13 Thread Dan Smith
I'd like us to avoid meaningless reviewer churn here: I'd like us to avoid trivial style guideline churn :) The case that made me raise this is this: folder_exists, file_exists, file_size_in_kb, disk_extents = \ self._path_file_exists(ds_browser, folder_path, file_name)

Re: [openstack-dev] [nova][object] One question to the resource tracker session

2013-11-14 Thread Dan Smith
You're right, it's not really achievable without moving to a schemaless persistence model. I'm fairly certain it was added to be humorous and should not be considered an outcome of that session. But we can avoid most data migrations by adding any required conversion code into the objects

Re: [openstack-dev] [nova][object] One question to the resource tracker session

2013-11-14 Thread Dan Smith
I assume this back support include also object and the N means major release like H, I, right? Yes, I meant N=Icehouse, N-1=Havana, for example. --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

[openstack-dev] [Nova] Hypervisor CI requirement and deprecation plan

2013-11-15 Thread Dan Smith
Hi all, As you know, Nova adopted a plan to require CI testing for all our in-tree hypervisors by the Icehouse release. At the summit last week, we determined the actual plan for deprecating non-compliant drivers. I put together a page detailing the specific requirements we're putting in place as

Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

2013-11-15 Thread Dan Smith
Thanks for weighing in, I do hope to keep the conversation going. Add my name to the list of people that won't be considering the trip as a result. --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [Nova] Configuration validation

2013-11-18 Thread Dan Smith
Another issue that we might want to try and solve with this (and imho another reason to keep the framework for this in oslo) is that we might want to make these update aware, and allow for some graceful degradation or something similar when for example an updated service is stated with an

Re: [openstack-dev] [Nova] Configuration validation

2013-11-18 Thread Dan Smith
To be fair, we test only the subset that is set via devstack on the stable side. That should be a common subset, but it is far from fully comprehensive. Nova has over 600 config variables, so additional tooling here would be goodness. I'm surely not arguing against additional testing of

Re: [openstack-dev] [Solum] Some initial code copying for db/migration

2013-11-18 Thread Dan Smith
Sorry for the delay in responding to this... * Moved the _obj_classes registry magic out of ObjectMetaClass and into its own method for easier use. Since this is a subclass based implementation, having a separate method feels more appropriate for a factory/registry pattern.

Re: [openstack-dev] Introducing the new OpenStack service for Containers

2013-11-18 Thread Dan Smith
Not having been at the summit (maybe the next one), could somebody give a really short explanation as to why it needs to be a separate service? It sounds like it should fit within the Nova area. It is, after all, just another hypervisor type, or so it seems. But it's not just another

Re: [openstack-dev] [Solum] Some initial code copying for db/migration

2013-11-18 Thread Dan Smith
I think the plus of avoiding decorating things isn't really a huge win, and actually i think takes clarity away. Hence the (meh) in my list :) This wasn't really a sticking point when we were getting reviews on the original base infrastructure, so I'm surprised people are so vehement now.

Re: [openstack-dev] [Nova] Proposal to add Matt Riedemann to nova-core

2013-11-22 Thread Dan Smith
Please respond with +1/-1, or any further comments. +1 from me -- Matt has been helping a lot lately. --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] FreeBSD hypervisor (bhyve) driver

2013-11-25 Thread Dan Smith
So just to clarify: the native driver for another hypervisor (bhyve) would not be accepted into Nova even if it met testing coverage criteria? As I said the libvirt route is an option we consider, but we would like to have the possibility of a native FreeBSD api integration as well, similar

Re: [openstack-dev] [Nova] Hypervisor CI requirement and deprecation plan

2013-11-26 Thread Dan Smith
My overall concern, and I think the other guys doing this for virt drivers will agree, is trying to scope down the exposure to unrelated failures. But, if it's not related to your driver, then it also failed in the upstream gate, right? If it didn't fail the upstream gate, then it is some

Re: [openstack-dev] [Nova][QA] Disabling the v3 API tests in the gate

2014-06-12 Thread Dan Smith
I think it'd be OK to move them to the experimental queue and a periodic nightly job until the v2.1 stuff shakes out. The v3 API is marked experimental right now so it seems fitting that it'd be running tests in the experimental queue until at least the spec is approved and microversioning

Re: [openstack-dev] [Nova][QA] Disabling the v3 API tests in the gate

2014-06-12 Thread Dan Smith
Thats true, though I was suggesting as v2.1microversions rolls out we drop the test out of v3 and move it to v2.1microversions testing, so there's no change in capacity required. Right now we run a full set over /v2 and a full set over /v3. Certainly as we introduce /v2.1 we'll need full

Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit

2014-06-27 Thread Dan Smith
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What if 3rd Party CI didn't vote in Gerrit? What if it instead published to some 3rd party test reporting site (a thing that doesn't yet exist). Gerrit has the facility so that we could inject the dashboard content for this in Gerrit in a little

Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit

2014-06-30 Thread Dan Smith
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There is a similar old bug for that, with a good suggestion for how it could possibly be done: https://bugs.launchpad.net/openstack-ci/+bug/1251758 This isn't what I'm talking about. What we need is, for each new patchset on a given change, an

Re: [openstack-dev] [nova] Live migration objects

2014-07-11 Thread Dan Smith
I'm contemplating how to fix https://bugs.launchpad.net/nova/+bug/1339823 and it seems that a part of the fix would be to track the state of live migrations in the database, more or less the same way that cold migrations are tracked. The thinking is that the logic could retrieve information

  1   2   3   4   >