Re: [openstack-dev] [nova] [placement] extraction (technical) update
On Wed, Sep 5, 2018 at 12:41 PM Dan Smith wrote: > > > I think there was a period in time where the nova_api database was created > > where entires would try to get pulled out from the original nova database > > and > > then checking nova_api if it doesn't exist afterwards (or vice versa). One > > of the cases that this was done to deal with was for things like instance > > types > > or flavours. > > > > I don't know the exact details but I know that older instance types exist in > > the nova db and the newer ones are sitting in nova_api. Something along > > those lines? > > Yep, we've moved entire databases before in nova with minimal disruption > to the users. Not just flavors, but several pieces of data came out of > the "main" database and into the api database transparently. It's > doable, but with placement being split to a separate > project/repo/whatever, there's not really any option for being graceful > about it in this case. > > > At this point, I'm thinking turn off placement, setup the new one, do > > the migration > > of the placement-specific tables (this can be a straightforward documented > > task > > OR it would be awesome if it was a placement command (something along > > the lines of `placement-manage db import_from_nova`) which would import all > > the right things > > > > The idea of having a command would be *extremely* useful for deployment > > tools > > in automating the process and it also allows the placement team to > > selectively > > decide what they want to onboard? > > Well, it's pretty cut-and-dried as all the tables in nova-api are either > for nova or placement, so there's not much confusion about what belongs. > > I'm not sure that doing this import in python is really the most > efficient way. I agree a placement-manage command would be ideal from an > "easy button" point of view, but I think a couple lines of bash that > call mysqldump are likely to vastly outperform us doing it natively in > python. We could script exec()s of those commands from python, but.. I > think I'd rather just see that as a shell script that people can easily > alter/test on their own. > > Just curious, but in your case would the service catalog entry change at > all? If you stand up the new placement in the exact same spot, it > shouldn't, but I imagine some people will have the catalog entry change > slightly (even if just because of a VIP or port change). Am I > remembering correctly that the catalog can get cached in various places > such that much of nova would need a restart to notice? We already have placement in the catalog and it's behind a load balancer so changing the backends resolves things right away, so we likely won't be needing any restarts (and I don't think OSA will either because it uses the same model). > --Dan -- Mohammed Naser — vexxhost - D. 514-316-8872 D. 800-910-1726 ext. 200 E. mna...@vexxhost.com W. http://vexxhost.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
> I think there was a period in time where the nova_api database was created > where entires would try to get pulled out from the original nova database and > then checking nova_api if it doesn't exist afterwards (or vice versa). One > of the cases that this was done to deal with was for things like instance > types > or flavours. > > I don't know the exact details but I know that older instance types exist in > the nova db and the newer ones are sitting in nova_api. Something along > those lines? Yep, we've moved entire databases before in nova with minimal disruption to the users. Not just flavors, but several pieces of data came out of the "main" database and into the api database transparently. It's doable, but with placement being split to a separate project/repo/whatever, there's not really any option for being graceful about it in this case. > At this point, I'm thinking turn off placement, setup the new one, do > the migration > of the placement-specific tables (this can be a straightforward documented > task > OR it would be awesome if it was a placement command (something along > the lines of `placement-manage db import_from_nova`) which would import all > the right things > > The idea of having a command would be *extremely* useful for deployment tools > in automating the process and it also allows the placement team to selectively > decide what they want to onboard? Well, it's pretty cut-and-dried as all the tables in nova-api are either for nova or placement, so there's not much confusion about what belongs. I'm not sure that doing this import in python is really the most efficient way. I agree a placement-manage command would be ideal from an "easy button" point of view, but I think a couple lines of bash that call mysqldump are likely to vastly outperform us doing it natively in python. We could script exec()s of those commands from python, but.. I think I'd rather just see that as a shell script that people can easily alter/test on their own. Just curious, but in your case would the service catalog entry change at all? If you stand up the new placement in the exact same spot, it shouldn't, but I imagine some people will have the catalog entry change slightly (even if just because of a VIP or port change). Am I remembering correctly that the catalog can get cached in various places such that much of nova would need a restart to notice? --Dan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On 9/5/2018 10:03 AM, Mohammed Naser wrote:
On Wed, Sep 5, 2018 at 10:57 AM Matt Riedemann wrote:
On 9/5/2018 8:47 AM, Mohammed Naser wrote:
Could placement not do what happened for a while when the nova_api
database was created?
Can you be more specific? I'm having a brain fart here and not
remembering what you are referring to with respect to the nova_api DB.
I think there was a period in time where the nova_api database was created
where entires would try to get pulled out from the original nova database and
then checking nova_api if it doesn't exist afterwards (or vice versa). One
of the cases that this was done to deal with was for things like instance types
or flavours.
I don't know the exact details but I know that older instance types exist in
the nova db and the newer ones are sitting in nova_api. Something along
those lines?
Yeah that more about supporting online data migrations *within* nova
where new records were created in the API DB and old records would be
looked up in both the API DB and then if not found there, in the cell
(traditional nova DB). But you'd also be running the "nova-manage db
online_data_migrations" CLI to force the migration of the records from
the cell DB to the API DB.
With Placement split out of nova, we can't really do that. You could
point placement at the nova_api DB so it can pull existing records, but
it would continue to create new records in the nova_api DB rather than
the placement DB and at some point you have to make that data migration.
Maybe you were thinking something like have temporary fallback code in
placement such that if a record isn't found in the placement database,
it queries a configured nova_api database? That'd be a ton of work at
this point, and if it was something we were going to do, we should have
agreed on that in YVR several months ago, definitely pre-extraction.
I say this because I know that moving the database is a huge task for
us, considering how big it can be in certain cases for us, and it
means control plane outage too
I'm pretty sure you were in the room in YVR when we talked about how
operators were going to do the database migration and were mostly OK
with what was discussed, which was a lot will just copy and take the
downtime (I think CERN said around 10 minutes for them, but they aren't
a public cloud either), but others might do something more sophisticated
and nova shouldn't try to pick the best fit for all.
If we're provided the list of tables used by placement, we could considerably
make the downtime smaller because we don't have to pull in the other huge
tables like instances/build requests/etc
There are no instances records in the API DB, maybe you mean
instance_mappings? But yes I get the point.
What happens if things like server deletes happen while the placement service
is down?
The DELETE /allocations/{consumer_id} requests from nova to placement
will fail with some keystoneauth1 exception, but because of our old
friend @safe_connect we likely won't fail the server delete because we
squash the exception from KSA:
https://github.com/openstack/nova/blob/0f102089dd0b27c7d35f0cbba87332414032c0a4/nova/scheduler/client/report.py#L2069
However, you'd still have allocations in placement against resource
providers (compute nodes) for instances that no longer exist, which
means you're available capacity for scheduling new requests is
diminished until those bogus allocations are purged from placement,
which will take some scripting.
In other words, not good things.
I'm definitely interested in what you do plan to do for the database
migration to minimize downtime.
At this point, I'm thinking turn off placement, setup the new one, do
the migration
of the placement-specific tables (this can be a straightforward documented task
OR it would be awesome if it was a placement command (something along
the lines of `placement-manage db import_from_nova`) which would import all
the right things
You wouldn't also stop nova-api while doing this? Otherwise you're going
to get into the data/resource tracking mess described above which will
require some post-migration cleanup scripting.
The idea of having a command would be*extremely* useful for deployment tools
in automating the process and it also allows the placement team to selectively
decide what they want to onboard?
Just throwing ideas here.
--
Thanks,
Matt
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On Wed, Sep 5, 2018 at 10:57 AM Matt Riedemann wrote: > > On 9/5/2018 8:47 AM, Mohammed Naser wrote: > > Could placement not do what happened for a while when the nova_api > > database was created? > > Can you be more specific? I'm having a brain fart here and not > remembering what you are referring to with respect to the nova_api DB. I think there was a period in time where the nova_api database was created where entires would try to get pulled out from the original nova database and then checking nova_api if it doesn't exist afterwards (or vice versa). One of the cases that this was done to deal with was for things like instance types or flavours. I don't know the exact details but I know that older instance types exist in the nova db and the newer ones are sitting in nova_api. Something along those lines? > > > > I say this because I know that moving the database is a huge task for > > us, considering how big it can be in certain cases for us, and it > > means control plane outage too > > I'm pretty sure you were in the room in YVR when we talked about how > operators were going to do the database migration and were mostly OK > with what was discussed, which was a lot will just copy and take the > downtime (I think CERN said around 10 minutes for them, but they aren't > a public cloud either), but others might do something more sophisticated > and nova shouldn't try to pick the best fit for all. If we're provided the list of tables used by placement, we could considerably make the downtime smaller because we don't have to pull in the other huge tables like instances/build requests/etc What happens if things like server deletes happen while the placement service is down? > I'm definitely interested in what you do plan to do for the database > migration to minimize downtime. At this point, I'm thinking turn off placement, setup the new one, do the migration of the placement-specific tables (this can be a straightforward documented task OR it would be awesome if it was a placement command (something along the lines of `placement-manage db import_from_nova`) which would import all the right things The idea of having a command would be *extremely* useful for deployment tools in automating the process and it also allows the placement team to selectively decide what they want to onboard? Just throwing ideas here. > +openstack-operators ML since this is an operators discussion now. > > -- > > Thanks, > > Matt -- Mohammed Naser — vexxhost - D. 514-316-8872 D. 800-910-1726 ext. 200 E. mna...@vexxhost.com W. http://vexxhost.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On 9/5/2018 8:47 AM, Mohammed Naser wrote: Could placement not do what happened for a while when the nova_api database was created? Can you be more specific? I'm having a brain fart here and not remembering what you are referring to with respect to the nova_api DB. I say this because I know that moving the database is a huge task for us, considering how big it can be in certain cases for us, and it means control plane outage too I'm pretty sure you were in the room in YVR when we talked about how operators were going to do the database migration and were mostly OK with what was discussed, which was a lot will just copy and take the downtime (I think CERN said around 10 minutes for them, but they aren't a public cloud either), but others might do something more sophisticated and nova shouldn't try to pick the best fit for all. I'm definitely interested in what you do plan to do for the database migration to minimize downtime. +openstack-operators ML since this is an operators discussion now. -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On Wed, Sep 5, 2018 at 3:56 PM, Matt Riedemann wrote: > On 9/5/2018 8:39 AM, Dan Smith wrote: > >> Why not? >> > > Because of the versions table as noted earlier. Up until this point no one > had mentioned that but it would be an issue. > > >> I think the safest/cleanest thing to do here is renumber placement-related >> migrations from 1, and provide a script or procedure to dump just the >> placement-related tables from the nova_api database to the new one (not >> including the sqlalchemy-migrate versions table). >> > > I'm OK with squashing/trimming/resetting the version to 1. What was not > mentioned earlier in this thread was (1) an acknowledgement that we'd need > to drop the versions table to reset the version in the new database and (2) > any ideas about providing scripts to help with the DB migration. > > I think it's safe too. Operators could just migrate the tables by using a read-only slave connection to a new DB and then using this script that would drop the non-needed tables. For people wanting to migrate tables, I think having placement versions being different is not a problem given the tables are the same. -Sylvain -- > > Thanks, > > Matt > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On 9/5/2018 8:39 AM, Dan Smith wrote: Why not? Because of the versions table as noted earlier. Up until this point no one had mentioned that but it would be an issue. I think the safest/cleanest thing to do here is renumber placement-related migrations from 1, and provide a script or procedure to dump just the placement-related tables from the nova_api database to the new one (not including the sqlalchemy-migrate versions table). I'm OK with squashing/trimming/resetting the version to 1. What was not mentioned earlier in this thread was (1) an acknowledgement that we'd need to drop the versions table to reset the version in the new database and (2) any ideas about providing scripts to help with the DB migration. -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
Could placement not do what happened for a while when the nova_api database was created? I say this because I know that moving the database is a huge task for us, considering how big it can be in certain cases for us, and it means control plane outage too On Wed, Sep 5, 2018 at 9:39 AM Dan Smith wrote: > > >> Yes, we should definitely trim the placement DB migrations to only > >> things relevant to placement. And we can use this opportunity to get > >> rid of cruft too and squash all of the placement migrations together > >> to start at migration 1 for the placement repo. If anyone can think > >> of a problem with doing that, please shout it out. > > I agree, FWIW. > > > Umm, nova-manage db sync creates entries in a sqlalchemy-migrate > > versions table, something like that, to track per database what the > > latest migration sync version has been. > > > > Based on that, and the fact I thought our DB extraction policy was to > > mostly tell operators to copy the nova_api database and throw it > > elsewhere in a placement database, then the migrate versions table is > > going to be saying you're at 061 and you can't start new migrations > > from 1 at that point, unless you wipe out that versions table after > > you copy the API DB. > > They can do this, sure. However, either we'll need migrations to delete > all the nova-api-related tables, or they will need to trim them > manually. If we do the former, then everyone who ever installs placement > from scratch will go through the early history of nova-api only to have > that removed. Or we trim those off the front, but we have to keep the > collapsing migrations until we compact again, etc. > > The thing I'm more worried about is operators being surprised by this > change (since it's happening suddenly in the middle of a release), > noticing some split, and then realizing that if they just point the > placement db connection at nova_api everything seems to work. That's > going to go really bad when things start to diverge. > > > I could be wrong, but just copying the database, squashing/trimming > > the migration scripts and resetting the version to 1, and assuming > > things are going to be hunky dory doesn't sound like it will work to > > me. > > Why not? > > I think the safest/cleanest thing to do here is renumber placement-related > migrations from 1, and provide a script or procedure to dump just the > placement-related tables from the nova_api database to the new one (not > including the sqlalchemy-migrate versions table). > > --Dan > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mohammed Naser — vexxhost - D. 514-316-8872 D. 800-910-1726 ext. 200 E. mna...@vexxhost.com W. http://vexxhost.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
>> Yes, we should definitely trim the placement DB migrations to only >> things relevant to placement. And we can use this opportunity to get >> rid of cruft too and squash all of the placement migrations together >> to start at migration 1 for the placement repo. If anyone can think >> of a problem with doing that, please shout it out. I agree, FWIW. > Umm, nova-manage db sync creates entries in a sqlalchemy-migrate > versions table, something like that, to track per database what the > latest migration sync version has been. > > Based on that, and the fact I thought our DB extraction policy was to > mostly tell operators to copy the nova_api database and throw it > elsewhere in a placement database, then the migrate versions table is > going to be saying you're at 061 and you can't start new migrations > from 1 at that point, unless you wipe out that versions table after > you copy the API DB. They can do this, sure. However, either we'll need migrations to delete all the nova-api-related tables, or they will need to trim them manually. If we do the former, then everyone who ever installs placement from scratch will go through the early history of nova-api only to have that removed. Or we trim those off the front, but we have to keep the collapsing migrations until we compact again, etc. The thing I'm more worried about is operators being surprised by this change (since it's happening suddenly in the middle of a release), noticing some split, and then realizing that if they just point the placement db connection at nova_api everything seems to work. That's going to go really bad when things start to diverge. > I could be wrong, but just copying the database, squashing/trimming > the migration scripts and resetting the version to 1, and assuming > things are going to be hunky dory doesn't sound like it will work to > me. Why not? I think the safest/cleanest thing to do here is renumber placement-related migrations from 1, and provide a script or procedure to dump just the placement-related tables from the nova_api database to the new one (not including the sqlalchemy-migrate versions table). --Dan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On 9/4/2018 4:27 PM, melanie witt wrote: Yes, we should definitely trim the placement DB migrations to only things relevant to placement. And we can use this opportunity to get rid of cruft too and squash all of the placement migrations together to start at migration 1 for the placement repo. If anyone can think of a problem with doing that, please shout it out. Umm, nova-manage db sync creates entries in a sqlalchemy-migrate versions table, something like that, to track per database what the latest migration sync version has been. Based on that, and the fact I thought our DB extraction policy was to mostly tell operators to copy the nova_api database and throw it elsewhere in a placement database, then the migrate versions table is going to be saying you're at 061 and you can't start new migrations from 1 at that point, unless you wipe out that versions table after you copy the API DB. I could be wrong, but just copying the database, squashing/trimming the migration scripts and resetting the version to 1, and assuming things are going to be hunky dory doesn't sound like it will work to me. -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On Tue, 4 Sep 2018, Eric Fried wrote: 030 is okay as long as nothing goes wrong. If something does it raises exceptions which would currently fail as the exceptions are not there. See below for more about exceptions. Maybe I'm misunderstanding what these migration thingies are supposed to be doing, but 030 [1] seems like it's totally not applicable to placement and should be removed. The placement database doesn't (and shouldn't) have 'flavors', 'cell_mappings', or 'host_mappings' tables in the first place. What am I missing? Nothing, as far as I can tell, but as we hadn't had a clear plan about how to proceed with the trimming of migrations, I've been trying to point out where they form little speed bumps as we've gone through this process and carried them with us. And tried to annotate where there may present some more, until we trim them. There are numerous limits to my expertise, and the db migrations is one of several areas where I decided I wasn't going to hold the ball, I'd just get us to the game and hope other people would find and fill in the blanks. That seems to be working okay, so far. * Presumably we can trim the placement DB migrations to just stuff that is relevant to placement Yah, I would hope so. What possible reason could there be to do otherwise? Mel's plans looks good to me. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On Tue, 4 Sep 2018 16:16:31 -0500, Eric Fried wrote: 030 is okay as long as nothing goes wrong. If something does it raises exceptions which would currently fail as the exceptions are not there. See below for more about exceptions. Maybe I'm misunderstanding what these migration thingies are supposed to be doing, but 030 [1] seems like it's totally not applicable to placement and should be removed. The placement database doesn't (and shouldn't) have 'flavors', 'cell_mappings', or 'host_mappings' tables in the first place. What am I missing? * Presumably we can trim the placement DB migrations to just stuff that is relevant to placement Yah, I would hope so. What possible reason could there be to do otherwise? Yes, we should definitely trim the placement DB migrations to only things relevant to placement. And we can use this opportunity to get rid of cruft too and squash all of the placement migrations together to start at migration 1 for the placement repo. If anyone can think of a problem with doing that, please shout it out. -melanie __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
> 030 is okay as long as nothing goes wrong. If something does it > raises exceptions which would currently fail as the exceptions are > not there. See below for more about exceptions. Maybe I'm misunderstanding what these migration thingies are supposed to be doing, but 030 [1] seems like it's totally not applicable to placement and should be removed. The placement database doesn't (and shouldn't) have 'flavors', 'cell_mappings', or 'host_mappings' tables in the first place. What am I missing? > * Presumably we can trim the placement DB migrations to just stuff > that is relevant to placement Yah, I would hope so. What possible reason could there be to do otherwise? -efried [1] https://github.com/openstack/placement/blob/2f1267c8785138c8f2c9495bd97e6c2a96c7c336/placement/db/sqlalchemy/api_migrations/migrate_repo/versions/030_require_cell_setup.py __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
There's been some progress on the technical side of extracting placement to it own repo. The summary is: * https://git.openstack.org/cgit/openstack/placement exists * https://review.openstack.org/#/c/599416/ is at the top of a series of patches. That patch is passing and voting on unit and functional for py 2.7 and 3.5 and is passing pep8. More below, in the steps. On Tue, 28 Aug 2018, Chris Dent wrote: On Mon, 27 Aug 2018, melanie witt wrote: 1. We copy the placement code into the openstack/placement repo and have it passing all of its own unit and functional tests. To break that down to more detail, how does this look? (note the ALL CAPS where more than acknowledgement is requested) 1.1 Run the git filter-branch on a copy of nova 1.1.1 Add missing files to the file list: 1.1.1.1 .gitignore 1.1.1.2 # ANYTHING ELSE? 1.2 Push -f that thing, acknowledge to be broken, to a seed repo on github (ed's repo should be fine) 1.3 Do the repo creation bits described in https://docs.openstack.org/infra/manual/creators.html to seed openstack/placement 1.3.1 set zuul jobs. Either to noop-jobs, or non voting basic func and unit # INPUT DESIRED HERE 1.4 Once the repo exists with some content, incrementally bring it to working 1.4.1 Update tox.ini to be placement oriented 1.4.2 Update setup.cfg to be placement oriented 1.4.3 Correct .stesr.conf 1.4.4 Move base of placement to "right" place 1.4.5 Move unit and functionals to right place 1.4.6 Do automated path fixings 1.4.7 Set up translation domain and i18n.py corectly 1.4.8 Trim placement/conf to just the conf settings required (api, base, database, keystone, paths, placement) 1.4.9 Remove database files that are not relevant (the db api is not used by placement) 1.4.10 Fix the Database Fixture to be just one database 1.4.11 Disable migrations that can't work (because of dependencies on nova code, 014 and 030 are examples) # INPUT DESIRED HERE AND ON SCHEMA MIGRATIONS IN GENERAL 030 is okay as long as nothing goes wrong. If something does it raises exceptions which would currently fail as the exceptions are not there. See below for more about exceptions. 1.4.12 Incrementally get tests working 1.4.13 Fix pep8 1.5 Make zuul pep, unit and functional voting This is where we are now at https://review.openstack.org/#/c/599416/ 1.6 Create tools for db table sync/create It made some TODOs about this in setup.cfg, also nothing that in additional to a placement-manage we'll want a placement-status. 1.7 Concurrently go to step 2, where the harder magic happens. 1.8 Find and remove dead code (there will be some). Some dead code has been removed, but there will definitely be plenty more to find. 1.9 Tune up and confirm docs 1.10 Grep for remaining "nova" (as string and spirit) and fix Item 1.4.12 may deserve some discussion. When I've done this the several times before, the strategy I've used is to be test driven: run either functional or unit tests, find and fix one of the errors revealed, commit, move on. In the patch set that ends with the review linked above, this is pretty much what I did. Switching between a tox run of the full suite and using testtools.run to run an individual test file. 2. We have a stack of changes to zuul jobs that show nova working but deploying placement in devstack from the new repo instead of nova's repo. This includes the grenade job, ensuring that upgrade works. Do people have the time or info needed to break this step down into multiple steps like the '1' section above. Things I can think of: * devstack patch to deploy placement from the new repo * and use placement.conf * stripping of placement out of nova, a bit like https://review.openstack.org/#/c/596291/ , unless we leave that enitrely to step 4 * grenade tweaks (?) * more 3. When those pass, we merge them, effectively orphaning nova's copy of placement. Switch those jobs to voting. 4. Finally, we delete the orphaned code from nova (without needing to make any changes to non-placement-only test code -- code is truly orphaned). Some questions I have: * Presumably we can trim the placement DB migrations to just stuff that is relevant to placement and renumber accordingly? * Could we also make it so we only run the migrations if we are not in a fresh install? In a fresh install we ought to be able to skip the migrations entirely and create the tables by reflection with the class models [1]. * I had another but I forgot. [1] I did something similar to placedock for when starting from scratch: https://github.com/cdent/placedock/blob/b5ca753a0d97e0d9a324e196349e3a19eb62668b/sync.py#L68-L73 -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent__ OpenStack
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On Aug 28, 2018, at 10:47 AM, Matt Riedemann wrote: > >> 1.1 Run the git filter-branch on a copy of nova >> 1.1.1 Add missing files to the file list: >> 1.1.1.1 .gitignore >> 1.1.1.2 # ANYTHING ELSE? > > Unless I were to actually run the git filter-branch tooling to see what is > excluded from the new repo, I can't really say what is missing at this time. > I assume it would be clear during review - which is why I'm asking that we do > this stuff in gerrit where we do reviews. Since I have run this tool a few times, I can answer that. The tool removes all files and their history from git, saving only those you explicitly ask to keep. Every commit involving those files is kept, along with any other files that were part of that commit. The end result is a much smaller directory tree, and a much smaller .git directory (513M -> 113M). Because the history is *removed*, running `git diff @^` on the result will not show the many files deleted by the history filter. So if you were looking for a diff in gerrit that shows all those deletions, it won’t be there. You can do a regular linux diff of the filtered directory and a nova directory to get a list of what has been removed, but that can be somewhat messy. I just want to set expectations when reviewing the extracted code in gerrit. -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
> Grenade already has it's own "resources db" right? So we can shove > things in there before we upgrade and then verify they are still there > after the upgrade? Yep, I'm working on something right now. We create an instance that survives the upgrade and validate it on the other side. I'll just do some basic inventory and allocation validation that we'll trip over if we somehow don't migrate that data from nova to placement. --Dan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On 8/28/2018 10:57 AM, Dan Smith wrote: The from-rocky will also need to extract data from the nova-api database for the placement tables and put it into the new placement database (as real operators will have to do). It'll need to do this after the split code has been installed and the schema has been sync'd. Without this, the pre-upgrade resources won't have allocations known by the split placement service. I do not think we should cheat by just pointing the split placement at nova's database. Yes excellent points. Also, ISTR you added some allocation/inventory checking to devstack via hook, maybe after the tempest job ran? We might want to add some stuff to grenade to verify the pre/post resource allocations before we start this move so we can make sure they're still good after we roll. I'll see if I can hack something up to that effect. It's in nova: https://github.com/openstack/nova/blob/8b4fcdfdc6c59e024e7639e0d2da6ccbea5c73d3/gate/post_test_hook.sh#L55 And only run in the nova-next job: https://github.com/openstack/nova/blob/8b4fcdfdc6c59e024e7639e0d2da6ccbea5c73d3/playbooks/legacy/nova-next/run.yaml#L62 Grenade already has it's own "resources db" right? So we can shove things in there before we upgrade and then verify they are still there after the upgrade? The post-tempest check I added to nova is looking for orphaned allocations, meaning we successfully completed some operation, like resize for example, but failed to cleanup after ourselves (which we missed quite a bit of that in Pike). -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On Tue, 28 Aug 2018, Matt Riedemann wrote: Are people okay with that and willing to commit to being okay with that answer in reviews? To some extent we need to have some faith on the end result: the tests work. If people are not okay with that, we need the people who are not to determine and prove the alternate strategy. I've had this one work and work well. Seems reasonable to me. But to be clear, if there are 70 failed tests, are you going to have 70 separate patches? Or this is just one of those things where you start with 70, fix something, get down to 50 failed tests, and iterate until you're down to all passing. If so, I'm OK with that. It's hard to say without knowing how many patches get from 70 failures to 0 and what the size/complexity of those changes is, but without knowing I'd default to the incremental approach for ease of review. It's lumpy. But at least at the begining it will be something like: 0 passing, stil 0 passing; still 0 passing; still 0 passing; 150 passing, 700 failing; 295 passing, X failing, etc. Because in the early stages, test discovery and listing doesn't work at all, for quite a few different reasons. Based on the discussion here, resolving those "different reasons" is things people want to see in different commits. One way to optimize this (if people preferred) would be to not use stestr as called by tox, with its built in test discovery, but instead run testtools or subunit in a non-parallel and failfast where not all tests need to be discovered first. That would provide a more visible sense of "it's getting better" to someone who is running the tests locally using that alternate method, but would not do much for the jobs run by zuul, so probably not all that useful. Thanks for the other info on the devstack and grenade stuff. If I read you right, from your perspective it's a case of "we'll see" and "we'll figure it out", which sounds good to me. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
> Grenade uses devstack so once we have devstack on master installing > (and configuring) placement from the new repo and disable installing > and configuring it from the nova repo, that's the majority of the > change I'd think. > > Grenade will likely need a from-rocky script to move any config that > is necessary, but as you already noted below, if the new repo can live > with an existing nova.conf, then we might not need to do anything in > grenade since placement from the new repo (in stein) could then run > with nova.conf created for placement from the nova repo (in rocky). The from-rocky will also need to extract data from the nova-api database for the placement tables and put it into the new placement database (as real operators will have to do). It'll need to do this after the split code has been installed and the schema has been sync'd. Without this, the pre-upgrade resources won't have allocations known by the split placement service. I do not think we should cheat by just pointing the split placement at nova's database. Also, ISTR you added some allocation/inventory checking to devstack via hook, maybe after the tempest job ran? We might want to add some stuff to grenade to verify the pre/post resource allocations before we start this move so we can make sure they're still good after we roll. I'll see if I can hack something up to that effect. --Dan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
Forgive me for barging into this, but just with my deployer and PTL of a deployment project hat on.. As part of the split, wouldn't we *not* need to make a devstack change if this is done correctly because placement will become a nova dependency, which is pulled out of Git and when using Zuul, will test the specific commit in question. From devstack's POV, deploying the way things are shouldn't change (except for when we decide to deploy placement separately).. but I believe in the process, both should technically work? (and if devstack breaks, then maybe we'll be breaking downstream users?) Thanks, Mohammed On Tue, Aug 28, 2018 at 11:47 AM Matt Riedemann wrote: > > On 8/28/2018 6:20 AM, Chris Dent wrote: > > On Mon, 27 Aug 2018, melanie witt wrote: > > > >> I think we should use the openstack review system (gerrit) for moving > >> the code. We're moving a critical piece of nova to its own repo and I > >> think it's worth having the review and history contained in the > >> openstack review system. > > > > This seems a reasonable enough strategy, in broad strokes. I want to > > be sure that we're all actually in agreement on the details, as > > we've had a few false starts and I think some of the details are > > getting confused in the shuffle and the general busy-ness in progress. > > > > Is anyone aware of anyone who hasn't commented yet that should? If > > you are, please poke them so we don't surprise them. > > > >> Using smaller changes that make it easy to see import vs content > >> changes might make review faster than fewer, larger changes. > > > > I _think_ we ought to be able to use the existing commits from the > > runs-throughs-to-passing-tests already done, but if we use the > > strategy described below it doesn't really matter: the TDD approach > > (after fixing paths and test config) is pretty fast. > > > >> The most important bit of all of this is making sure we don't break > >> anything in the process for operators and users consuming nova and > >> placement, and ensure the upgrade path from rocky => stein is tested > >> in grenade. > > > > This is one of the areas where pretty active support from all of > > nova will be required: getting zuul, upgrade paths, and the like > > clearly defined and executed. > > > >> The steps I think we should take are: > >> > >> 1. We copy the placement code into the openstack/placement repo and > >> have it passing all of its own unit and functional tests. > > > > To break that down to more detail, how does this look? > > (note the ALL CAPS where more than acknowledgement is requested) > > > > 1.1 Run the git filter-branch on a copy of nova > > 1.1.1 Add missing files to the file list: > >1.1.1.1 .gitignore > >1.1.1.2 # ANYTHING ELSE? > > Unless I were to actually run the git filter-branch tooling to see what > is excluded from the new repo, I can't really say what is missing at > this time. I assume it would be clear during review - which is why I'm > asking that we do this stuff in gerrit where we do reviews. > > > 1.2 Push -f that thing, acknowledge to be broken, to a seed repo on github > > (ed's repo should be fine) > > 1.3 Do the repo creation bits described in > > https://docs.openstack.org/infra/manual/creators.html > > to seed openstack/placement > > 1.3.1 set zuul jobs. Either to noop-jobs, or non voting basic > > func and unit # INPUT DESIRED HERE > > Agree. As I said to gibi elsewhere in this thread, I would hold off on > adding a tempest-full job to the repo until we're at the end. > > > 1.4 Once the repo exists with some content, incrementally bring it to > > working > > 1.4.1 Update tox.ini to be placement oriented > > 1.4.2 Update setup.cfg to be placement oriented > > 1.4.3 Correct .stesr.conf > > 1.4.4 Move base of placement to "right" place > > 1.4.5 Move unit and functionals to right place > > 1.4.6 Do automated path fixings > > 1.4.7 Set up translation domain and i18n.py corectly > > 1.4.8 Trim placement/conf to just the conf settings required > >(api, base, database, keystone, paths, placement) > > 1.4.9 Remove database files that are not relevant (the db api is > >not used by placement) > > 1.4.10 Fix the Database Fixture to be just one database > > 1.4.11 Disable migrations that can't work (because of > > dependencies on nova code, 014 and 030 are examples) > > # INPUT DESIRED HERE AND ON SCHEMA MIGRATIONS IN GENERAL > > 1.4.12 Incrementally get tests working > > 1.4.13 Fix pep8 > > 1.5 Make zuul pep, unit and functional voting > > 1.6 Create tools for db table sync/create > > 1.7 Concurrently go to step 2, where the harder magic happens. > > 1.8 Find and remove dead code (there will be some). > > 1.9 Tune up and confirm docs > > 1.10 Grep for remaining "nova" (as string and spirit) and fix > > > > > > Item 1.4.12 may deserve some discussion. When I've done
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On 8/28/2018 6:20 AM, Chris Dent wrote: On Mon, 27 Aug 2018, melanie witt wrote: I think we should use the openstack review system (gerrit) for moving the code. We're moving a critical piece of nova to its own repo and I think it's worth having the review and history contained in the openstack review system. This seems a reasonable enough strategy, in broad strokes. I want to be sure that we're all actually in agreement on the details, as we've had a few false starts and I think some of the details are getting confused in the shuffle and the general busy-ness in progress. Is anyone aware of anyone who hasn't commented yet that should? If you are, please poke them so we don't surprise them. Using smaller changes that make it easy to see import vs content changes might make review faster than fewer, larger changes. I _think_ we ought to be able to use the existing commits from the runs-throughs-to-passing-tests already done, but if we use the strategy described below it doesn't really matter: the TDD approach (after fixing paths and test config) is pretty fast. The most important bit of all of this is making sure we don't break anything in the process for operators and users consuming nova and placement, and ensure the upgrade path from rocky => stein is tested in grenade. This is one of the areas where pretty active support from all of nova will be required: getting zuul, upgrade paths, and the like clearly defined and executed. The steps I think we should take are: 1. We copy the placement code into the openstack/placement repo and have it passing all of its own unit and functional tests. To break that down to more detail, how does this look? (note the ALL CAPS where more than acknowledgement is requested) 1.1 Run the git filter-branch on a copy of nova 1.1.1 Add missing files to the file list: 1.1.1.1 .gitignore 1.1.1.2 # ANYTHING ELSE? Unless I were to actually run the git filter-branch tooling to see what is excluded from the new repo, I can't really say what is missing at this time. I assume it would be clear during review - which is why I'm asking that we do this stuff in gerrit where we do reviews. 1.2 Push -f that thing, acknowledge to be broken, to a seed repo on github (ed's repo should be fine) 1.3 Do the repo creation bits described in https://docs.openstack.org/infra/manual/creators.html to seed openstack/placement 1.3.1 set zuul jobs. Either to noop-jobs, or non voting basic func and unit # INPUT DESIRED HERE Agree. As I said to gibi elsewhere in this thread, I would hold off on adding a tempest-full job to the repo until we're at the end. 1.4 Once the repo exists with some content, incrementally bring it to working 1.4.1 Update tox.ini to be placement oriented 1.4.2 Update setup.cfg to be placement oriented 1.4.3 Correct .stesr.conf 1.4.4 Move base of placement to "right" place 1.4.5 Move unit and functionals to right place 1.4.6 Do automated path fixings 1.4.7 Set up translation domain and i18n.py corectly 1.4.8 Trim placement/conf to just the conf settings required (api, base, database, keystone, paths, placement) 1.4.9 Remove database files that are not relevant (the db api is not used by placement) 1.4.10 Fix the Database Fixture to be just one database 1.4.11 Disable migrations that can't work (because of dependencies on nova code, 014 and 030 are examples) # INPUT DESIRED HERE AND ON SCHEMA MIGRATIONS IN GENERAL 1.4.12 Incrementally get tests working 1.4.13 Fix pep8 1.5 Make zuul pep, unit and functional voting 1.6 Create tools for db table sync/create 1.7 Concurrently go to step 2, where the harder magic happens. 1.8 Find and remove dead code (there will be some). 1.9 Tune up and confirm docs 1.10 Grep for remaining "nova" (as string and spirit) and fix Item 1.4.12 may deserve some discussion. When I've done this the several times before, the strategy I've used is to be test driven: run either functional or unit tests, find and fix one of the errors revealed, commit, move on. This strategy has worked very well for me because of the "test driven" part, but I'm hesitant to do it if reviewers are going to get to a patch and say "why didn't you also change X?" The answer to that question is "because this is incremental and test driven and the tests didn't demand that change (yet)". Sometimes that will mean that things of the same class of change are in different commits. Are people okay with that and willing to commit to being okay with that answer in reviews? To some extent we need to have some faith on the end result: the tests work. If people are not okay with that, we need the people who are not to determine and prove the alternate strategy. I've had this one work and work well. Seems reasonable to me. But to be clear, if there are 70 failed tests, are you going to have 70
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On 8/28/2018 8:11 AM, Balázs Gibizer wrote: I also think that we can add a non-voting tempest full job as well. Making it green depends on how hard to deploy placement from the new repo to tempest. I think as soon as placement repo has passing gabbits (e.g functional job) and we can deploy placement in tempest then tempest will be green soon. There is likely no point in this until devstack itself is installing and using placement from the new repo rather than from nova. Because otherwise this job will be using devstack which still installs placement from nova and the job will pass but not actually test anything on the placement change in question. Even if it did run on the placement change from the placement repo, the job will be a time sink known failure until we get to the end of the series. It's at the end of the series where we declare that placement in the new repo is ready to go and passing all of it's own unit/functional tests that I think we add in the tempest-full job with a dependency on a devstack change which flips from which repo we install. -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
>> 2. We have a stack of changes to zuul jobs that show nova working but >> deploying placement in devstack from the new repo instead of nova's >> repo. This includes the grenade job, ensuring that upgrade works. > > I'm guessing there would need to be changes to Devstack itself, outside > of the zuul jobs? I think we'll need changes to devstack itself, as well as grenade, as well as zuul jobs I'd assume. Otherwise, this sequence of steps is what I've been anticipating. --Dan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On Tue, Aug 28, 2018 at 1:20 PM, Chris Dent wrote: On Mon, 27 Aug 2018, melanie witt wrote: I think we should use the openstack review system (gerrit) for moving the code. We're moving a critical piece of nova to its own repo and I think it's worth having the review and history contained in the openstack review system. This seems a reasonable enough strategy, in broad strokes. I want to be sure that we're all actually in agreement on the details, as we've had a few false starts and I think some of the details are getting confused in the shuffle and the general busy-ness in progress. Is anyone aware of anyone who hasn't commented yet that should? If you are, please poke them so we don't surprise them. Using smaller changes that make it easy to see import vs content changes might make review faster than fewer, larger changes. I _think_ we ought to be able to use the existing commits from the runs-throughs-to-passing-tests already done, but if we use the strategy described below it doesn't really matter: the TDD approach (after fixing paths and test config) is pretty fast. The most important bit of all of this is making sure we don't break anything in the process for operators and users consuming nova and placement, and ensure the upgrade path from rocky => stein is tested in grenade. This is one of the areas where pretty active support from all of nova will be required: getting zuul, upgrade paths, and the like clearly defined and executed. The steps I think we should take are: 1. We copy the placement code into the openstack/placement repo and have it passing all of its own unit and functional tests. To break that down to more detail, how does this look? (note the ALL CAPS where more than acknowledgement is requested) 1.1 Run the git filter-branch on a copy of nova 1.1.1 Add missing files to the file list: 1.1.1.1 .gitignore 1.1.1.2 # ANYTHING ELSE? 1.2 Push -f that thing, acknowledge to be broken, to a seed repo on github (ed's repo should be fine) 1.3 Do the repo creation bits described in https://docs.openstack.org/infra/manual/creators.html to seed openstack/placement 1.3.1 set zuul jobs. Either to noop-jobs, or non voting basic func and unit # INPUT DESIRED HERE I suggest to add a non-voting unit and functional job and iterate on the repo to make them green, then turn them to voting. I also think that we can add a non-voting tempest full job as well. Making it green depends on how hard to deploy placement from the new repo to tempest. I think as soon as placement repo has passing gabbits (e.g functional job) and we can deploy placement in tempest then tempest will be green soon. 1.4 Once the repo exists with some content, incrementally bring it to working 1.4.1 Update tox.ini to be placement oriented 1.4.2 Update setup.cfg to be placement oriented 1.4.3 Correct .stesr.conf 1.4.4 Move base of placement to "right" place 1.4.5 Move unit and functionals to right place 1.4.6 Do automated path fixings 1.4.7 Set up translation domain and i18n.py corectly 1.4.8 Trim placement/conf to just the conf settings required (api, base, database, keystone, paths, placement) 1.4.9 Remove database files that are not relevant (the db api is not used by placement) 1.4.10 Fix the Database Fixture to be just one database 1.4.11 Disable migrations that can't work (because of dependencies on nova code, 014 and 030 are examples) # INPUT DESIRED HERE AND ON SCHEMA MIGRATIONS IN GENERAL 1.4.12 Incrementally get tests working 1.4.13 Fix pep8 1.5 Make zuul pep, unit and functional voting 1.6 Create tools for db table sync/create 1.7 Concurrently go to step 2, where the harder magic happens. 1.8 Find and remove dead code (there will be some). 1.9 Tune up and confirm docs 1.10 Grep for remaining "nova" (as string and spirit) and fix Item 1.4.12 may deserve some discussion. When I've done this the several times before, the strategy I've used is to be test driven: run either functional or unit tests, find and fix one of the errors revealed, commit, move on. This strategy has worked very well for me because of the "test driven" part, but I'm hesitant to do it if reviewers are going to get to a patch and say "why didn't you also change X?" The answer to that question is "because this is incremental and test driven and the tests didn't demand that change (yet)". Sometimes that will mean that things of the same class of change are in different commits. Are people okay with that and willing to commit to being okay with that answer in reviews? To some extent we need to have some faith on the end result: the tests work. If people are not okay with that, we need the people who are not to determine and prove the alternate strategy. I've had this one work and work well. I like this test driven approach. If I start to leave comments like "why didn't you
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On Mon, Aug 27, 2018 at 5:31 PM, Matt Riedemann wrote: On 8/24/2018 7:36 AM, Chris Dent wrote: Over the past few days a few of us have been experimenting with extracting placement to its own repo, as has been discussed at length on this list, and in some etherpads: https://etherpad.openstack.org/p/placement-extract-stein https://etherpad.openstack.org/p/placement-extraction-file-notes As part of that, I've been doing some exploration to tease out the issues we're going to hit as we do it. None of this is work that will be merged, rather it is stuff to figure out what we need to know to do the eventual merging correctly and efficiently. Please note that doing that is just the near edge of a large collection of changes that will cascade in many ways to many projects, tools, distros, etc. The people doing this are aware of that, and the relative simplicity (and fairly immediate success) of these experiments is not misleading people into thinking "hey, no big deal". It's a big deal. There's a strategy now (described at the end of the first etherpad listed above) for trimming the nova history to create a thing which is placement. From the first run of that Ed created a github repo and I branched that to eventually create: https://github.com/EdLeafe/placement/pull/2 In that, all the placement unit and functional tests are now passing, and my placecat [1] integration suite also passes. That work has highlighted some gaps in the process for trimming history which will be refined to create another interim repo. We'll repeat this until the process is smooth, eventually resulting in an openstack/placement. We talked about the github strategy a bit in the placement meeting today [1]. Without being involved in this technical extraction work for the past few weeks, I came in with a different perspective on the end-game, and it was not aligned with what Chris/Ed thought as far as how we get to the official openstack/placement repo. At a high level, Ed's repo [2] is a fork of nova with large changes on top using pull requests to do things like remove the non-placement nova files, update import paths (because the import structure changes from nova.api.openstack.placement to just placement), and then changes from Chris [3] to get tests working. Then the idea was to just use that to seed the openstack/placement repo and rather than review the changes along the way*, people that care about what changed (like myself) would see the tests passing and be happy enough. However, I disagree with this approach since it bypasses our community code review system of using Gerrit and relying on a core team to approve changes at the sake of expediency. What I would like to see are the changes that go into making the seed repo and what gets it to passing tests done in gerrit like we do for everything else. There are a couple of options on how this is done though: 1. Seed the openstack/placement repo with the filter_git_history.sh script output as Ed has done here [4]. This would include moving the placement files to the root of the tree and dropping nova-specific files. Then make incremental changes in gerrit like with [5] and the individual changes which make up Chris's big pull request [3]. I am primarily interested in making sure there are not content changes happening, only mechanical tree-restructuring type changes, stuff like that. I'm asking for more changes in gerrit so they can be sanely reviewed (per normal). 2. Eric took a slightly different tack in that he's OK with just a couple of large changes (or even large patch sets within a single change) in gerrit rather than ~30 individual changes. So that would be more like at most 3 changes in gerrit for [4][5][3]. 3. The 3rd option is we just don't use gerrit at all and seed the official repo with the results of Chris and Ed's work in Ed's repo in github. Clearly this would be the fastest way to get us to a new repo (at the expense of bucking community code review and development process - is an exception worth it?). I assumed that the work on github was done to _discover_ what steps needs to be done later to populate the new repo and make the tests pass. So I more like the #1 approach. Option 1 would clearly be a drain on at least 2 nova cores to go through the changes. I think Eric is on board for reviewing options 1 or 2 in either case, but he prefers option 2. Since I'm throwing a wrench in the works, I also need to stand up and review the changes if we go with option 1 or 2. Jay said he'd review them but consider these reviews lower priority. I expect we could get some help from some other nova cores though, maybe not on all changes, but at least some (thinking gibi, alex_xu, sfinucan). I will spend time reviewing the patches coming for the new placement repo. Cheers, gibi Any CI jobs would be non-voting while going through options 1 or 2 until we get to a point that tests should finally be
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On Mon, 27 Aug 2018, melanie witt wrote: I think we should use the openstack review system (gerrit) for moving the code. We're moving a critical piece of nova to its own repo and I think it's worth having the review and history contained in the openstack review system. This seems a reasonable enough strategy, in broad strokes. I want to be sure that we're all actually in agreement on the details, as we've had a few false starts and I think some of the details are getting confused in the shuffle and the general busy-ness in progress. Is anyone aware of anyone who hasn't commented yet that should? If you are, please poke them so we don't surprise them. Using smaller changes that make it easy to see import vs content changes might make review faster than fewer, larger changes. I _think_ we ought to be able to use the existing commits from the runs-throughs-to-passing-tests already done, but if we use the strategy described below it doesn't really matter: the TDD approach (after fixing paths and test config) is pretty fast. The most important bit of all of this is making sure we don't break anything in the process for operators and users consuming nova and placement, and ensure the upgrade path from rocky => stein is tested in grenade. This is one of the areas where pretty active support from all of nova will be required: getting zuul, upgrade paths, and the like clearly defined and executed. The steps I think we should take are: 1. We copy the placement code into the openstack/placement repo and have it passing all of its own unit and functional tests. To break that down to more detail, how does this look? (note the ALL CAPS where more than acknowledgement is requested) 1.1 Run the git filter-branch on a copy of nova 1.1.1 Add missing files to the file list: 1.1.1.1 .gitignore 1.1.1.2 # ANYTHING ELSE? 1.2 Push -f that thing, acknowledge to be broken, to a seed repo on github (ed's repo should be fine) 1.3 Do the repo creation bits described in https://docs.openstack.org/infra/manual/creators.html to seed openstack/placement 1.3.1 set zuul jobs. Either to noop-jobs, or non voting basic func and unit # INPUT DESIRED HERE 1.4 Once the repo exists with some content, incrementally bring it to working 1.4.1 Update tox.ini to be placement oriented 1.4.2 Update setup.cfg to be placement oriented 1.4.3 Correct .stesr.conf 1.4.4 Move base of placement to "right" place 1.4.5 Move unit and functionals to right place 1.4.6 Do automated path fixings 1.4.7 Set up translation domain and i18n.py corectly 1.4.8 Trim placement/conf to just the conf settings required (api, base, database, keystone, paths, placement) 1.4.9 Remove database files that are not relevant (the db api is not used by placement) 1.4.10 Fix the Database Fixture to be just one database 1.4.11 Disable migrations that can't work (because of dependencies on nova code, 014 and 030 are examples) # INPUT DESIRED HERE AND ON SCHEMA MIGRATIONS IN GENERAL 1.4.12 Incrementally get tests working 1.4.13 Fix pep8 1.5 Make zuul pep, unit and functional voting 1.6 Create tools for db table sync/create 1.7 Concurrently go to step 2, where the harder magic happens. 1.8 Find and remove dead code (there will be some). 1.9 Tune up and confirm docs 1.10 Grep for remaining "nova" (as string and spirit) and fix Item 1.4.12 may deserve some discussion. When I've done this the several times before, the strategy I've used is to be test driven: run either functional or unit tests, find and fix one of the errors revealed, commit, move on. This strategy has worked very well for me because of the "test driven" part, but I'm hesitant to do it if reviewers are going to get to a patch and say "why didn't you also change X?" The answer to that question is "because this is incremental and test driven and the tests didn't demand that change (yet)". Sometimes that will mean that things of the same class of change are in different commits. Are people okay with that and willing to commit to being okay with that answer in reviews? To some extent we need to have some faith on the end result: the tests work. If people are not okay with that, we need the people who are not to determine and prove the alternate strategy. I've had this one work and work well. Please help to refine the above, thank you. 2. We have a stack of changes to zuul jobs that show nova working but deploying placement in devstack from the new repo instead of nova's repo. This includes the grenade job, ensuring that upgrade works. If we can make a list for this (and the subsequent) major items that is as detailed as I've made for step 1 above, I think that will help us avoid some of the confusion and frustration that comes up. I'm neither able nor willing to be responsible for creating those lists for all these points, but very happy to help. 3. When those
Re: [openstack-dev] [nova] [placement] extraction (technical) update
2018-08-27 23:31 GMT+08:00 Matt Riedemann : > On 8/24/2018 7:36 AM, Chris Dent wrote: > >> >> Over the past few days a few of us have been experimenting with >> extracting placement to its own repo, as has been discussed at >> length on this list, and in some etherpads: >> >> https://etherpad.openstack.org/p/placement-extract-stein >> https://etherpad.openstack.org/p/placement-extraction-file-notes >> >> As part of that, I've been doing some exploration to tease out the >> issues we're going to hit as we do it. None of this is work that >> will be merged, rather it is stuff to figure out what we need to >> know to do the eventual merging correctly and efficiently. >> >> Please note that doing that is just the near edge of a large >> collection of changes that will cascade in many ways to many >> projects, tools, distros, etc. The people doing this are aware of >> that, and the relative simplicity (and fairly immediate success) of >> these experiments is not misleading people into thinking "hey, no >> big deal". It's a big deal. >> >> There's a strategy now (described at the end of the first etherpad >> listed above) for trimming the nova history to create a thing which >> is placement. From the first run of that Ed created a github repo >> and I branched that to eventually create: >> >> https://github.com/EdLeafe/placement/pull/2 >> >> In that, all the placement unit and functional tests are now >> passing, and my placecat [1] integration suite also passes. >> >> That work has highlighted some gaps in the process for trimming >> history which will be refined to create another interim repo. We'll >> repeat this until the process is smooth, eventually resulting in an >> openstack/placement. >> > > We talked about the github strategy a bit in the placement meeting today > [1]. Without being involved in this technical extraction work for the past > few weeks, I came in with a different perspective on the end-game, and it > was not aligned with what Chris/Ed thought as far as how we get to the > official openstack/placement repo. > > At a high level, Ed's repo [2] is a fork of nova with large changes on top > using pull requests to do things like remove the non-placement nova files, > update import paths (because the import structure changes from > nova.api.openstack.placement to just placement), and then changes from > Chris [3] to get tests working. Then the idea was to just use that to seed > the openstack/placement repo and rather than review the changes along the > way*, people that care about what changed (like myself) would see the tests > passing and be happy enough. > > However, I disagree with this approach since it bypasses our community > code review system of using Gerrit and relying on a core team to approve > changes at the sake of expediency. > > What I would like to see are the changes that go into making the seed repo > and what gets it to passing tests done in gerrit like we do for everything > else. There are a couple of options on how this is done though: > > 1. Seed the openstack/placement repo with the filter_git_history.sh script > output as Ed has done here [4]. This would include moving the placement > files to the root of the tree and dropping nova-specific files. Then make > incremental changes in gerrit like with [5] and the individual changes > which make up Chris's big pull request [3]. I am primarily interested in > making sure there are not content changes happening, only mechanical > tree-restructuring type changes, stuff like that. I'm asking for more > changes in gerrit so they can be sanely reviewed (per normal). > > 2. Eric took a slightly different tack in that he's OK with just a couple > of large changes (or even large patch sets within a single change) in > gerrit rather than ~30 individual changes. So that would be more like at > most 3 changes in gerrit for [4][5][3]. > > 3. The 3rd option is we just don't use gerrit at all and seed the official > repo with the results of Chris and Ed's work in Ed's repo in github. > Clearly this would be the fastest way to get us to a new repo (at the > expense of bucking community code review and development process - is an > exception worth it?). > > Option 1 would clearly be a drain on at least 2 nova cores to go through > the changes. I think Eric is on board for reviewing options 1 or 2 in > either case, but he prefers option 2. Since I'm throwing a wrench in the > works, I also need to stand up and review the changes if we go with option > 1 or 2. Jay said he'd review them but consider these reviews lower > priority. I expect we could get some help from some other nova cores > though, maybe not on all changes, but at least some (thinking gibi, > alex_xu, sfinucan). > I can help some. And yes, small change is good than huge change. > > Any CI jobs would be non-voting while going through options 1 or 2 until > we get to a point that tests should finally be passing and we can make them > voting (it should be possible to
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On Mon, 2018-08-27 at 14:23 -0700, melanie witt wrote: > On Mon, 27 Aug 2018 10:31:50 -0500, Matt Riedemann wrote: > > On 8/24/2018 7:36 AM, Chris Dent wrote: > > > > > > Over the past few days a few of us have been experimenting with > > > extracting placement to its own repo, as has been discussed at > > > length on this list, and in some etherpads: > > > > > > https://etherpad.openstack.org/p/placement-extract-stein > > > https://etherpad.openstack.org/p/placement-extraction-file-notes > > > > > > As part of that, I've been doing some exploration to tease out the > > > issues we're going to hit as we do it. None of this is work that > > > will be merged, rather it is stuff to figure out what we need to > > > know to do the eventual merging correctly and efficiently. > > > > > > Please note that doing that is just the near edge of a large > > > collection of changes that will cascade in many ways to many > > > projects, tools, distros, etc. The people doing this are aware of > > > that, and the relative simplicity (and fairly immediate success) of > > > these experiments is not misleading people into thinking "hey, no > > > big deal". It's a big deal. > > > > > > There's a strategy now (described at the end of the first etherpad > > > listed above) for trimming the nova history to create a thing which > > > is placement. From the first run of that Ed created a github repo > > > and I branched that to eventually create: > > > > > > https://github.com/EdLeafe/placement/pull/2 > > > > > > In that, all the placement unit and functional tests are now > > > passing, and my placecat [1] integration suite also passes. > > > > > > That work has highlighted some gaps in the process for trimming > > > history which will be refined to create another interim repo. We'll > > > repeat this until the process is smooth, eventually resulting in an > > > openstack/placement. > > > > We talked about the github strategy a bit in the placement meeting today > > [1]. Without being involved in this technical extraction work for the > > past few weeks, I came in with a different perspective on the end-game, > > and it was not aligned with what Chris/Ed thought as far as how we get > > to the official openstack/placement repo. > > > > At a high level, Ed's repo [2] is a fork of nova with large changes on > > top using pull requests to do things like remove the non-placement nova > > files, update import paths (because the import structure changes from > > nova.api.openstack.placement to just placement), and then changes from > > Chris [3] to get tests working. Then the idea was to just use that to > > seed the openstack/placement repo and rather than review the changes > > along the way*, people that care about what changed (like myself) would > > see the tests passing and be happy enough. > > > > However, I disagree with this approach since it bypasses our community > > code review system of using Gerrit and relying on a core team to approve > > changes at the sake of expediency. > > > > What I would like to see are the changes that go into making the seed > > repo and what gets it to passing tests done in gerrit like we do for > > everything else. There are a couple of options on how this is done though: > > > > 1. Seed the openstack/placement repo with the filter_git_history.sh > > script output as Ed has done here [4]. This would include moving the > > placement files to the root of the tree and dropping nova-specific > > files. Then make incremental changes in gerrit like with [5] and the > > individual changes which make up Chris's big pull request [3]. I am > > primarily interested in making sure there are not content changes > > happening, only mechanical tree-restructuring type changes, stuff like > > that. I'm asking for more changes in gerrit so they can be sanely > > reviewed (per normal). > > > > 2. Eric took a slightly different tack in that he's OK with just a > > couple of large changes (or even large patch sets within a single > > change) in gerrit rather than ~30 individual changes. So that would be > > more like at most 3 changes in gerrit for [4][5][3]. > > > > 3. The 3rd option is we just don't use gerrit at all and seed the > > official repo with the results of Chris and Ed's work in Ed's repo in > > github. Clearly this would be the fastest way to get us to a new repo > > (at the expense of bucking community code review and development process > > - is an exception worth it?). > > > > Option 1 would clearly be a drain on at least 2 nova cores to go through > > the changes. I think Eric is on board for reviewing options 1 or 2 in > > either case, but he prefers option 2. Since I'm throwing a wrench in the > > works, I also need to stand up and review the changes if we go with > > option 1 or 2. Jay said he'd review them but consider these reviews > > lower priority. I expect we could get some help from some other nova > > cores though, maybe not on all changes, but at least some (thinking >
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On Mon, 27 Aug 2018 10:31:50 -0500, Matt Riedemann wrote: On 8/24/2018 7:36 AM, Chris Dent wrote: Over the past few days a few of us have been experimenting with extracting placement to its own repo, as has been discussed at length on this list, and in some etherpads: https://etherpad.openstack.org/p/placement-extract-stein https://etherpad.openstack.org/p/placement-extraction-file-notes As part of that, I've been doing some exploration to tease out the issues we're going to hit as we do it. None of this is work that will be merged, rather it is stuff to figure out what we need to know to do the eventual merging correctly and efficiently. Please note that doing that is just the near edge of a large collection of changes that will cascade in many ways to many projects, tools, distros, etc. The people doing this are aware of that, and the relative simplicity (and fairly immediate success) of these experiments is not misleading people into thinking "hey, no big deal". It's a big deal. There's a strategy now (described at the end of the first etherpad listed above) for trimming the nova history to create a thing which is placement. From the first run of that Ed created a github repo and I branched that to eventually create: https://github.com/EdLeafe/placement/pull/2 In that, all the placement unit and functional tests are now passing, and my placecat [1] integration suite also passes. That work has highlighted some gaps in the process for trimming history which will be refined to create another interim repo. We'll repeat this until the process is smooth, eventually resulting in an openstack/placement. We talked about the github strategy a bit in the placement meeting today [1]. Without being involved in this technical extraction work for the past few weeks, I came in with a different perspective on the end-game, and it was not aligned with what Chris/Ed thought as far as how we get to the official openstack/placement repo. At a high level, Ed's repo [2] is a fork of nova with large changes on top using pull requests to do things like remove the non-placement nova files, update import paths (because the import structure changes from nova.api.openstack.placement to just placement), and then changes from Chris [3] to get tests working. Then the idea was to just use that to seed the openstack/placement repo and rather than review the changes along the way*, people that care about what changed (like myself) would see the tests passing and be happy enough. However, I disagree with this approach since it bypasses our community code review system of using Gerrit and relying on a core team to approve changes at the sake of expediency. What I would like to see are the changes that go into making the seed repo and what gets it to passing tests done in gerrit like we do for everything else. There are a couple of options on how this is done though: 1. Seed the openstack/placement repo with the filter_git_history.sh script output as Ed has done here [4]. This would include moving the placement files to the root of the tree and dropping nova-specific files. Then make incremental changes in gerrit like with [5] and the individual changes which make up Chris's big pull request [3]. I am primarily interested in making sure there are not content changes happening, only mechanical tree-restructuring type changes, stuff like that. I'm asking for more changes in gerrit so they can be sanely reviewed (per normal). 2. Eric took a slightly different tack in that he's OK with just a couple of large changes (or even large patch sets within a single change) in gerrit rather than ~30 individual changes. So that would be more like at most 3 changes in gerrit for [4][5][3]. 3. The 3rd option is we just don't use gerrit at all and seed the official repo with the results of Chris and Ed's work in Ed's repo in github. Clearly this would be the fastest way to get us to a new repo (at the expense of bucking community code review and development process - is an exception worth it?). Option 1 would clearly be a drain on at least 2 nova cores to go through the changes. I think Eric is on board for reviewing options 1 or 2 in either case, but he prefers option 2. Since I'm throwing a wrench in the works, I also need to stand up and review the changes if we go with option 1 or 2. Jay said he'd review them but consider these reviews lower priority. I expect we could get some help from some other nova cores though, maybe not on all changes, but at least some (thinking gibi, alex_xu, sfinucan). Any CI jobs would be non-voting while going through options 1 or 2 until we get to a point that tests should finally be passing and we can make them voting (it should be possible to control this within the repo itself using zuul v3). I would like to know from others (nova core or otherwise) what they would prefer, and if you are a nova core that wants option 1 (or 2) are you willing to help review those incremental changes knowing it will
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On 08/27/2018 11:31 AM, Matt Riedemann wrote: On 8/24/2018 7:36 AM, Chris Dent wrote: Over the past few days a few of us have been experimenting with extracting placement to its own repo, as has been discussed at length on this list, and in some etherpads: https://etherpad.openstack.org/p/placement-extract-stein https://etherpad.openstack.org/p/placement-extraction-file-notes As part of that, I've been doing some exploration to tease out the issues we're going to hit as we do it. None of this is work that will be merged, rather it is stuff to figure out what we need to know to do the eventual merging correctly and efficiently. Please note that doing that is just the near edge of a large collection of changes that will cascade in many ways to many projects, tools, distros, etc. The people doing this are aware of that, and the relative simplicity (and fairly immediate success) of these experiments is not misleading people into thinking "hey, no big deal". It's a big deal. There's a strategy now (described at the end of the first etherpad listed above) for trimming the nova history to create a thing which is placement. From the first run of that Ed created a github repo and I branched that to eventually create: https://github.com/EdLeafe/placement/pull/2 In that, all the placement unit and functional tests are now passing, and my placecat [1] integration suite also passes. That work has highlighted some gaps in the process for trimming history which will be refined to create another interim repo. We'll repeat this until the process is smooth, eventually resulting in an openstack/placement. We talked about the github strategy a bit in the placement meeting today [1]. Without being involved in this technical extraction work for the past few weeks, I came in with a different perspective on the end-game, and it was not aligned with what Chris/Ed thought as far as how we get to the official openstack/placement repo. At a high level, Ed's repo [2] is a fork of nova with large changes on top using pull requests to do things like remove the non-placement nova files, update import paths (because the import structure changes from nova.api.openstack.placement to just placement), and then changes from Chris [3] to get tests working. Then the idea was to just use that to seed the openstack/placement repo and rather than review the changes along the way*, people that care about what changed (like myself) would see the tests passing and be happy enough. However, I disagree with this approach since it bypasses our community code review system of using Gerrit and relying on a core team to approve changes at the sake of expediency. What I would like to see are the changes that go into making the seed repo and what gets it to passing tests done in gerrit like we do for everything else. There are a couple of options on how this is done though: 1. Seed the openstack/placement repo with the filter_git_history.sh script output as Ed has done here [4]. This would include moving the placement files to the root of the tree and dropping nova-specific files. Then make incremental changes in gerrit like with [5] and the individual changes which make up Chris's big pull request [3]. I am primarily interested in making sure there are not content changes happening, only mechanical tree-restructuring type changes, stuff like that. I'm asking for more changes in gerrit so they can be sanely reviewed (per normal). 2. Eric took a slightly different tack in that he's OK with just a couple of large changes (or even large patch sets within a single change) in gerrit rather than ~30 individual changes. So that would be more like at most 3 changes in gerrit for [4][5][3]. 3. The 3rd option is we just don't use gerrit at all and seed the official repo with the results of Chris and Ed's work in Ed's repo in github. Clearly this would be the fastest way to get us to a new repo (at the expense of bucking community code review and development process - is an exception worth it?). Option 1 would clearly be a drain on at least 2 nova cores to go through the changes. I think Eric is on board for reviewing options 1 or 2 in either case, but he prefers option 2. Since I'm throwing a wrench in the works, I also need to stand up and review the changes if we go with option 1 or 2. Jay said he'd review them but consider these reviews lower priority. I expect we could get some help from some other nova cores though, maybe not on all changes, but at least some (thinking gibi, alex_xu, sfinucan). Any CI jobs would be non-voting while going through options 1 or 2 until we get to a point that tests should finally be passing and we can make them voting (it should be possible to control this within the repo itself using zuul v3). I would like to know from others (nova core or otherwise) what they would prefer, and if you are a nova core that wants option 1 (or 2) are you willing to help review
Re: [openstack-dev] [nova] [placement] extraction (technical) update
Thanks Matt, you summed it up nicely. Just one thing to point out... > Option 1 would clearly be a drain on at least 2 nova cores to go through > the changes. I think Eric is on board for reviewing options 1 or 2 in > either case, but he prefers option 2. Since I'm throwing a wrench in the > works, I also need to stand up and review the changes if we go with > option 1 or 2. Jay said he'd review them but consider these reviews > lower priority. I expect we could get some help from some other nova > cores though, maybe not on all changes, but at least some (thinking > gibi, alex_xu, sfinucan). The placement-core team should be seeded and should be the ones on the hook for the reviews. Since we've agreed in the other thread to make placement-core a superset of nova-core, what you've said above is still applicable, but incomplete: I would expect there to be at least one or two additional non-nova-core placement cores willing to do these reviews. (Assuming Ed and/or Chris to be on that team, I would of course expect them to refrain from approving, regardless of who does the gerrit work, since they've both been developing the changes in github.) -efried __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On 8/24/2018 7:36 AM, Chris Dent wrote: Over the past few days a few of us have been experimenting with extracting placement to its own repo, as has been discussed at length on this list, and in some etherpads: https://etherpad.openstack.org/p/placement-extract-stein https://etherpad.openstack.org/p/placement-extraction-file-notes As part of that, I've been doing some exploration to tease out the issues we're going to hit as we do it. None of this is work that will be merged, rather it is stuff to figure out what we need to know to do the eventual merging correctly and efficiently. Please note that doing that is just the near edge of a large collection of changes that will cascade in many ways to many projects, tools, distros, etc. The people doing this are aware of that, and the relative simplicity (and fairly immediate success) of these experiments is not misleading people into thinking "hey, no big deal". It's a big deal. There's a strategy now (described at the end of the first etherpad listed above) for trimming the nova history to create a thing which is placement. From the first run of that Ed created a github repo and I branched that to eventually create: https://github.com/EdLeafe/placement/pull/2 In that, all the placement unit and functional tests are now passing, and my placecat [1] integration suite also passes. That work has highlighted some gaps in the process for trimming history which will be refined to create another interim repo. We'll repeat this until the process is smooth, eventually resulting in an openstack/placement. We talked about the github strategy a bit in the placement meeting today [1]. Without being involved in this technical extraction work for the past few weeks, I came in with a different perspective on the end-game, and it was not aligned with what Chris/Ed thought as far as how we get to the official openstack/placement repo. At a high level, Ed's repo [2] is a fork of nova with large changes on top using pull requests to do things like remove the non-placement nova files, update import paths (because the import structure changes from nova.api.openstack.placement to just placement), and then changes from Chris [3] to get tests working. Then the idea was to just use that to seed the openstack/placement repo and rather than review the changes along the way*, people that care about what changed (like myself) would see the tests passing and be happy enough. However, I disagree with this approach since it bypasses our community code review system of using Gerrit and relying on a core team to approve changes at the sake of expediency. What I would like to see are the changes that go into making the seed repo and what gets it to passing tests done in gerrit like we do for everything else. There are a couple of options on how this is done though: 1. Seed the openstack/placement repo with the filter_git_history.sh script output as Ed has done here [4]. This would include moving the placement files to the root of the tree and dropping nova-specific files. Then make incremental changes in gerrit like with [5] and the individual changes which make up Chris's big pull request [3]. I am primarily interested in making sure there are not content changes happening, only mechanical tree-restructuring type changes, stuff like that. I'm asking for more changes in gerrit so they can be sanely reviewed (per normal). 2. Eric took a slightly different tack in that he's OK with just a couple of large changes (or even large patch sets within a single change) in gerrit rather than ~30 individual changes. So that would be more like at most 3 changes in gerrit for [4][5][3]. 3. The 3rd option is we just don't use gerrit at all and seed the official repo with the results of Chris and Ed's work in Ed's repo in github. Clearly this would be the fastest way to get us to a new repo (at the expense of bucking community code review and development process - is an exception worth it?). Option 1 would clearly be a drain on at least 2 nova cores to go through the changes. I think Eric is on board for reviewing options 1 or 2 in either case, but he prefers option 2. Since I'm throwing a wrench in the works, I also need to stand up and review the changes if we go with option 1 or 2. Jay said he'd review them but consider these reviews lower priority. I expect we could get some help from some other nova cores though, maybe not on all changes, but at least some (thinking gibi, alex_xu, sfinucan). Any CI jobs would be non-voting while going through options 1 or 2 until we get to a point that tests should finally be passing and we can make them voting (it should be possible to control this within the repo itself using zuul v3). I would like to know from others (nova core or otherwise) what they would prefer, and if you are a nova core that wants option 1 (or 2) are you willing to help review those incremental changes knowing it will be a
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On Aug 24, 2018, at 7:36 AM, Chris Dent wrote: > Over the past few days a few of us have been experimenting with > extracting placement to its own repo, as has been discussed at > length on this list, and in some etherpads: > >https://etherpad.openstack.org/p/placement-extract-stein >https://etherpad.openstack.org/p/placement-extraction-file-notes > > As part of that, I've been doing some exploration to tease out the > issues we're going to hit as we do it. None of this is work that > will be merged, rather it is stuff to figure out what we need to > know to do the eventual merging correctly and efficiently. I’ve re-run the extraction, re-arranged the directories, and cleaned up most of the import pathing. The code is here: https://github.com/EdLeafe/placement. I did a forced push to remove the first attempt. -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
>
> After some prompting from gibi, that code has now been adjusted so
> that requirements.txt and tox.ini [1] make sure that the extract
> placement branch is installed into the test virtualenvs. So in the
> gate the unit and functional tests pass. Other jobs do not because
> of [1].
>
> In the intervening time I've taken that code, built a devstack that
> uses a nova-placement-api wsgi script that uses nova.conf and the
> extracted placement code. It runs against the nova-api database.
>
> Created a few servers. Worked.
>
Excellent!
> Then I switched the devstack@placement-unit unit file to point to
> the placement-api wsgi script, and configured
> /etc/placement/placement.conf to have a
> [placement_database]/connection of the nova-api db.
>
> Created a few servers. Worked.
>
> Thanks.
>
> [1] As far as I can tell a requirements.txt entry of
>
> -e
> git+https://github.com/cdent/placement-1.git@cd/make-it-work#egg=placement
>
> will install just fine with 'pip install -r requirements.txt', but
> if I do 'pip install nova' and that line is in requirements.txt it
> does not work. This means I had to change tox.ini to have a deps
> setting of:
>
> deps = -r{toxinidir}/test-requirements.txt
>-r{toxinidir}/requirements.txt
>
> to get the functional and unit tests to build working virtualenvs.
> That this is not happening in the dsvm-based zuul jobs mean that the
> tests can't run or pass. What's going on here? Ideas?
Just conjecture on my part, but I know we have it documented somewhere that URL
paths to requirements are not allowed. Maybe we do something to actively
prevent that?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] extraction (technical) update
On Fri, 24 Aug 2018, Chris Dent wrote:
That work is in gerrit at
https://review.openstack.org/#/c/596291/
with a hopefully clear commit message about what's going on. As with
the rest of this work, this is not something to merge, rather an
experiment to learn from. The hot spots in the changes are
relatively limited and about what you would expect so, with luck,
should be pretty easy to deal with, some of them even before we
actually do any extracting (to enhance the boundaries between the
two services).
After some prompting from gibi, that code has now been adjusted so
that requirements.txt and tox.ini [1] make sure that the extract
placement branch is installed into the test virtualenvs. So in the
gate the unit and functional tests pass. Other jobs do not because
of [1].
In the intervening time I've taken that code, built a devstack that
uses a nova-placement-api wsgi script that uses nova.conf and the
extracted placement code. It runs against the nova-api database.
Created a few servers. Worked.
Then I switched the devstack@placement-unit unit file to point to
the placement-api wsgi script, and configured
/etc/placement/placement.conf to have a
[placement_database]/connection of the nova-api db.
Created a few servers. Worked.
Thanks.
[1] As far as I can tell a requirements.txt entry of
-e
git+https://github.com/cdent/placement-1.git@cd/make-it-work#egg=placement
will install just fine with 'pip install -r requirements.txt', but
if I do 'pip install nova' and that line is in requirements.txt it
does not work. This means I had to change tox.ini to have a deps
setting of:
deps = -r{toxinidir}/test-requirements.txt
-r{toxinidir}/requirements.txt
to get the functional and unit tests to build working virtualenvs.
That this is not happening in the dsvm-based zuul jobs mean that the
tests can't run or pass. What's going on here? Ideas?
--
Chris Dent ٩◔̯◔۶ https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
