Status Update - 6/21/2016



  • We know that we have not been making any public releases in some time, and that we have been mostly silent outside of our IRC channel about the current status of the project.

    Rest assured, this is not because we are dead. We are just busy.

    Since both heads have acquired full-time jobs, our ability to dedicate large amounts of time to this project has been hampered, but we are not letting this stop us. We have been working behind the scenes to prepare and plan for the new pufferd project, and looking to see how we can improve the user experience as a whole.

    Puffrfish has been active on our community forum, helping out our users with their problems, and just giving off the light of “we are still here”, and we are thankful for that.

    This last week, Lord_Ralex has been pushing large amounts of code to get pufferd to a working state, and so far it’s been promising. While the framework for it is basic, it has already demonstrated a drastic improvement in the quality and design over Scales, and we are confident that pufferd will be a completely better experience in the usability, customization, and installation.

    We are at this current moment planning on a new release plan for pufferd when most of the basic implementation is in place to begin moving users off of Scales and onto the new daemon. What will happen is the following:

    1. A minor release of PufferPanel will be required to allow for talking to pufferd and to resolve minor bugs with the panel. While pufferd was planned to be a drop-in replacement, it has been determined that while this is a goal, we are not going to keep it as a hard requirement. One place where this will not remain is the API itself. Pufferd uses a new API method, which we believe is clearer and simpler to use over Scales. This new API will be consumed by PufferPanel and so a code change is required for us to do that. We do hope the new API will be friendlier to users and administrators, and makes creation of billing and deployment modules that much easier to make.

    2. Pufferd will go through alpha releases once the minor release is ready. As part of the release scheduled above, one option we are considering is the ability to select which daemon to use. This would mean that you could use pufferd on the minor release and help test, or use Scales until its ready. This is a goal, so we may not allow the option to select if we determine the effort is too great.

    3. We will incorporate version checking into pufferd and likely PufferPanel to help notify users when the software needs update, as pufferd will need several updates to become completely ready. We will not be doing auto-updates, just update notification.

    We do not have any ETAs for when this will be ready, as things come up. We are hoping to have an alpha build “use-able” in the near future, but since we are using Golang, distribution of pufferd is a bit more work on our end, and that’s not in place yet.

    PufferD has so far been promising, allowing for a much more flexible system both internally and externally, and small testing has allowed for a much cleaner install process for servers, and allowing the flexibility to change how a server in general works.

    The biggest change to how servers are generated is through a new “template” system. Instead of hardcoding a server type into the program and hoping it works correctly, we have moved to a generic type process, and define templates that are used when a server is made. This means that the same code that powers Vanilla Minecraft is shared with Spigot and their Craftbukkit build (which internally we call fakecraftbukkit, but that’s a choice by Lord_Ralex, not by the project). With that, each process can build differently, but use the same code to work. To add in Forge would require a small json file change, and it would then be supported. Modpack support from FTB would follow suite, by just needing json files, which is a drastic improvement over Scales. We hope this new system will allow for a much wider scope, such as permitting Starmade servers or any other Java-driven application without requiring any code change, and just creating a new template json. This same concept will apply to other processes, so SRCDS servers would end up following this pattern, being defined under a generic SRCDS package and json templates would define what type of server it is and how to create and run it. One great improvement with this system is that we hope to allow creation of servers on Windows, which is not possible with Scales.
    Our templates currently in use can be viewed here: https://github.com/PufferPanel/pufferd/blob/master/data/templates/minecraft.go

    The next change moving forward is server file location. Scales currently populates 2 directories: /srv/scales and /home. Since the use of /home and creating system users is a bit impractical, pufferd only uses /srv/pufferd for all files, including servers. This means to remove PufferD is simply deleting this folder. Currently, the internal system does not containerize any servers, but we plan to keep this structure when we add back containers, but not add tons of system users and /home directories which make removing Scales harder.

    Finally, our new API. This API differs from Scales in that we are no longer using the header for any values, which made calling the API much more difficult. We have changed this to using strictly URL parameters, which will still remain secure when HTTPS is used. We have not yet forced HTTPS, but there are plans to do so.
    This means our new API has changed from this:

    curl -X "GET" "https://static.pufferpanel.com:5656/server/power/on" \
          -H "X-Access-Server: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
          -H "X-Access-Token: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
    

    To this:

    curl -X "GET" "https://static.pufferpanel.com:5656/server/myserverid/start?privkey=myprivatekey"
    

    This new API is a lot cleaner and simpler to use, and we hope will help creation of new modules.

    We are very excited for our plans for PufferD, and we hope we have explained why we have been silent for a while. We know that there are issues with our software, and we hope this new daemon will help resolve many of those issues that currently plague Scales.

    As always, thank you for using PufferPanel!



  • Rest assured, this is not because we are dead. We are just busy.. Oh good. I thought someone had killed you all over the wrong version number in 0.8.6 :p.

    I'm really excited to try out the new API method, since copying keys around different PHP files is really annoying. Will the GET and POST methods stay the same, though (will I just have to update URLs and take out headers), or will I need to redo stuff? And will it be documented this time? :p

    This build sounds like it's going to be amazing. Can't wait!



  • @zacharee said:

    I'm really excited to try out the new API method, since copying keys around different PHP files is really annoying. Will the GET and POST methods stay the same, though (will I just have to update URLs and take out headers), or will I need to redo stuff? And will it be documented this time? :p

    Right now, the methods will not, because of how different the URLs are. The examples that I demonstrated above show how the start differs actually. We have changed so the URL paths will actually now point to a server instead of being a header, so you will always know that /server/myserverid is your server, and not /server/power/on is a "what even is this pointing to". So yes, unfortunately, the API with pufferd will be a breaking API change. We currently have code that's conceptually meant to be a legacy API, but I think that this stage we may just remove it, because of how drastically different PufferD works compared to Scales.

    And yes, I plan on having better documentation. Right now this is all still a work in process, but we do plan on documenting it.

    An old design that I believe we may switch back to is that you do not talk to PufferD directly, but instead you talk to PufferPanel, which talks to PufferD. I may revert that and keep it how Scales is, but it's something I'm heavily considering.

    I am not a fan of the typical user talking to the backend (or even regular users), and so I want to reduce how much users talk to PufferD, but instead move to a PufferPanel api instead. So do understand that while PufferD's API would be simpler and the current method, it may change again in the future once the panel has received its major updates.



  • OK. I'm fine if it works or if it doesn't. After all, it's a way to learn more PHP (even if I can't stand it). As long as I don't have too dig through your source code again to find what I'm supposed to do, I'm good :p.



  • @LordRalex
    Thank you for continue the great project!



  • arghhhhh , been waiting for this !!! Waiting for good news!!! Really excited about what will it be looked like.



  • Yes!!! Finaly, I've been waiting for this :)


Log in to reply
 

Looks like your connection to PufferPanel Community was lost, please wait while we try to reconnect.