[tc] [ironic] Promoting ironic to a top-level opendev project?
Hi everyone! This topic should not come as a huge surprise for many, since it has been raised numerous times in the past years. I have a feeling that the end of Ussuri, now that we’ve re-acquired our PTL and are on the verge of selecting new TC members, may be a good time to propose it for a formal discussion. TL;DR I’m proposing to make Ironic a top-level project under opendev.org and the OpenStack Foundation, following the same model as Zuul. I don’t propose severing current relationships with other OpenStack projects, nor making substantial changes in how the project is operated. (And no, it’s not an April 1st joke) Background ========= Ironic was born as a Nova plugin, but has grown way beyond this single case since then. The first commit in Bifrost dates to February 2015. During these 5 years (hey, we forgot to celebrate!) it has developed into a commonly used data center management tool - and still based on standalone Ironic! The Metal3 project uses standalone Ironic as its hardware management backend. We haven’t been “just” a component of OpenStack for a while now, I think it’s time to officially recognize it. And before you ask: in no case do I suggest scaling down our invaluable integration with Nova. We’re observing a solid growth of deployments using Ironic as an addition to their OpenStack clouds, and this proposal doesn’t try to devalue this use case. The intention is to accept publicly and officially that it’s not the only or the main use case, but one of the main use cases. I don’t think it comes as a surprise to the Nova team. Okay, so why? =========== The first and the main reason is the ambiguity in our positioning. We do see prospective operators and users confused by the perception that Ironic is a part of OpenStack, especially when it comes to the standalone use case. “But what if I don’t need OpenStack” is a question that I hear in most of these conversations. Changing from “a part of OpenStack” to “a FOSS tool that can integrate with OpenStack” is critical for our project to keep growing into new fields. To me personally it feels in line with how OpenDev itself is reaching into new areas beyond just the traditional IaaS. The next OpenDev even will apparently have a bare metal management track, so why not a top-level project for it? Another reason is release cadence. We have repeatedly expressed the desire to release Ironic and its sub-projects more often than we do now. Granted, *technically* we can release often even now. We can even abandon the current release model and switch to “independent”, but it doesn’t entirely solve the issue at hand. First, we don’t want to lose the notion of stable branches. One way or another, we need to support consumers with bug fix releases. Second, to become truly “independent” we’ll need to remove any tight coupling with any projects that do integrated releases. Which is, essentially, what I’m proposing here. Finally, I believe that our independence (can I call it “Irexit” please?) has already happened in reality, we just shy away from recognizing it. Look: 1. All integration points with other OpenStack projects are optional. 2. We can work fully standalone and even provide a project for that. 3. Many new features (RAID, BIOS to name a few) are exposed to standalone users much earlier than to those going through Nova. 4. We even have our own mini-scheduler (although its intention is not and has not been to replace the Placement service). 5. We make releases more often than the “core” OpenStack projects (but see above). What we will do ============ This proposal involves in the short term: * Creating a new git namespace: opendev.org/ironic * Creating a new website (name TBD, bare metal puns are welcome). * If we can have https://docs.opendev.org/ironic/, it may be just fine though. * Keeping the same governance model, only adjusted to the necessary extent. * Keeping the same policies (reviews, CI, stable). * Defining a new release cadence and stable branch support schedule. In the long term we will consider (not necessary do): * Reshaping our CI to rely less on devstack and grenade (only use them for jobs involving OpenStack). * Reducing or removing reliance on oslo libraries. * Stopping using rabbitmq for messaging (we’ve already made it optional). * Integrating with non-OpenStack services (kubernetes?) and providing lighter alternatives (think, built-in authentication). What we will NOT do ================ At least this proposal does NOT involve: * Stopping maintaining the Ironic virt driver in Nova. * Stopping running voting CI jobs with OpenStack services. * Dropping optional integration with OpenStack services. * Leaving OpenDev completely. What do you think? =============== Please let us know what you think about this proposal. Any hints on how to proceed with it, in case we reach a consensus, are also welcome. Cheers, Dmitry
tl;dr <3 - more words below. On Wed, Apr 1, 2020 at 10:05 AM Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi everyone!
This topic should not come as a huge surprise for many, since it has been raised numerous times in the past years. I have a feeling that the end of Ussuri, now that we’ve re-acquired our PTL and are on the verge of selecting new TC members, may be a good time to propose it for a formal discussion.
TL;DR I’m proposing to make Ironic a top-level project under opendev.org and the OpenStack Foundation, following the same model as Zuul. I don’t propose severing current relationships with other OpenStack projects, nor making substantial changes in how the project is operated.
Thank you for bringing this up Dmitry. I know the cores have discussed this a couple times over the past two years in various settings and forums, and I think you make a solid case.
(And no, it’s not an April 1st joke)
Background =========
Ironic was born as a Nova plugin, but has grown way beyond this single case since then. The first commit in Bifrost dates to February 2015. During these 5 years (hey, we forgot to celebrate!) it has developed into a commonly used data center management tool - and still based on standalone Ironic! The Metal3 project uses standalone Ironic as its hardware management backend. We haven’t been “just” a component of OpenStack for a while now, I think it’s time to officially recognize it.
+2
And before you ask: in no case do I suggest scaling down our invaluable integration with Nova. We’re observing a solid growth of deployments using Ironic as an addition to their OpenStack clouds, and this proposal doesn’t try to devalue this use case. The intention is to accept publicly and officially that it’s not the only or the main use case, but one of the main use cases. I don’t think it comes as a surprise to the Nova team.
Okay, so why? ===========
The first and the main reason is the ambiguity in our positioning. We do see prospective operators and users confused by the perception that Ironic is a part of OpenStack, especially when it comes to the standalone use case. “But what if I don’t need OpenStack” is a question that I hear in most of these conversations. Changing from “a part of OpenStack” to “a FOSS tool that can integrate with OpenStack” is critical for our project to keep growing into new fields. To me personally it feels in line with how OpenDev itself is reaching into new areas beyond just the traditional IaaS. The next OpenDev even will apparently have a bare metal management track, so why not a top-level project for it?
I can second this perception issue that we encounter a lot. People assume because we're part of the community that everything else is required when it is not. This is possibly the #1 barrier to accepting Ironic or even parts of ironic's ecosystem to help solve problems.
Another reason is release cadence. We have repeatedly expressed the desire to release Ironic and its sub-projects more often than we do now. Granted, *technically* we can release often even now. We can even abandon the current release model and switch to “independent”, but it doesn’t entirely solve the issue at hand. First, we don’t want to lose the notion of stable branches. One way or another, we need to support consumers with bug fix releases. Second, to become truly “independent” we’ll need to remove any tight coupling with any projects that do integrated releases. Which is, essentially, what I’m proposing here.
I agree, and I suspect this is going to be perceived as the most "scary" part of this. Ideally we want and need consumers like Metal3 to be able to pickup latest releases and latest stable branches, and we want to be able to fix major issues in past branches. While I know I've obtained agreement that we should have more ad-hoc freedom from the TC, at least verbally, it only takes a single -1 to prevent the ironic project from doing what is right for its consumers.
Finally, I believe that our independence (can I call it “Irexit” please?) has already happened in reality, we just shy away from recognizing it. Look: 1. All integration points with other OpenStack projects are optional. 2. We can work fully standalone and even provide a project for that. 3. Many new features (RAID, BIOS to name a few) are exposed to standalone users much earlier than to those going through Nova. 4. We even have our own mini-scheduler (although its intention is not and has not been to replace the Placement service). 5. We make releases more often than the “core” OpenStack projects (but see above).
This is possibly the best point I've heard on this case to date. Your right, it basically has already happened and I think the resistance to change that is only human causes us to be shy about it.
What we will do ============
This proposal involves in the short term: * Creating a new git namespace: opendev.org/ironic * Creating a new website (name TBD, bare metal puns are welcome). * If we can have https://docs.opendev.org/ironic/, it may be just fine though. * Keeping the same governance model, only adjusted to the necessary extent.
I don't think we would need anything super expansive. In a sense, we're a bit of a rag-tag fugitive fleet, so we need to accept that as part of any model _AND_ recognize that most of us have numerous responsibilities, so things take time and don't necessarily ever fit to a perfect time table.
* Keeping the same policies (reviews, CI, stable). * Defining a new release cadence and stable branch support schedule.
I suspect this means we should also consider our own mailing list at some point, and maybe renaming the IRC channel?
In the long term we will consider (not necessary do): * Reshaping our CI to rely less on devstack and grenade (only use them for jobs involving OpenStack). * Reducing or removing reliance on oslo libraries. * Stopping using rabbitmq for messaging (we’ve already made it optional). * Integrating with non-OpenStack services (kubernetes?) and providing lighter alternatives (think, built-in authentication).
+1000
What we will NOT do ================
At least this proposal does NOT involve: * Stopping maintaining the Ironic virt driver in Nova. * Stopping running voting CI jobs with OpenStack services. * Dropping optional integration with OpenStack services. * Leaving OpenDev completely.
What do you think? ===============
Please let us know what you think about this proposal. Any hints on how to proceed with it, in case we reach a consensus, are also welcome.
Cheers, Dmitry
I completely agree with this, and while I've wondered about this for some time, I think now is the right time to proceed. Again, thank you Dmitry for bringing this up!
On Wed, Apr 1, 2020 at 1:06 PM Dmitry Tantsur <dtantsur@redhat.com> wrote:
Finally, I believe that our independence (can I call it “Irexit” please?) given the political overtones and baggage related to Irexit https://en.wikipedia.org/wiki/Irish_Freedom_Party i would avoid that like the plague both in real life and in this proposal unless you want to advocate for alt-right, populist, xenophobe polictical movement
On Wed, 2020-04-01 at 14:32 -0400, Artom Lifshitz wrote: that will piss off most irish people.
No, but I will accept "smelting" or "oxidation" ;)
On Wed, Apr 1, 2020 at 11:25 PM Sean Mooney <smooney@redhat.com> wrote:
On Wed, Apr 1, 2020 at 1:06 PM Dmitry Tantsur <dtantsur@redhat.com> wrote:
Finally, I believe that our independence (can I call it “Irexit”
On Wed, 2020-04-01 at 14:32 -0400, Artom Lifshitz wrote: please?) given the political overtones and baggage related to Irexit https://en.wikipedia.org/wiki/Irish_Freedom_Party i would avoid that like the plague both in real life and in this proposal unless you want to advocate for alt-right, populist, xenophobe polictical movement that will piss off most irish people.
Ugh, please accept my apologies, I did not realize there was something under this name already. No offense intended for anyone. Dmitry
No, but I will accept "smelting" or "oxidation" ;)
On Thu, 2020-04-02 at 09:51 +0200, Dmitry Tantsur wrote:
On Wed, Apr 1, 2020 at 11:25 PM Sean Mooney <smooney@redhat.com> wrote:
On Wed, 2020-04-01 at 14:32 -0400, Artom Lifshitz wrote:
On Wed, Apr 1, 2020 at 1:06 PM Dmitry Tantsur <dtantsur@redhat.com>
wrote:
Finally, I believe that our independence (can I call it “Irexit”
please?) given the political overtones and baggage related to Irexit https://en.wikipedia.org/wiki/Irish_Freedom_Party i would avoid that like the plague both in real life and in this proposal unless you want to advocate for alt-right, populist, xenophobe polictical movement that will piss off most irish people.
Ugh, please accept my apologies, I did not realize there was something under this name already.
No offense intended for anyone. no offense taken, just didnt want to see that name come back to bit you incase you were not aware of the other context its used in.
Dmitry
No, but I will accept "smelting" or "oxidation" ;)
Dmitry Tantsur wrote:
[...] TL;DR I’m proposing to make Ironic a top-level project under opendev.org <http://opendev.org> and the OpenStack Foundation, following the same model as Zuul. I don’t propose severing current relationships with other OpenStack projects, nor making substantial changes in how the project is operated. [...]
I agree that in the current situation, you have to explain that OpenStack is a collection of tools and it's OK if you install just one, while a lot of people assume "OpenStack" means "lots of services". So I think I understand the problem you're trying to solve. The main risk I see here is the slippery slope. Other OpenStack projects can be run standalone (Cinder, Swift...), so under that same reason could also move to be their own top-level project. At which point we end up with a collection of projects under the OSF, very much like we currently have a collection of projects under the TC. The only difference will be that the integration between the various components (currently the role of the TC) will no longer be under the responsibility of anyone. I'm not really sure that with less integration, we'll be collectively better off as a result. So I think we need to dig deeper in the strategy for Ironic, the adoption obstacles we are trying to remove, and discuss the options. Being set up as a separate top-level project is one option. But I feel like changing governance (i.e. no longer be under the TC) has a lot less impact to change the perception than, say, creating a separate ironic product website that explains Ironic completely outside of the OpenStack context (which we could do without changing governance). The release management issue is, I think, mostly a red herring. As swift has proven in the past, you can totally have a product strategy with the cycle-with-intermediary model. You can even maintain your own extra branches (think stable/2.0) if you want. The only extra limitations AFAIK in the integrated release are that (1) you also maintain stable branches at openstack common release points (like stable/train), and (2) that the openstack release management team has an opportunity to check the release numbering for semver sanity. -- Thierry Carrez (ttx)
Hi, On Thu, Apr 2, 2020 at 11:05 AM Thierry Carrez <thierry@openstack.org> wrote:
Dmitry Tantsur wrote:
[...] TL;DR I’m proposing to make Ironic a top-level project under opendev.org <http://opendev.org> and the OpenStack Foundation, following the same model as Zuul. I don’t propose severing current relationships with other OpenStack projects, nor making substantial changes in how the project is operated. [...]
I agree that in the current situation, you have to explain that OpenStack is a collection of tools and it's OK if you install just one, while a lot of people assume "OpenStack" means "lots of services". So I think I understand the problem you're trying to solve.
Exactly. Going a bit philosophical, I wonder if we actually want people to see OpenStack as a collection of tools. In my view, it may improve perception of OpenStack if we start more clearly defining what it is and is not, including promoting OpenStack as a set of services to build an IaaS solution. Including drawing borders with weird citizens like Ironic. I may be horribly wrong here, of course.
The main risk I see here is the slippery slope. Other OpenStack projects can be run standalone (Cinder, Swift...), so under that same reason could also move to be their own top-level project.
I'm surprised that Swift hasn't done that, to be honest :)
At which point we end up with a collection of projects under the OSF, very much like we currently have a collection of projects under the TC. The only difference will be that the integration between the various components (currently the role of the TC) will no longer be under the responsibility of anyone. I'm not really sure that with less integration, we'll be collectively better off as a result.
Cinder specifically is a much more inherent part of OpenStack than Ironic is. Supporting volumes in a cloud is much more natural than supporting bare metal machines. The fact that it can be used standalone is secondary here (and, honestly, I wish more services could be used standalone - I even see a case for standalone Nova!). I don't quite agree that the integration right now is the responsibility of the TC. For me it comes from the customer demand and will die out if such demand diminishes, with or without TC. In Ironic we don't integrate with Nova, Neutron, Glance, Cinder, Swift and Keystone because TC makes us. We do it because our users want us to. We will continue while they do. If at some point, say, Swift consumers stop caring about the rest of OpenStack, I don't think any TC will or any official status will hold the integration together for too long.
So I think we need to dig deeper in the strategy for Ironic, the adoption obstacles we are trying to remove, and discuss the options.
Please count me in!
Being set up as a separate top-level project is one option. But I feel like changing governance (i.e. no longer be under the TC) has a lot less impact to change the perception than, say, creating a separate ironic product website that explains Ironic completely outside of the OpenStack context (which we could do without changing governance).
This is a great idea, and I agree that we should do it irregardless of this decision. However, if we do this and also the release management changes you're talking about below, what will be left of our participation in OpenStack? Dmitry
The release management issue is, I think, mostly a red herring. As swift has proven in the past, you can totally have a product strategy with the cycle-with-intermediary model. You can even maintain your own extra branches (think stable/2.0) if you want. The only extra limitations AFAIK in the integrated release are that (1) you also maintain stable branches at openstack common release points (like stable/train), and (2) that the openstack release management team has an opportunity to check the release numbering for semver sanity.
-- Thierry Carrez (ttx)
TL;DR thanks Dmitry, I'm glad to see this concretize after all the talks :) On Wed, Apr 1, 2020 at 7:08 PM Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi everyone!
This topic should not come as a huge surprise for many, since it has been raised numerous times in the past years. I have a feeling that the end of Ussuri, now that we’ve re-acquired our PTL and are on the verge of selecting new TC members, may be a good time to propose it for a formal discussion.
TL;DR I’m proposing to make Ironic a top-level project under opendev.org and the OpenStack Foundation, following the same model as Zuul. I don’t propose severing current relationships with other OpenStack projects, nor making substantial changes in how the project is operated.
(And no, it’s not an April 1st joke)
Background =========
Ironic was born as a Nova plugin, but has grown way beyond this single case since then. The first commit in Bifrost dates to February 2015. During these 5 years (hey, we forgot to celebrate!) it has developed into a commonly used data center management tool - and still based on standalone Ironic! The Metal3 project uses standalone Ironic as its hardware management backend. We haven’t been “just” a component of OpenStack for a while now, I think it’s time to officially recognize it.
I can definitely confirm, being deeply involved in Metal3 and Openshift on the hardware management side, having ironic as an "independent" product from the top will probably simplify the road ahead, and maybe save some of what has left of my sanity :)
And before you ask: in no case do I suggest scaling down our invaluable integration with Nova. We’re observing a solid growth of deployments using Ironic as an addition to their OpenStack clouds, and this proposal doesn’t try to devalue this use case. The intention is to accept publicly and officially that it’s not the only or the main use case, but one of the main use cases. I don’t think it comes as a surprise to the Nova team.
Okay, so why? ===========
The first and the main reason is the ambiguity in our positioning. We do see prospective operators and users confused by the perception that Ironic is a part of OpenStack, especially when it comes to the standalone use case. “But what if I don’t need OpenStack” is a question that I hear in most of these conversations. Changing from “a part of OpenStack” to “a FOSS tool that can integrate with OpenStack” is critical for our project to keep growing into new fields. To me personally it feels in line with how OpenDev itself is reaching into new areas beyond just the traditional IaaS. The next OpenDev even will apparently have a bare metal management track, so why not a top-level project for it?
Since I joined the ironic team this is probably *the* recurrent question from former colleagues and operators in general: how can I manage my infrastructure with ironic standalone? The need of integration with Openstack comes after that, it's definitely a plus and a convenience, but not the first thought.
Another reason is release cadence. We have repeatedly expressed the desire to release Ironic and its sub-projects more often than we do now. Granted, *technically* we can release often even now. We can even abandon the current release model and switch to “independent”, but it doesn’t entirely solve the issue at hand. First, we don’t want to lose the notion of stable branches. One way or another, we need to support consumers with bug fix releases. Second, to become truly “independent” we’ll need to remove any tight coupling with any projects that do integrated releases. Which is, essentially, what I’m proposing here.
Finally, I believe that our independence (can I call it “Irexit” please?) has already happened in reality, we just shy away from recognizing it. Look: 1. All integration points with other OpenStack projects are optional. 2. We can work fully standalone and even provide a project for that. 3. Many new features (RAID, BIOS to name a few) are exposed to standalone users much earlier than to those going through Nova.
Again can definitely confirm the latest two points, we saw a lot of features being included in Metal3 as "finished product", from hardware management perspective, than generally available in a current Openstack distribution.
4. We even have our own mini-scheduler (although its intention is not and has not been to replace the Placement service). 5. We make releases more often than the “core” OpenStack projects (but see above).
What we will do ============
This proposal involves in the short term: * Creating a new git namespace: opendev.org/ironic * Creating a new website (name TBD, bare metal puns are welcome). * If we can have https://docs.opendev.org/ironic/, it may be just fine though. * Keeping the same governance model, only adjusted to the necessary extent. * Keeping the same policies (reviews, CI, stable). * Defining a new release cadence and stable branch support schedule.
In the long term we will consider (not necessary do): * Reshaping our CI to rely less on devstack and grenade (only use them for jobs involving OpenStack). * Reducing or removing reliance on oslo libraries. * Stopping using rabbitmq for messaging (we’ve already made it optional). * Integrating with non-OpenStack services (kubernetes?) and providing lighter alternatives (think, built-in authentication).
This is unavoidable and much needed!
What we will NOT do ================
At least this proposal does NOT involve: * Stopping maintaining the Ironic virt driver in Nova. * Stopping running voting CI jobs with OpenStack services. * Dropping optional integration with OpenStack services. * Leaving OpenDev completely.
What do you think? ===============
Please let us know what you think about this proposal. Any hints on how to proceed with it, in case we reach a consensus, are also welcome.
Cheers, Dmitry
On Thu, 2020-04-02 at 11:40 +0200, Riccardo Pittau wrote:
TL;DR thanks Dmitry, I'm glad to see this concretize after all the talks :)
On Wed, Apr 1, 2020 at 7:08 PM Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi everyone!
This topic should not come as a huge surprise for many, since it has been raised numerous times in the past years. I have a feeling that the end of Ussuri, now that we’ve re-acquired our PTL and are on the verge of selecting new TC members, may be a good time to propose it for a formal discussion.
TL;DR I’m proposing to make Ironic a top-level project under opendev.org and the OpenStack Foundation, following the same model as Zuul. I don’t propose severing current relationships with other OpenStack projects, nor making substantial changes in how the project is operated.
(And no, it’s not an April 1st joke)
Background =========
Ironic was born as a Nova plugin, but has grown way beyond this single case since then. The first commit in Bifrost dates to February 2015. During these 5 years (hey, we forgot to celebrate!) it has developed into a commonly used data center management tool - and still based on standalone Ironic! The Metal3 project uses standalone Ironic as its hardware management backend. We haven’t been “just” a component of OpenStack for a while now, I think it’s time to officially recognize it.
I can definitely confirm, being deeply involved in Metal3 and Openshift on the hardware management side, having ironic as an "independent" product from the top will probably simplify the road ahead, and maybe save some of what has left of my sanity :) given that ironci can already change to release cycle independt and release as offten as it like and give it is already deployable standalone with bifrost i dont think it will actully make any difference if it a seperate top level project in regards to openshift integration.
also we generally dont use the term product upstream. products are sold and have supprot implications, project are collaberations of like mined folk trying to solve common problems and helping each other out. that said im not against the idea or ironic being used standalone. i have use bifrost for personal use in the past and love the kaobe/kolla-ansible approch of using standalone ironic via bifrost to manage your hardware and then kolla- ansbile to deploy your cloud. doing the same thing with metal3 is also great im not sure if a governace change will help but i agree that the seperate marketing page for ironic an related services to better cater for that usecase which is mentioned else where in this mail is a good idea.
And before you ask: in no case do I suggest scaling down our invaluable integration with Nova. We’re observing a solid growth of deployments using Ironic as an addition to their OpenStack clouds, and this proposal doesn’t try to devalue this use case. The intention is to accept publicly and officially that it’s not the only or the main use case, but one of the main use cases. I don’t think it comes as a surprise to the Nova team.
Okay, so why? ===========
The first and the main reason is the ambiguity in our positioning. We do see prospective operators and users confused by the perception that Ironic is a part of OpenStack, especially when it comes to the standalone use case. “But what if I don’t need OpenStack” is a question that I hear in most of these conversations. Changing from “a part of OpenStack” to “a FOSS tool that can integrate with OpenStack” is critical for our project to keep growing into new fields. To me personally it feels in line with how OpenDev itself is reaching into new areas beyond just the traditional IaaS. The next OpenDev even will apparently have a bare metal management track, so why not a top-level project for it?
Since I joined the ironic team this is probably *the* recurrent question from former colleagues and operators in general: how can I manage my infrastructure with ironic standalone? The need of integration with Openstack comes after that, it's definitely a plus and a convenience, but not the first thought.
Another reason is release cadence. We have repeatedly expressed the desire to release Ironic and its sub-projects more often than we do now. Granted, *technically* we can release often even now. We can even abandon the current release model and switch to “independent”, but it doesn’t entirely solve the issue at hand. First, we don’t want to lose the notion of stable branches. One way or another, we need to support consumers with bug fix releases. Second, to become truly “independent” we’ll need to remove any tight coupling with any projects that do integrated releases. Which is, essentially, what I’m proposing here.
Finally, I believe that our independence (can I call it “Irexit” please?) has already happened in reality, we just shy away from recognizing it. Look: 1. All integration points with other OpenStack projects are optional. 2. We can work fully standalone and even provide a project for that. 3. Many new features (RAID, BIOS to name a few) are exposed to standalone users much earlier than to those going through Nova.
Again can definitely confirm the latest two points, we saw a lot of features being included in Metal3 as "finished product", from hardware management perspective, than generally available in a current Openstack distribution.
given we have not had a lot of specs or blueprints propsoed to consume new ironic feature for nova is that because no one cares about those features in a nova context, no one has had time to work on it or the nova team does not know about them. from my perspecitive of someone who works on nova and does take an active interst in review the nova-spec repo i have not had much visablity into what feature were added for metal3 that are not supproted by nova. i suspect that a lot of them are just not comunicated well. for example i know many redhat folks have contiubted to meltal3 but i dont think many of them have reached out the too the compute dfg to tell use what new feature they are adding or asking for use to support them in nova so im not sure this is beause its harder to integrate in nova so much as no one has done the work. it is harder to integrate with nova but that is beside the point.
4. We even have our own mini-scheduler (although its intention is not and has not been to replace the Placement service). 5. We make releases more often than the “core” OpenStack projects (but see above).
What we will do ============
This proposal involves in the short term: * Creating a new git namespace: opendev.org/ironic * Creating a new website (name TBD, bare metal puns are welcome). * If we can have https://docs.opendev.org/ironic/, it may be just fine though. * Keeping the same governance model, only adjusted to the necessary extent. * Keeping the same policies (reviews, CI, stable). * Defining a new release cadence and stable branch support schedule.
In the long term we will consider (not necessary do): * Reshaping our CI to rely less on devstack and grenade (only use them for jobs involving OpenStack). * Reducing or removing reliance on oslo libraries. * Stopping using rabbitmq for messaging (we’ve already made it optional). * Integrating with non-OpenStack services (kubernetes?) and providing lighter alternatives (think, built-in authentication).
This is unavoidable and much needed!
given that kuryr exists i dont think there is anything preventing openstack service form integrating with non openstack service today. nova and other serivce have plugin for auth. granted the only production one is keystone but i dont see any reason that ironic could not have a plugin for native kubernets auth or some other light weight alternivie although since kubernets already support integreating with keystone using keystone auth is praobly still the better approch. of all of the service in openstack keystone is proably one of the lightest weight services there is. placment might be slightly lighter but both are not exactuly combersum to deploy standalone and consume with ironic/bifrost.
What we will NOT do ================
At least this proposal does NOT involve: * Stopping maintaining the Ironic virt driver in Nova. * Stopping running voting CI jobs with OpenStack services. * Dropping optional integration with OpenStack services. * Leaving OpenDev completely.
What do you think? ===============
Please let us know what you think about this proposal. Any hints on how to proceed with it, in case we reach a consensus, are also welcome.
Cheers, Dmitry
Hello, My opinion (a little bit conservative, for once) is inline... On Wed, 2020-04-01 at 19:03 +0200, Dmitry Tantsur wrote:
The first and the main reason is the ambiguity in our positioning. We do see prospective operators and users confused by the perception that Ironic is a part of OpenStack, especially when it comes to the standalone use case. “But what if I don’t need OpenStack” is a question that I hear in most of these conversations. Changing from “a part of OpenStack” to “a FOSS tool that can integrate with OpenStack” is critical for our project to keep growing into new fields.
I think the name "Ironic" associated with the term "bare metal" maps to OpenStack. You are right. It's in the heads of the people who were involved, in the search engines, etc. However, I am not 100% sure it maps with "needs Nova" or "cannot be standalone". If you consider OpenStack taints this "standalone" part of Ironic, do you think that putting it as a top project of the **OpenStack Foundation ** will help? I don't think so. People will still see it's an OpenStack _related_ technology, with a history of being an OpenStack project, which is now a standalone project inside the OpenStack foundation. At best, it confuses people which are not really aware of all these details. If you really want to leave OpenStack for standalone purpose, I would encourage to try a more radical approach, like gnocchi, who completely split out. Sadly it didn't turn out fine for them, but at least the difference was clear. It was out. Again, I don't think that being in the "openstack" namespace prevents standalone. In fact that's what I would like to see more with our current openstack projects: Be relevant as standalone. Swift and Ironic are very good examples. They make sense in OpenStack, as standalone services, that happen to work well together in an ecosystem for IaaS. The whole point of the OpenStack name, for me, is the coordinated testing and releasing. "Those independents bits are tested together!". Can't we work on the branding, naming, and message without the move? Why the hassle of moving things? Does that really bring value to your team? Before forging my final (personal) opinion, I would like more information than just gut feelings.
To me personally it feels in line with how OpenDev itself is reaching into new areas beyond just the traditional IaaS. The next OpenDev even will apparently have a bare metal management track, so why not a top-level project for it?
I like the OpenDev idea, but I cannot unshake this off the OSF. In other words, I am not sure how far it goes "beyond the traditional IaaS" in my mind, because the OSF (and OpenDev) have missions after all. Would you care to explain for me? How does that map with the ironic reflection? I am confused, Ironic _for me_ is an infrastructure tool...
Another reason is release cadence. We have repeatedly expressed the desire to release Ironic and its sub-projects more often than we do now. Granted, *technically* we can release often even now. We can even abandon the current release model and switch to “independent”, but it doesn’t entirely solve the issue at hand. First, we don’t want to lose the notion of stable branches.
Independant doesn't mean _not branching_. In the old times, before cycle-trailing existed, OpenStack-Ansible was independent, we manually branched, and used the release tooling to do official releases. It's pretty close to what you are looking for, IMO.
One way or another, we need to support consumers with bug fix releases. Second, to become truly “independent” we’ll need to remove any tight coupling with any projects that do integrated releases. Which is, essentially, what I’m proposing here.
That's for me the simplest change you can do. When you move to independant, while still benefit from the release tooling and help of your current reviewer sets. Please note that I am still writing an idea in our ideas framework, proposing a change in the release cycles (that conversation again! but with a little twist), which I guess you might be interested in. Regards, Jean-Philippe Evrard
Hi, On Thu, Apr 2, 2020 at 12:17 PM Jean-Philippe Evrard < jean-philippe@evrard.me> wrote:
Hello,
My opinion (a little bit conservative, for once) is inline...
On Wed, 2020-04-01 at 19:03 +0200, Dmitry Tantsur wrote:
The first and the main reason is the ambiguity in our positioning. We do see prospective operators and users confused by the perception that Ironic is a part of OpenStack, especially when it comes to the standalone use case. “But what if I don’t need OpenStack” is a question that I hear in most of these conversations. Changing from “a part of OpenStack” to “a FOSS tool that can integrate with OpenStack” is critical for our project to keep growing into new fields.
I think the name "Ironic" associated with the term "bare metal" maps to OpenStack. You are right. It's in the heads of the people who were involved, in the search engines, etc.
However, I am not 100% sure it maps with "needs Nova" or "cannot be standalone".
People do get surprised when they hear that Ironic can be used standalone, yes. "A part of OpenStack" maps to "installed inside OpenStack" rather than "is developed on the OpenStack platform".
If you consider OpenStack taints this "standalone" part of Ironic, do you think that putting it as a top project of the **OpenStack Foundation ** will help? I don't think so. People will still see it's an OpenStack _related_ technology, with a history of being an OpenStack project, which is now a standalone project inside the OpenStack foundation. At best, it confuses people which are not really aware of all these details.
Time to rename the Foundation? :) How is the same problem solved for Zuul or Kata Containers?
If you really want to leave OpenStack for standalone purpose, I would encourage to try a more radical approach, like gnocchi, who completely split out. Sadly it didn't turn out fine for them, but at least the difference was clear. It was out.
As an aside, I don't think gnocchi fell victim of their split, but rather shared the overall fate of the Telemetry project. I also think your suggestion goes against the idea of OpenDev, which to me is to embrace a fast collection of Open Infrastructure projects, related to OpenStack or not. If you say that anything going to OpenDev will be seen as an OpenStack project, it defeats the purpose of OpenDev.
Again, I don't think that being in the "openstack" namespace prevents standalone. In fact that's what I would like to see more with our current openstack projects: Be relevant as standalone. Swift and Ironic are very good examples. They make sense in OpenStack, as standalone services, that happen to work well together in an ecosystem for IaaS. The whole point of the OpenStack name, for me, is the coordinated testing and releasing. "Those independents bits are tested together!".
Can't we work on the branding, naming, and message without the move? Why the hassle of moving things? Does that really bring value to your team? Before forging my final (personal) opinion, I would like more information than just gut feelings.
It's not "just gut feelings", it's the summary of numerous conversations that Julia and I have to hold when advocating for Ironic outside of the Nova context. We do this "Ironic does not imply OpenStack" explanation over and over, often enough unsuccessfully. And then some people just don't like OpenStack... Now, I do agree that there are steps that can be taken before we go all nuclear. We can definitely work on our own website, we can reduce reliance on oslo, start releasing independently, and so on. I'm wondering what will be left of our participation in OpenStack in the end. Thierry has suggested the role of the TC in ensuring integration. I'm of the opinion that if all stakeholders in Ironic lose interest in Ironic as part of OpenStack, no power will prevent the integration from slowly falling apart.
To me personally it feels in line with how OpenDev itself is reaching into new areas beyond just the traditional IaaS. The next OpenDev even will apparently have a bare metal management track, so why not a top-level project for it?
I like the OpenDev idea, but I cannot unshake this off the OSF. In other words, I am not sure how far it goes "beyond the traditional IaaS" in my mind, because the OSF (and OpenDev) have missions after all. Would you care to explain for me? How does that map with the ironic reflection? I am confused, Ironic _for me_ is an infrastructure tool...
I'm referring to a very narrow sense of Nova+company. I.e. a solution for providing virtual machines booting from virtual volumes on virtual networks. Ironic does not clearly fit there, nor does, say, Zuul.
Another reason is release cadence. We have repeatedly expressed the desire to release Ironic and its sub-projects more often than we do now. Granted, *technically* we can release often even now. We can even abandon the current release model and switch to “independent”, but it doesn’t entirely solve the issue at hand. First, we don’t want to lose the notion of stable branches.
Independant doesn't mean _not branching_. In the old times, before cycle-trailing existed, OpenStack-Ansible was independent, we manually branched, and used the release tooling to do official releases. It's pretty close to what you are looking for, IMO.
Good point, noted.
One way or another, we need to support consumers with bug fix releases. Second, to become truly “independent” we’ll need to remove any tight coupling with any projects that do integrated releases. Which is, essentially, what I’m proposing here.
That's for me the simplest change you can do. When you move to independant, while still benefit from the release tooling and help of your current reviewer sets.
Please note that I am still writing an idea in our ideas framework, proposing a change in the release cycles (that conversation again! but with a little twist), which I guess you might be interested in.
Please let me know when it's ready, I really am. Dmitry
Regards, Jean-Philippe Evrard
On Thu, 2020-04-02 at 12:38 +0200, Dmitry Tantsur wrote:
confused, Ironic _for me_ is an infrastructure tool...
I'm referring to a very narrow sense of Nova+company. I.e. a solution for providing virtual machines booting from virtual volumes on virtual networks. Ironic does not clearly fit there, nor does, say, Zuul.
well that is mischaracterising openstack as a vm centric iaas platform the very fact that nova-baremeatal dates back to folsom and we have many baremetal only cloud means that it is false to assume that the goal of openstack and nova specificly is only to cater for vms we have had several container backend like nova-lxd and nova-docker over the years. i for one was alwasy a fan of nova libvirt/lxc and we have other project like zun that integrate with kata containers. so i think ironci fits perfectly in the view of a cloud. if it did not then it would not be a good fit in kubernetes/openshift either which would suggest that metal3 is not a useful thing. given the interst metal3 has been getting i think we can agree that is not the case and that baremetal clouds are a think and a good synergy of technologies. openstack is a cloud plathform and as much as i like nova it is not what defines openstack its the collection of service and comuntieis that we have built that does and nova and ironic are both today part of that. that does nto prevent any of the combponets form being used on there own if the service chooses to support that.
Another reason is release cadenc
On 2020-04-02 12:38:02 +0200 (+0200), Dmitry Tantsur wrote: [...]
I also think your suggestion goes against the idea of OpenDev, which to me is to embrace a fast collection of Open Infrastructure projects, related to OpenStack or not. If you say that anything going to OpenDev will be seen as an OpenStack project, it defeats the purpose of OpenDev. [...]
I'll refrain from jumping into the rest of this, but please be aware that OpenDev's scope is not just limited to Open Infrastructure projects. The OpenDev team maintains a collaboration platform for any open source projects who are interested in collectively maintaining the development tooling on which their communities rely. OpenDev's collaboratory *is* a form of "infrastructure" but you don't need to be an infrastructure-focused project to be hosted within it. To quote the first two sentences from the current text on the https://opendev.org/ Web site: OpenDev is a space for collaborative Open Source software development. OpenDev’s mission is to provide project hosting, continuous integration tooling, and virtual collaboration spaces for Open Source software projects. It's also the case that not all the OSF's official "Open Infrastructure projects" are hosted in OpenDev's collaboratory (most are though, yes). -- Jeremy Stanley
On Thu, Apr 2, 2020, at 3:38 AM, Dmitry Tantsur wrote:
Snip because I wanted to respond to one specific point made below.
Now, I do agree that there are steps that can be taken before we go all nuclear. We can definitely work on our own website, we can reduce reliance on oslo, start releasing independently, and so on. I'm wondering what will be left of our participation in OpenStack in the end. Thierry has suggested the role of the TC in ensuring integration. I'm of the opinion that if all stakeholders in Ironic lose interest in Ironic as part of OpenStack, no power will prevent the integration from slowly falling apart.
Opinion from someone that has worked on OpenStack for a long time: I don't think using oslo, sticking to a 6 month release cadence, integration with Nova is what defines "OpenStack". The goal has been to build tools for API driven management of data center resources. When looked at in this way some of the other examples mentioned, Zuul and Gnocchi, don't quite fit. But within that goal even if we aren't using the same underlying libraries or releasing in tight synchronization the involved individuals and projects can learn from each other and help each other in significant ways. Taking Ironic as the example, I think one of the major ways Ironic can contribute to OpenStack is showing how you can evolve to do things like 1) operate in a standalone fashion to meet user demands 2) remove/refactor/replace existing dependencies like rabbitmq to improve operability and stability 3) rely less on devstack for testing and so on. Whether or not the proposed split happens isn't up to me, but I'm worried we think that using oslo, integrating with nova, and strict adherence to a 6 month release cycle is what defines OpenStack. What will be left is your participation in the community to not only make management of baremetal servers in the datacenter better, but also networking, and virtualization, and storage and so on. Clark
On Thu, Apr 2, 2020 at 10:58 AM Clark Boylan <cboylan@sapwetik.org> wrote:
On Thu, Apr 2, 2020, at 3:38 AM, Dmitry Tantsur wrote:
Snip because I wanted to respond to one specific point made below.
Now, I do agree that there are steps that can be taken before we go all nuclear. We can definitely work on our own website, we can reduce reliance on oslo, start releasing independently, and so on. I'm wondering what will be left of our participation in OpenStack in the end. Thierry has suggested the role of the TC in ensuring integration. I'm of the opinion that if all stakeholders in Ironic lose interest in Ironic as part of OpenStack, no power will prevent the integration from slowly falling apart.
Opinion from someone that has worked on OpenStack for a long time: I don't think using oslo, sticking to a 6 month release cadence, integration with Nova is what defines "OpenStack". The goal has been to build tools for API driven management of data center resources. When looked at in this way some of the other examples mentioned, Zuul and Gnocchi, don't quite fit. But within that goal even if we aren't using the same underlying libraries or releasing in tight synchronization the involved individuals and projects can learn from each other and help each other in significant ways.
You raise many good points, and I would hope that there would be a continuing cross-learning and collaboration. I feel like the idea of independence driven by trying to solve two distinct issues (perceptions (of, about, and related to OpenStack as related to Ironic), and human resistance to any different pattern of behavior (releases _AND_ consumption their of)) has elicited a bit of a nuclear response and interpretation.
Taking Ironic as the example, I think one of the major ways Ironic can contribute to OpenStack is showing how you can evolve to do things like 1) operate in a standalone fashion to meet user demands 2) remove/refactor/replace existing dependencies like rabbitmq to improve operability and stability 3) rely less on devstack for testing and so on.
I think we already have. Although, I'm unsure if the developer community at large places any value on those things. In my experience, consumers of ironic software seem to. Has Ironic failed to really broadcast those things out? Likely, but I'm fairly sure we've mentioned some of these things in multiple forums (including Forums and project update). As a result I'm also unsure of what really more we CAN [effectively] do given the pre-conditions and resistance to change along with the existing team divisions and focuses. Is there a better way that reaches everyone? An additional way? I don't know, but would sure like to know of one.
Whether or not the proposed split happens isn't up to me, but I'm worried we think that using oslo, integrating with nova, and strict adherence to a 6 month release cycle is what defines OpenStack. What will be left is your participation in the community to not only make management of baremetal servers in the datacenter better, but also networking, and virtualization, and storage and so on.
Clark
I believe it is ultimately up to the active contributors to the project as a whole in terms of splitting, and I guess that should be put to a vote at some point. Last time we polled among the cores about a ?year? ago upon revisiting an ask for us to consider working towards becoming a top level project, it was 50/50. Given everyone's comments, I'm fairly sure there would not be agreement to move forward. Maybe out of this, as a community, we could have a serious discussion of perceptions and headaches, but given our tendency to try and create process and tools for issues that are fundamentally related to humans... I am unsure. -Julia
On Thu, 2020-04-02 at 13:15 -0700, Julia Kreger wrote:
I believe it is ultimately up to the active contributors to the project as a whole in terms of splitting, and I guess that should be put to a vote at some point. Last time we polled among the cores about a ?year? ago upon revisiting an ask for us to consider working towards becoming a top level project, it was 50/50. Given everyone's comments, I'm fairly sure there would not be agreement to move forward.
I wholeheartily agree with the fact it's up to the active contributors. I just hope that if/when the move is done, it's a positive effort, and everyone had the required elements to decide. I can't tell for the other answers in this thread, but for me, I want to ask the difficult questions to make sure we have done everything that's right :) Let me rephrase that: If the Ironic community wants to split, let it be! I am not against the split by itself. I won't ask to stay if everybody wants to leave the boat. My intent is not to be a warden, because OpenStack isn't a prison :) I just love playing Devil's advocate. In this case, I am particularily interested, because I just genuinely care, and I am trying to think at the ecosystem level, not only at a project level. I try to understand how I can help Ironic grow, while helping the other projects too. I hope I am not the only one responding with that kind of view. It seems ironic has a few ideas on how to improve its standalone identity forward that doesn't seem needing to split out of OpenStack... I am just questioning whether the split out needs to happen now, or maybe phased afterwards.
Maybe out of this, as a community, we could have a serious discussion of perceptions and headaches, but given our tendency to try and create process and tools for issues that are fundamentally related to humans... I am unsure.
That's totally fair. I think we need to simplify openstack futher. Be the bazaar, not the Cathedral. Regards, JP
On Thu, 2020-04-02 at 10:56 -0700, Clark Boylan wrote:
Taking Ironic as the example, I think one of the major ways Ironic can contribute to OpenStack is showing how you can evolve to do things like 1) operate in a standalone fashion to meet user demands 2) remove/refactor/replace existing dependencies like rabbitmq to improve operability and stability 3) rely less on devstack for testing and so on.
Just FYI, I feel the same. I wouldn't stop on those 3 items, as I think project identity and branding will need a lot of work. I just think this work is to be done, regardless of where it's hosted. Regards, JP
Hello, On Thu, 2020-04-02 at 12:38 +0200, Dmitry Tantsur wrote:
Hi,
(snipped)
People do get surprised when they hear that Ironic can be used standalone, yes. "A part of OpenStack" maps to "installed inside OpenStack" rather than "is developed on the OpenStack platform".
That's indeed what we need to change.
If you consider OpenStack taints this "standalone" part of Ironic, do you think that putting it as a top project of the **OpenStack Foundation ** will help? I don't think so. People will still see it's an OpenStack _related_ technology, with a history of being an OpenStack project, which is now a standalone project inside the OpenStack foundation. At best, it confuses people which are not really aware of all these details.
Time to rename the Foundation? :) How is the same problem solved for Zuul or Kata Containers?
The first made me smile :) I would say that Kata and Zuul have a different history. To my eyes, Kata started as completely separated. How Zuul will eventually manage to detatch itself from the OpenStack name could be interesting. Please note that I have received the same questions (Do I need openstack? Is it a part of openstack?) when questioned about Zuul, in some events. (snipped)
As an aside, I don't think gnocchi fell victim of their split, but rather shared the overall fate of the Telemetry project.
I don't disagree.
I also think your suggestion goes against the idea of OpenDev, which to me is to embrace a fast collection of Open Infrastructure projects, related to OpenStack or not. If you say that anything going to OpenDev will be seen as an OpenStack project, it defeats the purpose of OpenDev.
I wrongly worded this then. This is not my intent. OpenDev is a good name/good branding IMO. It feels detached from OpenStack. I can totally see many projects to be successful there without appearing to be attached to the OpenStack name. For people searching a little bit, it wouldn't take long to see that OpenStack was behind OpenDev, and therefore people can still attach the name if they want. I think that what matters is to be explicit in the project message. (snipped)
Can't we work on the branding, naming, and message without the move? Why the hassle of moving things? Does that really bring value to your team? Before forging my final (personal) opinion, I would like more information than just gut feelings.
It's not "just gut feelings", it's the summary of numerous conversations that Julia and I have to hold when advocating for Ironic outside of the Nova context. We do this "Ironic does not imply OpenStack" explanation over and over, often enough unsuccessfully.
Let me rephrase this: Do you have feedback from people not active in the project which would be happy to step up/in if Ironic was not an OpenStack project anymore? What could be changed from the OpenStack side to change that mindset?
And then some people just don't like OpenStack...
I don't disagree, sadly. I know it's a hard task, but I prefer tackling this. Make OpenStack (more) likeable. To me, that seems a better goal in itself. But that's maybe me :)
Now, I do agree that there are steps that can be taken before we go all nuclear. We can definitely work on our own website, we can reduce reliance on oslo, start releasing independently, and so on. I'm wondering what will be left of our participation in OpenStack in the end. Thierry has suggested the role of the TC in ensuring integration. I'm of the opinion that if all stakeholders in Ironic lose interest in Ironic as part of OpenStack, no power will prevent the integration from slowly falling apart.
I don't see it that way. I see this as an opportunity to make OpenStack more clear, more reachable, more interesting. For me, Ironic, Cinder, Manila (to only name a few), are very good example of datacenter/IaaS software that could be completely independent in their consumption, and additionally released together. For me, the strength of OpenStack was always in the fact it had multiple small projects that work well together, compared to a single big blob of software which does everything. We just didn't bank enough on the standalone IMHO. But I am sure we are aligned there... Wouldn't the next steps be instead to make it easier to consume standalone? Also, how is the reliance on oslo a problem? Do you want to use another library in the python ecosystem instead? If true, what about phasing out that part of oslo, so we don't have to maintain it? Just curious.
(snipped) I'm referring to a very narrow sense of Nova+company. I.e. a solution for providing virtual machines booting from virtual volumes on virtual networks. Ironic does not clearly fit there, nor does, say, Zuul.
Got it. That's not my understanding of what OpenStack is, but I concede that I might have a different view than most.
)snipped) Please note that I am still writing an idea in our ideas framework, proposing a change in the release cycles (that conversation again! but with a little twist), which I guess you might be interested in.
Please let me know when it's ready, I really am.
Will do! Regards, JP
On 03/04/20 09:30 +0200, Jean-Philippe Evrard wrote:
Hello,
On Thu, 2020-04-02 at 12:38 +0200, Dmitry Tantsur wrote: <snip> (snipped) I'm referring to a very narrow sense of Nova+company. I.e.
a solution for providing virtual machines booting from virtual volumes on virtual networks. Ironic does not clearly fit there, nor does, say, Zuul.
Got it. That's not my understanding of what OpenStack is, but I concede that I might have a different view than most.
+1000 and I hope that we're all moving beyond this narrow understanding of what OpenStack is. I think of myself as working on OpenStack because I work on self-service storage cloud infrastructure with hard multi-tenant separatiion in a community committed to a design and development process committed to The Four Opens [1]. None of that requires that the consumers of this self-service storage infrastructure be virtual machines booting from virtual volumes on virtual networks. Sure, Nova VMs consume Manila shares. But so do bare metal machines and container workloads (via CSI plugins) themselves running on VMs and running on bare metal, where the hosts theselves may or may not be part of an OpenStack cloud. It would be interesting to see the question at hand about Ironic framed in the context of the recent OpenStack Technical Vision [2]. Is there an Ironic Vision that does not really align with it? -- Tom Barron [1] https://governance.openstack.org/tc/reference/opens.html [2] https://governance.openstack.org/tc/reference/technical-vision.html
Hi, On Fri, Apr 3, 2020 at 9:35 AM Jean-Philippe Evrard <jean-philippe@evrard.me> wrote:
Hello,
On Thu, 2020-04-02 at 12:38 +0200, Dmitry Tantsur wrote:
Hi,
(snipped)
People do get surprised when they hear that Ironic can be used standalone, yes. "A part of OpenStack" maps to "installed inside OpenStack" rather than "is developed on the OpenStack platform".
That's indeed what we need to change.
If you consider OpenStack taints this "standalone" part of Ironic, do you think that putting it as a top project of the **OpenStack Foundation ** will help? I don't think so. People will still see it's an OpenStack _related_ technology, with a history of being an OpenStack project, which is now a standalone project inside the OpenStack foundation. At best, it confuses people which are not really aware of all these details.
Time to rename the Foundation? :) How is the same problem solved for Zuul or Kata Containers?
The first made me smile :)
I would say that Kata and Zuul have a different history. To my eyes, Kata started as completely separated. How Zuul will eventually manage to detatch itself from the OpenStack name could be interesting. Please note that I have received the same questions (Do I need openstack? Is it a part of openstack?) when questioned about Zuul, in some events.
(snipped)
As an aside, I don't think gnocchi fell victim of their split, but rather shared the overall fate of the Telemetry project.
I don't disagree.
I also think your suggestion goes against the idea of OpenDev, which to me is to embrace a fast collection of Open Infrastructure projects, related to OpenStack or not. If you say that anything going to OpenDev will be seen as an OpenStack project, it defeats the purpose of OpenDev.
I wrongly worded this then. This is not my intent. OpenDev is a good name/good branding IMO. It feels detached from OpenStack. I can totally see many projects to be successful there without appearing to be attached to the OpenStack name. For people searching a little bit, it wouldn't take long to see that OpenStack was behind OpenDev, and therefore people can still attach the name if they want. I think that what matters is to be explicit in the project message.
(snipped)
Can't we work on the branding, naming, and message without the move? Why the hassle of moving things? Does that really bring value to your team? Before forging my final (personal) opinion, I would like more information than just gut feelings.
It's not "just gut feelings", it's the summary of numerous conversations that Julia and I have to hold when advocating for Ironic outside of the Nova context. We do this "Ironic does not imply OpenStack" explanation over and over, often enough unsuccessfully.
Let me rephrase this: Do you have feedback from people not active in the project which would be happy to step up/in if Ironic was not an OpenStack project anymore? What could be changed from the OpenStack side to change that mindset?
In my case it's more about potential adoption rather than contributions. Then there is this problem: I probably don't hear from a lot of people who silently walk away assuming that "an OpenStack project" requires OpenStack. We can try to educate people on a case-by-case basis, but to solve the problem completely we may need to stop being "an OpenStack project" even if we don't actually quit the OpenStack umbrella.
And then some people just don't like OpenStack...
I don't disagree, sadly. I know it's a hard task, but I prefer tackling this. Make OpenStack (more) likeable. To me, that seems a better goal in itself. But that's maybe me :)
Now, I do agree that there are steps that can be taken before we go all nuclear. We can definitely work on our own website, we can reduce reliance on oslo, start releasing independently, and so on. I'm wondering what will be left of our participation in OpenStack in the end. Thierry has suggested the role of the TC in ensuring integration. I'm of the opinion that if all stakeholders in Ironic lose interest in Ironic as part of OpenStack, no power will prevent the integration from slowly falling apart.
I don't see it that way. I see this as an opportunity to make OpenStack more clear, more reachable, more interesting. For me, Ironic, Cinder, Manila (to only name a few), are very good example of datacenter/IaaS software that could be completely independent in their consumption, and additionally released together. For me, the strength of OpenStack was always in the fact it had multiple small projects that work well together, compared to a single big blob of software which does everything. We just didn't bank enough on the standalone IMHO. But I am sure we are aligned there... Wouldn't the next steps be instead to make it easier to consume standalone?
For us one of the problems, as I've mentioned already, is producing releases more often. Now, the point of potential misunderstanding is this: we can (and do) release more often than once in 6 months. These releases, however, do not enjoy the same degree of support as the "blessed" releases, especially when it comes to upgrades and longer-term support. Partly related to that, most of the tooling to install and operate OpenStack services seemingly: 1) Don't support non-coordinated releases. 2) Don't support standalone installation at all or make it a 2nd class citizen. Ironic provides Bifrost to partly cover this gap.
Also, how is the reliance on oslo a problem? Do you want to use another library in the python ecosystem instead? If true, what about phasing out that part of oslo, so we don't have to maintain it? Just curious.
The problem is that oslo libraries are OpenStack-specific. Imagine metal3, for example. When building our images, we can pull (most of) regular Python packages from the base OS, but everything with "oslo" in its name is on us. It's a maintenance burden. With absolutely no disrespect meant to the awesome Oslo team, I think the existence of Oslo libraries is a bad sign. I think as a strong FOSS community we shouldn't invest into libraries that are either useful only to us or at least are marketed this way. For example: 1) oslo.config is a fantastic piece of software that the whole python world could benefit from. Same for oslo.service, probably. 2) oslo.utils as a catch-all repository of utilities should IMO be either moved to existing python projects or decomposed into small generally reusable libraries (essentially, each sub-module could be a library of its own). Same for oslo.concurrency. 3) I'm genuinely not sure why oslo.log and oslo.i18n exist and which parts of their functionality cannot be moved upstream.
(snipped) I'm referring to a very narrow sense of Nova+company. I.e. a solution for providing virtual machines booting from virtual volumes on virtual networks. Ironic does not clearly fit there, nor does, say, Zuul.
Got it. That's not my understanding of what OpenStack is, but I concede that I might have a different view than most.
It's not mine either. I wonder if it's a good thing. I wonder if OpenStack would be (using your own words) more likeable if it was clearer what OpenStack is. Dmitry
)snipped) Please note that I am still writing an idea in our ideas framework, proposing a change in the release cycles (that conversation again! but with a little twist), which I guess you might be interested in.
Please let me know when it's ready, I really am.
Will do!
Regards, JP
On Mon, 2020-04-06 at 10:10 +0200, Dmitry Tantsur wrote:
The problem is that oslo libraries are OpenStack-specific. Imagine metal3, for example. When building our images, we can pull (most of) regular Python packages from the base OS, but everything with "oslo" in its name is on us. It's a maintenance burden.
what distros dont ship oslo libs? RHEL ships them via the OSP repos CentOS ship it via RDO Ubunutu has them in the cloud archive SUSE also shiped them via there openstack product although sicne they are nolonger maintaining that goign forward and moveing the k8s based cloud offerings it might be a valid concern there. they are also directly installable via pip. building rpms in the first place is a mangaince burden you do not need if you are doing containerised delivery they only add value if you are supporting non containerised delivery via standard package manages. so for metal3 i dont see that as a vaild argument as in your case redhat is already going to be doing the packageing for the OSP product line irrispective of the supprot/sale of metal3 in a product so using olso wont have any additional downstream cost. form a distro/downstream perpective we still need to maintain the python libs so using oslo is no larger burden the using a different pip lib that is not already packaged in rhel.
On Mon, Apr 6, 2020 at 1:03 PM Sean Mooney <smooney@redhat.com> wrote:
The problem is that oslo libraries are OpenStack-specific. Imagine
On Mon, 2020-04-06 at 10:10 +0200, Dmitry Tantsur wrote: metal3,
for example. When building our images, we can pull (most of) regular Python packages from the base OS, but everything with "oslo" in its name is on us. It's a maintenance burden.
what distros dont ship oslo libs?
RHEL ships them via the OSP repos
As part of OpenStack, right.
CentOS ship it via RDO Ubunutu has them in the cloud archive SUSE also shiped them via there openstack product although sicne they are nolonger maintaining that goign forward and moveing the k8s based cloud offerings it might be a valid concern there.
All the same here: oslo libs are parts of OpenStack distributions/offerings. Meaning that to install Ironic you need to at least enable OpenStack repositories, even if you package Ironic yourself.
they are also directly installable via pip. building rpms in the first place is a mangaince burden you do not need if you are doing containerised delivery they only add value if you are supporting non containerised delivery via standard package manages.
Packages do not lose any of their value when used inside containers, and the same arguments apply to this case. And no, let's not seriously talk about pip install.
so for metal3 i dont see that as a vaild argument as in your case redhat is already going to be doing the packageing for the OSP product line irrispective of the supprot/sale of metal3 in a product so using olso wont have any additional downstream cost.
Metal3 is OpenShift, not OpenStack. You're suggesting exactly the thing that turns people against Ironic: require OpenStack. Dmitry
form a distro/downstream perpective we still need to maintain the python libs so using oslo is no larger burden the using a different pip lib that is not already packaged in rhel.
On Mon, 2020-04-06 at 13:14 +0200, Dmitry Tantsur wrote:
On Mon, Apr 6, 2020 at 1:03 PM Sean Mooney <smooney@redhat.com> wrote:
On Mon, 2020-04-06 at 10:10 +0200, Dmitry Tantsur wrote:
The problem is that oslo libraries are OpenStack-specific. Imagine
metal3,
for example. When building our images, we can pull (most of) regular
Python
packages from the base OS, but everything with "oslo" in its name is on
us.
It's a maintenance burden.
what distros dont ship oslo libs?
RHEL ships them via the OSP repos
As part of OpenStack, right.
CentOS ship it via RDO Ubunutu has them in the cloud archive SUSE also shiped them via there openstack product although sicne they are nolonger maintaining that goign forward and moveing the k8s based cloud offerings it might be a valid concern there.
All the same here: oslo libs are parts of OpenStack distributions/offerings. Meaning that to install Ironic you need to at least enable OpenStack repositories, even if you package Ironic yourself. ya that is true although i think oslo is also a good candiate for standablone reuse outside of openstack. like placment keystone and ironic are. so in my perfered world i would love to see oslo in the base os repos.
they are also directly installable via pip. building rpms in the first place is a mangaince burden you do not need if you are doing containerised delivery they only add value if you are supporting non containerised delivery via standard package manages.
Packages do not lose any of their value when used inside containers, and the same arguments apply to this case. And no, let's not seriously talk about pip install. we can agree to disagree on that point. as someone who prefers to install python packages from souce/pip or viewpoint will difer on there value.
so for metal3 i dont see that as a vaild argument as in your case redhat is already going to be doing the packageing for the OSP product line irrispective of the supprot/sale of metal3 in a product so using olso wont have any additional downstream cost.
Metal3 is OpenShift, not OpenStack. You're suggesting exactly the thing that turns people against Ironic: require OpenStack. well im suggestion we also woudl not want ironci to require openshift. and not really i was more thinking we should work to get oslo packaged in base rhel so that its nolong only shiped in the openstack distro repo and instead availabel for anywoe to use. i kind of feel sad that oslo is not used that much outside of openstack as the lib are good quality.
Dmitry
form a distro/downstream perpective we still need to maintain the python libs so using oslo is no larger burden the using a different pip lib that is not already packaged in rhel.
Sean Mooney wrote:
On Mon, 2020-04-06 at 13:14 +0200, Dmitry Tantsur wrote:
On Mon, Apr 6, 2020 at 1:03 PM Sean Mooney <smooney@redhat.com> wrote:
On Mon, 2020-04-06 at 10:10 +0200, Dmitry Tantsur wrote:
The problem is that oslo libraries are OpenStack-specific. Imagine
metal3,
for example. When building our images, we can pull (most of) regular
Python
packages from the base OS, but everything with "oslo" in its name is on
us.
It's a maintenance burden.
what distros dont ship oslo libs?
RHEL ships them via the OSP repos
As part of OpenStack, right.
CentOS ship it via RDO Ubunutu has them in the cloud archive SUSE also shiped them via there openstack product although sicne they are nolonger maintaining that goign forward and moveing the k8s based cloud offerings it might be a valid concern there.
All the same here: oslo libs are parts of OpenStack distributions/offerings. Meaning that to install Ironic you need to at least enable OpenStack repositories, even if you package Ironic yourself. ya that is true although i think oslo is also a good candiate for standablone reuse outside of openstack. like placment keystone and ironic are. so in my perfered world i would love to see oslo in the base os repos.
What's preventing that from happening ? What is distro policy around general-purpose but openstack-community-maintained Python libraries like stevedore or tooz ? FWIW in Ubuntu all oslo libraries are packaged as part of the "base OS repos", and therefore indistinguishable from other Python libraries in terms of reuse. The 'cloud archive' is just an additive repository that allows older LTS users to use the most recent OpenStack releases. -- Thierry Carrez (ttx)
On Mon, Apr 6, 2020 at 3:13 PM Thierry Carrez <thierry@openstack.org> wrote:
Sean Mooney wrote:
On Mon, 2020-04-06 at 13:14 +0200, Dmitry Tantsur wrote:
On Mon, Apr 6, 2020 at 1:03 PM Sean Mooney <smooney@redhat.com> wrote:
On Mon, 2020-04-06 at 10:10 +0200, Dmitry Tantsur wrote:
The problem is that oslo libraries are OpenStack-specific. Imagine
metal3,
for example. When building our images, we can pull (most of) regular
Python
packages from the base OS, but everything with "oslo" in its name is on
us.
It's a maintenance burden.
what distros dont ship oslo libs?
RHEL ships them via the OSP repos
As part of OpenStack, right.
CentOS ship it via RDO Ubunutu has them in the cloud archive SUSE also shiped them via there openstack product although sicne they are nolonger maintaining that goign forward and moveing the k8s based cloud offerings it might be a valid concern there.
All the same here: oslo libs are parts of OpenStack distributions/offerings. Meaning that to install Ironic you need to at least enable OpenStack repositories, even if you package Ironic yourself. ya that is true although i think oslo is also a good candiate for standablone reuse outside of openstack. like placment keystone and ironic are. so in my perfered world i would love to see oslo in the base os repos.
What's preventing that from happening ? What is distro policy around general-purpose but openstack-community-maintained Python libraries like stevedore or tooz ?
I don't think such a policy exists. I think it's based on the actual usage by non-OpenStack consumers. I can only speculate what prevents them from using e.g. oslo.config or stevedore. Maybe they see that the source and documentation are hosted on openstack.org and assume they're only for OpenStack or somehow require OpenStack (i.e. same problem)? Maybe it's something that docs.opendev.org/stevedore and opendev.org/stevedore (no openstack) could help fixing? Dmitry
FWIW in Ubuntu all oslo libraries are packaged as part of the "base OS repos", and therefore indistinguishable from other Python libraries in terms of reuse. The 'cloud archive' is just an additive repository that allows older LTS users to use the most recent OpenStack releases.
-- Thierry Carrez (ttx)
On 4/6/20 8:16 AM, Dmitry Tantsur wrote:
On Mon, Apr 6, 2020 at 3:13 PM Thierry Carrez <thierry@openstack.org <mailto:thierry@openstack.org>> wrote:
Sean Mooney wrote: > On Mon, 2020-04-06 at 13:14 +0200, Dmitry Tantsur wrote: >> On Mon, Apr 6, 2020 at 1:03 PM Sean Mooney <smooney@redhat.com <mailto:smooney@redhat.com>> wrote: >> >>> On Mon, 2020-04-06 at 10:10 +0200, Dmitry Tantsur wrote: >>>> The problem is that oslo libraries are OpenStack-specific. Imagine >>> >>> metal3, >>>> for example. When building our images, we can pull (most of) regular >>> >>> Python >>>> packages from the base OS, but everything with "oslo" in its name is on >>> >>> us. >>>> It's a maintenance burden. >>> >>> what distros dont ship oslo libs? >>> >>> RHEL ships them via the OSP repos >>> >> >> As part of OpenStack, right. >> >> >>> CentOS ship it via RDO >>> Ubunutu has them in the cloud archive >>> SUSE also shiped them via there openstack product although sicne they are >>> nolonger >>> maintaining that goign forward and moveing the k8s based cloud offerings >>> it might be >>> a valid concern there. >>> >> >> All the same here: oslo libs are parts of OpenStack >> distributions/offerings. Meaning that to install Ironic you need to at >> least enable OpenStack repositories, even if you package Ironic yourself. > ya that is true although i think oslo is also a good candiate for standablone reuse > outside of openstack. like placment keystone and ironic are. > so in my perfered world i would love to see oslo in the base os repos.
What's preventing that from happening ? What is distro policy around general-purpose but openstack-community-maintained Python libraries like stevedore or tooz ?
I don't think such a policy exists.
I think it's based on the actual usage by non-OpenStack consumers. I can only speculate what prevents them from using e.g. oslo.config or stevedore. Maybe they see that the source and documentation are hosted on openstack.org <http://openstack.org> and assume they're only for OpenStack or somehow require OpenStack (i.e. same problem)?
I want to interject here and mention that the Oslo team actually differentiates between things named oslo* and things not named oslo that are maintained by the Oslo team. The former are for OpenStack-specific logic and are not necessarily designed for broader use. The latter are intended as general purpose libraries to be used outside of OpenStack. This obviously does not help here at all since it just muddies the water about what is and is not "for OpenStack", but I think it's important to note that this is not an either-or question for Oslo.
Maybe it's something that docs.opendev.org/stevedore <http://docs.opendev.org/stevedore> and opendev.org/stevedore <http://opendev.org/stevedore> (no openstack) could help fixing?
Dmitry
FWIW in Ubuntu all oslo libraries are packaged as part of the "base OS repos", and therefore indistinguishable from other Python libraries in terms of reuse. The 'cloud archive' is just an additive repository that allows older LTS users to use the most recent OpenStack releases.
-- Thierry Carrez (ttx)
On Mon, 2020-04-06 at 15:10 +0200, Thierry Carrez wrote:
Sean Mooney wrote:
On Mon, 2020-04-06 at 13:14 +0200, Dmitry Tantsur wrote:
On Mon, Apr 6, 2020 at 1:03 PM Sean Mooney <smooney@redhat.com> wrote:
On Mon, 2020-04-06 at 10:10 +0200, Dmitry Tantsur wrote:
The problem is that oslo libraries are OpenStack-specific. Imagine
metal3,
for example. When building our images, we can pull (most of) regular
Python
packages from the base OS, but everything with "oslo" in its name is on
us.
It's a maintenance burden.
what distros dont ship oslo libs?
RHEL ships them via the OSP repos
As part of OpenStack, right.
CentOS ship it via RDO Ubunutu has them in the cloud archive SUSE also shiped them via there openstack product although sicne they are nolonger maintaining that goign forward and moveing the k8s based cloud offerings it might be a valid concern there.
All the same here: oslo libs are parts of OpenStack distributions/offerings. Meaning that to install Ironic you need to at least enable OpenStack repositories, even if you package Ironic yourself.
ya that is true although i think oslo is also a good candiate for standablone reuse outside of openstack. like placment keystone and ironic are. so in my perfered world i would love to see oslo in the base os repos.
What's preventing that from happening ? What is distro policy around general-purpose but openstack-community-maintained Python libraries like stevedore or tooz ?
FWIW in Ubuntu all oslo libraries are packaged as part of the "base OS repos", and therefore indistinguishable from other Python libraries in terms of reuse. The 'cloud archive' is just an additive repository that allows older LTS users to use the most recent OpenStack releases. i think fedora ships them in the base os too https://src.fedoraproject.org/rpms/python-oslo-config and if im reading this rgiht i think opensuse does too https://build.opensuse.org/repositories/openSUSE:Factory/python-oslo.config
i suspect from a redhat perspective it was just a reflection our org stucture or there may have been a business decision at play. through the use of modules in the new buidl system on rhel8 its perfectly possible for RHEL to provide a version of a package and the openstack product to provide an different version on a different delivery cadence. we do this for libvirt via the advnced virt module but form a technicall perspective i dont think there is fundamentally an issue with that other then manpower and this is how its currently done. RDO certenly is a factor as if we move too packaging them in centos main repos instead of rdo there would have to be some collaberation there to enable it to work smothly. currently tooz and the rest of oslo are deliver as part of the centos cloud sig https://cbs.centos.org/koji/buildinfo?buildID=25866 consuming the output of the rdo project. https://wiki.centos.org/SpecialInterestGroup/Cloud i would expect kubernets/openshift orgin to be part of that too although apparently it is not.
On Apr 6, 2020, at 7:14 AM, Dmitry Tantsur <dtantsur@redhat.com> wrote:
On Mon, Apr 6, 2020 at 1:03 PM Sean Mooney <smooney@redhat.com <mailto:smooney@redhat.com>> wrote: On Mon, 2020-04-06 at 10:10 +0200, Dmitry Tantsur wrote:
The problem is that oslo libraries are OpenStack-specific. Imagine metal3, for example. When building our images, we can pull (most of) regular Python packages from the base OS, but everything with "oslo" in its name is on us. It's a maintenance burden.
what distros dont ship oslo libs?
RHEL ships them via the OSP repos
As part of OpenStack, right.
CentOS ship it via RDO Ubunutu has them in the cloud archive SUSE also shiped them via there openstack product although sicne they are nolonger maintaining that goign forward and moveing the k8s based cloud offerings it might be a valid concern there.
All the same here: oslo libs are parts of OpenStack distributions/offerings. Meaning that to install Ironic you need to at least enable OpenStack repositories, even if you package Ironic yourself.
This issue is internal to Red Hat and our choices in how we manage our resources to package things for distribution. I don’t think moving Ironic out of OpenStack at the community level is going to make the problem go away. Doug
On Apr 6, 2020, at 4:10 AM, Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi,
On Fri, Apr 3, 2020 at 9:35 AM Jean-Philippe Evrard <jean-philippe@evrard.me <mailto:jean-philippe@evrard.me>> wrote:
Also, how is the reliance on oslo a problem? Do you want to use another library in the python ecosystem instead? If true, what about phasing out that part of oslo, so we don't have to maintain it? Just curious.
The problem is that oslo libraries are OpenStack-specific. Imagine metal3, for example. When building our images, we can pull (most of) regular Python packages from the base OS, but everything with "oslo" in its name is on us. It's a maintenance burden.
With absolutely no disrespect meant to the awesome Oslo team, I think the existence of Oslo libraries is a bad sign. I think as a strong FOSS community we shouldn't invest into libraries that are either useful only to us or at least are marketed this way. For example: 1) oslo.config is a fantastic piece of software that the whole python world could benefit from. Same for oslo.service, probably.
I would love to have oslo.config more widely adopted outside of OpenStack. At the same time, it has a very opinionated way of managing config than most applications need, so I can understand why it might not be.
2) oslo.utils as a catch-all repository of utilities should IMO be either moved to existing python projects or decomposed into small generally reusable libraries (essentially, each sub-module could be a library of its own). Same for oslo.concurrency.
When I did the original analysis for breaking oslo-incubator up into separate libraries, I had to balance the work to create and manage individual libraries and their cross-dependencies with the desire to have everything nice and neat. The utils library ended up as a catch all for things that didn’t seem reusable outside of OpenStack so that at a time before all of our release automation was in place the team only had to manage ~30 libraries instead of ~50. Of course that can evolve, if someone feels strongly enough to do the work. It’s certainly easier today than it was back then.
3) I'm genuinely not sure why oslo.log and oslo.i18n exist and which parts of their functionality cannot be moved upstream.
The log library is there to make it simple for all OpenStack services to configure their logging in the same way. It’s glue between oslo.config and Python’s logging module. Similarly, the i18n library is the glue between oslo.config and Python’s gettext module. The hint is in their names. The “oslo" prefix was reserved for libraries that are more likely to be seen as only useful within OpenStack. In a project as large as OpenStack, there’s a fair amount of code that can be reused but that wouldn’t make sense for use in any other code bases. For libraries that we thought would be useful by other communities, we chose more generic names. Doug
On Apr 6, 2020, at 4:10 AM, Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi,
On Fri, Apr 3, 2020 at 9:35 AM Jean-Philippe Evrard <jean-philippe@evrard.me <mailto:jean-philippe@evrard.me>> wrote: Hello,
On Thu, 2020-04-02 at 12:38 +0200, Dmitry Tantsur wrote:
[snip]
Now, I do agree that there are steps that can be taken before we go all nuclear. We can definitely work on our own website, we can reduce reliance on oslo, start releasing independently, and so on. I'm wondering what will be left of our participation in OpenStack in the end. Thierry has suggested the role of the TC in ensuring integration. I'm of the opinion that if all stakeholders in Ironic lose interest in Ironic as part of OpenStack, no power will prevent the integration from slowly falling apart.
I don't see it that way. I see this as an opportunity to make OpenStack more clear, more reachable, more interesting. For me, Ironic, Cinder, Manila (to only name a few), are very good example of datacenter/IaaS software that could be completely independent in their consumption, and additionally released together. For me, the strength of OpenStack was always in the fact it had multiple small projects that work well together, compared to a single big blob of software which does everything. We just didn't bank enough on the standalone IMHO. But I am sure we are aligned there... Wouldn't the next steps be instead to make it easier to consume standalone?
For us one of the problems, as I've mentioned already, is producing releases more often. Now, the point of potential misunderstanding is this: we can (and do) release more often than once in 6 months. These releases, however, do not enjoy the same degree of support as the "blessed" releases, especially when it comes to upgrades and longer-term support.
But that’s not because Ironic is part of OpenStack, right? Nothing stops teams from creating and managing additional branches. The rest of the OpenStack community doesn’t do that, so the Ironic team would have to manage the additional work (creating the branches, supporting them in CI, backports, filing more releases, etc.) but that wouldn’t change if Ironic was not part of OpenStack, would it? If anything, there would be less support because some of the automation we have for OpenStack projects wouldn’t be there to lean on. Doug
At the risk of getting defensive, I do want to make some points relating to Oslo specifically here. TLDR at the bottom if your eyes glaze over at the wall of text. On 4/6/20 3:10 AM, Dmitry Tantsur wrote:
With absolutely no disrespect meant to the awesome Oslo team, I think the existence of Oslo libraries is a bad sign. I think as a strong FOSS community we shouldn't invest into libraries that are either useful only to us or at least are marketed this way. For example:
I think it's relevant to keep in mind that Oslo didn't start out as a collection of libraries, it started out as a bunch of code forklifted from Nova for use by other OpenStack services. It was a significant effort just to get the Nova-isms out of it, much less trying to sanitize everything OpenStack-specific. I also don't think it's fair to characterize Oslo as only focused on OpenStack today. In reality, many of our new libraries since the initial incubator split have been general purpose as often as not. Where they haven't, it's things like oslo.limit that are explicitly dependent on an OpenStack service (Keystone in this case). We believe in being good OSS citizens as much as anyone else. There's also a boil the ocean problem with trying to generalize every solution to every problem. It's a question we ask every time a new library is proposed, but in some cases it just doesn't make sense to write a library for an audience that may or may not exist. And in some cases when such an audience appears, we have refactored libraries to make them more general purpose, while often keeping an OpenStack-specific layer to ease integration with OpenStack services. See oslo.concurrency and fasteners. In fact, that kind of split is a pretty common pattern, even in cases where the underlying library didn't originate in Oslo/OpenStack. Think sqlalchemy/oslo.db, dogpile/oslo.cache, kombu/oslo.messaging. A lot of Oslo is glue code to make it easier to use something in a common way across OpenStack services.
1) oslo.config is a fantastic piece of software that the whole python world could benefit from. Same for oslo.service, probably.
oslo.config is an interesting case because there is definitely interest outside OpenStack thanks to things like the Castellan config backend, but as Doug mentioned oslo.config is heavily opinionated (global config object, anyone?) and that's an issue for a lot of people. I will also point out that the only oslo.* dependency that oslo.config has is oslo.i18n, which itself has no other oslo dependencies, so there's not much barrier to entry to using it standalone today. I would not inflict oslo.service on anyone I liked. :-P Seriously though, I would advocate for using cotyledon if you're looking for a general purpose service library. It's not eventlet-based and provides a lot of the functionality of oslo.service, at least as I understand it. It was also written by an ex-Oslo contributor outside of OpenStack so maybe it's an interesting case study for this discussion. I don't know how much contribution it gets from other sources, but that would be good to look into.
2) oslo.utils as a catch-all repository of utilities should IMO be either moved to existing python projects or decomposed into small generally reusable libraries (essentially, each sub-module could be a library of its own). Same for oslo.concurrency.
oslo.concurrency has already been decomposed into general purpose code (fasteners) and OpenStack-specific, at least for the most part. I'm sure the split isn't perfect, but it's not like we haven't recognized the need for better concurrency libraries in Python as a whole. Note that fasteners also lives outside Oslo in another ex-Osloers personal repo. Again, I'm not sure whether that was beneficial or not but it might be worth reaching out to Mehdi and Josh to see how they feel about it. I would probably -2 any attempt to split oslo.utils. You'd end up with a bunch of single file libraries and a metric ****-ton of administrative overhead. It's bad enough managing 40 some repos as it is. Also, that's another library with minimal cross-dependencies with the rest of Oslo (just oslo.i18n again), which was an intentional design decision to make it relatively painless to pull in.
3) I'm genuinely not sure why oslo.log and oslo.i18n exist and which parts of their functionality cannot be moved upstream.
oslo.log basically provides convenience functions for OpenStack services, which is kind of what the oslo.* libraries should do. It provides built-in support for things like context objects, which are fairly domain-specific and would be difficult to generalize. It also provides a common set of configuration options so each project doesn't have to write their own. We don't need 20 different ways to enable debug logging. :-) oslo.i18n is mostly for lazy translation, which apparently is a thing people still use even though the company pushing for it in the first place no longer cares. We've also had calls to remove it completely because it's finicky and tends to break things if the consuming projects don't follow the best practices with translated strings. So it's in a weird limbo state. I did talk with JP in Shanghai about possibly making it optional because it pulls in a fair amount of translation files which can bloat minimal containers. I looked into it briefly and I think it would be possible, although I don't remember a lot of details because nobody was really pushing for it anymore so it's hard to justify spending a bunch of time on it. TLDR: I think Oslo provides value both in and out of OpenStack (shocking, I know!). I'm sure the separation isn't perfect, but what is? There are some projects that have been split out of it that might be interesting case studies for this discussion if anyone wants to follow up. Not it. ;-) -Ben
After reading this lengthy and enlightening threadI come back to Julia original points. 1. What are the benefits of having Ironic as part of OpenStack vs. having Ironic as part of opendev? a. I do not buy that people will use Ironic more as standalone. Biforst has been created several years back and was available as standalone Ironic. And it is not widely used. b. Ironic is used as underpinning to other projects, like Metal3, Airship. And that is with Ironic being part of OpenStack. Can Ironic be improved for easier use outside OpenStack - absolutely? Having better handling of dependencies, like already mentioned Oslo and python will definitely help. c. Will Ironic be more adapted outside of OpenStack if it part opendev rather than OpenStack? Will be good to have some evidence for it. 2. Does being part of OpenStack slows or impede Ironic growth and adoption? I would argue that being part of OpenDev will provide more opportunities for growth. 3. If Ironic becomes OpenDev project what changes? a. It will still be under the same governance, unless Ironic community want to create its own governances which will take velocity of developing new features. So expect that the current OpenStack governance rules will stay. b. Will the gate and other processes change? Do not think so since the current ones work reasonably well. c. Should Ironic be part of "integrated" openstack release and tested together with rest of openstack? - absolutely. It has a lot of benefit for a openstack community, including all derived distro products. d. Will Ironic change its release cadence if it is no longer part of OpenStack proper? Ironic is only as good as its underlying drivers. That means that all drivers, that are currently outside of OpenStack governance will have to follow. e. Will Ironic change the development platform? It currently use devstack. f. All Ironic documentation follows OpenStack and is part of it. 4. If Ironic leaves OpenStack proper what stops some of the other projects, like Cinder, or Keystone. to leave? That worries me. As it may lead to disintegration of the community and the notion of what OpenStack is. Or it may transition OpenStack to federated model of projects. So after saying all of it, I am leaning toward cleaning up and simplifying dependencies to make it easier to consume Ironic outside OpenStack, at least for Victoria cycle and revisit it at that cycle end. Sorry for long stream of conscious. Arkady
On 2020-04-07 02:03:46 +0000 (+0000), Arkady.Kanevsky@dell.com wrote: [...]
1. What are the benefits of having Ironic as part of OpenStack vs. having Ironic as part of opendev? [...] c. Will Ironic be more adapted outside of OpenStack if it part opendev rather than OpenStack? Will be good to have some evidence for it.
2. Does being part of OpenStack slows or impede Ironic growth and adoption? I would argue that being part of OpenDev will provide more opportunities for growth.
3. If Ironic becomes OpenDev project what changes? [...]
I regret that Dimitry's initial post used a subject which seems to be deepening confusion about OpenDev. Please understand that OpenDev is a project hosting platform and community of collaboration infrastructure sysadmins. What it means for a project to be "part of OpenDev" is that it's a piece of the collaboration infrastructure we're using to support and host open source software projects. Ironic would not be that, nor do I think that's what Dimitry meant. I think what he was trying to convey is that he still wants Ironic to be "hosted in OpenDev" (using OpenDev's Gerrit instance for code review, Zuul for project gating, Mailman for mailing lists, and so on, like OpenStack does), and also for Ironic to apply to become an official Open Infrastructure Project represented by the OSF (like OpenStack already is). Not all projects hosted in OpenDev are OSF Open Infrastructure Projects, and not all OSF Open Infrastructure Projects are hosted in OpenDev. Also the vast majority of projects hosted in OpenDev are not "part of OpenDev." We'll navigate this discussion best if we don't conflate these concepts needlessly. Thanks. -- Jeremy Stanley
Dell Customer Communication - Confidential Thanks Jeremy for this critical clarity. -----Original Message----- From: Jeremy Stanley <fungi@yuggoth.org> Sent: Tuesday, April 7, 2020 12:01 AM To: openstack-discuss@lists.openstack.org Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project? On 2020-04-07 02:03:46 +0000 (+0000), Arkady.Kanevsky@dell.com wrote: [...]
1. What are the benefits of having Ironic as part of OpenStack vs. having Ironic as part of opendev? [...] c. Will Ironic be more adapted outside of OpenStack if it part opendev rather than OpenStack? Will be good to have some evidence for it.
2. Does being part of OpenStack slows or impede Ironic growth and adoption? I would argue that being part of OpenDev will provide more opportunities for growth.
3. If Ironic becomes OpenDev project what changes? [...]
I regret that Dimitry's initial post used a subject which seems to be deepening confusion about OpenDev. Please understand that OpenDev is a project hosting platform and community of collaboration infrastructure sysadmins. What it means for a project to be "part of OpenDev" is that it's a piece of the collaboration infrastructure we're using to support and host open source software projects. Ironic would not be that, nor do I think that's what Dimitry meant. I think what he was trying to convey is that he still wants Ironic to be "hosted in OpenDev" (using OpenDev's Gerrit instance for code review, Zuul for project gating, Mailman for mailing lists, and so on, like OpenStack does), and also for Ironic to apply to become an official Open Infrastructure Project represented by the OSF (like OpenStack already is). Not all projects hosted in OpenDev are OSF Open Infrastructure Projects, and not all OSF Open Infrastructure Projects are hosted in OpenDev. Also the vast majority of projects hosted in OpenDev are not "part of OpenDev." We'll navigate this discussion best if we don't conflate these concepts needlessly. Thanks. -- Jeremy Stanley
Hi, On Tue, Apr 7, 2020 at 4:03 AM <Arkady.Kanevsky@dell.com> wrote:
After reading this lengthy and enlightening threadI come back to Julia original points.
1. What are the benefits of having Ironic as part of OpenStack vs. having Ironic as part of opendev? a. I do not buy that people will use Ironic more as standalone. Biforst has been created several years back and was available as standalone Ironic. And it is not widely used.
It is widely used, just not among big names. Julia and I constantly encounter people using it, as well as just installing ironic standalone themselves or with kolla. And now metal3 is another standalone ironic use case completely unrelated to openstack.
b. Ironic is used as underpinning to other projects, like Metal3, Airship. And that is with Ironic being part of OpenStack. Can Ironic be improved for easier use outside OpenStack - absolutely? Having better handling of dependencies, like already mentioned Oslo and python will definitely help. c. Will Ironic be more adapted outside of OpenStack if it part opendev rather than OpenStack? Will be good to have some evidence for it.
I wish I could see the future :) I can only suggest that people who currently have doubts about OpenStack-specific nature of Ironic would use it. Maybe they wouldn't.
2. Does being part of OpenStack slows or impede Ironic growth and adoption? I would argue that being part of OpenDev will provide more opportunities for growth. 3. If Ironic becomes OpenDev project what changes?
As Jeremy rightly noted, I'm using "OpenDev" in a sense that I wish existed, but doesn't exist currently. In the current reality it would be an OSF project outside of the OpenStack umbrella. And I do apologize for the confusion I caused.
a. It will still be under the same governance, unless Ironic community want to create its own governances which will take velocity of developing new features. So expect that the current OpenStack governance rules will stay.
Please expand your question. The TC would no longer be in charge, the PTL-core structure would probably stay in place.
b. Will the gate and other processes change? Do not think so since the current ones work reasonably well.
Not much or not at all.
c. Should Ironic be part of "integrated" openstack release and tested together with rest of openstack? - absolutely. It has a lot of benefit for a openstack community, including all derived distro products.
Should libvirt be part of the integrated OpenStack release? I think Nova's integration with libvirt is more developed than one with Ironic. Still, I keep hearing that the integration will fall apart if Ironic is no longer under OpenStack. Why is that? Haven't we invented microversions specifically to be able to further decouple service development? That being said, there would be a certain level of release coordination. There would be Ironic deliverables matching a coordinated OpenStack release and supported accordingly.
d. Will Ironic change its release cadence if it is no longer part of OpenStack proper? Ironic is only as good as its underlying drivers. That means that all drivers, that are currently outside of OpenStack governance will have to follow.
It's part of the idea, really. I don't see a problem from the driver's perspective though. I thought the Dell team was actually interested in more frequent releases to be able to deliver driver features more often?
e. Will Ironic change the development platform? It currently use devstack.
We use devstack and bifrost, and we'll keep using them. We may reduce our reliance on devstack in the CI, but, to be clear, it's part of our plans irregardless of the outcome of this discussion.
f. All Ironic documentation follows OpenStack and is part of it.
And this may be one of the perception problems we're seeing. Our standalone documentation feels second-class, examples use Nova and OSC.
4. If Ironic leaves OpenStack proper what stops some of the other projects, like Cinder, or Keystone. to leave? That worries me. As it may lead to disintegration of the community and the notion of what OpenStack is. Or it may transition OpenStack to federated model of projects.
Maybe we may indeed? Maybe if we change OpenStack itself there won't be a need for Ironic (Cinder, Keystone) to leave? It's a great question, thank you for raising it! Dmitry
So after saying all of it, I am leaning toward cleaning up and simplifying dependencies to make it easier to consume Ironic outside OpenStack, at least for Victoria cycle and revisit it at that cycle end.
Sorry for long stream of conscious. Arkady
From: Dmitry Tantsur <dtantsur@redhat.com> Sent: Tuesday, April 7, 2020 5:27 AM To: openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project? [EXTERNAL EMAIL] … 2. Does being part of OpenStack slows or impede Ironic growth and adoption? I would argue that being part of OpenDev will provide more opportunities for growth. 3. If Ironic becomes OpenDev project what changes? As Jeremy rightly noted, I'm using "OpenDev" in a sense that I wish existed, but doesn't exist currently. In the current reality it would be an OSF project outside of the OpenStack umbrella. And I do apologize for the confusion I caused. AK: Now it makes more sense. But that brings new set of questions. There is already Metal3 for Kubernetes. Why not combined them? To be fair Metal3 cannot exist in it current form without Ironic. But exposing each server/switch component to user, forcing them to choose which driver to use and then orchestrate ironic calls, including handling reboots, outtages and so on as Ironic does – is not simple. a. It will still be under the same governance, unless Ironic community want to create its own governances which will take velocity of developing new features. So expect that the current OpenStack governance rules will stay. Please expand your question. The TC would no longer be in charge, the PTL-core structure would probably stay in place. AK: I was assuming we are talking about OpenDev move. That means Ironic project will need its own TC, UC, election process, cadence and all the rest as independent project. If it goes outside OpenStack foundation umbrella it is still need to be handled which is a lot of overhead for little gain. b. Will the gate and other processes change? Do not think so since the current ones work reasonably well. Not much or not at all. c. Should Ironic be part of "integrated" openstack release and tested together with rest of openstack? - absolutely. It has a lot of benefit for a openstack community, including all derived distro products. Should libvirt be part of the integrated OpenStack release? I think Nova's integration with libvirt is more developed than one with Ironic. Still, I keep hearing that the integration will fall apart if Ironic is no longer under OpenStack. Why is that? Haven't we invented microversions specifically to be able to further decouple service development? That being said, there would be a certain level of release coordination. There would be Ironic deliverables matching a coordinated OpenStack release and supported accordingly. AK: well stated. d. Will Ironic change its release cadence if it is no longer part of OpenStack proper? Ironic is only as good as its underlying drivers. That means that all drivers, that are currently outside of OpenStack governance will have to follow. It's part of the idea, really. I don't see a problem from the driver's perspective though. I thought the Dell team was actually interested in more frequent releases to be able to deliver driver features more often? AK: Dell will be interested in more often driver releases including community ones. But that can be done with current model. e. Will Ironic change the development platform? It currently use devstack. We use devstack and bifrost, and we'll keep using them. We may reduce our reliance on devstack in the CI, but, to be clear, it's part of our plans irregardless of the outcome of this discussion. f. All Ironic documentation follows OpenStack and is part of it. And this may be one of the perception problems we're seeing. Our standalone documentation feels second-class, examples use Nova and OSC. AK: that can be solved by having separate entry point for Ironic documentation. 4. If Ironic leaves OpenStack proper what stops some of the other projects, like Cinder, or Keystone. to leave? That worries me. As it may lead to disintegration of the community and the notion of what OpenStack is. Or it may transition OpenStack to federated model of projects. Maybe we may indeed? Maybe if we change OpenStack itself there won't be a need for Ironic (Cinder, Keystone) to leave? It's a great question, thank you for raising it! AK: Dmitry can you elaborate on it? What changes will help Ironic and other projects to stay in OpenStack? Dmitry So after saying all of it, I am leaning toward cleaning up and simplifying dependencies to make it easier to consume Ironic outside OpenStack, at least for Victoria cycle and revisit it at that cycle end. Sorry for long stream of conscious. Arkady
Hi, On Tue, Apr 7, 2020 at 11:26 PM <Arkady.Kanevsky@dell.com> wrote:
*From:* Dmitry Tantsur <dtantsur@redhat.com> *Sent:* Tuesday, April 7, 2020 5:27 AM *To:* openstack-discuss *Subject:* Re: [tc] [ironic] Promoting ironic to a top-level opendev project?
[EXTERNAL EMAIL]
…
2. Does being part of OpenStack slows or impede Ironic growth and adoption? I would argue that being part of OpenDev will provide more opportunities for growth. 3. If Ironic becomes OpenDev project what changes?
As Jeremy rightly noted, I'm using "OpenDev" in a sense that I wish existed, but doesn't exist currently. In the current reality it would be an OSF project outside of the OpenStack umbrella.
And I do apologize for the confusion I caused.
AK: Now it makes more sense. But that brings new set of questions. There is already Metal3 for Kubernetes. Why not combined them? To be fair Metal3 cannot exist in it current form without Ironic. But exposing each server/switch component to user, forcing them to choose which driver to use and then orchestrate ironic calls, including handling reboots, outtages and so on as Ironic does – is not simple.
Sorry, I don't quite get your point. Combine what with what? Metal3 can potentially exist without Ironic, although I don't find it's a reasonable idea to try swapping the backend at this stage.
a. It will still be under the same governance, unless Ironic community want to create its own governances which will take velocity of developing new features. So expect that the current OpenStack governance rules will stay.
Please expand your question. The TC would no longer be in charge, the PTL-core structure would probably stay in place.
AK: I was assuming we are talking about OpenDev move. That means Ironic project will need its own TC, UC, election process, cadence and all the rest as independent project. If it goes outside OpenStack foundation umbrella it is still need to be handled which is a lot of overhead for little gain.
I don't think an independent Ironic would need a TC and UC. I'm even sceptical about PTL, but that's a whole different discussion. I do agree that the separation would involve more bureaucracy that we're successfully avoiding now.
b. Will the gate and other processes change? Do not think so since the current ones work reasonably well.
Not much or not at all.
c. Should Ironic be part of "integrated" openstack release and tested together with rest of openstack? - absolutely. It has a lot of benefit for a openstack community, including all derived distro products.
Should libvirt be part of the integrated OpenStack release? I think Nova's integration with libvirt is more developed than one with Ironic. Still, I keep hearing that the integration will fall apart if Ironic is no longer under OpenStack. Why is that? Haven't we invented microversions specifically to be able to further decouple service development?
That being said, there would be a certain level of release coordination. There would be Ironic deliverables matching a coordinated OpenStack release and supported accordingly.
AK: well stated.
d. Will Ironic change its release cadence if it is no longer part of OpenStack proper? Ironic is only as good as its underlying drivers. That means that all drivers, that are currently outside of OpenStack governance will have to follow.
It's part of the idea, really. I don't see a problem from the driver's perspective though. I thought the Dell team was actually interested in more frequent releases to be able to deliver driver features more often?
AK: Dell will be interested in more often driver releases including community ones. But that can be done with current model.
e. Will Ironic change the development platform? It currently use devstack.
We use devstack and bifrost, and we'll keep using them. We may reduce our reliance on devstack in the CI, but, to be clear, it's part of our plans irregardless of the outcome of this discussion.
f. All Ironic documentation follows OpenStack and is part of it.
And this may be one of the perception problems we're seeing. Our standalone documentation feels second-class, examples use Nova and OSC.
AK: that can be solved by having separate entry point for Ironic documentation.
4. If Ironic leaves OpenStack proper what stops some of the other projects, like Cinder, or Keystone. to leave? That worries me. As it may lead to disintegration of the community and the notion of what OpenStack is. Or it may transition OpenStack to federated model of projects.
Maybe we may indeed? Maybe if we change OpenStack itself there won't be a need for Ironic (Cinder, Keystone) to leave? It's a great question, thank you for raising it!
AK: Dmitry can you elaborate on it? What changes will help Ironic and other projects to stay in OpenStack?
I'm referring to treating OpenStack as a more federated model of projects. Which it sort of is, it's just not entirely obvious from our positioning. But that's probably diverging from the original thread. I don't think "what if Cinder also leaves" is a valid argument against the separation of Ironic. Dmitry
Dmitry
So after saying all of it, I am leaning toward cleaning up and simplifying dependencies to make it easier to consume Ironic outside OpenStack, at least for Victoria cycle and revisit it at that cycle end.
Sorry for long stream of conscious. Arkady
Thanks Dmitry. Having Ironic elevated and have Ironic to be used independently from other parts of OpenStack makes perfect sense. With better marketing and position will definitely help. Still not clear what is the best place for Ironic to be if outside OpenStack foundation. Thanks, From: Dmitry Tantsur <dtantsur@redhat.com> Sent: Wednesday, April 8, 2020 3:10 AM To: openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project? [EXTERNAL EMAIL] Hi, On Tue, Apr 7, 2020 at 11:26 PM <Arkady.Kanevsky@dell.com<mailto:Arkady.Kanevsky@dell.com>> wrote: From: Dmitry Tantsur <dtantsur@redhat.com<mailto:dtantsur@redhat.com>> Sent: Tuesday, April 7, 2020 5:27 AM To: openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project? [EXTERNAL EMAIL] … 2. Does being part of OpenStack slows or impede Ironic growth and adoption? I would argue that being part of OpenDev will provide more opportunities for growth. 3. If Ironic becomes OpenDev project what changes? As Jeremy rightly noted, I'm using "OpenDev" in a sense that I wish existed, but doesn't exist currently. In the current reality it would be an OSF project outside of the OpenStack umbrella. And I do apologize for the confusion I caused. AK: Now it makes more sense. But that brings new set of questions. There is already Metal3 for Kubernetes. Why not combined them? To be fair Metal3 cannot exist in it current form without Ironic. But exposing each server/switch component to user, forcing them to choose which driver to use and then orchestrate ironic calls, including handling reboots, outtages and so on as Ironic does – is not simple. Sorry, I don't quite get your point. Combine what with what? Metal3 can potentially exist without Ironic, although I don't find it's a reasonable idea to try swapping the backend at this stage. a. It will still be under the same governance, unless Ironic community want to create its own governances which will take velocity of developing new features. So expect that the current OpenStack governance rules will stay. Please expand your question. The TC would no longer be in charge, the PTL-core structure would probably stay in place. AK: I was assuming we are talking about OpenDev move. That means Ironic project will need its own TC, UC, election process, cadence and all the rest as independent project. If it goes outside OpenStack foundation umbrella it is still need to be handled which is a lot of overhead for little gain. I don't think an independent Ironic would need a TC and UC. I'm even sceptical about PTL, but that's a whole different discussion. I do agree that the separation would involve more bureaucracy that we're successfully avoiding now. b. Will the gate and other processes change? Do not think so since the current ones work reasonably well. Not much or not at all. c. Should Ironic be part of "integrated" openstack release and tested together with rest of openstack? - absolutely. It has a lot of benefit for a openstack community, including all derived distro products. Should libvirt be part of the integrated OpenStack release? I think Nova's integration with libvirt is more developed than one with Ironic. Still, I keep hearing that the integration will fall apart if Ironic is no longer under OpenStack. Why is that? Haven't we invented microversions specifically to be able to further decouple service development? That being said, there would be a certain level of release coordination. There would be Ironic deliverables matching a coordinated OpenStack release and supported accordingly. AK: well stated. d. Will Ironic change its release cadence if it is no longer part of OpenStack proper? Ironic is only as good as its underlying drivers. That means that all drivers, that are currently outside of OpenStack governance will have to follow. It's part of the idea, really. I don't see a problem from the driver's perspective though. I thought the Dell team was actually interested in more frequent releases to be able to deliver driver features more often? AK: Dell will be interested in more often driver releases including community ones. But that can be done with current model. e. Will Ironic change the development platform? It currently use devstack. We use devstack and bifrost, and we'll keep using them. We may reduce our reliance on devstack in the CI, but, to be clear, it's part of our plans irregardless of the outcome of this discussion. f. All Ironic documentation follows OpenStack and is part of it. And this may be one of the perception problems we're seeing. Our standalone documentation feels second-class, examples use Nova and OSC. AK: that can be solved by having separate entry point for Ironic documentation. 4. If Ironic leaves OpenStack proper what stops some of the other projects, like Cinder, or Keystone. to leave? That worries me. As it may lead to disintegration of the community and the notion of what OpenStack is. Or it may transition OpenStack to federated model of projects. Maybe we may indeed? Maybe if we change OpenStack itself there won't be a need for Ironic (Cinder, Keystone) to leave? It's a great question, thank you for raising it! AK: Dmitry can you elaborate on it? What changes will help Ironic and other projects to stay in OpenStack? I'm referring to treating OpenStack as a more federated model of projects. Which it sort of is, it's just not entirely obvious from our positioning. But that's probably diverging from the original thread. I don't think "what if Cinder also leaves" is a valid argument against the separation of Ironic. Dmitry Dmitry So after saying all of it, I am leaning toward cleaning up and simplifying dependencies to make it easier to consume Ironic outside OpenStack, at least for Victoria cycle and revisit it at that cycle end. Sorry for long stream of conscious. Arkady
Jumping back into the thread after taking a few days off last week and disconnecting. On Tue, Apr 7, 2020 at 3:34 AM Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi,
On Tue, Apr 7, 2020 at 4:03 AM <Arkady.Kanevsky@dell.com> wrote:
After reading this lengthy and enlightening threadI come back to Julia original points.
1. What are the benefits of having Ironic as part of OpenStack vs. having Ironic as part of opendev? a. I do not buy that people will use Ironic more as standalone. Biforst has been created several years back and was available as standalone Ironic. And it is not widely used.
It is widely used, just not among big names. Julia and I constantly encounter people using it, as well as just installing ironic standalone themselves or with kolla. And now metal3 is another standalone ironic use case completely unrelated to openstack.
This and worse. Big names use it, but don't like to publicly talk about it. Or they use it in fixed process areas. Somewhere along the way, we stopped encouraging operators/deployers to really talk about their lives and the way they achieve their work. The result is FAR less visibility of their use, and a fast track to perception of non-use. What we need as a community is actual data collection and statistics that are not an opt-in poll. I know that seems antithetical to OpenStack's culture, but perhaps a separate website might be able to help drive that. Another, possibly silly question, are there metrics available for the logs of docs.openstack.org ? [trim]
b. Will the gate and other processes change? Do not think so since the current ones work reasonably well.
Not much or not at all.
And also, Ironic is largely on the consumption side of other projects for integration point testing. Changes outside our control can break the Ironic's gate because there is no cross-gating with the way things have structurally resulted and evolved over the years. Sometimes we've been able to get breaking changes in other projects reverted quickly, but getting forward moving fixes has always been an uphill battle because the perception of other projects and areas is that it works for them. [trim]
d. Will Ironic change its release cadence if it is no longer part of OpenStack proper? Ironic is only as good as its underlying drivers. That means that all drivers, that are currently outside of OpenStack governance will have to follow.
In-tree drivers are subject to governance and release processes at present. Which is why our stable branch cut is when we release for the cycle. Also because we're not able to otherwise create the branch without a tag and we don't get beta releases. (Those who hack on the releases repo scripting, please feel free to correct me!) What is not subject to governance is vendor specific API client libraries. [trim]
On Mon, Apr 13, 2020, at 1:30 PM, Julia Kreger wrote:
Jumping back into the thread after taking a few days off last week and disconnecting.
On Tue, Apr 7, 2020 at 3:34 AM Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi,
On Tue, Apr 7, 2020 at 4:03 AM <Arkady.Kanevsky@dell.com> wrote:
After reading this lengthy and enlightening threadI come back to Julia original points.
1. What are the benefits of having Ironic as part of OpenStack vs. having Ironic as part of opendev? a. I do not buy that people will use Ironic more as standalone. Biforst has been created several years back and was available as standalone Ironic. And it is not widely used.
It is widely used, just not among big names. Julia and I constantly encounter people using it, as well as just installing ironic standalone themselves or with kolla. And now metal3 is another standalone ironic use case completely unrelated to openstack.
This and worse. Big names use it, but don't like to publicly talk about it. Or they use it in fixed process areas. Somewhere along the way, we stopped encouraging operators/deployers to really talk about their lives and the way they achieve their work. The result is FAR less visibility of their use, and a fast track to perception of non-use. What we need as a community is actual data collection and statistics that are not an opt-in poll. I know that seems antithetical to OpenStack's culture, but perhaps a separate website might be able to help drive that.
Another, possibly silly question, are there metrics available for the logs of docs.openstack.org ?
There are! We've started publishing goaccess reports without personal data for OpenDev's websites hosted off of AFS. Each day we run a job for docs.openstack.org logs, https://zuul.openstack.org/builds?job_name=docs-openstack-goaccess-report#, the zuul build for that job has a goaccess report link which takes you to that day's logs: https://1712df26976563daaa68-1d1d80315f13535a7a11e7a3d54723f4.ssl.cf5.rackcd... These jobs should process all currently available logs and they are on a rotation so we get a snapshot over time. This was in part driven to replace some of the 404 url reporting we had in the past, but does a bit more and could potentially be expanded to do even more. Also, I think docs.openstack.org might have a google analytics setup but I don't know who manage that these days.
[trim]
b. Will the gate and other processes change? Do not think so since the current ones work reasonably well.
Not much or not at all.
And also, Ironic is largely on the consumption side of other projects for integration point testing. Changes outside our control can break the Ironic's gate because there is no cross-gating with the way things have structurally resulted and evolved over the years. Sometimes we've been able to get breaking changes in other projects reverted quickly, but getting forward moving fixes has always been an uphill battle because the perception of other projects and areas is that it works for them.
It should be noted that the CI system doesn't prevent you from cross gating. We have the technical tools necessary to avoid the bulk of these issues.
[trim]
d. Will Ironic change its release cadence if it is no longer part of OpenStack proper? Ironic is only as good as its underlying drivers. That means that all drivers, that are currently outside of OpenStack governance will have to follow.
In-tree drivers are subject to governance and release processes at present. Which is why our stable branch cut is when we release for the cycle. Also because we're not able to otherwise create the branch without a tag and we don't get beta releases. (Those who hack on the releases repo scripting, please feel free to correct me!)
What is not subject to governance is vendor specific API client libraries.
[trim]
On Mon, Apr 13, 2020 at 1:58 PM Clark Boylan <cboylan@sapwetik.org> wrote:
On Mon, Apr 13, 2020, at 1:30 PM, Julia Kreger wrote:
Jumping back into the thread after taking a few days off last week and disconnecting.
On Tue, Apr 7, 2020 at 3:34 AM Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi,
On Tue, Apr 7, 2020 at 4:03 AM <Arkady.Kanevsky@dell.com> wrote:
After reading this lengthy and enlightening threadI come back to Julia original points.
1. What are the benefits of having Ironic as part of OpenStack vs. having Ironic as part of opendev? a. I do not buy that people will use Ironic more as standalone. Biforst has been created several years back and was available as standalone Ironic. And it is not widely used.
It is widely used, just not among big names. Julia and I constantly encounter people using it, as well as just installing ironic standalone themselves or with kolla. And now metal3 is another standalone ironic use case completely unrelated to openstack.
This and worse. Big names use it, but don't like to publicly talk about it. Or they use it in fixed process areas. Somewhere along the way, we stopped encouraging operators/deployers to really talk about their lives and the way they achieve their work. The result is FAR less visibility of their use, and a fast track to perception of non-use. What we need as a community is actual data collection and statistics that are not an opt-in poll. I know that seems antithetical to OpenStack's culture, but perhaps a separate website might be able to help drive that.
Another, possibly silly question, are there metrics available for the logs of docs.openstack.org ?
There are! We've started publishing goaccess reports without personal data for OpenDev's websites hosted off of AFS. Each day we run a job for docs.openstack.org logs, https://zuul.openstack.org/builds?job_name=docs-openstack-goaccess-report#, the zuul build for that job has a goaccess report link which takes you to that day's logs: https://1712df26976563daaa68-1d1d80315f13535a7a11e7a3d54723f4.ssl.cf5.rackcd...
These jobs should process all currently available logs and they are on a rotation so we get a snapshot over time. This was in part driven to replace some of the 404 url reporting we had in the past, but does a bit more and could potentially be expanded to do even more.
Also, I think docs.openstack.org might have a google analytics setup but I don't know who manage that these days.
This is awesome Clark! Thanks!
[trim]
b. Will the gate and other processes change? Do not think so since the current ones work reasonably well.
Not much or not at all.
And also, Ironic is largely on the consumption side of other projects for integration point testing. Changes outside our control can break the Ironic's gate because there is no cross-gating with the way things have structurally resulted and evolved over the years. Sometimes we've been able to get breaking changes in other projects reverted quickly, but getting forward moving fixes has always been an uphill battle because the perception of other projects and areas is that it works for them.
It should be noted that the CI system doesn't prevent you from cross gating. We have the technical tools necessary to avoid the bulk of these issues.
[trim]
d. Will Ironic change its release cadence if it is no longer part of OpenStack proper? Ironic is only as good as its underlying drivers. That means that all drivers, that are currently outside of OpenStack governance will have to follow.
In-tree drivers are subject to governance and release processes at present. Which is why our stable branch cut is when we release for the cycle. Also because we're not able to otherwise create the branch without a tag and we don't get beta releases. (Those who hack on the releases repo scripting, please feel free to correct me!)
What is not subject to governance is vendor specific API client libraries.
[trim]
This is really cool data. Thanks Boylan. DO we have some statistics what pages and code repots visited? -----Original Message----- From: Clark Boylan <cboylan@sapwetik.org> Sent: Monday, April 13, 2020 3:54 PM To: openstack-discuss@lists.openstack.org Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project? [EXTERNAL EMAIL] On Mon, Apr 13, 2020, at 1:30 PM, Julia Kreger wrote:
Jumping back into the thread after taking a few days off last week and disconnecting.
On Tue, Apr 7, 2020 at 3:34 AM Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi,
On Tue, Apr 7, 2020 at 4:03 AM <Arkady.Kanevsky@dell.com> wrote:
After reading this lengthy and enlightening threadI come back to Julia original points.
1. What are the benefits of having Ironic as part of OpenStack vs. having Ironic as part of opendev? a. I do not buy that people will use Ironic more as standalone. Biforst has been created several years back and was available as standalone Ironic. And it is not widely used.
It is widely used, just not among big names. Julia and I constantly encounter people using it, as well as just installing ironic standalone themselves or with kolla. And now metal3 is another standalone ironic use case completely unrelated to openstack.
This and worse. Big names use it, but don't like to publicly talk about it. Or they use it in fixed process areas. Somewhere along the way, we stopped encouraging operators/deployers to really talk about their lives and the way they achieve their work. The result is FAR less visibility of their use, and a fast track to perception of non-use. What we need as a community is actual data collection and statistics that are not an opt-in poll. I know that seems antithetical to OpenStack's culture, but perhaps a separate website might be able to help drive that.
Another, possibly silly question, are there metrics available for the logs of docs.openstack.org ?
There are! We've started publishing goaccess reports without personal data for OpenDev's websites hosted off of AFS. Each day we run a job for docs.openstack.org logs, https://zuul.openstack.org/builds?job_name=docs-openstack-goaccess-report#, the zuul build for that job has a goaccess report link which takes you to that day's logs: https://1712df26976563daaa68-1d1d80315f13535a7a11e7a3d54723f4.ssl.cf5.rackcd... These jobs should process all currently available logs and they are on a rotation so we get a snapshot over time. This was in part driven to replace some of the 404 url reporting we had in the past, but does a bit more and could potentially be expanded to do even more. Also, I think docs.openstack.org might have a google analytics setup but I don't know who manage that these days.
[trim]
b. Will the gate and other processes change? Do not think so since the current ones work reasonably well.
Not much or not at all.
And also, Ironic is largely on the consumption side of other projects for integration point testing. Changes outside our control can break the Ironic's gate because there is no cross-gating with the way things have structurally resulted and evolved over the years. Sometimes we've been able to get breaking changes in other projects reverted quickly, but getting forward moving fixes has always been an uphill battle because the perception of other projects and areas is that it works for them.
It should be noted that the CI system doesn't prevent you from cross gating. We have the technical tools necessary to avoid the bulk of these issues.
[trim]
d. Will Ironic change its release cadence if it is no longer part of OpenStack proper? Ironic is only as good as its underlying drivers. That means that all drivers, that are currently outside of OpenStack governance will have to follow.
In-tree drivers are subject to governance and release processes at present. Which is why our stable branch cut is when we release for the cycle. Also because we're not able to otherwise create the branch without a tag and we don't get beta releases. (Those who hack on the releases repo scripting, please feel free to correct me!)
What is not subject to governance is vendor specific API client libraries.
[trim]
On 4/13/20 13:30, Julia Kreger wrote:
Jumping back into the thread after taking a few days off last week and disconnecting.
On Tue, Apr 7, 2020 at 3:34 AM Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi,
On Tue, Apr 7, 2020 at 4:03 AM <Arkady.Kanevsky@dell.com> wrote:
After reading this lengthy and enlightening threadI come back to Julia original points.
1. What are the benefits of having Ironic as part of OpenStack vs. having Ironic as part of opendev? a. I do not buy that people will use Ironic more as standalone. Biforst has been created several years back and was available as standalone Ironic. And it is not widely used.
It is widely used, just not among big names. Julia and I constantly encounter people using it, as well as just installing ironic standalone themselves or with kolla. And now metal3 is another standalone ironic use case completely unrelated to openstack.
This and worse. Big names use it, but don't like to publicly talk about it. Or they use it in fixed process areas. Somewhere along the way, we stopped encouraging operators/deployers to really talk about their lives and the way they achieve their work. The result is FAR less visibility of their use, and a fast track to perception of non-use.
I have noticed this and found it interesting as well. Recently, I was trying to identify some examples of people using standalone Ironic because someone at work had asked me about it. I had a difficult time finding anything definitive even though I knew it's probably used at least a fair bit. I went to the Metal3 website because I was pretty sure it uses Ironic but even there is says, "There are a number of great open source tools for bare metal host provisioning, including Ironic. Metal3.io aims to build on these ..." Through the use of the word "aims" I wasn't totally sure whether it uses Ironic or is just "inspired by" it. However, this article makes it clear that it does in fact use it: https://thenewstack.io/metal3-uses-openstacks-ironic-for-declarative-bare-me... I know CERN uses Ironic but not sure if standalone. I haven't seen that detail mentioned. I don't know if the obscurity of standalone Ironic is intentional or if it's just because it's an "implementation detail" that people don't think to mention. Either way, it makes it tough when someone is interested and you're trying to find them some examples to check out. Is this related to it being "OpenStack" vs not? I'm skeptical, but maybe I'm wrong. I agree with what's been said before that it seems like the main thing that could help is giving it its own website (that is not OpenStack branded) that clearly shows and features the standalone deployment. Will that encourage systems that build upon it and people who use it to explicitly mention standalone Ironic as a component? I can't guess. -melanie <snip>
melanie witt wrote:
[...] I don't know if the obscurity of standalone Ironic is intentional or if it's just because it's an "implementation detail" that people don't think to mention. Either way, it makes it tough when someone is interested and you're trying to find them some examples to check out.
I don't think it's intentional, but it's a side-effect of only presenting Ironic in an openstack context (openstack.org, docs.openstack.org, Open Infra Summit...) Technically it is an implementation detail. But as long as we say "Ironic is bare metal for OpenStack, it can also be used standalone" instead of "Ironic does bare metal provisioning, it can integrate with OpenStack", I suspect the standalone case will remain obscure.
Is this related to it being "OpenStack" vs not? I'm skeptical, but maybe I'm wrong.
I'm also skeptical that this is a governance issue. I bet nobody checks the governance of the project to determine if it can be used standalone. We do however have systems in place that can make the life of a "can-be-used-standalone" project more difficult than it should be. The solution IMHO is not to jump the ship, but to identify and fix those systems. Other OpenStack components will be able to benefit from it. -- Thierry Carrez (ttx)
Agree. We need more visibility into users and their use cases. -----Original Message----- From: Julia Kreger <juliaashleykreger@gmail.com> Sent: Monday, April 13, 2020 3:31 PM To: Dmitry Tantsur Cc: openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project? [EXTERNAL EMAIL] Jumping back into the thread after taking a few days off last week and disconnecting. On Tue, Apr 7, 2020 at 3:34 AM Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi,
On Tue, Apr 7, 2020 at 4:03 AM <Arkady.Kanevsky@dell.com> wrote:
After reading this lengthy and enlightening threadI come back to Julia original points.
1. What are the benefits of having Ironic as part of OpenStack vs. having Ironic as part of opendev? a. I do not buy that people will use Ironic more as standalone. Biforst has been created several years back and was available as standalone Ironic. And it is not widely used.
It is widely used, just not among big names. Julia and I constantly encounter people using it, as well as just installing ironic standalone themselves or with kolla. And now metal3 is another standalone ironic use case completely unrelated to openstack.
This and worse. Big names use it, but don't like to publicly talk about it. Or they use it in fixed process areas. Somewhere along the way, we stopped encouraging operators/deployers to really talk about their lives and the way they achieve their work. The result is FAR less visibility of their use, and a fast track to perception of non-use. What we need as a community is actual data collection and statistics that are not an opt-in poll. I know that seems antithetical to OpenStack's culture, but perhaps a separate website might be able to help drive that. Another, possibly silly question, are there metrics available for the logs of docs.openstack.org ? [trim]
b. Will the gate and other processes change? Do not think so since the current ones work reasonably well.
Not much or not at all.
And also, Ironic is largely on the consumption side of other projects for integration point testing. Changes outside our control can break the Ironic's gate because there is no cross-gating with the way things have structurally resulted and evolved over the years. Sometimes we've been able to get breaking changes in other projects reverted quickly, but getting forward moving fixes has always been an uphill battle because the perception of other projects and areas is that it works for them. [trim]
d. Will Ironic change its release cadence if it is no longer part of OpenStack proper? Ironic is only as good as its underlying drivers. That means that all drivers, that are currently outside of OpenStack governance will have to follow.
In-tree drivers are subject to governance and release processes at present. Which is why our stable branch cut is when we release for the cycle. Also because we're not able to otherwise create the branch without a tag and we don't get beta releases. (Those who hack on the releases repo scripting, please feel free to correct me!) What is not subject to governance is vendor specific API client libraries. [trim]
Hi all, I am not sure if it is relevant here, but we are trying to use ironic to boot not only servers but some other HW (which are included into big projects which are used by big companies all across the world to provide services) to add it into our machinery in a controlled CI environment. Also, I think we will use the stack to provision OSP and I have an expectation to take over CaaS with Zul ?) Also we are going to provision all HW (as mentioned before, not only servers but a bit more) of our equipment using ironic. On Tue, 14 Apr 2020 at 04:25, <Arkady.Kanevsky@dell.com> wrote:
Agree. We need more visibility into users and their use cases.
-----Original Message----- From: Julia Kreger <juliaashleykreger@gmail.com> Sent: Monday, April 13, 2020 3:31 PM To: Dmitry Tantsur Cc: openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project?
[EXTERNAL EMAIL]
Jumping back into the thread after taking a few days off last week and disconnecting.
On Tue, Apr 7, 2020 at 3:34 AM Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi,
On Tue, Apr 7, 2020 at 4:03 AM <Arkady.Kanevsky@dell.com> wrote:
After reading this lengthy and enlightening threadI come back to Julia
1. What are the benefits of having Ironic as part of OpenStack vs.
having Ironic as part of opendev?
a. I do not buy that people will use Ironic more as standalone. Biforst has been created several years back and was available as standalone Ironic. And it is not widely used.
It is widely used, just not among big names. Julia and I constantly encounter people using it, as well as just installing ironic standalone
original points. themselves or with kolla. And now metal3 is another standalone ironic use case completely unrelated to openstack.
This and worse. Big names use it, but don't like to publicly talk about it. Or they use it in fixed process areas. Somewhere along the way, we stopped encouraging operators/deployers to really talk about their lives and the way they achieve their work. The result is FAR less visibility of their use, and a fast track to perception of non-use. What we need as a community is actual data collection and statistics that are not an opt-in poll. I know that seems antithetical to OpenStack's culture, but perhaps a separate website might be able to help drive that.
Another, possibly silly question, are there metrics available for the logs of docs.openstack.org ?
[trim]
b. Will the gate and other processes change? Do not think so since the
current ones work reasonably well.
Not much or not at all.
And also, Ironic is largely on the consumption side of other projects for integration point testing. Changes outside our control can break the Ironic's gate because there is no cross-gating with the way things have structurally resulted and evolved over the years. Sometimes we've been able to get breaking changes in other projects reverted quickly, but getting forward moving fixes has always been an uphill battle because the perception of other projects and areas is that it works for them.
[trim]
d. Will Ironic change its release cadence if it is no longer part of
OpenStack proper? Ironic is only as good as its underlying drivers. That means that all drivers, that are currently outside of OpenStack governance will have to follow.
In-tree drivers are subject to governance and release processes at present. Which is why our stable branch cut is when we release for the cycle. Also because we're not able to otherwise create the branch without a tag and we don't get beta releases. (Those who hack on the releases repo scripting, please feel free to correct me!)
What is not subject to governance is vendor specific API client libraries.
[trim]
-- Ruslanas Gžibovskis +370 6030 7030
Hi, On Mon, Apr 6, 2020 at 11:06 PM Ben Nemec <openstack@nemebean.com> wrote:
At the risk of getting defensive, I do want to make some points relating to Oslo specifically here.
I really do hope nothing I've said comes as offensive to the Oslo team. I'm not blaming you, we're all in this together :)
TLDR at the bottom if your eyes glaze over at the wall of text.
On 4/6/20 3:10 AM, Dmitry Tantsur wrote:
With absolutely no disrespect meant to the awesome Oslo team, I think the existence of Oslo libraries is a bad sign. I think as a strong FOSS community we shouldn't invest into libraries that are either useful only to us or at least are marketed this way. For example:
I think it's relevant to keep in mind that Oslo didn't start out as a collection of libraries, it started out as a bunch of code forklifted from Nova for use by other OpenStack services. It was a significant effort just to get the Nova-isms out of it, much less trying to sanitize everything OpenStack-specific.
I also don't think it's fair to characterize Oslo as only focused on OpenStack today. In reality, many of our new libraries since the initial incubator split have been general purpose as often as not. Where they haven't, it's things like oslo.limit that are explicitly dependent on an OpenStack service (Keystone in this case). We believe in being good OSS citizens as much as anyone else.
There's also a boil the ocean problem with trying to generalize every solution to every problem. It's a question we ask every time a new library is proposed, but in some cases it just doesn't make sense to write a library for an audience that may or may not exist. And in some cases when such an audience appears, we have refactored libraries to make them more general purpose, while often keeping an OpenStack-specific layer to ease integration with OpenStack services. See oslo.concurrency and fasteners.
In fact, that kind of split is a pretty common pattern, even in cases where the underlying library didn't originate in Oslo/OpenStack. Think sqlalchemy/oslo.db, dogpile/oslo.cache, kombu/oslo.messaging. A lot of Oslo is glue code to make it easier to use something in a common way across OpenStack services.
1) oslo.config is a fantastic piece of software that the whole python world could benefit from. Same for oslo.service, probably.
oslo.config is an interesting case because there is definitely interest outside OpenStack thanks to things like the Castellan config backend, but as Doug mentioned oslo.config is heavily opinionated (global config object, anyone?) and that's an issue for a lot of people. I will also point out that the only oslo.* dependency that oslo.config has is oslo.i18n, which itself has no other oslo dependencies, so there's not much barrier to entry to using it standalone today.
oslo.config currently pulls in 16 dependencies to a clean venv, including oslo.18n, Babel (why?) and requests (WHY?).
I would not inflict oslo.service on anyone I liked. :-P
So, you don't like us? :-P
Seriously though, I would advocate for using cotyledon if you're looking for a general purpose service library. It's not eventlet-based and provides a lot of the functionality of oslo.service, at least as I understand it. It was also written by an ex-Oslo contributor outside of OpenStack so maybe it's an interesting case study for this discussion. I don't know how much contribution it gets from other sources, but that would be good to look into.
Good to know, thanks!
2) oslo.utils as a catch-all repository of utilities should IMO be either moved to existing python projects or decomposed into small generally reusable libraries (essentially, each sub-module could be a library of its own). Same for oslo.concurrency.
oslo.concurrency has already been decomposed into general purpose code (fasteners) and OpenStack-specific, at least for the most part. I'm sure the split isn't perfect, but it's not like we haven't recognized the need for better concurrency libraries in Python as a whole. Note that fasteners also lives outside Oslo in another ex-Osloers personal repo. Again, I'm not sure whether that was beneficial or not but it might be worth reaching out to Mehdi and Josh to see how they feel about it.
I *think* we mostly use oslo.concurrency for its execute() wrapper, which seems like it could be a very useful library on its own (can I suggest better-execute as a name?).
I would probably -2 any attempt to split oslo.utils. You'd end up with a bunch of single file libraries and a metric ****-ton of administrative overhead. It's bad enough managing 40 some repos as it is. Also, that's another library with minimal cross-dependencies with the rest of Oslo (just oslo.i18n again), which was an intentional design decision to make it relatively painless to pull in.
I guess I have a personal dislike of libraries without a simple goal (I've been also fighting with various "utils" modules inside Ironic - with only limited luck). I do suspect that at least some of oslo.utils contents could find a new home, some maybe even in the stdlib. I also don't want us to end up in the leafpad situation, on the other hand.
3) I'm genuinely not sure why oslo.log and oslo.i18n exist and which parts of their functionality cannot be moved upstream.
oslo.log basically provides convenience functions for OpenStack services, which is kind of what the oslo.* libraries should do. It provides built-in support for things like context objects, which are fairly domain-specific and would be difficult to generalize. It also provides a common set of configuration options so each project doesn't have to write their own. We don't need 20 different ways to enable debug logging. :-)
oslo.i18n is mostly for lazy translation, which apparently is a thing people still use even though the company pushing for it in the first place no longer cares. We've also had calls to remove it completely because it's finicky and tends to break things if the consuming projects don't follow the best practices with translated strings. So it's in a weird limbo state.
May I join these calls please? :) Will I break Zanata (assuming anybody still translates ironic projects) if I switch to the upstream gettext?
I did talk with JP in Shanghai about possibly making it optional because it pulls in a fair amount of translation files which can bloat minimal containers. I looked into it briefly and I think it would be possible, although I don't remember a lot of details because nobody was really pushing for it anymore so it's hard to justify spending a bunch of time on it.
I'd be curious to hear more. Dmitry
TLDR: I think Oslo provides value both in and out of OpenStack (shocking, I know!). I'm sure the separation isn't perfect, but what is?
There are some projects that have been split out of it that might be interesting case studies for this discussion if anyone wants to follow up. Not it. ;-)
-Ben
On 4/7/20 5:15 AM, Dmitry Tantsur wrote:
Hi,
On Mon, Apr 6, 2020 at 11:06 PM Ben Nemec <openstack@nemebean.com <mailto:openstack@nemebean.com>> wrote:
At the risk of getting defensive, I do want to make some points relating to Oslo specifically here.
I really do hope nothing I've said comes as offensive to the Oslo team. I'm not blaming you, we're all in this together :)
TLDR at the bottom if your eyes glaze over at the wall of text.
On 4/6/20 3:10 AM, Dmitry Tantsur wrote: > With absolutely no disrespect meant to the awesome Oslo team, I think > the existence of Oslo libraries is a bad sign. I think as a strong FOSS > community we shouldn't invest into libraries that are either useful only > to us or at least are marketed this way. For example:
I think it's relevant to keep in mind that Oslo didn't start out as a collection of libraries, it started out as a bunch of code forklifted from Nova for use by other OpenStack services. It was a significant effort just to get the Nova-isms out of it, much less trying to sanitize everything OpenStack-specific.
I also don't think it's fair to characterize Oslo as only focused on OpenStack today. In reality, many of our new libraries since the initial incubator split have been general purpose as often as not. Where they haven't, it's things like oslo.limit that are explicitly dependent on an OpenStack service (Keystone in this case). We believe in being good OSS citizens as much as anyone else.
There's also a boil the ocean problem with trying to generalize every solution to every problem. It's a question we ask every time a new library is proposed, but in some cases it just doesn't make sense to write a library for an audience that may or may not exist. And in some cases when such an audience appears, we have refactored libraries to make them more general purpose, while often keeping an OpenStack-specific layer to ease integration with OpenStack services. See oslo.concurrency and fasteners.
In fact, that kind of split is a pretty common pattern, even in cases where the underlying library didn't originate in Oslo/OpenStack. Think sqlalchemy/oslo.db, dogpile/oslo.cache, kombu/oslo.messaging. A lot of Oslo is glue code to make it easier to use something in a common way across OpenStack services.
> 1) oslo.config is a fantastic piece of software that the whole python > world could benefit from. Same for oslo.service, probably.
oslo.config is an interesting case because there is definitely interest outside OpenStack thanks to things like the Castellan config backend, but as Doug mentioned oslo.config is heavily opinionated (global config object, anyone?) and that's an issue for a lot of people. I will also point out that the only oslo.* dependency that oslo.config has is oslo.i18n, which itself has no other oslo dependencies, so there's not much barrier to entry to using it standalone today.
oslo.config currently pulls in 16 dependencies to a clean venv, including oslo.18n, Babel (why?) and requests (WHY?).
Well, it's got translated strings and thus i18n, Babel is used for lazy translation, and requests is used for the remote file driver. It's posssible the latter two could/should be optional deps, but without them you do lose functionality.
I would not inflict oslo.service on anyone I liked. :-P
So, you don't like us? :-P
I don't _think_ I'm responsible for anyone using oslo.service. If I am, it happened years ago before I had dug into oslo.service much. ;-)
Seriously though, I would advocate for using cotyledon if you're looking for a general purpose service library. It's not eventlet-based and provides a lot of the functionality of oslo.service, at least as I understand it. It was also written by an ex-Oslo contributor outside of OpenStack so maybe it's an interesting case study for this discussion. I don't know how much contribution it gets from other sources, but that would be good to look into.
Good to know, thanks!
> 2) oslo.utils as a catch-all repository of utilities should IMO be > either moved to existing python projects or decomposed into small > generally reusable libraries (essentially, each sub-module could be a > library of its own). Same for oslo.concurrency.
oslo.concurrency has already been decomposed into general purpose code (fasteners) and OpenStack-specific, at least for the most part. I'm sure the split isn't perfect, but it's not like we haven't recognized the need for better concurrency libraries in Python as a whole. Note that fasteners also lives outside Oslo in another ex-Osloers personal repo. Again, I'm not sure whether that was beneficial or not but it might be worth reaching out to Mehdi and Josh to see how they feel about it.
I *think* we mostly use oslo.concurrency for its execute() wrapper, which seems like it could be a very useful library on its own (can I suggest better-execute as a name?).
Certainly something we could explore. Note that quite a few projects also use interprocess locks from o.c, in which case they're implicitly picking up some standard config opts for setting things like lock_path. I don't know if that's the case for Ironic though.
I would probably -2 any attempt to split oslo.utils. You'd end up with a bunch of single file libraries and a metric ****-ton of administrative overhead. It's bad enough managing 40 some repos as it is. Also, that's another library with minimal cross-dependencies with the rest of Oslo (just oslo.i18n again), which was an intentional design decision to make it relatively painless to pull in.
I guess I have a personal dislike of libraries without a simple goal (I've been also fighting with various "utils" modules inside Ironic - with only limited luck).
I guess I should have noted that I agree "utils" and "misc" modules tend to be a code smell, but in this case we had two bad options available and had to pick one. IMHO we've done a reasonable job of keeping oslo.utils pretty minimal, but obviously I'm a bit biased. :-)
I do suspect that at least some of oslo.utils contents could find a new home, some maybe even in the stdlib. I also don't want us to end up in the leafpad situation, on the other hand.
That's entirely possible. We kind of lost our stdlib guy when Victor left the Oslo team so there may be things we've overlooked that could have been upstreamed.
> 3) I'm genuinely not sure why oslo.log and oslo.i18n exist and which > parts of their functionality cannot be moved upstream.
oslo.log basically provides convenience functions for OpenStack services, which is kind of what the oslo.* libraries should do. It provides built-in support for things like context objects, which are fairly domain-specific and would be difficult to generalize. It also provides a common set of configuration options so each project doesn't have to write their own. We don't need 20 different ways to enable debug logging. :-)
oslo.i18n is mostly for lazy translation, which apparently is a thing people still use even though the company pushing for it in the first place no longer cares. We've also had calls to remove it completely because it's finicky and tends to break things if the consuming projects don't follow the best practices with translated strings. So it's in a weird limbo state.
May I join these calls please? :) Will I break Zanata (assuming anybody still translates ironic projects) if I switch to the upstream gettext?
I don't think you'll break Zanata, I think you'll break anyone who was using lazy translation. I know there are users of it out there, but maybe we should look into getting a user survey question for Oslo that would give us an idea of how widely its used.
I did talk with JP in Shanghai about possibly making it optional because it pulls in a fair amount of translation files which can bloat minimal containers. I looked into it briefly and I think it would be possible, although I don't remember a lot of details because nobody was really pushing for it anymore so it's hard to justify spending a bunch of time on it.
I'd be curious to hear more.
Upon reflection, I think the thing we were looking to make optional was the Babel dep of oslo.i18n. It pulls in something like 6 MB of translation files and is only used to look up the available languages for lazy translation. I think code changes were needed though, it wasn't as simple as moving Babel to optional. There's probably an argument that we shouldn't be making that call when lazy translation is disabled anyway though.
Dmitry
TLDR: I think Oslo provides value both in and out of OpenStack (shocking, I know!). I'm sure the separation isn't perfect, but what is?
There are some projects that have been split out of it that might be interesting case studies for this discussion if anyone wants to follow up. Not it. ;-)
-Ben
Hi, On Wed, Apr 15, 2020 at 9:55 PM Ben Nemec <openstack@nemebean.com> wrote:
On 4/7/20 5:15 AM, Dmitry Tantsur wrote:
Hi,
On Mon, Apr 6, 2020 at 11:06 PM Ben Nemec <openstack@nemebean.com <mailto:openstack@nemebean.com>> wrote:
At the risk of getting defensive, I do want to make some points relating to Oslo specifically here.
<snip>
> 1) oslo.config is a fantastic piece of software that the whole python > world could benefit from. Same for oslo.service, probably.
oslo.config is an interesting case because there is definitely
interest
outside OpenStack thanks to things like the Castellan config backend, but as Doug mentioned oslo.config is heavily opinionated (global
config
object, anyone?) and that's an issue for a lot of people. I will also point out that the only oslo.* dependency that oslo.config has is oslo.i18n, which itself has no other oslo dependencies, so there's
not
much barrier to entry to using it standalone today.
oslo.config currently pulls in 16 dependencies to a clean venv, including oslo.18n, Babel (why?) and requests (WHY?).
Well, it's got translated strings and thus i18n, Babel is used for lazy translation, and requests is used for the remote file driver. It's posssible the latter two could/should be optional deps, but without them you do lose functionality.
Please pardon my ignorance, it's the first time I hear about this driver? How many people are using it in the wild? Will it hurt much if we treat this dependencies similar to database/tooz backend, i.e. as optional? More on Babel below.
I would not inflict oslo.service on anyone I liked. :-P
So, you don't like us? :-P
I don't _think_ I'm responsible for anyone using oslo.service. If I am, it happened years ago before I had dug into oslo.service much. ;-)
Seriously though, I would advocate for using cotyledon if you're looking for a general purpose service library. It's not eventlet-based and provides a lot of the functionality of oslo.service, at least as I understand it. It was also written by an ex-Oslo contributor outside
of
OpenStack so maybe it's an interesting case study for this discussion. I don't know how much contribution it gets from other sources, but that would be good to look into.
Good to know, thanks!
> 2) oslo.utils as a catch-all repository of utilities should IMO be > either moved to existing python projects or decomposed into small > generally reusable libraries (essentially, each sub-module could be a > library of its own). Same for oslo.concurrency.
oslo.concurrency has already been decomposed into general purpose
code
(fasteners) and OpenStack-specific, at least for the most part. I'm sure the split isn't perfect, but it's not like we haven't recognized the need for better concurrency libraries in Python as a whole. Note that fasteners also lives outside Oslo in another ex-Osloers personal
repo.
Again, I'm not sure whether that was beneficial or not but it might
be
worth reaching out to Mehdi and Josh to see how they feel about it.
I *think* we mostly use oslo.concurrency for its execute() wrapper, which seems like it could be a very useful library on its own (can I suggest better-execute as a name?).
Certainly something we could explore. Note that quite a few projects also use interprocess locks from o.c, in which case they're implicitly picking up some standard config opts for setting things like lock_path. I don't know if that's the case for Ironic though.
We only use in-process locks.
I would probably -2 any attempt to split oslo.utils. You'd end up with a bunch of single file libraries and a metric ****-ton of
administrative
overhead. It's bad enough managing 40 some repos as it is. Also,
that's
another library with minimal cross-dependencies with the rest of Oslo (just oslo.i18n again), which was an intentional design decision to make it relatively painless to pull in.
I guess I have a personal dislike of libraries without a simple goal (I've been also fighting with various "utils" modules inside Ironic - with only limited luck).
I guess I should have noted that I agree "utils" and "misc" modules tend to be a code smell, but in this case we had two bad options available and had to pick one. IMHO we've done a reasonable job of keeping oslo.utils pretty minimal, but obviously I'm a bit biased. :-)
I guess I'm fine with that if we stop pulling in Babel :) By the way, only oslo.i18n imports Babel directly. I'm proposing patches to various projects that move it out of requirements.txt. If you see one - please review. E.g. a shameless ping for osc-lib folks: https://review.opendev.org/717737
I do suspect that at least some of oslo.utils contents could find a new home, some maybe even in the stdlib. I also don't want us to end up in the leafpad situation, on the other hand.
That's entirely possible. We kind of lost our stdlib guy when Victor left the Oslo team so there may be things we've overlooked that could have been upstreamed.
> 3) I'm genuinely not sure why oslo.log and oslo.i18n exist and
which
> parts of their functionality cannot be moved upstream.
oslo.log basically provides convenience functions for OpenStack services, which is kind of what the oslo.* libraries should do. It provides built-in support for things like context objects, which are fairly domain-specific and would be difficult to generalize. It also provides a common set of configuration options so each project
doesn't
have to write their own. We don't need 20 different ways to enable debug logging. :-)
oslo.i18n is mostly for lazy translation, which apparently is a thing people still use even though the company pushing for it in the first place no longer cares. We've also had calls to remove it completely because it's finicky and tends to break things if the consuming projects don't follow the best practices with translated strings. So it's in a weird limbo state.
May I join these calls please? :) Will I break Zanata (assuming anybody still translates ironic projects) if I switch to the upstream gettext?
I don't think you'll break Zanata, I think you'll break anyone who was using lazy translation. I know there are users of it out there, but maybe we should look into getting a user survey question for Oslo that would give us an idea of how widely its used.
I meant changing ironic, which honestly doesn't have real translations any more..
I did talk with JP in Shanghai about possibly making it optional because it pulls in a fair amount of translation files which can bloat
minimal
containers. I looked into it briefly and I think it would be
possible,
although I don't remember a lot of details because nobody was really pushing for it anymore so it's hard to justify spending a bunch of
time
on it.
I'd be curious to hear more.
Upon reflection, I think the thing we were looking to make optional was the Babel dep of oslo.i18n. It pulls in something like 6 MB of translation files
Oh, yeah. When building our ramdisk, we have to manually delete these files to make it smaller.
and is only used to look up the available languages for lazy translation. I think code changes were needed though, it wasn't as simple as moving Babel to optional. There's probably an argument that we shouldn't be making that call when lazy translation is disabled anyway though.
Is it something I can help with? It seems that Babel is only used in get_available_languages. Can we make it an optional dependency for projects that do use this call (ironic does not)? Dmitry
Dmitry
TLDR: I think Oslo provides value both in and out of OpenStack (shocking, I know!). I'm sure the separation isn't perfect, but what
is?
There are some projects that have been split out of it that might be interesting case studies for this discussion if anyone wants to
follow
up. Not it. ;-)
-Ben
On Thu, Apr 16, 2020 at 10:50 AM Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi,
On Wed, Apr 15, 2020 at 9:55 PM Ben Nemec <openstack@nemebean.com> wrote:
On 4/7/20 5:15 AM, Dmitry Tantsur wrote:
Hi,
On Mon, Apr 6, 2020 at 11:06 PM Ben Nemec <openstack@nemebean.com <mailto:openstack@nemebean.com>> wrote:
At the risk of getting defensive, I do want to make some points relating to Oslo specifically here.
<snip>
> 1) oslo.config is a fantastic piece of software that the whole python > world could benefit from. Same for oslo.service, probably.
oslo.config is an interesting case because there is definitely
interest
outside OpenStack thanks to things like the Castellan config
backend,
but as Doug mentioned oslo.config is heavily opinionated (global
config
object, anyone?) and that's an issue for a lot of people. I will
also
point out that the only oslo.* dependency that oslo.config has is oslo.i18n, which itself has no other oslo dependencies, so there's
not
much barrier to entry to using it standalone today.
oslo.config currently pulls in 16 dependencies to a clean venv, including oslo.18n, Babel (why?) and requests (WHY?).
Well, it's got translated strings and thus i18n, Babel is used for lazy translation, and requests is used for the remote file driver. It's posssible the latter two could/should be optional deps, but without them you do lose functionality.
Please pardon my ignorance, it's the first time I hear about this driver? How many people are using it in the wild? Will it hurt much if we treat this dependencies similar to database/tooz backend, i.e. as optional?
More on Babel below.
I would not inflict oslo.service on anyone I liked. :-P
So, you don't like us? :-P
I don't _think_ I'm responsible for anyone using oslo.service. If I am, it happened years ago before I had dug into oslo.service much. ;-)
Seriously though, I would advocate for using cotyledon if you're looking for a general purpose service library. It's not eventlet-based and provides a lot of the functionality of oslo.service, at least as I understand it. It was also written by an ex-Oslo contributor
outside of
OpenStack so maybe it's an interesting case study for this discussion. I don't know how much contribution it gets from other sources, but
that
would be good to look into.
Good to know, thanks!
> 2) oslo.utils as a catch-all repository of utilities should IMO
be
> either moved to existing python projects or decomposed into small > generally reusable libraries (essentially, each sub-module could be a > library of its own). Same for oslo.concurrency.
oslo.concurrency has already been decomposed into general purpose
code
(fasteners) and OpenStack-specific, at least for the most part. I'm sure the split isn't perfect, but it's not like we haven't recognized the need for better concurrency libraries in Python as a whole. Note
that
fasteners also lives outside Oslo in another ex-Osloers personal
repo.
Again, I'm not sure whether that was beneficial or not but it might
be
worth reaching out to Mehdi and Josh to see how they feel about it.
I *think* we mostly use oslo.concurrency for its execute() wrapper, which seems like it could be a very useful library on its own (can I suggest better-execute as a name?).
Certainly something we could explore. Note that quite a few projects also use interprocess locks from o.c, in which case they're implicitly picking up some standard config opts for setting things like lock_path. I don't know if that's the case for Ironic though.
We only use in-process locks.
I would probably -2 any attempt to split oslo.utils. You'd end up with a bunch of single file libraries and a metric ****-ton of
administrative
overhead. It's bad enough managing 40 some repos as it is. Also,
that's
another library with minimal cross-dependencies with the rest of
Oslo
(just oslo.i18n again), which was an intentional design decision to make it relatively painless to pull in.
I guess I have a personal dislike of libraries without a simple goal (I've been also fighting with various "utils" modules inside Ironic - with only limited luck).
I guess I should have noted that I agree "utils" and "misc" modules tend to be a code smell, but in this case we had two bad options available and had to pick one. IMHO we've done a reasonable job of keeping oslo.utils pretty minimal, but obviously I'm a bit biased. :-)
I guess I'm fine with that if we stop pulling in Babel :)
By the way, only oslo.i18n imports Babel directly. I'm proposing patches to various projects that move it out of requirements.txt. If you see one - please review.
E.g. a shameless ping for osc-lib folks: https://review.opendev.org/717737
I do suspect that at least some of oslo.utils contents could find a new home, some maybe even in the stdlib. I also don't want us to end up in the leafpad situation, on the other hand.
That's entirely possible. We kind of lost our stdlib guy when Victor left the Oslo team so there may be things we've overlooked that could have been upstreamed.
> 3) I'm genuinely not sure why oslo.log and oslo.i18n exist and
which
> parts of their functionality cannot be moved upstream.
oslo.log basically provides convenience functions for OpenStack services, which is kind of what the oslo.* libraries should do. It provides built-in support for things like context objects, which are fairly domain-specific and would be difficult to generalize. It also provides a common set of configuration options so each project
doesn't
have to write their own. We don't need 20 different ways to enable debug logging. :-)
oslo.i18n is mostly for lazy translation, which apparently is a
thing
people still use even though the company pushing for it in the first place no longer cares. We've also had calls to remove it completely because it's finicky and tends to break things if the consuming projects don't follow the best practices with translated strings. So it's in
a
weird limbo state.
May I join these calls please? :) Will I break Zanata (assuming anybody still translates ironic projects) if I switch to the upstream gettext?
I don't think you'll break Zanata, I think you'll break anyone who was using lazy translation. I know there are users of it out there, but maybe we should look into getting a user survey question for Oslo that would give us an idea of how widely its used.
I meant changing ironic, which honestly doesn't have real translations any more..
I did talk with JP in Shanghai about possibly making it optional because it pulls in a fair amount of translation files which can bloat
minimal
containers. I looked into it briefly and I think it would be
possible,
although I don't remember a lot of details because nobody was really pushing for it anymore so it's hard to justify spending a bunch of
time
on it.
I'd be curious to hear more.
Upon reflection, I think the thing we were looking to make optional was the Babel dep of oslo.i18n. It pulls in something like 6 MB of translation files
Oh, yeah. When building our ramdisk, we have to manually delete these files to make it smaller.
and is only used to look up the available languages for lazy translation. I think code changes were needed though, it wasn't as simple as moving Babel to optional. There's probably an argument that we shouldn't be making that call when lazy translation is disabled anyway though.
Is it something I can help with?
It seems that Babel is only used in get_available_languages. Can we make it an optional dependency for projects that do use this call (ironic does not)?
I've prepared a patch: https://review.opendev.org/#/c/720404/ comments are welcome. It seems that we need to update all projects using get_available_languages (mostly "core" projects) to depend on Babel explicity. Dmitry
Dmitry
Dmitry
TLDR: I think Oslo provides value both in and out of OpenStack (shocking, I know!). I'm sure the separation isn't perfect, but
what is?
There are some projects that have been split out of it that might be interesting case studies for this discussion if anyone wants to
follow
up. Not it. ;-)
-Ben
On 4/16/20 3:50 AM, Dmitry Tantsur wrote:
Hi,
On Wed, Apr 15, 2020 at 9:55 PM Ben Nemec <openstack@nemebean.com <mailto:openstack@nemebean.com>> wrote:
On 4/7/20 5:15 AM, Dmitry Tantsur wrote: > Hi, > > On Mon, Apr 6, 2020 at 11:06 PM Ben Nemec <openstack@nemebean.com <mailto:openstack@nemebean.com> > <mailto:openstack@nemebean.com <mailto:openstack@nemebean.com>>> wrote: > > At the risk of getting defensive, I do want to make some points > relating > to Oslo specifically here.
<snip>
> > > 1) oslo.config is a fantastic piece of software that the whole > python > > world could benefit from. Same for oslo.service, probably. > > oslo.config is an interesting case because there is definitely interest > outside OpenStack thanks to things like the Castellan config backend, > but as Doug mentioned oslo.config is heavily opinionated (global config > object, anyone?) and that's an issue for a lot of people. I will also > point out that the only oslo.* dependency that oslo.config has is > oslo.i18n, which itself has no other oslo dependencies, so there's not > much barrier to entry to using it standalone today. > > > oslo.config currently pulls in 16 dependencies to a clean venv, > including oslo.18n, Babel (why?) and requests (WHY?).
Well, it's got translated strings and thus i18n, Babel is used for lazy translation, and requests is used for the remote file driver. It's posssible the latter two could/should be optional deps, but without them you do lose functionality.
Please pardon my ignorance, it's the first time I hear about this driver? How many people are using it in the wild? Will it hurt much if we treat this dependencies similar to database/tooz backend, i.e. as optional?
I can't say for sure because we don't have any sort of usage metrics. It was kind of a stepping stone on the way to the Castellan driver for keeping secrets out of the on-disk configuration files. If I had to guess, I would say most people are probably using the Castellan driver in that scenario. Either way, making the deps for it optional seems reasonable to me. [snip]
I meant changing ironic, which honestly doesn't have real translations any more..
Ah, that sounds like a question for the i18n team then.
Back in 2017 when Gnocchi moved out from OpenStack governance [1], in a review Dean Troyer wrote "This actually feels like a graduation, and I have a hunch it will not be the last one we see this year". I feel the same about Ironic moving beyond OpenStack governance. When OpenStack was riding high we created the big tent in order to accomodate new projects that desired entry. Now as OpenStack is later in it's lifecycle I think we should be just as accomodating for projects that see a brighter future in separation. When you think of the top open source projects for bootstrapping bare metal like Foreman or Cobbler, a datacenter automation engineer's first thought isn't "oh, isn't that part of some other thing I'm not interested in?" I think Ironic should be free to take it's place next to those other tools and be considered in it's own right. Since this proposal represents the collective will of the Ironic team, based on the endorsement of their elected team lead, I support the decision. [1] https://review.opendev.org/#/c/447438/ On Wed, Apr 01, 2020 at 07:03:47PM +0200, Dmitry Tantsur wrote:
Hi everyone!
This topic should not come as a huge surprise for many, since it has been raised numerous times in the past years. I have a feeling that the end of Ussuri, now that we’ve re-acquired our PTL and are on the verge of selecting new TC members, may be a good time to propose it for a formal discussion.
TL;DR I’m proposing to make Ironic a top-level project under opendev.org and the OpenStack Foundation, following the same model as Zuul. I don’t propose severing current relationships with other OpenStack projects, nor making substantial changes in how the project is operated.
(And no, it’s not an April 1st joke)
Background =========
Ironic was born as a Nova plugin, but has grown way beyond this single case since then. The first commit in Bifrost dates to February 2015. During these 5 years (hey, we forgot to celebrate!) it has developed into a commonly used data center management tool - and still based on standalone Ironic! The Metal3 project uses standalone Ironic as its hardware management backend. We haven’t been “just” a component of OpenStack for a while now, I think it’s time to officially recognize it.
And before you ask: in no case do I suggest scaling down our invaluable integration with Nova. We’re observing a solid growth of deployments using Ironic as an addition to their OpenStack clouds, and this proposal doesn’t try to devalue this use case. The intention is to accept publicly and officially that it’s not the only or the main use case, but one of the main use cases. I don’t think it comes as a surprise to the Nova team.
Okay, so why? ===========
The first and the main reason is the ambiguity in our positioning. We do see prospective operators and users confused by the perception that Ironic is a part of OpenStack, especially when it comes to the standalone use case. “But what if I don’t need OpenStack” is a question that I hear in most of these conversations. Changing from “a part of OpenStack” to “a FOSS tool that can integrate with OpenStack” is critical for our project to keep growing into new fields. To me personally it feels in line with how OpenDev itself is reaching into new areas beyond just the traditional IaaS. The next OpenDev even will apparently have a bare metal management track, so why not a top-level project for it?
Another reason is release cadence. We have repeatedly expressed the desire to release Ironic and its sub-projects more often than we do now. Granted, *technically* we can release often even now. We can even abandon the current release model and switch to “independent”, but it doesn’t entirely solve the issue at hand. First, we don’t want to lose the notion of stable branches. One way or another, we need to support consumers with bug fix releases. Second, to become truly “independent” we’ll need to remove any tight coupling with any projects that do integrated releases. Which is, essentially, what I’m proposing here.
Finally, I believe that our independence (can I call it “Irexit” please?) has already happened in reality, we just shy away from recognizing it. Look: 1. All integration points with other OpenStack projects are optional. 2. We can work fully standalone and even provide a project for that. 3. Many new features (RAID, BIOS to name a few) are exposed to standalone users much earlier than to those going through Nova. 4. We even have our own mini-scheduler (although its intention is not and has not been to replace the Placement service). 5. We make releases more often than the “core” OpenStack projects (but see above).
What we will do ============
This proposal involves in the short term: * Creating a new git namespace: opendev.org/ironic * Creating a new website (name TBD, bare metal puns are welcome). * If we can have https://docs.opendev.org/ironic/, it may be just fine though. * Keeping the same governance model, only adjusted to the necessary extent. * Keeping the same policies (reviews, CI, stable). * Defining a new release cadence and stable branch support schedule.
In the long term we will consider (not necessary do): * Reshaping our CI to rely less on devstack and grenade (only use them for jobs involving OpenStack). * Reducing or removing reliance on oslo libraries. * Stopping using rabbitmq for messaging (we’ve already made it optional). * Integrating with non-OpenStack services (kubernetes?) and providing lighter alternatives (think, built-in authentication).
What we will NOT do ================
At least this proposal does NOT involve: * Stopping maintaining the Ironic virt driver in Nova. * Stopping running voting CI jobs with OpenStack services. * Dropping optional integration with OpenStack services. * Leaving OpenDev completely.
What do you think? ===============
Please let us know what you think about this proposal. Any hints on how to proceed with it, in case we reach a consensus, are also welcome.
Cheers, Dmitry
I see we are talking about another "Gnocchi", when Gnocchi moved out of OpenStack, people said they could run Gnocchi in standalone mode without installing the other OpenStack services, then they changed default dependency of some other projects (Ceilometer, Panko, etc) to Gnocchi. As a result, they are all dead (or almost dead). Another example is a long time ago in one OpenStack project, there was a demand for secret management, people said, Barbican is not mature and not production ready yet, we shouldn't dependent on Barbican but could make it optional, as a result, Barbican never adopted in the project in real deployment. I have been involved in OpenStack community since 2013, I see people came and left, I see projects created and died, until now, there are only a few of projects alive and actively maintained. IMHO, as a community, we should try our best to integrate projects with each other, no project can live well without some others help， projects rarely stand or fall alone. Well, I'm not part of TC, I'm not the person or team can decide how Ironic project goes in this situation. But as a developer who is trying very hard to maintain several OpenStack projects, that what I'm thinking. My 0.02. - Best regards, Lingxian Kong Catalyst Cloud
On Fri, Apr 3, 2020 at 2:48 AM Lingxian Kong <anlin.kong@gmail.com> wrote:
I see we are talking about another "Gnocchi", when Gnocchi moved out of OpenStack, people said they could run Gnocchi in standalone mode without installing the other OpenStack services, then they changed default dependency of some other projects (Ceilometer, Panko, etc) to Gnocchi. As a result, they are all dead (or almost dead).
I'd be very careful comparing Ironic to Gnocchi/Telemetry. I think the fate that Telemetry met was largely due to staffing problems, more specifically, all large contributors pulling away from it. It would end up the same inside or outside of OpenStack.
Another example is a long time ago in one OpenStack project, there was a demand for secret management, people said, Barbican is not mature and not production ready yet, we shouldn't dependent on Barbican but could make it optional, as a result, Barbican never adopted in the project in real deployment.
I don't know much about the Barbican situation, but there may be other explanations. Some operators are against deploying any new service unless absolutely necessary, because any new service is a maintenance burden. At the Denver PTG we were talking about non-Keystone authentication in Ironic. Keystone is arguably very trivial to install, and still it meets some resistance.
I have been involved in OpenStack community since 2013, I see people came and left, I see projects created and died, until now, there are only a few of projects alive and actively maintained. IMHO, as a community, we should try our best to integrate projects with each other, no project can live well without some others help， projects rarely stand or fall alone.
To be clear, my proposal does not affect this. Specifically: 1) I don't suggest reducing the number of integration points. 2) Integration points with OpenStack services are already optional in Ironic. What exactly is your concern? Ironic dropping integration points altogether? We don't plan on that. Dmitry
Well, I'm not part of TC, I'm not the person or team can decide how Ironic project goes in this situation. But as a developer who is trying very hard to maintain several OpenStack projects, that what I'm thinking.
My 0.02.
- Best regards, Lingxian Kong Catalyst Cloud
On 06.04.2020 09:51, Dmitry Tantsur wrote:
On Fri, Apr 3, 2020 at 2:48 AM Lingxian Kong <anlin.kong@gmail.com <mailto:anlin.kong@gmail.com>> wrote:
I see we are talking about another "Gnocchi", when Gnocchi moved out of OpenStack, people said they could run Gnocchi in standalone mode without installing the other OpenStack services, then they changed default dependency of some other projects (Ceilometer, Panko, etc) to Gnocchi. As a result, they are all dead (or almost dead).
I'd be very careful comparing Ironic to Gnocchi/Telemetry. I think the fate that Telemetry met was largely due to staffing problems, more specifically, all large contributors pulling away from it. It would end up the same inside or outside of OpenStack.
Another example is a long time ago in one OpenStack project, there was a demand for secret management, people said, Barbican is not mature and not production ready yet, we shouldn't dependent on Barbican but could make it optional, as a result, Barbican never adopted in the project in real deployment.
I don't know much about the Barbican situation, but there may be other explanations. Some operators are against deploying any new service unless absolutely necessary, because any new service is a maintenance burden.
At the Denver PTG we were talking about non-Keystone authentication in Ironic. Keystone is arguably very trivial to install, and still it meets some resistance.
I have been involved in OpenStack community since 2013, I see people came and left, I see projects created and died, until now, there are only a few of projects alive and actively maintained. IMHO, as a community, we should try our best to integrate projects with each other, no project can live well without some others help， projects rarely stand or fall alone.
To be clear, my proposal does not affect this. Specifically: 1) I don't suggest reducing the number of integration points.
But having *more* integration points and functional duplication, like internal project's authorization, coordination (placement/messaging), shared libraries, indirectly reduce the integration points in OpenStack and pulls off contributors by spreading its focus on that otherwise would have been shipped and maintained "out of box" (or out of big tent). Not ranting, I understand that it is pointless to complain against inevitability.
2) Integration points with OpenStack services are already optional in Ironic.
What exactly is your concern? Ironic dropping integration points altogether? We don't plan on that.
Dmitry
Well, I'm not part of TC, I'm not the person or team can decide how Ironic project goes in this situation. But as a developer who is trying very hard to maintain several OpenStack projects, that what I'm thinking.
My 0.02.
- Best regards, Lingxian Kong Catalyst Cloud
-- Best regards, Bogdan Dobrelya, Irc #bogdando
On Mon, Apr 6, 2020 at 10:18 AM Bogdan Dobrelya <bdobreli@redhat.com> wrote:
On 06.04.2020 09:51, Dmitry Tantsur wrote:
On Fri, Apr 3, 2020 at 2:48 AM Lingxian Kong <anlin.kong@gmail.com <mailto:anlin.kong@gmail.com>> wrote:
I see we are talking about another "Gnocchi", when Gnocchi moved out
of
OpenStack, people said they could run Gnocchi in standalone mode
without
installing the other OpenStack services, then they changed default dependency of some other projects (Ceilometer, Panko, etc) to
Gnocchi.
As a result, they are all dead (or almost dead).
I'd be very careful comparing Ironic to Gnocchi/Telemetry. I think the fate that Telemetry met was largely due to staffing problems, more specifically, all large contributors pulling away from it. It would end up the same inside or outside of OpenStack.
Another example is a long time ago in one OpenStack project, there
was a
demand for secret management, people said, Barbican is not mature and not production ready yet, we shouldn't dependent on Barbican but
could
make it optional, as a result, Barbican never adopted in the project
in
real deployment.
I don't know much about the Barbican situation, but there may be other explanations. Some operators are against deploying any new service unless absolutely necessary, because any new service is a maintenance burden.
At the Denver PTG we were talking about non-Keystone authentication in Ironic. Keystone is arguably very trivial to install, and still it meets some resistance.
I have been involved in OpenStack community since 2013, I see people came and left, I see projects created and died, until now, there are only a few of projects alive and actively maintained. IMHO, as a community, we should try our best to integrate projects with each
other,
no project can live well without some others help， projects rarely stand or fall alone.
To be clear, my proposal does not affect this. Specifically: 1) I don't suggest reducing the number of integration points.
But having *more* integration points and functional duplication, like internal project's authorization, coordination (placement/messaging), shared libraries, indirectly reduce the integration points in OpenStack and pulls off contributors by spreading its focus on that otherwise would have been shipped and maintained "out of box" (or out of big tent). Not ranting, I understand that it is pointless to complain against inevitability.
On the other hand, not having some of these prevents adoption (for example, the requirement of RabbitMQ has been a huge deal for standalone adoption and was considered a blocker for metal3). Dmitry
2) Integration points with OpenStack services are already optional in Ironic.
What exactly is your concern? Ironic dropping integration points altogether? We don't plan on that.
Dmitry
Well, I'm not part of TC, I'm not the person or team can decide how Ironic project goes in this situation. But as a developer who is trying very hard to maintain several OpenStack projects, that what I'm thinking.
My 0.02.
- Best regards, Lingxian Kong Catalyst Cloud
-- Best regards, Bogdan Dobrelya, Irc #bogdando
On Mon, 2020-04-06 at 10:40 +0200, Dmitry Tantsur wrote:
On Mon, Apr 6, 2020 at 10:18 AM Bogdan Dobrelya <bdobreli@redhat.com> wrote:
On 06.04.2020 09:51, Dmitry Tantsur wrote:
On Fri, Apr 3, 2020 at 2:48 AM Lingxian Kong <anlin.kong@gmail.com <mailto:anlin.kong@gmail.com>> wrote:
I see we are talking about another "Gnocchi", when Gnocchi moved out
of
OpenStack, people said they could run Gnocchi in standalone mode
without
installing the other OpenStack services, then they changed default dependency of some other projects (Ceilometer, Panko, etc) to
Gnocchi.
As a result, they are all dead (or almost dead).
I'd be very careful comparing Ironic to Gnocchi/Telemetry. I think the fate that Telemetry met was largely due to staffing problems, more specifically, all large contributors pulling away from it. It would end up the same inside or outside of OpenStack.
Another example is a long time ago in one OpenStack project, there
was a
demand for secret management, people said, Barbican is not mature and not production ready yet, we shouldn't dependent on Barbican but
could
make it optional, as a result, Barbican never adopted in the project
in
real deployment.
I don't know much about the Barbican situation, but there may be other explanations. Some operators are against deploying any new service unless absolutely necessary, because any new service is a maintenance burden.
At the Denver PTG we were talking about non-Keystone authentication in Ironic. Keystone is arguably very trivial to install, and still it meets some resistance.
I have been involved in OpenStack community since 2013, I see people came and left, I see projects created and died, until now, there are only a few of projects alive and actively maintained. IMHO, as a community, we should try our best to integrate projects with each
other,
no project can live well without some others help， projects rarely stand or fall alone.
To be clear, my proposal does not affect this. Specifically: 1) I don't suggest reducing the number of integration points.
But having *more* integration points and functional duplication, like internal project's authorization, coordination (placement/messaging), shared libraries, indirectly reduce the integration points in OpenStack and pulls off contributors by spreading its focus on that otherwise would have been shipped and maintained "out of box" (or out of big tent). Not ranting, I understand that it is pointless to complain against inevitability.
On the other hand, not having some of these prevents adoption (for example, the requirement of RabbitMQ has been a huge deal for standalone adoption and was considered a blocker for metal3).
Dmitry you could use other messaging busses for a long time with oslo. e.g. zeromq,activemq qpid not just rabbit if you or someone else was to add supprot for NATS https://nats.io/ or ectd i would love to try using that in other projects like nova as honestly i think that is the only true alternitve that has emerged in the last 3-4 years that could propely replace rabbitmq https://blueprints.launchpad.net/oslo.messaging/+spec/nats-transport
that said there is nothing that requires ironic to use rabbit today none of the other services should even know if you are using rabbit. they interact via the restapi only. so ironic is free to use something else if it chooses too. i belive there are several projects already using etcd. so if a distibupted state model works better for ironic there is nothing stopping it evloving in that direction. i would argue that the only reason most service use rabbitmq is that that means there are less supproting services that need to be maintained by the sys admin.
2) Integration points with OpenStack services are already optional in Ironic.
What exactly is your concern? Ironic dropping integration points altogether? We don't plan on that.
Dmitry
Well, I'm not part of TC, I'm not the person or team can decide how Ironic project goes in this situation. But as a developer who is
trying
very hard to maintain several OpenStack projects, that what I'm thinking.
My 0.02.
- Best regards, Lingxian Kong Catalyst Cloud
-- Best regards, Bogdan Dobrelya, Irc #bogdando
Hi Dmitry, Thank you for raising this. I think what you're looking for makes sense, I don't think splitting outside OpenStack is the right solution for this. There are many logistical issues in doing this. First of all, it promotes even more bureaucracy within our community which is something that we're trying to split. "Ironic" and "OpenStack" becoming two separate pieces means that we've failed as a community to be able to deliver what OpenStack is. If we do this, we further promote the separation of our communities and that is not sustainable. With a dwindling contributor base, we'll find power in standing together in big groups, not by isolating ourselves to small islands. Arguably, you would say that "well, Ironic is picking up outside OpenStack and we want to capitalize on that". I agree with you on that, I think we should absolutely do that. However, I think simply just becoming a top-level project is not the way to go about this. It will introduce a lot more work to our (already overwhelmed) OSF staff, it means maintaining a new identity, it means applying to be a pilot project and going through the whole process. It means that all existing developer may need to have to revise the way they do work because they have signed the CCLA for OpenStack and not "Ironic". We're adding a whole lot of bureaucray when the problem is messaging. I've gone over your points below about what you think this will do and strongly suggest those alternatives. Regards, Mohammed On Wed, Apr 1, 2020 at 1:07 PM Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi everyone!
This topic should not come as a huge surprise for many, since it has been raised numerous times in the past years. I have a feeling that the end of Ussuri, now that we’ve re-acquired our PTL and are on the verge of selecting new TC members, may be a good time to propose it for a formal discussion.
TL;DR I’m proposing to make Ironic a top-level project under opendev.org and the OpenStack Foundation, following the same model as Zuul. I don’t propose severing current relationships with other OpenStack projects, nor making substantial changes in how the project is operated.
(And no, it’s not an April 1st joke)
Background =========
Ironic was born as a Nova plugin, but has grown way beyond this single case since then. The first commit in Bifrost dates to February 2015. During these 5 years (hey, we forgot to celebrate!) it has developed into a commonly used data center management tool - and still based on standalone Ironic! The Metal3 project uses standalone Ironic as its hardware management backend. We haven’t been “just” a component of OpenStack for a while now, I think it’s time to officially recognize it.
And before you ask: in no case do I suggest scaling down our invaluable integration with Nova. We’re observing a solid growth of deployments using Ironic as an addition to their OpenStack clouds, and this proposal doesn’t try to devalue this use case. The intention is to accept publicly and officially that it’s not the only or the main use case, but one of the main use cases. I don’t think it comes as a surprise to the Nova team.
Okay, so why? ===========
The first and the main reason is the ambiguity in our positioning. We do see prospective operators and users confused by the perception that Ironic is a part of OpenStack, especially when it comes to the standalone use case. “But what if I don’t need OpenStack” is a question that I hear in most of these conversations. Changing from “a part of OpenStack” to “a FOSS tool that can integrate with OpenStack” is critical for our project to keep growing into new fields. To me personally it feels in line with how OpenDev itself is reaching into new areas beyond just the traditional IaaS. The next OpenDev even will apparently have a bare metal management track, so why not a top-level project for it?
Another reason is release cadence. We have repeatedly expressed the desire to release Ironic and its sub-projects more often than we do now. Granted, *technically* we can release often even now. We can even abandon the current release model and switch to “independent”, but it doesn’t entirely solve the issue at hand. First, we don’t want to lose the notion of stable branches. One way or another, we need to support consumers with bug fix releases. Second, to become truly “independent” we’ll need to remove any tight coupling with any projects that do integrated releases. Which is, essentially, what I’m proposing here.
Finally, I believe that our independence (can I call it “Irexit” please?) has already happened in reality, we just shy away from recognizing it. Look: 1. All integration points with other OpenStack projects are optional. 2. We can work fully standalone and even provide a project for that. 3. Many new features (RAID, BIOS to name a few) are exposed to standalone users much earlier than to those going through Nova. 4. We even have our own mini-scheduler (although its intention is not and has not been to replace the Placement service). 5. We make releases more often than the “core” OpenStack projects (but see above).
What we will do ============
This proposal involves in the short term: * Creating a new git namespace: opendev.org/ironic
We could totally do this for all existing projects honestly. I think the TC could probably be okay with this.
* Creating a new website (name TBD, bare metal puns are welcome). * If we can have https://docs.opendev.org/ironic/, it may be just fine though.
Who's going to work on this website? It's important to not only have a website but keep it maintained, add more content, update it. The website will have absolutely zero traction initially and we'll miss out on all the "traffic" that OpenStack.org gets. I think what we should actually do is redesign OpenStack.org so that it's a focused about the OpenStack projects and move all the foundation stuff to osf.dev -- In there, we can nail down the messaging of "you don't need all of OpenStack".
* Keeping the same governance model, only adjusted to the necessary extent.
This is not easy, you'll have to come up with a whole governance, run elections, manage people. We already have volunteers that help do this inside OpenStack, why add all that extra layer?
* Keeping the same policies (reviews, CI, stable).
That seems reasonable to me
* Defining a new release cadence and stable branch support schedule.
If there is anything in the current model that doesn't suit you, please bring it up, and let's revise it. I've heard this repeated a lot as a complaint from the Ironic team and I've unfortunately not seen any proposal about an ideal alternative. We need to hear things to change things.
In the long term we will consider (not necessary do): * Reshaping our CI to rely less on devstack and grenade (only use them for jobs involving OpenStack).
That seems reasonable to have more Ironic "standalone" jobs. It is important that _the_ biggest consumers *are* the OpenStack ones, let's not alienate them so we end up in a world of nothing new.
* Reducing or removing reliance on oslo libraries.
Why?
* Stopping using rabbitmq for messaging (we’ve already made it optional).
Please. Please. Whatever you replace it with, just update oslo.messaging and make all of us happy to stop using it. It's hell.
* Integrating with non-OpenStack services (kubernetes?) and providing lighter alternatives (think, built-in authentication).
I support this, and I think there's nothing stopping you from doing that today. If there is, let's bring it up.
What we will NOT do ================
At least this proposal does NOT involve: * Stopping maintaining the Ironic virt driver in Nova. * Stopping running voting CI jobs with OpenStack services. * Dropping optional integration with OpenStack services. * Leaving OpenDev completely.
What do you think? ===============
Please let us know what you think about this proposal. Any hints on how to proceed with it, in case we reach a consensus, are also welcome.
Cheers, Dmitry
-- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser@vexxhost.com W. https://vexxhost.com
On 4/6/20 9:45 AM, Mohammed Naser wrote:
Hi Dmitry,
Thank you for raising this. I think what you're looking for makes sense, I don't think splitting outside OpenStack is the right solution for this. There are many logistical issues in doing this.
First of all, it promotes even more bureaucracy within our community which is something that we're trying to split. "Ironic" and "OpenStack" becoming two separate pieces means that we've failed as a community to be able to deliver what OpenStack is. If we do this, we further promote the separation of our communities and that is not sustainable. With a dwindling contributor base, we'll find power in standing together in big groups, not by isolating ourselves to small islands.
Arguably, you would say that "well, Ironic is picking up outside OpenStack and we want to capitalize on that". I agree with you on that, I think we should absolutely do that. However, I think simply just becoming a top-level project is not the way to go about this. It will introduce a lot more work to our (already overwhelmed) OSF staff, it means maintaining a new identity, it means applying to be a pilot project and going through the whole process. It means that all existing developer may need to have to revise the way they do work because they have signed the CCLA for OpenStack and not "Ironic". We're adding a whole lot of bureaucray when the problem is messaging.
I've gone over your points below about what you think this will do and strongly suggest those alternatives.
Regards, Mohammed
Cinder has been useful stand alone for several years now, but I have also seen the reaction of "why would I use that, I don't need all of that OpenStack stuff". I wonder if we need to do something better to highlight and message that there are certain components of OpenStack that are useful as independent components that can exist on their own. Sean
On Mon, Apr 6, 2020 at 10:53 AM Sean McGinnis <sean.mcginnis@gmx.com> wrote:
On 4/6/20 9:45 AM, Mohammed Naser wrote:
Hi Dmitry,
Thank you for raising this. I think what you're looking for makes sense, I don't think splitting outside OpenStack is the right solution for this. There are many logistical issues in doing this.
First of all, it promotes even more bureaucracy within our community which is something that we're trying to split. "Ironic" and "OpenStack" becoming two separate pieces means that we've failed as a community to be able to deliver what OpenStack is. If we do this, we further promote the separation of our communities and that is not sustainable. With a dwindling contributor base, we'll find power in standing together in big groups, not by isolating ourselves to small islands.
Arguably, you would say that "well, Ironic is picking up outside OpenStack and we want to capitalize on that". I agree with you on that, I think we should absolutely do that. However, I think simply just becoming a top-level project is not the way to go about this. It will introduce a lot more work to our (already overwhelmed) OSF staff, it means maintaining a new identity, it means applying to be a pilot project and going through the whole process. It means that all existing developer may need to have to revise the way they do work because they have signed the CCLA for OpenStack and not "Ironic". We're adding a whole lot of bureaucray when the problem is messaging.
I've gone over your points below about what you think this will do and strongly suggest those alternatives.
Regards, Mohammed
Cinder has been useful stand alone for several years now, but I have also seen the reaction of "why would I use that, I don't need all of that OpenStack stuff".
I wonder if we need to do something better to highlight and message that there are certain components of OpenStack that are useful as independent components that can exist on their own.
I think that Sean here hit on the most critical point we need to drive. There's no amount of splitting that would resolve this.
Sean
-- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser@vexxhost.com W. https://vexxhost.com
Mohammed Naser wrote:
On Mon, Apr 6, 2020 at 10:53 AM Sean McGinnis <sean.mcginnis@gmx.com> wrote:
[...] Cinder has been useful stand alone for several years now, but I have also seen the reaction of "why would I use that, I don't need all of that OpenStack stuff".
I wonder if we need to do something better to highlight and message that there are certain components of OpenStack that are useful as independent components that can exist on their own.
I think that Sean here hit on the most critical point we need to drive. There's no amount of splitting that would resolve this.
I think a large part of the problem lies in the way we communicate about OpenStack. In particular, it is difficult to find a webpage that talks about ironic as a software component you might want to use. Practical exercise: find ironic on openstack.org. The best path involves two clicks and you only land on a component page[1] without much explanations. Or you reach https://www.openstack.org/bare-metal/ which is great, but more about the use case than the software. We are collectively to blame for this. The data on that component page is maintained by a repo[2] that I issued multiple calls for help for, and yet there aren't many changes proposed to expand the information presented there. And having a mix of a Foundation and a product website coexist at openstack.org means the information is buried so deeply someone born in this century would likely never find it. I think we need to improve on that, but it takes time due to how search engines work. I may sound like a broken record, but the solution in my opinion is to have basic, component-specific websites for components that can be run standalone. Think ironic.io (except .io domains are horrible and it's already taken). A website that would solely be dedicated to presenting Ironic, and would only mention OpenStack in the fineprint, or as a possible integration. It would list Ironic releases outside of openstack cycle context, and display Ironic docs without the openstack branding. That would go further to solve the issue than any governance change IMHO. Thoughts? [1] https://www.openstack.org/software/releases/train/components/ironic [2] https://opendev.org/osf/openstack-map/ -- Thierry Carrez (ttx)
Practical exercise: find ironic on openstack.org. The best path involves two clicks and you only land on a component page[1] without much explanations. Or you reach https://www.openstack.org/bare-metal/ which is great, but more about the use case than the software. We are collectively to blame for this. The data on that component page is maintained by a repo[2] that I issued multiple calls for help for, and yet there aren't many changes proposed to expand the information presented there. And having a mix of a Foundation and a product website coexist at openstack.org means the information is buried so deeply someone born in this century would likely never find it.
I think we need to improve on that, but it takes time due to how search engines work. I may sound like a broken record, but the solution in my opinion is to have basic, component-specific websites for components that can be run standalone. Think ironic.io (except .io domains are horrible and it's already taken). A website that would solely be dedicated to presenting Ironic, and would only mention OpenStack in the fineprint, or as a possible integration. It would list Ironic releases outside of openstack cycle context, and display Ironic docs without the openstack branding.
That would go further to solve the issue than any governance change IMHO. Thoughts?
[1] https://www.openstack.org/software/releases/train/components/ironic [2] https://opendev.org/osf/openstack-map/
I wonder if it could help if we have something like: used_independently: true in https://opendev.org/osf/openstack-map/src/branch/master/openstack_components...
Hi, On Tue, Apr 7, 2020 at 2:57 PM Thierry Carrez <thierry@openstack.org> wrote:
Mohammed Naser wrote:
On Mon, Apr 6, 2020 at 10:53 AM Sean McGinnis <sean.mcginnis@gmx.com> wrote:
[...] Cinder has been useful stand alone for several years now, but I have also seen the reaction of "why would I use that, I don't need all of that OpenStack stuff".
I wonder if we need to do something better to highlight and message that there are certain components of OpenStack that are useful as independent components that can exist on their own.
I think that Sean here hit on the most critical point we need to drive. There's no amount of splitting that would resolve this.
I think a large part of the problem lies in the way we communicate about OpenStack. In particular, it is difficult to find a webpage that talks about ironic as a software component you might want to use.
Practical exercise: find ironic on openstack.org. The best path involves two clicks and you only land on a component page[1] without much explanations. Or you reach https://www.openstack.org/bare-metal/ which is great, but more about the use case than the software. We are collectively to blame for this. The data on that component page is maintained by a repo[2] that I issued multiple calls for help for, and yet there aren't many changes proposed to expand the information presented there. And having a mix of a Foundation and a product website coexist at openstack.org means the information is buried so deeply someone born in this century would likely never find it.
I didn't even know about osf/openstack-map.. Either I'm living under a rock (possible) or there may be some improvements in the internal communication as well (not blaming anyone, we're all in it together).
I think we need to improve on that, but it takes time due to how search engines work. I may sound like a broken record, but the solution in my opinion is to have basic, component-specific websites for components that can be run standalone. Think ironic.io (except .io domains are horrible and it's already taken). A website that would solely be dedicated to presenting Ironic, and would only mention OpenStack in the fineprint, or as a possible integration. It would list Ironic releases outside of openstack cycle context, and display Ironic docs without the openstack branding.
That would go further to solve the issue than any governance change IMHO. Thoughts?
I think I've said it already, but it's a great idea and should be done no matter how this discussion ends up. Dmitry
[1] https://www.openstack.org/software/releases/train/components/ironic [2] https://opendev.org/osf/openstack-map/
-- Thierry Carrez (ttx)
Hi, On Mon, Apr 6, 2020 at 4:45 PM Mohammed Naser <mnaser@vexxhost.com> wrote:
Hi Dmitry,
Thank you for raising this. I think what you're looking for makes sense, I don't think splitting outside OpenStack is the right solution for this. There are many logistical issues in doing this.
I do agree with this.
First of all, it promotes even more bureaucracy within our community which is something that we're trying to split. "Ironic" and "OpenStack" becoming two separate pieces means that we've failed as a community to be able to deliver what OpenStack is. If we do this, we further promote the separation of our communities and that is not sustainable. With a dwindling contributor base, we'll find power in standing together in big groups, not by isolating ourselves to small islands.
This sounds a bit like the "us vs them" mentality, which I think may be hurting OpenStack now. I think we should be more open to the things that happen outside of our control. This also goes back to my points about Oslo and the bigger Python world.
Arguably, you would say that "well, Ironic is picking up outside OpenStack and we want to capitalize on that". I agree with you on that, I think we should absolutely do that. However, I think simply just becoming a top-level project is not the way to go about this. It will introduce a lot more work to our (already overwhelmed) OSF staff, it means maintaining a new identity, it means applying to be a pilot project and going through the whole process. It means that all existing developer may need to have to revise the way they do work because they have signed the CCLA for OpenStack and not "Ironic".
I fully agree, this is unfortunate.
We're adding a whole lot of bureaucray when the problem is messaging.
I've gone over your points below about what you think this will do and strongly suggest those alternatives.
Regards, Mohammed
On Wed, Apr 1, 2020 at 1:07 PM Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi everyone!
This topic should not come as a huge surprise for many, since it has
been raised numerous times in the past years. I have a feeling that the end of Ussuri, now that we’ve re-acquired our PTL and are on the verge of selecting new TC members, may be a good time to propose it for a formal discussion.
TL;DR I’m proposing to make Ironic a top-level project under opendev.org
and the OpenStack Foundation, following the same model as Zuul. I don’t propose severing current relationships with other OpenStack projects, nor making substantial changes in how the project is operated.
(And no, it’s not an April 1st joke)
Background =========
Ironic was born as a Nova plugin, but has grown way beyond this single
case since then. The first commit in Bifrost dates to February 2015. During these 5 years (hey, we forgot to celebrate!) it has developed into a commonly used data center management tool - and still based on standalone Ironic! The Metal3 project uses standalone Ironic as its hardware management backend. We haven’t been “just” a component of OpenStack for a while now, I think it’s time to officially recognize it.
And before you ask: in no case do I suggest scaling down our invaluable
integration with Nova. We’re observing a solid growth of deployments using Ironic as an addition to their OpenStack clouds, and this proposal doesn’t try to devalue this use case. The intention is to accept publicly and officially that it’s not the only or the main use case, but one of the main use cases. I don’t think it comes as a surprise to the Nova team.
Okay, so why? ===========
The first and the main reason is the ambiguity in our positioning. We do
see prospective operators and users confused by the perception that Ironic is a part of OpenStack, especially when it comes to the standalone use case. “But what if I don’t need OpenStack” is a question that I hear in most of these conversations. Changing from “a part of OpenStack” to “a FOSS tool that can integrate with OpenStack” is critical for our project to keep growing into new fields. To me personally it feels in line with how OpenDev itself is reaching into new areas beyond just the traditional IaaS. The next OpenDev even will apparently have a bare metal management track, so why not a top-level project for it?
Another reason is release cadence. We have repeatedly expressed the
desire to release Ironic and its sub-projects more often than we do now. Granted, *technically* we can release often even now. We can even abandon the current release model and switch to “independent”, but it doesn’t entirely solve the issue at hand. First, we don’t want to lose the notion of stable branches. One way or another, we need to support consumers with bug fix releases. Second, to become truly “independent” we’ll need to remove any tight coupling with any projects that do integrated releases. Which is, essentially, what I’m proposing here.
Finally, I believe that our independence (can I call it “Irexit”
please?) has already happened in reality, we just shy away from recognizing it. Look:
1. All integration points with other OpenStack projects are optional. 2. We can work fully standalone and even provide a project for that. 3. Many new features (RAID, BIOS to name a few) are exposed to standalone users much earlier than to those going through Nova. 4. We even have our own mini-scheduler (although its intention is not and has not been to replace the Placement service). 5. We make releases more often than the “core” OpenStack projects (but see above).
What we will do ============
This proposal involves in the short term: * Creating a new git namespace: opendev.org/ironic
We could totally do this for all existing projects honestly. I think the TC could probably be okay with this.
That's an interesting thought, actually. Maybe rather than one "openstack" namespace we can have a namespace per program? Like opendev.org/compute/nova, etc? This may also solve a part of the problem with oslo libraries adoption outside of OpenStack. opendev.org/libs/stevedore doesn't suggest that it belongs to openstack the same way as opendev.org/openstack/stevedore. And it will provide an obvious link between code names and purposes! Who can we talk to to make this happen?
* Creating a new website (name TBD, bare metal puns are welcome). * If we can have https://docs.opendev.org/ironic/, it may be just fine though.
Who's going to work on this website? It's important to not only have a website but keep it maintained, add more content, update it.
We do realize this, and we're already doing it, to some extent, with docs.o.o/ironic. It's unfortunate that we don't have dedicated designers and technical writers, but it's already our reality. Note that I don't suggest a highly dynamic web site. More of a consumer-oriented landing page like http://metal3.io/ and an umbrella-neutral hosting for documentation like http://tripleo.org/. I do agree with Thierry that it's doable without the actual split, but then it needs cooperation from the Foundation and the TC.
The website will have absolutely zero traction initially and we'll miss out on all the "traffic" that OpenStack.org gets. I think what we should actually do is redesign OpenStack.org so that it's a focused about the OpenStack projects and move all the foundation stuff to osf.dev -- In there, we can nail down the messaging of "you don't need all of OpenStack".
I don't think keeping ironic on openstack.org will help you nail it down.
* Keeping the same governance model, only adjusted to the necessary extent.
This is not easy, you'll have to come up with a whole governance, run elections, manage people. We already have volunteers that help do this inside OpenStack, why add all that extra layer?
* Keeping the same policies (reviews, CI, stable).
That seems reasonable to me
* Defining a new release cadence and stable branch support schedule.
If there is anything in the current model that doesn't suit you, please bring it up, and let's revise it. I've heard this repeated a lot as a complaint from the Ironic team and I've unfortunately not seen any proposal about an ideal alternative. We need to hear things to change things.
There is no ideal alternative, this is why most of these discussions get stuck. We may need to look at the Swift model since it seems closer to what we're aiming at. Which are: 1) More frequent releases with a possibility of bug-fix support for them (i.e. short-lived stable branches) and upgrades (time to ditch grenade?). 2) Stop release-to-release matching for interactions with other services (largely achieved by microversioning). 3) Support for non-coordinated releases in installation tools (okay, this one is fun, I'm not sure how to approach it).
In the long term we will consider (not necessary do): * Reshaping our CI to rely less on devstack and grenade (only use them for jobs involving OpenStack).
That seems reasonable to have more Ironic "standalone" jobs. It is important that _the_ biggest consumers *are* the OpenStack ones, let's not alienate them so we end up in a world of nothing new.
I'm not sure I get your proposal. If you suggest that we keep most of our testing on devstack/grenade/tempest with the whole OpenStack, this is something we're moving away from, no matter if split or not. The current approach to CI testing simply doesn't scale well enough to cover our feature set.
* Reducing or removing reliance on oslo libraries.
Why?
I've left some thoughts in my previous replies, but I don't quite like the way we're creating silos in OpenStack. Everyone is depending on oslo.utils, sometimes for one tiny helper (bool_from_string anyone?). Couldn't we move it to Python stdlib? I think the existence of our semi-private libraries discourages reaching out to the whole infrastructure. Everything depends on oslo.i18n, cannot we use the built-in gettext instead? Why is everything pulling in Babel even though nothing imports it? Sorry, this is turning into a rant, the essence of which is that we're taking a too easy approach to requirements.
* Stopping using rabbitmq for messaging (we’ve already made it optional).
Please. Please. Whatever you replace it with, just update oslo.messaging and make all of us happy to stop using it. It's hell.
I'd be happy to, but I think the oslo.messaging API is designed around the AMQP pattern too much. I'm getting back to my rant above: do all projects really need a messaging queue? When I asked this question in Ironic, we realized that we don't. We simply introduced JSON RPC support instead. Dmitry
* Integrating with non-OpenStack services (kubernetes?) and providing lighter alternatives (think, built-in authentication).
I support this, and I think there's nothing stopping you from doing that today. If there is, let's bring it up.
What we will NOT do ================
At least this proposal does NOT involve: * Stopping maintaining the Ironic virt driver in Nova. * Stopping running voting CI jobs with OpenStack services. * Dropping optional integration with OpenStack services. * Leaving OpenDev completely.
What do you think? ===============
Please let us know what you think about this proposal. Any hints on how to proceed with it, in case we reach a consensus, are also welcome.
Cheers, Dmitry
-- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser@vexxhost.com W. https://vexxhost.com
On 2020-04-07 12:03:53 +0200 (+0200), Dmitry Tantsur wrote:
On Mon, Apr 6, 2020 at 4:45 PM Mohammed Naser <mnaser@vexxhost.com> wrote: [...]
First of all, it promotes even more bureaucracy within our community which is something that we're trying to split. "Ironic" and "OpenStack" becoming two separate pieces means that we've failed as a community to be able to deliver what OpenStack is. If we do this, we further promote the separation of our communities and that is not sustainable. With a dwindling contributor base, we'll find power in standing together in big groups, not by isolating ourselves to small islands.
This sounds a bit like the "us vs them" mentality, which I think may be hurting OpenStack now. I think we should be more open to the things that happen outside of our control. This also goes back to my points about Oslo and the bigger Python world. [...]
The assertion that you can't include Ironic in OpenShift while it's still tainted with the OpenStack name seems like even more of an us vs them mentality, if I'm being totally honest. Can't we all just get along? Why *can't* OpenShift include OpenStack projects? I haven't seen this adequately explained.
Maybe rather than one "openstack" namespace we can have a namespace per program? Like opendev.org/compute/nova, etc? This may also solve a part of the problem with oslo libraries adoption outside of OpenStack.
This was in fact one of the options presented to the TC when we reorganized for the move from git.openstack.org to opendev.org, but the TC chose to have a single namespace for all official OpenStack deliverables. It can be revisited, though reshuffling every OpenStack deliverable repo at mass scale is going to be a nontrivial effort so is not something we should engage in without careful planning and consideration.
opendev.org/libs/stevedore doesn't suggest that it belongs to openstack the same way as opendev.org/openstack/stevedore. And it will provide an obvious link between code names and purposes! Who can we talk to to make this happen? [...]
This specific example likely won't work. Remember that OpenDev is shared by multiple communities, and so a "libs" namespace in OpenDev could be misleading if all the repositories within it are the product of a single community. On the other hand, something less generic like opendev.org/plugh/stevedore would be fine. (Side question, why not just the obvious opendev.org/oslo/stevedore? Is the name "Oslo" considered as tainted as "Openstack" by product managers?)
Note that I don't suggest a highly dynamic web site. More of a consumer-oriented landing page like http://metal3.io/ and an umbrella-neutral hosting for documentation like http://tripleo.org/. I do agree with Thierry that it's doable without the actual split, but then it needs cooperation from the Foundation and the TC. [...]
Apparently it doesn't need cooperation from the Foundation and the TC, since the TripleO team already did it without actually asking anyone whether they should.
1) More frequent releases with a possibility of bug-fix support for them (i.e. short-lived stable branches) and upgrades (time to ditch grenade?).
Existence of extended maintenance mode for stable branches is evidence that distros (in particular) want fewer longer-lived stable branches, not more shorter-lived ones.
2) Stop release-to-release matching for interactions with other services (largely achieved by microversioning).
Deciding what integrations you test in upgrades will likely get very interesting here. The compatibility matrix between Ironic releases and Nova releases gets increasingly complex the more releases you're supporting at a different cadence. Elsewhere you draw comparisons to Libvirt, which is probably a similar situation. Does Libvirt actually test whether they'll break Nova? Or do they just make whatever changes they want (with deference to their API stability policies) and expect consumers like Nova to perform their own independent evaluation of new releases? I have a feeling if Ironic's release cadence drifts significantly from OpenStack's, then the situation for Nova will be closer to what it is in their relationship with Libvirt today.
3) Support for non-coordinated releases in installation tools (okay, this one is fun, I'm not sure how to approach it). [...]
This part might not be as hard as you think. Deployment projects already deal with lots of dependencies which are not released on the same schedule as OpenStack (Libvirt as already mentioned, but hundreds upon hundreds more beyond). -- Jeremy Stanley
Hi, On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-04-07 12:03:53 +0200 (+0200), Dmitry Tantsur wrote:
On Mon, Apr 6, 2020 at 4:45 PM Mohammed Naser <mnaser@vexxhost.com> wrote: [...]
First of all, it promotes even more bureaucracy within our community which is something that we're trying to split. "Ironic" and "OpenStack" becoming two separate pieces means that we've failed as a community to be able to deliver what OpenStack is. If we do this, we further promote the separation of our communities and that is not sustainable. With a dwindling contributor base, we'll find power in standing together in big groups, not by isolating ourselves to small islands.
This sounds a bit like the "us vs them" mentality, which I think may be hurting OpenStack now. I think we should be more open to the things that happen outside of our control. This also goes back to my points about Oslo and the bigger Python world. [...]
The assertion that you can't include Ironic in OpenShift while it's still tainted with the OpenStack name seems like even more of an us vs them mentality, if I'm being totally honest. Can't we all just get along? Why *can't* OpenShift include OpenStack projects? I haven't seen this adequately explained.
It's less of a technical issue, but more of misunderstanding that including an OpenStack project does not involve literally installing OpenStack. And no matter what we think, for a lot of people OpenStack==Nova (another marketing issue to address?).
Maybe rather than one "openstack" namespace we can have a namespace per program? Like opendev.org/compute/nova, etc? This may also solve a part of the problem with oslo libraries adoption outside of OpenStack.
This was in fact one of the options presented to the TC when we reorganized for the move from git.openstack.org to opendev.org, but the TC chose to have a single namespace for all official OpenStack deliverables. It can be revisited, though reshuffling every OpenStack deliverable repo at mass scale is going to be a nontrivial effort so is not something we should engage in without careful planning and consideration.
opendev.org/libs/stevedore doesn't suggest that it belongs to openstack the same way as opendev.org/openstack/stevedore. And it will provide an obvious link between code names and purposes! Who can we talk to to make this happen? [...]
This specific example likely won't work. Remember that OpenDev is shared by multiple communities, and so a "libs" namespace in OpenDev could be misleading if all the repositories within it are the product of a single community. On the other hand, something less generic like opendev.org/plugh/stevedore would be fine. (Side question, why not just the obvious opendev.org/oslo/stevedore? Is the name "Oslo" considered as tainted as "Openstack" by product managers?)
Not a product manager, but probably fine if we position "oslo" appropriately (i.e. not as "libraries developed specifically for OpenStack").
Note that I don't suggest a highly dynamic web site. More of a consumer-oriented landing page like http://metal3.io/ and an umbrella-neutral hosting for documentation like http://tripleo.org/. I do agree with Thierry that it's doable without the actual split, but then it needs cooperation from the Foundation and the TC. [...]
Apparently it doesn't need cooperation from the Foundation and the TC, since the TripleO team already did it without actually asking anyone whether they should.
Well, we'd prefer to do it in cooperation, if possible and reasonable.
1) More frequent releases with a possibility of bug-fix support for them (i.e. short-lived stable branches) and upgrades (time to ditch grenade?).
Existence of extended maintenance mode for stable branches is evidence that distros (in particular) want fewer longer-lived stable branches, not more shorter-lived ones.
This problem is more complex than that. On one hand, large distributions want us to have stable branches every year or two. Even what we have is too much. On the other - we have small consumers who could benefit from just pulling the latest(ish) release and knowing that if a serous bug is found there, they won't have to update to the next feature (and potentially major) release.
2) Stop release-to-release matching for interactions with other services (largely achieved by microversioning).
Deciding what integrations you test in upgrades will likely get very interesting here. The compatibility matrix between Ironic releases and Nova releases gets increasingly complex the more releases you're supporting at a different cadence. Elsewhere you draw comparisons to Libvirt, which is probably a similar situation. Does Libvirt actually test whether they'll break Nova? Or do they just make whatever changes they want (with deference to their API stability policies) and expect consumers like Nova to perform their own independent evaluation of new releases? I have a feeling if Ironic's release cadence drifts significantly from OpenStack's, then the situation for Nova will be closer to what it is in their relationship with Libvirt today.
I think microversions (as much as I'm sceptical about them) are game-changing here. Nova can (and actually does) declare which microversions of Ironic it supports. Assuming we're good at microversioning (admittedly, we're not so much), this is all Nova ever has to care about. There's no even need to talk about versions of *ironic* required, just versions of the *API*. Anecdotally, some consumers do use newer Ironic with older Nova. I think CERN did that at some earlier point. Dmitry
3) Support for non-coordinated releases in installation tools (okay, this one is fun, I'm not sure how to approach it). [...]
This part might not be as hard as you think. Deployment projects already deal with lots of dependencies which are not released on the same schedule as OpenStack (Libvirt as already mentioned, but hundreds upon hundreds more beyond). -- Jeremy Stanley
On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote:
On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote: [...]
Why *can't* OpenShift include OpenStack projects? I haven't seen this adequately explained.
It's less of a technical issue, but more of misunderstanding that including an OpenStack project does not involve literally installing OpenStack. And no matter what we think, for a lot of people OpenStack==Nova (another marketing issue to address?). [...]
I don't understand why that would make a difference in this case, unless you're saying that the people who make architectural decisions about what's included in OpenShift have no actual familiarity with Ironic and OpenStack. If you know anyone who works at that company, can you help them understand the difference?
On one hand, large distributions want us to have stable branches every year or two. Even what we have is too much.
On the other - we have small consumers who could benefit from just pulling the latest(ish) release and knowing that if a serous bug is found there, they won't have to update to the next feature (and potentially major) release. [...]
This sounds like a problem shared by, well, basically every other project in OpenStack too. Perhaps it's an opportunity to collaborate on finding solutions. -- Jeremy Stanley
On Apr 9, 2020, at 1:24 PM, Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote:
On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote: [...]
Why *can't* OpenShift include OpenStack projects? I haven't seen this adequately explained.
It's less of a technical issue, but more of misunderstanding that including an OpenStack project does not involve literally installing OpenStack. And no matter what we think, for a lot of people OpenStack==Nova (another marketing issue to address?). [...]
I don't understand why that would make a difference in this case, unless you're saying that the people who make architectural decisions about what's included in OpenShift have no actual familiarity with Ironic and OpenStack. If you know anyone who works at that company, can you help them understand the difference?
This part of the argument has completely lost me. OpenShift 4 already includes Ironic. I’m not aware of any challenges that arose while making that happen that would have been solved or even made easier by Ironic being its own OIP.
On one hand, large distributions want us to have stable branches every year or two. Even what we have is too much.
On the other - we have small consumers who could benefit from just pulling the latest(ish) release and knowing that if a serous bug is found there, they won't have to update to the next feature (and potentially major) release. [...]
This sounds like a problem shared by, well, basically every other project in OpenStack too. Perhaps it's an opportunity to collaborate on finding solutions. -- Jeremy Stanley
On Thu, Apr 9, 2020 at 11:27 AM Doug Hellmann <doug@doughellmann.com> wrote:
On Apr 9, 2020, at 1:24 PM, Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote:
On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote: [...]
Why *can't* OpenShift include OpenStack projects? I haven't seen this adequately explained.
It's less of a technical issue, but more of misunderstanding that including an OpenStack project does not involve literally installing OpenStack. And no matter what we think, for a lot of people OpenStack==Nova (another marketing issue to address?). [...]
I don't understand why that would make a difference in this case, unless you're saying that the people who make architectural decisions about what's included in OpenShift have no actual familiarity with Ironic and OpenStack. If you know anyone who works at that company, can you help them understand the difference?
This part of the argument has completely lost me. OpenShift 4 already includes Ironic. I’m not aware of any challenges that arose while making that happen that would have been solved or even made easier by Ironic being its own OIP.
I'm sure one time challenges would have been greater initially, but ongoing headaches would be less IMHO. All headaches there are a result of how people want to do their jobs and achieve/interpret goals with perceptions while trying to match that up to policy and procedural frameworks. In essence, without further delineation, it is an uphill battle that focuses on finding the string "OpenStack" and directing it to that process.
On one hand, large distributions want us to have stable branches every year or two. Even what we have is too much.
On the other - we have small consumers who could benefit from just pulling the latest(ish) release and knowing that if a serous bug is found there, they won't have to update to the next feature (and potentially major) release. [...]
This sounds like a problem shared by, well, basically every other project in OpenStack too. Perhaps it's an opportunity to collaborate on finding solutions. -- Jeremy Stanley
On Apr 13, 2020, at 4:50 PM, Julia Kreger <juliaashleykreger@gmail.com> wrote:
On Thu, Apr 9, 2020 at 11:27 AM Doug Hellmann <doug@doughellmann.com <mailto:doug@doughellmann.com>> wrote:
On Apr 9, 2020, at 1:24 PM, Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote:
On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote: [...]
Why *can't* OpenShift include OpenStack projects? I haven't seen this adequately explained.
It's less of a technical issue, but more of misunderstanding that including an OpenStack project does not involve literally installing OpenStack. And no matter what we think, for a lot of people OpenStack==Nova (another marketing issue to address?). [...]
I don't understand why that would make a difference in this case, unless you're saying that the people who make architectural decisions about what's included in OpenShift have no actual familiarity with Ironic and OpenStack. If you know anyone who works at that company, can you help them understand the difference?
This part of the argument has completely lost me. OpenShift 4 already includes Ironic. I’m not aware of any challenges that arose while making that happen that would have been solved or even made easier by Ironic being its own OIP.
I'm sure one time challenges would have been greater initially, but ongoing headaches would be less IMHO. All headaches there are a result of how people want to do their jobs and achieve/interpret goals with perceptions while trying to match that up to policy and procedural frameworks. In essence, without further delineation, it is an uphill battle that focuses on finding the string "OpenStack" and directing it to that process.
That may be true, but those problems are internal to Red Hat, aren’t they?
On one hand, large distributions want us to have stable branches every year or two. Even what we have is too much.
On the other - we have small consumers who could benefit from just pulling the latest(ish) release and knowing that if a serous bug is found there, they won't have to update to the next feature (and potentially major) release. [...]
This sounds like a problem shared by, well, basically every other project in OpenStack too. Perhaps it's an opportunity to collaborate on finding solutions. -- Jeremy Stanley
On Mon, Apr 13, 2020 at 1:51 PM Doug Hellmann <doug@doughellmann.com> wrote:
On Apr 13, 2020, at 4:50 PM, Julia Kreger <juliaashleykreger@gmail.com> wrote:
On Thu, Apr 9, 2020 at 11:27 AM Doug Hellmann <doug@doughellmann.com> wrote:
On Apr 9, 2020, at 1:24 PM, Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote:
On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
[...]
Why *can't* OpenShift include OpenStack projects? I haven't seen this adequately explained.
It's less of a technical issue, but more of misunderstanding that including an OpenStack project does not involve literally installing OpenStack. And no matter what we think, for a lot of people OpenStack==Nova (another marketing issue to address?).
[...]
I don't understand why that would make a difference in this case, unless you're saying that the people who make architectural decisions about what's included in OpenShift have no actual familiarity with Ironic and OpenStack. If you know anyone who works at that company, can you help them understand the difference?
This part of the argument has completely lost me. OpenShift 4 already includes Ironic. I’m not aware of any challenges that arose while making that happen that would have been solved or even made easier by Ironic being its own OIP.
I'm sure one time challenges would have been greater initially, but ongoing headaches would be less IMHO. All headaches there are a result of how people want to do their jobs and achieve/interpret goals with perceptions while trying to match that up to policy and procedural frameworks. In essence, without further delineation, it is an uphill battle that focuses on finding the string "OpenStack" and directing it to that process.
That may be true, but those problems are internal to Red Hat, aren’t they?
In terms of OpenShift the product consuming Ironic, absolutely. But that doesn't change the larger picture reasons as to why this thread started.
On one hand, large distributions want us to have stable branches every year or two. Even what we have is too much.
On the other - we have small consumers who could benefit from just pulling the latest(ish) release and knowing that if a serous bug is found there, they won't have to update to the next feature (and potentially major) release.
[...]
This sounds like a problem shared by, well, basically every other project in OpenStack too. Perhaps it's an opportunity to collaborate on finding solutions. -- Jeremy Stanley
On Mon, Apr 13, 2020 at 10:53 PM Doug Hellmann <doug@doughellmann.com> wrote:
On Apr 13, 2020, at 4:50 PM, Julia Kreger <juliaashleykreger@gmail.com> wrote:
On Thu, Apr 9, 2020 at 11:27 AM Doug Hellmann <doug@doughellmann.com> wrote:
On Apr 9, 2020, at 1:24 PM, Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote:
On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
[...]
Why *can't* OpenShift include OpenStack projects? I haven't seen this adequately explained.
It's less of a technical issue, but more of misunderstanding that including an OpenStack project does not involve literally installing OpenStack. And no matter what we think, for a lot of people OpenStack==Nova (another marketing issue to address?).
[...]
I don't understand why that would make a difference in this case, unless you're saying that the people who make architectural decisions about what's included in OpenShift have no actual familiarity with Ironic and OpenStack. If you know anyone who works at that company, can you help them understand the difference?
This part of the argument has completely lost me. OpenShift 4 already includes Ironic. I’m not aware of any challenges that arose while making that happen that would have been solved or even made easier by Ironic being its own OIP.
I'm sure one time challenges would have been greater initially, but ongoing headaches would be less IMHO. All headaches there are a result of how people want to do their jobs and achieve/interpret goals with perceptions while trying to match that up to policy and procedural frameworks. In essence, without further delineation, it is an uphill battle that focuses on finding the string "OpenStack" and directing it to that process.
That may be true, but those problems are internal to Red Hat, aren’t they?
This particular one - yes. Sigh, I regret bringing up metal3, but I wanted an example that I'm well familiar with... It's not only about OpenShift. Please. Dmitry
On one hand, large distributions want us to have stable branches every year or two. Even what we have is too much.
On the other - we have small consumers who could benefit from just pulling the latest(ish) release and knowing that if a serous bug is found there, they won't have to update to the next feature (and potentially major) release.
[...]
This sounds like a problem shared by, well, basically every other project in OpenStack too. Perhaps it's an opportunity to collaborate on finding solutions. -- Jeremy Stanley
On Tue, 2020-04-14 at 11:47 +0200, Dmitry Tantsur wrote:
On Mon, Apr 13, 2020 at 10:53 PM Doug Hellmann <doug@doughellmann.com> wrote:
On Apr 13, 2020, at 4:50 PM, Julia Kreger <juliaashleykreger@gmail.com> wrote:
On Thu, Apr 9, 2020 at 11:27 AM Doug Hellmann <doug@doughellmann.com> wrote:
On Apr 9, 2020, at 1:24 PM, Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote:
On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
[...]
Why *can't* OpenShift include OpenStack projects? I haven't seen this adequately explained.
It's less of a technical issue, but more of misunderstanding that including an OpenStack project does not involve literally installing OpenStack. And no matter what we think, for a lot of people OpenStack==Nova (another marketing issue to address?).
[...]
I don't understand why that would make a difference in this case, unless you're saying that the people who make architectural decisions about what's included in OpenShift have no actual familiarity with Ironic and OpenStack. If you know anyone who works at that company, can you help them understand the difference?
This part of the argument has completely lost me. OpenShift 4 already includes Ironic. I’m not aware of any challenges that arose while making that happen that would have been solved or even made easier by Ironic being its own OIP.
I'm sure one time challenges would have been greater initially, but ongoing headaches would be less IMHO. All headaches there are a result of how people want to do their jobs and achieve/interpret goals with perceptions while trying to match that up to policy and procedural frameworks. In essence, without further delineation, it is an uphill battle that focuses on finding the string "OpenStack" and directing it to that process.
That may be true, but those problems are internal to Red Hat, aren’t they?
This particular one - yes. Sigh, I regret bringing up metal3, but I wanted an example that I'm well familiar with... It's not only about OpenShift. Please.
kayobe is perhaps an example although the fact it used a biforst deployed ironic to provision hardware for use with kolla-ansible to build a cloud slightly complicate that example. https://docs.openstack.org/kayobe/latest/ kayobe's use of bifrost/ironic is as a barematal host provider, it then treats openstack as an application that is deployed on those hosts. if it was useful to them to provision spark or k8s on those host instead i am sure they would jsut swap out kolla-ansible for another deployment tool to deploy there workload. this is effectivly how i would expect standalone ironic to be used most often. to prepare physical host with a base OS that is then manage by another tools that only/predomently deals with the software confituretion without having to worry about how the hardware was intially bootstraped. in that useage model none of the other openstack compnents are required although it may be useful to still have keystone and swift for auth and image storage althouth tftp works equally well in a static deployment.
Dmitry
On one hand, large distributions want us to have stable branches every year or two. Even what we have is too much.
On the other - we have small consumers who could benefit from just pulling the latest(ish) release and knowing that if a serous bug is found there, they won't have to update to the next feature (and potentially major) release.
[...]
This sounds like a problem shared by, well, basically every other project in OpenStack too. Perhaps it's an opportunity to collaborate on finding solutions. -- Jeremy Stanley
On Thu, Apr 9, 2020 at 7:26 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote:
On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote: [...]
Why *can't* OpenShift include OpenStack projects? I haven't seen this adequately explained.
It's less of a technical issue, but more of misunderstanding that including an OpenStack project does not involve literally installing OpenStack. And no matter what we think, for a lot of people OpenStack==Nova (another marketing issue to address?). [...]
I don't understand why that would make a difference in this case, unless you're saying that the people who make architectural decisions about what's included in OpenShift have no actual familiarity with Ironic and OpenStack. If you know anyone who works at that company, can you help them understand the difference?
Let's de-focus on OpenShift please. People who just need a bare metal management solution don't need to understand what OpenStack is. What would they assume from a quick search? The first link I've got by googling in a private window is our web site with: OpenStack software controls large pools of compute, storage, and networking resources throughout a datacenter, managed through a dashboard or via the OpenStack API. OpenStack works with popular enterprise and open source technologies making it ideal for heterogeneous infrastructure. Is it so unexpected they assume Ironic needs virtual machines to operate?
On one hand, large distributions want us to have stable branches every year or two. Even what we have is too much.
On the other - we have small consumers who could benefit from just pulling the latest(ish) release and knowing that if a serous bug is found there, they won't have to update to the next feature (and potentially major) release. [...]
This sounds like a problem shared by, well, basically every other project in OpenStack too. Perhaps it's an opportunity to collaborate on finding solutions.
+1000 although I'm not sure if all projects are interested in intermediate releases. Given how many follow the cycle-with-rc model, I doubt it. Dmitry
-- Jeremy Stanley
On Tue, 2020-04-14 at 11:45 +0200, Dmitry Tantsur wrote:
On Thu, Apr 9, 2020 at 7:26 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote:
On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
[...]
Why *can't* OpenShift include OpenStack projects? I haven't seen this adequately explained.
It's less of a technical issue, but more of misunderstanding that including an OpenStack project does not involve literally installing OpenStack. And no matter what we think, for a lot of people OpenStack==Nova (another marketing issue to address?).
[...]
I don't understand why that would make a difference in this case, unless you're saying that the people who make architectural decisions about what's included in OpenShift have no actual familiarity with Ironic and OpenStack. If you know anyone who works at that company, can you help them understand the difference?
Let's de-focus on OpenShift please. People who just need a bare metal management solution don't need to understand what OpenStack is. What would they assume from a quick search? The first link I've got by googling in a private window is our web site with:
OpenStack software controls large pools of compute, storage, and networking resources throughout a datacenter, managed through a dashboard or via the OpenStack API. OpenStack works with popular enterprise and open source technologies making it ideal for heterogeneous infrastructure.
Is it so unexpected they assume Ironic needs virtual machines to operate? yes since that at no point mentions viurtual machines. openstack is not a vm managment system. even in the early days form diablo or essex openstack cloud manage baremetal computes as well as contaienr via openvz and lxc then nova docker.
kubernetes is trying to redifine anything that is not contaienr native as not cloud but the compute context (container, vm or baremetal) provided by a cloud system is an implementation detail. the phrase "OpenStack software controls large pools of compute" does not imply vm any more then "ironic implies ipmi". ipmi is an important protocol in ironic and many of the vendor driver just ipmi with extentions but ironic does not directly imply it and openstack does not directly imply vms. i admit there has been some misteps in this regard in terms of openstack powered programe specificly the "OpenStack Powered Compute" trademark the fact it specificaly requires nova as the requirement is actully the compute api https://opendev.org/openstack/interop/src/branch/master/2018.02.json#L100-L1... can be consuing to some but it does not require the use of virtual machine dirver. the only requiremetn the list that cannot be achive with ironic today is compute-servers-resize. if the ironic node was pxe booted form a cinder volume resize would actully be doable in a diskless baremetal server scech as a blade or a rsd system. if you look at the apiu requriement objectivly it really only requires that the api exsits to create an instance but does not state way tthat instance is. it could be an lxc contaienr or any other virt dirver that fullfuils the api requirements. it would have been nice if this branding treated ironic and now zun i guess as first class citizens but i think that is an an artifict of the the fact the requiremetn are defiend in terms of api. compute-servers-create dose not mean create a vm even if that is what will happen most of the time.
On one hand, large distributions want us to have stable branches every year or two. Even what we have is too much.
On the other - we have small consumers who could benefit from just pulling the latest(ish) release and knowing that if a serous bug is found there, they won't have to update to the next feature (and potentially major) release.
[...]
This sounds like a problem shared by, well, basically every other project in OpenStack too. Perhaps it's an opportunity to collaborate on finding solutions.
+1000 although I'm not sure if all projects are interested in intermediate releases. Given how many follow the cycle-with-rc model, I doubt it.
Dmitry
-- Jeremy Stanley
On Tue, Apr 14, 2020 at 12:37 PM Sean Mooney <smooney@redhat.com> wrote:
On Tue, 2020-04-14 at 11:45 +0200, Dmitry Tantsur wrote:
On Thu, Apr 9, 2020 at 7:26 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote:
On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
[...]
Why *can't* OpenShift include OpenStack projects? I haven't seen this adequately explained.
It's less of a technical issue, but more of misunderstanding that including an OpenStack project does not involve literally installing OpenStack. And no matter what we think, for a lot of people OpenStack==Nova (another marketing issue to address?).
[...]
I don't understand why that would make a difference in this case, unless you're saying that the people who make architectural decisions about what's included in OpenShift have no actual familiarity with Ironic and OpenStack. If you know anyone who works at that company, can you help them understand the difference?
Let's de-focus on OpenShift please. People who just need a bare metal management solution don't need to understand what OpenStack is. What would they assume from a quick search? The first link I've got by googling in a private window is our web site with:
OpenStack software controls large pools of compute, storage, and networking resources throughout a datacenter, managed through a dashboard or via the OpenStack API. OpenStack works with popular enterprise and open source technologies making it ideal for heterogeneous infrastructure.
Is it so unexpected they assume Ironic needs virtual machines to operate? yes since that at no point mentions viurtual machines. openstack is not a vm managment system. even in the early days form diablo or essex openstack cloud manage baremetal computes as well as contaienr via openvz and lxc then nova docker.
Not everyone has the same background as you and me. The common understanding, to a large extent set by the big public cloud providers, is that IaaS == VMs. It has only started to change. Move away from our official resources, and things become even worse. One of the first links in duckduckgo: https://opensource.com/resources/what-is-openstack
OpenStack lets users deploy virtual machines and other instances that handle different tasks for managing a cloud environment on the fly. How many readers will guess bare metal in "other instances"? No explicit mentions of bare metal on the whole page.
My company also contributes, unfortunately: https://www.redhat.com/en/topics/openstack
OpenStack is an open source platform that uses pooled virtual resources to build and manage private and public clouds. A lot of references to virtualization and only one passing mention of "bare-metal" on the whole page.
kubernetes is trying to redifine anything that is not contaienr native as not cloud but the compute context (container, vm or baremetal) provided by a cloud system is an implementation detail.
the phrase "OpenStack software controls large pools of compute" does not
imply vm any more then "ironic implies ipmi". ipmi is an important protocol in ironic and many of the vendor driver just ipmi with extentions but ironic does not directly imply it and openstack does not directly imply vms.
Ironic is not a driver of OpenStack, and it's certainly not the most commonly used driver of Nova, so we cannot really draw parallels with IPMI here. Dmitry
i admit there has been some misteps in this regard in terms of openstack powered programe
specificly the "OpenStack Powered Compute" trademark
the fact it specificaly requires nova as the requirement is actully the compute api
https://opendev.org/openstack/interop/src/branch/master/2018.02.json#L100-L1... can be consuing to some but it does not require the use of virtual machine dirver.
the only requiremetn the list that cannot be achive with ironic today is compute-servers-resize. if the ironic node was pxe booted form a cinder volume resize would actully be doable in a diskless baremetal server scech as a blade or a rsd system.
if you look at the apiu requriement objectivly it really only requires that the api exsits to create an instance but does not state way tthat instance is. it could be an lxc contaienr or any other virt dirver that fullfuils the api requirements.
it would have been nice if this branding treated ironic and now zun i guess as first class citizens but i think that is an an artifict of the the fact the requiremetn are defiend in terms of api.
compute-servers-create dose not mean create a vm even if that is what will happen most of the time.
On one hand, large distributions want us to have stable branches every year or two. Even what we have is too much.
On the other - we have small consumers who could benefit from just pulling the latest(ish) release and knowing that if a serous bug is found there, they won't have to update to the next feature (and potentially major) release.
[...]
This sounds like a problem shared by, well, basically every other project in OpenStack too. Perhaps it's an opportunity to collaborate on finding solutions.
+1000 although I'm not sure if all projects are interested in
intermediate
releases. Given how many follow the cycle-with-rc model, I doubt it.
Dmitry
-- Jeremy Stanley
Good Point Sean. Does that lead to OpenStack powered BareMetal trademark? -----Original Message----- From: Sean Mooney <smooney@redhat.com> Sent: Tuesday, April 14, 2020 5:38 AM To: Dmitry Tantsur; openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project? [EXTERNAL EMAIL] On Tue, 2020-04-14 at 11:45 +0200, Dmitry Tantsur wrote:
On Thu, Apr 9, 2020 at 7:26 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote:
On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
[...]
Why *can't* OpenShift include OpenStack projects? I haven't seen this adequately explained.
It's less of a technical issue, but more of misunderstanding that including an OpenStack project does not involve literally installing OpenStack. And no matter what we think, for a lot of people OpenStack==Nova (another marketing issue to address?).
[...]
I don't understand why that would make a difference in this case, unless you're saying that the people who make architectural decisions about what's included in OpenShift have no actual familiarity with Ironic and OpenStack. If you know anyone who works at that company, can you help them understand the difference?
Let's de-focus on OpenShift please. People who just need a bare metal management solution don't need to understand what OpenStack is. What would they assume from a quick search? The first link I've got by googling in a private window is our web site with:
OpenStack software controls large pools of compute, storage, and networking resources throughout a datacenter, managed through a dashboard or via the OpenStack API. OpenStack works with popular enterprise and open source technologies making it ideal for heterogeneous infrastructure.
Is it so unexpected they assume Ironic needs virtual machines to operate? yes since that at no point mentions viurtual machines. openstack is not a vm managment system. even in the early days form diablo or essex openstack cloud manage baremetal computes as well as contaienr via openvz and lxc then nova docker.
kubernetes is trying to redifine anything that is not contaienr native as not cloud but the compute context (container, vm or baremetal) provided by a cloud system is an implementation detail. the phrase "OpenStack software controls large pools of compute" does not imply vm any more then "ironic implies ipmi". ipmi is an important protocol in ironic and many of the vendor driver just ipmi with extentions but ironic does not directly imply it and openstack does not directly imply vms. i admit there has been some misteps in this regard in terms of openstack powered programe specificly the "OpenStack Powered Compute" trademark the fact it specificaly requires nova as the requirement is actully the compute api https://opendev.org/openstack/interop/src/branch/master/2018.02.json#L100-L1... can be consuing to some but it does not require the use of virtual machine dirver. the only requiremetn the list that cannot be achive with ironic today is compute-servers-resize. if the ironic node was pxe booted form a cinder volume resize would actully be doable in a diskless baremetal server scech as a blade or a rsd system. if you look at the apiu requriement objectivly it really only requires that the api exsits to create an instance but does not state way tthat instance is. it could be an lxc contaienr or any other virt dirver that fullfuils the api requirements. it would have been nice if this branding treated ironic and now zun i guess as first class citizens but i think that is an an artifict of the the fact the requiremetn are defiend in terms of api. compute-servers-create dose not mean create a vm even if that is what will happen most of the time.
On one hand, large distributions want us to have stable branches every year or two. Even what we have is too much.
On the other - we have small consumers who could benefit from just pulling the latest(ish) release and knowing that if a serous bug is found there, they won't have to update to the next feature (and potentially major) release.
[...]
This sounds like a problem shared by, well, basically every other project in OpenStack too. Perhaps it's an opportunity to collaborate on finding solutions.
+1000 although I'm not sure if all projects are interested in +intermediate releases. Given how many follow the cycle-with-rc model, I doubt it.
Dmitry
-- Jeremy Stanley
On Tue, Apr 14, 2020 at 1:04 PM <Arkady.Kanevsky@dell.com> wrote:
Good Point Sean.
Does that lead to OpenStack powered BareMetal trademark?
I'm not entirely sure where your thought process is going. Could you elaborate a little on what your thinking? Thanks!
-----Original Message----- From: Sean Mooney <smooney@redhat.com> Sent: Tuesday, April 14, 2020 5:38 AM To: Dmitry Tantsur; openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project?
[EXTERNAL EMAIL]
On Tue, 2020-04-14 at 11:45 +0200, Dmitry Tantsur wrote:
On Thu, Apr 9, 2020 at 7:26 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote:
On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
[...]
Why *can't* OpenShift include OpenStack projects? I haven't seen this adequately explained.
It's less of a technical issue, but more of misunderstanding that including an OpenStack project does not involve literally installing OpenStack. And no matter what we think, for a lot of people OpenStack==Nova (another marketing issue to address?).
[...]
I don't understand why that would make a difference in this case, unless you're saying that the people who make architectural decisions about what's included in OpenShift have no actual familiarity with Ironic and OpenStack. If you know anyone who works at that company, can you help them understand the difference?
Let's de-focus on OpenShift please. People who just need a bare metal management solution don't need to understand what OpenStack is. What would they assume from a quick search? The first link I've got by googling in a private window is our web site with:
OpenStack software controls large pools of compute, storage, and networking resources throughout a datacenter, managed through a dashboard or via the OpenStack API. OpenStack works with popular enterprise and open source technologies making it ideal for heterogeneous infrastructure.
Is it so unexpected they assume Ironic needs virtual machines to operate? yes since that at no point mentions viurtual machines. openstack is not a vm managment system. even in the early days form diablo or essex openstack cloud manage baremetal computes as well as contaienr via openvz and lxc then nova docker.
kubernetes is trying to redifine anything that is not contaienr native as not cloud but the compute context (container, vm or baremetal) provided by a cloud system is an implementation detail. the phrase "OpenStack software controls large pools of compute" does not imply vm any more then "ironic implies ipmi". ipmi is an important protocol in ironic and many of the vendor driver just ipmi with extentions but ironic does not directly imply it and openstack does not directly imply vms.
i admit there has been some misteps in this regard in terms of openstack powered programe
specificly the "OpenStack Powered Compute" trademark
the fact it specificaly requires nova as the requirement is actully the compute api https://opendev.org/openstack/interop/src/branch/master/2018.02.json#L100-L1... can be consuing to some but it does not require the use of virtual machine dirver.
the only requiremetn the list that cannot be achive with ironic today is compute-servers-resize. if the ironic node was pxe booted form a cinder volume resize would actully be doable in a diskless baremetal server scech as a blade or a rsd system.
if you look at the apiu requriement objectivly it really only requires that the api exsits to create an instance but does not state way tthat instance is. it could be an lxc contaienr or any other virt dirver that fullfuils the api requirements.
it would have been nice if this branding treated ironic and now zun i guess as first class citizens but i think that is an an artifict of the the fact the requiremetn are defiend in terms of api.
compute-servers-create dose not mean create a vm even if that is what will happen most of the time.
On one hand, large distributions want us to have stable branches every year or two. Even what we have is too much.
On the other - we have small consumers who could benefit from just pulling the latest(ish) release and knowing that if a serous bug is found there, they won't have to update to the next feature (and potentially major) release.
[...]
This sounds like a problem shared by, well, basically every other project in OpenStack too. Perhaps it's an opportunity to collaborate on finding solutions.
+1000 although I'm not sure if all projects are interested in +intermediate releases. Given how many follow the cycle-with-rc model, I doubt it.
Dmitry
-- Jeremy Stanley
This is specific to https://www.openstack.org/marketplace/distros/ and private clouds. We have trademarks for Compute, storage, and for Full openstack. We can add trademark for baremetal for distros to market based on trademarks. It will be interesting if we can make that trademark of Open Infrastructure. Thanks, Arkady -----Original Message----- From: Julia Kreger <juliaashleykreger@gmail.com> Sent: Tuesday, April 14, 2020 3:37 PM To: Kanevsky, Arkady Cc: Sean Mooney; Dmitry Tantsur; openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project? [EXTERNAL EMAIL] On Tue, Apr 14, 2020 at 1:04 PM <Arkady.Kanevsky@dell.com> wrote:
Good Point Sean.
Does that lead to OpenStack powered BareMetal trademark?
I'm not entirely sure where your thought process is going. Could you elaborate a little on what your thinking? Thanks!
-----Original Message----- From: Sean Mooney <smooney@redhat.com> Sent: Tuesday, April 14, 2020 5:38 AM To: Dmitry Tantsur; openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project?
[EXTERNAL EMAIL]
On Tue, 2020-04-14 at 11:45 +0200, Dmitry Tantsur wrote:
On Thu, Apr 9, 2020 at 7:26 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote:
On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
[...]
Why *can't* OpenShift include OpenStack projects? I haven't seen this adequately explained.
It's less of a technical issue, but more of misunderstanding that including an OpenStack project does not involve literally installing OpenStack. And no matter what we think, for a lot of people OpenStack==Nova (another marketing issue to address?).
[...]
I don't understand why that would make a difference in this case, unless you're saying that the people who make architectural decisions about what's included in OpenShift have no actual familiarity with Ironic and OpenStack. If you know anyone who works at that company, can you help them understand the difference?
Let's de-focus on OpenShift please. People who just need a bare metal management solution don't need to understand what OpenStack is. What would they assume from a quick search? The first link I've got by googling in a private window is our web site with:
OpenStack software controls large pools of compute, storage, and networking resources throughout a datacenter, managed through a dashboard or via the OpenStack API. OpenStack works with popular enterprise and open source technologies making it ideal for heterogeneous infrastructure.
Is it so unexpected they assume Ironic needs virtual machines to operate? yes since that at no point mentions viurtual machines. openstack is not a vm managment system. even in the early days form diablo or essex openstack cloud manage baremetal computes as well as contaienr via openvz and lxc then nova docker.
kubernetes is trying to redifine anything that is not contaienr native as not cloud but the compute context (container, vm or baremetal) provided by a cloud system is an implementation detail. the phrase "OpenStack software controls large pools of compute" does not imply vm any more then "ironic implies ipmi". ipmi is an important protocol in ironic and many of the vendor driver just ipmi with extentions but ironic does not directly imply it and openstack does not directly imply vms.
i admit there has been some misteps in this regard in terms of openstack powered programe
specificly the "OpenStack Powered Compute" trademark
the fact it specificaly requires nova as the requirement is actully the compute api https://opendev.org/openstack/interop/src/branch/master/2018.02.json#L 100-L193 can be consuing to some but it does not require the use of virtual machine dirver.
the only requiremetn the list that cannot be achive with ironic today is compute-servers-resize. if the ironic node was pxe booted form a cinder volume resize would actully be doable in a diskless baremetal server scech as a blade or a rsd system.
if you look at the apiu requriement objectivly it really only requires that the api exsits to create an instance but does not state way tthat instance is. it could be an lxc contaienr or any other virt dirver that fullfuils the api requirements.
it would have been nice if this branding treated ironic and now zun i guess as first class citizens but i think that is an an artifict of the the fact the requiremetn are defiend in terms of api.
compute-servers-create dose not mean create a vm even if that is what will happen most of the time.
On one hand, large distributions want us to have stable branches every year or two. Even what we have is too much.
On the other - we have small consumers who could benefit from just pulling the latest(ish) release and knowing that if a serous bug is found there, they won't have to update to the next feature (and potentially major) release.
[...]
This sounds like a problem shared by, well, basically every other project in OpenStack too. Perhaps it's an opportunity to collaborate on finding solutions.
+1000 although I'm not sure if all projects are interested in +intermediate releases. Given how many follow the cycle-with-rc model, I doubt it.
Dmitry
-- Jeremy Stanley
On Wed, 2020-04-15 at 01:17 +0000, Arkady.Kanevsky@dell.com wrote:
This is specific to https://www.openstack.org/marketplace/distros/ and private clouds. sometime as a comunity we are such trolls https://www.openstack.org/marketplace/distros/distribution/devstack/ds-opens... i love that devstack is listed there. although given how long it took use to stop people running in production i guess it qualifies as it had market usage. We have trademarks for Compute, storage, and for Full openstack. We can add trademark for baremetal for distros to market based on trademarks. It will be interesting if we can make that trademark of Open Infrastructure.
Thanks, Arkady
-----Original Message----- From: Julia Kreger <juliaashleykreger@gmail.com> Sent: Tuesday, April 14, 2020 3:37 PM To: Kanevsky, Arkady Cc: Sean Mooney; Dmitry Tantsur; openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project?
[EXTERNAL EMAIL]
On Tue, Apr 14, 2020 at 1:04 PM <Arkady.Kanevsky@dell.com> wrote:
Good Point Sean.
Does that lead to OpenStack powered BareMetal trademark?
I'm not entirely sure where your thought process is going. Could you elaborate a little on what your thinking?
Thanks!
-----Original Message----- From: Sean Mooney <smooney@redhat.com> Sent: Tuesday, April 14, 2020 5:38 AM To: Dmitry Tantsur; openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project?
[EXTERNAL EMAIL]
On Tue, 2020-04-14 at 11:45 +0200, Dmitry Tantsur wrote:
On Thu, Apr 9, 2020 at 7:26 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote:
On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
[...]
Why *can't* OpenShift include OpenStack projects? I haven't seen this adequately explained.
It's less of a technical issue, but more of misunderstanding that including an OpenStack project does not involve literally installing OpenStack. And no matter what we think, for a lot of people OpenStack==Nova (another marketing issue to address?).
[...]
I don't understand why that would make a difference in this case, unless you're saying that the people who make architectural decisions about what's included in OpenShift have no actual familiarity with Ironic and OpenStack. If you know anyone who works at that company, can you help them understand the difference?
Let's de-focus on OpenShift please. People who just need a bare metal management solution don't need to understand what OpenStack is. What would they assume from a quick search? The first link I've got by googling in a private window is our web site with:
OpenStack software controls large pools of compute, storage, and networking resources throughout a datacenter, managed through a dashboard or via the OpenStack API. OpenStack works with popular enterprise and open source technologies making it ideal for heterogeneous infrastructure.
Is it so unexpected they assume Ironic needs virtual machines to operate?
yes since that at no point mentions viurtual machines. openstack is not a vm managment system. even in the early days form diablo or essex openstack cloud manage baremetal computes as well as contaienr via openvz and lxc then nova docker.
kubernetes is trying to redifine anything that is not contaienr native as not cloud but the compute context (container, vm or baremetal) provided by a cloud system is an implementation detail. the phrase "OpenStack software controls large pools of compute" does not imply vm any more then "ironic implies ipmi". ipmi is an important protocol in ironic and many of the vendor driver just ipmi with extentions but ironic does not directly imply it and openstack does not directly imply vms.
i admit there has been some misteps in this regard in terms of openstack powered programe
specificly the "OpenStack Powered Compute" trademark
the fact it specificaly requires nova as the requirement is actully the compute api https://opendev.org/openstack/interop/src/branch/master/2018.02.json#L 100-L193 can be consuing to some but it does not require the use of virtual machine dirver.
the only requiremetn the list that cannot be achive with ironic today is compute-servers-resize. if the ironic node was pxe booted form a cinder volume resize would actully be doable in a diskless baremetal server scech as a blade or a rsd system.
if you look at the apiu requriement objectivly it really only requires that the api exsits to create an instance but does not state way tthat instance is. it could be an lxc contaienr or any other virt dirver that fullfuils the api requirements.
it would have been nice if this branding treated ironic and now zun i guess as first class citizens but i think that is an an artifict of the the fact the requiremetn are defiend in terms of api.
compute-servers-create dose not mean create a vm even if that is what will happen most of the time.
On one hand, large distributions want us to have stable branches every year or two. Even what we have is too much.
On the other - we have small consumers who could benefit from just pulling the latest(ish) release and knowing that if a serous bug is found there, they won't have to update to the next feature (and potentially major) release.
[...]
This sounds like a problem shared by, well, basically every other project in OpenStack too. Perhaps it's an opportunity to collaborate on finding solutions.
+1000 although I'm not sure if all projects are interested in +intermediate releases. Given how many follow the cycle-with-rc model, I doubt it.
Dmitry
-- Jeremy Stanley
On Wed, Apr 15, 2020 at 12:12:08PM +0100, Sean Mooney wrote:
On Wed, 2020-04-15 at 01:17 +0000, Arkady.Kanevsky@dell.com wrote:
This is specific to https://www.openstack.org/marketplace/distros/ and private clouds. sometime as a comunity we are such trolls https://www.openstack.org/marketplace/distros/distribution/devstack/ds-opens... i love that devstack is listed there. although given how long it took use to stop people running in production i guess it qualifies as it had market usage.
This actually isn't devstack the development tool, it is a company named Devstack that is an OpenStack vendor (not confusing at all :p). Their website is: http://www.devstack.co.kr I hope they're not basing their offerings on devstack the tool, but I have no idea. -Matt Treinish
We have trademarks for Compute, storage, and for Full openstack. We can add trademark for baremetal for distros to market based on trademarks. It will be interesting if we can make that trademark of Open Infrastructure.
Thanks, Arkady
-----Original Message----- From: Julia Kreger <juliaashleykreger@gmail.com> Sent: Tuesday, April 14, 2020 3:37 PM To: Kanevsky, Arkady Cc: Sean Mooney; Dmitry Tantsur; openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project?
[EXTERNAL EMAIL]
On Tue, Apr 14, 2020 at 1:04 PM <Arkady.Kanevsky@dell.com> wrote:
Good Point Sean.
Does that lead to OpenStack powered BareMetal trademark?
I'm not entirely sure where your thought process is going. Could you elaborate a little on what your thinking?
Thanks!
-----Original Message----- From: Sean Mooney <smooney@redhat.com> Sent: Tuesday, April 14, 2020 5:38 AM To: Dmitry Tantsur; openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project?
[EXTERNAL EMAIL]
On Tue, 2020-04-14 at 11:45 +0200, Dmitry Tantsur wrote:
On Thu, Apr 9, 2020 at 7:26 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote:
On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
[...]
> Why *can't* OpenShift include OpenStack projects? I haven't > seen this adequately explained.
It's less of a technical issue, but more of misunderstanding that including an OpenStack project does not involve literally installing OpenStack. And no matter what we think, for a lot of people OpenStack==Nova (another marketing issue to address?).
[...]
I don't understand why that would make a difference in this case, unless you're saying that the people who make architectural decisions about what's included in OpenShift have no actual familiarity with Ironic and OpenStack. If you know anyone who works at that company, can you help them understand the difference?
Let's de-focus on OpenShift please. People who just need a bare metal management solution don't need to understand what OpenStack is. What would they assume from a quick search? The first link I've got by googling in a private window is our web site with:
OpenStack software controls large pools of compute, storage, and networking resources throughout a datacenter, managed through a dashboard or via the OpenStack API. OpenStack works with popular enterprise and open source technologies making it ideal for heterogeneous infrastructure.
Is it so unexpected they assume Ironic needs virtual machines to operate?
yes since that at no point mentions viurtual machines. openstack is not a vm managment system. even in the early days form diablo or essex openstack cloud manage baremetal computes as well as contaienr via openvz and lxc then nova docker.
kubernetes is trying to redifine anything that is not contaienr native as not cloud but the compute context (container, vm or baremetal) provided by a cloud system is an implementation detail. the phrase "OpenStack software controls large pools of compute" does not imply vm any more then "ironic implies ipmi". ipmi is an important protocol in ironic and many of the vendor driver just ipmi with extentions but ironic does not directly imply it and openstack does not directly imply vms.
i admit there has been some misteps in this regard in terms of openstack powered programe
specificly the "OpenStack Powered Compute" trademark
the fact it specificaly requires nova as the requirement is actully the compute api https://opendev.org/openstack/interop/src/branch/master/2018.02.json#L 100-L193 can be consuing to some but it does not require the use of virtual machine dirver.
the only requiremetn the list that cannot be achive with ironic today is compute-servers-resize. if the ironic node was pxe booted form a cinder volume resize would actully be doable in a diskless baremetal server scech as a blade or a rsd system.
if you look at the apiu requriement objectivly it really only requires that the api exsits to create an instance but does not state way tthat instance is. it could be an lxc contaienr or any other virt dirver that fullfuils the api requirements.
it would have been nice if this branding treated ironic and now zun i guess as first class citizens but i think that is an an artifict of the the fact the requiremetn are defiend in terms of api.
compute-servers-create dose not mean create a vm even if that is what will happen most of the time.
On one hand, large distributions want us to have stable branches every year or two. Even what we have is too much.
On the other - we have small consumers who could benefit from just pulling the latest(ish) release and knowing that if a serous bug is found there, they won't have to update to the next feature (and potentially major) release.
[...]
This sounds like a problem shared by, well, basically every other project in OpenStack too. Perhaps it's an opportunity to collaborate on finding solutions.
+1000 although I'm not sure if all projects are interested in +intermediate releases. Given how many follow the cycle-with-rc model, I doubt it.
Dmitry
-- Jeremy Stanley
On Wed, Apr 15, 2020 at 11:17 AM Matthew Treinish <mtreinish@kortar.org> wrote:
On Wed, Apr 15, 2020 at 12:12:08PM +0100, Sean Mooney wrote:
On Wed, 2020-04-15 at 01:17 +0000, Arkady.Kanevsky@dell.com wrote:
This is specific to https://www.openstack.org/marketplace/distros/ and private clouds. sometime as a comunity we are such trolls
https://www.openstack.org/marketplace/distros/distribution/devstack/ds-opens...
i love that devstack is listed there. although given how long it took use to stop people running in production i guess it qualifies as it had market usage.
This actually isn't devstack the development tool, it is a company named Devstack that is an OpenStack vendor (not confusing at all :p). Their website is:
I hope they're not basing their offerings on devstack the tool, but I have no idea.
-Matt Treinish
We have trademarks for Compute, storage, and for Full openstack. We can add trademark for baremetal for distros to market based on trademarks. It will be interesting if we can make that trademark of Open Infrastructure.
Thanks, Arkady
-----Original Message----- From: Julia Kreger <juliaashleykreger@gmail.com> Sent: Tuesday, April 14, 2020 3:37 PM To: Kanevsky, Arkady Cc: Sean Mooney; Dmitry Tantsur; openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project?
[EXTERNAL EMAIL]
On Tue, Apr 14, 2020 at 1:04 PM <Arkady.Kanevsky@dell.com> wrote:
Good Point Sean.
Does that lead to OpenStack powered BareMetal trademark?
I'm not entirely sure where your thought process is going. Could you elaborate a little on what your thinking?
Thanks!
-----Original Message----- From: Sean Mooney <smooney@redhat.com> Sent: Tuesday, April 14, 2020 5:38 AM To: Dmitry Tantsur; openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev
project?
[EXTERNAL EMAIL]
On Tue, 2020-04-14 at 11:45 +0200, Dmitry Tantsur wrote:
On Thu, Apr 9, 2020 at 7:26 PM Jeremy Stanley <fungi@yuggoth.org>
wrote:
On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote: > On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <
fungi@yuggoth.org> wrote:
[...] > > Why *can't* OpenShift include OpenStack projects? I haven't > > seen this adequately explained. > > It's less of a technical issue, but more of misunderstanding > that including an OpenStack project does not involve literally > installing OpenStack. And no matter what we think, for a lot
of
> people OpenStack==Nova (another marketing issue to address?).
[...]
I don't understand why that would make a difference in this case, unless you're saying that the people who make architectural decisions about what's included in OpenShift have no actual familiarity with Ironic and OpenStack. If you know anyone who works at that company, can you help them understand the difference?
Let's de-focus on OpenShift please. People who just need a bare metal management solution don't need to understand what OpenStack is. What would they assume from a quick search? The first link I've got by googling in a private window is our web site with:
OpenStack software controls large pools of compute, storage, and networking resources throughout a datacenter, managed through a dashboard or via the OpenStack API. OpenStack works with popular enterprise and open source technologies making it ideal for heterogeneous infrastructure.
Is it so unexpected they assume Ironic needs virtual machines to operate?
yes since that at no point mentions viurtual machines. openstack is not a vm managment system. even in the early days form diablo or essex openstack cloud manage baremetal computes as well as contaienr via openvz and lxc then nova docker.
kubernetes is trying to redifine anything that is not contaienr native as not cloud but the compute context (container, vm or baremetal) provided by a cloud system is an implementation detail. the phrase "OpenStack software controls large pools of compute" does not imply vm any more then "ironic implies ipmi". ipmi is an important protocol in ironic and many of the vendor driver just ipmi with extentions but ironic does not directly imply it and openstack does not directly imply vms.
i admit there has been some misteps in this regard in terms of openstack powered programe
specificly the "OpenStack Powered Compute" trademark
the fact it specificaly requires nova as the requirement is actully the compute api
https://opendev.org/openstack/interop/src/branch/master/2018.02.json#L
100-L193 can be consuing to some but it does not require the use of virtual machine dirver.
the only requiremetn the list that cannot be achive with ironic today is compute-servers-resize. if the ironic node was pxe booted form a cinder volume resize would actully be doable in a diskless baremetal server scech as a blade or a rsd system.
if you look at the apiu requriement objectivly it really only requires that the api exsits to create an instance but does not state way tthat instance is. it could be an lxc contaienr or any other virt dirver that fullfuils the api requirements.
it would have been nice if this branding treated ironic and now zun i guess as first class citizens but i think that is an an artifict of the the fact the requiremetn are defiend in terms of api.
compute-servers-create dose not mean create a vm even if that is what will happen most of the time.
> On one hand, large distributions want us to have stable
branches
> every year or two. Even what we have is too much. > > On the other - we have small consumers who could benefit from > just pulling the latest(ish) release and knowing that if a > serous bug is found there, they won't have to update to the next > feature (and potentially major) release.
[...]
This sounds like a problem shared by, well, basically every other project in OpenStack too. Perhaps it's an opportunity to collaborate on finding solutions.
+1000 although I'm not sure if all projects are interested in +intermediate releases. Given how many follow the cycle-with-rc model, I doubt it.
Dmitry
-- Jeremy Stanley
I know I am probably going to be lit on fire for this... but anyways here goes it. Why does anyone care if ironic wants to move to a top level project or not? I would think the leaders of this project are most involved in the needs of what it's going to take for continued success. If the team that is doing the heavy lifting wants something, then I feel it's our position to enable success. It looks a lot to me like this is what the people who work on the project want (and if you don't have that data maybe poll your own team), So why the push back? The resources we do have are clearly dwindling - lets not give people any more reasons to leave if we can avoid it. Happiness in what you do and where you do it is a thing. If Ironic wants to move, and it's not damaging to other projects. I think we should make that as easy as possible. All the rest seems like a bunch of noise. /donnyd cowers in the corner waiting for blunt objects to be thrown -- ~/DonnyD C: 805 814 6800 "No mission too difficult. No sacrifice too great. Duty First"
On Wed, Apr 15, 2020 at 8:41 AM Donny Davis <donny@fortnebula.com> wrote:
[trim]
I know I am probably going to be lit on fire for this... but anyways here goes it.
Why does anyone care if ironic wants to move to a top level project or not? I would think the leaders of this project are most involved in the needs of what it's going to take for continued success. If the team that is doing the heavy lifting wants something, then I feel it's our position to enable success. It looks a lot to me like this is what the people who work on the project want (and if you don't have that data maybe poll your own team),
So why the push back?
The resources we do have are clearly dwindling - lets not give people any more reasons to leave if we can avoid it. Happiness in what you do and where you do it is a thing.
If Ironic wants to move, and it's not damaging to other projects. I think we should make that as easy as possible. All the rest seems like a bunch of noise.
/donnyd cowers in the corner waiting for blunt objects to be thrown -- ~/DonnyD C: 805 814 6800 "No mission too difficult. No sacrifice too great. Duty First"
No blunt objects shall be thrown as feared! At least on my watch! :) People care because they are invested in the community as a whole, and I think the thought of such a major change does bring fear. I think that is totally natural and honestly I feel the same way. Also at the same time, I think we risk letting the fear control us. Thus prohibits us and prevents us from what may be the right direction. In part, that is also why we need to talk through these things. :) That is my perception as to why there is push back. Everyone has a different context, and that brings value to the discussion.
On 2020-04-15 15:46:04 -0700 (-0700), Julia Kreger wrote: [...]
People care because they are invested in the community as a whole, and I think the thought of such a major change does bring fear. I think that is totally natural and honestly I feel the same way. Also at the same time, I think we risk letting the fear control us. Thus prohibits us and prevents us from what may be the right direction. In part, that is also why we need to talk through these things. :) [...]
In my case, I just want to make sure folks are approaching these sorts of decisions by first identifying problems and only *then* moving to discussing solutions. Otherwise there's a risk that a lot of effort and resources are wasted on work which doesn't solve whatever needs solving. Hear each of the arguments (for and against) with a critical ear, and ask whether they're good solutions for the problems you've identified. Above all, try to avoid the trap of using problems to justify a solution which has already been chosen for other reasons. When the discussion starts out as a proposal for some particular solution, that's how it tends to come across. -- Jeremy Stanley
On 4/15/20 6:47 PM, Jeremy Stanley wrote:
On 2020-04-15 15:46:04 -0700 (-0700), Julia Kreger wrote: [...]
People care because they are invested in the community as a whole, and I think the thought of such a major change does bring fear. I think that is totally natural and honestly I feel the same way. Also at the same time, I think we risk letting the fear control us. Thus prohibits us and prevents us from what may be the right direction. In part, that is also why we need to talk through these things. :) [...]
In my case, I just want to make sure folks are approaching these sorts of decisions by first identifying problems and only *then* moving to discussing solutions. Otherwise there's a risk that a lot of effort and resources are wasted on work which doesn't solve whatever needs solving. Hear each of the arguments (for and against) with a critical ear, and ask whether they're good solutions for the problems you've identified.
Above all, try to avoid the trap of using problems to justify a solution which has already been chosen for other reasons. When the discussion starts out as a proposal for some particular solution, that's how it tends to come across.
We also have other projects that can and are used standalone. Cinder has been enabled for that for years, but I'm pretty sure there are others. So part of this long discussion, I think, is to make sure whatever action the community takes is one that makes sense and does not confuse the situation even more. Looking at it as a whole, does it make sense for any service that can be used standalone to become its own top level project. If it's only after a certain level of adoption, what is the threshold or how is that decided? Is there a better way to not disrupt the community while still addressing the needs of the projects that want to stand out more as something that could be seen as more independent? There isn't really an easy answer here, so it's worth getting input from those involved in the community to make sure we don't go down a path we are going to regret later. Sean
On Thu, 2020-04-16 at 07:29 -0500, Sean McGinnis wrote:
On 4/15/20 6:47 PM, Jeremy Stanley wrote:
On 2020-04-15 15:46:04 -0700 (-0700), Julia Kreger wrote: [...]
People care because they are invested in the community as a whole, and I think the thought of such a major change does bring fear. I think that is totally natural and honestly I feel the same way. Also at the same time, I think we risk letting the fear control us. Thus prohibits us and prevents us from what may be the right direction. In part, that is also why we need to talk through these things. :)
[...]
In my case, I just want to make sure folks are approaching these sorts of decisions by first identifying problems and only *then* moving to discussing solutions. Otherwise there's a risk that a lot of effort and resources are wasted on work which doesn't solve whatever needs solving. Hear each of the arguments (for and against) with a critical ear, and ask whether they're good solutions for the problems you've identified.
Above all, try to avoid the trap of using problems to justify a solution which has already been chosen for other reasons. When the discussion starts out as a proposal for some particular solution, that's how it tends to come across.
We also have other projects that can and are used standalone. Cinder has been enabled for that for years, but I'm pretty sure there are others. well swift comes to mind im pretty sure it can run standalone or at most using keystone. speaking of which keystone can be used standablone in open source mano or keystone. im not aware of anyone using placment standalone but it would also be a good candidate. glance has no depency on other project to function out side of perhaps keystone. im ignoring oslo deps in all cases above by the way since libary dependises are not an overhead for the operator they are an over head for the distro maintaienr or you can grab them form pip.
things like horizon and heat by there nature obviously cannot be used standalone but many of the lower level porject could be. if they are actully used standalone is another matter.
So part of this long discussion, I think, is to make sure whatever action the community takes is one that makes sense and does not confuse the situation even more. Looking at it as a whole, does it make sense for any service that can be used standalone to become its own top level project. If it's only after a certain level of adoption, what is the threshold or how is that decided? Is there a better way to not disrupt the community while still addressing the needs of the projects that want to stand out more as something that could be seen as more independent?
There isn't really an easy answer here, so it's worth getting input from those involved in the community to make sure we don't go down a path we are going to regret later.
Sean
On Thu, 2020-04-16 at 14:07 +0100, Sean Mooney wrote:
On Thu, 2020-04-16 at 07:29 -0500, Sean McGinnis wrote:
On 4/15/20 6:47 PM, Jeremy Stanley wrote:
On 2020-04-15 15:46:04 -0700 (-0700), Julia Kreger wrote: [...]
People care because they are invested in the community as a whole, and I think the thought of such a major change does bring fear. I think that is totally natural and honestly I feel the same way. Also at the same time, I think we risk letting the fear control us. Thus prohibits us and prevents us from what may be the right direction. In part, that is also why we need to talk through these things. :)
[...]
In my case, I just want to make sure folks are approaching these sorts of decisions by first identifying problems and only *then* moving to discussing solutions. Otherwise there's a risk that a lot of effort and resources are wasted on work which doesn't solve whatever needs solving. Hear each of the arguments (for and against) with a critical ear, and ask whether they're good solutions for the problems you've identified.
Above all, try to avoid the trap of using problems to justify a solution which has already been chosen for other reasons. When the discussion starts out as a proposal for some particular solution, that's how it tends to come across.
We also have other projects that can and are used standalone. Cinder has been enabled for that for years, but I'm pretty sure there are others.
well swift comes to mind im pretty sure it can run standalone or at most using keystone. speaking of which keystone can be used standablone in open source mano or keystone. i ment to say kubernetes kubctl and your k8s cluster can be configured to use keystone for auth.
im not aware of anyone using placment standalone but it would also be a good candidate. glance has no depency on other project to function out side of perhaps keystone. im ignoring oslo deps in all cases above by the way since libary dependises are not an overhead for the operator they are an over head for the distro maintaienr or you can grab them form pip.
things like horizon and heat by there nature obviously cannot be used standalone but many of the lower level porject could be. if they are actully used standalone is another matter.
So part of this long discussion, I think, is to make sure whatever action the community takes is one that makes sense and does not confuse the situation even more. Looking at it as a whole, does it make sense for any service that can be used standalone to become its own top level project. If it's only after a certain level of adoption, what is the threshold or how is that decided? Is there a better way to not disrupt the community while still addressing the needs of the projects that want to stand out more as something that could be seen as more independent?
There isn't really an easy answer here, so it's worth getting input from those involved in the community to make sure we don't go down a path we are going to regret later.
Sean
On 16/04/20 14:07 +0100, Sean Mooney wrote:
On Thu, 2020-04-16 at 07:29 -0500, Sean McGinnis wrote:
On 4/15/20 6:47 PM, Jeremy Stanley wrote:
On 2020-04-15 15:46:04 -0700 (-0700), Julia Kreger wrote: [...]
People care because they are invested in the community as a whole, and I think the thought of such a major change does bring fear. I think that is totally natural and honestly I feel the same way. Also at the same time, I think we risk letting the fear control us. Thus prohibits us and prevents us from what may be the right direction. In part, that is also why we need to talk through these things. :)
[...]
In my case, I just want to make sure folks are approaching these sorts of decisions by first identifying problems and only *then* moving to discussing solutions. Otherwise there's a risk that a lot of effort and resources are wasted on work which doesn't solve whatever needs solving. Hear each of the arguments (for and against) with a critical ear, and ask whether they're good solutions for the problems you've identified.
Above all, try to avoid the trap of using problems to justify a solution which has already been chosen for other reasons. When the discussion starts out as a proposal for some particular solution, that's how it tends to come across.
We also have other projects that can and are used standalone. Cinder has been enabled for that for years, but I'm pretty sure there are others. well swift comes to mind im pretty sure it can run standalone or at most using keystone. speaking of which keystone can be used standablone in open source mano or keystone. im not aware of anyone using placment standalone but it would also be a good candidate. glance has no depency on other project to function out side of perhaps keystone. im ignoring oslo deps in all cases above by the way since libary dependises are not an overhead for the operator they are an over head for the distro maintaienr or you can grab them form pip.
things like horizon and heat by there nature obviously cannot be used standalone but many of the lower level porject could be. if they are actully used standalone is another matter.
Manila can run standalone or with keystone only. With keystone is the way we position it (with CSI plugin) for running multiple Kubernetes clusters as isolated tenants with common storage infrastructure. It would be handy to also have other, loosely coupled, multi-tenant service infrastructure services, including one that offers bare metal compute instances, developed in a community dedicated to the four open principles [1] and aligned with a common technical vision [2]. As I follow this thread I'm trying to understand what "Ironic moving out of OpenStack" would mean in terms of the previous paragraph. That doesn't have anything do do with fear of change or wanting to control the destinies of other developers. [1] https://governance.openstack.org/tc/reference/opens.html [2] https://governance.openstack.org/tc/reference/technical-vision.html
So part of this long discussion, I think, is to make sure whatever action the community takes is one that makes sense and does not confuse the situation even more. Looking at it as a whole, does it make sense for any service that can be used standalone to become its own top level project. If it's only after a certain level of adoption, what is the threshold or how is that decided? Is there a better way to not disrupt the community while still addressing the needs of the projects that want to stand out more as something that could be seen as more independent?
There isn't really an easy answer here, so it's worth getting input from those involved in the community to make sure we don't go down a path we are going to regret later.
Sean
On Thu, Apr 16, 2020 at 10:27 AM Tom Barron <tpb@dyncloud.net> wrote:
On 16/04/20 14:07 +0100, Sean Mooney wrote:
On Thu, 2020-04-16 at 07:29 -0500, Sean McGinnis wrote:
On 4/15/20 6:47 PM, Jeremy Stanley wrote:
On 2020-04-15 15:46:04 -0700 (-0700), Julia Kreger wrote: [...]
People care because they are invested in the community as a whole, and I think the thought of such a major change does bring fear. I think that is totally natural and honestly I feel the same way. Also at the same time, I think we risk letting the fear control us. Thus prohibits us and prevents us from what may be the right direction. In part, that is also why we need to talk through these things. :)
[...]
In my case, I just want to make sure folks are approaching these sorts of decisions by first identifying problems and only *then* moving to discussing solutions. Otherwise there's a risk that a lot of effort and resources are wasted on work which doesn't solve whatever needs solving. Hear each of the arguments (for and against) with a critical ear, and ask whether they're good solutions for the problems you've identified.
Above all, try to avoid the trap of using problems to justify a solution which has already been chosen for other reasons. When the discussion starts out as a proposal for some particular solution, that's how it tends to come across.
We also have other projects that can and are used standalone. Cinder has been enabled for that for years, but I'm pretty sure there are others. well swift comes to mind im pretty sure it can run standalone or at most using keystone. speaking of which keystone can be used standablone in open source mano or keystone. im not aware of anyone using placment standalone but it would also be a good candidate. glance has no depency on other project to function out side of perhaps keystone. im ignoring oslo deps in all cases above by the way since libary dependises are not an overhead for the operator they are an over head for the distro maintaienr or you can grab them form pip.
things like horizon and heat by there nature obviously cannot be used standalone but many of the lower level porject could be. if they are actully used standalone is another matter.
Manila can run standalone or with keystone only. With keystone is the way we position it (with CSI plugin) for running multiple Kubernetes clusters as isolated tenants with common storage infrastructure.
It would be handy to also have other, loosely coupled, multi-tenant service infrastructure services, including one that offers bare metal compute instances, developed in a community dedicated to the four open principles [1] and aligned with a common technical vision [2].
As I follow this thread I'm trying to understand what "Ironic moving out of OpenStack" would mean in terms of the previous paragraph. That doesn't have anything do do with fear of change or wanting to control the destinies of other developers.
[1] https://governance.openstack.org/tc/reference/opens.html
[2] https://governance.openstack.org/tc/reference/technical-vision.html
So part of this long discussion, I think, is to make sure whatever action the community takes is one that makes sense and does not confuse the situation even more. Looking at it as a whole, does it make sense for any service that can be used standalone to become its own top level project. If it's only after a certain level of adoption, what is the threshold or how is that decided? Is there a better way to not disrupt the community while still addressing the needs of the projects that want to stand out more as something that could be seen as more independent?
There isn't really an easy answer here, so it's worth getting input from those involved in the community to make sure we don't go down a path we are going to regret later.
Sean
Is this a technical decision that is supported by contributors to the project? Is this a perception decision that is supported by contributors to the project? Both? If there is support, how much? 60%, 80%, 100% I am just some dumb operator, can someone please explain in regular human terms what the desired end result is from the move. All of the technical bits and bytes are good and all - but like big picture - what does the effort to move result in? -- ~/DonnyD C: 805 814 6800 "No mission too difficult. No sacrifice too great. Duty First"
On Wed, 15 Apr 2020 at 16:39, Donny Davis <donny@fortnebula.com> wrote:
On Wed, Apr 15, 2020 at 11:17 AM Matthew Treinish <mtreinish@kortar.org> wrote:
On Wed, Apr 15, 2020 at 12:12:08PM +0100, Sean Mooney wrote:
On Wed, 2020-04-15 at 01:17 +0000, Arkady.Kanevsky@dell.com wrote:
This is specific to https://www.openstack.org/marketplace/distros/ and private clouds. sometime as a comunity we are such trolls https://www.openstack.org/marketplace/distros/distribution/devstack/ds-opens... i love that devstack is listed there. although given how long it took use to stop people running in production i guess it qualifies as it had market usage.
This actually isn't devstack the development tool, it is a company named Devstack that is an OpenStack vendor (not confusing at all :p). Their website is:
I hope they're not basing their offerings on devstack the tool, but I have no idea.
-Matt Treinish
We have trademarks for Compute, storage, and for Full openstack. We can add trademark for baremetal for distros to market based on trademarks. It will be interesting if we can make that trademark of Open Infrastructure.
Thanks, Arkady
-----Original Message----- From: Julia Kreger <juliaashleykreger@gmail.com> Sent: Tuesday, April 14, 2020 3:37 PM To: Kanevsky, Arkady Cc: Sean Mooney; Dmitry Tantsur; openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project?
[EXTERNAL EMAIL]
On Tue, Apr 14, 2020 at 1:04 PM <Arkady.Kanevsky@dell.com> wrote:
Good Point Sean.
Does that lead to OpenStack powered BareMetal trademark?
I'm not entirely sure where your thought process is going. Could you elaborate a little on what your thinking?
Thanks!
-----Original Message----- From: Sean Mooney <smooney@redhat.com> Sent: Tuesday, April 14, 2020 5:38 AM To: Dmitry Tantsur; openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project?
[EXTERNAL EMAIL]
On Tue, 2020-04-14 at 11:45 +0200, Dmitry Tantsur wrote:
On Thu, Apr 9, 2020 at 7:26 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
> On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote: > > On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote: > > [...] > > > Why *can't* OpenShift include OpenStack projects? I haven't > > > seen this adequately explained. > > > > It's less of a technical issue, but more of misunderstanding > > that including an OpenStack project does not involve literally > > installing OpenStack. And no matter what we think, for a lot of > > people OpenStack==Nova (another marketing issue to address?). > > [...] > > I don't understand why that would make a difference in this case, > unless you're saying that the people who make architectural > decisions about what's included in OpenShift have no actual > familiarity with Ironic and OpenStack. If you know anyone who > works at that company, can you help them understand the difference? >
Let's de-focus on OpenShift please. People who just need a bare metal management solution don't need to understand what OpenStack is. What would they assume from a quick search? The first link I've got by googling in a private window is our web site with:
OpenStack software controls large pools of compute, storage, and networking resources throughout a datacenter, managed through a dashboard or via the OpenStack API. OpenStack works with popular enterprise and open source technologies making it ideal for heterogeneous infrastructure.
Is it so unexpected they assume Ironic needs virtual machines to operate?
yes since that at no point mentions viurtual machines. openstack is not a vm managment system. even in the early days form diablo or essex openstack cloud manage baremetal computes as well as contaienr via openvz and lxc then nova docker.
kubernetes is trying to redifine anything that is not contaienr native as not cloud but the compute context (container, vm or baremetal) provided by a cloud system is an implementation detail. the phrase "OpenStack software controls large pools of compute" does not imply vm any more then "ironic implies ipmi". ipmi is an important protocol in ironic and many of the vendor driver just ipmi with extentions but ironic does not directly imply it and openstack does not directly imply vms.
i admit there has been some misteps in this regard in terms of openstack powered programe
specificly the "OpenStack Powered Compute" trademark
the fact it specificaly requires nova as the requirement is actully the compute api https://opendev.org/openstack/interop/src/branch/master/2018.02.json#L 100-L193 can be consuing to some but it does not require the use of virtual machine dirver.
the only requiremetn the list that cannot be achive with ironic today is compute-servers-resize. if the ironic node was pxe booted form a cinder volume resize would actully be doable in a diskless baremetal server scech as a blade or a rsd system.
if you look at the apiu requriement objectivly it really only requires that the api exsits to create an instance but does not state way tthat instance is. it could be an lxc contaienr or any other virt dirver that fullfuils the api requirements.
it would have been nice if this branding treated ironic and now zun i guess as first class citizens but i think that is an an artifict of the the fact the requiremetn are defiend in terms of api.
compute-servers-create dose not mean create a vm even if that is what will happen most of the time.
> > > On one hand, large distributions want us to have stable branches > > every year or two. Even what we have is too much. > > > > On the other - we have small consumers who could benefit from > > just pulling the latest(ish) release and knowing that if a > > serous bug is found there, they won't have to update to the next > > feature (and potentially major) release. > > [...] > > This sounds like a problem shared by, well, basically every other > project in OpenStack too. Perhaps it's an opportunity to > collaborate on finding solutions. >
+1000 although I'm not sure if all projects are interested in +intermediate releases. Given how many follow the cycle-with-rc model, I doubt it.
Dmitry
> -- > Jeremy Stanley >
I know I am probably going to be lit on fire for this... but anyways here goes it.
Why does anyone care if ironic wants to move to a top level project or not? I would think the leaders of this project are most involved in the needs of what it's going to take for continued success. If the team that is doing the heavy lifting wants something, then I feel it's our position to enable success. It looks a lot to me like this is what the people who work on the project want (and if you don't have that data maybe poll your own team),
So why the push back?
The resources we do have are clearly dwindling - lets not give people any more reasons to leave if we can avoid it. Happiness in what you do and where you do it is a thing.
If Ironic wants to move, and it's not damaging to other projects. I think we should make that as easy as possible. All the rest seems like a bunch of noise.
/donnyd cowers in the corner waiting for blunt objects to be thrown
Well let's not assume that there is consensus even within the ironic team on this. The last time we discussed it between cores there was no unanimous decision. I see the problems of perception that this is trying to solve, but I suspect that the technical difference between being a top level OSF project vs. an OpenStack project will be lost on most who have already made up their minds. Not least because it's the *OpenStack* foundation! I'd like to see us fix some of the pain points mentioned within the community before jumping out (if necessary). The fact that metal3 and other projects are using Ironic will only help to strengthen Ironic's image outside of OpenStack, and if it means the metal3 marketing team has to do a bit of work to say "yes we're using an OpenStack project, and we're proud of that", then that's fine by me.
-- ~/DonnyD C: 805 814 6800 "No mission too difficult. No sacrifice too great. Duty First"
On 16.04.20 10:30, Mark Goddard wrote:
On Wed, 15 Apr 2020 at 16:39, Donny Davis <donny@fortnebula.com> wrote:
On Wed, Apr 15, 2020 at 11:17 AM Matthew Treinish <mtreinish@kortar.org> wrote:
On Wed, Apr 15, 2020 at 12:12:08PM +0100, Sean Mooney wrote:
On Wed, 2020-04-15 at 01:17 +0000, Arkady.Kanevsky@dell.com wrote:
This is specific to https://www.openstack.org/marketplace/distros/ and private clouds. sometime as a comunity we are such trolls https://www.openstack.org/marketplace/distros/distribution/devstack/ds-opens... i love that devstack is listed there. although given how long it took use to stop people running in production i guess it qualifies as it had market usage.
This actually isn't devstack the development tool, it is a company named Devstack that is an OpenStack vendor (not confusing at all :p). Their website is:
I hope they're not basing their offerings on devstack the tool, but I have no idea.
-Matt Treinish
We have trademarks for Compute, storage, and for Full openstack. We can add trademark for baremetal for distros to market based on trademarks. It will be interesting if we can make that trademark of Open Infrastructure.
Thanks, Arkady
-----Original Message----- From: Julia Kreger <juliaashleykreger@gmail.com> Sent: Tuesday, April 14, 2020 3:37 PM To: Kanevsky, Arkady Cc: Sean Mooney; Dmitry Tantsur; openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project?
[EXTERNAL EMAIL]
On Tue, Apr 14, 2020 at 1:04 PM <Arkady.Kanevsky@dell.com> wrote:
Good Point Sean.
Does that lead to OpenStack powered BareMetal trademark?
I'm not entirely sure where your thought process is going. Could you elaborate a little on what your thinking?
Thanks!
-----Original Message----- From: Sean Mooney <smooney@redhat.com> Sent: Tuesday, April 14, 2020 5:38 AM To: Dmitry Tantsur; openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project?
[EXTERNAL EMAIL]
On Tue, 2020-04-14 at 11:45 +0200, Dmitry Tantsur wrote: > On Thu, Apr 9, 2020 at 7:26 PM Jeremy Stanley <fungi@yuggoth.org> wrote: > >> On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote: >>> On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote: >> >> [...] >>>> Why *can't* OpenShift include OpenStack projects? I haven't >>>> seen this adequately explained. >>> >>> It's less of a technical issue, but more of misunderstanding >>> that including an OpenStack project does not involve literally >>> installing OpenStack. And no matter what we think, for a lot of >>> people OpenStack==Nova (another marketing issue to address?). >> >> [...] >> >> I don't understand why that would make a difference in this case, >> unless you're saying that the people who make architectural >> decisions about what's included in OpenShift have no actual >> familiarity with Ironic and OpenStack. If you know anyone who >> works at that company, can you help them understand the difference? >> > > Let's de-focus on OpenShift please. People who just need a bare > metal management solution don't need to understand what OpenStack > is. What would they assume from a quick search? The first link I've > got by googling in a private window is our web site with: > > OpenStack software controls large pools of compute, storage, and > networking resources throughout a datacenter, managed through a > dashboard or via the OpenStack API. OpenStack works with popular > enterprise and open source technologies making it ideal for heterogeneous infrastructure. > > Is it so unexpected they assume Ironic needs virtual machines to operate?
yes since that at no point mentions viurtual machines. openstack is not a vm managment system. even in the early days form diablo or essex openstack cloud manage baremetal computes as well as contaienr via openvz and lxc then nova docker.
kubernetes is trying to redifine anything that is not contaienr native as not cloud but the compute context (container, vm or baremetal) provided by a cloud system is an implementation detail. the phrase "OpenStack software controls large pools of compute" does not imply vm any more then "ironic implies ipmi". ipmi is an important protocol in ironic and many of the vendor driver just ipmi with extentions but ironic does not directly imply it and openstack does not directly imply vms.
i admit there has been some misteps in this regard in terms of openstack powered programe
specificly the "OpenStack Powered Compute" trademark
the fact it specificaly requires nova as the requirement is actully the compute api https://opendev.org/openstack/interop/src/branch/master/2018.02.json#L 100-L193 can be consuing to some but it does not require the use of virtual machine dirver.
the only requiremetn the list that cannot be achive with ironic today is compute-servers-resize. if the ironic node was pxe booted form a cinder volume resize would actully be doable in a diskless baremetal server scech as a blade or a rsd system.
if you look at the apiu requriement objectivly it really only requires that the api exsits to create an instance but does not state way tthat instance is. it could be an lxc contaienr or any other virt dirver that fullfuils the api requirements.
it would have been nice if this branding treated ironic and now zun i guess as first class citizens but i think that is an an artifict of the the fact the requiremetn are defiend in terms of api.
compute-servers-create dose not mean create a vm even if that is what will happen most of the time. > > >> >>> On one hand, large distributions want us to have stable branches >>> every year or two. Even what we have is too much. >>> >>> On the other - we have small consumers who could benefit from >>> just pulling the latest(ish) release and knowing that if a >>> serous bug is found there, they won't have to update to the next >>> feature (and potentially major) release. >> >> [...] >> >> This sounds like a problem shared by, well, basically every other >> project in OpenStack too. Perhaps it's an opportunity to >> collaborate on finding solutions. >> > > +1000 although I'm not sure if all projects are interested in > +intermediate > releases. Given how many follow the cycle-with-rc model, I doubt it. > > Dmitry > > >> -- >> Jeremy Stanley >>
I know I am probably going to be lit on fire for this... but anyways here goes it.
Why does anyone care if ironic wants to move to a top level project or not? I would think the leaders of this project are most involved in the needs of what it's going to take for continued success. If the team that is doing the heavy lifting wants something, then I feel it's our position to enable success. It looks a lot to me like this is what the people who work on the project want (and if you don't have that data maybe poll your own team),
So why the push back?
The resources we do have are clearly dwindling - lets not give people any more reasons to leave if we can avoid it. Happiness in what you do and where you do it is a thing.
If Ironic wants to move, and it's not damaging to other projects. I think we should make that as easy as possible. All the rest seems like a bunch of noise.
/donnyd cowers in the corner waiting for blunt objects to be thrown
Well let's not assume that there is consensus even within the ironic team on this. The last time we discussed it between cores there was no unanimous decision. I see the problems of perception that this is trying to solve, but I suspect that the technical difference between being a top level OSF project vs. an OpenStack project will be lost on most who have already made up their minds. Not least because it's the *OpenStack* foundation!
There is probably very little we can do about the ones who have made up their minds already or the ones who make up their minds because of the governing foundation (in practice, I'd think/hope very few do). I think the proposal is more to do something about the ones who are looking for a bare metal management/provisioning/lifecycle solution now, but move on to other places as it is not immediately obvious to them that Ironic does not necessarily need the additional complexity of a full OpenStack deployment.
I'd like to see us fix some of the pain points mentioned within the community before jumping out (if necessary).
The fact that metal3 and other projects are using Ironic will only help to strengthen Ironic's image outside of OpenStack, and if it means the metal3 marketing team has to do a bit of work to say "yes we're using an OpenStack project, and we're proud of that", then that's fine by me.
-- ~/DonnyD C: 805 814 6800 "No mission too difficult. No sacrifice too great. Duty First"
On Tue, 2020-04-14 at 20:00 +0000, Arkady.Kanevsky@dell.com wrote:
Good Point Sean.
Does that lead to OpenStack powered BareMetal trademark? it could and zun/kata would promt "OpenStack powered Containers" although i would prefer nova with libvirt to be represented as "OpenStack powered Compute" and "OpenStack powered VMs" where the driver capablity is reflected in the latter trademark and the form just models nova is deployed. if its an ironc backed nova with no vms it would then have "OpenStack powered Compute" and "OpenStack powered BareMetal" in that scheme.
i dont actully know if that is an improvement or not but it hink it would help seperate Compute from VMs which i think is a good thing. if you use metal3 with ironic would qualify hypoteitically to use "OpenStack powered BareMetal" as they would be consuming ironic as there baremetal provioning system althouhg they may not be using any other part of openstack which is fine. i dont know if more OpenStack powered .... trademarks help however. people who understand openstack at a technical level know that many of the project can and should be used standalone. form me the misconceptions are mainly marketing related and im not sure adding more trademarks for the different standalone usecase wehn help since they have openstack in the name. "Ironic powered Baremetal" on the other hand might. or "Kata powered Containers"
-----Original Message----- From: Sean Mooney <smooney@redhat.com> Sent: Tuesday, April 14, 2020 5:38 AM To: Dmitry Tantsur; openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project?
[EXTERNAL EMAIL]
On Tue, 2020-04-14 at 11:45 +0200, Dmitry Tantsur wrote:
On Thu, Apr 9, 2020 at 7:26 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote:
On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
[...]
Why *can't* OpenShift include OpenStack projects? I haven't seen this adequately explained.
It's less of a technical issue, but more of misunderstanding that including an OpenStack project does not involve literally installing OpenStack. And no matter what we think, for a lot of people OpenStack==Nova (another marketing issue to address?).
[...]
I don't understand why that would make a difference in this case, unless you're saying that the people who make architectural decisions about what's included in OpenShift have no actual familiarity with Ironic and OpenStack. If you know anyone who works at that company, can you help them understand the difference?
Let's de-focus on OpenShift please. People who just need a bare metal management solution don't need to understand what OpenStack is. What would they assume from a quick search? The first link I've got by googling in a private window is our web site with:
OpenStack software controls large pools of compute, storage, and networking resources throughout a datacenter, managed through a dashboard or via the OpenStack API. OpenStack works with popular enterprise and open source technologies making it ideal for heterogeneous infrastructure.
Is it so unexpected they assume Ironic needs virtual machines to operate?
yes since that at no point mentions viurtual machines. openstack is not a vm managment system. even in the early days form diablo or essex openstack cloud manage baremetal computes as well as contaienr via openvz and lxc then nova docker.
kubernetes is trying to redifine anything that is not contaienr native as not cloud but the compute context (container, vm or baremetal) provided by a cloud system is an implementation detail. the phrase "OpenStack software controls large pools of compute" does not imply vm any more then "ironic implies ipmi". ipmi is an important protocol in ironic and many of the vendor driver just ipmi with extentions but ironic does not directly imply it and openstack does not directly imply vms.
i admit there has been some misteps in this regard in terms of openstack powered programe
specificly the "OpenStack Powered Compute" trademark
the fact it specificaly requires nova as the requirement is actully the compute api https://opendev.org/openstack/interop/src/branch/master/2018.02.json#L100-L1... can be consuing to some but it does not require the use of virtual machine dirver.
the only requiremetn the list that cannot be achive with ironic today is compute-servers-resize. if the ironic node was pxe booted form a cinder volume resize would actully be doable in a diskless baremetal server scech as a blade or a rsd system.
if you look at the apiu requriement objectivly it really only requires that the api exsits to create an instance but does not state way tthat instance is. it could be an lxc contaienr or any other virt dirver that fullfuils the api requirements.
it would have been nice if this branding treated ironic and now zun i guess as first class citizens but i think that is an an artifict of the the fact the requiremetn are defiend in terms of api.
compute-servers-create dose not mean create a vm even if that is what will happen most of the time.
On one hand, large distributions want us to have stable branches every year or two. Even what we have is too much.
On the other - we have small consumers who could benefit from just pulling the latest(ish) release and knowing that if a serous bug is found there, they won't have to update to the next feature (and potentially major) release.
[...]
This sounds like a problem shared by, well, basically every other project in OpenStack too. Perhaps it's an opportunity to collaborate on finding solutions.
+1000 although I'm not sure if all projects are interested in +intermediate releases. Given how many follow the cycle-with-rc model, I doubt it.
Dmitry
-- Jeremy Stanley
That is clearly 64M$ question: Is OpenStack powered .... trademarks help? -----Original Message----- From: Sean Mooney <smooney@redhat.com> Sent: Wednesday, April 15, 2020 6:01 AM To: Kanevsky, Arkady; dtantsur@redhat.com; openstack-discuss@lists.openstack.org Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project? [EXTERNAL EMAIL] On Tue, 2020-04-14 at 20:00 +0000, Arkady.Kanevsky@dell.com wrote:
Good Point Sean.
Does that lead to OpenStack powered BareMetal trademark? it could and zun/kata would promt "OpenStack powered Containers" although i would prefer nova with libvirt to be represented as "OpenStack powered Compute" and "OpenStack powered VMs" where the driver capablity is reflected in the latter trademark and the form just models nova is deployed. if its an ironc backed nova with no vms it would then have "OpenStack powered Compute" and "OpenStack powered BareMetal" in that scheme.
i dont actully know if that is an improvement or not but it hink it would help seperate Compute from VMs which i think is a good thing. if you use metal3 with ironic would qualify hypoteitically to use "OpenStack powered BareMetal" as they would be consuming ironic as there baremetal provioning system althouhg they may not be using any other part of openstack which is fine. i dont know if more OpenStack powered .... trademarks help however. people who understand openstack at a technical level know that many of the project can and should be used standalone. form me the misconceptions are mainly marketing related and im not sure adding more trademarks for the different standalone usecase wehn help since they have openstack in the name. "Ironic powered Baremetal" on the other hand might. or "Kata powered Containers"
-----Original Message----- From: Sean Mooney <smooney@redhat.com> Sent: Tuesday, April 14, 2020 5:38 AM To: Dmitry Tantsur; openstack-discuss Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project?
[EXTERNAL EMAIL]
On Tue, 2020-04-14 at 11:45 +0200, Dmitry Tantsur wrote:
On Thu, Apr 9, 2020 at 7:26 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote:
On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
[...]
Why *can't* OpenShift include OpenStack projects? I haven't seen this adequately explained.
It's less of a technical issue, but more of misunderstanding that including an OpenStack project does not involve literally installing OpenStack. And no matter what we think, for a lot of people OpenStack==Nova (another marketing issue to address?).
[...]
I don't understand why that would make a difference in this case, unless you're saying that the people who make architectural decisions about what's included in OpenShift have no actual familiarity with Ironic and OpenStack. If you know anyone who works at that company, can you help them understand the difference?
Let's de-focus on OpenShift please. People who just need a bare metal management solution don't need to understand what OpenStack is. What would they assume from a quick search? The first link I've got by googling in a private window is our web site with:
OpenStack software controls large pools of compute, storage, and networking resources throughout a datacenter, managed through a dashboard or via the OpenStack API. OpenStack works with popular enterprise and open source technologies making it ideal for heterogeneous infrastructure.
Is it so unexpected they assume Ironic needs virtual machines to operate?
yes since that at no point mentions viurtual machines. openstack is not a vm managment system. even in the early days form diablo or essex openstack cloud manage baremetal computes as well as contaienr via openvz and lxc then nova docker.
kubernetes is trying to redifine anything that is not contaienr native as not cloud but the compute context (container, vm or baremetal) provided by a cloud system is an implementation detail. the phrase "OpenStack software controls large pools of compute" does not imply vm any more then "ironic implies ipmi". ipmi is an important protocol in ironic and many of the vendor driver just ipmi with extentions but ironic does not directly imply it and openstack does not directly imply vms.
i admit there has been some misteps in this regard in terms of openstack powered programe
specificly the "OpenStack Powered Compute" trademark
the fact it specificaly requires nova as the requirement is actully the compute api https://opendev.org/openstack/interop/src/branch/master/2018.02.json#L 100-L193 can be consuing to some but it does not require the use of virtual machine dirver.
the only requiremetn the list that cannot be achive with ironic today is compute-servers-resize. if the ironic node was pxe booted form a cinder volume resize would actully be doable in a diskless baremetal server scech as a blade or a rsd system.
if you look at the apiu requriement objectivly it really only requires that the api exsits to create an instance but does not state way tthat instance is. it could be an lxc contaienr or any other virt dirver that fullfuils the api requirements.
it would have been nice if this branding treated ironic and now zun i guess as first class citizens but i think that is an an artifict of the the fact the requiremetn are defiend in terms of api.
compute-servers-create dose not mean create a vm even if that is what will happen most of the time.
On one hand, large distributions want us to have stable branches every year or two. Even what we have is too much.
On the other - we have small consumers who could benefit from just pulling the latest(ish) release and knowing that if a serous bug is found there, they won't have to update to the next feature (and potentially major) release.
[...]
This sounds like a problem shared by, well, basically every other project in OpenStack too. Perhaps it's an opportunity to collaborate on finding solutions.
+1000 although I'm not sure if all projects are interested in +intermediate releases. Given how many follow the cycle-with-rc model, I doubt it.
Dmitry
-- Jeremy Stanley
participants (24)
-
Arkady.Kanevsky＠dell.com
-
Arne Wiebalck
-
Artom Lifshitz
-
Ben Nemec
-
Bogdan Dobrelya
-
Clark Boylan
-
Dmitry Tantsur
-
Donny Davis
-
Doug Hellmann
-
Jean-Philippe Evrard
-
Jeremy Stanley
-
Julia Kreger
-
Lingxian Kong
-
Mark Goddard
-
Matthew Treinish
-
melanie witt
-
Mohammed Naser
-
Nate Johnston
-
Riccardo Pittau
-
Ruslanas Gžibovskis
-
Sean McGinnis
-
Sean Mooney
-
Thierry Carrez
-
Tom Barron