Mailing List Archive

[nova] StarlingX diff analysis
In case you haven't heard, there was this StarlingX thing announced at
the last summit. I have gone through the enormous nova diff in their
repo and the results are in a spreadsheet [1]. Given the enormous
spreadsheet (see a pattern?), I have further refined that into a set of
high-level charts [2].

I suspect there might be some negative reactions to even doing this type
of analysis lest it might seem like promoting throwing a huge pile of
code over the wall and expecting the OpenStack (or more specifically the
nova) community to pick it up. That's not my intention at all, nor do I
expect nova maintainers to be responsible for upstreaming any of this.

This is all educational to figure out what the major differences and
overlaps are and what could be constructively upstreamed from the
starlingx staging repo since it's not all NFV and Edge dragons in here,
there are some legitimate bug fixes and good ideas. I'm sharing it
because I want to feel like my time spent on this in the last week
wasn't all for nothing.

[1]
https://docs.google.com/spreadsheets/d/1ugp1FVWMsu4x3KgrmPf7HGX8Mh1n80v-KVzweSDZunU/edit?usp=sharing
[2]
https://docs.google.com/presentation/d/1P-__JnxCFUbSVlEoPX26Jz6VaOyNg-jZbBsmmKA2f0c/edit?usp=sharing

--

Thanks,

Matt

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [nova] StarlingX diff analysis [ In reply to ]
Hi matt, everyone,

I just read your analysis and would like to thank you for such work. I
really think there are numerous features included/used on this Nova rework
that would be highly beneficial for Nova and users of it.

I hope people will fairly appreciate you work.

I didn’t had time to check StarlingX code quality, how did you feel it
while you were doing your analysis?

Thanks a lot for this share.
I’ll have a closer look at it this afternoon as my company may be
interested by some features.

Kind regards,
G.
Le mar. 7 août 2018 à 00:03, Matt Riedemann <mriedemos@gmail.com> a écrit :

> In case you haven't heard, there was this StarlingX thing announced at
> the last summit. I have gone through the enormous nova diff in their
> repo and the results are in a spreadsheet [1]. Given the enormous
> spreadsheet (see a pattern?), I have further refined that into a set of
> high-level charts [2].
>
> I suspect there might be some negative reactions to even doing this type
> of analysis lest it might seem like promoting throwing a huge pile of
> code over the wall and expecting the OpenStack (or more specifically the
> nova) community to pick it up. That's not my intention at all, nor do I
> expect nova maintainers to be responsible for upstreaming any of this.
>
> This is all educational to figure out what the major differences and
> overlaps are and what could be constructively upstreamed from the
> starlingx staging repo since it's not all NFV and Edge dragons in here,
> there are some legitimate bug fixes and good ideas. I'm sharing it
> because I want to feel like my time spent on this in the last week
> wasn't all for nothing.
>
> [1]
>
> https://docs.google.com/spreadsheets/d/1ugp1FVWMsu4x3KgrmPf7HGX8Mh1n80v-KVzweSDZunU/edit?usp=sharing
> [2]
>
> https://docs.google.com/presentation/d/1P-__JnxCFUbSVlEoPX26Jz6VaOyNg-jZbBsmmKA2f0c/edit?usp=sharing
>
> --
>
> Thanks,
>
> Matt
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
Re: [nova] StarlingX diff analysis [ In reply to ]
On 8/7/2018 1:10 AM, Flint WALRUS wrote:
> I didn’t had time to check StarlingX code quality, how did you feel it
> while you were doing your analysis?

I didn't dig into the test diffs themselves, but it was my impression
that from what I was poking around in the local git repo, there were
several changes which didn't have any test coverage.

For the really big full stack changes (L3 CAT, CPU scaling and
shared/pinned CPUs on same host), toward the end I just started glossing
over a lot of that because it's so much code in so many places, so I
can't really speak very well to how it was written or how well it is
tested (maybe WindRiver had a more robust CI system running integration
tests, I don't know).

There were also some things which would have been caught in code review
upstream. For example, they ignore the "force" parameter for live
migration so that live migration requests always go through the
scheduler. However, the "force" parameter is only on newer
microversions. Before that, if you specified a host at all it would
bypass the scheduler, but the change didn't take that into account, so
they still have gaps in some of the things they were trying to
essentially disable in the API.

On the whole I think the quality is OK. It's not really possible to
accurately judge that when looking at a single diff this large.

--

Thanks,

Matt

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators