Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-07-18
14:38:39 fungi no pending changes for review on opendev/git-restack that i can see
14:38:44 fungi was someone having problems using it?
14:39:21 sean-k-mooney the tool extention i personly want to write at some point is "git review --quad-diff <gerrit id>" or "git-review -Q" if that is free
14:40:03 sean-k-mooney it would print the diff of the current reve to its base difed againt the previs revies to that revions base
14:40:17 fungi sean-k-mooney: maybe better to just make a separate git subcommand for whatever that does? (doesn't sound like it's related to fetching and pushing changes for review)
14:40:19 sean-k-mooney so if you have don rebase it would remove them and show you only what changed
14:40:50 fungi oh, i see, you want to compare against content on gerrit... hmmm
14:41:25 sean-k-mooney fungi: ya i actully want it in gerrit itself but i dont want to write java or javscript
14:41:53 sean-k-mooney so ill settle for a little tool or an extention to git review.
14:42:06 sean-k-mooney its on my todo list for the next weekend i feel like hacking on something
14:42:20 fungi gertty has a couple of diff options already, maybe a third would fit in nicely?
14:42:39 sean-k-mooney ya maybe
14:43:06 sean-k-mooney i have been meaning to look at the db opertion in gerrty to see if i can speed up the intial data base builing
14:43:30 sean-k-mooney but the diff feature would be simpler to start with
14:45:12 efried fungi: "no pending changes" "having problems" -- no, I was just mentioning its existence to kashyap, and he asked if it was abandoned because it hasn't seen a commit in 4y, and I said nay because it doesn't need any because it's so simple, but we talked recently about a feature that could be added to it.
14:45:19 efried and now you're up to date
14:45:48 sean-k-mooney fungi: efried does it work on python3?
14:45:53 kashyap Yeah, that's completely fair. I shouldn't confuse "activity" with "improvements".
14:45:57 sean-k-mooney if its been 4 years...
14:46:19 kashyap sean-k-mooney: So? Maybe it does one thing and does it well? :-)
14:46:39 efried sean-k-mooney: um, it's possible it's sh, not python, though I haven't looked.
14:46:53 efried because technically all it would need to do is invoke a few git commands
14:47:43 sean-k-mooney its got some python 3 checking code https://github.com/openstack-infra/git-restack/blob/master/git_restack/cmd.py#L30-L46
14:47:47 sean-k-mooney so ill assume its fine
14:50:17 fungi efried: kashyap: thanks! and yeah, happy to discuss features that might be in-scope, but also as you say it's a great example of a very simple git subcommand, and it's easy to add more subcommands to git... the opendev/git-restack is nearly all boilerplate
14:50:41 fungi er, the opendev/git-restack repo is i mean
14:51:27 kashyap Noted :-)
14:51:40 fungi and yeah, it's python-based, and yeah i run it installed into a python3 (.8 beta) venv
14:54:21 sean-k-mooney gibi: do you mind if i reverse the direction fo the depend on for the vpmu patch. e.g. make the glance change to the metadef depend on the nova one.
14:54:54 sean-k-mooney the glance change is not really needed for it to work its just documentation which ill write but i dont know how long that will take to merge
15:01:23 gibi sean-k-mooney: ohh, so the new glance image property doesn't need any code on glance side?
15:02:12 sean-k-mooney correct
15:02:27 sean-k-mooney we just need to extend the nova image meta object
15:02:37 sean-k-mooney glance does no validation
15:03:30 sean-k-mooney what the metadefs are fro aare auto generating client e.g. the horizon dashboard for setting image metadata
15:04:22 gibi sean-k-mooney: thanks, then I'm OK to have the dependency in the other way
15:05:19 sean-k-mooney im currently fixing the other issue but i should get a new version up today.
15:05:33 sean-k-mooney ill start on the glance patch once that is done
15:08:54 efried gibi: responded in https://review.opendev.org/#/c/612497/ -- please let's resolve the discussion about $COMPUTE_HOST if you're still around.
15:12:04 cdent heh: "this is obviously by design"
15:14:10 dansmith efried: your comment about $COMPUTE_HOST for ironic makes this basically unusable by any real ironic deployment, AFAICT
15:15:22 efried dansmith: on the contrary, $COMPUTE_HOST is really a convenience to un-awkward the chicken/egg of having to bring up the compute so it creates the provider so you can glean its UUID and create your file and restart compute.
15:15:43 efried for ironic, don't you already know the UUIDs of the nodes before you bring up the compute service?
15:15:54 dansmith efried: except that ironic computes rebalance their nodes in ways you don
15:15:58 dansmith don't control
15:16:16 efried meaning putting them under different computes?
15:16:18 dansmith the ownership of nodes by comptues I mean
15:16:21 efried got it
15:16:22 efried well
15:16:34 dansmith point being,
15:16:44 dansmith the node is the thing with the inventory, be it the one single node for a libvirt system,
15:16:56 dansmith or the ironic nodes managed by a compute *service*
15:17:02 dansmith further,
15:17:02 efried If we want to add a "template multiple providers" feature in the future, that's certainly a possibility.
15:17:28 dansmith on something like xen or vmware where the compute *service* may be running on a different host than the actual thing providing the resource,
15:17:48 dansmith it's the node that has the inventory and they don't even share a name
15:18:25 efried Okay, so you're suggesting a) $COMPUTE_NODE is the more proper term regardless; and b) we should apply whatever changes to all "nodes", which is only >1 for ironic
15:18:27 dansmith if you make it $COMPUTE_NODE, then I think it would be natural to apply the contents below that to any compute node the compute service manages,
15:18:36 dansmith which is basically the templating thing done
15:18:41 dansmith yes
15:18:52 efried okay, I can buy that.
15:19:22 dansmith every time I look at this spec it has been rev'd or rebased, which makes back-and-forth discussion on individual points kinda hard,
15:19:38 dansmith so I'm going to reply to your reply to my comments on three patch revisions ago to capture this
15:19:45 efried dansmith: thanks.
15:28:17 stephenfin dansmith: Turns out adding a new column to an existing table with 'nullable=False, default=0' doesn't do what you'd think it does. We need 'server_default="0"' instead, for some reason
15:28:19 stephenfin The more you know
15:28:34 stephenfin Django's ORM _does_ work as expected
15:28:51 efried I remember something about this from a couple years ago
15:28:52 dansmith stephenfin: yep, knew that
15:29:00 dansmith stephenfin: however, you don't need a default either
15:29:13 dansmith stephenfin: your object should handle all of that
15:29:23 stephenfin Figured you might, but I mentioned it cos that also took me some time to handle that
15:29:39 stephenfin Hmm, without that SQLite complained about adding a non-nullable field without a default value
15:29:54 dansmith stephenfin: you can't make it non-nullable
15:30:12 stephenfin Right, that's what I ended up doing instead
15:30:34 dansmith it needs to be nullable in the model and the schema, but the object can/should be non-nullable and just handle the translation across the upgrade boundary
15:31:20 stephenfin Oh, I assumed the DB model had to match the object
15:31:29 stephenfin I'll tweak that, in that case
15:32:11 dansmith no,
15:32:32 dansmith that's kind of the point of the object is to hide the differences in the model and the upgrade minutia from the above layers
15:33:01 dansmith efried: I just realized I somehow didn't commit a comment on the spec from yesterday, relating to the version thing
15:33:22 dansmith efried: what I was going to say is that I think that the file should be forwards and backwards compatible within a minor version,
15:33:26 dansmith er, within a major
15:33:46 dansmith such that 1.0 should be parseable by a 1.9-knowing bit of code
15:34:03 dansmith and similarly, 1.9 file should work for a 1.0-knowing old piece of code
15:34:37 dansmith the reason the minor is there is just as an early key for newer code to know if it should even look for new things, not to know if it should use the stricter or looser schecma
15:34:54 dansmith and that the schema(s) should have additionalProperties:true in them
15:35:19 dansmith such that we're always purely additive within a major, and the new stuff is ignore-able by old things
15:35:28 dansmith i.e. less pedantic than our external API
15:36:25 dansmith I say this because in reality people will be rolling multiple versions of compute code with a single version of a deployment tool, and having to know the precise minor expected by a particular RPM revision on a single node is going to be super annoying
15:37:08 dansmith config files are supposed to be uuber stable and our handling of them across versions super gracious
15:50:19 gibi efried: I replyied to the $COMPUTE_HOST part of the spec and removed my -1. Besides this COMPUTE_HOSt identification thing I'm OK with the spec
15:50:44 gibi efried: and I have to leave now (was no a meeting since you pinged)
15:55:33 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Deprecate 'devname' field of '[pci] passthrough_whitelist' https://review.opendev.org/670585
15:59:30 openstackgerrit Artom Lifshitz proposed openstack/nova master: migrations: libvirt: remove get_machine_ips() https://review.opendev.org/671471
16:00:05 artom sean-k-mooney, stephenfin ^^
16:00:31 openstackgerrit Merged openstack/nova master: bindep: Remove dead markers https://review.opendev.org/671452
16:06:53 artom stephenfin, cheers!
16:08:01 efried dansmith: I don't see how you could expect 1.4-level code to be able to handle 1.5-level config
16:10:05 efried artom: we talking about remove get_machine_ips?

Earlier   Later