I have no particular part thus any part that need help is ok for me. My own purpose is to support dynamic resource claim to support live migration to instance with hardware allocated. For instance with device assigned (PCI device, USB or everything), we can't migrate it unless it's unplugged.
Also currently the resource tracker is more than tracker, it in fact also update host to the instance, which I assume should be done by conducto. It even create the migration object, which I think should also be created by conductor. IIUC, the reason is to keep the atomic operation to avoid race with the audit. Combine the above two, I'm considering if we can change current resource tracker. Instead of passing the instance/flavor, a new object, resource requirement is used. The process is: the conductor calculate the resource requirement for the instance on both building and resize , and passing it to the resource tracker, the resource tracker will add the hypervisor overhead, and then claim it. If the claim is success, the resource tracker save this resource requirement to the database. For build time, this should work well. For resize, this should also work, only that the instance will have two resource requirement. And there will be no race condition here. Other than that, another benefit is, the resource tracker don't need care for the flavor anymore. I'm not sure if we can totally remove the new_/old_ flavor information in system_metadata, but we can move the key user of it. Your opinion? Thanks --jyh > -----Original Message----- > From: Murray, Paul (HP Cloud Services) [mailto:pmur...@hp.com] > Sent: Friday, November 15, 2013 6:55 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [nova][object] One question to the resource > tracker session > > I was leading that session and put the comment there - sorry it has lead to > confusion - I'll add something to make it clear. > > I'm actually drafting the bp at the moment - probably going to split some of > the tasks up into different bps (at the suggestion of Dan and Russell). > > Is there a particular part you were interested in? > > -----Original Message----- > From: Jiang, Yunhong [mailto:yunhong.ji...@intel.com] > Sent: 14 November 2013 18:20 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [nova][object] One question to the resource > tracker session > > > > > -----Original Message----- > > From: Andrew Laski [mailto:andrew.la...@rackspace.com] > > Sent: Thursday, November 14, 2013 10:02 AM > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [nova][object] One question to the > > resource tracker session > > > > On 11/14/13 at 05:37pm, Jiang, Yunhong wrote: > > > > > >> -----Original Message----- > > >> From: Andrew Laski [mailto:andrew.la...@rackspace.com] > > >> Sent: Wednesday, November 13, 2013 3:22 PM > > >> To: OpenStack Development Mailing List (not for usage questions) > > >> Subject: Re: [openstack-dev] [nova][object] One question to the > > resource > > >> tracker session > > >> > > >> On 11/13/13 at 11:12pm, Jiang, Yunhong wrote: > > >> >Hi, Dan Smith and all, > > >> > I noticed followed statement in 'Icehouse tasks' in > > >> > > > https://etherpad.openstack.org/p/IcehouseNovaExtensibleSchedulerMetr > > >> ics > > >> > > > >> > convert resource tracker to objects > > >> > make resoruce tracker extensible > > >> > no db migrations ever again!! > > >> > extra specs to cover resources - use a name space > > >> > > > >> > How is it planned to achieve the 'no db migrations ever again'? > > Even > > >> with the object, we still need keep resource information in database. > > And > > >> when new resource type added, we either add a new column to the > > table. > > >> Or it means we merge all resource information into a single column > > >> as > > json > > >> string and parse it in the resource tracker object?. > > >> > > >> 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. > > > > > >Andrew, thanks for the explanation. Not sure anyone have interests on > > this task, otherwise I will take it. > > > > There is a blueprint for part of this from Paul Murray, > > > https://blueprints.launchpad.net/nova/+spec/make-resource-tracker-use- > > objects. > > So you could coordinate the work if you're interested. > > Yes, just noticed it and the first 2 sponsor. I will keep an eye on it. > > --jyh > > > > > > > > >--jyh > > > > > >> > > >> > > > >> >Thanks > > >> >--jyh > > >> > > > >> >_______________________________________________ > > >> >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 > > > > > >_______________________________________________ > > >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 > > _______________________________________________ > 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
