| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-05 | |||
| 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 | |
| 16:14:32 | sean-k-mooney | spatel: AWS availablity zones ar enot the same as openstacks | |
| 16:15:03 | spatel | understand but is there way i can get functionality close to AWS | |
| 16:15:08 | sean-k-mooney | in AWS an availablity zone is a seperate falut domain so if you have an ouate in zone A zone by is still fine | |
| 16:16:25 | spatel | Let's in openstack i create two AZ (a, b) and i want to tell openstack go build 10 vm then does openstack spread machine out between two AZ ? or this is not possible? | |
| 16:16:44 | sean-k-mooney | spatel: yes unfortunetely we leave that as an exerciest to the operator to configure cooreltys. 1.) you can actully map your AZ to seprate falut domains 2.) you can use cells + availahity zone or 3.) you can use regions | |
| 16:16:57 | spatel | if not possible then i have to specify AZ by hand | |
| 16:17:51 | sean-k-mooney | spatel: if they are different requires e.g. 10 vm requires they can be spread. if you use the multi create api im not certine if it will spread or scdule them all to the same AZ | |
| 16:18:08 | spatel | currently i have TOR level AZ (i am not much worried about power failure) | |
| 16:18:54 | spatel | just want to make sure if i loose TOR it won't knock out all my customer server | |
| 16:19:15 | spatel | so trying to spread out VM between two tor | |
| 16:19:18 | sean-k-mooney | ok the other thing that you are sharing with openstack AZ are your controler service. e.g. your db and api seriveces | |
| 16:19:51 | spatel | hmm?? | |
| 16:20:47 | sean-k-mooney | so in a standard openstack deployment you have contoler nodes that run the api services, schduler and databases | |
| 16:21:03 | spatel | Yes i have 3 controller node | |
| 16:21:15 | sean-k-mooney | thoes contoll plane nodes manage the compute nodes that reside in AZs | |