| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-18 | |||
| 14:36:37 | fungi | ahh, nope, it's official opendev. i forgot | |
| 14:36:43 | fungi | he just initially developed it | |
| 14:37:08 | sean-k-mooney | e.g. i think if you were on stable/stien origically it look for where your feature branch meets stable/stine instead of master | |
| 14:37:23 | efried | kashyap: If you wanted to break that 4-year streak, we did recently discuss adding a feature where you could say `git restack --continue` and it determines whether you need a `commit --amend` or just a `rebase --continue`, which is one place I've gotten bitten in the restack workflow from time to time. | |
| 14:37:29 | fungi | https://review.opendev.org/#/admin/groups/git-restack-core | |
| 14:37:34 | fungi | infra-core approves changes for it | |
| 14:37:50 | kashyap | efried: Hehe, noted. | |
| 14:38:03 | efried | sean-k-mooney: yes, "meets up with its parent branch" is more correct. My hyphenated thingy wasn't long enough already. | |
| 14:38:17 | sean-k-mooney | :) | |
| 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 | |