| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-18 | |||
| 14:14:43 | efried | kashyap: I use git-restack regularly to manage series | |
| 14:14:48 | dansmith | stephenfin: ^ | |
| 14:15:17 | stephenfin | dansmith: I don't see how though http://paste.openstack.org/show/754547/ | |
| 14:16:49 | dansmith | hmm, so it must be claiming that both of those are missing from one or the other | |
| 14:17:23 | dansmith | oh | |
| 14:17:32 | dansmith | stephenfin: aren't you creat5ing them as nullable=True, | |
| 14:17:39 | dansmith | but they're =false in the model | |
| 14:17:47 | stephenfin | god damn it, yup | |
| 14:18:04 | dansmith | that output from the test looks different than I remember for some reason, but .. yeah | |
| 14:18:20 | stephenfin | Thanks. I've been looking at that for at least 30 minutes 😅 | |
| 14:18:34 | dansmith | np, blinders.. it's a thing | |
| 14:21:54 | kashyap | efried: Good to know. Thanks for the view | |
| 14:22:46 | efried | kashyap: in fact, if you're trying to convince people that gerrit is awesomer than other things, how do other things manage series? Cause gerrit does it awesomely. | |
| 14:24:47 | efried | kashyap: I wrote a tutorial, which might be handy: https://docs.openstack.org/contributors/de/code-and-documentation/patch-series-tutorial.html | |
| 14:25:04 | efried | https://docs.openstack.org/contributors/code-and-documentation/patch-series-tutorial.html | |
| 14:30:00 | kashyap | Excellent; I saw that before! | |
| 14:30:27 | kashyap | efried: I don't think this group might consider Gerrit. I wanted to present where Gerrit shines | |
| 14:30:45 | kashyap | s/!// | |
| 14:31:22 | efried | cool | |
| 14:33:42 | kashyap | efried: So 'git-restack' is not exactly "abandonware" is it? | |
| 14:33:55 | efried | what does that mean? | |
| 14:34:13 | kashyap | Sorry, meanining, nobody has time to tend to it | |
| 14:34:36 | kashyap | [Last commit was from 4 years ago.] | |
| 14:34:37 | efried | oh, it's maintained, insofar as that's necessary. I think someone like fungi or dhellmann owns it. | |
| 14:34:49 | kashyap | It might well be that the project is "done", though. Which is perfectly acceptable | |
| 14:34:56 | kashyap | Right, noted. | |
| 14:34:59 | efried | yeah, it doesn't need much. It's just a thin wrapper around `git rebase -i commit-before-wherever-my-current-series-meets-up-with-master` | |
| 14:35:08 | efried | just saves you figuring out that last piece. | |
| 14:36:00 | fungi | efried: it's a side-project of corvus | |
| 14:36:06 | fungi | (like gertty) | |
| 14:36:12 | efried | ah, k | |
| 14:36:29 | sean-k-mooney | efried: i think its a little smarter tehn that and looks for the parent commit where my current series meets up with its parent branch. but i might be mistaken | |
| 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 | efried | If we want to add a "template multiple providers" feature in the future, that's certainly a possibility. | |
| 15:17:02 | dansmith | further, | |
| 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 | |