Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team
Same here. I’m definitely interested in helping out but not sure how much time I can commit to. Will most definitely help out with reviews and other decision making process to help ensure magnum-ui is implemented and in the correct direction relating to Horizon. From: Thai Q Tran tqt...@us.ibm.commailto:tqt...@us.ibm.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, June 4, 2015 at 2:07 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team I am interested but not sure how much time I have this release cycle. I can take on a more hands-off approach and help review to make sure that magnum-ui is align with future horizon directions. -Steven Dake (stdake) std...@cisco.commailto:std...@cisco.com wrote: - To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org From: Steven Dake (stdake) std...@cisco.commailto:std...@cisco.com Date: 06/04/2015 11:03AM Subject: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team Hey folks, I think it is critical for self-service needs that we have a Horizon dashboard to represent Magnum. I know the entire Magnum team has no experience in UI development, but I have found atleast one volunteer Bradley Jones to tackle the work. I am looking for more volunteers to tackle this high impact effort to bring Containers to OpenStack either in the existing Magnum core team or as new contributors. If your interested, please chime in on this thread. As far as “how to get patches approved”, there are two models we can go with. Option #1: We add these UI folks to the magnum-core team and trust them not to +2/+A Magnum infrastructure code. This also preserves us as one team with one mission. Option #2: We make a new core team magnum-ui-core. This presents special problems if the UI contributor team isn’t large enough to get reviews in. I suspect Option #2 will be difficult to execute. Cores, please vote on Option #1, or Option #2, and Adrian can make a decision based upon the results. Regards -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] FFE request for Firewall Router insertion BP
Dear Horizon community, I would like to request an FFE for the review we have out currently for the firewall feature in the project dashboard. The review is at - https://review.openstack.org/#/c/162552/ This feature is very important for the neutron FWaaS community to move the firewall feature from out of experimental stage. It allows for firewalls to finally be applied to a router and having Horizon support for this will greatly enhance the ability to use FWaaS. The neutron side of the feature got merged just before the K-3 deadline and there isn¹t a neutron client dependency on Horizon for this. A final review version to address comments about UT and also a details page will be made very shortly. The review in its current state is ready to test and for anyone to try out. Please make sure to include the q-fwaas service in your local.conf if testing. Requesting Akihiro and David to please sponsor reviews (as discussed on IRC). Much thanks and kind regards, Abishek __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [horizon] Question about behavior of override_settings
Hi,
This has to do with a patch I have out for review currently -
https://review.openstack.org/#/c/90093/
I believe version 5 to be the proper solution for the problem with the
unit tests that I am trying to fix.
However based on some comments that asked me to try a couple things,
version 7 is the latest one out but
I have a couple of questions regarding the behavior I am observing.
1. The diffs change the running of tests in admin/networks/tests.py -
A small snippet is this addition -
@override_settings(OPENSTACK_NEUTRON_NETWORK={'profile_support': None})
def test_network_create_get_with_no_profile(self):
self.test_network_create_get(test_with_profile=False)
This essentially defines a new UT which invokes an existing one but with
different settings.
This same patch for the similar project/networks/tests.py containing the
exact same test however does not work the same way.
It seems that the override_settings somehow finds fault with the
test.create_stubs of the base test.
I put this down to the possibly the definition of the test class itself.
In admin/networks it is - class NetworkTests(test.BaseAdminViewTests):
Whereas in project/networks it is - class NetworkTests(test.TestCase):
Anyone have any idea what the difference is between the two and also
why the BaseAdminViewTests would affect the settings differently?
Also would appreciate any further reviews on this.
Thanks!
Abishek
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [horizon] Help debugging js files
Hi, I need to make some changes to the horizon.instances.js file and I was wondering what the best method would be to help debug issues in this file? Is there a debugger or something available to debug this file separately? Thanks! Abishek ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon][dashboards] Running the 'profile' specific unit tests
Hi all, Akihiro, I wanted to get a little feedback on the issue regarding the running of the dashboard unit tests with the cisco n1k profiles (and very soon the cisco DFA profiles) and more specifically how to have existing network and instance unit tests run both with and without profiles. Currently there all tests relating to profiles are turned off by default. In order to run them, you need to manually go enable running them by changing the test/settings.py file. Based on community feedback and review comments from Akihiro, I raised this bug to fix this issue - https://bugs.launchpad.net/horizon/+bug/1229819 I have an initial WIP review out for it as well that I'd appreciate feedback on. There are two kinds of 'profile' related tests. One set is directly part of the 'router' dashboard. These I have fixed via the review to now run always by default. There is another set - in existing network and instance launch unit tests. The issue with these tests is that the network create and nova server create APIs will need a profile_id argument if and only if the appropriate neutron plugin is being used. If not, the neutron APIs will not take a profile_id argument. Hence, in horizon, the code checks to see if the profile_id should be given or not. Similarly the unit tests mock this same behavior. The dilemma here is how to run the same unit test and hence the same portion of actual code once with the profiles and once without. I'd appreciate any suggestions. Please let me know if there are any further questions to clarify this problem. Regards, Abishek ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon][dashboards] Running the 'profile' specific unit tests
Just to add to this - Akihiro did mention the usage of @override_settings I've seen examples of this in existing unit tests and I can implement something similar. This will mean however that we will have the test with the default setting and then the same test again with the override which accepts the profile_id yes? On 4/24/14 10:54 AM, Abishek Subramanian (absubram) absub...@cisco.com wrote: Hi all, Akihiro, I wanted to get a little feedback on the issue regarding the running of the dashboard unit tests with the cisco n1k profiles (and very soon the cisco DFA profiles) and more specifically how to have existing network and instance unit tests run both with and without profiles. Currently there all tests relating to profiles are turned off by default. In order to run them, you need to manually go enable running them by changing the test/settings.py file. Based on community feedback and review comments from Akihiro, I raised this bug to fix this issue - https://bugs.launchpad.net/horizon/+bug/1229819 I have an initial WIP review out for it as well that I'd appreciate feedback on. There are two kinds of 'profile' related tests. One set is directly part of the 'router' dashboard. These I have fixed via the review to now run always by default. There is another set - in existing network and instance launch unit tests. The issue with these tests is that the network create and nova server create APIs will need a profile_id argument if and only if the appropriate neutron plugin is being used. If not, the neutron APIs will not take a profile_id argument. Hence, in horizon, the code checks to see if the profile_id should be given or not. Similarly the unit tests mock this same behavior. The dilemma here is how to run the same unit test and hence the same portion of actual code once with the profiles and once without. I'd appreciate any suggestions. Please let me know if there are any further questions to clarify this problem. Regards, Abishek ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] Regarding bug/bp https://bugs.launchpad.net/horizon/+bug/1285298
Hi all, Akihiro, David, This is regarding the review for - https://review.openstack.org/#/c/76653/ Akihiro - Thanks for the review as always and as I mentioned in the review comment I completely agree with you. This is a small featurette. However this is small in that it adds to a chociefield in an existing forms.py attribute that I left out which neutron supports. And so in addition, I also had to add some code to my clean routine and yes update the string in the create description to include this new option. I have more test code really, than actual code. It was small enough, and hence I made request that this be treated as a bug and not a bp. And only then did I proceed to open the bug. I will respect what the community decides on this. Please let me know how we wish to proceed. Thanks and regards, Abishek ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] test_launch_instance_post questions
Hi all, jpich, amotoki and toshi,
I'm including a link to a small set of diff to show you what I'm trying to
do.
It is obviously a small subset of what I want to do.
https://www.dropbox.com/s/r7khv7gvdcd02gl/launch_instance_post_diff.patch
But to illustrate the issue I am seeing and to help my understanding of
this
test, all I'm doing is this - I've added a new network in the neutron_data
that is similar to the first network. Then I have replaced the nics
argument
which is needed to launch an instance. It now takes my new network instead
of
the first network.
However the test fails because when it is run, it is supposed to expect my
new network
but it actually finds the first network in the code.
The problem in code is here -
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashbo
ards/project/instances/workflows/create_instance.py
Lines 700-705:
netids = context.get('network_id', None)
if netids:
nics = [{net-id: netid, v4-fixed-ip: }
for netid in netids]
else:
nics = None
This part is confusing. In the UT environment, can I please get some help
in understanding how this line
seems to always pick the first network when this particular test is run?
Thanks!
On 3/11/14 9:58 AM, Abishek Subramanian (absubram) absub...@cisco.com
wrote:
Hi,
Can I please get some help with this UT?
I am having a little issue with the nics argument -
nics = [{net-id: netid, v4-fixed-ip: }
I wish to add a second network to this argument, but somehow
the UT only picks up the first network.
Any guidance will be appreciated.
Thanks!
On 3/6/14 12:06 PM, Abishek Subramanian (absubram) absub...@cisco.com
wrote:
Hi,
I had a couple of questions regarding this UT and the
JS template that it ends up using.
Hopefully someone can point me in the right direction
and help me understand this a little better.
I see that for this particular UT, we have a total of 3 networks
in the network_list (the second network is supposed to be disabled
though).
For the nic argument needed by the nova/server_create API though we
only pass the first network's net_id.
I am trying to modify this unit test so as to be able to accept 2
network_ids
instead of just one. This should be possible yes?
We can have two nics in an instance of just one?
However, I always see that when the test runs,
in code it only finds the first network from the list.
This line of code -
if netids:
nics = [{net-id: netid, v4-fixed-ip: }
for netid in netids]
There's always just one net-id in this dictionary even though I've added
a new network in the neutron test_data. Can someone please help me
figure out what I might be doing wrong?
How does the JS code in horizon.instances.js file work?
I assume this is where the network list is obtained from?
How does this translate in the unit test environment?
Thanks!
Abishek
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] test_launch_instance_post questions
Hi,
Can I please get some help with this UT?
I am having a little issue with the nics argument -
nics = [{net-id: netid, v4-fixed-ip: }
I wish to add a second network to this argument, but somehow
the UT only picks up the first network.
Any guidance will be appreciated.
Thanks!
On 3/6/14 12:06 PM, Abishek Subramanian (absubram) absub...@cisco.com
wrote:
Hi,
I had a couple of questions regarding this UT and the
JS template that it ends up using.
Hopefully someone can point me in the right direction
and help me understand this a little better.
I see that for this particular UT, we have a total of 3 networks
in the network_list (the second network is supposed to be disabled
though).
For the nic argument needed by the nova/server_create API though we
only pass the first network's net_id.
I am trying to modify this unit test so as to be able to accept 2
network_ids
instead of just one. This should be possible yes?
We can have two nics in an instance of just one?
However, I always see that when the test runs,
in code it only finds the first network from the list.
This line of code -
if netids:
nics = [{net-id: netid, v4-fixed-ip: }
for netid in netids]
There's always just one net-id in this dictionary even though I've added
a new network in the neutron test_data. Can someone please help me
figure out what I might be doing wrong?
How does the JS code in horizon.instances.js file work?
I assume this is where the network list is obtained from?
How does this translate in the unit test environment?
Thanks!
Abishek
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] Edit subnet in workflows - ip_version hidden?
Hi, I had a question regarding the dashboards/project/networks/subnets/workflows.py file and in particular the portion of the ip_version field. It is marked as a hidden input field for the update subnet class with this note. # NOTE(amotoki): When 'disabled' attribute is set for the ChoiceField # and ValidationError is raised for POST request, the initial value of # the ip_version ChoiceField is not set in the re-displayed form # As a result, 'IPv4' is displayed even when IPv6 is used if # ValidationError is detected. In addition 'required=True' check complains # when re-POST since the value of the ChoiceField is not set. # Thus now I use HiddenInput for the ip_version ChoiceField as a work # around. Can I get a little more context to this please? I'm not sure I understand why it says this field always is displayed as IPv4. Is this still the case? Adding some debug logs I seem to see that the ipversion is correctly being detected as 4 or 6 as the case may be. Thanks! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Edit subnet in workflows - ip_version hidden?
Thanks Radomir.
Yes I've changed it to a readonly. But just wanted to double check
I didn't end up breaking something elsewhere :)
Althouh - how up to date is this code?
These are the actual lines of code -
# NOTE(amotoki): When 'disabled' attribute is set for the ChoiceField
# and ValidationError is raised for POST request, the initial value of
# the ip_version ChoiceField is not set in the re-displayed form
# As a result, 'IPv4' is displayed even when IPv6 is used if
# ValidationError is detected. In addition 'required=True' check
complains
# when re-POST since the value of the ChoiceField is not set.
# Thus now I use HiddenInput for the ip_version ChoiceField as a work
# around.
ip_version = forms.ChoiceField(choices=[(4, 'IPv4'), (6, 'IPv6')],
#widget=forms.Select(
#attrs={'disabled': 'disabled'}),
widget=forms.HiddenInput(),
label=_(IP Version))
I don't think ip_version even has an attribute or an option to be set to
'disabled'.
Is this from an old version where the create side got fixed but the update
side was forgotten about?
On 3/11/14 11:30 AM, Radomir Dopieralski openst...@sheep.art.pl wrote:
On 11/03/14 15:52, Abishek Subramanian (absubram) wrote:
Hi,
I had a question regarding the
dashboards/project/networks/subnets/workflows.py
file and in particular the portion of the ip_version field.
It is marked as a hidden input field for the update subnet class with
this
note.
# NOTE(amotoki): When 'disabled' attribute is set for the ChoiceField
# and ValidationError is raised for POST request, the initial value
of
# the ip_version ChoiceField is not set in the re-displayed form
# As a result, 'IPv4' is displayed even when IPv6 is used if
# ValidationError is detected. In addition 'required=True' check
complains
# when re-POST since the value of the ChoiceField is not set.
# Thus now I use HiddenInput for the ip_version ChoiceField as a
work
# around.
Can I get a little more context to this please?
I'm not sure I understand why it says this field always is displayed as
IPv4.
Is this still the case? Adding some debug logs I seem to see that the
ipversion is correctly being detected as 4 or 6 as the case may be.
Some browsers (Chrome, iirc) will not submit the values from form fields
that are disabled. That means, that when re-displaying this form
(after an error in any other field, for example), that field's value
will be missing, and the browser will happily display the first option,
which is ipv4.
Another solution could be perhaps using readonly instead of disabled.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Openstack-dev][Horizon] test_launch_instance_post questions
Hi,
I had a couple of questions regarding this UT and the
JS template that it ends up using.
Hopefully someone can point me in the right direction
and help me understand this a little better.
I see that for this particular UT, we have a total of 3 networks
in the network_list (the second network is supposed to be disabled though).
For the nic argument needed by the nova/server_create API though we
only pass the first network's net_id.
I am trying to modify this unit test so as to be able to accept 2
network_ids
instead of just one. This should be possible yes?
We can have two nics in an instance of just one?
However, I always see that when the test runs,
in code it only finds the first network from the list.
This line of code -
if netids:
nics = [{net-id: netid, v4-fixed-ip: }
for netid in netids]
There's always just one net-id in this dictionary even though I've added
a new network in the neutron test_data. Can someone please help me
figure out what I might be doing wrong?
How does the JS code in horizon.instances.js file work?
I assume this is where the network list is obtained from?
How does this translate in the unit test environment?
Thanks!
Abishek
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][IPv6] Testing functionality of IPv6 modes using Horizon
Hi, I just wanted to find out if anyone had been able to test using Horizon? Was everything ok? Additionally wanted to confirm - the two modes can be updated too yes when using neutron subnet-update? Thanks! On 2/18/14 12:58 PM, Abishek Subramanian (absubram) absub...@cisco.com wrote: Hi shshang, all, I have some preliminary Horizon diffs available and if anyone would be kind enough to patch them and try to test the functionality, I'd really appreciate it. I know I'm able to create subnets successfully with the two modes but if there's anything else you'd like to test or have any other user experience comments, please feel free to let me know. The diffs are at - https://review.openstack.org/74453 Thanks!! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][IPv6] Testing functionality of IPv6 modes using Horizon
Hi shshang, all, I have some preliminary Horizon diffs available and if anyone would be kind enough to patch them and try to test the functionality, I'd really appreciate it. I know I'm able to create subnets successfully with the two modes but if there's anything else you'd like to test or have any other user experience comments, please feel free to let me know. The diffs are at - https://review.openstack.org/74453 Thanks!! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Openstack][Horizon] switchable switched classes in forms.py
Hi, I can see that the forms.py file can have parameters/inputs that are of class type switchable switched, i.e. this field 'B' will appear on the form if it's 'switched' based on a choice from a previous field 'A'. Then depending on the choice made for 'B', field 'C' will appear on the form. I want to now find out if the 'choices' for the forms field 'B' can also be switched. i.e depending on the choice made in field 'A', the choices that will appear for 'B' will change. Is this doable? Thanks! Abishek ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack-dev Digest, Vol 22, Issue 27
Hi Shixiong, Thanks for the reply and clearing up my question! The document you've shared - they aren't the only possible combinations correct? Each of the two fields can have any one of these four values in any possible combination yes? Thanks! On 2/11/14 7:00 AM, openstack-dev-requ...@lists.openstack.org openstack-dev-requ...@lists.openstack.org wrote: Hi, Abishek: Thank you for taking care of Horizon for IPv6 enhancement. So now we have coverage on both CLI and dashboard side. Very exciting! W.r.t your questions, these two parameters work independently. In other words, Horizon should present both options if the interested subnet is IPv6. For each parameter, the valid values are: off slacc dhcpv6-stateful dhcpv6-stateless The CLI command may look like, for example, something below: neutron subnet-create --ip-version 6 --ipv6_ra_mode off --ipv6_address_mode off NETWORK CIDR neutron subnet-create --ip-version 6 --ipv6_ra_mode off --ipv6_address_mode dhcpv6-stateful NETWORK CIDR neutron subnet-create --ip-version 6 --ipv6_ra_mode slaac --ipv6_address_mode slaac NETWORK CIDR neutron subnet-create --ip-version 6 --ipv6_ra_mode dhcpv6-stateful --ipv6_address_mode off NETWORK CIDR neutron subnet-create --ip-version 6 --ipv6_ra_mode dhcpv6-stateless --ipv6_address_mode dhcpv6-stateless NETWORK CIDR The valid combinations are outlined in the PDF file below. https://www.dropbox.com/s/9bojvv9vywsz8sd/IPv6%20Two%20Modes%20v3.0.pdf Please let me know if you have any further questions. Thanks! Shixiong ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] CLI for the new subnet keywords
Hi IPv6 experts, This is regarding the BP - https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes Is it possible to give me a quick example of the CLI that you envision? This is so that the Horizon BP can be updated accordingly. Once the neutron side of things is ready, when creating a subnet, and the version is IPv6 will now enable these two options, yes? Can both options exist or is it an either/or combination, i.e. either ipv6_ra or ipv6_address? Thanks! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
