Re: [openstack-dev] [Neutron] Let's fix all neutron bugs! (NOT)

[marios]

On 07/11/14 11:17, Eugene Nikanorov wrote:
> Hi folks,
> 
> I have been supervising bug list for neutron during the last release
> cycle, trying
> to do some "housekeeping", prioritizing issues and fixing some of them.
> 
> As you might see, amount of bugs (even staying in "New" state) doesn't
> go down.
> Bugs appear at quite fast pace, and some of them hang for quite a long
> time, especially if someone has assigned the bug on himself and then
> abandoned working on it.
> One of the other reasons for that is that we lack volunteers willing to
> fix those bugs.
> 
> So,

Hi Eugene,

I started looking into various bugs a couple weeks before summit as a
way to learn more about the codebase - I can continue to do this into
this cycle and am happy to try anything,

thanks! marios

> 
> If you're willing to help, have some knowledge of neutron and its
> codebase or you have a lab where you can reproduce (and hence, confirm)
> the bug and provide more additional debugging info, that would be great! 
> My plan is to get your contact, knowing what "part" of neutron project
> you familiar with, and then assign bugs directly to you if I feel that
> the issue matches your experience.
> 
> I just want to make bug triaging/fixing process a bit more iterative and
> efficient, with a help of community.
> So please reach directly to me and let me know what you are
> interested/experienced with.
> 
> Thanks,
> Eugene.
> 
> 
> ___
> 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

Re: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon ode support

[John Schwarz]

+1. I think this is an important feature and I'd be happy to do reviews
when needed - hopefully this can get in by Kilo! :)

On 11/08/2014 12:24 PM, Armando M. wrote:
> Hi Miguel,
> 
> Thanks for picking this up. Pull me in and I'd be happy to help!
> 
> Cheers,
> Armando
> 
> On 7 November 2014 10:05, Miguel Ángel Ajo  > wrote:
> 
> 
> Hi Yorik,
> 
>I was talking with Mark Mcclain a minute ago here at the summit
> about this. And he told me that now at the start of the cycle looks
> like a good moment to merge the spec & the root wrap daemon bits, so
> we have a lot of headroom for testing during the next months.
> 
>We need to upgrade the spec [1] to the new Kilo format.
> 
>Do you have some time to do it?, I can allocate some time and do
> it right away.
> 
> [1] https://review.openstack.org/#/c/93889/
> -- 
> Miguel Ángel Ajo
> Sent with Sparrow 
> 
> On Thursday, 24 de July de 2014 at 01:42, Miguel Angel Ajo Pelayo wrote:
> 
>> +1
>>
>> Sent from my Android phone using TouchDown (www.nitrodesk.com
>> )
>>
>>
>> -Original Message-
>> From: Yuriy Taraday [yorik@gmail.com
>> ]
>> Received: Thursday, 24 Jul 2014, 0:42
>> To: OpenStack Development Mailing List
>> [openstack-dev@lists.openstack.org
>> ]
>> Subject: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap
>> daemon mode support
>>
>>
>> Hello.
>>
>> I'd like to propose making a spec freeze exception for
>> rootwrap-daemon-mode spec [1].
>>
>> Its goal is to save agents' execution time by using daemon mode
>> for rootwrap and thus avoiding python interpreter startup time as
>> well as sudo overhead for each call. Preliminary benchmark shows
>> 10x+ speedup of the rootwrap interaction itself.
>>
>> This spec have a number of supporters from Neutron team (Carl and
>> Miguel gave it their +2 and +1) and have all code waiting for
>> review [2], [3], [4].
>> The only thing that has been blocking its progress is Mark's -2
>> left when oslo.rootwrap spec hasn't been merged yet. Now that's
>> not the case and code in oslo.rootwrap is steadily getting
>> approved [5].
>>
>> [1] https://review.openstack.org/93889
>> [2] https://review.openstack.org/82787
>> [3] https://review.openstack.org/84667
>> [4] https://review.openstack.org/107386
>> [5] 
>> https://review.openstack.org/#/q/project:openstack/oslo.rootwrap+topic:bp/rootwrap-daemon-mode,n,z
>>
>> -- 
>>
>> Kind regards, Yuriy.
>> ___
>> 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 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

Re: [openstack-dev] [Manila] File-storage for Manila service image

[Hallur, Parashuram]

Is this image made available from some other location? I'm not able to download 
it from the dropbox?
  
Date: Tue, 5 Aug 2014 21:11:36 +
From: "Swartzlander, Ben" 
To: "openstack-dev@lists.openstack.org"

Subject: Re: [openstack-dev] [Manila] File-storage for Manila service
image
Message-ID: <1407273103.3455.4.camel@bswartz-u904>
Content-Type: text/plain; charset="utf-8"

On Tue, 2014-08-05 at 23:50 +0300, Valeriy Ponomaryov wrote:
> Github has file size limit in 100 Mb, see
> https://help.github.com/articles/what-is-my-disk-quota
> 
> 
> Our current image is about 300 Mb.

Do you think we could upload the file to launchpad somehow? I've seen LP
hosting various downloadable files. If that fails maybe the
openstack-infra team has a place for blobs.

Worst case we will just host in on S3 and pay for it out of our pockets.


> On Tue, Aug 5, 2014 at 11:43 PM, Swartzlander, Ben
>  wrote:
> On Tue, 2014-08-05 at 23:13 +0300, Valeriy Ponomaryov wrote:
> > Hello everyone,
> >
> >
> > Currently used image for Manila is located in
> > dropbox: ubuntu_1204_nfs_cifs.qcow2 and dropbox has limit
> for traffic,
> > see https://www.dropbox.com/help/4204
> >
> >
> > Due to generation of excessive traffic, public links were
> banned and
> > image could not be downloaded with error code 509, now it is
> unbanned,
> > until another excess reached.
> >
> >
> > Traffic limit should not threat possibility to use project,
> so we need
> > find stable file storage with permanent public links and
> without
> > traffic limit.
> >
> >
> > Does anyone have any suggestions for more suitable file
> storage to
> > use?
> 
> 
> Let's try creating a github repo and sharing it there. For
> hopefully
> obvious reasons, let's NOT put this into the manila repos
> directly --
> let's keep it separate.
> 
> 
> > --
> > Kind Regards
> > Valeriy Ponomaryov
> >
> 
> > ___
> > 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
> 
> 
> 
> 
> -- 
> Kind Regards
> Valeriy Ponomaryov
> 
> ___
> 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


End of OpenStack-dev Digest, Vol 28, Issue 11
*

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][advanced services] Weekly IRC meeting day/time change

[Damon Wang]

I use Event time announcer to create a event to convenient people in
different time zone:

http://www.timeanddate.com/worldclock/fixedtime.html?msg=Neutron+Advanced+Services&iso=2014T17&p1=1440

Hope helps
Damon

2014-11-10 12:14 GMT+08:00 Sumit Naiksatam :

> Hi All,
>
> Following up from the discussions during the Kilo Summit, we will be
> resuming the Advanced Services' meetings [1]. The new day/time will be
> Tuesday 17.00 UTC on #openstack-meeting-4 to follow the LBaaS meeting
> [2].
>
> Hope you can join.
>
> Thanks,
> ~Sumit.
>
> [1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2014-November/050005.html
>
> ___
> 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] [neutron][advanced services] Weekly IRC meeting day/time change

[Sumit Naiksatam]

Hi All,

Following up from the discussions during the Kilo Summit, we will be
resuming the Advanced Services' meetings [1]. The new day/time will be
Tuesday 17.00 UTC on #openstack-meeting-4 to follow the LBaaS meeting
[2].

Hope you can join.

Thanks,
~Sumit.

[1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices
[2] http://lists.openstack.org/pipermail/openstack-dev/2014-November/050005.html

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Let's fix all neutron bugs! (NOT)

[Damon Wang]

Hi Bryant,


> There is one potential downside with this workflow.  When a bug is
> assigned to someone, it will discourage anyone else from looking at it.
> You may end up with a lot of bugs assigned that are not actively being
> worked on.
>
Can't agree more

>
> An alternative approach would be to just subscribe developers you think
> may be willing and interested to take a look.  That way they'll get a
> notification email about it, but it won't discourage anyone else from
> working on it that may want to in the meantime.

Good Way!

Damon

2014-11-10 9:47 GMT+08:00 Russell Bryant :

>
>
> - Original Message -
> > Hi folks,
> >
> > I have been supervising bug list for neutron during the last release
> cycle,
> > trying
> > to do some "housekeeping", prioritizing issues and fixing some of them.
> >
> > As you might see, amount of bugs (even staying in "New" state) doesn't go
> > down.
> > Bugs appear at quite fast pace, and some of them hang for quite a long
> time,
> > especially if someone has assigned the bug on himself and then abandoned
> > working on it.
> > One of the other reasons for that is that we lack volunteers willing to
> fix
> > those bugs.
> >
> > So,
> >
> > If you're willing to help, have some knowledge of neutron and its
> codebase or
> > you have a lab where you can reproduce (and hence, confirm) the bug and
> > provide more additional debugging info, that would be great!
> > My plan is to get your contact, knowing what "part" of neutron project
> you
> > familiar with, and then assign bugs directly to you if I feel that the
> issue
> > matches your experience.
> >
> > I just want to make bug triaging/fixing process a bit more iterative and
> > efficient, with a help of community.
> > So please reach directly to me and let me know what you are
> > interested/experienced with.
>
> There is one potential downside with this workflow.  When a bug is
> assigned to someone, it will discourage anyone else from looking at it.
> You may end up with a lot of bugs assigned that are not actively being
> worked on.
>
> An alternative approach would be to just subscribe developers you think
> may be willing and interested to take a look.  That way they'll get a
> notification email about it, but it won't discourage anyone else from
> working on it that may want to in the meantime.
>
> --
> Russell Bryant
>
> ___
> 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

Re: [openstack-dev] [Neutron] Let's fix all neutron bugs! (NOT)

[Russell Bryant]

- Original Message -
> Hi folks,
> 
> I have been supervising bug list for neutron during the last release cycle,
> trying
> to do some "housekeeping", prioritizing issues and fixing some of them.
> 
> As you might see, amount of bugs (even staying in "New" state) doesn't go
> down.
> Bugs appear at quite fast pace, and some of them hang for quite a long time,
> especially if someone has assigned the bug on himself and then abandoned
> working on it.
> One of the other reasons for that is that we lack volunteers willing to fix
> those bugs.
> 
> So,
> 
> If you're willing to help, have some knowledge of neutron and its codebase or
> you have a lab where you can reproduce (and hence, confirm) the bug and
> provide more additional debugging info, that would be great!
> My plan is to get your contact, knowing what "part" of neutron project you
> familiar with, and then assign bugs directly to you if I feel that the issue
> matches your experience.
> 
> I just want to make bug triaging/fixing process a bit more iterative and
> efficient, with a help of community.
> So please reach directly to me and let me know what you are
> interested/experienced with.

There is one potential downside with this workflow.  When a bug is assigned to 
someone, it will discourage anyone else from looking at it.  You may end up 
with a lot of bugs assigned that are not actively being worked on.

An alternative approach would be to just subscribe developers you think may be 
willing and interested to take a look.  That way they'll get a notification 
email about it, but it won't discourage anyone else from working on it that may 
want to in the meantime.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] [UX] Curvature interactive virtual network design

[Stefano Santini]

Another +1 for me and 2 preliminary questions

Router visualisation will work also with Neutron DVR ?
Any change to handle also network services  ? (i.e. LBaaS)

Thanks & regards
Stefano

On Sun, Nov 9, 2014 at 5:39 PM, Stuart Fox  wrote:

> +1 from me
>
> Also, can you get Cisco to opensource Avos? It was demo'd at Atlanta
>
> On Sun, Nov 9, 2014 at 6:45 AM, Chris Dent  wrote:
>
>> On Fri, 7 Nov 2014, John Davidge (jodavidg) wrote:
>>
>>  We’d like to gauge interest from the community on whether this is
>>> something people want.
>>>
>>
>> When I go to the existing network topology maps in horizon I
>> frequently find myself wanting to drag stuff around.
>>
>> So +1 from me.
>>
>> --
>> Chris Dent tw:@anticdent freenode:cdent
>> https://tank.peermore.com/tanks/cdent
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> BR,
> Stuart
>
> ___
> 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

Re: [openstack-dev] [nova] pci pass through turing complete config options?

[Robert Collins]

On 7 Nov 2014 16:57, "Ian Wienand"  wrote:
>
> On 10/29/2014 12:42 AM, Doug Hellmann wrote:
>>
>> Another way to do this, which has been used in some other projects,
>> is to define one option for a list of “names” of things, and use
>> those names to make groups with each field
>
>
> I've proposed that in [1].  I look forward to some -1's :)
>
>
>> OTOH, oslo.config is not the only way we have to support
>> configuration. This looks like a good example of settings that are
>> more complex than what oslo.config is meant to handle, and that
>> might be better served in a separate file with the location of that
>> file specified in an oslo.config option.
>
>
> My personal opinion is that yet-another-config-file in possibly
> yet-another-format is just a few lines of code, but has a pretty high
> cost for packagers, testers, admins, etc.  So I feel like that's
> probably a last-resort.

Mangling hardware data into an obtuse format is harder than it needs to be.
Dropping a new file in /etc is very ready for a deployer.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] New function: first_nonnull

[Clint Byrum]

Excerpts from Zane Bitter's message of 2014-11-06 15:35:09 -0800:
> On 06/11/14 20:44, Steven Hardy wrote:
> > On Wed, Nov 05, 2014 at 02:46:43PM +, Lee, Alexis wrote:
> >> I'm considering adding a function which takes a list and returns the 
> >> first
> >>
> >> non-null, non-empty value in that list.
> >>
> >> So you could do EG:
> >>
> >> some_thing:
> >>
> >> config:
> >>
> >> ControlVIP:
> >>
> >> first_nonnull:
> >>
> >> - {get_param: ControlVIP}
> >>
> >> - {get_attr: [ControlVirtualIP, fixed_ips, 0,
> >> ip_address]}]}
> >>
> >>
> >> I'm open to other names, EG "some", "or", "fallback_list" etc.
> >>
> >> Steve Hardy suggested building this into get_attr or Fn::Select. My
> >> feeling is that those each do one job well right now, I'm happy to
> >> take a steer though.
> >
> > Ah, from our IRC discussion I was thinking you wanted primarily list
> > filtering of get_attr output, thus thinking an optional argument would make
> > more sense than a new function.
> >
> > I see now that you're actually looking for something of a poor-mans
> > conditional, so you choose either the ControlVIP parameter, or the
> > ControlVirtualIP attribute, for which your proposal is probably cleaner -
> > my concern is just that we avoid a proliferation of different list
> > select/filter functions, when we could just have one.
> 
> 
> Crazy thought: why not just implement conditionals? We had a proto-spec 
> for them started at one point...
> 

The coalesce/first_nonnull is just a shortcut for a common conditional
problem. I'd agree that conditionals are useful as well, but they might
be better served by more time to bake than this more narrow case.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] New function: first_nonnull

[Clint Byrum]

Excerpts from Angus Salkeld's message of 2014-11-09 00:15:42 -0800:
> On 06/11/2014 8:32 AM, "Clint Byrum"  wrote:
> >
> > Excerpts from Lee, Alexis's message of 2014-11-05 15:46:43 +0100:
> > > I'm considering adding a function which takes a list and returns the
> first
> > > non-null, non-empty value in that list.
> > >
> > > So you could do EG:
> > >
> > > some_thing:
> > > config:
> > > ControlVIP:
> > > first_nonnull:
> > > - {get_param: ControlVIP}
> > > - {get_attr: [ControlVirtualIP, fixed_ips, 0,
> ip_address]}]}
> > >
> > > I'm open to other names, EG "some", "or", "fallback_list" etc.
> > >
> > > Steve Hardy suggested building this into get_attr or Fn::Select. My
> feeling
> > > is that those each do one job well right now, I'm happy to take a steer
> > > though.
> > >
> > > What do you think please?
> > >
> >
> > Yes this is super useful for writing responsive, reusable templates.
> >
> > I'd like to suggest that this be called 'coalesce' as that is what SQL
> > calls it.
> 
> Although I have no clue why they called it that (colalesce mean join/merge
> not get first non-null). I'd rather it be called what it does
> "first_nonnull()" seems more obvious to me. We could also try the
> conditional as Zane suggested.

I believe it is called that because it is meant to coalesce a list of
variables in descending priority into one, which is precisely the use
case presented.

That said, first_nonnull is fine too if that nuance is not as obvious to
others as it is to me. :-P

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] [UX] Curvature interactive virtual network design

[Stuart Fox]

+1 from me

Also, can you get Cisco to opensource Avos? It was demo'd at Atlanta

On Sun, Nov 9, 2014 at 6:45 AM, Chris Dent  wrote:

> On Fri, 7 Nov 2014, John Davidge (jodavidg) wrote:
>
>  We’d like to gauge interest from the community on whether this is
>> something people want.
>>
>
> When I go to the existing network topology maps in horizon I
> frequently find myself wanting to drag stuff around.
>
> So +1 from me.
>
> --
> Chris Dent tw:@anticdent freenode:cdent
> https://tank.peermore.com/tanks/cdent
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
BR,
Stuart
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] [neutron] local.conf for devstack using neutron on home network

[Kashyap Chamarthy]

On Sun, Nov 09, 2014 at 02:48:49PM +, Chris Dent wrote:
> On Sat, 8 Nov 2014, Kashyap Chamarthy wrote:
> 
> >[I realize you intend to use physical machine for DevStack, still I
> >thought I'd post this here.]
> 
> Thanks for posting it. Each added datapoint will get us closer.
> 
> >FWIW, this[1] is the minimal localrc contents (be sure to edit
> 
> That's minimal? :)

Hmm, apart from Cinder service in the said config, rest of them all
noted there are essential to get a minimal, functional DevStack --
at-least in my testing. Cinder isn't normally part of my test
environment (maybe I should add it), but I was investigating a bug in
that case, so if you don't prefer it, you can elide these:
c-api,c-bak,c-sch,c-vol.

That said, I should have defined what I consider minimal, broadly: Nova
(libvirt/KVM driver with nested virt), Neutron (OVS+GRE or VXLAN),
Keystone (with PKI), Glance.

> >Once the stack.sh is complete, I do some tasks Neutron expects:
> >
> > - Create a new private network
> > - Create a new private subnet (on the above private network)
> > - Create a router
> > - Associate the router to an existing external network by setting it
> >   as its gateway
> > - Associate the private network interface to the router
> > - Add Neutron security group rules for ICMP and SSH
 
> For devstack to live up to the "dev" in its name the above steps are
> something I would expect devstack to do for me, assuming I set the
> right varables and enabled the right services in local.conf.
 

-- 
/kashyap

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] [neutron] local.conf for devstack using neutron on home network

[Chris Dent]

On Sat, 8 Nov 2014, Kashyap Chamarthy wrote:


[I realize you intend to use physical machine for DevStack, still I
thought I'd post this here.]


Thanks for posting it. Each added datapoint will get us closer.


FWIW, this[1] is the minimal localrc contents (be sure to edit


That's minimal? :)


Once the stack.sh is complete, I do some tasks Neutron expects:

 - Create a new private network
 - Create a new private subnet (on the above private network)
 - Create a router
 - Associate the router to an existing external network by setting it
   as its gateway
 - Associate the private network interface to the router
 - Add Neutron security group rules for ICMP and SSH


For devstack to live up to the "dev" in its name the above steps are
something I would expect devstack to do for me, assuming I set the
right varables and enabled the right services in local.conf.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] [UX] Curvature interactive virtual network design

[Chris Dent]

On Fri, 7 Nov 2014, John Davidge (jodavidg) wrote:


We’d like to gauge interest from the community on whether this is something 
people want.


When I go to the existing network topology maps in horizon I
frequently find myself wanting to drag stuff around.

So +1 from me.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Test runner for python tests and parallel execution

[Chris Dent]

On Sat, 8 Nov 2014, Robert Collins wrote:


What changes do you want to see in the ui?


I don't want to hijack the thread too much so I hope Dmitriy will join
back in but for me there are two aspects of the existing experience
that don't work out well. I suspect many of these situations can be
resolved with more info (that is, the bug is in my ignorance, not in
the software).

* Lack of transparency on how to manage verbosity and output handling
  during a test run. Obviously the output during an unobserved run is
  going to need to be different from what I as a devloper want while
  doing an observed run.

  In the latter case I want to know, while it is happening, which
  tests have been discovered, which one is happening right now, and a
  sense of the status of the current assert.

  I want, at my option, to spew stderr and stdout directly without
  interference so I can do unhygenic debugging.

  Essentially, I want to be able to discover the flags, arguments and
  toosl that allow me to use tests as an ad hoc development aid, not
  post hoc.

  I know this is possible with the existing tools, it's just not easy
  nor easy (for me) to discover.

* The current testing code and tools are, to use that lovely saw, "hard
  to reason about". Which for me equates to "hard to read".

  This is perhaps because I'm not particular wed to _unit_ tests,
  _unittest_ formed tests, or concepts such as test isolation and
  hates mocks. I see the value of these things but I think it is
  easy for them to be overused and make other purposes more difficult.

  I threw this[1] up on the list a little while, which is related:
  Same complaints and a hope that we won't have the same over-emphasis
  when we move to in tree testing.

Summary: I think we need to spend some time and thought on improving
the usefulness of tests, testing and testing tools for someone working
on a feature or a bug _right now_. That is: tests run by humans should
be as frictionless as possible so that bugs are caught[2] and fixed
before test suites are ever run by robots.

[1] https://tank.peermore.com/tanks/cdent-rhat/SummitFunctionalTesting

[2] And with luck will help create more effective and usable code[3].

[3] Yes, I believe in TDD.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] New function: first_nonnull

[Angus Salkeld]

On 06/11/2014 8:32 AM, "Clint Byrum"  wrote:
>
> Excerpts from Lee, Alexis's message of 2014-11-05 15:46:43 +0100:
> > I'm considering adding a function which takes a list and returns the
first
> > non-null, non-empty value in that list.
> >
> > So you could do EG:
> >
> > some_thing:
> > config:
> > ControlVIP:
> > first_nonnull:
> > - {get_param: ControlVIP}
> > - {get_attr: [ControlVirtualIP, fixed_ips, 0,
ip_address]}]}
> >
> > I'm open to other names, EG "some", "or", "fallback_list" etc.
> >
> > Steve Hardy suggested building this into get_attr or Fn::Select. My
feeling
> > is that those each do one job well right now, I'm happy to take a steer
> > though.
> >
> > What do you think please?
> >
>
> Yes this is super useful for writing responsive, reusable templates.
>
> I'd like to suggest that this be called 'coalesce' as that is what SQL
> calls it.

Although I have no clue why they called it that (colalesce mean join/merge
not get first non-null). I'd rather it be called what it does
"first_nonnull()" seems more obvious to me. We could also try the
conditional as Zane suggested.

-Angus

>
> ___
> 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