@chrisronline We seem to have uncovered a few bugs with the new UI.
The counts seem to be off for some reason
In the below example, upon entering the page or using * you see that 16 indices are available to create a matching index pattern for

However, if you were to specify an index pattern somehow the number of indices increased to 20.

This was consistently reproducible. Are we doing any type of caching here for that initial count? Is it possible this view could be affected if a user is ingesting data in parallel?
Include internal indices can be confusing
The current implementation of include internal indices can get a bit confusing when you start to apply it to more general index patterns. Specifically * or any index pattern that starts off similar to an internal index .*
If you go through this wizard and create an index pattern for all indices (*) with the "Include internal indices" check box unchecked, the internal indices are still included. While technically this makes sense, a user wouldn't expect them to be included because they were not in the table below. The "include internal indices" option only seems to filter on the table. So if a user expects to select all indices (but none of the internal indices) they'll be presented with timestamps and fields from internal indices as well.
I'm not sure what the best approach here would be. Ideally, this option is still off by default. I had some initial thoughts here but none are ideal
- Move the checkbox to the table and instead change the label to "Show internal indices" or "Hide internal indices". This way the configuration is tied directly to the table
- Provide a separate tab to the table that is specific to internal indices (also weird)
- Always show internal indices and rename the checkbox to "exclude internal indices". Checking this option would append the necessary exclusions (mentioned below) to the index pattern
We may be leaving out additional index patterns
You can technically search for index patterns that support inclusion / exclusion rules, example of using *,-.* below:

This doesn't seem possible in today's index pattern management page either. However, I'm not sure if we decided not to support these types of index patterns in Kibana or an oversight.

@epixa or @skearns64 may be able to provide some insight here.
@chrisronline We seem to have uncovered a few bugs with the new UI.
The counts seem to be off for some reason
In the below example, upon entering the page or using

*you see that 16 indices are available to create a matching index pattern forHowever, if you were to specify an index pattern somehow the number of indices increased to 20.

This was consistently reproducible. Are we doing any type of caching here for that initial count? Is it possible this view could be affected if a user is ingesting data in parallel?
Include internal indices can be confusing
The current implementation of include internal indices can get a bit confusing when you start to apply it to more general index patterns. Specifically
*or any index pattern that starts off similar to an internal index.*If you go through this wizard and create an index pattern for all indices (
*) with the "Include internal indices" check box unchecked, the internal indices are still included. While technically this makes sense, a user wouldn't expect them to be included because they were not in the table below. The "include internal indices" option only seems to filter on the table. So if a user expects to select all indices (but none of the internal indices) they'll be presented with timestamps and fields from internal indices as well.I'm not sure what the best approach here would be. Ideally, this option is still off by default. I had some initial thoughts here but none are ideal
We may be leaving out additional index patterns
You can technically search for index patterns that support inclusion / exclusion rules, example of using

*,-.*below:This doesn't seem possible in today's index pattern management page either. However, I'm not sure if we decided not to support these types of index patterns in Kibana or an oversight.

@epixa or @skearns64 may be able to provide some insight here.