Road map for 16.1 and beyond

[chol]

We have reached the first milestone Production Release of OPNsense, namely 15.7, which left development branch just today (July 2, 2015)!

16.1 is in the development branch of OPNsense as of July 215 , also!
From the roadmap on opnsense.org one can look up  these 4 aims for 16.1 so far:

• Package / Plugin implementation
• Security updates
• Replace ACL
• Unattended / Automated installation

Oppinion: Would be good if we had a list of far away topics for 16.7 also.

I would like to start a list if it was appropriate. If not just say so. We could agree and try to get in contact with possible developers, or get developers interested, which would be interested in (long-term/short-term) cooperation!?

ROADMAP for 16.7

• NanoBSD image w/ 2 working slices
  
• BIND alternatives ?: NSD, Unbound (DNS server)
  
• ALt. hardwareplatforms : MIPS64^)  , ARM$)
  
• IPv6-style forms etc. pp. in the GUI %)
  
• ext2*)
  

Notes:
^)  FreeBSD 10.x on MIPS64 - Ubiquiti EdgeRouter Lite
$)   FreeBSD/ARM
%)  OpenWRT würfelt IPv6-Präfixe (german, "OpenWRT casts random IPv6-prefixes")
*)   just kidding

[franco]

Thanks for getting this rolling, Christian. I moved the topic to General due to the larger scope (even thinking about 16.7 now feels a little weird, but good). We will pick a few initial items for 16.1 today and throw them in here for transparency and scrutiny.

@everyone: we'd like to have your personal wish list for 16.1 to select items from

[Supermule]

A better GUI. preferably widescreen adaptable.

MOre columns, able to move widgets around. Menu on top and dropdown or menu left and then 2nd level menu to the right (see picture).

I this case its very simple since its text and can be moved around as wished very easily.

Based on js script.

Menu can be seen here http://bjerring-jensen.dk

[chol]

O.K.

I would like to add

* Unattended / Automated update/upgrade both kernel and ports/plugins
* possible a web content filter

(even thinking about 16.7 now feels a little weird, but good)

Suggested just because since now we had development branch 15.7 and future branch 16.1, so I thought this would continue..

[lucifercipher]

If i may suggest something chol. Even though this project has been under development but just recently went stable. Setting the RoadMap is an excellent idea but it is too early to look for a substitute for Bind, support off the shelf embedded devices, etc for example. In my opinion, the RoadMap should wait a little while this project goes to couple of racks around the world and face real life challenges. There is clearly room for improvement and a lot of feedback is needed still from the community.

Let me know your thoughts on this. Thanks. 

[franco]

We're finalising our internal meta-discussion on the roadmap and we've come to the conclusion that we are going to provide the following:

(1) Reachable goals for 16.1
(2) Vision and wishlist for 16.7+

This allows us to remain flexible by not locking in on 16.7 just yet while staying transparent on the matter of what happens after 16.1.

A few comments about the suggestions follow in the next post.

[franco]

NanoBSD image w/ 2 working slices  -- This is definitely going on the wish list.

BIND alternatives ?: NSD, Unbound (DNS server) -- Not sure about this. Unbound is already in there but needs more work. Bind is only used for Dynamic DNS via RFC 2136. We have had, however, numerous requests to include a full Bind build. Though we can split off Bind from the default installation as soon as our plugins are ready with 16.1.

Alt. hardware platforms (mips,arm) -- Generally, yes, but we need people willing to help to compile and verify here. We can talk all fixes, but we can't provide builds on the notion of having to support them on our own. Our ecosystem is quite big for our small project as is with amd64 and i386, OpenSSL and LibreSSL, and 4 types of images. This is going on the wish list.

GUI padding and wide screen support (maybe even themes)  -- We are aware and a ticket exists, but it's not going on the wish list or roadmap as these are minor improvements that don't affect functionality so these things can happen for 15.7 too. I have these on my personal list. A ticket is here: https://github.com/opnsense/core/issues/238

I'm also going to throw ZFS into the wish list mix or is anybody against that?

[jstrebel]

Don't forget the appliances wich have lower performance and Memory.
jakob

[franco]

There is an effort to split off base functionality and move it into the plugins instead. This would allow for a slicker installation for small uses cases, but that's what I can think of in terms of slow devices. The approach that we try to pull off with API and privilege separation is likely not the approach to save CPU cycles. I can also think of headless systems, but they still need an API so the web server isn't going away.

Any ideas on how we can actively save CPU cycles without jeopardising the functional scope we are aiming at?

[franco]

Ad compiled the road map for us: https://opnsense.org/about/road-map/

[chol]

We're finalising our internal meta-discussion on the roadmap and we've come to the conclusion that we are going to provide the following:

(1) Reachable goals for 16.1
(2) Vision and wishlist for 16.7+

This allows us to remain flexible by not locking in on 16.7 just yet while staying transparent on the matter of what happens after 16.1.

Wonderful, exactly what I intended: a list of development goals, transparency and an outlook on possible interesting things with a little overhead of futuristic aims that might or might not be achieveable, but could make the project interesting and lively in the eyes of users, testers, developers and enthusiasts, new and supporting ones.

[chol]

There is an effort to split off base functionality and move it into the plugins instead. This would allow for a slicker installation for small uses cases, but that's what I can think of in terms of slow devices. The approach that we try to pull off with API and privilege separation is likely not the approach to save CPU cycles. I can also think of headless systems, but they still need an API so the web server isn't going away.

Any ideas on how we can actively save CPU cycles without jeopardising the functional scope we are aiming at?

A very theoretical question:
Was it imaginable/doable that all of OPNsense management could be outsourced to an App for your firewall-management device of choice - IPhone, Android, PC, tablet? This would leave a more stripped of and defensible base firewall at the TCP/IP internet-trenches.

Any ideas on how we can actively save CPU cycles without jeopardising the functional scope we are aiming at?

What is it, the "functional scope"? If services can be left asside as non-installed plugins in future OPNsense versions, is it logic to assume the functional scope was to fit a certain set of hardware, like in a OPNsense appliance-shop? I am confused.

[franco]

If you consider JavaScript/jQuery and our API to be a client-server type of architecture, it's doing that already. We can save cycles through PHP page serving, but reconfiguring the system will always be a constant. There is not much room for improvement short of only supplying an API and letting the other side ship the control logic and it won't have the desired impact or stripping down layers and/or functionality/complexity.

[chol]

There is not much room for improvement short of only supplying an API and letting the other side ship the control logic and it won't have the desired impact or stripping down layers and/or functionality/complexity.

What if an outside App would read config files from the firewall, modify it locally by GUI handlers and sent the modified config text back - like a GUI type of an console ssh connection?

[franco]

You' still need all the PHP glue to run the config.xml-driven system reconfiguration. You're making it headless, but that doesn't mean it's getting slimmer. It's like the tip of the iceberg with the GUI, but the real computing power is
underneath and still needs to run on the same system.