| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-05 | |||
| 14:55:18 | melwitt | there are differences, we don't have an official list. there might be an etherpad out there somewhere that describes the parity discrepancies | |
| 14:55:49 | melwitt | I don't know what --property is, so I need to look at the docs to see what it is | |
| 14:55:51 | waterloo | melwitt: should i assume it was just missed (it is --meta in 'nova server-rebuild') | |
| 14:55:55 | PapaOurs | mriedem: now that nova supports nested a-c, could you drop your -2 on https://review.openstack.org/#/c/599208/ ? | |
| 14:56:12 | waterloo | melwitt: err, 'nova rebuild' | |
| 14:56:44 | melwitt | waterloo: yeah, if there's anything you can do in novaclient that you can't do in osc, it's not intentional | |
| 14:57:21 | waterloo | melwitt: great or not great ;) I'll submit a story about it cuz i love stories! :D | |
| 14:57:30 | melwitt | we talked about the general problem of the lack of parity at the PTG | |
| 14:58:30 | melwitt | and IIRC, we talked about the possibility of moving our CLI to be an OSC plugin (which we've talked about in the past, but not too seriously) but then I think dtroyer said OSC is in the process of moving to openstacksdk so that should be completed first | |
| 14:58:36 | mriedem | waterloo: https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc | |
| 14:59:15 | melwitt | cool, I thought mriedem might have an etherpad | |
| 14:59:20 | waterloo | melwitt: i did it for ironic awhile ago, somewhat painful to go through and compare/address but done! you too, can do it, just need to find a guinea pig, err volunteer. | |
| 14:59:28 | waterloo | thx mriedem! | |
| 14:59:30 | mriedem | anything else thats missing unrelated to microversions is just a new parity story against OSC in SB | |
| 15:05:06 | waterloo | mriedem: would you mind if i opened a story (in python-openstackclient) wrt nova CLI feature parity and just link this etherpad? although maybe that won't help, not sure i would have looked for that | |
| 15:06:44 | mriedem | sure...there are already several osc stories created and linked *from* the etherpad since that's how the work was being tracked. doesn't matter much to me if there is an epic or something in SB though. | |
| 15:07:14 | mriedem | needs a project manager to create a board and all that | |
| 15:07:20 | mriedem | and people to test/review the changes | |
| 15:08:04 | waterloo | mriedem: good luck with that... | |
| 15:08:17 | mriedem | well if it were a community goal in T... | |
| 15:08:40 | mriedem | then someone could maybe justify to their employer dedicating a lot of time to this | |
| 15:09:17 | waterloo | mriedem: I'm sure lots of folks would support that! | |
| 15:09:28 | waterloo | (dunno about companies but who knows...) | |
| 15:10:15 | sean-k-mooney | waterloo: are ye talking about nova/osc feature partity? | |
| 15:10:37 | waterloo | sean-k-mooney: yeah, are you working on it? (i can only hope) | |
| 15:11:04 | sean-k-mooney | waterloo: finucannot: and i said we were interested in looking at it if we had time | |
| 15:11:39 | mriedem | melwitt: i don't think we need to care about getting these CI job changes into ocata-em https://review.openstack.org/#/q/I41b03a34795efe139d5911c605cdbd3c47a2f059 - given that, everything else is merged for ocata and we could do the final release and tag the branch | |
| 15:11:45 | sean-k-mooney | waterloo: that assume i get my feature dev done early in S e.g. m1/m2 so that i have tiem to look at it later in the cycle | |
| 15:12:16 | waterloo | sean-k-mooney: sweet, thx, I can hope then :) | |
| 15:13:47 | melwitt | mriedem: makes sense. I added a new [as of yesterday] bug to the ocata-em etherpad, but the more I think about it, it's super latent so probably not worth holding up for | |
| 15:14:46 | mriedem | yeah i saw, and commented | |
| 15:14:55 | mriedem | in the etherpad. i don't think we need to hold up EM forever | |
| 15:15:47 | melwitt | I wasn't thinking of it as forever, just someone ran into the problem and the fix fixed it for them. and it's a 5 line change | |
| 15:16:25 | melwitt | and I wasn't sure if there was anything else in the works or what date the rest of the community was targeting for EM, so I just thought I'd ask | |
| 15:17:04 | melwitt | if everything and everyone else is ready to go, then we can just go ahead | |
| 15:17:32 | mriedem | EM means the branch stays open so people can backport fixes and pull from stable/ocata, | |
| 15:17:38 | mriedem | which is good enough IMO | |
| 15:19:47 | melwitt | yeah. again, I didn't know when the rest of the community was targeting EM so I didn't know if there was time anyway. if everyone's ready to go now, then that's fine, let's go ahead | |
| 15:21:59 | mriedem | i doubt anyone else is ready to go | |
| 15:22:04 | mriedem | or is working on this | |
| 15:22:14 | mriedem | lots of projects probably just want to eol ocata | |
| 15:22:17 | mriedem | like heat | |
| 15:22:22 | waterloo | sean-k-mooney, mriedem: fyi, I added that as a story, only to try to get eyes on it and to mention the etherpad: https://storyboard.openstack.org/#!/story/2003980 | |
| 15:28:25 | cdent | Is there some way to boot a server such that you force the host and the scheduler doesn't get involved? I know that's possible with migrations, but is it with boot? | |
| 15:28:43 | sean-k-mooney | cdent: yes and its kindo fo a bug | |
| 15:28:53 | mriedem | --availability-zone nova:<host> | |
| 15:29:03 | sean-k-mooney | yep that ^ | |
| 15:29:07 | mriedem | https://docs.openstack.org/nova/latest/admin/availability-zones.html | |
| 15:29:32 | mriedem | melwitt: so i'm going to propose rocky/queens/pike/ocata releases and then the ocata-em tag on top of that | |
| 15:29:55 | melwitt | mriedem: ack | |
| 15:30:38 | sean-k-mooney | mriedem: what effect does the em tag actully have? we are not going to backport anything ourselves anymroe right but in therory others can? | |
| 15:31:03 | mriedem | we? | |
| 15:31:10 | cdent | sean-k-mooney, mriedem: interesting, thanks. The reason for this is to be able to move a vm from cloud A to cloud B in magical ways. When some form of it gets B, want to be able to skip the scheduler | |
| 15:31:11 | mriedem | anyone that cares about stable can backport stuff as before | |
| 15:32:17 | mriedem | as for what it means, read https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html | |
| 15:32:29 | sean-k-mooney | people working on nova bugfixs. normally they would be backported to stable branches subject to policy but would that still happen for em branches | |
| 15:33:09 | mriedem | tl;dr we don't release it, VMT can ignore it, and we can let it rot if no one cares about it | |
| 15:34:13 | sean-k-mooney | mriedem: sure but since we dont delete that branch and convert it to just at tag if a disto or a large customer is still using it and wants to backport fixes they still could | |
| 15:42:17 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Handle allocations consuming only from the child RPs https://review.openstack.org/608298 | |
| 15:46:36 | spatel | sean-k-mooney: morning | |
| 15:47:00 | spatel | had one general question if you available Ping me! no rush | |
| 15:52:01 | fried_rice | finucannot: https://review.openstack.org/#/c/530924/ is +A, but there's some fup work whenever you feel like it :) | |
| 15:56:06 | finucannot | fried_rice: Ack, I'll tackle those now | |
| 15:59:37 | sean-k-mooney | spatel: hi | |
| 15:59:58 | leakypipes | fried_rice: you pushing an updated revision on https://review.openstack.org/#/c/607989/? | |
| 16:00:09 | sean-k-mooney | spatel: am i will be around for a littel bit but did not sleep very weel last night | |
| 16:00:22 | fried_rice | leakypipes: Nope, cfriesen/jackding are taking over. | |
| 16:00:40 | spatel | sean-k-mooney: hey! so my SR-IOV working great now i am working in availability zone and this is how my server layout work in racks https://ibb.co/j9kgUK | |
| 16:00:49 | fried_rice | leakypipes: My interest in the issue was purely in wearing you down on the whole using-traits-for-config thing. So my work here is done. | |
| 16:00:56 | spatel | sean-k-mooney: sorry to hear that!! | |
| 16:01:12 | spatel | its long weekend get some sleep :) | |
| 16:02:02 | spatel | Base on that diagram how should plan my availability zone? and how does openstack spread instance between two AZ ? | |
| 16:02:37 | spatel | if i tell openstack create 10 instance then how does it get divided between AZ ? | |
| 16:03:12 | PapaOurs | spatel: there was an excellent talk about AZs in a previous Summit | |
| 16:03:26 | PapaOurs | spatel: lemme help you by giving you the session link | |
| 16:04:00 | spatel | PapaOurs: great they must have video in youtube then | |
| 16:04:10 | PapaOurs | spatel: https://www.openstack.org/videos/vancouver-2018/curse-your-bones-availability-zones-1 | |
| 16:04:25 | spatel | sweet!! | |
| 16:04:36 | leakypipes | fried_rice: :) | |
| 16:05:29 | spatel | trying to understand mechanic behind AZ and scheduler, how drive logic to spread machine out between two zone? | |
| 16:05:38 | spatel | is that scheduler job ? | |
| 16:06:24 | PapaOurs | spatel: that's a filter | |
| 16:06:35 | PapaOurs | but see the video, it explains it :) | |
| 16:06:43 | spatel | i am watching it.. | |
| 16:06:50 | spatel | PapaOurs: thanks | |
| 16:08:15 | PapaOurs | 6pm here, time for opening a beer | |
| 16:08:21 | PapaOurs | have a nice week-end folks | |
| 16:08:23 | PapaOurs | \o | |
| 16:09:18 | sean-k-mooney | spatel: sorry just looking at teh diagram now | |
| 16:10:12 | spatel | no worry! take your time | |
| 16:10:38 | spatel | SR-IOV doesn't support bonding so i can't create bond between two TOR switches | |
| 16:11:05 | spatel | SR-IOV does support bonding but inside VM (i think i am not ready for that) | |
| 16:11:35 | sean-k-mooney | so availablity zones are a user facing grouping mechaniums. from the schduler point of view they are just a metadata tag on a host aggaragte | |
| 16:12:18 | sean-k-mooney | so if you requst a vm in zone A the scudler will only look at host that are in a host aggragte with avaiablity_zone=a set | |
| 16:13:05 | sean-k-mooney | it then allpies the rest of the filters to reduce the set of host. e.g. ram, cpus, disk or in your case pci deivces for sriov | |
| 16:13:10 | spatel | but that would be hardwire right? | |
| 16:13:40 | sean-k-mooney | that is a bit of a simplicfation as there is another service called placement that is also invoved. | |
| 16:13:46 | sean-k-mooney | so yes and no | |
| 16:14:03 | spatel | currently we are using AWS with terraform and we tell tf to create instance between A and B zone and it does it job | |
| 16:14:10 | sean-k-mooney | the operator e.g. you in this case has to decalre what hosts are in the A avaliablity zone | |