On 28 April 2015 at 10:14, Duncan Thomas wrote:
> If we allow third party CI to fail and wait for vendors to fix their
> stuff, experience has shown that they won't, and there'll be broken or
> barely functional drivers out there, and no easy way for the community to
> exert pressure to fix them
On 23 April 2015 at 01:17, Maru Newby wrote:
> My name is Maru Newby, and I am announcing my candidacy for the
> Technical Committee (TC) election.
>
Cool!
** Growing our contributors
>
Question regarding your candidacy:
If I recall correctly you have spoken in favor of face to face discussio
On 22 October 2014 16:34, Steve Gordon wrote:
> Thanks to those who attended the meeting today, for those who missed in
> minutes and the full log are available at these locations:
>
Apologies for absence. Here is an update from me:
We are currently developing the Snabb mechanism driver out-of-
On 1 September 2014 09:10, loy wolfe wrote:
> If the neutron side MD is just for snabbswitch, then I thinks there is no
> change to be merged into the tree. Maybe we can learn from sriov nic,
> although backend is vendor specific, but the MD is generic, can support
> snabb, dpdkovs, ans other use
Howdy!
I am writing to ask whether it will be possible to merge VIF_VHOSTUSER [1]
in Juno?
VIF_VHOSTUSER adds support for a QEMU 2.1 has a feature called vhost-user
[2] that allows a guest to do Virtio-net I/O via a userspace vswitch. This
makes it convenient to deploy new vswitches that are opti
On 21 August 2014 12:12, Ihar Hrachyshka wrote:
> Let the ones that are primarily interested in
> good quality of that code (vendors) to drive development. And if some
> plugins become garbage, it's bad news for specific vendors; if neutron
> screws because of lack of concentration on core featur
On 19 August 2014 23:15, Alan Kavanagh wrote:
> +1, I am hoping this is just a short term holding point and this will
> eventually be merged into main branch as this is a feature a lot of
> companies, us included would definitely benefit from having supported and
> many thanks to Sean for stickin
Congrats Sukhdev :) That's no small feat.
On 7 August 2014 03:41, Sukhdev Kapur wrote:
> I am looking into the scenario tests. Having some issues with them. Will
> soon be adding a few to the test suite.
>
This is also where I'm at with the Tail-f CI driver. I am running API tests
stably now bu
On 8 August 2014 15:27, Russell Bryant wrote:
> It sounds like what you're working on is a separate thing.
>
Roger. Just wanted to check if our work could have some broader utility,
but as you say we do have a specific use case in mind.
Cheers!
-Luke
On 8 August 2014 02:06, Michael Still wrote:
> 1: I think that ultimately should live in infra as part of check, but
> I'd be ok with it starting as a third party if that delivers us
> something faster. I'd be happy enough to donate resources to get that
> going if we decide to go with this plan.
Howdy!
Rumor has it that it's easy to distribute ML2 mech drivers as out-of-tree
add-on modules.
Is this true? Has it been done? Where would one find an example?
Cheers!
-Luke
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://list
Hi Salvatore,
On 5 August 2014 10:34, Salvatore Orlando wrote:
> Once in place, the CI system should be able to pick up the patches from
> the new plugin or driver on gerrit.
>
> In my opinion, successful CI runs against those patches should constitute
> a sufficient proof of the validity of the
Howdy,
Could somebody please clarify the protocol for bringing up a CI for a new
Neutron driver?
Specifically, how does one resolve the chicken-and-egg situation of:
1. CI should be enabled before the driver is merged.
2. CI should test the refspecs given by Gerrit, which will not include the
c
Hi Steve,
Thanks for the continuing help!
On 29 July 2014 20:25, Steve Gordon wrote:
> It appears to me the expectation/desire from Mark and Maru here is to see
> a lot more justification of the use cases for this driver and the direction
> of the current implementation
>
I am attempting to sa
Howdy!
Our feature "Snabb NFV mech driver" has become controversial on Gerrit.
Mark and Maru suspect that it is fundamentally ill-conceived. This mail is
to explain the background and advertise that we are available for
discussion. (No pressure, I just want to volunteer relevant information.)
Blu
On 29 July 2014 10:48, Luke Gorrie wrote:
> We are developing a practical open source NFV implementation for
> OpenStack. This is for people who want to run tens of millions of packets
> per second through Virtio-net on each compute node.
>
Incidentally, we do currently achieve ~ li
Hi Steve,
On 29 July 2014 17:21, Steve Gordon wrote:
> I've added the [third-party] tag as well to ensure this catches the
> broadest segment of relevant people.
>
Thanks!
> are any modifications to upstream Open vSwitch required to support Snabb?
>
Good question. No, this uses a separate vs
On 28 July 2014 11:37, Salvatore Orlando wrote:
> Therefore the likeness of your patch merging depends on the specific
> nature of the -1 you received.
>
This is really a key point.
Here is a pattern that's worth recognising:
If your code is in reasonable shape but there is no urgent need to c
Greetings fellow NFV'stas!
I would like to explain and solicit feedback on our plan to support a new
open source NFV system in Juno. This work is approved as
low-priority/best-effort for Juno-3. (Yes, we do understand that we are
fighting the odds in terms of the Juno schedule.)
We are developing
On 25 July 2014 20:05, Stefano Maffulli wrote:
> Indeed, communication is key. I'm not sure how you envision to
> implement this though. We do send a message to first time
> contributors[1] to explain them how the review process works and give
> them very basic suggestions on how to react to comm
On 24 July 2014 17:09, Kyle Mestery wrote:
> I've received a lot of emails lately, mostly private, from people who
> feel they are being left out of the Neutron process. I'm unsure if
> other projects have people who feel this way, thus the uniquely worded
> subject above. I wanted to broadly add
Thanks everybody!
Onward :-)
On 24 July 2014 19:41, Anita Kuno wrote:
> On 07/24/2014 01:18 PM, Kyle Mestery wrote:
> > On Thu, Jul 24, 2014 at 12:03 PM, Collins, Sean
> > wrote:
> >> On Wed, Jul 23, 2014 at 11:19:13AM EDT, Luke Gorrie wrote:
> >>> Tai
On 22 July 2014 11:06, Luke Gorrie wrote:
> End of Part One.
>
Let's skip Part Two. That is just more frustration.
Let's talk about Part Three in which we all do awesome CI hacking in Juno
together :-).
Here is what I want to achieve in Juno:
NFV CI: Myself and my colleague
On 22 July 2014 11:06, Luke Gorrie wrote:
> This must have been bad for you guys since you were stuck waiting on us
> and couldn't fix the problem on your side. I was also contacted by email,
> as the previous contact person for that driver, but the message simply
> asked
Hi Sean,
On 21 July 2014 22:53, Collins, Sean
wrote:
> The fact that I tried to reach out to the person who was listed as the
> contact back in November to try and resolve the –1 that this CI system
> gave, and never received a response until the public mailing list thread
> about revoking vot
Howdy!
I am writing to request voting rights for the Tail-f CI account. This runs
tests for the Tail-f NCS ML2 mechanism driver in Neutron.
This account has been non-votingly testing ML2 changes and posting results
since June 10th. It has made around 500 test runs in that time. I am
monitoring it
On 11 July 2014 17:56, Kyle Mestery wrote:
>
>1. Tail-F
> 1. Inconsistent past runs, need updates on status.
>
> I've updated the Etherpad for our Tail-f CI and will be at the meeting.
Cheers,
-Luke
___
OpenStack-dev mailing list
OpenStack-de
Hi again Jon Paul,
My mistake! This seems to be exactly what I was looking for, thank you. (I
goofed the query which is why I thought it was lacking.)
Cheers :)
-Luke
On 10 July 2014 09:17, Luke Gorrie wrote:
> On 9 July 2014 20:24, Sullivan, Jon Paul wrote:
>
>>Incidental
On 10 July 2014 10:06, Luke Gorrie wrote:
> The main new feature now is to automatically retrigger events that neither
> definitely succeed (exit status 100) nor definitely fail (exit status 101).
> In this case the CI will vote "0" with the logs and then automatically
> s
Howdy!
I've been operating a shellci for a while now and overall it is very smooth.
The main new feature now is to automatically retrigger events that neither
definitely succeed (exit status 100) nor definitely fail (exit status 101).
In this case the CI will vote "0" with the logs and then autom
On 9 July 2014 20:24, Sullivan, Jon Paul wrote:
>Incidentally, is there already way to review what votes my CI (or
> indeed anybody's) is casting via an openstack.org web interface?
>
>
>
> >>> You can look at the individual account dashboards in Gerrit, like:
> https://review.openstack.org/#
On 7 July 2014 11:41, Luke Gorrie wrote:
> I'm running an additional non-voting instance that runs five parallel
> builds and triggers on all OpenStack projects.
>
To clarify: by "non-voting" I mean not posting any results to
review.openstack.org at all, to avoid noi
On 3 July 2014 19:05, Luke Gorrie wrote:
> Time to make it start running real tempest tests.
>
Howdy!
shellci now supports running parallel build processes and by default
runs each test with devstack+tempest in a one-shot Vagrant VM.
The README is updated on Github: https://gith
On 3 July 2014 19:02, Jay Pipes wrote:
> devstack-gate works very well for what it is supposed to do:
>
Yeah, I would actually love to use devstack-gate.
I tried that first. There are two problems for me as a user:
First I didn't manage to get it up and running reliably in a reasonable
time fr
On 1 July 2014 19:12, Luke Gorrie wrote:
> It does not yet run devstack/tempest and I hope to reuse that part from
> somebody else's efforts.
>
shellci is happily voting on the sandbox with the Snabb NFV CI account so
far: http://egg.snabb.co:81/shellci/shellci.log
Time to
On 3 July 2014 02:44, Michael Still wrote:
> The main purpose is to let change reviewers know that a change might
> be problematic for a piece of code not well tested by the gate
Just a thought:
A "sampling" approach could be a reasonable way to stay responsive under
heavy load and still give
On 3 July 2014 02:44, Michael Still wrote:
> I have seen both. Normally there's a failure, reviewers notice, and
> then the developer spins trying out fixes by uploading new patch sets.
>
Interesting. Yes, I can see that you need fast response from CIs to support
that scenario. 12-hour edit-comp
On 2 July 2014 20:33, Luke Gorrie wrote:
> I'd love to see links to such reviews, if anybody has some? (I've only
> seen positive reviews and false-negative reviews from 3rd party CIs so far
> in my limited experience.)
>
I didn't say what I meant: reviews where a
On 30 June 2014 21:04, Kevin Benton wrote:
> As a maintainer of a small CI system that tends to get backed up during
> milestone rush hours, it would be nice if we were allowed up to 12 hours.
> However, as a developer this seems like too long to have to wait for the
> results of a patch.
>
Inter
On 2 July 2014 10:39, Gary Kotton wrote:
> There are some patches that are relevant to the NFV support. There are
> as follows:
>
Additionally, we who are building Deutsche Telekom's open source NFV
implementation will be able to make that available to the whole community
if the VIF_VHOSTUSER s
Howdy!
I wrote a new version of shellci today and have it up and running and
voting on the sandbox.
It's described on the Github page: https://github.com/SnabbCo/shellci
Currently this is simple shell scripts to receive review.openstack.org
gerrit events, run tests and determine results, then po
On 30 June 2014 21:08, Anita Kuno wrote:
> I am disappointed to realize that Ilya (or stackalytics, I don't know
> where this is coming from) is unwilling to cease making up definitions
> of success for third party ci systems to allow the openstack community
> to arrive at its own definition.
>
I have a really early sketch of this project on Github now.
shellci - OpenStack 3rd party CI in 100 lines of shell
https://github.com/SnabbCo/shellci
This is not finished yet but I'll try to use it for the new Neutron mech
driver that I want to contribute to Juno.
Ideas and encouragement welcome
On 30 June 2014 19:37, Asselin, Ramy wrote:
> Not sure if these are “minimalist” but at least they setup
> automagically, so you don’t need to do it from scratch:
>
I'm aiming to do exactly the opposite of this i.e. no automagic.
My experience has been that the really heavy-duty CI setups are
On 30 June 2014 17:34, Kyle Mestery wrote:
> It would be great to get you to join the 3rd Party meeting [1] in
> #openstack-meeting at 1800UTC to discuss this. Can you make it today
> Luke?
>
Yes, I'll be there.
Currently I'm looking into "the simplest 3rd party CI that could possibly
work" whi
Howdy!
Paging other 3rd party CI operators...
I would like to run a simple and robust 3rd party CI. Simple as in a small
number of moving parts, robust as in unlikely to make mistakes due to
unexpected problems.
I'm imagining:
- 100 lines of shell for the implementation.
- Minimum of daemons.
On 18 June 2014 12:00, Carlos Gonçalves wrote:
> I’ve added Joao Soares (Portugal Telecom) and myself (Instituto de
> Telecomunicacoes) to https://wiki.openstack.org/wiki/Sprints/ParisJuno2014 for
> a Neutron and NFV meetup.
> Please add yourselves as well so that we can have a better idea of who
On 18 June 2014 18:24, Salvatore Orlando wrote:
> it seems something is not quite right with your tempest environment - you
> have import errors at startup [1]
> This might be happening because of missing dependencies, or, if you have
> applied some custom patches to tempest trunk, possibly those
On 18 June 2014 15:48, Salvatore Orlando wrote:
> Hi Luke,
>
> That kind of message usually shows up in unit tests job when there is some
> syntax error or circular import. But I think that it's not your case.
> Usually you see an "import error" message towards the end of the "garbage".
>
> If yo
On 17 June 2014 09:55, Luke Gorrie wrote:
> I have a problem that appeared at the same time and may be related? "testr
> list-tests" in the tempest directory is failing with an obscure error
> message. Seems to be exactly the situation described here:
> https://bugs.laun
On 15 June 2014 02:45, Sukhdev Kapur wrote:
> I thought I send out this message in case other CI maintainers are
> investigating this issue.
>
I have a problem that appeared at the same time and may be related? "testr
list-tests" in the tempest directory is failing with an obscure error
message.
On 13 June 2014 11:45, Carlos Gonçalves wrote:
> Neutron and NFV team members, who’s interested in meeting in Paris, or if
> not available on the date set by eNovance in other time and place?
>
I'd be very interested in an NFV meet up in Paris in July.
Cheers,
-Luke
On 10 June 2014 18:18, Irena Berezovsky wrote:
> Hi Luke,
>
> Very impressive solution!
>
Thanks for the kind words!
>
>
> I do not think there is a problem to keep agent out of the tree in a short
> term, but would highly recommend to put it upstream in a longer term.
>
> You will benefit fro
Hi Sean,
On 10 June 2014 18:09, Collins, Sean
wrote:
> One of the links that is posted in that review comment for the Tail-f
> NCS Jenkins timed out for me.
>
> http://egg.snabb.co:8080/job/jenkins-ncs/19/
>
> I notice that there is another link included in that review that does
> work and has t
Howdy!
Here is a successful Sandbox test from right now:
https://review.openstack.org/#/c/99061/. I don't immediately see how to
list all historical sandbox tests. (The previous ones are from before the
Summit anyway.)
I enabled the CI for the openstack/neutron Gerrit feed now. Here is a
change t
Hi Irena,
Thanks for the very interesting perspective!
On 10 June 2014 10:57, Irena Berezovsky wrote:
> *[IrenaB] The DB access approach was previously used by OVS and
> LinuxBridge Agents and at some point (~Grizzly Release) was changed to use
> RPC communication.*
>
That is very interesting
Howdy Kyle,
On 9 June 2014 22:37, Kyle Mestery wrote:
> After talking with various infra folks, we've noticed the Tail-f CI
> system is not voting anymore. According to some informal research, the
> last run for this CI setup was in April [1]. Can you verify this
> system is still running? We wi
On 6 June 2014 10:17, henry hly wrote:
> ML2 mechanism drivers are becoming another kind of "plugins". Although
> they can be loaded together, but can not work with each other.
>
[...]
> Could we remove all device related adaption(rest/ssh/netconf/of... proxy)
> from these mechanism driver to th
Can't wait :-).
On 14 May 2014 19:06, Chris Wright wrote:
> Thursday at 1:30 PM in the Neutron Pod we'll do
> an NFV BoF. If you are at design summit and
> interested in Neutron + NFV please come join us.
>
> thanks,
> -chris
>
> ___
> OpenStack-dev ma
Howdy!
Here's some follow-up on setting up devstack-vm-gate as a 3rd party.
On 13 March 2014 15:30, Luke Gorrie wrote:
> 1. I need to enable an ML2 mech driver. How can I do this? I have been
> trying to create a localrc with a "Q_ML2_PLUGIN_MECHANISM_DRIVERS=..."
> l
oh and in my haste I forgot to say: thank you extremely much to everybody
who's been giving me pointers on IRC and especially to Jay for the blog
walkthrough!
On 13 March 2014 15:30, Luke Gorrie wrote:
> Howdy!
>
> I have some tech questions I'd love some pointers on
Howdy!
I have some tech questions I'd love some pointers on from people who've
succeeded in setting up CI for Neutron based on the upstream devstack-gate.
Here are the parts where I'm blocked now:
1. I need to enable an ML2 mech driver. How can I do this? I have been
trying to create a localrc w
On 4 March 2014 17:07, Jay Pipes wrote:
> I would advise dropping the custom CI setup and going with a method that
> specifically uses the upstream openstack-dev/devstack and
> openstack-infra/devstack-gate projects.
>
This sounds great to me. Thank you for all the work you are doing on
simplify
Hi Jay,
(Switching Subject to third party testing)
On 4 March 2014 15:13, Jay Pipes wrote:
> Let me know how we can help you!
>
Thanks for the invitation! I will take you up on it :-).
My goal is to make sure the Tail-f NCS mechanism driver is fully supported
in Icehouse.
Question: How shoul
On 4 March 2014 11:40, Thierry Carrez wrote:
> This is a technical requirement, and failing to match those requirements
> is clearly not the same as engaging in deception or otherwise failing
> the OpenStack community code of conduct.
>
Thank you for clearing that up!
___
On 3 March 2014 18:30, Thierry Carrez wrote:
> My advice was therefore that you should not wait for that to happen to
> engage in cooperative behavior, because you don't want to be the first
> company to get singled out.
>
"Cooperative behavior" is vague.
Case in point: I have not successfully
On 3 March 2014 11:27, Thierry Carrez wrote:
> It will certainly hurt the first one we nail on the wall. So here is one
> reputational pressure: you don't want to be that company.
>
> [1] http://fnords.wordpress.com/2014/02/24/the-dilemma-of-open-innovation/
-1.
That's a really harsh threat be
Howdy!
My name is Luke and I'm helping my friends at Tail-f Systems to
support Neutron with their NCS [1] product. This went really smoothly
for us on the Havana cycle, but lately we're having a harder time with
Icehouse. In particular, our attempt to fulfill the 3rd party testing
requirements has
On 23 January 2014 17:42, Calum Loudon wrote:
> That sounds fantastic. As an NFV application developer I'm very pleased
> to see this contribution which looks to eliminate the key bottleneck
> hitting the performance of very high packet throughput apps on
> OpenStack.
>
Thanks for the kind word
he port-update that precedes VIF
> plugging. That would leave you with the option of passing the path back and
> requesting an actual passthrough or coming up with some other mechanism of
> your own choosing (which may not involve changing Nova at all, if you're
> using your
Hi Mike,
On 10 January 2014 17:35, Michael Bright wrote:
> Very pleased to see this initiative in the OpenStack/NFV space.
Glad to hear it!
> A dumb question - how do you see this related to the ongoing
> "[openstack-dev] [nova] [neutron] PCI pass-through network support"
>
> discussion o
Howdy Stackers!
We are developing a new open source Network Functions Virtualization
driver for Neutron. I am writing to you now to ask for early advice
that could help us to smoothly bring this work upstream into OpenStack
Juno.
The background is that we are open source developers working to
sat
On 6 January 2014 18:12, Collins, Sean wrote:
> How should we handle existing -1's that have been posted?
I suggest removing/ignoring those votes until we see if they are spurious.
The Tail-f NCS plugin is very simple code and I'd say it's unlikely
that any recent changes will have broken it in
Hi guys,
On 6 January 2014 14:44, Anita Kuno wrote:
> If the account holder of this account is reading this email, responding
> to it would certainly be a good idea.
Apologies for the disturbance!
Please do go ahead and disable the voting rights while we work out
what's going wrong and get the
On 21 October 2013 19:51, Sean M. Collins wrote:
> The motivation is to help Neutron work with IPv6 - which is a must-have
> for Comcast.
>
Deutsche Telekom too. We are working on making Neutron interoperate well
with a service provider network that's based on IPv6. I look forward to
talking abo
Howdy!
I'm trying to get ml2 up and running with devstack. I'm falling at the
first hurdle - getting devstack working with Neutron. I would love a hint!
Here is my localrc:
disable_service n-net
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-
Hi guys,
Can someone tell me the best way currently to run a subset of Neutron unit
tests (e.g. ml2 ones)?
The command I got the last time I asked has recently stopped working:
On 6 June 2013 17:16, Luke Gorrie wrote:
> The .venv/bin/python run_tests.py ... trick works for me after . I am
I also won't make the meeting today. I have now started writing code for
the Tail-f NCS mechanism driver based on Andre's great work. Thanks Andre !
On 10 July 2013 06:53, Andre Pech wrote:
> Thanks Kyle,
>
> I'm unfortunately going to be on a plane during tomorrow's meeting, so
> wanted to sen
18 jun 2013 kl. 15:28 skrev Kyle Mestery (kmestery):
>> Kyle, do you guys have the same issue with the OpenDaylight plugin?
>>
> We will want subnets for the ODL ML2 driver as well, so I think we'll want
> them here as well. Luke, maybe add these comments into the MechanismDriver
> review here
18 jun 2013 kl. 15:28 skrev Kyle Mestery (kmestery):
>> Kyle, do you guys have the same issue with the OpenDaylight plugin?
>>
> We will want subnets for the ODL ML2 driver as well, so I think we'll want
> them here as well. Luke, maybe add these comments into the MechanismDriver
> review here
12 jun 2013 kl. 09:25 skrev Andre Pech:
> As promised at the ml2 kickoff meeting last week, attached is our basic
> proposal for the ml2 mechanism driver API.
Great, that is fast work!
> After getting more familiar with the ml2 plugin code and looking at some of
> the other blueprints that ar
81 matches
Mail list logo
