*** Tom_ has quit IRC | 00:01 | |
*** yangyapeng has joined #openstack-nova | 00:04 | |
*** kbaegis has quit IRC | 00:05 | |
*** yangyapeng has quit IRC | 00:09 | |
*** kbaegis has joined #openstack-nova | 00:15 | |
*** claudiub|2 has quit IRC | 00:17 | |
*** kbaegis has quit IRC | 00:18 | |
*** thorst_afk has joined #openstack-nova | 00:24 | |
*** adisky__ has joined #openstack-nova | 00:26 | |
*** edmondsw has quit IRC | 00:26 | |
*** markvoelker has joined #openstack-nova | 00:26 | |
*** crushil has quit IRC | 00:29 | |
*** crushil has joined #openstack-nova | 00:29 | |
*** crushil has quit IRC | 00:30 | |
*** crushil has joined #openstack-nova | 00:31 | |
*** kiennt has joined #openstack-nova | 00:47 | |
*** jichen has joined #openstack-nova | 00:49 | |
*** zhurong has joined #openstack-nova | 00:50 | |
*** gbarros has joined #openstack-nova | 00:51 | |
*** thorst_afk has quit IRC | 00:55 | |
*** dixiaoli has joined #openstack-nova | 00:57 | |
*** markvoelker has quit IRC | 00:59 | |
*** zxy has joined #openstack-nova | 01:00 | |
*** Shunli has joined #openstack-nova | 01:01 | |
*** kbaegis has joined #openstack-nova | 01:09 | |
*** yangyapeng has joined #openstack-nova | 01:11 | |
*** ijw has quit IRC | 01:11 | |
*** ijw has joined #openstack-nova | 01:16 | |
*** david-lyle has joined #openstack-nova | 01:20 | |
*** bkopilov has quit IRC | 01:28 | |
*** baoli has joined #openstack-nova | 01:30 | |
*** StevenK_ is now known as StevenK | 01:30 | |
*** gcb has joined #openstack-nova | 01:34 | |
*** thorst_afk has joined #openstack-nova | 01:39 | |
*** thorst_afk has quit IRC | 01:39 | |
*** takashin has left #openstack-nova | 01:44 | |
*** TuanLA has joined #openstack-nova | 01:54 | |
openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi: Support live migration in pooled multi-nodes environment https://review.openstack.org/489451 | 01:55 |
---|---|---|
*** markvoelker has joined #openstack-nova | 01:56 | |
openstackgerrit | jichenjc proposed openstack/nova master: Update doc to indicate nova-network deprecated https://review.openstack.org/500654 | 01:59 |
openstackgerrit | Hironori Shiina proposed openstack/nova-specs master: Ironic: Cold migration support https://review.openstack.org/449155 | 02:02 |
*** hongbin has joined #openstack-nova | 02:03 | |
*** takashin has joined #openstack-nova | 02:03 | |
*** phuongnh has joined #openstack-nova | 02:06 | |
*** gouthamr has quit IRC | 02:08 | |
*** thorst_afk has joined #openstack-nova | 02:17 | |
*** thorst_afk has quit IRC | 02:17 | |
*** hongbin has quit IRC | 02:18 | |
*** baoli has quit IRC | 02:24 | |
*** markvoelker has quit IRC | 02:30 | |
*** Tom has joined #openstack-nova | 02:31 | |
*** hongbin has joined #openstack-nova | 02:45 | |
*** baoli has joined #openstack-nova | 02:45 | |
*** Tom has quit IRC | 02:46 | |
*** bkopilov has joined #openstack-nova | 02:46 | |
*** Tom has joined #openstack-nova | 02:48 | |
*** trinaths has joined #openstack-nova | 02:53 | |
*** hongbin has quit IRC | 02:58 | |
*** hongbin has joined #openstack-nova | 02:59 | |
*** Tom has quit IRC | 02:59 | |
*** Tom has joined #openstack-nova | 02:59 | |
*** Sree has joined #openstack-nova | 03:01 | |
*** Tom has quit IRC | 03:04 | |
*** trinaths has left #openstack-nova | 03:04 | |
openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: fix server creation error using az name with ':' https://review.openstack.org/490722 | 03:04 |
*** baoli has quit IRC | 03:07 | |
*** gbarros has quit IRC | 03:07 | |
*** thorst_afk has joined #openstack-nova | 03:18 | |
*** ijw has quit IRC | 03:22 | |
*** abhi89 has joined #openstack-nova | 03:23 | |
*** thorst_afk has quit IRC | 03:23 | |
*** kiennt_ has joined #openstack-nova | 03:33 | |
*** kiennt has quit IRC | 03:36 | |
*** kiennt_ is now known as kiennt | 03:38 | |
*** kiennt_ has joined #openstack-nova | 03:44 | |
*** kiennt has quit IRC | 03:47 | |
*** links has joined #openstack-nova | 03:51 | |
*** sridharg has joined #openstack-nova | 03:53 | |
*** hshiina has joined #openstack-nova | 04:02 | |
*** ijw has joined #openstack-nova | 04:03 | |
*** slaweq has joined #openstack-nova | 04:03 | |
*** hongbin has quit IRC | 04:05 | |
*** ijw has quit IRC | 04:08 | |
*** Sree has quit IRC | 04:08 | |
*** slaweq has quit IRC | 04:08 | |
*** Sree has joined #openstack-nova | 04:08 | |
*** zxy has quit IRC | 04:12 | |
*** Sree_ has joined #openstack-nova | 04:12 | |
*** Sree_ is now known as Guest74805 | 04:13 | |
*** gcb has quit IRC | 04:13 | |
*** kiennt_ is now known as kiennt_AWAY | 04:16 | |
*** Sree has quit IRC | 04:17 | |
*** udesale has joined #openstack-nova | 04:18 | |
*** ratailor has joined #openstack-nova | 04:18 | |
*** thorst_afk has joined #openstack-nova | 04:19 | |
*** psachin has joined #openstack-nova | 04:21 | |
*** thorst_afk has quit IRC | 04:23 | |
*** hieulq has joined #openstack-nova | 04:24 | |
*** tbh_ has joined #openstack-nova | 04:25 | |
*** gcb has joined #openstack-nova | 04:26 | |
*** zxy has joined #openstack-nova | 04:26 | |
*** markvoelker has joined #openstack-nova | 04:27 | |
*** zxy has quit IRC | 04:33 | |
*** zxy has joined #openstack-nova | 04:34 | |
*** yamahata has joined #openstack-nova | 04:47 | |
*** ratailor has quit IRC | 04:49 | |
*** pcaruana has joined #openstack-nova | 04:52 | |
*** baoli has joined #openstack-nova | 04:54 | |
openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: fix server creation error using az name with ':' https://review.openstack.org/490722 | 04:57 |
*** baoli has quit IRC | 04:59 | |
*** markvoelker has quit IRC | 05:00 | |
*** claudiub|2 has joined #openstack-nova | 05:07 | |
*** jaosorior has quit IRC | 05:08 | |
*** lpetrut has joined #openstack-nova | 05:09 | |
*** ratailor has joined #openstack-nova | 05:12 | |
*** shan has joined #openstack-nova | 05:12 | |
*** liverpooler has joined #openstack-nova | 05:16 | |
*** thorst_afk has joined #openstack-nova | 05:20 | |
*** thorst_afk has quit IRC | 05:24 | |
*** liverpooler has quit IRC | 05:27 | |
*** liverpooler has joined #openstack-nova | 05:27 | |
*** jaosorior has joined #openstack-nova | 05:30 | |
*** Tom has joined #openstack-nova | 05:32 | |
*** trinaths has joined #openstack-nova | 05:34 | |
openstackgerrit | Hironori Shiina proposed openstack/nova master: [WIP] ironic: Support cold migration https://review.openstack.org/500677 | 05:35 |
*** suresh12 has joined #openstack-nova | 05:38 | |
*** lpetrut has quit IRC | 05:46 | |
*** josecastroleon has joined #openstack-nova | 05:46 | |
*** jaosorior has quit IRC | 05:47 | |
*** moshele has joined #openstack-nova | 05:53 | |
*** markvoelker has joined #openstack-nova | 05:58 | |
*** Guest74805 has quit IRC | 05:58 | |
*** lpetrut has joined #openstack-nova | 05:59 | |
*** hoonetorg has quit IRC | 06:05 | |
*** Sree_ has joined #openstack-nova | 06:05 | |
*** Sree_ is now known as Guest48826 | 06:06 | |
*** Oku_OS-away is now known as Oku_OS | 06:12 | |
*** lpetrut has quit IRC | 06:18 | |
*** takashin_ has joined #openstack-nova | 06:18 | |
*** takashin has quit IRC | 06:19 | |
*** thorst_afk has joined #openstack-nova | 06:20 | |
gibi | good morning nova | 06:21 |
*** hoonetorg has joined #openstack-nova | 06:22 | |
*** thorst_afk has quit IRC | 06:25 | |
*** lpetrut has joined #openstack-nova | 06:26 | |
*** litao__ has joined #openstack-nova | 06:26 | |
*** jaosorior has joined #openstack-nova | 06:26 | |
*** suresh12 has quit IRC | 06:27 | |
*** markvoelker has quit IRC | 06:31 | |
*** takashin_ has left #openstack-nova | 06:31 | |
*** ekuris has quit IRC | 06:37 | |
*** ekuris has joined #openstack-nova | 06:38 | |
*** zsli_ has joined #openstack-nova | 06:40 | |
*** Shunli has quit IRC | 06:43 | |
*** trungnv has joined #openstack-nova | 06:46 | |
*** rcernin has joined #openstack-nova | 06:46 | |
openstackgerrit | Merged openstack/nova master: Fix scope of errors_out_migration in finish_resize https://review.openstack.org/487515 | 06:46 |
*** Guest48826 has quit IRC | 06:48 | |
*** lpetrut has quit IRC | 06:54 | |
*** Tom has quit IRC | 07:03 | |
*** Tom has joined #openstack-nova | 07:03 | |
*** Tom_ has joined #openstack-nova | 07:05 | |
*** sahid has joined #openstack-nova | 07:05 | |
*** sahid has quit IRC | 07:05 | |
*** Tom_ has quit IRC | 07:06 | |
*** Tom_ has joined #openstack-nova | 07:06 | |
openstackgerrit | zhangbailin proposed openstack/nova master: Replace http with https for doc links in nova https://review.openstack.org/500693 | 07:06 |
*** Tom has quit IRC | 07:08 | |
*** zsli_ has quit IRC | 07:12 | |
*** tesseract has joined #openstack-nova | 07:13 | |
*** sahid has joined #openstack-nova | 07:14 | |
*** ygl has joined #openstack-nova | 07:15 | |
*** zxy has quit IRC | 07:20 | |
*** zxy has joined #openstack-nova | 07:21 | |
*** thorst_afk has joined #openstack-nova | 07:22 | |
*** gcb has quit IRC | 07:22 | |
*** gcb has joined #openstack-nova | 07:22 | |
*** trinaths has quit IRC | 07:24 | |
openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: disable numa feature when virt_type=qemu https://review.openstack.org/465160 | 07:24 |
*** andreas_s has joined #openstack-nova | 07:24 | |
*** thorst_afk has quit IRC | 07:26 | |
*** slaweq has joined #openstack-nova | 07:29 | |
*** jpena|off is now known as jpena | 07:33 | |
*** ralonsoh has joined #openstack-nova | 07:41 | |
*** moshele has quit IRC | 07:54 | |
*** rmart04 has joined #openstack-nova | 07:56 | |
openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Add datapath type information to OVS vif objects https://review.openstack.org/474892 | 07:58 |
*** moshele has joined #openstack-nova | 08:03 | |
*** udesale has quit IRC | 08:03 | |
openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: disable numa feature when virt_type=qemu https://review.openstack.org/465160 | 08:04 |
*** slaweq_ has joined #openstack-nova | 08:04 | |
*** Tom_ has quit IRC | 08:04 | |
*** Tom_ has joined #openstack-nova | 08:05 | |
*** udesale has joined #openstack-nova | 08:05 | |
*** Tom____ has joined #openstack-nova | 08:06 | |
*** Tom____ has quit IRC | 08:06 | |
*** Tom____ has joined #openstack-nova | 08:07 | |
*** slaweq_ has quit IRC | 08:08 | |
*** Tom_ has quit IRC | 08:09 | |
*** thorst_afk has joined #openstack-nova | 08:22 | |
*** priteau has joined #openstack-nova | 08:24 | |
*** trinaths has joined #openstack-nova | 08:25 | |
*** thorst_afk has quit IRC | 08:27 | |
*** udesale has quit IRC | 08:27 | |
*** udesale has joined #openstack-nova | 08:27 | |
*** suresh12 has joined #openstack-nova | 08:28 | |
*** markvoelker has joined #openstack-nova | 08:28 | |
*** jaosorior has quit IRC | 08:29 | |
*** alexchadin has joined #openstack-nova | 08:30 | |
*** lucas-afk is now known as lucasagomes | 08:32 | |
openstackgerrit | Hironori Shiina proposed openstack/nova master: [WIP] ironic: Support cold migration https://review.openstack.org/500677 | 08:32 |
*** suresh12 has quit IRC | 08:32 | |
*** avolkov has joined #openstack-nova | 08:33 | |
*** yangyapeng has quit IRC | 08:34 | |
*** yangyapeng has joined #openstack-nova | 08:35 | |
openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add support for Windows network commands https://review.openstack.org/487405 | 08:40 |
*** derekh has joined #openstack-nova | 08:42 | |
*** ygl has quit IRC | 08:42 | |
*** dtantsur|afk is now known as dtantsur | 08:46 | |
*** hshiina has quit IRC | 08:49 | |
*** Tom____ has quit IRC | 08:50 | |
*** yangyapeng has quit IRC | 08:52 | |
*** yangyapeng has joined #openstack-nova | 08:53 | |
openstackgerrit | Jeremy Liu proposed openstack/nova master: Put base policy rules at first https://review.openstack.org/500736 | 08:55 |
*** markvoelker has quit IRC | 09:01 | |
openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Read Neutron port 'binding_profile' during boot https://review.openstack.org/449257 | 09:05 |
*** amotoki__away is now known as amotoki | 09:07 | |
*** gszasz has joined #openstack-nova | 09:09 | |
*** sambetts|afk is now known as sambetts | 09:20 | |
*** thorst_afk has joined #openstack-nova | 09:23 | |
*** thorst_afk has quit IRC | 09:28 | |
openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add ``HostPortProfileInfo`` class https://review.openstack.org/441590 | 09:31 |
*** Sree_ has joined #openstack-nova | 09:32 | |
*** Sree_ is now known as Guest49624 | 09:32 | |
*** jichen has quit IRC | 09:44 | |
openstackgerrit | zhangbailin proposed openstack/nova master: Replace http with https for doc links in nova https://review.openstack.org/500693 | 09:45 |
*** alexchadin has quit IRC | 09:46 | |
*** alexchadin has joined #openstack-nova | 09:47 | |
*** priteau has quit IRC | 09:51 | |
*** yassine has quit IRC | 09:55 | |
*** dixiaoli has quit IRC | 09:56 | |
*** markvoelker has joined #openstack-nova | 09:58 | |
*** yamamoto has quit IRC | 10:00 | |
*** nicolasbock has joined #openstack-nova | 10:05 | |
*** lpetrut has joined #openstack-nova | 10:05 | |
*** dtantsur is now known as dtantsur|lunch | 10:06 | |
*** nicolasbock has quit IRC | 10:09 | |
*** dixiaoli has joined #openstack-nova | 10:12 | |
*** dixiaoli has quit IRC | 10:13 | |
*** ratailor has quit IRC | 10:14 | |
*** yamamoto has joined #openstack-nova | 10:15 | |
*** ratailor has joined #openstack-nova | 10:15 | |
*** abhi89 has quit IRC | 10:20 | |
*** nicolasbock has joined #openstack-nova | 10:22 | |
*** jaosorior has joined #openstack-nova | 10:23 | |
*** thorst_afk has joined #openstack-nova | 10:24 | |
openstackgerrit | Alexandru Muresan proposed openstack/nova master: Pass config object to oslo_reports https://review.openstack.org/485575 | 10:25 |
*** thorst_afk has quit IRC | 10:28 | |
*** bkopilov has quit IRC | 10:31 | |
*** markvoelker has quit IRC | 10:31 | |
*** moshele has quit IRC | 10:32 | |
*** moshele has joined #openstack-nova | 10:34 | |
*** yamamoto has quit IRC | 10:37 | |
*** udesale__ has joined #openstack-nova | 10:37 | |
stephenfin | Do we use reno for bugfixes? | 10:38 |
*** udesale has quit IRC | 10:39 | |
openstackgerrit | Stephen Finucane proposed openstack/nova master: Pass config object to oslo_reports https://review.openstack.org/485575 | 10:39 |
*** udesale__ has quit IRC | 10:40 | |
*** udesale has joined #openstack-nova | 10:40 | |
openstackgerrit | Pooja Jadhav proposed openstack/nova master: Fix ValueError if invalid max_rows passed to db purge https://review.openstack.org/500771 | 10:42 |
*** ratailor has quit IRC | 10:43 | |
*** yangyapeng has quit IRC | 10:43 | |
*** Oku_OS is now known as Oku_OS-away | 10:47 | |
openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Remove deprecated 'null_kernel' opt https://review.openstack.org/499611 | 10:49 |
openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP! conf: Remove deprecated 'multi_instance_display_name_template' opt https://review.openstack.org/499612 | 10:49 |
*** Oku_OS-away is now known as Oku_OS | 10:53 | |
*** moshele has quit IRC | 10:58 | |
*** moshele has joined #openstack-nova | 10:59 | |
*** yamamoto has joined #openstack-nova | 11:02 | |
*** moshele has quit IRC | 11:03 | |
*** lucasagomes is now known as lucas-hungry | 11:05 | |
*** moshele has joined #openstack-nova | 11:06 | |
*** moshele has quit IRC | 11:09 | |
*** ZZelle has joined #openstack-nova | 11:14 | |
*** sdague has joined #openstack-nova | 11:19 | |
*** smatzek has joined #openstack-nova | 11:21 | |
*** yassine has joined #openstack-nova | 11:24 | |
*** thorst_afk has joined #openstack-nova | 11:25 | |
*** tbh_ has quit IRC | 11:25 | |
*** priteau has joined #openstack-nova | 11:26 | |
openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Migration from ``ip`` commands to ``pyroute2`` https://review.openstack.org/484386 | 11:28 |
openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Add datapath type information to OVS vif objects https://review.openstack.org/474892 | 11:29 |
*** markvoelker has joined #openstack-nova | 11:29 | |
*** fried_rice is now known as efried | 11:29 | |
efried | stephenfin If behavior changed? | 11:30 |
*** thorst_afk has quit IRC | 11:33 | |
*** rcernin has quit IRC | 11:36 | |
*** rcernin has joined #openstack-nova | 11:36 | |
openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add plugin names as constants. https://review.openstack.org/500111 | 11:38 |
*** jpena is now known as jpena|lunch | 11:41 | |
*** alexchadin has quit IRC | 11:44 | |
*** alexchadin has joined #openstack-nova | 11:44 | |
*** dikonoor has joined #openstack-nova | 11:45 | |
*** Guest49624 has quit IRC | 11:46 | |
*** kiennt_AWAY has quit IRC | 11:46 | |
*** Sree has joined #openstack-nova | 11:46 | |
*** Sree has quit IRC | 11:51 | |
*** moshele has joined #openstack-nova | 11:52 | |
*** dtantsur|lunch is now known as dtantsur | 11:57 | |
*** moshele has quit IRC | 11:58 | |
*** nicolasbock has quit IRC | 11:58 | |
*** Sree has joined #openstack-nova | 11:58 | |
*** nicolasbock has joined #openstack-nova | 12:00 | |
*** thorst_afk has joined #openstack-nova | 12:00 | |
*** jaypipes has joined #openstack-nova | 12:00 | |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: use already loaded BDM in instance.<action> (2) https://review.openstack.org/483955 | 12:01 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: use already loaded BDM in instance.create https://review.openstack.org/483969 | 12:01 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: use already loaded BDM in instance.<action> https://review.openstack.org/483324 | 12:01 |
*** markvoelker has quit IRC | 12:01 | |
*** dave-mccowan has joined #openstack-nova | 12:05 | |
*** abhi89 has joined #openstack-nova | 12:06 | |
*** moshele has joined #openstack-nova | 12:07 | |
*** TuanLA has quit IRC | 12:09 | |
*** litao__ has quit IRC | 12:13 | |
*** markvoelker has joined #openstack-nova | 12:16 | |
*** lucas-hungry is now known as lucasagomes | 12:18 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/500011 | 12:19 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Factor out duplicated notification sample data (3) https://review.openstack.org/452820 | 12:21 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Factor out duplicated notification sample data https://review.openstack.org/452818 | 12:21 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Factor out duplicated notification sample data (2) https://review.openstack.org/452819 | 12:21 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Refactor instance.power-off notification samples https://review.openstack.org/475860 | 12:21 |
bhagyashris | jaypipes: Hi, Is there any placement api to get resource provider for a given instance uuid? | 12:21 |
*** edmondsw has joined #openstack-nova | 12:21 | |
*** zhurong has quit IRC | 12:22 | |
bhagyashris | jaypipes: if there is no direct api, is it possible to get resource provider if I know the instance uuid | 12:22 |
*** udesale has quit IRC | 12:25 | |
*** shan7 has joined #openstack-nova | 12:25 | |
*** edmondsw has quit IRC | 12:26 | |
*** shan has quit IRC | 12:26 | |
*** shan has joined #openstack-nova | 12:27 | |
*** edmondsw has joined #openstack-nova | 12:27 | |
*** shan has quit IRC | 12:28 | |
*** yangyapeng has joined #openstack-nova | 12:28 | |
*** shan has joined #openstack-nova | 12:28 | |
*** shan has quit IRC | 12:29 | |
*** shan7 has quit IRC | 12:30 | |
*** Sree has quit IRC | 12:31 | |
*** edmondsw has quit IRC | 12:31 | |
*** hferenc has joined #openstack-nova | 12:32 | |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Send soft_delete from context manager https://review.openstack.org/476459 | 12:37 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: use context mgr in instance.delete https://review.openstack.org/443764 | 12:37 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Transform missing delete notifications https://review.openstack.org/410297 | 12:37 |
*** jaosorior has quit IRC | 12:41 | |
*** eharney has quit IRC | 12:45 | |
stephenfin | efried: What do you think of this one, in that case? https://review.openstack.org/#/c/465160/ Looks like a change in behavior | 12:46 |
efried | stephenfin ... | 12:46 |
*** shan has joined #openstack-nova | 12:47 | |
efried | stephenfin Well, I definitely don't claim understanding of the plumbing here, but if I'm reading it right, it's making an ugly/unpredictable error into a crisp, predictable one. | 12:49 |
*** scottda_ has joined #openstack-nova | 12:49 | |
efried | ...which IMO would not warrant a reno. | 12:49 |
efried | If it is in fact explicitly removing support for something which used-to-sort-of-work-maybe-sometimes and now definitely won't work ever for anyone, then *maybe* it warrants a reno. RBB kind of thing. | 12:50 |
stephenfin | efried: Yup, agree with all of the above. I'll drop the -1 for that and let him address sahid's comments | 12:51 |
stephenfin | efried: Thanks for the input :) | 12:51 |
*** lyan has joined #openstack-nova | 12:51 | |
efried | stephenfin Sure thing, for whatever it's worth :) | 12:51 |
*** mgariepy has quit IRC | 12:53 | |
efried | sean-k-mooney Can I just say I think it's neat how you start each line of a paragraph with a capital. It's like poetry. | 12:54 |
*** baoli has joined #openstack-nova | 12:54 | |
*** baoli has quit IRC | 12:54 | |
*** mgariepy has joined #openstack-nova | 12:54 | |
*** catintheroof has joined #openstack-nova | 12:55 | |
*** catintheroof has quit IRC | 12:55 | |
*** catintheroof has joined #openstack-nova | 12:55 | |
efried | One question: you said, "...in this case the bandwidth resource provider will be a child of the PF" -- not to split hairs, but wouldn't the bandwidth resource provider be the PF itself? That is, the PF needs to provide the pool of VFs *and* the pool of bandwidth... units. | 12:55 |
*** pchavva has joined #openstack-nova | 12:56 | |
*** zhurong has joined #openstack-nova | 12:56 | |
*** jpena|lunch is now known as jpena | 12:57 | |
*** esberglu has joined #openstack-nova | 12:57 | |
*** kylek3h has joined #openstack-nova | 12:58 | |
*** edmondsw has joined #openstack-nova | 12:58 | |
*** gszasz has quit IRC | 12:59 | |
*** baoli has joined #openstack-nova | 13:00 | |
*** gszasz has joined #openstack-nova | 13:02 | |
*** mriedem has joined #openstack-nova | 13:06 | |
*** shaohe_feng has quit IRC | 13:06 | |
*** bkopilov has joined #openstack-nova | 13:07 | |
efried | mriedem Was going to move the pike powervm bp from approved/ to implemented/, but noticed there seems to be a script that does that for everything. Which made me assume someone else (like you) would be doing that at some designated point in the release cycle. True? | 13:09 |
*** zhurong has quit IRC | 13:10 | |
kashyap | mriedem: When you're about, do you have any further remarks on this - https://review.openstack.org/#/c/498983/ | 13:10 |
jaypipes | bhagyashris: GET /allocations/{instance_uuid} | 13:11 |
jaypipes | bhagyashris: no, that's not right... never mind. | 13:12 |
bhagyashris | jaypipes: ok. | 13:12 |
efried | jaypipes bhagyashris Not sure what that means, "resource provider for an instance"? | 13:13 |
mriedem | gmann: i'm missing something here https://review.openstack.org/#/c/500369/2 | 13:13 |
mriedem | efried: see ^ | 13:13 |
jaypipes | efried: he means get the resource providers that an instance is consuming from. | 13:13 |
efried | ah, that makes sense. | 13:13 |
*** shaohe_feng has joined #openstack-nova | 13:14 | |
*** alexchadin has quit IRC | 13:14 | |
*** gouthamr has joined #openstack-nova | 13:14 | |
efried | mriedem Roger that, thanks. | 13:14 |
*** shan has quit IRC | 13:14 | |
bhagyashris | efried, jaypipes: I have tried to search but haven't found any api or anyway I guess we can not get the resource provider if we know the instance uuid | 13:14 |
jaypipes | bhagyashris: no, I was correct the first time... GET /allocations/{instance_uuid} | 13:15 |
bhagyashris | jaypipes: ok let me check. | 13:15 |
jaypipes | bhagyashris: https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/handlers/allocation.py#L111-L128 | 13:16 |
jaypipes | bhagyashris: that's what the response will look like. | 13:16 |
jaypipes | bhagyashris: you can get the resource provider UUIDs by grabbing response.get('allocations').keys() | 13:16 |
bhagyashris | jaypipes: yes | 13:16 |
bhagyashris | jaypipes: {"allocations": {"0cda7039-eee9-4ea4-90c5-78308b1990e9": {"generation": 1004, "resources": {"VCPU": 1, "MEMORY_MB": 512, "DISK_GB": 1}}}} | 13:17 |
bhagyashris | jaypipes: like this got it. | 13:17 |
jaypipes | bhagyashris: also, see here: https://developer.openstack.org/api-ref/placement/ | 13:18 |
jaypipes | https://developer.openstack.org/api-ref/placement/#list-allocations | 13:18 |
*** phuongnh has quit IRC | 13:18 | |
openstackgerrit | YongMing Zeng proposed openstack/nova master: optimized code https://review.openstack.org/500820 | 13:19 |
bhagyashris | jaypipes: thanks, I have two doubt can you please guide me | 13:20 |
bhagyashris | jaypipes: is it possible to assign resources from different resources providers for a given instance? | 13:20 |
jaypipes | bhagyashris: yes. | 13:21 |
jaypipes | bhagyashris: see above link for an example. | 13:21 |
bhagyashris | jaypipes: As per my finding if i used the custom resource classes to create the inventory using the resource provider then it's possible but if i used the existing resource classes then it's not possible | 13:22 |
bhagyashris | jaypipes: am i correct? | 13:22 |
bhagyashris | jaypipes: ohh ok. | 13:22 |
jaypipes | bhagyashris: custom vs. standard resource classes don't matter when creating inventory against multiple providers. | 13:25 |
*** lpetrut_ has joined #openstack-nova | 13:27 | |
bhagyashris | jaypipes: ok. | 13:27 |
bhagyashris | jaypipes: how a aggregate is selected in placement service? | 13:28 |
jaypipes | bhagyashris: just remember that when you call PUT /resource_providers/{rp_uuid}/inventory, that you are *replacing* the inventory of the resource provider each time you call that. | 13:28 |
jaypipes | bhagyashris: aggregates are not selected. only resource providers are selected. aggregates allow relationships between resource providers, for example, to denote a grouping of like providers. | 13:29 |
bhagyashris | jaypipes: for example, I have host-aggregate-1 and host-aggregate-2, and when a new request comes to boot an instance, then how the placement api decides in which host aggregate this new vm should be created | 13:29 |
*** burt has joined #openstack-nova | 13:29 | |
bhagyashris | jaypipes: ok. | 13:29 |
*** lpetrut has quit IRC | 13:29 | |
jaypipes | bhagyashris: that's not how things work :) instances don't get created "in an aggregate". Instead, instances get created on a compute host. That compute host may be associated with one or more aggregates. | 13:30 |
jaypipes | bhagyashris: perhaps you're confusing availability zone with host aggregate? | 13:30 |
bhagyashris | jaypipes: yes. | 13:31 |
*** shaohe_feng has quit IRC | 13:33 | |
jaypipes | bhagyashris: availability zone is an attribute (metadata key/value pair) against a Nova host aggregate. All compute hosts in the host aggregate belong to the availability zone that the host aggregate is marked with. That said, the placement API does not have anything to do with the availability zone. The Nova host aggregate and the placement aggregate are different things. For example, a Nova host aggregate actually refers to the nova-compute | 13:33 |
jaypipes | service daemon, not the provider of resources. This is why, for example, Ironic baremetal nodes cannot individually be assigned to a Nova host aggregate. But Ironic baremetal nodes *can* be associated individually with a placement aggregate. | 13:33 |
*** shaohe_feng has joined #openstack-nova | 13:33 | |
jaypipes | bhagyashris: it's all ludicrously confusing, I know :( | 13:34 |
jaypipes | bhagyashris: perhaps you could describe what you're attempting to do so I can assist you in finding the answers you seek :) | 13:35 |
*** crushil has quit IRC | 13:37 | |
*** eharney has joined #openstack-nova | 13:37 | |
*** artom_ has quit IRC | 13:41 | |
bhagyashris | jaypipes: actually my doubt was regarding the selection host aggregate in placement when i request to boot instance but host aggregates are not selected to create the instance at placement that is only used for the relationships between the providers | 13:43 |
*** mriedem has quit IRC | 13:43 | |
*** baoli_ has joined #openstack-nova | 13:43 | |
*** mriedem has joined #openstack-nova | 13:44 | |
*** gbarros has joined #openstack-nova | 13:44 | |
efried | jaypipes I also would like to understand what an aggregate is (in placement context). Is this the best thing to read? https://developer.openstack.org/api-ref/placement/#resource-provider-aggregates | 13:44 |
efried | (though ^ seems to assume a foreknowledge of what a "host aggregate" is... which I lack0 | 13:44 |
efried | ) | 13:44 |
mriedem | https://docs.openstack.org/nova/latest/user/aggregates.html | 13:45 |
mriedem | for host aggregates | 13:45 |
*** jaosorior has joined #openstack-nova | 13:45 | |
*** baoli has quit IRC | 13:46 | |
efried | Thanks | 13:46 |
*** crushil has joined #openstack-nova | 13:47 | |
jaypipes | efried: placement aggregates are groupings of resource providers, nothing more. Placement aggregates do not have traits associated with them. Placement aggregates are not "in an availability zone" or anything like that. Nova host aggregates are groupings of nova-compute service daemons (NOT the compute hosts that actually provide the resources). Nova host aggregates have metadata key/value pairs associated with them. Nova host aggregates are | 13:49 |
jaypipes | an entity in any of themselves, whereas placement aggregates are nothing more than a UUID that provides a grouping to resource providers. | 13:49 |
jaypipes | bhagyashris: ^ you too. :) | 13:49 |
*** marst has joined #openstack-nova | 13:50 | |
efried | jaypipes What are placement aggregates useful/used for? | 13:50 |
jaypipes | efried: associating a resource provider to another. | 13:50 |
jaypipes | efried: that's it. nothing more. | 13:50 |
efried | Associating for programmatic or human consumption? | 13:50 |
jaypipes | efried: right now, mostly programmatic. | 13:51 |
jaypipes | efried: it's currently how we handle shared resources. | 13:51 |
efried | So placement aggregates can overlap. | 13:51 |
efried | I seem to recall asking this very question in Boston :) | 13:52 |
efried | And the answer was yes | 13:52 |
stephenfin | mriedem: Could you take another look at this this week? https://review.openstack.org/#/c/412356/ | 13:52 |
edleafe | efried: placement can't select based on nova host agg | 13:52 |
jaypipes | efried: in the future, I envision aggregates being associated to each other via a distance attribute. In other words, agg A and agg B are distance 1 apart. agg X and agg A are distance 4 apart, etc. | 13:52 |
edleafe | efried: that's done in the scheduler filters | 13:52 |
jaypipes | efried: this will provide us a way to model affinity and anti-affinity concerns in placement. | 13:52 |
jaypipes | efried: yep, aggregates (either placement or Nova host aggregate) can overlap. | 13:53 |
efried | jaypipes So it also makes sense that a nested resource provider will be implicitly aggregated with its parent. | 13:53 |
*** tidwellr has joined #openstack-nova | 13:54 | |
efried | ...and by extension, with its "siblings" and "cousins"... | 13:54 |
jaypipes | efried: yes. I was planning on making a constraint that only root provider UUIDs could be associated with an aggregate. | 13:55 |
*** zxy has quit IRC | 13:55 | |
*** zxy has joined #openstack-nova | 13:55 | |
mriedem | stephenfin: replied | 13:56 |
stephenfin | ta | 13:57 |
mriedem | stephenfin: if we're going to play fast and loose we should at least have a release note | 13:57 |
*** ijw has joined #openstack-nova | 13:57 | |
bhagyashris | jaypipes: Thanks for your inputs :) | 13:58 |
stephenfin | mriedem: 'upgrade' section? | 13:59 |
mriedem | stephenfin: yeah i suppose | 13:59 |
sean-k-mooney | efried: hehe that is more my email client enforcing it then i doing it intentionally but thanks in any case. | 14:03 |
*** erlon has quit IRC | 14:03 | |
*** kbaegis has quit IRC | 14:03 | |
*** suresh12 has joined #openstack-nova | 14:03 | |
openstackgerrit | Stephen Finucane proposed openstack/nova master: rbd: Remove unnecessary 'encode' calls https://review.openstack.org/412356 | 14:04 |
*** kbaegis has joined #openstack-nova | 14:04 | |
stephenfin | sean-k-mooney: I'd suggest using something like Evolution but don't - it's buggy af :( | 14:04 |
sean-k-mooney | stephenfin: currently im still using outlook because im too lazy to figure out how to get tunderbird to work with our exchange servers. but since you helped me to get inline respconces to text only mail working i think it does the job well enough | 14:06 |
stephenfin | mriedem: Done. The important bit is that this will only affect users running under Python 3 | 14:06 |
stephenfin | sean-k-mooney: Heh, I actually blogged that when I left Intel https://that.guru/blog/sane-outlook/ | 14:07 |
stephenfin | one of my very few posts. I should probably use that more | 14:07 |
sean-k-mooney | oh cool i should send that to sdake | 14:08 |
sean-k-mooney | sdake: you were asking how i got outlook to work with inline plain text before. stephens blog should help https://that.guru/blog/sane-outlook/ | 14:09 |
*** hongbin has joined #openstack-nova | 14:09 | |
*** gszasz has quit IRC | 14:10 | |
sean-k-mooney | stephenfin: speanking of blogs in need to set min up again ... | 14:10 |
bauzas | mriedem: could you please tell me again which series to review ? I now have a new laptop and I don't find it | 14:10 |
sdake | sean-k-mooney the problem is the line doesn't break in replies | 14:10 |
sdake | sean-k-mooney therefore one cnnot reply inline | 14:10 |
bauzas | mriedem: I mean, the bug series about the problems with allocations | 14:11 |
sdake | stephenfin does your solution fix thta? | 14:11 |
sdake | sean-k-mooney everyting I've read says its an outlook bug and microsoft doesn't care | 14:11 |
stephenfin | sdake: Afraid not, I'd to guess what 80 characters looked like | 14:11 |
sdake | it has to dowith the way word is integrated into outlook | 14:11 |
mriedem | bauzas: starts here https://review.openstack.org/#/c/499678/3 | 14:11 |
*** hferenc has quit IRC | 14:11 | |
bauzas | mriedem: ta | 14:12 |
bauzas | CC'ing | 14:12 |
stephenfin | MS don't care for plain text. If you use outlook.com and try to switch to plain text, you suddenly can't paste links | 14:12 |
mriedem | bauzas: and https://review.openstack.org/#/c/498861/ | 14:12 |
sdake | stephenfin there is a bar on the left side of replies, - it has nothign to do with 80 chars however the bar can't be broken - if there are 4 layers of replies, there is no way to "put a new reply" in | 14:12 |
stephenfin | It formats them as HTML | 14:12 |
bauzas | mriedem: will reviewing them in the next hour | 14:12 |
bauzas | thanks | 14:12 |
sean-k-mooney | sdake: this is what it looks like when i reply http://lists.openstack.org/pipermail/openstack-dev/2017-September/121804.html | 14:12 |
stephenfin | sdake: Ah, I remember that, though not what I did to resolve it | 14:13 |
sdake | i am on outlook 2016 | 14:13 |
sdake | 2016 is where is broke - it worked on 2013 and prior | 14:13 |
openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add VersionedObjectPrintable mixin https://review.openstack.org/493082 | 14:13 |
bauzas | FWIW, I now have again an Entry button \o/ | 14:13 |
sdake | it even worked briefly for 2016 | 14:14 |
*** cfriesen__ has joined #openstack-nova | 14:14 | |
sdake | sean-k-mooney are ou using 2016 outlook? | 14:14 |
stephenfin | sdake: Maybe it's a feature, heh | 14:14 |
sean-k-mooney | sdake: no still on 2013 i am afraid | 14:14 |
stephenfin | For what it's worth, I ended up using Mutt for everything except openstack-dev in the end (ovs-dev, patchwork, dpdk-dev etc.) | 14:14 |
sdake | sean-k-mooney if you want a sane mail client don't upgrade | 14:14 |
sdake | i just use gmail for mailing lists - since i can actually reply | 14:14 |
openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Migration from ``ip`` commands to ``pyroute2`` https://review.openstack.org/484386 | 14:15 |
sean-k-mooney | sdake: if i do an os reinstall or upgrade ill just setup tunderbird. but since outlook is not currently broken im not going to change it | 14:15 |
*** suresh12 has quit IRC | 14:15 | |
stephenfin | Exchange is still an excellent protocol (at least from a usability perspective), but the lack of things like auto-wrap in Outlook makes it tough to work with | 14:15 |
stephenfin | sean-k-mooney: Good luck. That is also terrible, IMO | 14:15 |
sean-k-mooney | stephenfin: well i have been usingin it since i created my first email account at home so im used to it. it works for me. | 14:17 |
*** suresh12 has joined #openstack-nova | 14:17 | |
stephenfin | sean-k-mooney: Ah, then you're not too badly off. I thought it was ugly as sin and calendering with Gmail was seriously broken. Evolution would be excellent if it just weren't so damn buggy :( | 14:18 |
sean-k-mooney | im currently in a "its not broke so im not going to fix it" mode with my apps and workflow. eventully ill upgrading things when i have too. | 14:20 |
*** andreas_s has quit IRC | 14:20 | |
sean-k-mooney | its kindo fo like openstack. our dev cloud has been running on newton rc1 for almost a year. it is now finally beging to have issue so im going to go strait to stable pike once kolla-ansible make its release but while it was working no need to upgrade it | 14:22 |
*** rabel has joined #openstack-nova | 14:22 | |
*** gszasz has joined #openstack-nova | 14:23 | |
*** dikonoor has quit IRC | 14:23 | |
*** yamamoto has quit IRC | 14:24 | |
*** ratailor has joined #openstack-nova | 14:24 | |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Moving more utils to ServerResourceAllocationTestBase https://review.openstack.org/499539 | 14:24 |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Test resource allocation during soft delete https://review.openstack.org/495159 | 14:24 |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Refactor ServerMovingTests for non-move tests https://review.openstack.org/498596 | 14:24 |
*** ratailor has quit IRC | 14:24 | |
*** beekneemech is now known as bnemec | 14:25 | |
*** ratailor has joined #openstack-nova | 14:25 | |
*** yamamoto has joined #openstack-nova | 14:25 | |
*** hferenc has joined #openstack-nova | 14:25 | |
*** suresh12 has quit IRC | 14:26 | |
*** eharney_ has joined #openstack-nova | 14:26 | |
*** eharney has quit IRC | 14:27 | |
*** ratailor has quit IRC | 14:28 | |
*** suresh12 has joined #openstack-nova | 14:28 | |
*** ebbex has joined #openstack-nova | 14:31 | |
*** vikrant has joined #openstack-nova | 14:32 | |
sdake | stephenfin i used thunderbird for 10 years - your correct it is awful :) | 14:33 |
sdake | if i relaly feel like osme pain I use mac mail for responding to mailing lists and outlook for reading | 14:34 |
sdake | wish i could find a mail client that worked with exchange that was good | 14:34 |
sdake | there is this rockin mac client, however, it lacks exchange support...... | 14:34 |
sdake | in other words, its useless :) | 14:34 |
*** yamamoto has quit IRC | 14:35 | |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove compatibility code for flavors https://review.openstack.org/460377 | 14:36 |
*** kristian__ has joined #openstack-nova | 14:36 | |
sean-k-mooney | stephenfin: by the way, you mentioned before that we can associate multiple email accounts with a singel openstack account correct? do you have a link to how to do this. if not ill just google it | 14:37 |
*** links has quit IRC | 14:37 | |
stephenfin | sean-k-mooney: Sure. Sec | 14:38 |
stephenfin | sean-k-mooney: So I _think_ you do it from Launchpad. Go to https://launchpad.net/ and click your user in the top right | 14:38 |
stephenfin | That'll bring you to your profile. Emails are listed on the left. IIRC, this gets propagated to Gerrit | 14:40 |
*** eharney_ is now known as eharney | 14:41 | |
dansmith | hope you guys don't mind me interrupting the email chat to talk about nova... | 14:41 |
dansmith | mriedem: so the people working on skip level upgrades pointed out that our ironic flavor migration thing will be a problem for them, | 14:42 |
sean-k-mooney | ok ill give that a try and if it doesnt work ill ask the infra guys next week. | 14:42 |
dansmith | which is correct, and a little contrary to the promises we've been making about being able to do offline upgrades with nova-manage | 14:42 |
sean-k-mooney | dansmith: sorry :) | 14:42 |
dansmith | so I'm trying to think about the best way to make that doable without compute running | 14:42 |
dansmith | sean-k-mooney: :) | 14:42 |
*** moshele has quit IRC | 14:42 | |
dansmith | mriedem: I'm thinking that the best plan would just be a dedicated subcommand for this specific case since it's kinda weird | 14:43 |
mriedem | dansmith: well, we can do some purely db intensive stuff in nova-manage | 14:43 |
*** hrw has quit IRC | 14:43 | |
dansmith | mriedem: yeah, but we need to know which instances are ironic and not, so I'm kinda thinking that maybe we should make a dedicated command that takes an ironic compute's hostname and migrates instances that are on that compute | 14:44 |
dansmith | which makes it not really fit the online-data-migrations model | 14:44 |
*** udesale has joined #openstack-nova | 14:44 | |
dtantsur | mriedem: hey! when do you folks plan on finalizing your PTG schedule? I specifically wonder about the scheduling discussion, as we have a couple of topics there | 14:44 |
mriedem | we can figure out the ironic nodes via the hypervisor_type on the compute_nodes table right? | 14:44 |
mriedem | dtantsur: it's something i need to work on this week | 14:44 |
dansmith | mriedem: we can yeah | 14:44 |
mriedem | it's pretty open ended atm, except for thursday morning being cinder time | 14:44 |
dtantsur | mriedem: we have a few topics depending on the scheduling discussion outcome to an extent. so I guess Wed would work better, probably afternoon. | 14:45 |
*** suresh12 has quit IRC | 14:46 | |
dtantsur | but it's up to you of course :) | 14:46 |
dtantsur | vdrok: ^^ | 14:46 |
dansmith | mriedem: so your preference would be to do it fully automatic like that? we kinda need to backport this if we're going to remove the migration from queens | 14:46 |
mriedem | dansmith: so the problem with the offline data migrations command with this is we don't really have a marker i don't think | 14:46 |
dtantsur | or just don't remove the migration from queens... | 14:46 |
mriedem | since the extra specs are a json blob | 14:46 |
mriedem | but i haven't thought it through fully | 14:46 |
dansmith | mriedem: yup, hence my thinking that a one-shot command for a host would be good | 14:46 |
dansmith | dtantsur: yeah, but we really want to stop allowing the old model too, which we *could* do separate from the migration piece, but... | 14:47 |
mriedem | for all compute nodes where hypervisor_type == 'ironic'; find all instances where host/node in that list; do migrate instance extra spec | 14:47 |
dansmith | the migration piece in compute also brings overhead | 14:47 |
mriedem | dansmith: i wouldn't want to require a host, but it could be an option | 14:47 |
*** udesale has quit IRC | 14:47 | |
*** jheroux has joined #openstack-nova | 14:47 | |
*** udesale has joined #openstack-nova | 14:48 | |
dansmith | mriedem: well, for a dedicated command I was thinking make it specifically "run for instances on this host" so you're responsible for iterating hosts and therefore not running twice | 14:48 |
*** hrw has joined #openstack-nova | 14:49 | |
*** udesale has quit IRC | 14:49 | |
*** coreywright has quit IRC | 14:50 | |
mriedem | how do you know you've hit all hosts? | 14:50 |
mriedem | and then someone will say, how do i get the list of hosts | 14:50 |
dansmith | well, I'm thinking about tripleo where that's easy to determine | 14:51 |
mriedem | running twice isn't a problem either right? it's just a no-op if already migrated | 14:51 |
dansmith | sure, it's just super expensive | 14:51 |
mriedem | i'm generally never thinking about tripleo | 14:51 |
mriedem | :) | 14:51 |
dansmith | heh | 14:51 |
dtantsur | :D | 14:51 |
mriedem | my preference would be, host is optional, so if someone thinks they know better and want to iterate hosts client side, fine | 14:51 |
mriedem | otherwise we do it | 14:51 |
dansmith | how about we make it expected, else there's an --all option, | 14:52 |
dansmith | so it's clear that it's not just idempotent and zero impact? | 14:52 |
dansmith | and to be clear, this is a dedicated command with specific behaviors, yes? | 14:52 |
mriedem | it is idempotent except for the db read hit right? | 14:52 |
dansmith | right, idempotent is the wrong word, because it is, I meant "resumable" or "zero impact if nothing to do" | 14:53 |
dansmith | like, don't just run this on every puppet run | 14:53 |
mriedem | how is tripleo going to determine that it's done all of the migrations? | 14:53 |
mriedem | and can stop | 14:53 |
dansmith | tripleo won't, | 14:54 |
dtantsur | so, are you going to call into ironic in this command? | 14:54 |
mriedem | dtantsur: no | 14:54 |
dtantsur | sorry, I don't quite understand how you're going to know the resource class of the node | 14:54 |
mriedem | dtantsur: this is just duplicating what we do in nova-compute startup | 14:54 |
dansmith | it'll be a specific skip-level upgrades script | 14:54 |
dtantsur | well, in nova compute we're using data from ironic | 14:54 |
dansmith | dtantsur: yeah, we'll have to take a RC as well | 14:54 |
dansmith | it's going to be super offline | 14:54 |
dtantsur | I know, hence my concern :) | 14:54 |
dansmith | yup | 14:54 |
dtantsur | one mistake - and the cloud is in a very strange state | 14:55 |
dansmith | but that's the risk of skip level upgrades, | 14:55 |
dansmith | you're taking the complexity of skipping into your own hands | 14:55 |
dansmith | it's a tradeoff of complexity and downtime for infrequent upgrades | 14:55 |
dtantsur | okie, but how is the command invokation going to look? | 14:55 |
dansmith | that's been a core part of my messaging on the topic at least :) | 14:55 |
dansmith | nova-manage db migrate-ironic-things --resource_class 'undercloud' --do-all-make-my-db-hurt | 14:56 |
dtantsur | $ nova-migrate-to-pike <host> --node <uuid>=<class> --node <uuid2>=<class2> | 14:56 |
dtantsur | ? | 14:56 |
dtantsur | dansmith: wait, tripleo uses one resource class, but that does not mean everyone does | 14:56 |
jaypipes | dansmith: would you be able to attend this session in Denver? https://etherpad.openstack.org/p/queens-PTG-skip-level-upgrades | 14:56 |
dansmith | or if you have different ones, then: | 14:56 |
dansmith | nova-manage db migrate-ironic-things --resource_class 'undercloud' --host foo1 | 14:56 |
dansmith | dtantsur: sure, that means you have to do your hosts one at a time with a rc then | 14:57 |
dtantsur | dansmith: host == ironic node, not nova-compute process, right? | 14:57 |
dansmith | jaypipes: um yes? been working on this with lyarwood :) | 14:57 |
dtantsur | (sorry, I always confuse the terms) | 14:57 |
dansmith | dtantsur: ah, well, that's a fair point | 14:57 |
dansmith | dtantsur: I was meaning compute, but yeah --node is probably the better option | 14:57 |
rabel | mriedem: i answered to your questions on https://review.openstack.org/#/c/494169/ . could you have a look at it again? | 14:58 |
vdrok | dtantsur: yeah everything except friday works for me | 14:59 |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Mark LXC as missing for swap volume support https://review.openstack.org/482216 | 14:59 |
*** josecastroleon has quit IRC | 15:01 | |
dansmith | dtantsur: mriedem: anyway, let me cook something up along these lines and ya'll can rip on it | 15:01 |
dtantsur | yes please :) | 15:01 |
mriedem | we do have this compute_nodes.mapped column now | 15:01 |
mriedem | wonder if we could use that for dumb paging | 15:01 |
dansmith | mriedem: not really a good idea, I don't think | 15:02 |
dansmith | mriedem: we'd have to bump that for all the non-ironic computes too if we did | 15:02 |
mriedem | true | 15:02 |
mriedem | this is probably going to have to use all sqla orm code, | 15:03 |
dansmith | and | 15:03 |
mriedem | since we don't have some query methods you'd need on the objects | 15:03 |
mriedem | unless you just did ComputeNodeList.get_all and filter in python | 15:03 |
dansmith | maybe yeah | 15:03 |
dansmith | just some non-remotable object queries to make it clean is fine I think | 15:03 |
dansmith | no rpc impact there | 15:03 |
*** coreywright has joined #openstack-nova | 15:04 | |
*** abhi89 has quit IRC | 15:04 | |
*** abhi89 has joined #openstack-nova | 15:04 | |
*** artom_ has joined #openstack-nova | 15:04 | |
mriedem | taking a uuid would be nice, but you don't get the uuid out of the rest api until you're at pike | 15:04 |
mriedem | so that's out of the question probably | 15:04 |
openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Add attachment_complete call to volume/cinder.py https://review.openstack.org/493323 | 15:05 |
openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Tweak connection_info translation for the new Cinder attach/detach API https://review.openstack.org/493324 | 15:05 |
openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285 | 15:05 |
*** Oku_OS is now known as Oku_OS-away | 15:07 | |
*** vikrant has quit IRC | 15:07 | |
*** felipemonteiro has joined #openstack-nova | 15:07 | |
*** felipemonteiro_ has joined #openstack-nova | 15:09 | |
melwitt | abhi89: the cell with uuid of all zeros is "cell0" which contains only instances that failed to be scheduled. it's not associated with any compute host. see doc https://docs.openstack.org/nova/latest/user/cellsv2_layout.html | 15:11 |
*** rmart04 has quit IRC | 15:11 | |
*** felipemonteiro has quit IRC | 15:13 | |
*** lucasxu has joined #openstack-nova | 15:17 | |
*** kristian__ has quit IRC | 15:17 | |
*** kristian__ has joined #openstack-nova | 15:18 | |
*** kristia__ has joined #openstack-nova | 15:19 | |
*** kristian__ has quit IRC | 15:19 | |
*** kristia__ has quit IRC | 15:20 | |
*** kristian__ has joined #openstack-nova | 15:20 | |
*** kristian__ has quit IRC | 15:22 | |
*** kristian__ has joined #openstack-nova | 15:23 | |
*** suresh12 has joined #openstack-nova | 15:23 | |
*** gmann has quit IRC | 15:24 | |
*** annegentle has joined #openstack-nova | 15:24 | |
*** gmann has joined #openstack-nova | 15:24 | |
*** lbragstad has joined #openstack-nova | 15:25 | |
*** hferenc has quit IRC | 15:26 | |
*** kristian__ has quit IRC | 15:27 | |
*** cleong has joined #openstack-nova | 15:28 | |
efried | avolkov yt? | 15:29 |
*** gyee has joined #openstack-nova | 15:32 | |
*** tidwellr has quit IRC | 15:33 | |
*** vikrant has joined #openstack-nova | 15:33 | |
*** b4rti has quit IRC | 15:33 | |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Add some inline code docs tracing the cold migrate flow https://review.openstack.org/496861 | 15:34 |
*** tidwellr has joined #openstack-nova | 15:34 | |
*** yamamoto has joined #openstack-nova | 15:35 | |
*** kristian__ has joined #openstack-nova | 15:36 | |
avolkov | efried: hi | 15:37 |
*** baoli_ has quit IRC | 15:37 | |
efried | avolkov Was just about to respond to your ML post about HA/anti-affinity of SR-IOV VFs... | 15:37 |
*** baoli has joined #openstack-nova | 15:38 | |
efried | avolkov I think we can do a bit better even within the bounds of the existing placement API (assuming we get nested RPs). | 15:38 |
efried | ...by chunking the PFs into HA groups. | 15:39 |
efried | So I don't think you need the ports labeled P1, P2, P3, P4. I think you can label them G1 and G2, spread across your switches. | 15:39 |
avolkov | efried: some meta group based on those properties? sounds good | 15:40 |
efried | This gets a little weird in flavor land, though, cause you'd need a separate flavor for each group I think. | 15:40 |
efried | So you would have one flavor that says "give me two VFs: one from Switch 1 + Group 1; one from Switch 2 + Group 1" | 15:41 |
efried | Then another that says "give me two VFs: one from Switch 1 + Group 2; one from Switch 2 + Group 2" | 15:41 |
*** kristia__ has joined #openstack-nova | 15:41 | |
efried | ...and somehow alternate which one you use to do spawns, so you get saturation of the different ports. | 15:41 |
*** ssmith has joined #openstack-nova | 15:41 | |
efried | Using P1/P2/P3/P4 you have that same problem, only twice as bad :) | 15:42 |
avolkov | efried: yeah :), it's another question I wanted to ask | 15:42 |
mriedem | johnthetubaguy: here you go https://bugs.launchpad.net/nova/+bug/1715182 | 15:42 |
openstack | Launchpad bug 1715182 in OpenStack Compute (nova) "_rollback_live_migration does not remove allocations from destination node" [High,Triaged] | 15:42 |
edmondsw | efried what does the group signify that knowing the switch doesn't tell you? | 15:42 |
*** yamamoto has quit IRC | 15:43 | |
edmondsw | i.e., isn't the switch tag essentially a group tag? | 15:43 |
efried | no | 15:43 |
edmondsw | oh, I guess you could have the switches wired differently | 15:43 |
efried | (sorry, got an interrupt, gimme a few mins...) | 15:44 |
*** kristian__ has quit IRC | 15:45 | |
*** lucasagomes is now known as lucas-afk | 15:46 | |
efried | okay, so avolkov that's a point: how many VFs do you want? | 15:47 |
edmondsw | I guess what I'm getting at is that you shouldn't need to know switch or port... just groups | 15:48 |
efried | avolkov If you want four, then yeah, you only need one flavor. | 15:48 |
openstackgerrit | Merged openstack/os-vif master: Add plugin names as constants. https://review.openstack.org/500111 | 15:48 |
efried | "give me four VFs: Switch1 x Group1; Switch1 x Group2; Switch2 x Group1; Switch2 x Group2" | 15:49 |
*** kristian__ has joined #openstack-nova | 15:49 | |
mriedem | dtantsur: i've started a rough agenda at the bottom of this etherpad https://etherpad.openstack.org/p/nova-ptg-queens | 15:49 |
mriedem | penciled in ironic for 3pm on wed | 15:49 |
edmondsw | efried why wouldn't that be (give me 2 from group 1 and 2 from group 2)? | 15:50 |
dtantsur | cool, lemme check our schedule | 15:50 |
efried | edmondsw Because then you might get both from the same switch in group 1 | 15:50 |
*** kbaegis has quit IRC | 15:50 | |
edmondsw | efried not if they defined the groups properly... | 15:51 |
dtantsur | mriedem: do you remember when we have lunch? | 15:51 |
mriedem | sdague: lyarwood: stable/pike backport for a novaclient thing regressed since 9.0.0 https://review.openstack.org/#/c/495901/ | 15:51 |
dtantsur | is it right after or...? | 15:51 |
mriedem | dtantsur: i was told 12-1 | 15:51 |
dtantsur | thnx | 15:51 |
efried | edmondsw How can you define two groups to ensure you get four separate ports across two separate switches? | 15:51 |
mriedem | 3pm wednesday would be *after* lunch :) | 15:51 |
edmondsw | group 1 = one port to sw1 and one to sw2, group 2 = one port to sw1 and one to sw2, then ask for 2 ports in each group | 15:52 |
*** artom_ is now known as artom | 15:53 | |
*** kristia__ has quit IRC | 15:53 | |
*** kristian__ has quit IRC | 15:53 | |
efried | edmondsw But placement doesn't know enough to not give you both VFs from group 1 on the same switch. | 15:53 |
*** kairo has joined #openstack-nova | 15:53 | |
edmondsw | efried there aren't 2 ports in group 1 with the same switch | 15:54 |
efried | Yes, there are multiple VFs on each pport. | 15:54 |
edmondsw | oh, VFs... | 15:54 |
edmondsw | I gotcha now | 15:55 |
efried | And yes, you could conceivably do this same thing with four groups - but enumerating switches might make more sense to the user; and you also want the model to extend to >2 switches, >2 ports per switch. | 15:55 |
*** psachin has quit IRC | 15:55 | |
dtantsur | mriedem: okay, sounds good | 15:55 |
efried | although... avolkov that might actually make more sense. If you always know you want four VFs, you could just tag your PFs in groups so they'll always be spread out. | 15:56 |
edmondsw | efried how about group 1 = 2 ports to sw1 and group 2 = 2 ports to sw2? | 15:56 |
efried | edmondsw Then again you'll ask for two VFs from group 1 and they might wind up coming from the same pport | 15:56 |
edmondsw | yep, k... better for PFs but doesn't help with VFs | 15:57 |
efried | eh? | 15:57 |
edmondsw | nm... it doesn't work, so it doesn't work :) | 15:57 |
edmondsw | I'm not following why you wouldn't tag them with the port, then | 15:58 |
efried | avolkov In your email example, it's no different than having labeled P1,P2,P3,P4 - but extending to more than four pports (or reducing the problem set to fewer than 4 desired VFs) it makes more sense to think of groups - where the total number of groups is the number of VFs you're going to want from a single allocation request. | 15:58 |
efried | edmondsw ^^ | 15:58 |
avolkov | efried: groups are okay if you have the same requirements for each boot request | 16:00 |
avolkov | efried: with original properties you can ask distinct ports for one boot request and distict switches for another | 16:01 |
efried | avolkov Yeah, I get it. If they're different, then it makes more sense for each PF to have its own label, and you do your HA/anti-affinity by constructing your flavors appropriately. | 16:01 |
efried | Problem with that, though, is if you don't have exactly the same number and configuration of SR-IOV cards on all your hosts. | 16:02 |
edmondsw | will it be possible to request ports on separate identical cards (HA if a card fails)? | 16:02 |
efried | So it probably makes more sense to *call* them groups anyway, even if they usually/always map to PFs :) | 16:03 |
sean-k-mooney | efried: i would prefer if we did not model this in flavor or image properties though | 16:03 |
openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Add functional recreate test for live migration pre-check fails https://review.openstack.org/500907 | 16:03 |
openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Cleanup allocations on invalid dest node during live migration https://review.openstack.org/500908 | 16:03 |
efried | sean-k-mooney Which "this"? | 16:03 |
sean-k-mooney | efried: really we should try to model the bond requiremetn as an atribute of the neutron port | 16:03 |
sean-k-mooney | vf selection policy | 16:03 |
avolkov | sean-k-mooney: +1 not to use flavors ) | 16:04 |
efried | Yeah, that makes sense, sorry. | 16:04 |
*** hamzy has quit IRC | 16:04 | |
openstackgerrit | melanie witt proposed openstack/nova master: Request zero root disk for boot-from-volume instances https://review.openstack.org/428481 | 16:04 |
openstackgerrit | melanie witt proposed openstack/nova master: Claim and report zero root disk for boot-from-volume instances https://review.openstack.org/428505 | 16:04 |
efried | but wait | 16:05 |
*** marst has quit IRC | 16:05 | |
efried | wouldn't we like to be able to do a spawn with SR-IOV VFs in one command rather than two? | 16:05 |
sean-k-mooney | efried: did you see the section i added to the ptg etherpad https://etherpad.openstack.org/p/nova-ptg-queens lines 107-125 | 16:05 |
sean-k-mooney | efried: no | 16:05 |
*** marst has joined #openstack-nova | 16:05 | |
sean-k-mooney | efried: and yes but not via flavor | 16:06 |
efried | Is a port bound to a host? | 16:06 |
sean-k-mooney | if we can do it with one command via nova-boot sure but i dont whant to create a flavor multiple time with just different number of interfaes | 16:06 |
*** sahid has quit IRC | 16:06 | |
sean-k-mooney | efried: it is after nova selects the host | 16:06 |
sean-k-mooney | efried: before that it is just a logical port in a db | 16:07 |
sean-k-mooney | efried: as part of portbinding nova compute updates the neutron port with the host id | 16:07 |
*** dtantsur is now known as dtantsur|afk | 16:07 | |
efried | So you want to create the port with an anti-affinity/HA spec which specifies the number of VFs and how they should be spread out... | 16:08 |
sean-k-mooney | efried: yep | 16:08 |
*** yassine has quit IRC | 16:08 | |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Skip more racy rebuild failing tests with cells v1 https://review.openstack.org/499001 | 16:08 |
efried | ...and then we schedule to the host and spawn attaches the right number of VFs with the right distribution. | 16:08 |
*** kristian__ has joined #openstack-nova | 16:09 | |
efried | There's a big hand-wavey part in the middle there, though, where the scheduler was able to figure out which compute host(s) would be able to honor that request. Is the scheduler (and/or, gods forbid, the placement API) supposed to introspect the port metadata to help with that decision?? | 16:10 |
sean-k-mooney | efried: yep see my comments in https://review.openstack.org/#/c/463526/ and https://review.openstack.org/#/c/182242/ to this effect | 16:10 |
sean-k-mooney | no basically before the scheduler starts scheduling today the neutron v2 client api in nova retrives the port from neutorn | 16:11 |
*** marst_ has joined #openstack-nova | 16:11 | |
*** marst has quit IRC | 16:12 | |
sean-k-mooney | if that port is vnic_type direct/macvtap or virtio-forwarder it create a new pcieresutespec object | 16:12 |
sean-k-mooney | we need to extend that to also read the ha spec and add that to the picerequeste spec so that when tha tis passed to the sceduler/placement it can fufille the requirementes for ha | 16:12 |
sean-k-mooney | this is what we have imlemented for the feature based scheduing also | 16:13 |
efried | Yeah, okay, so that's how it works today; but I thought we were trying to move away from that kind of special-casing as we get into placement. | 16:13 |
sean-k-mooney | efried: yes so in placement i would like to be able to express affinity and anti affintiy | 16:13 |
*** yamahata has quit IRC | 16:14 | |
sean-k-mooney | so we would ask for 2 vf with pf antiaffinity | 16:14 |
*** Apoorva has joined #openstack-nova | 16:14 | |
*** kristian__ has quit IRC | 16:14 | |
sean-k-mooney | placement would filer host based on that and then the scheduler would make the final desision | 16:14 |
efried | Has jaypipes weighed in yet on how affinity/anti-affinity might be made to work with placement? | 16:15 |
dansmith | efried: distance | 16:16 |
sean-k-mooney | proably its not the first time i have mentioned this to him but not aware of his current stance | 16:16 |
dansmith | efried: as mentioned earlier this morning, but also quite a bit in boston during that session | 16:16 |
*** suresh12 has quit IRC | 16:16 | |
edmondsw | there are anti-affinity needs at multiple layers... 1) device, 2) PF, 3) switch... | 16:16 |
sean-k-mooney | edmondsw: yes i was hoping we could model the switch as a trait on the pf if that made sense? | 16:17 |
efried | Right, so basically placement would need a generic, multi-layer-capable distance/affinity mechanism, and then consumers could model as they see fit within that framework. | 16:17 |
sean-k-mooney | efried: yes ideally. its just up to the consumers to model the dependcies with traits and netested providers correctly | 16:18 |
*** shan has joined #openstack-nova | 16:18 | |
*** marst has joined #openstack-nova | 16:18 | |
sean-k-mooney | that is easier said then done however | 16:18 |
sean-k-mooney | ideally i would like to see a request for a bonded port that looked someting like this | 16:19 |
efried | sean-k-mooney Definitely makes sense for the switch to be a trait on the PF. Or for the switch to be a RP with its PFs nested underneath it. Either way would work. But if these affinity gizmos are separate from traits, then it probably doesn't matter as much how the RPs are nested. | 16:19 |
sean-k-mooney | neutron port-create --binding:vnic_type=direct --binding:profile={bond=true, bond_mode=active-backup,bound_count=2,bond_antiafinity=pf} --name bond1 private | 16:19 |
*** marst_ has quit IRC | 16:19 | |
efried | Where you could conceivably also say bond_antiaffinity=pf,switch ? | 16:19 |
sean-k-mooney | efried: yes | 16:20 |
jaypipes | efried: distance would be stored in an aggregate_distances table, which would store the distance between the providers in one aggregate and providers in another. | 16:20 |
jaypipes | efried: distance would just be a number. higher the number, greater the relative distance. | 16:20 |
edmondsw | or bond_antiaffinity=card,switch if you want the PFs to come from different physical CNAs? | 16:21 |
sean-k-mooney | jaypipes: im not sure that distance would be a good match to antiafinity/affinity if i need to manually create agggreates for the vfs but ingeneral it is usefull | 16:21 |
sean-k-mooney | edmondsw: you could but you see the general pattern i would love to express this requirement on the neutorn port in a general way rather then statically defiened in a flavor | 16:22 |
edmondsw | sean-k-mooney yeah, and I think I agree with that if we can make it work | 16:23 |
efried | Now, let me make sure I understand something: placement is never going to be in the business of assigning individual VFs around. It's just gonna decrement the count and say "you got one from this RP". | 16:23 |
sean-k-mooney | bassically i would like to keep flavor extraspecs for compute requirement | 16:23 |
*** marst_ has joined #openstack-nova | 16:23 | |
*** marst has quit IRC | 16:23 | |
*** trinaths has left #openstack-nova | 16:23 | |
efried | Then it's up to the virt driver (or maybe the mech driver in this case?) to decide which specific VF to use -- or even to create the VF on the fly if that's something it can do. | 16:23 |
sean-k-mooney | efried: maybe... i think jay would agree i would not mind extending it to be able to do indvidual assignment | 16:24 |
jaypipes | sean-k-mooney: it's a possibility. | 16:24 |
efried | Point is, placement shouldn't be aware of an individual VF any more than it's aware of an individual memory megabyte. | 16:24 |
jaypipes | sean-k-mooney: in the same way that we agreed not to have aggregates have traits (instead, we "push down" all traits to the resource provider) | 16:25 |
jaypipes | efried: not necessarily. | 16:25 |
dansmith | jaypipes: eh? | 16:25 |
efried | jaypipes: eh? | 16:25 |
jaypipes | efried: if you need to differentiate between two VFs on a host because those two VFs expose different capabilities, then you will need to create each different VF as a resource provider. | 16:26 |
sean-k-mooney | efried: well i would like to have the mem_page resouce provider track indiviual pages too but i have more importing things to adress first | 16:26 |
*** rajathagasthya has joined #openstack-nova | 16:26 | |
dansmith | ah, sure | 16:26 |
efried | Okay, yeah. | 16:26 |
dansmith | not sure when/how that would happen | 16:26 |
dansmith | but if it did, then I guess | 16:26 |
dansmith | although then we're going to have a shitton of single-resource providers | 16:26 |
jaypipes | dansmith: ask sean-k-mooney. Intel excels at creating uses for complexity. | 16:26 |
dansmith | I'd hope that you could separate that into 32 VFs with tls-offload and 32 without, for a 64-vf nic | 16:27 |
efried | okay, as long as the general case is to have the inventory of VFs just be a number. | 16:27 |
dansmith | but.. | 16:27 |
dansmith | efried: it's still that, | 16:27 |
dansmith | efried: you'd just have inventory=1 for these | 16:27 |
efried | yeah yeah. | 16:27 |
efried | I get it. | 16:27 |
efried | But the tls-offload thing... | 16:27 |
sean-k-mooney | well i can certenly do a lot with singel-resouce proverders | 16:28 |
efried | I would really hope there would be some other way to specify that. | 16:28 |
*** annegentle has quit IRC | 16:28 | |
dansmith | efried: I wouldn't | 16:28 |
jaypipes | sean-k-mooney: would single resource providers provide spell checking? :) | 16:28 |
sean-k-mooney | haha perhaps... | 16:28 |
dansmith | efried: tls-offload being a trait for regular nics, and vfs, so if some have it and some don't... | 16:28 |
jaypipes | sean-k-mooney: :P | 16:28 |
efried | But if I create my VFs on the fly, and could assign that trait to any one of 'em on the fly (say, based on a prop in the binding profile)... | 16:29 |
jaypipes | dansmith, efried: technically you wouldn't necessarily need to have single resource providers for each VF. just one resource provider per set of VFs with similar capabilities. | 16:29 |
dansmith | efried: no, that's not the same | 16:29 |
dansmith | jaypipes: right exactly | 16:29 |
*** itlinux has joined #openstack-nova | 16:29 | |
* jaypipes runs away before calling it pci device pools. | 16:29 | |
dansmith | efried: I meant if some VFs would be unable to provide tls offload, then they go in a separate provider without that trait | 16:30 |
sean-k-mooney | so our current generation of nics cant do this but in future nics we will be able to load firmware that gives different feature per vf | 16:30 |
dansmith | efried: if they all can and it's a by-request thing, then that means they're all in one provider with that trait and the virt driver decides to configure it as such based on the request | 16:30 |
*** kristian__ has joined #openstack-nova | 16:30 | |
sean-k-mooney | with fortvile XL710 its card wide | 16:30 |
sean-k-mooney | so all vf would have same features/tratis | 16:30 |
dansmith | sean-k-mooney: yeah and we're all REALLY glad for that | 16:30 |
dansmith | (not) | 16:30 |
efried | dansmith Ah, exactly what I was getting at earlier, but you said you didn't want. | 16:30 |
dansmith | efried: huh? | 16:31 |
dansmith | efried: a request has a list of required and preferred traits | 16:31 |
jaypipes | dansmith: don't tempt sean-k-mooney. he will call up the hw designers and ask them to rework it to be more complicated :P | 16:31 |
*** marst has joined #openstack-nova | 16:31 | |
dansmith | efried: what I said was I didn't want virt-specific communication from the api user to the virt driver | 16:32 |
*** marst_ has quit IRC | 16:32 | |
sean-k-mooney | haha well i did ask them to make atleas per pf instead of per card... | 16:32 |
dansmith | efried: this is not that, this is a generic and abstract requested trait.. placement has already filtered out virt hosts that can't do that generic thing | 16:32 |
efried | okay, "preferred trait" is new to me. | 16:32 |
dansmith | efried: doesn't matter, required trait is the same | 16:32 |
dansmith | for this example | 16:32 |
sean-k-mooney | efriad: the idea was the required traits would be enforced by filter and prefered trais would be consumed by weigher | 16:33 |
dansmith | sean-k-mooney: and both could feed into how the virt driver does something eventually | 16:33 |
sean-k-mooney | yes | 16:34 |
abhi89 | hey guys.. can someone please review https://review.openstack.org/#/c/485121/.. pending from a long time.. | 16:34 |
sean-k-mooney | my go to examle is dpdk requires sse3 to work but would prefer avx for performance reasons | 16:34 |
lbragstad | mriedem: https://review.openstack.org/#/c/500918/ | 16:34 |
*** kristian__ has quit IRC | 16:35 | |
*** Swami has joined #openstack-nova | 16:37 | |
*** cfriesen__ has quit IRC | 16:38 | |
*** gbarros has quit IRC | 16:38 | |
*** ijw has quit IRC | 16:40 | |
mriedem | lbragstad: comment inline | 16:41 |
efried | What's the plan for associating physnets with RPs? | 16:41 |
efried | Does the RP have a trait like CUSTOM_PHYSNET_XXX where XXX is somehow associated with the port's physnet? | 16:42 |
lbragstad | mriedem: good call - done | 16:43 |
openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Add attachment_complete call to volume/cinder.py https://review.openstack.org/493323 | 16:46 |
openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Tweak connection_info translation for the new Cinder attach/detach API https://review.openstack.org/493324 | 16:46 |
openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285 | 16:46 |
*** yamahata has joined #openstack-nova | 16:49 | |
*** Apoorva has quit IRC | 16:49 | |
*** Apoorva has joined #openstack-nova | 16:50 | |
*** suresh12 has joined #openstack-nova | 16:50 | |
*** kristian__ has joined #openstack-nova | 16:51 | |
*** kbaegis has joined #openstack-nova | 16:52 | |
*** kbaegis has quit IRC | 16:52 | |
*** kbaegis has joined #openstack-nova | 16:53 | |
*** Apoorva has quit IRC | 16:54 | |
*** kristian__ has quit IRC | 16:55 | |
*** gbarros has joined #openstack-nova | 16:56 | |
*** shan has quit IRC | 16:57 | |
*** abalutoiu has joined #openstack-nova | 16:57 | |
*** jpena is now known as jpena|off | 16:57 | |
*** david-lyle has quit IRC | 16:59 | |
*** cfriesen__ has joined #openstack-nova | 17:00 | |
*** derekh has quit IRC | 17:00 | |
*** erlon has joined #openstack-nova | 17:01 | |
*** kbaegis has quit IRC | 17:02 | |
*** kbaegis has joined #openstack-nova | 17:02 | |
*** kbaegis has quit IRC | 17:02 | |
*** ralonsoh has quit IRC | 17:02 | |
*** kbaegis has joined #openstack-nova | 17:02 | |
*** lpetrut_ has quit IRC | 17:03 | |
*** eharney_ has joined #openstack-nova | 17:04 | |
*** eharney has quit IRC | 17:05 | |
*** eharney_ is now known as eharney | 17:05 | |
sean-k-mooney | efried: i think physnet can be a standard trait prefix. so NW_PHYSNET_XXX | 17:07 |
efried | Okay; I thought you weren't allowed to create a trait with anything other than a CUSTOM_ prefix. | 17:08 |
efried | But that wasn't really my question. | 17:08 |
*** harlowja has joined #openstack-nova | 17:08 | |
sean-k-mooney | efried: this was one of the usecases i wanted to have key value traits for originally but standard prefixes i think are ok too | 17:08 |
efried | My question is: who's responsible for recognizing that the XXX corresponds to the physnet in the neutron port? | 17:08 |
*** Apoorva has joined #openstack-nova | 17:09 | |
sean-k-mooney | efried: technically yes but lacking key value traits i was hoping we could have a set of stadard prefixes that you were also allowed to create. phynets is one the other option is to have physnet be a field of resouce class | 17:09 |
*** shan has joined #openstack-nova | 17:09 | |
efried | Okay, but who's responsible for recognizing that the XXX corresponds to the physnet in the neutron port? | 17:10 |
sean-k-mooney | efried: well if nova reads the phynet form the port it can compute the trait name and placement can then just do a sting match | 17:10 |
efried | That would be one way... is that how it's going to work? Or is this still part of the open discussion? | 17:11 |
*** kristian__ has joined #openstack-nova | 17:11 | |
sean-k-mooney | still open. i was also thinking of ways to have neutron pass traits/resouce prodier request to nova so that nova does not have to compute the trait name | 17:12 |
sean-k-mooney | for example addint a traits field to the vif_binding details with the physnet name trait so that nova does not have to query neutron for the physnet | 17:13 |
sean-k-mooney | again this is up for discussion | 17:13 |
*** david-lyle has joined #openstack-nova | 17:14 | |
efried | sean-k-mooney Okay, thanks for the info. | 17:15 |
*** kristian__ has quit IRC | 17:16 | |
*** penick has joined #openstack-nova | 17:16 | |
mriedem | dtantsur|afk: vdrok: do you know if there are any docs that talk about quota considerations for a tenant that is accessing both VMs and BMs? it's a topic i added here for the ptg: https://etherpad.openstack.org/p/queens-PTG-vmbm | 17:16 |
vdrok | hrm, not in ironic docs I think. | 17:17 |
sean-k-mooney | nova is currently the main thing interacting with traits and placement but i would like to add some knolowe of those apis to neutron so that nova does not have to know as much deails about the networking contriants going forwand and can jsut fowrad the reques for resouce providers and traints form neutorn. | 17:17 |
mriedem | sean-k-mooney: i think mlavalle already started something like a placement client in neutron a few releases ago | 17:18 |
sean-k-mooney | mriedem: cool we will need if for thinks like bandwith qos. e.g. if we model bandwith in placement and you increase the minium bandwith for a port i should go to placement and check that there is capasity left and increase the claim if so or fail the requst if not | 17:20 |
sean-k-mooney | e.g. if port is bound it should only allow bandwith to be increased if placement says there is capasity to do so and provide error to user if it cannot | 17:21 |
*** hamzy has joined #openstack-nova | 17:21 | |
*** kbaegis has quit IRC | 17:22 | |
*** sambetts is now known as sambetts|afk | 17:22 | |
*** tesseract has quit IRC | 17:25 | |
*** rcernin has quit IRC | 17:25 | |
*** ijw has joined #openstack-nova | 17:27 | |
jaypipes | sean-k-mooney: there is no such thing as a standard trait prefix. | 17:30 |
jaypipes | sean-k-mooney: that XXX means it has to be a custom trait. | 17:30 |
*** david-lyle has quit IRC | 17:30 | |
*** suresh12 has quit IRC | 17:31 | |
sean-k-mooney | jaypipes: correct today. i was hopping we could add them if we were going to use them for standard thing like physnets to differenciate them for user created traits | 17:31 |
sean-k-mooney | basically any traint that does not start with custom_ i consider to be a trait that must be defiend in os-traits | 17:32 |
jaypipes | sean-k-mooney: I would oppose that. traits are boolean values. | 17:32 |
*** gouthamr has quit IRC | 17:32 | |
jaypipes | sean-k-mooney: the physical network that a NIC is associated with must be a custom trait. | 17:33 |
sean-k-mooney | but just as we have defiend the custom_ as a user defiend prefix i was hoping we could have other prefiex reseved for internal use such as the physnet | 17:33 |
jaypipes | sean-k-mooney: why though? | 17:33 |
jaypipes | sean-k-mooney: what benefit does that bring? | 17:33 |
sean-k-mooney | so i can tell the differnece between traits used by openstack to function and ones added by admins for there own use | 17:33 |
*** vikrant has quit IRC | 17:34 | |
jaypipes | sean-k-mooney: that' | 17:34 |
dansmith | sean-k-mooney: that's custom | 17:34 |
jaypipes | s the CUSTOM_ prefix. | 17:34 |
sean-k-mooney | dansmith: a physnet is custom? | 17:34 |
*** yassine has joined #openstack-nova | 17:35 | |
*** yassine has quit IRC | 17:35 | |
dansmith | o.O | 17:35 |
dansmith | if it's not a standard one, then it's custom :) | 17:35 |
sean-k-mooney | we need to apply physnets to all sriov vf otherwise we cant use them with neutron networks | 17:35 |
jaypipes | there's no such thing as a "standard physnet"... | 17:35 |
jaypipes | it's a named entity | 17:36 |
sean-k-mooney | yes we cant standaries the full trait because its just a config option | 17:36 |
sean-k-mooney | hence haveing a standard prefix | 17:36 |
jaypipes | no, it's not a config option... it's an attribute of the port profile isn't it? | 17:36 |
sean-k-mooney | no | 17:36 |
dansmith | not for sriov right? | 17:36 |
sean-k-mooney | it a neutorn and nova config option | 17:36 |
dansmith | but even still, those'll all have to be custom ones anyway right? | 17:37 |
sean-k-mooney | for sriov its set in the pci whitelist | 17:37 |
jaypipes | ugh | 17:37 |
dansmith | because they're not enumerable across all deployments | 17:37 |
*** annegentle has joined #openstack-nova | 17:37 | |
*** shan7 has joined #openstack-nova | 17:37 | |
jaypipes | what dansmith said. | 17:37 |
sean-k-mooney | well no because i have no ideay which pci device is connected to which phyical network unless you tell me | 17:37 |
dansmith | um, wat? | 17:38 |
jaypipes | dansmith: he's saying "you" as in the nova.conf setting. | 17:38 |
*** liverpooler has quit IRC | 17:38 | |
sean-k-mooney | yes its not automatically discoverable so we have to declare it statically in the nova.conf | 17:38 |
dansmith | we will probably have to do something like we were going to do for ironic, which is synthesize CUSTOM_PHYSNET_$thing_in_your_config | 17:38 |
jaypipes | i.e. unless the nova.conf pci whitelist indicates which PCI devices are asssociated with which physnet, there's no way for code on the compute host to know. | 17:38 |
dansmith | sean-k-mooney: right, I know | 17:38 |
dansmith | sure | 17:39 |
dansmith | we have that today | 17:39 |
sean-k-mooney | dansmith: yes so when we systesize traiths i was suggesting uses a prefix other then custom to do that | 17:39 |
dansmith | sean-k-mooney: yeah but that does't work | 17:39 |
dansmith | sean-k-mooney: because anything but a CUSTOM_ is a hard enum in a library | 17:39 |
dansmith | sean-k-mooney: anything synthesized by the operator or somecode has to be CUSTOM_ | 17:40 |
*** armax has joined #openstack-nova | 17:40 | |
sean-k-mooney | dansmith: correct so im suggesting that we extend os tratis to have other prefixes that are not enums. if that is not desirabel then CUSTOM_ works too | 17:40 |
sean-k-mooney | i just can tell if its created by a person of synthesize by openstack | 17:41 |
*** shan has quit IRC | 17:41 | |
*** shan7 has quit IRC | 17:42 | |
*** moshele has joined #openstack-nova | 17:43 | |
*** shan has joined #openstack-nova | 17:44 | |
sean-k-mooney | may main concern is that as an enduse i have no way of knowing is CUSTOM_PHYSNET_<XYZ> is special custom trait that casuse a change in the behaior of openstack vs CUSTOM_MY_TRAIT_<XYZ> that does not. | 17:44 |
*** david-lyle has joined #openstack-nova | 17:46 | |
*** shan7 has joined #openstack-nova | 17:47 | |
*** shan has quit IRC | 17:48 | |
*** shan7 has quit IRC | 17:48 | |
sean-k-mooney | anyway got to run. food is calling | 17:48 |
*** shan has joined #openstack-nova | 17:48 | |
*** gvrangan has joined #openstack-nova | 17:52 | |
*** kristian__ has joined #openstack-nova | 17:53 | |
gvrangan | https://docs.openstack.org/nova/pike Folloed the latest install in centOs7 | 17:55 |
gvrangan | the hypervisot list is not listing | 17:55 |
gvrangan | the computes are not added to cells | 17:56 |
gvrangan | Should the doc be updated? | 17:56 |
*** kristia__ has joined #openstack-nova | 17:56 | |
*** suresh12 has joined #openstack-nova | 17:57 | |
*** kristian__ has quit IRC | 17:57 | |
*** cdent has joined #openstack-nova | 17:59 | |
*** gouthamr has joined #openstack-nova | 17:59 | |
*** baoli has quit IRC | 18:00 | |
*** baoli has joined #openstack-nova | 18:01 | |
*** moshele has quit IRC | 18:02 | |
*** Apoorva_ has joined #openstack-nova | 18:03 | |
gvrangan | when I execure the discover, the computes are not getting listed | 18:04 |
gvrangan | should the nova compute be configure differntly in pike? | 18:04 |
*** Apoorva has quit IRC | 18:06 | |
*** karthiks has quit IRC | 18:06 | |
melwitt | gvrangan: which instructions did you follow? this? https://docs.openstack.org/nova/latest/user/cells.html#fresh-install | 18:07 |
jaypipes | gvrangan: pls see /topic. Best to ask your question on the @openstack mailing list. | 18:07 |
gvrangan | melwitt, I followed only the nhttps://docs.openstack.org/nova/pike/install/controller-install-rdo.html and https://docs.openstack.org/nova/pike/install/compute-install-rdo.html | 18:08 |
*** rabel has quit IRC | 18:08 | |
openstackgerrit | Jackie Truong proposed openstack/python-novaclient master: Microversion 2.54 - Add trusted_certificates param https://review.openstack.org/500396 | 18:11 |
melwitt | gvrangan: okay. I see all of the commands you need are in those docs. so you have to make sure you see cell0 and cell1 when you do 'nova-manage cell_v2 list_cells' and then make sure you did 'nova-manage cell_v2 discover_hosts --verbose' after you have brought up the compute node | 18:13 |
*** suresh12 has quit IRC | 18:14 | |
*** suresh12 has joined #openstack-nova | 18:17 | |
*** gszasz has quit IRC | 18:20 | |
rybridges1 | Hello all | 18:20 |
rybridges1 | I had a quick question about nova cells | 18:20 |
rybridges1 | We are currently attempting to deploy a fresh ocata cluster. I was wondering if [cells] section of nova.conf is required for cells v2 at all? I read in the comments that the stuff under that section is only for cells v1, but just wanted to make sure | 18:21 |
*** karthiks has joined #openstack-nova | 18:22 | |
melwitt | rybridges1: that's correct. see 4. on the FAQ, [cells] section is not to be used https://docs.openstack.org/nova/latest/user/cells.html#faqs | 18:23 |
efried | jaypipes We were talking last week about how to model e.g. minimum egreess bandwidth support on SR-IOV VFs. | 18:24 |
rybridges1 | Okay great! Thanks melwitt | 18:24 |
jaypipes | efried: who is we? :) | 18:25 |
efried | dansmith suggested we would model the PF as a RP with e.g. SRIOV_VFS=48,EGRESS_BW_PCT=100 | 18:25 |
efried | So that basically you would grab some number of VFs and some percentage of the bandwidth, and whichever you exhausted first would take that PF out of the running for subsequent requests, kind of thing. | 18:26 |
efried | First of all, is this along the lines of what you've been thinking? | 18:26 |
efried | Doesn't have to be percentage; could be bps or whatever; point is the number of VFs and the total bandwidth are separate but parallel resource classes in the RP. | 18:27 |
cdent | “parallel”? | 18:27 |
efried | just meaning that they're RC inventories on the same RP | 18:27 |
* efried will stop trying to invent terminology | 18:28 | |
cdent | isn’t that what we do around here? | 18:28 |
efried | Some of us shouldn't. | 18:28 |
jaypipes | efried: yep. that's pretty close. I don't like the pct versus using bytes_per_sec but yeah. | 18:29 |
jaypipes | efried: in fact, that's pretty close to what I had written on the ML, no? | 18:29 |
efried | jaypipes okay, so help me fill in the gaps here. | 18:29 |
efried | IRL I'll have multiple PF-y RPs, and let's say they each have both of those RC inventories defined. | 18:30 |
jaypipes | k | 18:30 |
efried | When I make a request for, say, SRIOV_VFS=1,EGRESS_BW_PCT=20 -- what's to stop placement from allocating the VF inventory from one RP and the egress bandwidth inventory from another?? | 18:31 |
*** rajathagasthya has quit IRC | 18:31 | |
openstackgerrit | Mateusz Kowalski proposed openstack/nova stable/pike: Handle keypair not found from metadata server using cells https://review.openstack.org/500953 | 18:32 |
openstackgerrit | Mateusz Kowalski proposed openstack/nova stable/ocata: Handle keypair not found from metadata server using cells https://review.openstack.org/500954 | 18:32 |
*** crushil has quit IRC | 18:34 | |
* efried is hoping jaypipes is (a) composing an eloquent but incredibly clear response; or (b) temporarily distracted by real work but eagerly looking forward to getting to (a); but not (c) scraping skull fragments and bits of brain off the walls. | 18:36 | |
jaypipes | efried: actually currently stressing out trying to figure out how to deal with this hurricane that is going to hit us. | 18:36 |
efried | jaypipes Been there, done that. Where you at? | 18:37 |
jaypipes | efried: and getting my girls to safety and my wife to her plane flight to Italy on Sunday :( | 18:37 |
jaypipes | efried: Sarasota | 18:37 |
efried | Totally counts as (b) | 18:38 |
jaypipes | efried: the answer to your question is: nothing would stop placement from doing so. | 18:40 |
efried | jaypipes Then... "eek". | 18:40 |
jaypipes | efried: yeah | 18:40 |
*** ijw has quit IRC | 18:41 | |
efried | The followup, of course, is what about SRIOV_VFS=4,EGRESS_BW_PCT=20 ? | 18:41 |
*** crushil has joined #openstack-nova | 18:41 | |
jaypipes | efried: we would need to add some mechanism to the request that says "make sure the thing providing EGRESS_BW_PCT and SRIOV_VF is the same provider. | 18:42 |
efried | jaypipes Rojah dat. Any thoughts been assayed in that regard to this point? | 18:42 |
*** sridharg has quit IRC | 18:42 | |
melwitt | mriedem: I'm gonna sign up for that nova project update redhat interview thing at the PTG | 18:43 |
jaypipes | efried: resource_constraints=same_provider:SRIOV_NET_VF,NET_EGRESS_BYTES_SEC&resources=SRIOV_NET_VF:1&NET_EGRESS_BYTES_SEC:20000 | 18:44 |
mriedem | melwitt: awesome | 18:44 |
openstackgerrit | Merged openstack/nova master: Replace dd with shred for zeroing lvm volumes. https://review.openstack.org/495532 | 18:44 |
*** ijw has joined #openstack-nova | 18:46 | |
efried | jaypipes What stage is that semantic in? Just popped out of your head, in a spec somewhere, implemented, released? | 18:46 |
*** Apoorva_ has quit IRC | 18:47 | |
*** Apoorva has joined #openstack-nova | 18:47 | |
*** moshele has joined #openstack-nova | 18:47 | |
*** tinwood has quit IRC | 18:48 | |
jaypipes | efried: popped off the top of my thick, oh so thick, head of hair. | 18:48 |
melwitt | mriedem: let me know if there's anything else you'd like me to highlight other than cells and placement. I was gonna go through the rel notes and dev ML announcements to see what else to mention | 18:48 |
*** pcaruana has quit IRC | 18:49 | |
melwitt | and then I'll use the nova PTG etherpad to summarize what's coming up in queens | 18:49 |
efried | jaypipes Cool, will add it to discussion points. | 18:49 |
efried | I still need to complete my reading, but presumably there's a syntax for requesting multiple different resources of the same class with different traits? | 18:49 |
*** tinwood has joined #openstack-nova | 18:49 | |
*** moshele has quit IRC | 18:51 | |
efried | jaypipes So like, pursuant to the anti-affinity grouping conversation avolkov and I were having earlier, I want to be able to say gimme (SRIOV_NET_VF:1&NET_EGRESS_BYTES_SET:2000&traits=CUSTOM_PF_HA_GROUP_1; SRIOV_NET_VF:1&NET_EGRESS_BYTES_SET:2000&traits=CUSTOM_PF_HA_GROUP_2) | 18:51 |
mriedem | melwitt: i can send you my list that i sent internally | 18:51 |
*** suresh12 has quit IRC | 18:51 | |
melwitt | mriedem: cool, I think that would be helpful. thanks | 18:52 |
*** suresh12 has joined #openstack-nova | 18:53 | |
*** prometheanfire has joined #openstack-nova | 18:54 | |
jaypipes | efried: lemme pastebin something for that | 18:54 |
prometheanfire | this look like an error with the os-xenapi bump? http://logs.openstack.org/70/500770/3/check/gate-cross-nova-python27-ubuntu-xenial/1305547/testr_results.html.gz | 18:54 |
prometheanfire | from https://review.openstack.org/500770 | 18:54 |
*** ociuhandu has joined #openstack-nova | 18:54 | |
mriedem | prometheanfire: looking | 18:55 |
openstackgerrit | Michael Still proposed openstack/nova master: Move nbd commands to privsep. https://review.openstack.org/500351 | 18:56 |
openstackgerrit | Michael Still proposed openstack/nova master: Move lvm handling to privsep. https://review.openstack.org/495516 | 18:56 |
openstackgerrit | Michael Still proposed openstack/nova master: Move xend existence probes to privsep. https://review.openstack.org/495538 | 18:56 |
openstackgerrit | Michael Still proposed openstack/nova master: Move shred to privsep. https://review.openstack.org/495537 | 18:56 |
openstackgerrit | Michael Still proposed openstack/nova master: Cleanup mount / umount and associated rmdir calls https://review.openstack.org/494423 | 18:56 |
openstackgerrit | Michael Still proposed openstack/nova master: WIP / Aspirational: we don't need rootwrap any more. https://review.openstack.org/495542 | 18:56 |
openstackgerrit | Michael Still proposed openstack/nova master: Move loopback setup and removal to privsep. https://review.openstack.org/495664 | 18:56 |
openstackgerrit | Michael Still proposed openstack/nova master: Move libvirt usages of chown to privsep. https://review.openstack.org/471972 | 18:56 |
openstackgerrit | Michael Still proposed openstack/nova master: Don't shell out to mkdir, use ensure_tree() https://review.openstack.org/492326 | 18:56 |
openstackgerrit | Michael Still proposed openstack/nova master: Move the idmapshift binary into privsep. https://review.openstack.org/495541 | 18:56 |
openstackgerrit | Michael Still proposed openstack/nova master: Move ploop commands to privsep. https://review.openstack.org/492325 | 18:56 |
openstackgerrit | Michael Still proposed openstack/nova master: Read from console ptys using privsep. https://review.openstack.org/489486 | 18:56 |
openstackgerrit | Michael Still proposed openstack/nova master: Move kpartx calls to privsep. https://review.openstack.org/500354 | 18:56 |
openstackgerrit | Michael Still proposed openstack/nova master: Avoid chowning console logs in libvirt https://review.openstack.org/472229 | 18:56 |
openstackgerrit | Michael Still proposed openstack/nova master: First attempt at adding a privsep user to nova itself. https://review.openstack.org/459166 | 18:56 |
openstackgerrit | Michael Still proposed openstack/nova master: Move execs of touch to privsep. https://review.openstack.org/489190 | 18:56 |
prometheanfire | mriedem: that's a quick git-review you have there (or rebase maybe) | 18:56 |
openstackgerrit | Michael Still proposed openstack/nova master: Move libvirts dmcrypt support to privsep. https://review.openstack.org/490737 | 18:56 |
openstackgerrit | Michael Still proposed openstack/nova master: Move blkid calls to privsep. https://review.openstack.org/500398 | 18:56 |
openstackgerrit | Michael Still proposed openstack/nova master: Move execs of tee to privsep. https://review.openstack.org/489438 | 18:56 |
prometheanfire | bah, meant that for michael | 18:56 |
openstackgerrit | Merged openstack/nova master: Updated from global requirements https://review.openstack.org/500011 | 18:57 |
efried | prometheanfire git restack, yo. | 18:57 |
prometheanfire | what that come from? | 18:58 |
efried | It's a thing, hold on... | 18:58 |
*** ijw has quit IRC | 18:58 | |
*** penick has quit IRC | 18:58 | |
*** penick has joined #openstack-nova | 18:59 | |
efried | prometheanfire I think you install it with `pip install git-restack` | 18:59 |
*** thorst_afk has quit IRC | 18:59 | |
* prometheanfire is gonna see if that should be packaged or not | 18:59 | |
efried | It's a git plugin maintained by stackers | 18:59 |
*** thorst_afk has joined #openstack-nova | 18:59 | |
mriedem | prometheanfire: looks like this is the regression https://github.com/openstack/os-xenapi/commit/755876c19f7c47eaa773f835a68dcf93c3d6b50d | 19:00 |
efried | prometheanfire You say `git restack <commit-before-the-bottom-of-the-pile>`. Then you can choose to edit whichever ones in the chain via an edit file that looks kinda like when you rebase -i. It auto rebases everything in the pile. Then when you're done, you can `git review` and it pushes the whole pile (anything that has been changed, including rebases) | 19:01 |
prometheanfire | mriedem: k, so nova needs to update it's tests? | 19:01 |
prometheanfire | efried: I'll probably just stick to the classic rebase then | 19:02 |
mriedem | prometheanfire: not sure if it's that or if os-xenapi is regressed | 19:02 |
mriedem | i can start with reporting a bug | 19:03 |
prometheanfire | k | 19:03 |
prometheanfire | I'll hold that back for now then | 19:03 |
mriedem | thanks | 19:03 |
*** ociuhandu_ has joined #openstack-nova | 19:04 | |
*** yangyapeng has quit IRC | 19:04 | |
*** thorst_afk has quit IRC | 19:04 | |
*** ociuhandu has quit IRC | 19:05 | |
efried | jaypipes I'll have the same question about the "multiple resources, same class, different traits" syntax (in what state of maturity is this idea?) | 19:05 |
mriedem | prometheanfire: https://bugs.launchpad.net/nova/+bug/1715217 | 19:08 |
openstack | Launchpad bug 1715217 in OpenStack Compute (nova) "nova xenapi unit tests fail with os-xenapi 0.3.0" [Undecided,New] | 19:08 |
*** moshele has joined #openstack-nova | 19:08 | |
prometheanfire | thanks | 19:09 |
*** abhi89 has quit IRC | 19:09 | |
*** moshele has quit IRC | 19:10 | |
*** thorst_afk has joined #openstack-nova | 19:11 | |
*** gbarros has quit IRC | 19:12 | |
openstackgerrit | Jackie Truong proposed openstack/nova master: Add trusted_certs to instance_extra https://review.openstack.org/457711 | 19:13 |
*** priteau has quit IRC | 19:15 | |
*** thorst_afk has quit IRC | 19:15 | |
*** gbarros has joined #openstack-nova | 19:16 | |
artom | How are our man pages generated? Am I understanding correctly that https://review.openstack.org/#/c/475810/ has nothing to do with man pages? | 19:17 |
artom | stephenfin ^^, since you're the patch author :) | 19:17 |
*** gbarros has quit IRC | 19:18 | |
*** slaweq_ has joined #openstack-nova | 19:21 | |
*** rajathagasthya has joined #openstack-nova | 19:24 | |
mriedem | artom: https://github.com/openstack/nova/blob/master/doc/source/conf.py#L113 | 19:24 |
mriedem | part of the sphinx build | 19:24 |
mriedem | and yes https://review.openstack.org/#/c/475810/ has nothing to do with man pages | 19:24 |
artom | mriedem, and those all come from the doc/source/cli directory? | 19:24 |
mriedem | yeah | 19:25 |
*** gbarros has joined #openstack-nova | 19:25 | |
artom | Thanks :) | 19:25 |
mriedem | did i win? | 19:25 |
artom | My eternal indifference | 19:25 |
artom | (It's 2 steps up from seething hatred) | 19:26 |
*** thorst has joined #openstack-nova | 19:27 | |
*** gvrangan has quit IRC | 19:28 | |
*** tonygunk has joined #openstack-nova | 19:32 | |
*** cdent has quit IRC | 19:34 | |
*** slaweq_ has quit IRC | 19:34 | |
*** slaweq_ has joined #openstack-nova | 19:35 | |
*** itlinux has quit IRC | 19:35 | |
*** priteau has joined #openstack-nova | 19:37 | |
*** priteau has quit IRC | 19:41 | |
*** ijw has joined #openstack-nova | 19:45 | |
*** suresh12 has quit IRC | 19:47 | |
*** kristia__ has quit IRC | 19:48 | |
openstackgerrit | Lee Yarwood proposed openstack/nova-specs master: Libvirt: Native LUKS file and host device decryption by QEMU https://review.openstack.org/490824 | 19:49 |
*** suresh12 has joined #openstack-nova | 19:49 | |
*** esberglu has quit IRC | 19:50 | |
*** esberglu has joined #openstack-nova | 19:50 | |
*** egonzalez has joined #openstack-nova | 19:52 | |
jaypipes | efried: I don't know how to structure a request that would impart the required information for this query :( | 19:53 |
efried | jaypipes Well, shit, if YOU can't do it.... | 19:54 |
efried | Adding to list. | 19:54 |
jaypipes | efried: we would essentially need to replicate child-parent information in the request for resources. in other words, the requestor must know that a VF is a child of a PF is a child of a compute host. | 19:54 |
jaypipes | efried: and we can't ask the user to know that relationship... | 19:55 |
*** esberglu has quit IRC | 19:55 | |
efried | jaypipes But the alternative is making them separate resource classes. Which doesn't seem right at all. | 19:55 |
jaypipes | efried: no, that doesn't work either... | 19:55 |
jaypipes | efried: because their not separate resource classes. they're separate providers. | 19:56 |
jaypipes | efried: just imagine for a second how one might ask AWS for such a thing. | 19:56 |
* efried doesn't know from AWS | 19:56 | |
jaypipes | efried: you can't. | 19:56 |
efried | uhm | 19:57 |
jaypipes | efried: you need a more complicated DSL like CloudFormation or TOSCA | 19:57 |
efried | So how are we planning to model e.g. asking for more than one cinder volume? | 19:57 |
jaypipes | efried: and an orchestrator that would take one of those request templates and produce multiple requests to EC2 APIs. | 19:57 |
jaypipes | efried: we don't. that's the very reason why we've pushed back on having the compute API be an orchestration system. | 19:58 |
mriedem | prometheanfire: i think i've got these xenapi unit tests fixed | 19:58 |
mriedem | should have a patch up shortly | 19:58 |
prometheanfire | cool | 19:58 |
jaypipes | efried: you want >1 cinder volumes? then create them in cinder and attach them to your compute instance. | 19:58 |
*** suresh12 has quit IRC | 19:58 | |
prometheanfire | if that merges today then the xenapi change can go in tomorrow via bot update | 19:58 |
jaypipes | efried: there is absolutely no "atomically create 10 volumes in Cinder" command. | 19:59 |
*** tidwellr has left #openstack-nova | 19:59 | |
*** priteau has joined #openstack-nova | 19:59 | |
mriedem | there isn't?! | 19:59 |
jaypipes | efried: and these kinds of requests that the VNFM would be making are essentially that: requests for a set of related resources to be created as an atomic unit. | 19:59 |
efried | jaypipes Seems like there should be a way to specify multiple `resources=` keys in a single request, kind of thing. | 20:00 |
mriedem | how about i request 10 VMs with block_device_mapping_v2 in the request, of size 10, for each entry with different device names so nova creates the volumes! | 20:00 |
jaypipes | incidentally, this is why there's no atomicity guarantees that *any* orchestrator provides. not k8s, not heat, not IBM "smart" cloud orchestrator. not any of them. | 20:00 |
mriedem | does sco still exist? | 20:00 |
jaypipes | heh, no idea. | 20:00 |
smcginnis | mriedem: I hear they own the copyright to OpenStack. | 20:01 |
efried | only as a lawsuit troller | 20:01 |
*** yangyapeng has joined #openstack-nova | 20:01 | |
mriedem | they do have a snapshot api for vmware instances | 20:01 |
mriedem | which is different from os-createImage | 20:01 |
mriedem | different, and superior | 20:01 |
efried | Yeah, less concerned about atomicity at the moment. | 20:02 |
efried | I mean, what if I want two different GPUs with different specialties? | 20:02 |
efried | / capabilities | 20:03 |
mriedem | ask cyborg | 20:03 |
*** esberglu has joined #openstack-nova | 20:03 | |
efried | I don't know what that means | 20:03 |
mriedem | https://wiki.openstack.org/wiki/Cyborg | 20:04 |
mriedem | https://review.openstack.org/#/c/448228/ | 20:04 |
mriedem | jaypipes: is Roman Dobosz still around? | 20:04 |
mriedem | oh nvm | 20:05 |
mriedem | no | 20:05 |
*** ijw has quit IRC | 20:05 | |
jaypipes | mriedem: no | 20:05 |
mriedem | he was osic? | 20:05 |
jaypipes | no | 20:05 |
jaypipes | just got moved to a super-special-secret internal Intel project | 20:05 |
*** ijw has joined #openstack-nova | 20:05 | |
efried | Okay, so IIRC, it's legal in HTTP for a query param key to be repeated, and show up on the server side as a list of values. | 20:06 |
jaypipes | efried: show me an EC2, GCE, or Azure ability to request an instance that has multiple GPUs that are different. | 20:06 |
jaypipes | efried: yes. | 20:06 |
efried | What, because they can't do it, we shouldn't? | 20:06 |
efried | I mean, I'm at a clear disadvantage here, having no experience with any of those things. | 20:07 |
jaypipes | efried: no, because they can't do it is a pretty good indication that it's not something we should spend a shit-ton of time trying to do ;) | 20:07 |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Make xen unit tests work with os-xenapi>=0.3.0 https://review.openstack.org/500968 | 20:07 |
efried | What if it's not a shit-ton of time? | 20:07 |
jaypipes | efried: if it wasn't, you'd have done it already. | 20:07 |
*** esberglu has quit IRC | 20:07 | |
mriedem | prometheanfire: https://review.openstack.org/500968 | 20:08 |
efried | Mebbe I will. | 20:08 |
efried | But - okay - will put this down for now as "stated acceptable limitation". | 20:08 |
jaypipes | efried: all of these feature requests are basically for NFV use cases, anyway... which is hardware-defined software as I've said before. It's not cloud in as much as it's not abstraction. It's basically just automating the installation of \a very specific hardware environment. | 20:09 |
efried | jaypipes So can I have a VM on more than one network? | 20:10 |
jaypipes | efried: you can do that *now*... | 20:11 |
efried | jaypipes Right, but when everything's placement, how am I gonna say "give me one VF from physnet A and one VF from physnet B" ? | 20:11 |
jaypipes | efried: I don't know. | 20:12 |
openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Refactor encryptor attach and detach calls https://review.openstack.org/460243 | 20:12 |
jaypipes | efried: I've been staring at a pastebin for 2 hours trying to think of how to represent that request. | 20:12 |
efried | I mean, per earlier conversation with sean-k-mooney, I'll create one neutron port on each physnet and stuff 'em both into the spawn request; but somebody's gonna have to get both of those guys into placement somehow. | 20:12 |
*** Swami_ has joined #openstack-nova | 20:13 | |
*** Swami_ has quit IRC | 20:13 | |
jaypipes | efried: without inventing YET ANOTHER orchestration DSL ala Kubernetes pod templates, Heat templates, TOSCA, and CloudFormation. | 20:13 |
jaypipes | efried: which... oh wait! are orchestration frameworks, not compute infrastructure services. :) | 20:13 |
*** smatzek has quit IRC | 20:14 | |
*** efried is now known as efried_bbiab | 20:15 | |
*** abalutoiu has quit IRC | 20:15 | |
jaypipes | efried_bbiab, edleafe, dansmith: I'm getting close to saying "fuck it, let's add another placement REST endpoint called POST /crazypants that accepts a JSON blob representing the innumerable requests for related resources that an orchestrator has" | 20:18 |
mriedem | mmm JsonFilter | 20:18 |
mriedem | v2 | 20:18 |
dansmith | jaypipes: maybe we should finish several of the things we started with baseline gains before we freak out about not being able to request two different types of gpus | 20:20 |
openstackgerrit | Merged openstack/nova master: Add video type virtio for AArch64 https://review.openstack.org/493822 | 20:20 |
jaypipes | dansmith: that sounds like an excellent idea. | 20:21 |
openstackgerrit | Merged openstack/nova master: Add uuid to migration table https://review.openstack.org/496933 | 20:21 |
*** suresh12 has joined #openstack-nova | 20:22 | |
mriedem | dansmith: when is https://review.openstack.org/#/c/498510/ not a WPI? | 20:23 |
mriedem | *WIP | 20:23 |
mriedem | given patches are merging | 20:23 |
dansmith | mriedem: meant to remove it after the last round but ... didn't | 20:23 |
*** ijw has quit IRC | 20:24 | |
openstackgerrit | Dan Smith proposed openstack/nova-specs master: Add migration-allocations spec https://review.openstack.org/498510 | 20:24 |
dansmith | ther go | 20:24 |
*** ijw has joined #openstack-nova | 20:24 | |
*** cdent has joined #openstack-nova | 20:28 | |
openstackgerrit | Jackie Truong proposed openstack/nova master: Add trusted_certs to instance_extra https://review.openstack.org/457711 | 20:29 |
openstackgerrit | Chris Dent proposed openstack/nova master: WIP: [placement] POST /allocations to set allocations for >1 consumers https://review.openstack.org/500073 | 20:29 |
openstackgerrit | Chris Dent proposed openstack/nova master: Move project_id and user_id to Allocation object https://review.openstack.org/500410 | 20:29 |
*** tonygunk has quit IRC | 20:29 | |
openstackgerrit | Jackie Truong proposed openstack/nova master: Add trusted_certs to Instance object https://review.openstack.org/489408 | 20:31 |
*** marst has quit IRC | 20:33 | |
*** tbachman has quit IRC | 20:36 | |
melwitt | cdent: heh, I think we all noticed the issues with project_id/user_id on the List object at the time but nobody was sure we would need them per allocation yet | 20:36 |
*** artom has quit IRC | 20:36 | |
cdent | melwitt: tru | 20:36 |
openstackgerrit | melanie witt proposed openstack/nova-specs master: Convert consoles code to use objects framework https://review.openstack.org/500975 | 20:36 |
*** edmondsw has quit IRC | 20:36 | |
*** edmondsw has joined #openstack-nova | 20:37 | |
*** edmondsw has quit IRC | 20:42 | |
*** cleong has quit IRC | 20:42 | |
*** rcernin has joined #openstack-nova | 20:44 | |
*** pchavva has quit IRC | 20:45 | |
*** gbarros has quit IRC | 20:46 | |
*** shan7 has joined #openstack-nova | 20:46 | |
*** lucasxu has quit IRC | 20:48 | |
*** shan has quit IRC | 20:50 | |
*** efried_bbiab is now known as efried | 20:52 | |
efried | jaypipes Maybe different types of GPUs is crazypants, but somebody's gonna object to not being able to put a VM on more than one network. | 20:54 |
jaypipes | efried: again, you can already do that. | 20:54 |
efried | jaypipes With placement? | 20:54 |
efried | Maybe I misunderstood the previous conversation. But I thought that was exactly my point: you can do it today, but you won't be able to do it tomorrow. | 20:55 |
jaypipes | efried: no, not with placementy. | 20:55 |
jaypipes | efried: you can currently do it with the physnet tag hack in the pci_passthrough_whitelist thing. | 20:56 |
jaypipes | efried: and pre-creating Neutron ports with matching physnet tags | 20:56 |
jaypipes | efried: and passing those ports in to the Nova boot request | 20:57 |
*** slaweq_ has quit IRC | 20:57 | |
*** slaweq_ has joined #openstack-nova | 20:58 | |
efried | jaypipes Right. And I *thought* part of what we were trying to move toward is getting rid of the current PCI setup in favor of having device (incl. PCI) management revolving around placement. | 20:58 |
jaypipes | efried: what you're asking for here is combining the PCI device manager and PCIPassthroughFilter's behaviour of selecting a specific device based on arbitrary tags in the pci_device_request into the placement API. | 20:58 |
efried | jaypipes Well.... yes. | 20:58 |
*** tbachman has joined #openstack-nova | 20:59 | |
efried | I'm asking what's the answer to that ^ gonna be when we've gotten rid of the PCI device manager and moved to Placement nirvana. | 20:59 |
jaypipes | efried: I'd like to be storing structurally-correct data in the placement DB, yes. that means nested resource providers, support for traits, and linking the (generic) device manager with support for both setting traits and inventory on a tree of provider records. | 20:59 |
dansmith | efried: the people that want to attach multiple physical networks to vms are the same people that ultimately keep most of us employed you know | 21:00 |
jaypipes | efried: what I *don't* see a way to do -- again, without crazypants complex DSLs -- is a way to reproduce the PciPassthroughFilter and NUMATopologyFilters as REST API requests to placement | 21:00 |
dansmith | efried: I don't think we'll deprecate or remove legacy structures from nova before we have a way to replicate critical behavior like that using something else.. not sure where you got that idea | 21:00 |
jaypipes | efried: it's the "how do I request all these related things from the placement REST API" part that has me stumped, not the "please store this structured data in the placement DB" part. | 21:01 |
efried | jaypipes Right, I can see how to get the structure/inventory data into placement. | 21:02 |
*** Apoorva_ has joined #openstack-nova | 21:02 | |
jaypipes | efried: yes. we're both A-OK on that front. | 21:02 |
*** smatzek has joined #openstack-nova | 21:02 | |
efried | dansmith Sorry it came across that way; I misunderstood some stuff. | 21:03 |
jaypipes | efried: however, I still don't know a way to make a request of the placement API without essentially reproducing a domain-specific YAML/JSON language to deal with these complex topology requests. | 21:03 |
*** jheroux has quit IRC | 21:04 | |
*** eharney has quit IRC | 21:04 | |
efried | dansmith When jaypipes was venting about nova not being a cloud orchestration thingy, I thought he was saying being able to request multiple networks was a cloud orchestration thingy behavior, and that nova shouldn't be in that business. | 21:04 |
*** gouthamr has quit IRC | 21:05 | |
efried | ...Which may indeed be what he was saying - just not suggesting that that actually *happen* :) | 21:05 |
*** crushil has quit IRC | 21:05 | |
efried | jaypipes Right, so go with me on this "multiple instances of the `resources=` key" thing for a sec. | 21:05 |
*** Apoorva has quit IRC | 21:06 | |
dansmith | efried: I think what he was saying was that expecting nova to do lots of steps for you (i.e. determine and reserve multiple resources) as part of a single boot request is really getting into orchestration | 21:06 |
*** egonzalez has quit IRC | 21:06 | |
openstackgerrit | Brianna Poulos proposed openstack/nova master: Add trusted_certificates to REST API https://review.openstack.org/486204 | 21:07 |
efried | So I'm confused as to how VCPU+MEM_MB+DISK_GB isn't determining and reserving multiple resources. | 21:07 |
dansmith | efried: are you just being sarcastic and difficult now? | 21:07 |
dansmith | obviously that's not | 21:07 |
*** penick has quit IRC | 21:07 | |
efried | No, dansmith, I'm actually this obtuse I'm afraid. Mostly from lack of experience (and a disproportionate lack of inhibition to speak up and ask questions). | 21:08 |
efried | But again, apologies, I think I understand what you mean now. | 21:08 |
efried | when you said "multiple resources" | 21:08 |
efried | you meant "multiple disparate resources of the same class". | 21:09 |
efried | mahbad. | 21:09 |
jaypipes | efried: hold up... I just thought of something... gimme a minute to flesh it out in my brain. | 21:09 |
efried | btw jaypipes I realized as I started typing it why the 'multiple querystring keys' thing is a nonstarter if traits is its own qs key... | 21:09 |
dansmith | efried: I mean things like nova going to cinder to create, image, and attach a volume, and to neutron to create multiple ports for a complex network layout, and then to some other service to arrange for party balloons to be sent in ten minutes, and then, finally, to boot the instance | 21:10 |
efried | dansmith Rightright. And I think again the reason I'm confused as to why we wouldn't want that is because that (at least the neutron & cinder stuff) is part and parcel of what nova does today, and therefore what I think of as being in nova's purview. | 21:11 |
efried | and if we're not taking away at least the neutron &/| cinder stuff, then presumably there's going to have to be an answer for it in the placement world. | 21:12 |
efried | which solution, if we're gonna solve it for neutron & cinder, would seem like it oughtta work for whatever. | 21:12 |
efried | although I'm *not* suggesting it should go talk to just any external service. | 21:13 |
*** harlowja has quit IRC | 21:13 | |
*** itlinux has joined #openstack-nova | 21:13 | |
dansmith | I don't follow | 21:14 |
efried | In the case of neutron, the model we have today for VFs is that you create your ports in neutron and then some gizmo in nova knows to associate that with the physnet tags from the [pci]passthrough_whitelist (which is one of jaypipes's bugbears) | 21:14 |
dansmith | we're not talking about getting rid of neutron or our talking to it, but just not trying to build requests for complex things into nova's API, IMHO | 21:15 |
dansmith | I think I've lost track of why this is coming up in the context of placement | 21:15 |
*** edmondsw has joined #openstack-nova | 21:16 | |
jaypipes | I'm still pastebinning. :) | 21:17 |
efried | dansmith Well, the premise - which I *think* started with jaypipes (see comments here https://review.openstack.org/#/c/497965/) - is that we want to phase out the PCI device management gorp that's been frankensteined over the years. | 21:17 |
*** ijw has quit IRC | 21:17 | |
jaypipes | guys, can I hit pause on this conversation for 5 minutes so I can finish my braindump? | 21:17 |
*** tbachman has quit IRC | 21:17 | |
efried | ...with some kind of "generic device manager" which talks to Placement | 21:17 |
efried | sure. | 21:17 |
*** thorst has quit IRC | 21:18 | |
dansmith | efried: definitely, to the extent we can | 21:19 |
*** smatzek has quit IRC | 21:19 | |
openstackgerrit | Dan Smith proposed openstack/nova-specs master: Add migration-allocations spec https://review.openstack.org/498510 | 21:20 |
*** shan7 has quit IRC | 21:24 | |
*** thorst has joined #openstack-nova | 21:37 | |
*** thorst has quit IRC | 21:42 | |
*** catintheroof has quit IRC | 21:43 | |
*** crushil has joined #openstack-nova | 21:43 | |
*** kbaegis has joined #openstack-nova | 21:46 | |
*** suresh12 has quit IRC | 21:48 | |
*** kbaegis has quit IRC | 21:52 | |
*** rcernin has quit IRC | 21:53 | |
*** slaweq_ has quit IRC | 21:57 | |
cfriesen__ | when calling a remotable object function, does nova-conductor do a keystone token validation? | 21:59 |
dansmith | no | 22:01 |
*** thorst has joined #openstack-nova | 22:07 | |
*** thorst has quit IRC | 22:10 | |
*** burt has quit IRC | 22:10 | |
*** annegentle has quit IRC | 22:10 | |
*** annegentle has joined #openstack-nova | 22:11 | |
*** ijw has joined #openstack-nova | 22:13 | |
*** priteau has quit IRC | 22:15 | |
*** annegentle has quit IRC | 22:16 | |
*** ijw has quit IRC | 22:21 | |
openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Spec for flavor description https://review.openstack.org/501017 | 22:21 |
mriedem | Kevin_Zheng: ^ | 22:21 |
*** felipemonteiro_ has quit IRC | 22:22 | |
*** tidwellr has joined #openstack-nova | 22:23 | |
jaypipes | efried, dansmith: sorry, dinner got in the way.. | 22:23 |
jaypipes | efried, dansmith: dumped some thoughts here: http://paste.openstack.org/show/620456/ | 22:23 |
efried | jaypipes ... | 22:24 |
jaypipes | efried: yes? | 22:25 |
efried | jaypipes Sorry, that's "Message received, processing..." | 22:26 |
jaypipes | efried: ack | 22:26 |
*** sdague has quit IRC | 22:26 | |
*** lyan has quit IRC | 22:27 | |
*** tidwellr has quit IRC | 22:27 | |
efried | jaypipes Yes, just so. But I thought this was the part we were all in sync with. The part we hadn't yet come to grips with was the hand-waving on L35-6. | 22:29 |
*** baoli has quit IRC | 22:30 | |
jaypipes | efried: no, I can come up with an *internal* representation for the request. what I can't figure out is how to map that to a *single* REST API call. | 22:30 |
efried | Right. | 22:30 |
efried | jaypipes Don't kill me don't kill me but... what if I numbered the query param keys? | 22:31 |
efried | resources1=...&traits1=...&resources2=...&traits2=... | 22:32 |
jaypipes | efried: uhm, eww? :) | 22:32 |
efried | Well, yeah it's eww, that's a given. But it's clear that it could work. | 22:32 |
efried | It could also conceivably answer the thing where it matters what order we attach devices in... | 22:33 |
efried | ...which some people care about. | 22:33 |
jaypipes | efried: not sure I follow why the attachment order matters to the placement API. | 22:33 |
efried | It doesn't, but when the request comes in, don't those keys come through? Mebbe not, sorry. | 22:33 |
efried | Anyway, for the general case, non-numbered querystring keys work just fine; in fact they don't even have to be numbers - we just parse the prefix and group by the suffix, whatever it is. | 22:35 |
jaypipes | efried: the problem with adding this to the placement REST API is that then we're adding a bunch of orchestration-like logic into the placement service. | 22:36 |
jaypipes | efried: instead of keeping that out of placement and relying on the caller to placement understanding that the request contains a number of "subrequests" that are for specific complex types. | 22:36 |
efried | jaypipes Yeah, I admit I don't understand what is meant by "orchestration" and where that line is drawn. | 22:37 |
jaypipes | efried: dealing with lots of resources as a group is orchestration. | 22:37 |
jaypipes | efried: where the relationship between the resources, the dependencies between them, the constraints that each imposes on each other, etc. that's orchestration. | 22:38 |
jaypipes | efried: whereas placement is designed to be a fast, efficient method of determining providers of resources for a given simple request for capacity. | 22:38 |
*** tbachman has joined #openstack-nova | 22:40 | |
cdent | jaypipes: can you clarify something for me: I’m not fully grokking why, in your paste, we need to make multiple requests to /a_c ? Is it is because at the point we don’t have a good way to express (in one request) what we want or is there more than that? | 22:41 |
efried | jaypipes I'm probably being obtuse again, but I still don't really see how what we're talking about here doesn't still fall into that description. Placement is designed to grab resources from multiple resource providers. From a way-zoomed-out view, saying "you can only get stuff from a given resource class from a single provider" seems like an arbitrary limitation. Zoom back in, and it's one that seems imposed because we | 22:42 |
efried | 're having trouble expressing it under the current design, not because it inherently crosses the line to "orchestration". | 22:42 |
cdent | jaypipes: on line 50 it is GROUP_A on the first go round and GROUP_B on the second? | 22:42 |
*** claudiub|2 has quit IRC | 22:43 | |
efried | cdent Yeah; and/or L49 could be different egress bandwidth numbers | 22:43 |
cdent | thanks | 22:43 |
jaypipes | cdent: a couple reasons for that. the first is that it's difficult for me to map the concept of related sub-requests in a single REST API call (again, without resorting to some DSL-ish request payload) and b) because I suspect these types of use cases are just the tip of the iceberg and that the logic that relates various things with each other (GPUs, FPGAs, NIC HA groups, etc) will be different and not possible to cleanly express with simple | 22:44 |
jaypipes | query parameters. | 22:44 |
* cdent nods | 22:44 | |
jaypipes | cdent: and yes, it would be GROUP_A on the first go around and GROUP_B on the second. | 22:44 |
cdent | jaypipes: next question: step 4 sounds like a pretty big step backwards for the goals we originally expressed for allocation_candidates | 22:45 |
jaypipes | cdent: could also have different amounts of egress bandwidth, different affinity policies, different all sorts of things, frnakly | 22:45 |
jaypipes | cdent: Yupppp! | 22:45 |
cdent | why can’t we have a complete allocation_requests (just to be explicit) | 22:45 |
*** Apoorva_ has quit IRC | 22:45 | |
jaypipes | cdent: it removes the whole opaqueness aspect of the allocation request :() | 22:45 |
cdent | yes much :( | 22:45 |
efried | Is it because the allocation request is keyed by resource class? | 22:46 |
efried | (haven't looked at that guy yet) | 22:46 |
*** Apoorva has joined #openstack-nova | 22:46 | |
jaypipes | cdent: we can't have a complete allocation_requests unless placement is passed all of the logic about relationship between sub-resources | 22:46 |
cdent | I thought that’s what nested was providing us? | 22:47 |
jaypipes | efried: the allocation request is not keyed by resource class, no. | 22:47 |
jaypipes | efried: the allocation request is essentially the request payload to PUT /allocations/{consumer_uuid} | 22:47 |
openstackgerrit | Michael Still proposed openstack/nova master: Add release note for requiring shred 8.22 or above. https://review.openstack.org/501022 | 22:47 |
*** edmondsw has quit IRC | 22:47 | |
cdent | jaypipes: related, have you yet seen: http://lists.openstack.org/pipermail/openstack-dev/2017-September/121824.html from avolkov ? | 22:48 |
efried | jaypipes And it must be able to contain resources from different RPs. So why would there be a limitation that RCs therein be unique? | 22:48 |
efried | cdent That's what started this whole thing :) | 22:48 |
*** edmondsw has joined #openstack-nova | 22:48 | |
cdent | ah, good | 22:48 |
efried | cdent Back around http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-09-05.log.html#t2017-09-05T15:37:39 | 22:48 |
cdent | presumably the response to option 2 is “no” | 22:49 |
cdent | as that’s not "real" | 22:49 |
jaypipes | cdent: nested resource providers allows the placement API to understand whether, say, a PF that provides some VFs is on a particular compute node. Nested providers doesn't, however, solve the problem of how do we model the *request* for resources when the user doesn't know that there is a nested relationship between things. | 22:49 |
jaypipes | efried: there is no such limitation. I'm not sure what you're getting at. | 22:49 |
mikal | mriedem: I am a bad man and realized once that shred patch had merged that it probably should have had a reno, so I've added one in https://review.openstack.org/#/c/501022/ | 22:50 |
*** esberglu has joined #openstack-nova | 22:50 | |
efried | jaypipes What you and cdent were saying about breaking opaqueness? And a step backwards for original goals of allocation_candidates. I didn't catch where that came from. | 22:51 |
cdent | jaypipes: I get that the request modeling is a limitation, but if were to set that aside for a moment and we could express the request well then the we could present a complete set of allocations in response, right? The limitation as described in your paste is because the current request doesn’t have all the state. | 22:51 |
cdent | efried: ideally it would be possible to take the first item in the allocation_request list and send that to /allocations/{consumer_uuid} without modifications to make a “claim” | 22:52 |
efried | cdent Why doesn't that still work in this scenario? | 22:52 |
jaypipes | efried: the items in the "allocation_requests" part of the HTTP response for the GET /allocation_candidates placement API call is intended to be able to pass as-is (i.e. opaquely without the caller needing to know the structure of the HTTP payload) to the PUT /allocations/{consumer_uuid} call.' | 22:52 |
*** edmondsw has quit IRC | 22:52 | |
cdent | but if you’ve used multple requests to construct the set of rps, we don’t have enough info to construction all the pieces of the allocation | 22:52 |
jaypipes | cdent: correct. | 22:53 |
cdent | feh | 22:53 |
efried | Okay, I don't understand that, but I'm sure it's because I haven't read everything yet. | 22:53 |
cdent | efried: if you haven’t got it after some cogitation, ask me again a bit later and I can try to explain it using different words | 22:54 |
cdent | we’re making some shortcuts in our explanations that aren’t really helping matters | 22:54 |
jaypipes | cdent: thus my earlier comment that "fuck it..." we will probably end up needing yet another REST API call to placement that takes as a payload some crazypants HOT template|TOSCA YAML|CloudFormation template thing that describes all the various components of the instance that the user wants Nova to atomically claim and spawn. | 22:54 |
efried | cdent Thanks - I don't think it's words; it's background. | 22:54 |
*** esberglu has quit IRC | 22:55 | |
cdent | jaypipes: i believe that’s where I feel like borrowing dansmith’s gun | 22:55 |
jaypipes | cdent: yup. and the reason I keep bringing up that I hate Nova being an orchestrator. | 22:55 |
dansmith | cdent: what kind you want? semi-auto? large bore? hollow points? | 22:55 |
*** itlinux has quit IRC | 22:55 | |
* dansmith opens his trenchcoat | 22:56 | |
cdent | dansmith: I’m away for home, so would feel bad for making a mess | 22:56 |
cdent | from | 22:56 |
efried | Every time this happens, though, I go away and study some more, and next time I come back and read the eavesdrop or whatever, I actually get it. I'm hoping to be good enough by the PTG not to get lost when this stuff is being discussed live. | 22:56 |
dansmith | cdent: okay so hollow-points then | 22:56 |
jaypipes | dansmith: shotty. it's got a "good spread". | 22:56 |
jaypipes | efried: no worries, man. these conversations are important to have. | 22:56 |
cfriesen__ | .700 nitro express | 22:56 |
*** cfriesen__ is now known as cfriesen | 22:56 | |
openstackgerrit | Dan Smith proposed openstack/nova master: Split out the core of the ironic flavor migration https://review.openstack.org/501024 | 22:56 |
openstackgerrit | Dan Smith proposed openstack/nova master: Add nova-manage db command for ironic flavor migrations https://review.openstack.org/501025 | 22:56 |
dansmith | mriedem: dtantsur|afk ^ | 22:57 |
jaypipes | efried: as much as they just inevitably end up reinforcing my annoyance with orchestration. | 22:57 |
dansmith | needs a reno but I'm out of brain power and the smoke is cutting my oxygen supply | 22:57 |
efried | cdent jaypipes So what we're talking about here is that we made an architectural call to be able to take a chunk of the placement response and just blat it into a (single) allocation request; but if we've made multiple calls to placement we'll have multiple such chunks, and there's currently no semantic for "combining" them into a single allocation request. | 22:57 |
efried | Did I get that right? | 22:58 |
cdent | jaypipes: sadly, somewhere is going to have to have a model for that tosca thing for an instance doign nested rp stuff and it is going to need to land on a compute (so the instance can build correctly). we planned ourselves into this corner, is just the way the world is for now :( | 22:59 |
cdent | efried: yes, pretty much. we’d need to build that “reassembler” in the scheduler and in a perfect world wouldn’t have to | 22:59 |
efried | In practical terms, the "opaque" allocation request is just a list of things, and we would just append those lists together and be fine. We just didn't wanna have to do that. | 23:00 |
cdent | we now need to be smart in at least two spots | 23:00 |
cdent | efried: not exactly. | 23:00 |
cdent | If we are lisp coders and are talking about this problem, then yes, we building lists | 23:01 |
cdent | but the selection of pieces is not just reassambling a sequence | 23:01 |
efried | jaypipes cdent I gotta run. FYI, I've been assembling notes which I eventually planned to link off of the main PTG etherpad once they were in a state where they were sanely readable by someone other than me. I'm not sure if we've reached that point yet, but... https://etherpad.openstack.org/p/nova-ptg-queens-generic-device-management | 23:03 |
cdent | thanks for doing that efried, you want annotations in the realm of “nowish” or “laterish”? | 23:04 |
efried | cdent I guess any-time-ish is fine, thanks. I didn't think I was done with it for sure, but I believe I've at least removed most of my horribly-misinformed early thoughts/ideas. | 23:06 |
cdent | ✔ | 23:06 |
efried | Thanks as always for talking through this with me jaypipes cdent dansmith sean-k-mooney | 23:07 |
*** efried is now known as efried_zzz | 23:07 | |
jaypipes | ciao | 23:09 |
*** thorst has joined #openstack-nova | 23:11 | |
*** hongbin has quit IRC | 23:12 | |
*** kairo_ has joined #openstack-nova | 23:13 | |
*** kairo has quit IRC | 23:15 | |
*** thorst has quit IRC | 23:16 | |
*** gouthamr has joined #openstack-nova | 23:16 | |
*** hongbin has joined #openstack-nova | 23:21 | |
*** thorst has joined #openstack-nova | 23:21 | |
*** hongbin has quit IRC | 23:22 | |
*** thorst has quit IRC | 23:25 | |
*** catintheroof has joined #openstack-nova | 23:26 | |
gmann | mriedem, +1, i overlooked | 23:28 |
gmann | mriedem, can we have a specless BP for index schema chages - https://review.openstack.org/#/c/500347/ https://review.openstack.org/#/c/499091/ etc | 23:30 |
gmann | mriedem, that will be basically continuation of this - https://blueprints.launchpad.net/nova/+spec/consistent-query-parameters-validation | 23:30 |
gmann | it will be easy to track and capture any accidental API changes | 23:30 |
*** catintheroof has quit IRC | 23:31 | |
gmann | mriedem, created one, check if it looks fine - https://blueprints.launchpad.net/nova/+spec/json-schema-validation-for-index-query-param | 23:37 |
gmann | alex_xu, ^^ | 23:37 |
alex_xu | gmann: thanks, that's great | 23:39 |
*** kairo_ has quit IRC | 23:40 | |
*** markvoelker has quit IRC | 23:43 | |
*** kairo has joined #openstack-nova | 23:44 | |
*** crushil has quit IRC | 23:46 | |
openstackgerrit | Chris Dent proposed openstack/nova-specs master: Add a spec for POST /allocations in placement https://review.openstack.org/499259 | 23:47 |
*** suresh12 has joined #openstack-nova | 23:48 | |
openstackgerrit | Dan Smith proposed openstack/nova master: Add nova-manage db command for ironic flavor migrations https://review.openstack.org/501025 | 23:50 |
openstackgerrit | Merged openstack/nova master: Add recreate test for forced host evacuate not setting dest allocations https://review.openstack.org/499678 | 23:51 |
*** crushil has joined #openstack-nova | 23:52 | |
*** artom has joined #openstack-nova | 23:56 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!