The status of PetaSAN Jan 2023
DennisV
5 Posts
January 9, 2023, 10:14 amQuote from DennisV on January 9, 2023, 10:14 amThe last 7-9 months I've been looking into using PetaSAN.
The current version 3.1 does work, but it's lacking a lot of updates , missing improvements and got various bugs.
The latest word on a newer version was back in Aug 2022, but nothing has been updated since.
It feels this project is maintained by a single individual and due to constraints this project is missing the TLC it needs.
Maybe also consider moving the project to a public git based system.
I'm not complaining about the lack of updates etc, just wondering what the status of PetaSAN is present day (Jan 2023).
Kind regards.
The last 7-9 months I've been looking into using PetaSAN.
The current version 3.1 does work, but it's lacking a lot of updates , missing improvements and got various bugs.
The latest word on a newer version was back in Aug 2022, but nothing has been updated since.
It feels this project is maintained by a single individual and due to constraints this project is missing the TLC it needs.
Maybe also consider moving the project to a public git based system.
I'm not complaining about the lack of updates etc, just wondering what the status of PetaSAN is present day (Jan 2023).
Kind regards.
admin
2,930 Posts
January 9, 2023, 12:17 pmQuote from admin on January 9, 2023, 12:17 pmThanks for the post. In general, the more the software matures the more changes take longer, but we are as active as from our beta days. It would be great if we hear what improvements you see lacking, user recommendations are invaluable to us, most get implemented in our newer releases. Please if you have bugs, please post them under bugs topic. We have big plans for PetaSAN, our goal is to do the most important use cases and do them very well, we put a lot of effort and upfront analysis to make sure the system works in a cohesive manner. SUSE had an enterprise storage product around Ceph which got discontinued, the main reason was it had too many use cases it tried to support.
Version 3.2 will include manual and automated/scheduled snapshot support, exporting snapshot read-only disks/shares and rolling back support + minor UI enhancements/additions. It will also have a 5.14 kernel based on latest SUSE SP4. We are also testing Ceph Quincy but not decided yet if it will make in 3.2, there were some performance issues reported by Ceph users so we want to make sure these are handled. I will try to post screenshots of the latest 3.2 UI additions we made in separate post.
We are a software company in Cairo, Egypt and are currently 7 people working full time between development, support and testing. We follow strict software development lifecycle process.
Thanks for the post. In general, the more the software matures the more changes take longer, but we are as active as from our beta days. It would be great if we hear what improvements you see lacking, user recommendations are invaluable to us, most get implemented in our newer releases. Please if you have bugs, please post them under bugs topic. We have big plans for PetaSAN, our goal is to do the most important use cases and do them very well, we put a lot of effort and upfront analysis to make sure the system works in a cohesive manner. SUSE had an enterprise storage product around Ceph which got discontinued, the main reason was it had too many use cases it tried to support.
Version 3.2 will include manual and automated/scheduled snapshot support, exporting snapshot read-only disks/shares and rolling back support + minor UI enhancements/additions. It will also have a 5.14 kernel based on latest SUSE SP4. We are also testing Ceph Quincy but not decided yet if it will make in 3.2, there were some performance issues reported by Ceph users so we want to make sure these are handled. I will try to post screenshots of the latest 3.2 UI additions we made in separate post.
We are a software company in Cairo, Egypt and are currently 7 people working full time between development, support and testing. We follow strict software development lifecycle process.
gb.123
4 Posts
January 12, 2023, 11:32 pmQuote from gb.123 on January 12, 2023, 11:32 pmHi !
New to this forum, but I would like to ask why are you guys not adding the source to GitHub ? Its free for Open-Source Software and a lot more people can help to contribute making this software grow exponentially.
If you guys want, I can put up the software to GitHub and also help you maintain it (Like uploading latest Sources, etc.)
Keep up the work !
Thanks
PS: Also, I think downloads (iso) can be externally hosted so that it becomes faster
Hi !
New to this forum, but I would like to ask why are you guys not adding the source to GitHub ? Its free for Open-Source Software and a lot more people can help to contribute making this software grow exponentially.
If you guys want, I can put up the software to GitHub and also help you maintain it (Like uploading latest Sources, etc.)
Keep up the work !
Thanks
PS: Also, I think downloads (iso) can be externally hosted so that it becomes faster
Last edited on January 12, 2023, 11:36 pm by gb.123 · #3
admin
2,930 Posts
January 13, 2023, 2:58 pmQuote from admin on January 13, 2023, 2:58 pmGood question and very valid 🙂 and i hope we will move to github. Yes PetaSAN is and will remain open source. The current issue is we are a software company and have internal software process (quite rigid i may say) and internally have been using subversion/svn for years. We did discuss moving to github a while back but at the time we found the current internal process suits us better and is more inline with how we develop software, we store code, design docs, test plans, requirement analysis..etc. I am not saying this is ideal for all and again hope we can take the jump to github.
So noted, and i will discuss us with the rest of us here.
Good question and very valid 🙂 and i hope we will move to github. Yes PetaSAN is and will remain open source. The current issue is we are a software company and have internal software process (quite rigid i may say) and internally have been using subversion/svn for years. We did discuss moving to github a while back but at the time we found the current internal process suits us better and is more inline with how we develop software, we store code, design docs, test plans, requirement analysis..etc. I am not saying this is ideal for all and again hope we can take the jump to github.
So noted, and i will discuss us with the rest of us here.
Last edited on January 13, 2023, 3:04 pm by admin · #4
gb.123
4 Posts
January 14, 2023, 4:52 pmQuote from gb.123 on January 14, 2023, 4:52 pmThe current issue is we are a software company and have internal software process (quite rigid i may say)
Well the same processes can be adopted with Git (with slight modifications)
and internally have been using subversion/svn for years. We did discuss moving to github a while back but at the time we found the current internal process suits us better and is more inline with how we develop software, we store code, design docs, test plans, requirement analysis..etc.
I understand that moving from SVN to Git would require a slight learning curve and might mean you need to slightly alter your current processes because of how things work in Git. But once tweaked, Git can help you develop MUCH faster than SVN. Besides, you don't need to move everything to Git-Hub all at once. My suggestion would be to move code first, then the other things. I am sure test plans, design docs, etc. can also be maintained via Git.
If you need any help from my side, I would be willing to pitch in some work re-designing your software processes.
The current issue is we are a software company and have internal software process (quite rigid i may say)
Well the same processes can be adopted with Git (with slight modifications)
and internally have been using subversion/svn for years. We did discuss moving to github a while back but at the time we found the current internal process suits us better and is more inline with how we develop software, we store code, design docs, test plans, requirement analysis..etc.
I understand that moving from SVN to Git would require a slight learning curve and might mean you need to slightly alter your current processes because of how things work in Git. But once tweaked, Git can help you develop MUCH faster than SVN. Besides, you don't need to move everything to Git-Hub all at once. My suggestion would be to move code first, then the other things. I am sure test plans, design docs, etc. can also be maintained via Git.
If you need any help from my side, I would be willing to pitch in some work re-designing your software processes.
The status of PetaSAN Jan 2023
DennisV
5 Posts
Quote from DennisV on January 9, 2023, 10:14 amThe last 7-9 months I've been looking into using PetaSAN.
The current version 3.1 does work, but it's lacking a lot of updates , missing improvements and got various bugs.
The latest word on a newer version was back in Aug 2022, but nothing has been updated since.
It feels this project is maintained by a single individual and due to constraints this project is missing the TLC it needs.
Maybe also consider moving the project to a public git based system.
I'm not complaining about the lack of updates etc, just wondering what the status of PetaSAN is present day (Jan 2023).Kind regards.
The last 7-9 months I've been looking into using PetaSAN.
The current version 3.1 does work, but it's lacking a lot of updates , missing improvements and got various bugs.
The latest word on a newer version was back in Aug 2022, but nothing has been updated since.
It feels this project is maintained by a single individual and due to constraints this project is missing the TLC it needs.
Maybe also consider moving the project to a public git based system.
I'm not complaining about the lack of updates etc, just wondering what the status of PetaSAN is present day (Jan 2023).
Kind regards.
admin
2,930 Posts
Quote from admin on January 9, 2023, 12:17 pmThanks for the post. In general, the more the software matures the more changes take longer, but we are as active as from our beta days. It would be great if we hear what improvements you see lacking, user recommendations are invaluable to us, most get implemented in our newer releases. Please if you have bugs, please post them under bugs topic. We have big plans for PetaSAN, our goal is to do the most important use cases and do them very well, we put a lot of effort and upfront analysis to make sure the system works in a cohesive manner. SUSE had an enterprise storage product around Ceph which got discontinued, the main reason was it had too many use cases it tried to support.
Version 3.2 will include manual and automated/scheduled snapshot support, exporting snapshot read-only disks/shares and rolling back support + minor UI enhancements/additions. It will also have a 5.14 kernel based on latest SUSE SP4. We are also testing Ceph Quincy but not decided yet if it will make in 3.2, there were some performance issues reported by Ceph users so we want to make sure these are handled. I will try to post screenshots of the latest 3.2 UI additions we made in separate post.
We are a software company in Cairo, Egypt and are currently 7 people working full time between development, support and testing. We follow strict software development lifecycle process.
Thanks for the post. In general, the more the software matures the more changes take longer, but we are as active as from our beta days. It would be great if we hear what improvements you see lacking, user recommendations are invaluable to us, most get implemented in our newer releases. Please if you have bugs, please post them under bugs topic. We have big plans for PetaSAN, our goal is to do the most important use cases and do them very well, we put a lot of effort and upfront analysis to make sure the system works in a cohesive manner. SUSE had an enterprise storage product around Ceph which got discontinued, the main reason was it had too many use cases it tried to support.
Version 3.2 will include manual and automated/scheduled snapshot support, exporting snapshot read-only disks/shares and rolling back support + minor UI enhancements/additions. It will also have a 5.14 kernel based on latest SUSE SP4. We are also testing Ceph Quincy but not decided yet if it will make in 3.2, there were some performance issues reported by Ceph users so we want to make sure these are handled. I will try to post screenshots of the latest 3.2 UI additions we made in separate post.
We are a software company in Cairo, Egypt and are currently 7 people working full time between development, support and testing. We follow strict software development lifecycle process.
gb.123
4 Posts
Quote from gb.123 on January 12, 2023, 11:32 pmHi !
New to this forum, but I would like to ask why are you guys not adding the source to GitHub ? Its free for Open-Source Software and a lot more people can help to contribute making this software grow exponentially.
If you guys want, I can put up the software to GitHub and also help you maintain it (Like uploading latest Sources, etc.)
Keep up the work !
Thanks
PS: Also, I think downloads (iso) can be externally hosted so that it becomes faster
Hi !
New to this forum, but I would like to ask why are you guys not adding the source to GitHub ? Its free for Open-Source Software and a lot more people can help to contribute making this software grow exponentially.
If you guys want, I can put up the software to GitHub and also help you maintain it (Like uploading latest Sources, etc.)
Keep up the work !
Thanks
PS: Also, I think downloads (iso) can be externally hosted so that it becomes faster
admin
2,930 Posts
Quote from admin on January 13, 2023, 2:58 pmGood question and very valid 🙂 and i hope we will move to github. Yes PetaSAN is and will remain open source. The current issue is we are a software company and have internal software process (quite rigid i may say) and internally have been using subversion/svn for years. We did discuss moving to github a while back but at the time we found the current internal process suits us better and is more inline with how we develop software, we store code, design docs, test plans, requirement analysis..etc. I am not saying this is ideal for all and again hope we can take the jump to github.
So noted, and i will discuss us with the rest of us here.
Good question and very valid 🙂 and i hope we will move to github. Yes PetaSAN is and will remain open source. The current issue is we are a software company and have internal software process (quite rigid i may say) and internally have been using subversion/svn for years. We did discuss moving to github a while back but at the time we found the current internal process suits us better and is more inline with how we develop software, we store code, design docs, test plans, requirement analysis..etc. I am not saying this is ideal for all and again hope we can take the jump to github.
So noted, and i will discuss us with the rest of us here.
gb.123
4 Posts
Quote from gb.123 on January 14, 2023, 4:52 pmThe current issue is we are a software company and have internal software process (quite rigid i may say)
Well the same processes can be adopted with Git (with slight modifications)
and internally have been using subversion/svn for years. We did discuss moving to github a while back but at the time we found the current internal process suits us better and is more inline with how we develop software, we store code, design docs, test plans, requirement analysis..etc.
I understand that moving from SVN to Git would require a slight learning curve and might mean you need to slightly alter your current processes because of how things work in Git. But once tweaked, Git can help you develop MUCH faster than SVN. Besides, you don't need to move everything to Git-Hub all at once. My suggestion would be to move code first, then the other things. I am sure test plans, design docs, etc. can also be maintained via Git.
If you need any help from my side, I would be willing to pitch in some work re-designing your software processes.
The current issue is we are a software company and have internal software process (quite rigid i may say)
Well the same processes can be adopted with Git (with slight modifications)
and internally have been using subversion/svn for years. We did discuss moving to github a while back but at the time we found the current internal process suits us better and is more inline with how we develop software, we store code, design docs, test plans, requirement analysis..etc.
I understand that moving from SVN to Git would require a slight learning curve and might mean you need to slightly alter your current processes because of how things work in Git. But once tweaked, Git can help you develop MUCH faster than SVN. Besides, you don't need to move everything to Git-Hub all at once. My suggestion would be to move code first, then the other things. I am sure test plans, design docs, etc. can also be maintained via Git.
If you need any help from my side, I would be willing to pitch in some work re-designing your software processes.