DR options with openstack
Hi Tony,
It looks like Cheesecake didn’t survive but apparently some components of it did; details in https://docs.openstack.org/cinder/pike/contributor/replication.html
I’m not using Cinder now; we used it at eBay with Ceph and Netapp backends. Netapp makes it easy but is expensive; Ceph is free but you have to figure out how to make it work. You’re right about forking; we did it and then upgrading turned from an incredibly difficult ordeal to an impossible one. It’s better to stay with the “official” code so that upgrading remains an option.
I’m just an operator; hopefully someone more expert will reply with more useful info.
It’s true that our community lacks participation. It’s very difficult for a new operator to start using openstack and get help with the issues that they encounter. So far this mailing list has been the best resource for me. IRC and Ask Openstack are mostly unattended. I try to help out in #openstack when I can, but I don’t know a lot so I mostly end up telling people to ask on the list. On IRC sometimes I find help by asking in other openstack-* channels. Sometimes people complain that I’m asking in a developer channel, but sometimes I get help. Persistence is the key. If I keep asking long enough in enough places, eventually someone will answer. If all else fails, I open a bug.
Good luck and welcome to the Openstack community!
From: Tony Pearce tony.pearce@cinglevue.com Sent: Wednesday, January 15, 2020 11:37 PM To: openstack-discuss@lists.openstack.org Subject: DR options with openstack
Hi all
My questions are;
1. How are people using iSCSI Cinder storage with Openstack to-date? For example a Nimble Storage array backend. I mean to say, are people using backend integration drivers for other hardware (like netapp)? Or are they using backend iscsi for example? 2. How are people managing DR with Openstack in terms of backend storage replication to another array in another location and continuing to use Openstack?
The environment which I am currently using; 1 x Nimble Storage array (iSCSI) with nimble.py Cinder driver 1 x virtualised Controller node 2 x physical compute nodes This is Openstack Pike.
In addition, I have a 2nd Nimble Storage array in another location.
To explain the questions I’d like to put forward my thoughts for question 2 first: For point 2 above, I have been searching for a way to utilise replicated volumes on the 2nd array from Openstack with existing instances. For example, if site 1 goes down how would I bring up openstack in the 2nd location and boot up the instances where their volumes are stored on the 2nd array. I found a proposal for something called “cheesecake” ref: https://specs.openstack.org/openstack/cinder-specs/specs/rocky/cheesecake-pr...https://urldefense.proofpoint.com/v2/url?u=https-3A__specs.openstack.org_openstack_cinder-2Dspecs_specs_rocky_cheesecake-2Dpromote-2Dbackend.html&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=XrJBXYlVPpvOXkMqGPz6KucRW_ils95ZMrEmlTflPm8&m=e2jC0sFEUAs6byl7JOv5IAZTKPkABl-Eh6rQwQ55tWk&s=oVEr3DpxprOpbuxZ_4WSfSqAVCaZUlPCFT6g6DsqQHQ&e= But I could not find if it had been approved or implemented. So I return to square 1. I have some thoughts about failing over the controller VM and compute node but I don’t think there’s any need to go into here because of the above blocker and for brevity anyway.
The nimble.py driver which I am using came with Openstack Pike and it appears Nimble / HPE are not maintaining it any longer. I saw a commit to remove nimble.py in Openstack Train release. The driver uses the REST API to perform actions on the array. Such as creating a volume, downloading the image, mounting the volume to the instance, snapshots, clones etc. This is great for me because to date I have around 10TB of openstack storage data allocated and the Nimble array shows the amount of data being consumed is <900GB. This is due to the compression and zero-byte snapshots and clones.
So coming back to question 2 – is it possible? Can you drop me some keywords that I can search for such as an Openstack component like Cheesecake? I think basically what I am looking for is a supported way of telling Openstack that the instance volumes are now located at the new / second array. This means a new cinder backend. Example, new iqn, IP address, volume serial number. I think I could probably hack the cinder db but I really want to avoid that.
So failing the above, it brings me to the question 1 I asked before. How are people using Cinder volumes? May be I am going about this the wrong way and need to take a few steps backwards to go forwards? I need storage to be able to deploy instances onto. Snapshots and clones are desired. At the moment these operations take less time than the horizon dashboard takes to load because of the waiting API responses.
When searching for information about the above as an end-user / consumer I get a bit concerned. Is it right that Openstack usage is dropping? There’s no web forum to post questions. The chatroom on freenode is filled with ~300 ghosts. Ask Openstack questions go without response. Earlier this week (before I found this mail list) I had to use facebook to report that the Openstack.org website had been hacked. Basically it seems that if you’re a developer that can write code then you’re in but that’s it. I have never been a coder and so I am somewhat stuck.
Thanks in advance
On 2020-01-16 19:49:08 +0000 (+0000), Albert Braden wrote: [...]
On IRC sometimes I find help by asking in other openstack-* channels. Sometimes people complain that I’m asking in a developer channel, but sometimes I get help
[...]
I hope we don't have "developer[-only] channels" in OpenStack. The way of free/libre open source software is that users often become developers once they gain an increased familiarity with a project, so telling them to go away when they have a question is absolutely the wrong approach if we want this to be a sustainable effort longer term. I'm a developer on a number of projects where I still regularly have questions as a user, so even for selfish reasons I don't think that sort of discussion should be off-topic. If software developers get annoyed by users asking them too many questions or the same questions over and over, they should see that as a clear sign that they need to improve the documentation they maintain.
So just to reassure you, you are absolutely doing the right thing by asking folks in project-specific IRC channels (or on this mailing list) when documentation about something is unclear or you encounter an undocumented behavior you'd like help investigating.
Hi Tony, Looking at the nimble driver, it has been removed from Cinder due to lack of support and maintenance from the vendor. Also, Looking at the code prior to it's removal, it didn't have any support for replication and failover. Cinder is a community based opensource project that relies on vendors, operators and users to contribute and support the codebase. As a core member of the Cinder team, we do our best to provide support for folks using Cinder and this mailing list and the #openstack-cinder channel is the best mechanism to get in touch with us. The #openstack-cinder irc channel is not a developer only channel. We help when we can, but also remember we have our day jobs as well.
Unfortunately Nimble stopped providing support for their driver quite a while ago now and part of the Cinder policy to have a driver in tree is to have CI (Continuous Integration) tests in place to ensure that cinder patches don't break a driver. If the CI isn't in place, then the Cinder team marks the driver as unsupported in a release, and the following release the driver gets removed.
All that being said, the nimbe driver never supported the cheesecake replication/DR capabilities that were added in Cinder.
Walt (hemna in irc)
On Thu, Jan 16, 2020 at 2:49 AM Tony Pearce tony.pearce@cinglevue.com wrote:
Hi all
My questions are;
- How are people using iSCSI Cinder storage with Openstack to-date?
For example a Nimble Storage array backend. I mean to say, are people using backend integration drivers for other hardware (like netapp)? Or are they using backend iscsi for example? 2. How are people managing DR with Openstack in terms of backend storage replication to another array in another location and continuing to use Openstack?
The environment which I am currently using;
1 x Nimble Storage array (iSCSI) with nimble.py Cinder driver
1 x virtualised Controller node
2 x physical compute nodes
This is Openstack Pike.
In addition, I have a 2nd Nimble Storage array in another location.
To explain the questions I’d like to put forward my thoughts for question 2 first:
For point 2 above, I have been searching for a way to utilise replicated volumes on the 2nd array from Openstack with existing instances. For example, if site 1 goes down how would I bring up openstack in the 2nd location and boot up the instances where their volumes are stored on the 2 nd array. I found a proposal for something called “cheesecake” ref: https://specs.openstack.org/openstack/cinder-specs/specs/rocky/cheesecake-pr... But I could not find if it had been approved or implemented. So I return to square 1. I have some thoughts about failing over the controller VM and compute node but I don’t think there’s any need to go into here because of the above blocker and for brevity anyway.
The nimble.py driver which I am using came with Openstack Pike and it appears Nimble / HPE are not maintaining it any longer. I saw a commit to remove nimble.py in Openstack Train release. The driver uses the REST API to perform actions on the array. Such as creating a volume, downloading the image, mounting the volume to the instance, snapshots, clones etc. This is great for me because to date I have around 10TB of openstack storage data allocated and the Nimble array shows the amount of data being consumed is <900GB. This is due to the compression and zero-byte snapshots and clones.
So coming back to question 2 – is it possible? Can you drop me some keywords that I can search for such as an Openstack component like Cheesecake? I think basically what I am looking for is a supported way of telling Openstack that the instance volumes are now located at the new / second array. This means a new cinder backend. Example, new iqn, IP address, volume serial number. I think I could probably hack the cinder db but I really want to avoid that.
So failing the above, it brings me to the question 1 I asked before. How are people using Cinder volumes? May be I am going about this the wrong way and need to take a few steps backwards to go forwards? I need storage to be able to deploy instances onto. Snapshots and clones are desired. At the moment these operations take less time than the horizon dashboard takes to load because of the waiting API responses.
When searching for information about the above as an end-user / consumer I get a bit concerned. Is it right that Openstack usage is dropping? There’s no web forum to post questions. The chatroom on freenode is filled with ~300 ghosts. Ask Openstack questions go without response. Earlier this week (before I found this mail list) I had to use facebook to report that the Openstack.org website had been hacked. Basically it seems that if you’re a developer that can write code then you’re in but that’s it. I have never been a coder and so I am somewhat stuck.
Thanks in advance
Sent from Mail https://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10
Hi Walter
Thank you for the information. It's unfortunate about the lack of support from nimble.
With regards to replication, nimble has their own software implementation that I'm currently using. The problem I face is that the replicated volumes have a different iqn, serial number and are accessed via a different array IP.
I didn't get time to read up on freezer today but I'm hopeful that I can use something there. 🙂
On Fri, 17 Jan 2020, 21:10 Walter Boring, waboring@hemna.com wrote:
Hi Tony, Looking at the nimble driver, it has been removed from Cinder due to lack of support and maintenance from the vendor. Also, Looking at the code prior to it's removal, it didn't have any support for replication and failover. Cinder is a community based opensource project that relies on vendors, operators and users to contribute and support the codebase. As a core member of the Cinder team, we do our best to provide support for folks using Cinder and this mailing list and the #openstack-cinder channel is the best mechanism to get in touch with us. The #openstack-cinder irc channel is not a developer only channel. We help when we can, but also remember we have our day jobs as well.
Unfortunately Nimble stopped providing support for their driver quite a while ago now and part of the Cinder policy to have a driver in tree is to have CI (Continuous Integration) tests in place to ensure that cinder patches don't break a driver. If the CI isn't in place, then the Cinder team marks the driver as unsupported in a release, and the following release the driver gets removed.
All that being said, the nimbe driver never supported the cheesecake replication/DR capabilities that were added in Cinder.
Walt (hemna in irc)
On Thu, Jan 16, 2020 at 2:49 AM Tony Pearce tony.pearce@cinglevue.com wrote:
Hi all
My questions are;
- How are people using iSCSI Cinder storage with Openstack to-date?
For example a Nimble Storage array backend. I mean to say, are people using backend integration drivers for other hardware (like netapp)? Or are they using backend iscsi for example? 2. How are people managing DR with Openstack in terms of backend storage replication to another array in another location and continuing to use Openstack?
The environment which I am currently using;
1 x Nimble Storage array (iSCSI) with nimble.py Cinder driver
1 x virtualised Controller node
2 x physical compute nodes
This is Openstack Pike.
In addition, I have a 2nd Nimble Storage array in another location.
To explain the questions I’d like to put forward my thoughts for question 2 first:
For point 2 above, I have been searching for a way to utilise replicated volumes on the 2nd array from Openstack with existing instances. For example, if site 1 goes down how would I bring up openstack in the 2nd location and boot up the instances where their volumes are stored on the 2 nd array. I found a proposal for something called “cheesecake” ref: https://specs.openstack.org/openstack/cinder-specs/specs/rocky/cheesecake-pr... But I could not find if it had been approved or implemented. So I return to square 1. I have some thoughts about failing over the controller VM and compute node but I don’t think there’s any need to go into here because of the above blocker and for brevity anyway.
The nimble.py driver which I am using came with Openstack Pike and it appears Nimble / HPE are not maintaining it any longer. I saw a commit to remove nimble.py in Openstack Train release. The driver uses the REST API to perform actions on the array. Such as creating a volume, downloading the image, mounting the volume to the instance, snapshots, clones etc. This is great for me because to date I have around 10TB of openstack storage data allocated and the Nimble array shows the amount of data being consumed is <900GB. This is due to the compression and zero-byte snapshots and clones.
So coming back to question 2 – is it possible? Can you drop me some keywords that I can search for such as an Openstack component like Cheesecake? I think basically what I am looking for is a supported way of telling Openstack that the instance volumes are now located at the new / second array. This means a new cinder backend. Example, new iqn, IP address, volume serial number. I think I could probably hack the cinder db but I really want to avoid that.
So failing the above, it brings me to the question 1 I asked before. How are people using Cinder volumes? May be I am going about this the wrong way and need to take a few steps backwards to go forwards? I need storage to be able to deploy instances onto. Snapshots and clones are desired. At the moment these operations take less time than the horizon dashboard takes to load because of the waiting API responses.
When searching for information about the above as an end-user / consumer I get a bit concerned. Is it right that Openstack usage is dropping? There’s no web forum to post questions. The chatroom on freenode is filled with ~300 ghosts. Ask Openstack questions go without response. Earlier this week (before I found this mail list) I had to use facebook to report that the Openstack.org website had been hacked. Basically it seems that if you’re a developer that can write code then you’re in but that’s it. I have never been a coder and so I am somewhat stuck.
Thanks in advance
Sent from Mail https://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10
I'm traveling in India right now and will reply later. I've architected several large OpenStack clouds from Cisco to Juniper to SAP to AT&T to HPE to Wells Fargo to -- you name it. Will share some things we've done regarding DR and more specifically how we handled replication and dividing the cloud up so it made sense from a design and operational perspective.
Also, we need to be clear not everyone leans towards being a developer or even *wants* to go in that direction when using OpenStack. In fact, most don't and if there is that expectation by those entrenched with the OpenStack product, the OpenStack option gets dropped in favor of something else. It's developer-friendly but we need to be mega-mega-careful, as a community, to ensure development isn't the baseline or assumption for adequate support or to get questions answered. Especially since we've converged our communication channels.
/soapbox
More later.
//adam
On Fri, Jan 17, 2020, 7:19 PM Tony Pearce tony.pearce@cinglevue.com wrote:
Hi Walter
Thank you for the information. It's unfortunate about the lack of support from nimble.
With regards to replication, nimble has their own software implementation that I'm currently using. The problem I face is that the replicated volumes have a different iqn, serial number and are accessed via a different array IP.
I didn't get time to read up on freezer today but I'm hopeful that I can use something there. 🙂
On Fri, 17 Jan 2020, 21:10 Walter Boring, waboring@hemna.com wrote:
Hi Tony, Looking at the nimble driver, it has been removed from Cinder due to lack of support and maintenance from the vendor. Also, Looking at the code prior to it's removal, it didn't have any support for replication and failover. Cinder is a community based opensource project that relies on vendors, operators and users to contribute and support the codebase. As a core member of the Cinder team, we do our best to provide support for folks using Cinder and this mailing list and the #openstack-cinder channel is the best mechanism to get in touch with us. The #openstack-cinder irc channel is not a developer only channel. We help when we can, but also remember we have our day jobs as well.
Unfortunately Nimble stopped providing support for their driver quite a while ago now and part of the Cinder policy to have a driver in tree is to have CI (Continuous Integration) tests in place to ensure that cinder patches don't break a driver. If the CI isn't in place, then the Cinder team marks the driver as unsupported in a release, and the following release the driver gets removed.
All that being said, the nimbe driver never supported the cheesecake replication/DR capabilities that were added in Cinder.
Walt (hemna in irc)
On Thu, Jan 16, 2020 at 2:49 AM Tony Pearce tony.pearce@cinglevue.com wrote:
Hi all
My questions are;
- How are people using iSCSI Cinder storage with Openstack
to-date? For example a Nimble Storage array backend. I mean to say, are people using backend integration drivers for other hardware (like netapp)? Or are they using backend iscsi for example? 2. How are people managing DR with Openstack in terms of backend storage replication to another array in another location and continuing to use Openstack?
The environment which I am currently using;
1 x Nimble Storage array (iSCSI) with nimble.py Cinder driver
1 x virtualised Controller node
2 x physical compute nodes
This is Openstack Pike.
In addition, I have a 2nd Nimble Storage array in another location.
To explain the questions I’d like to put forward my thoughts for question 2 first:
For point 2 above, I have been searching for a way to utilise replicated volumes on the 2nd array from Openstack with existing instances. For example, if site 1 goes down how would I bring up openstack in the 2nd location and boot up the instances where their volumes are stored on the 2 nd array. I found a proposal for something called “cheesecake” ref: https://specs.openstack.org/openstack/cinder-specs/specs/rocky/cheesecake-pr... But I could not find if it had been approved or implemented. So I return to square 1. I have some thoughts about failing over the controller VM and compute node but I don’t think there’s any need to go into here because of the above blocker and for brevity anyway.
The nimble.py driver which I am using came with Openstack Pike and it appears Nimble / HPE are not maintaining it any longer. I saw a commit to remove nimble.py in Openstack Train release. The driver uses the REST API to perform actions on the array. Such as creating a volume, downloading the image, mounting the volume to the instance, snapshots, clones etc. This is great for me because to date I have around 10TB of openstack storage data allocated and the Nimble array shows the amount of data being consumed is <900GB. This is due to the compression and zero-byte snapshots and clones.
So coming back to question 2 – is it possible? Can you drop me some keywords that I can search for such as an Openstack component like Cheesecake? I think basically what I am looking for is a supported way of telling Openstack that the instance volumes are now located at the new / second array. This means a new cinder backend. Example, new iqn, IP address, volume serial number. I think I could probably hack the cinder db but I really want to avoid that.
So failing the above, it brings me to the question 1 I asked before. How are people using Cinder volumes? May be I am going about this the wrong way and need to take a few steps backwards to go forwards? I need storage to be able to deploy instances onto. Snapshots and clones are desired. At the moment these operations take less time than the horizon dashboard takes to load because of the waiting API responses.
When searching for information about the above as an end-user / consumer I get a bit concerned. Is it right that Openstack usage is dropping? There’s no web forum to post questions. The chatroom on freenode is filled with ~300 ghosts. Ask Openstack questions go without response. Earlier this week (before I found this mail list) I had to use facebook to report that the Openstack.org website had been hacked. Basically it seems that if you’re a developer that can write code then you’re in but that’s it. I have never been a coder and so I am somewhat stuck.
Thanks in advance
Sent from Mail https://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10
On 2020-01-17 21:24:36 +0530 (+0530), Adam Peacock wrote: [...]
Also, we need to be clear not everyone leans towards being a developer or even *wants* to go in that direction when using OpenStack. In fact, most don't and if there is that expectation by those entrenched with the OpenStack product, the OpenStack option gets dropped in favor of something else. It's developer-friendly but we need to be mega-mega-careful, as a community, to ensure development isn't the baseline or assumption for adequate support or to get questions answered. Especially since we've converged our communication channels.
[...]
Most users probably won't become developers on OpenStack, but some will, and I believe its long-term survival depends on that so we should do everything we can to encourage it. Users may also contribute in a variety of other ways like bug reporting and triage, outreach, revising or translating documentation, and so on.
OpenStack isn't a "product," it's a community software collaboration on which many companies have built products (either by running it as a service or selling support for it). Treating the community the way you might treat a paid vendor is where all of this goes to a bad place very quickly.
How we view OpenStack within our community here is usually vastly different than the majority of enterprises and how they view it. Side note: My biggest gripe with OpenStack leadership is actually that everything is viewed from the lens of a developer which, I feel, is contributing to the plateau/decline in its adoption. That is but that's a topic for another day.
Most organizations ( as I've seen anyway) view OpenStack as a product that is compared to other cloud products like vCloud Director/similar. And after 8 years architecting clouds with it, I see it the same way. So I'm not exactly inclined to split hairs with how it is characterized.
Bottom line though, ensuring that non-developers are able to easily able to get their questions answered will, in my personal opinion, either promote OpenStack or promote the conception that it requires a team of developers to understand and run which kills any serious consideration in the boardroom.
Sorry to the OP, didn't mean to hijack your thread here. :) just raises an important topic th get I see come up over and over.
//adam
On Sat, Jan 18, 2020, 2:43 AM Jeremy Stanley fungi@yuggoth.org wrote:
On 2020-01-17 21:24:36 +0530 (+0530), Adam Peacock wrote: [...]
Also, we need to be clear not everyone leans towards being a developer or even *wants* to go in that direction when using OpenStack. In fact, most don't and if there is that expectation by those entrenched with the OpenStack product, the OpenStack option gets dropped in favor of something else. It's developer-friendly but we need to be mega-mega-careful, as a community, to ensure development isn't the baseline or assumption for adequate support or to get questions answered. Especially since we've converged our communication channels.
[...]
Most users probably won't become developers on OpenStack, but some will, and I believe its long-term survival depends on that so we should do everything we can to encourage it. Users may also contribute in a variety of other ways like bug reporting and triage, outreach, revising or translating documentation, and so on.
OpenStack isn't a "product," it's a community software collaboration on which many companies have built products (either by running it as a service or selling support for it). Treating the community the way you might treat a paid vendor is where all of this goes to a bad place very quickly. -- Jeremy Stanley
On 2020-01-18 04:14:28 +0530 (+0530), Adam Peacock wrote:
How we view OpenStack within our community here is usually vastly different than the majority of enterprises and how they view it. Side note: My biggest gripe with OpenStack leadership is actually that everything is viewed from the lens of a developer which, I feel, is contributing to the plateau/decline in its adoption. That is but that's a topic for another day.
I don't know whether you consider me part of OpenStack leadership, but if it helps, my background is ~30 years as a Unix/Linux sysadmin, data center engineer, security analyst and network architect. I don't have any formal education in software development (or even a University degree). This is the lens with which I view OpenStack.
Most organizations ( as I've seen anyway) view OpenStack as a product that is compared to other cloud products like vCloud Director/similar. And after 8 years architecting clouds with it, I see it the same way. So I'm not exactly inclined to split hairs with how it is characterized.
I used vCloud Director for years, and I don't recall getting it for free nor being provided with access to its source outside an NDA. There also wasn't any way to reach out to the developers for it without a paid service contract (or really even with one most of the time). Sounds like VMware has become a bit more progressive recently? ;)
Bottom line though, ensuring that non-developers are able to easily able to get their questions answered will, in my personal opinion, either promote OpenStack or promote the conception that it requires a team of developers to understand and run which kills any serious consideration in the boardroom.
[...]
I wholeheartedly agree with this, and it's basically the point I've been trying to make as well. We need to welcome users and let them ask questions wherever we're all having conversations. Free/libre open source software thrives or withers based on the strength of its user base, not on its technical superiority or novelty. If we don't take every opportunity to accommodate users who engage with us, we're going to have fewer and fewer users... until the day comes when we have none at all. Also as the hype subsides, companies aren't going to throw developer hours at OpenStack just because it looks good in advertisements. We're going to need to learn how to shore up our ranks of developers and maintainers from the only other source available to us: our users.
On Fri, Jan 17, 2020 at 1:42 PM Jeremy Stanley fungi@yuggoth.org wrote:
On 2020-01-17 21:24:36 +0530 (+0530), Adam Peacock wrote: [...]
Also, we need to be clear not everyone leans towards being a developer or even *wants* to go in that direction when using OpenStack. In fact, most don't and if there is that expectation by those entrenched with the OpenStack product, the OpenStack option gets dropped in favor of something else. It's developer-friendly but we need to be mega-mega-careful, as a community, to ensure development isn't the baseline or assumption for adequate support or to get questions answered. Especially since we've converged our communication channels.
[...]
Most users probably won't become developers on OpenStack, but some will, and I believe its long-term survival depends on that so we should do everything we can to encourage it. Users may also contribute in a variety of other ways like bug reporting and triage, outreach, revising or translating documentation, and so on.
OpenStack isn't a "product," it's a community software collaboration on which many companies have built products (either by running it as a service or selling support for it). Treating the community the way you might treat a paid vendor is where all of this goes to a bad place very quickly.
We've probably strayed a bit far away from the original topic, but I echo this thought very much.
OpenStack is a project. $your_favorite_vendor's OpenStack is a product. It's important for us to keep that distinction for the success of both the project and vendors IMHO.
-- Jeremy Stanley
So if I understand correctly, this says to me that Openstack is never intended to be consumed by end users.
Is this correct?
Regards
On Sat, 18 Jan 2020, 11:28 Mohammed Naser, mnaser@vexxhost.com wrote:
On Fri, Jan 17, 2020 at 1:42 PM Jeremy Stanley fungi@yuggoth.org wrote:
On 2020-01-17 21:24:36 +0530 (+0530), Adam Peacock wrote: [...]
Also, we need to be clear not everyone leans towards being a developer or even *wants* to go in that direction when using OpenStack. In fact, most don't and if there is that expectation by those entrenched with the OpenStack product, the OpenStack option gets dropped in favor of something else. It's developer-friendly but we need to be mega-mega-careful, as a community, to ensure development isn't the baseline or assumption for adequate support or to get questions answered. Especially since we've converged our communication channels.
[...]
Most users probably won't become developers on OpenStack, but some will, and I believe its long-term survival depends on that so we should do everything we can to encourage it. Users may also contribute in a variety of other ways like bug reporting and triage, outreach, revising or translating documentation, and so on.
OpenStack isn't a "product," it's a community software collaboration on which many companies have built products (either by running it as a service or selling support for it). Treating the community the way you might treat a paid vendor is where all of this goes to a bad place very quickly.
We've probably strayed a bit far away from the original topic, but I echo this thought very much.
OpenStack is a project. $your_favorite_vendor's OpenStack is a product. It's important for us to keep that distinction for the success of both the project and vendors IMHO.
-- Jeremy Stanley
-- Mohammed Naser — vexxhost
D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser@vexxhost.com W. https://vexxhost.com
On Sat, 2020-01-18 at 14:48 +0800, Tony Pearce wrote:
So if I understand correctly, this says to me that Openstack is never intended to be consumed by end users.
Is this correct?
no there are many end user that deploy there openstack directly from source or using comunity installer project. as an opensouce project developer of the project will try to help our end user fix there own problems by explain how things work and pointing them in the right direction. If a user reports a ligitimate bug we will try to fix it eventually when our day job allows. But the same way the mysql develpers wont provdie 1:1 support for tuneing your db deployment for your workload the openstack communtiy does nto provide deployment planning or day 2 operation supprot to customers.
we obviously try to make day 2 operation eaiser and if user report pain point we take that on board but if you choose to deploy openstack directly from source or community distributions without a vendor then you are relying on the good will of indiviuals. i and other do help end users when they ask genuine questions providing links ot the relevnet docs or pointing them to config optins or presentaiton on the topic they ask about. we will also somtime help diagnose problem the people are having, but if that good will is abused then i will go back to my day job.
if you show up and demand that we drop everything and fix your problem now you will likely have a negitive experience. unlike a vendor relationship we dont have a professional/paid relationship with our end users, on the other hand if you show up, get involved and help other where you can then i think you will find most people in the comunity will try to help you too when you need it. that is one of the big cultural difference between an opensouce project and a support product. a project is a comunity of people working together to advance a common goal. a product on the ohter hand has a businesses promise of support and with that an expectation that your vendor will go beyond good will if your business is impacted by an issue with there product.
if you chose to deploy openstack as an end user understand that while we try to make that easy, the learning curvy is high and you need to have the right skills to make it a success but you can certenly do that if you invest the time and peopel to do it. kolla-ansible and openstack ansible provide two of the simplest comunity installer for managing openstack. as installer projects there focus is on day 1 and day 2 operations and tend to have more operators involved the component projects. while you can role your own they have already centralised the knoladge of may operators in the solutions they have developed so i would recommend reaching out to them to learn how you can deploy openstack your self. if you want a product as other said then you should reach out to your vendor of choice and they will help you with both planning your deployment and keeping it running.
Regards
On Sat, 18 Jan 2020, 11:28 Mohammed Naser, mnaser@vexxhost.com wrote:
On Fri, Jan 17, 2020 at 1:42 PM Jeremy Stanley fungi@yuggoth.org wrote:
On 2020-01-17 21:24:36 +0530 (+0530), Adam Peacock wrote: [...]
Also, we need to be clear not everyone leans towards being a developer or even *wants* to go in that direction when using OpenStack. In fact, most don't and if there is that expectation by those entrenched with the OpenStack product, the OpenStack option gets dropped in favor of something else. It's developer-friendly but we need to be mega-mega-careful, as a community, to ensure development isn't the baseline or assumption for adequate support or to get questions answered. Especially since we've converged our communication channels.
[...]
Most users probably won't become developers on OpenStack, but some will, and I believe its long-term survival depends on that so we should do everything we can to encourage it. Users may also contribute in a variety of other ways like bug reporting and triage, outreach, revising or translating documentation, and so on.
OpenStack isn't a "product," it's a community software collaboration on which many companies have built products (either by running it as a service or selling support for it). Treating the community the way you might treat a paid vendor is where all of this goes to a bad place very quickly.
We've probably strayed a bit far away from the original topic, but I echo this thought very much.
OpenStack is a project. $your_favorite_vendor's OpenStack is a product. It's important for us to keep that distinction for the success of both the project and vendors IMHO.
-- Jeremy Stanley
-- Mohammed Naser — vexxhost
D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser@vexxhost.com W. https://vexxhost.com
On 2020-01-18 14:48:36 +0800 (+0800), Tony Pearce wrote:
So if I understand correctly, this says to me that Openstack is never intended to be consumed by end users.
[...]
I have no idea how you got that from my message (elided since I can't be bothered to fix your top-posting[*] right now). It's also unclear to me which definition of "end users" you're applying. For these purposes I lump people who install/manage OpenStack deployments and people who interact with OpenStack deployments together, though the latter have an established relationship with the former and that's generally where their recommended support channels lie.
End users consume the Linux kernel. Where do they go for support when they have a problem with it? End users consume the bash shell. Where do they go for support with that? You can totally build and install those things yourself from source. When you do that you 1. are assumed to be a somewhat advanced user and 2. might consider reaching out to their developers and other advanced users for them when you run into an issue. They may have time to help you, or they may not. You don't have a paid support contract with them, so while they're likely to try and help you out if they can, they're certainly under no obligation.
You can also get those things ready-to-use from various places, and can even buy support for them from someone who *is* obligated to help you. Which path you choose is up to you.
[*] https://wiki.openstack.org/wiki/MailingListEtiquette
Thanks guys for clarifying 🙂
My question was in reply to Mohammed Naser's email. Sorry for the confusion.
On Sun, 19 Jan 2020, 01:17 Jeremy Stanley, fungi@yuggoth.org wrote:
On 2020-01-18 14:48:36 +0800 (+0800), Tony Pearce wrote:
So if I understand correctly, this says to me that Openstack is never intended to be consumed by end users.
[...]
I have no idea how you got that from my message (elided since I can't be bothered to fix your top-posting[*] right now). It's also unclear to me which definition of "end users" you're applying. For these purposes I lump people who install/manage OpenStack deployments and people who interact with OpenStack deployments together, though the latter have an established relationship with the former and that's generally where their recommended support channels lie.
End users consume the Linux kernel. Where do they go for support when they have a problem with it? End users consume the bash shell. Where do they go for support with that? You can totally build and install those things yourself from source. When you do that you 1. are assumed to be a somewhat advanced user and 2. might consider reaching out to their developers and other advanced users for them when you run into an issue. They may have time to help you, or they may not. You don't have a paid support contract with them, so while they're likely to try and help you out if they can, they're certainly under no obligation.
You can also get those things ready-to-use from various places, and can even buy support for them from someone who *is* obligated to help you. Which path you choose is up to you.
[*] https://wiki.openstack.org/wiki/MailingListEtiquette
Jeremy Stanley
participants (7)
-
Adam Peacock
-
Albert Braden
-
Jeremy Stanley
-
Mohammed Naser
-
Sean Mooney
-
Tony Pearce
-
Walter Boring